From: Frank Liang (liangfrank@xxxxxxxxxxx)
Date: Mon Feb 05 2001 - 03:15:04 GMT-3
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