ISDN Keep triggering

[maher]

Hi there,

Lately, I found that my ISDN router is keep on triggering and dailing to my HQ eventhough the primary link is up. When doing the traceroute and sh ip route <prefix> it is still preferring primary.

Herewith I found that something intersting under sh dialer:

BRI1/7:1 - dialer type = ISDN

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

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

Dialer state is multilink member

Dial reason: Multilink bundle overloaded

Interface bound to profile Di1

Current call connected 00:00:00

Connected to 12345678 (HQ)

Anyone know the reason of Multilink bundle overloaded?

thanks in advance.

maher

[Richard Burts]

Maher

Without knowing more about your environment it is hard to know the answer to your situation. It would be helpful if you would post the configuration of the dialer interface (I assume from the output that you have configured dialer profiles), of the BRI interface, and of the primary interface.

It would also be helpful to have the output of debug dialer.

I will make a guess without having seen the information that I asked for: do you have backup interface configured on the primary and do you specify backup load? If so it could bring up the ISDN based on the load level of the primary link.

HTH

Rick

[maher]

Hi Rbuts,

Thanks for the fast respond. Below is my configuration for the ISDN.

interface BRI1/0

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

ppp multilink

!

interface BRI1/1

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

ppp multilink

!

interface BRI1/2

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

ppp multilink

!

interface BRI1/3

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

ppp multilink

!

interface BRI1/4

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

ppp multilink

!

interface BRI1/5

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

ppp multilink

!

interface BRI1/6

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

ppp multilink

!

interface BRI1/7

no ip address

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

no cdp enable

ppp authentication chap

ppp multilink

!

interface Dialer1

description ISDN backup to HQ

ip address 10.0.0.1 255.255.255.252

encapsulation ppp

dialer pool 1

dialer remote-name HQ

dialer rotor best

dialer enable-timeout 160

dialer string 12345678

dialer load-threshold 1 either

dialer max-call 16

dialer-group 1

fair-queue 64 16 0

no cdp enable

ppp authentication chap

ppp chap hostname R1

ppp chap password xxxxxxx

ppp multilink

If you need any info, please let me know.

regards,

maher

[maher]

Oppsss...forget to post the debug dialer:

Jan 11 15:59:07: Di1 DDR: ip (s=10.0.0.1, d=255.255.255.255), 54 bytes, outgoing interesting (list 199)

Jan 11 15:59:07: Di1 DDR: ip (s=10.0.0.1, d=255.255.255.255), 54 bytes, outgoing interesting (list 199)

Jan 11 15:59:07: Di1 DDR: ip (s=10.0.0.1, d=255.255.255.255), 54 bytes, outgoing interesting (list 199)

Jan 11 15:59:10.421: %ISDN-6-LAYER2UP: Layer 2 for Interface BR1/6, TEI 66 changed to up

Jan 11 15:59:11.330: %LINK-3-UPDOWN: Interface BRI1/6:1, changed state to up

Jan 11 15:59:11.338: %DIALER-6-BIND: Interface BR1/6:1 bound to profile Di1

access-list 199:

access-list 199 deny udp any any eq snmp

access-list 199 deny udp any any eq ntp

access-list 199 deny ospf any any

access-list 199 permit ip any any

thanks again.

maher

[dbellaze]

Looks like a broadcast is triggering your dialer. Do you also have RIP or anything similar on this router?

Daniel

[maher]

Hi Daniel,

My primary link is running OSPF. According to the access-list 199, the packets does not hit the ospf statements.

regards,

maher

[Kevin Dorrell]

It looks like RIP v1 or something like that.

If you change the last line of your access list to access-list 199 permit any any log, then you will get some information about the packets that are triggering the ISDN. Unfortunately, it will stop the backup solution working at all, because of an issue with the log keyword on a dialer-list access-list. However, it will tell you about the packets, and you can remove the log immediately afterwards.

You could try slipping this line into the access list: access-list 199 deny ip any host 255.255.255.255. That will stop any broadcasts from triggering the ISDN. But it would be nice to know what it is you are blocking.

Kevin Dorrell

Luxemborg

[maher]

Hi Kevin,

Thanks for the suggestion.FYI, I did run command ip helper address at my LAN. Would it be the issues?

regards,

maher

[Kevin Dorrell]

It could be the ip helper-address, but the packets triggering the ISDN were send to the IP broadcast address, so did you do ip helper-address 255.255.255.255?

Kevin Dorrell

Luxembourg

[maher]

Hi Kevin,

Nope. I use ip helper-address 203.x.x.x address. Hmm..not sure sure this could be the reason.

regards,

maher

[Kevin Dorrell]

No, nor do I.

I think you'll have to put that "log" keyword at the end of the last line of your ACL, and look at the messages. Just for enough time to capture one of the packets. Then remove it again. The log message will tell you the source and destination addresses, and also the source and destination ports (because you specify ntp/snmp port numbers elsewhere in your ACL.)

Kevin Dorrell

Luxembourg

[maher]

Hi Kevin,

Since this is becoming more and more intersting things, I figure out to picture into diagram, easy for us to troubleshoot and diagnose..

regards,

maher

[maher]

Hi Kevin,

Since this is becoming more and more intersting things, I figure out to picture into diagram, easy for us to troubleshoot and diagnose..

regards,

maher

[Richard Burts]

It is an interesting diagram that you have posted. It has a lot of information that does not seem to relate to the problem being discussed in this forum. And it is not consistent with previous parts of this discussion. In particular your earlier post had address 10.0.0.1 as the address on the dialer interface of the router doing the dialing. The diagram has that address as the loopback of router CE-A1.

So I think we need some clarification.

It might be helpful if you posted the ourput of show ip protocol on the router which is doing the dialing. I suspect that what we will really need is the complete config of the router so that we can try to find what is causing the dialing to happen.

HTH

Rick

[maher]

Hi Rick and others,

I'm deeply sorry that my last posting makes everyone in the thread confused and feel anonying. The pdf files attach is the actual diagram.

Anyway, the problem is solve after changing and advertise the loopback address in router CE-D2 into area 1.

It seems to be like discontigous area. But what makes me confused a little bit is that, in router CE-B2 and CE-C2 loopback addresses are advertising in area 0 still reachable? Done few test my removing the loopback address under router ospf and still reachable...it seems to be that the advertising the loopback address is useless in this network topology.....

thanks in advance.

maher