From: Rohan Grover (rohang@cisco.com)
Date: Thu Oct 28 2004 - 13:04:16 GMT-3
Hi Brian,
Thanks for the explanation. This really helped my understanding of dialer-watch!
Rohan
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Brian McGahan
Sent: Thursday, October 28, 2004 9:20 PM
To: Rohan Grover; ccielab@groupstudy.com
Subject: RE: Problem with dialer-watch
Rohan,
These are two separate issues you are seeing. The first relates to PPP and the peer neighbor route. PPP's peer neighbor
route is used in situations when the endpoints of the link are not on the same IP subnet. This occurs quite commonly in dial
environments when access servers are outsourced, because the provider will have a different block of address space than the access
server will. To alleviate this issue, PPP installs a host route for the other end of the link during IPCP negotiation. This peer
neighbor route functionality allows you to dynamically add and remove connected addresses from the routing table without having to
maintain static routing information.
In your case this is occurring because the route you are watching is /32. Therefore, PPP assumes that it should install a
host route for the destination as a peer neighbor route. The solution is either to watch a route that has a mask less than /32, or
to issue the no peer neighbor-route.
The second issue you are seeing is relates to the dialer idle timeout of the remote end of the link. Interesting traffic,
including methods to reset interesting traffic such as dialer watch, are only locally significant. This means that when R1
initiates the call, R2 will start counting down its idle timer. When R1's idle timer expires, the dialer watch process will reset
it. When R2's idle timer expires, it will send a disconnect message. In order to solve this issue either set the idle timer on R2
to 0, or if not supported in your IOS version, to the maximum value. Another solution would be to configure interesting traffic
that will be recurring on R2, but not allow it to initiate a call my removing the layer 2 address from the dialer map or the dialer
string.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Rohan Grover
> Sent: Thursday, October 28, 2004 8:52 AM
> To: ccielab@groupstudy.com
> Subject: Problem with dialer-watch
>
> Hi,
>
> I have following topology
>
> R1 -----serial----R2
> -----pri-------
>
> I have configured dialer-watch on R1
>
>
> ==========================================
> R1#sh run int s5/0:23
> Building configuration...
>
> Current configuration : 470 bytes
> !
> interface Serial5/0:23
> ip address 150.50.9.2 255.255.255.192
> encapsulation ppp
> ip ospf cost 70
> dialer idle-timeout 30
> dialer map ip 2.2.2.2 name R2 broadcast 222222
> dialer map ip 150.50.9.5 name R2 broadcast 222222
> dialer load-threshold 1 outbound
> dialer watch-group 1
> dialer-group 1
> isdn switch-type primary-ni
> isdn protocol-emulate network
> isdn incoming-voice data
> ppp authentication chap
> ppp multilink
> end
>
> <output ommitted>
>
> access-list 101 deny ospf any any
> access-list 101 permit ip any any
> dialer watch-list 1 ip 2.2.2.2 255.255.255.255
> dialer watch-list 1 delay connect 50
> dialer watch-list 1 delay disconnect 15
> dialer-list 1 protocol ip list 101
>
> ========================================
> 2.2.2.2/32 is known via ospf across the serial link
> When I shut the serial link the pri link comes up because of
dialer-watch.
>
> But I don't see 2.2.2.2/32 as an ospf route but rather as a connected
> route. I don't understand why?
>
> I know the solution is to use 'no peer neighbour-route' under the pri
int
> but the logic is not clear to me.
>
> Also whether or not 'peer neighbour-route' is used, after the idle
timeout
> (30 secs) the pri link is torn down and then immediately restarted.
>
> ==========
> 22:18:13: Vi1 DDR: idle timeout
> 22:18:13: DDR: Dialer Watch: watch-group = 1
> 22:18:13: DDR: network 2.2.2.2/255.255.255.255 UP,
> 22:18:13: DDR: primary DOWN
> 22:18:13: Vi1 DDR: disconnecting call
> 22:18:13: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
down
> 22:18:13: %ISDN-6-DISCONNECT: Interface Serial5/0:0 disconnected from
> 222222 R2, call lasted 30 seconds
> 22:18:13: %LINK-3-UPDOWN: Interface Serial5/0:0, changed state to down
> 22:18:13: DDR: Dialer Watch: watch-group = 1
> 22:18:13: DDR: network 2.2.2.2/255.255.255.255 UP,
> 22:18:13: DDR: primary DOWN
> 22:18:13: DDR: Dialer Watch: Dial Reason: Secondary of group 1
AVAILABLE
> 22:18:13: DDR: Dialer Watch: watch-group = 1,
> 22:18:13: DDR: dialing secondary by dialer map 2.2.2.2 on Se5/0:23
> 22:18:13: Se5/0:23 DDR: Attempting to dial 222222
> 22:18:13: %LINK-3-UPDOWN: Interface Serial5/0:0, changed state to up
> 22:18:13: Se5/0:0 DDR: Dialer Watch: resetting call in progress
> 22:18:13: %ISDN-6-CONNECT: Interface Serial5/0:0 is now connected to
> 222222 N/A
> 22:18:14: Se5/0:0 DDR: Remote name for Vofr_Callgen
> 22:18:14: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to
up
> 22:18:14: Vi2 DDR: Dialer statechange to up
> 22:18:14: Vi2 DDR: Dialer Watch: resetting call in progress
> 22:18:14: Vi2 DDR: Dialer call has been placed
> 22:18:14: Vi2 DDR: dialer protocol up
> 22:18:14: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1,
> changed state to down
> 22:18:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access2,
> changed state to up
> 22:18:19: %ISDN-6-CONNECT: Interface Serial5/0:0 is now connected to
> 222222 R2
> 22:18:19: %ISDN-6-CONNECT: Interface Serial5/0:0 is now connected to
> 222222 R2
> 22:18:44: Vi2 DDR: idle timeout
> 22:18:44: DDR: Dialer Watch: watch-group = 1
> 22:18:44: DDR: network 2.2.2.2/255.255.255.255 UP,
> 22:18:44: DDR: primary DOWN
> 22:18:44: Vi2 DDR: disconnecting call
> 22:18:44: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to
down
> 22:18:44: %ISDN-6-DISCONNECT: Interface Serial5/0:0 disconnected from
> 222222 R2, call lasted 30 seconds
> 22:18:44: %LINK-3-UPDOWN: Interface Serial5/0:0, changed state to down
> 22:18:44: DDR: Dialer Watch: watch-group = 1
> 22:18:44: DDR: network 2.2.2.2/255.255.255.255 UP,
> 22:18:44: DDR: primary DOWN
> 22:18:44: DDR: Dialer Watch: Dial Reason: Secondary of group 1
AVAILABLE
> 22:18:44: DDR: Dialer Watch: watch-group = 1,
> 22:18:44: DDR: dialing secondary by dialer map 2.2.2.2 on Se5/0:23
> 22:18:44: Se5/0:23 DDR: Attempting to dial 222222
> 22:18:44: %LINK-3-UPDOWN: Interface Serial5/0:0, changed state to up
> 22:18:44: Se5/0:0 DDR: Dialer Watch: resetting call in progress
> 22:18:44: %ISDN-6-CONNECT: Interface Serial5/0:0 is now connected to
> 222222 N/A
> 22:18:44: Se5/0:0 DDR: Remote name for R2
> 22:18:44: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
up
> 22:18:44: Vi1 DDR: Dialer statechange to up
> 22:18:44: Vi1 DDR: Dialer Watch: resetting call in progress
> 22:18:44: Vi1 DDR: Dialer call has been placed
> 22:18:44: Vi1 DDR: dialer protocol up
> 22:18:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access2,
> changed state to down
> 22:18:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1,
> changed state to up
> 22:18:50: %ISDN-6-CONNECT: Interface Serial5/0:0 is now connected to
> 222222 R2
> 22:18:50: %ISDN-6-CONNECT: Interface Serial5/0:0 is now connected to
> 222222 R2 ================
>
> Can someone explain to be whats happening here? I tht that
dialer-watch
> periodically checked the watched route after every idle-timeout and if
> primary is still down then rest the idle-timeout.
>
> So why is it tearing down the link?
>
> Thanks!
> Rohan
>
>
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:54 GMT-3