cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1797
Views
0
Helpful
24
Replies

Possible Dialer Watch bug?

m.belloni
Level 1
Level 1

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

24 Replies 24

dgahm
Level 8
Level 8

You have an interesting configuration in that you are using floating static routes as well as dialer watch. Even without dialer watch the floating statics would send traffic to the dialer interface and bring up the link if the primary routes go away. Typically dialer watch is used with a dynamic routing protocol, and routes are learned after the backup link is active.

I suspect there is traffic active on the dialer interface which is preventing the idle timeout from dropping the call. Have you looked for routes in the route table with a better AD/metric pointing at the Dialer interface? You can also use ip accounting or netflow to determine what traffic is keeping the link active.

Ok thanks. By hoping that the problem shouldn't occur again, in case it should happen, I'll follow your advice

Problem occured again but we couldn't get rilevant informations through "ip accounting".

But exactly what you suggested to change in the configuration?Floating static routes with metric of 300 or more instead of 220 could help?

You are describing a problem I have been having almost exactly... I have a 2621 with a BRI line. Using code 12.2.26 I tried multiple times to get Dialer Watch as advertised per cisco's website. I had a local CCIE send me an even different config. In some instances the ISDN would just dial immediately without the primary link going down.

I finally got it so the ISDN would dial but once the primary link came up the ISDN would shut down... but then dial back shortly thereafter.

So I had to change to code rev 12.2.15T14 so that I could add the following command

dialer watch-list 1 delay connect 30

That fixed it...

I'll check.Thanks

Just to be clear, let me restate my understanding of your issue.

Your dial backup initiates properly when the watched routes are no longer learned via BGP, but fails to drop the call when the routes come back. Is this correct?

Your config seems a bit unusual in your use of statics as opposed to using an IGP like OSPF or EIGRP, but it really should work.

The obvious thing that would keep the link from dropping is traffic flowing through it. With your network normal the traffic should be using the normal routes. Applying the 'ip accounting output-packets' under the interface and then doing a 'show ip accounting' when the link is up, but should be down, would hopefully reveal the source of the traffic. You might try 'debug dialer packets'to see if that shows you the source and destination. If the overall traffic is very low at the time you could do a 'debug ip packet', but that is a very dangerous debug and could bring the router down. A 'show interface' should at least confirm the presence of packets in and out, though won't tell you what you need to know to stop it.

If you can initiate a test you could also do a 'debug dialer events' which would tell you if the dialer watch is properly detecting the route changes.

Well, exactly the problem is the following:the dial backup drops the calls when the routes come back, but, after some minutes, one hour, one day, it could start isdn calls even if the primary links have been working fine for hours or days.

On this week this occured a couple of times and the primary links weren't bouncing!And to stop the isdn calls I had to shut and unshut the dialer.

The route that the dialer watch is watching is the one to a remote loopback ip address. I chose this route because the loopback interfaces are more stables than all the other one, but something is not working properly

OK, that is different that what I understood.

When the backup router dials out do a:

'show dialer'

This should show the reason for dialing.

Often multicast traffic is the culprit with this symptom.

In all my routers I include this line in the dialer access list:

access-list 101 deny ip any 224.0.0.0 15.255.255.255

This will prevent ip in the multicast range of 224.0.0.0 to 239.255.255.255 from activating the dialer.

You might give this a try.

For what it's worth.

Virus/worm activity can also cause this. If you have something out there doing ping sweeps, the pings across the isdn dialer interfaces can cause the links to come up.

Placing an acl on the affected router(s) to ignore ICMP from unknown/untrusted sources is one way to avoid this. But design carefully so you don't unintentionally break traceroute.

Ok, thanks for the last two notes. Currently I'm following a previous updated by adding the command "dialer-watch list 1 connect delay 30". I'm going to check with colleagues and customers if they want to immediately add the last acl suggested or if we want to check before if the "connect delay" command I added is fixing the problem

h.chia
Level 1
Level 1

I have faced a similar problem using OSPF as the dynamic routing protocol. Different from your scenario is, I am not using floating statics.

In my case, when the primary link returns to service, I see 2 routes to each destinations - 1 through the primary and the other through the backup.

My guess is, when the dialer-watch disable timer runs out, the ISDN connection will be dropped, causing the backup routes to be flushed from the routing table. And dialer-watch somehow see this as a "watched route loss" and starts dialing again.

My solution is to specify a higher ospf cost at the Dialer interface. This will immediately flushed out the backup routes whenever the primary link is back.

For your case, do you see 2 routes to the same destinations when the primary link is up ? I suspect that may be the case, because you have floating statics pointing directly to a Dialer interface.

h.chia
Level 1
Level 1

Another thing that you may want to consider doing is to remove the following statement :-

access-list 101 permit ip any any

Having this statement effectively make all IP traffic interesting (other than those denied before) therefore the dialer idle timer will be reset whenever there is traffic flowing through.

Since your objective is to make use of dialer watch to bring up the link, I don't think it is necessary to define a dialer list. You may consider removing the dialer-group statement from the Dialer interface too.

Problem occured again on yesterday when suddenly isdn call started without any outage or ounce occured at the main links. I fixed by shutting and unshutting the dialer interface and then I added one command in the acl by denying multicast traffic

Before you reset the interface next time try a 'show dialer' The dial reason will tell you what initiated the call.

Here is an example:

BRI0/0:1 - dialer type = ISDN

Idle timer (240 secs), Fast idle timer (20 secs)

Wait for carrier (30 secs), Re-enable (15 secs)

Dialer state is multilink member

Dial reason: Dialing on watched route loss

Connected to XXXXXXX (routerXXX)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco