From: Tim Fletcher (groupstudy@fletchmail.net)
Date: Fri Mar 26 2004 - 20:00:35 GMT-3
At 04:32 AM 3/26/04, Tom Lijnse wrote:
>Hi Erwin,
>
>As far as I remember from debugging this feature, the dialer watch feature resets the idle-timeout whenever it would reach 0. So this will prevent the router that has dialer watch configured from disconnecting the call.
>
>The problem lies with the router at the other side of the connection though. This router uses regular DDR and therefore it will disconnect the call in the absence of interesting traffic. I see several solutions to this problem:
>
>1) On the "non dialer watch router" set the idle-timeout to the maximum value.
Or you can set it to 0 and it will never time out.
>2) On the "non dialer watch router" make OSPF interesting. Configure DDR on this end without a dial string. (Dialer map without phone number or dialer interface without dial string). Because the router has no phone number it can't dial out, but incoming calls will be kept up indefinitely since the idle-timer is reset by the OSPF hellos. Downside of this is that calls can only be set up in one direction.
>
>3) On the newer IOSes the "non dialer watch router" could be configured without a dialer-list and group. Incoming calls would stay connected indefinitely and outgoing calls will never be initiated. On older IOSes (I don't remember off the top of my head when this behavior changed) configuring this would prevent the DDR interface from passing packets entirely, so this solution wouldn't work. This method has the same downside as 2).
>
>Maybe others have different solutions to this problem, but these were the first ones that came to mind. On the lab, of course it's entirely dependent on the wording of the question.
>
>Regards,
>
>Tom Lijnse
>
>CCIE #11031
>Global Knowledge Netherlands
>
>-----Original Message-----
>From: CHIONG, ERWIN R (ASI) [mailto:ec2929@sbc.com]
>Sent: Friday, March 26, 2004 12:26 AM
>To: 'Edwards, Andrew M'; Tom Lijnse; Chris Fontes; Joseph D. Phillips;
>Group Study (E-mail)
>Subject: RE: OSPF Demand circuit and Backup
>
>
>How about...when the dialer watch triggers the call, I noticed that the
>dialer watched prefix will result in a "directly connected" state pointing
>to the ISDN interface in the routing table. I also noticed that when the
>idle timeout expires (due to un-interesting ospf packets, when configured),
>the ISDN interface will go down, which will remove the watched prefix from
>the routing table...which results in another dialer watch trigger.
>
>Is there anyway to stabilize the ISDN backup link to remain UP/UP without
>interesting traffic and without using an infinite idle-timeout, until the
>primary link recovers?
>
>Cheers,
>-Erwin
>
>-----Original Message-----
>From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
>Sent: Thursday, March 25, 2004 9:52 AM
>To: Tom Lijnse; Chris Fontes; Joseph D. Phillips; Group Study (E-mail)
>Subject: RE: OSPF Demand circuit and Backup
>
>Great explaination. I would only add one thing... Method 1 provides
>faster failover for user data than method 2.
>
>-----Original Message-----
>From: Tom Lijnse [mailto:Tom.Lijnse@globalknowledge.nl]
>Sent: Thursday, March 25, 2004 9:29 AM
>To: Chris Fontes; Joseph D. Phillips; Group Study (E-mail)
>Subject: RE: OSPF Demand circuit and Backup
>
>
>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
>
>_______________________________________________________________________
>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