From: Larry Metzger (larrymetzger@sbcglobal.net)
Date: Tue Aug 24 2004 - 12:20:02 GMT-3
I worked on this and found if you put a second dialer map statement in
the system will work.
Dialer map ip 150.4.3.0 name remote-router broadcast 5555555
The 150.4.3.0/32 route comes in as connected and allows everything to
work correctly.
Larry
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Carlos G Mendioroz
Sent: Tuesday, August 24, 2004 4:49 AM
To: marc van hoof
Cc: ccielab@groupstudy.com
Subject: Re: more dialer watch woes
Connected because it's in your BRI network ?
Why are you using that IP then, and not a remote loopback that will not
have this problem ?
marc van hoof wrote:
> Dialer watch doesn't like me very much..
>
> Here's the current situation
>
> R4 is watching a /32 route that it is receiving via ospf.
>
>
>
> Dialer watch-list 1 ip 150.4.3.3
>
> Int bri 0/0
>
> Dialer watch-group 1
>
> So as a result of this, I need to have that route in a dialer map
statement
>
> Int bri 0/0
>
> Dialer map ip 150.4.3.3 name remote-router broadcast 5555555
>
> So when the route is up, everything is going well, and when it fails
the
> dialer watch kicks in and connects the isdn circuit.
>
> But then I get a connected host route via the bri interface:
>
> Rack4R4#show ip route 150.4.3.3
>
> Routing entry for 150.4.3.3/32
>
> Known via "connected", distance 0, metric 0 (connected, via
interface)
> Routing Descriptor Blocks:
> * directly connected, via BRI0/0
> Route metric is 0, traffic share count is 1
>
> Rack4R4#
>
> So when the ospf route reappears, it never makes it into the route
table as
> there is a lower administrative distance route in there already.
> Consequently, the dialer watch service never realizes the primary is
back
> up.
>
> Any help appreciated !!
>
> -marc.
>
>
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:48 GMT-3