From: Packet Man (ccie2b@hotmail.com)
Date: Thu Mar 25 2004 - 14:38:21 GMT-3
Thanks Tom for that great and comprehensive explanation. I think there's
been alot of confusion about these 2 features and your post clears all that
up.
pm
>From: "Tom Lijnse" <Tom.Lijnse@globalknowledge.nl>
>Reply-To: "Tom Lijnse" <Tom.Lijnse@globalknowledge.nl>
>To: "Chris Fontes" <cfontes@atrion.net>, "Joseph D. Phillips"
><jphillips@ufcwdrugtrust.org>, "Group Study (E-mail)"
><ccielab@groupstudy.com>
>Subject: RE: OSPF Demand circuit and Backup
>Date: Thu, 25 Mar 2004 18:28:49 +0100
>
>Hi all,
>
>I tend to agree with Chris here. Both techniques can accomplish the same
>goal and they don't need to be configured simultaneously. (Of course you
>can configure both at the same time and it will still work, so in that
>respect they're "compatible").
>
>The behavior is somewhat different though and especially you have to pay
>attention to your interesting traffic definitions. For both features you
>will have to configure the regular DDR stuff. In addition you need to take
>the following into account:
>
>1) OSPF on Demand Feature
>
>The idea is to have any ip traffic defined as interesting traffic
>(including OSPF). OSPF will trigger the link, exchange databases across the
>ISDN and after that hellos will be suppressed and unless there's a topology
>change OSPF will not trigger the link. You have to make sure that the cost
>of the ISDN link is higher than the cost of the primary, so regular user
>traffic will be routed across the primary. Now if the primary goes down,
>OSPF will trigger the ISDN to exchange the newly generated LSAs and then
>recalculate routes. All user traffic will now be routed across the ISDN. If
>there's no user traffic the ISDN will go down, because OSPF still
>suppresses hellos. Any new interesting packets will trigger the link, since
>the routing table.
>
>2) Dialer Watch Feature
>
>You configure regular DDR, but you explicitly exclude OSPF from your
>interesting traffic definitions. We don't want OSPF triggering the link,
>since the dialer watch feature is going to trigger the link when the
>watched routes disappear from the routing table. So basically what happens
>is that OSPF initially only forms an adjacency across the primary link, not
>across the ISDN, so all user traffic is routed across the primary. When the
>primary goes down the watched route disappears and dialer watch kicks in.
>Now OSPF forms an adjacency across the ISDN, exchanges the database and
>recalculates to route user traffic across the ISDN.
>
>So each of the two methods accomplishes the same overall goal: Rerouting
>user traffic across the ISDN when the primary goes down. No need to
>configure them both at the same time.
>
>Regards,
>
>Tom Lijnse
>
>CCIE #11031
>Global Knowledge Netherlands
>
>P.S. sorry for repeating some things already mentioned in this thread. The
>replies came in while I was composing this mail. I figured this post might
>serve as a final summary so I decided to hit the "send" button anyway.
>
>
>
>
>-----Original Message-----
>From: Chris Fontes [mailto:cfontes@atrion.net]
>Sent: Thursday, March 25, 2004 5:20 PM
>To: 'Joseph D. Phillips'; Group Study (E-mail)
>Subject: RE: OSPF Demand circuit and Backup
>
>
>Hi all
>
>Not sure I agree with your whole explanation Joseph.
>
>OSPF demand circuit does keep the link from flapping, but once there is a
>topology change the link will come up, ospf will converge and routing will
>take place over the link. It will provide reachability.
>
>With dialer watch you only need a dialer map statement for the specific
>network(s) that are being watched with the dialer watch-list not for each
>network that would be lost if the primary connection goes down (ie if your
>learning 6 routes over your primary link, you could just watch one of them
>with dialer watch). If the network drops from the routing table, dialer
>watch will bring the ISDN link up, ospf will converge and routing will take
>place over the link.
>
>Each method would provide the same results.
>
>Packet Man I can't think of any reason why you would cofigure both at the
>same time. Its two different methods that provide the same results.
>
>Chris
>
>-----Original Message-----
>From: Joseph D. Phillips [mailto:jphillips@ufcwdrugtrust.org]
>Sent: Thursday, March 25, 2004 10:44 AM
>To: Group Study (E-mail)
>Subject: OSPF Demand circuit and Backup
>
>
>Dialer watch and OSPF demand-circuit accomplish two different purposes.
>
>OSPF demand only keeps the BRI link from flapping after the BRI's IP
>network
>is defined under the OSPF router process.
>
>By itself, it does not provide any reachability to any networks.
>
>If you want a true backup of a frame-relay network, you'd need
>dialer-watch,
>and you'd have to create a dialer map statement for each network which
>would
>be lost if the primary connection goes down.
>
>
>-----Original Message-----
>From: Packet Man [mailto:ccie2b@hotmail.com]
>Sent: Thursday, March 25, 2004 07:12
>To: ccielab@groupstudy.com
>Subject: OSPF Demand circuit and Backup
>
>
>Hi all,
>
>When an ISDN circuit is configured as an OSPF demand-circuit to backup
>another OSPF link in the same area, should and can any other backup method
>such as Dialer Watch also be configured on the same ISDN link?
>
>My sense is that there's no need to configure any other backup method and
>doing so would only complicate things and lead to unexpected results.
>
>Here's what I believes happens in such a situation (without 2nd method
>configured).
>
>Primary link goes down.
>
>This causes ospf to see a topology change has occurred.
>
>OSPF floods lsa over all links including ISDN circuit which brings up ISDN
>circuit.
>
>OSPF updates the route table to reflect new topology.
>
>Now, user traffic that would have used the primary link now uses the ISDN
>link.
>
>Is this simplified chain of events correct? Are there other significant
>things that occur that we should be aware of?
>
>Thanks in advance, pm
>
>_________________________________________________________________
>Get rid of annoying pop-up ads with the new MSN Toolbar FREE!
>http://toolbar.msn.com/go/onm00200414ave/direct/01/
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Apr 01 2004 - 08:15:47 GMT-3