From: Brian Hescock (bhescock@xxxxxxxxx)
Date: Mon Feb 05 2001 - 00:42:46 GMT-3
It was the same routing protocol (EIGRP), perhaps it reacts differently
with a different routing protocol on the isdn link as you mentioned. I do
know that in some of the watch-group examples they say to use a floating
static route, which might change the behavior. I avoided using a floating
static route since we most likely won't have that option in the lab.
Someone had asked if the eigrp hello's would reset the idle-timer. I'm
not an isdn guru by any means (if you can't tell... ;-) but I believe
anything you've denied in your dialer-list can't keep the line up either
(such as "access-list 100 deny eigrp any any).
B.
B.
On Mon, 5 Feb 2001, Devender Singh wrote:
> Hi all,
>
> Brian if that is what is happening. It is definetly a bug. we should not
> need any other support for dialer watch to work. If the route goes missing
> via original protocol, it should dial out and should remain up as long route
> is is missing via original protocol. I have tested it and is working in my
> production network. we donot need to define dialer-list for this case.
>
> Devender Singh
> BE(Hons), CCNP
> IP Solution Specialist
>
>
> -----Original Message-----
> From: Frank Liang [mailto:liangfrank@hotmail.com]
> Sent: Monday, 5 February 2001 2:15
> To: dunn@cisco.com; bhescock@cisco.com
> Cc: ccielab@groupstudy.com
> Subject: Re: watch-group observation
>
>
> Wouldn't eigrp hellos reset the idle timer?
>
> FL
>
>
> >From: Bernard Dunn <dunn@cisco.com>
> >Reply-To: Bernard Dunn <dunn@cisco.com>
> >To: Brian Hescock <bhescock@cisco.com>
> >CC: ccielab@groupstudy.com
> >Subject: Re: watch-group observation
> >Date: Mon, 5 Feb 2001 13:15:58 +1100 (EST)
> >
> >Brian,
> >
> >Shouldn't be a bug, because you have your interesting traffic to flow in a
> >real environment, to reset your idle-timeout.
> >
> >A touchy senario would be when you try adding snapshot to dialer
> >watch. Try it after your exam.. :-)
> >
> >
> >On Sun, 4 Feb 2001, Brian Hescock wrote:
> >
> > > This looks like normal behavior but, in my opinion, is broken:
> > >
> > > - dialer watch-group configured for network 30.1.1.0, which is learned
> >via
> > > ethernet 0
> > > - shut down ethernet 0 interface, lose route for 30.1.1.0 and isdn comes
> > > up due to no route for 30.1.1.0
> > > - eigrp forms neighbors over isdn and we get route for 30.1.1.0
> > > - isdn drops after 120 seconds, the default idle-timeout
> > > - isdn redials immediately since it has no route for 30.1.1.0
> > >
> > > Personally, I think IOS should be smart enough to know it only knows the
> > > route through isdn so it should keep the line up if it doesn't know of a
> > > route for 30.1.1.0 via some other interface. It's a waste of money to
> > > increase the idle-timeout so this doesn't happen as often because then
> > > isdn will always stay up longer.
> > >
> > > Anyone know of a way around this problem other than increasing the
> > > idle-timeout? Looks like I may need to file a sys-wish bug to get IOS
> > > changed so it doesn't drop the isdn link if the route is only known via
> > > isdn. Perhaps it's just me but I think is silly that we drop the link,
> > > only to bring it up again.
> > >
> > > Brian
> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:36 GMT-3