RE: Problem with dialer-watch

From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Thu Oct 28 2004 - 12:49:48 GMT-3


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