Re: Possible Dialer Watch bug? - Page 2

m.belloni · ‎02-25-2005

Two cisco 2620XM, 128Mb Ram and 32Mb Flash and IOS c2600-is-mz.122-15.T13.bin, are active on the same Lan, with the hsrp function enable. One it's connected to the primary link and the second one starts isdn calls when the primary link goes down.

We configured the Dialer-Watch option and the backup run fine, but, after that the Primary Link comes up again, the backup router is going on to perform isdn calls and to stop it we have to shut and unshut the Dialer1. May you please check if there is one config error or if this is a cisco bug? I already checked the Tac case collection and the software bug tool and this Forum too but I didn't find any useful informations

I'm attaching the cisco configs and the sh ip route of the watched route when the primary link is in normal conditions

m.belloni · ‎03-24-2005

I was near to hope that my last modification which should have stopped the multicast traffic could have fixed, but unfortunately, after about two weeks of good performances, problem occured again. I performed some show with the problem active and others after its solution.I'm sure the destination address is difference from the one of the last outage

SHOW DURING THE PROBLEM

***********************

HSE-NECK#sh isdn active

--------------------------------------------------------------------------------

ISDN ACTIVE CALLS

--------------------------------------------------------------------------------

Call Calling Called Remote Seconds Seconds Seconds Charges

Type Number Number Name Used Left Idle Units/Currency

--------------------------------------------------------------------------------

Out ---N/A--- +0239640031 HSEMIMIB01 40 Unavail - 0

Out ---N/A--- +0239640031 HSEMIMIB01 5 Unavail - 0

--------------------------------------------------------------------------------

HSE-NECK#sh dialer

Dial reason: ip (s=193.28.103.38, d=10.212.20.60)

Interface bound to profile Di1

Current call connected 00:00:51

Connected to 00390239640031 (HSEMIMIB01)

HSE-NECK#sh clock

12:23:44.709 GMT Thu Mar 24 2005

HSE-NECK#sh ip route 10.212.20.60

Routing entry for 10.212.20.0/23

Known via "static", distance 220, metric 0 (connected)

Redistributing via bgp 65184

Advertised by bgp 65184 metric 300

Routing Descriptor Blocks:

* directly connected, via Dialer1

Route metric is 0, traffic share count is 1

HSE-NECK#quit

[Connection to 10.10.10.2 closed by foreign host]

HSE-Neckarsulm-Primary>sh ip route 10.212.20.60

Routing entry for 10.212.20.0/23

Known via "bgp 65184", distance 200, metric 300, type internal

Last update from 10.120.2.10 02:12:16 ago

Routing Descriptor Blocks:

* 10.120.2.10, from 10.120.2.10, 02:12:16 ago

Route metric is 300, traffic share count is 1

SHOW AFTER THE PROBLEM

**********************

HSE-NECK(config)#int dialer 1

HSE-NECK(config-if)#shut

HSE-NECK(config-if)#no shut

HSE-NECK(config-if)#^Z

HSE-NECK#sh isdn active

--------------------------------------------------------------------------------

ISDN ACTIVE CALLS

--------------------------------------------------------------------------------

Call Calling Called Remote Seconds Seconds Seconds Charges

Type Number Number Name Used Left Idle Units/Currency

--------------------------------------------------------------------------------

HSE-NECK#sh ip route 10.212.20.60

Routing entry for 10.212.20.0/23

Known via "bgp 65184", distance 200, metric 0

Tag 2006, type internal

Last update from 10.120.2.9 00:01:26 ago

Routing Descriptor Blocks:

* 10.120.2.9, from 10.120.2.9, 00:01:26 ago

Route metric is 0, traffic share count is 1

AS Hops 2

HSE-NECK#quit

[Connection to 10.10.10.2 closed by foreign host]

HSE-Neckarsulm-Primary>sh ip route 10.212.20.60

Routing entry for 10.212.20.0/23

Known via "bgp 65184", distance 20, metric 0

Tag 2006, type external

Last update from 146.198.71.53 00:01:38 ago

Routing Descriptor Blocks:

* 146.198.71.53, from 146.198.71.53, 00:01:38 ago

Route metric is 0, traffic share count is 1

AS Hops 2

dgahm · ‎03-24-2005

You have BGP routes flapping, resulting in your statics sending traffic to the dialer. So you need to find out why the routes are dropping from your BGP, or you need to re-configure so only dialer watch routes will bring up the ISDN link.

