From: Tim Fletcher (groupstudy@fletchmail.net)
Date: Fri Mar 26 2004 - 19:57:05 GMT-3
Good explanation Tom. I'd like to add a few comments if I may.
At 12:28 PM 3/25/04, Tom Lijnse wrote:
>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.
One of the side effects of demand circuit is that any topology change will bring up the ISDN circuit, not just the circuit that you are backing up. So if another circuit anywhere in your OSPF domain (or even beyond if you're doing redistribution) changes state, your ISDN circuit will come up.
>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.
Dialer watch will keep the circuit up until the primary path is restored, regardless of whether there is interesting traffic or not. When you configure dialer watch, you don't even need to (and probably shouldn't) define interesting traffic.
>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.
Configuring both does work, but gives you the worst of both worlds. It would bring the ISDN circuit up anytime there is a topology change, which could result in unnecessary calls. And if the primary circuit did go down, it would stay up until the primary is restored, even if there is no traffic.
>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:48 GMT-3