As another poster suggested, dropping the 'access-list 101 permit ip any any' will stop this from happening. At that point only dialer watch will activate the dialer.

m.belloni · ‎04-12-2005

So, by considering the acl

access-list 101 deny eigrp any any

access-list 101 deny ospf any any

access-list 101 deny tcp any any eq bgp

access-list 101 deny udp any host 255.255.255.255

access-list 101 deny udp any any eq ntp

access-list 101 deny udp any any eq snmp

access-list 101 deny udp any any eq snmptrap

access-list 101 deny ip any 224.0.0.0 15.255.255.255

access-list 101 permit ip any any

you are suggesting me to cancel the last statement and keep all the previous ones, or to cancel all the acl?

h.chia · ‎04-12-2005

Cancel away the last statement - however take note that you cannot do a "no access-list 101 permit ip any any", because that will remove the whole ACL 101.

Using a dialer-list will in fact reset the idle timer every time an interesting packet passes through. Hence it may not be a good idea to use dialer-list together with dialer-watch. I seriously question the purpose and actual usage of such a combination.

Therefore, I suggest removing the "dial-group" statement from your dialer interface - as that will definitely ensure any activation of the backup link is due to dialer watch.

m.belloni · ‎04-12-2005

OK, I removed the dialer-group statement as you suggested.Now only dialer-watch rules the backup

m.belloni · ‎06-15-2005

On last days we migrated the customer under a different platform by using one different routing protocol (eigrp instead of ospf) but as in the past isdn was activating calls also when the primary link was up,so, without a good reason. The config file attached is "Dialer watch new conf". If I delete acl 101 associated to dialer watch, the backup never run. Do you believe I can modify it by changing the last statement as "access-list 101 deny ip any any" just to try if this can stop this useless calls?

Or do you believe I can semplify the acl by only using the following statement: access-list 1 deny ip any?

Thanks

m.belloni · ‎04-12-2005

One question: I verified that often the wrong and unnecessary isdn calls directs to destination addresses placed on the remote network 10.212.20.0/23.In which manner could I enable a debug ip routing only related to this remote network?

mlanglois · ‎04-12-2005

Below is the relevant config parts of my router (mind you it's using a PRI so all you need to do is substitute SPIDS in for the switch type stuff on the BRI and obviously BRI interface instead of Serial)

I had the same issue you were/are having. ISDN continued to dial in until I shut down the int. I no longer have that issue... since I put in the delay command. I originally tested this config with a BRI.

I am running IOS 12.3.13.

Today my primary failed (planned failover) and ISDN came up and went down when the primary came back....

interface Serial1/0:23

description d-channel

no ip address

encapsulation ppp

dialer rotary-group 1

dialer-group 1

isdn switch-type primary-4ess

isdn nsf-service sdn

no isdn gtd

ppp authentication pap

ppp multilink

!

interface Dialer1

ip address x.x.x.x 255.255.255.192

encapsulation ppp

dialer in-band

dialer idle-timeout 300

dialer map ip y.y.y.y name isdnrtr class sdnplan broadcast 5557777

! above y.y.y.y is the ip of my isdn rtr I am dialing into

dialer map ip z.z.z.z name isdnrtr class sdnplan broadcast 5557777

! above z.z.z.z is interesting dialer-watch traffic

dialer watch-group 1

dialer-group 1

ppp authentication pap

ppp pap sent-username uname password 7 blahblahblah

ppp multilink

ppp multilink interleave

router eigrp 1

network x.x.0.0

network z.z.z.z

no auto-summary

dialer watch-list 1 ip z.z.z.z 255.255.255.0

dialer watch-list 1 delay route-check initial 200

dialer watch-list 1 delay connect 30

dialer watch-list 1 delay disconnect 20

dialer-list 1 protocol ip deny

m.belloni · ‎04-13-2005

Thanks for your update. I've unfortunately already setted the delay statement but my problem occured again. On yesterday I cancelled the dialer-group statement from Dialer1 as I want that only dialer-watch will be ruling the backup

mlanglois · ‎06-15-2005

Interesting... like I said earlier. I had a similar problem and fixed it by changing code rev and adding the delay command. The code rev you have doesn't support the delay command as far as I have noticed.

After the failover and ISDN dials, have you done a sho ip route and noticed if your Dialer routes actually ever leave? Use the include command to check... Some of my Dialer routes were never leaving until I used delay. I had TAC's opened and as I said before I had a CCIE send me a config. The only way I got it to work was I took everything out and added bits and pieces that seemed to make sense to me.

I originally was using the same rev of code you are.