bri problem

[seegomaa]

dears

i have 1751 router connected via Frame-Relay primary and isdn backup. i found that isdn make calls although frame-relay is up .

here is sample of debug dialer ouput

4d02h: BR1/0 DDR: place call

4d02h: BR1/0 DDR: Dialing cause ip (s=20.0.0.44, d=255.255.255.255)

4d02h: BR1/0 DDR: Attempting to dial 022706043

4d02h: BR1/0 DDR: place call

4d02h: BR1/0 DDR: Dialing cause ip (s=20.0.0.44, d=255.255.255.255)

4d02h: BR1/0 DDR: Attempting to dial 023364809

and this is the config.

HDB44#sh ru

Building configuration...

version 12.2

service config

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname HDB44

!

enable secret xxxxxx

enable password xxxxxx

!

username HDB44 password 0 xxxx

username HDB81 password 0 xxxx

username HDB30 password 0 xxxx

username HDB09 password 0 xxxx

memory-size iomem 15

ip subnet-zero

!

!

no ip domain-lookup

!

isdn switch-type basic-net3

!

fax interface-type fax-mail

mta receive maximum-recipients 0

!

interface FastEthernet0/0

ip address 172.16.44.1 255.255.255.0

speed auto

full-duplex

no cdp enable

!

interface Serial0/0

no ip address

encapsulation frame-relay

frame-relay lmi-type ansi

!

interface Serial0/0.1 point-to-point

description connection to (( Roxy ))

bandwidth 128

ip address 10.0.5.22 255.255.255.252

frame-relay interface-dlci 16

!

interface Serial0/0.2 point-to-point

description connection to (( Elbatal-Ahmed ))

bandwidth 128

ip address 10.0.6.10 255.255.255.252

no cdp enable

frame-relay interface-dlci 17

!

interface BRI1/0

ip address 20.0.0.44 255.255.255.0

encapsulation ppp

dialer idle-timeout 180

dialer fast-idle 360

dialer map ip 20.0.0.9 name HDB09 022706043 broadcast

dialer map ip 20.0.0.81 name HDB81 023364809 broadcast

dialer map ip 20.0.0.30 name HDB30 034848754 broadcast

dialer-group 1

isdn switch-type basic-net3

ppp authentication chap

!

router eigrp 1

network 10.0.0.0

network 20.0.0.0

network 172.16.0.0

no auto-summary

no eigrp log-neighbor-changes

!

ip classless

ip route 172.16.9.0 255.255.255.0 20.0.0.9 100

ip route 172.16.30.0 255.255.255.0 20.0.0.30 102

ip route 172.16.81.0 255.255.255.0 20.0.0.81 101

no ip http server

no ip pim bidir-enable

!

!

logging trap debugging

logging 172.16.82.64

access-list 101 deny eigrp any any

access-list 101 deny ip host 172.16.82.64 any

access-list 101 permit ip any any

dialer-list 1 protocol ip list 101

!

snmp-server community public RO

snmp-server community private RW

snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart

snmp-server enable traps isdn call-information

snmp-server enable traps config

snmp-server enable traps entity

snmp-server enable traps frame-relay

snmp-server enable traps syslog

snmp-server enable traps rtr

snmp-server host 172.16.82.133 public

call rsvp-sync

!

!

mgcp profile default

!

dial-peer cor custom

Reply To This Message Newer Topic | Older Topic

Topics Author Date

bri-interface-issue new mohamad goma 06-13-05 10:36

New Topic|Go to Top|Search|Flat View

Reply To This Message

Your Name: mohamad goma

Your Email:

Subject:

[thisisshanky]

Your three static routes are pointing via BRI. Are you getting a default route via Frame-relay - EIGRP ?

[Richard Burts]

From the output of debug dialer it is apparent that what is causing the dialing activity is some packet originated from the router itself since the source address is the address of the bri. The destination address is the broadcast address. I do not see anything in the part of the config that was posted that would explain the broadcast traffic. I am not sure that the posted information was the complete config and there is a possibility that something is configured that we do not see that would generate broadcast traffic. Or there is a possibility that someone did something on the router that would generate broadcast traffic (copy to or from tftp etc).

Also the posted output shows dialing to the first entry in the dialer map and then to the second entry. Can you tell us whether it also dials the third entry or does it stop after the second?

With the specification of service timestamps log uptime the timestamp only indicates day and hour. If you would configure service timestamps log datetime we might get a better sense of whether the two attempts to dial were right together or were separated in time.

Can you tell us whether this dialing activity is constant (which would indicate more likely some configured service) or happens occasionally (which would indicate more likely some activity on the router)?

HTH

Rick

[riz_432]

i agree with rburts.disable cdp and keepalives on the bri interface and try and also can u provide the output of show ip route command.

[seegomaa]

dear

this is the complete configuration

and the router dials the 1st destination then the second then it tries the third but no third channel then it begins the fast idle then it calls the third and so on

note that this happens random

[Richard Burts]

If it happens randomly then I wonder if it could be a reaction to some command that someone entered on the router. Is anyone telnetted to the router or active on the console when the dialing activity happens?

Does the dialing activity happen during the night or is it just during the daytime hours?

HTH

Rick

[seegomaa]

it happens random. i shut down the bri interface, when i do no shut, after minutes it begin to dial and not one call or two per day but call after call

all the time. And this is not due to command issued on the router.

[Kevin Dorrell]

You are using lagacy DDR, so I am not sure whether this will help ... but ... if this were a dialer profile configuration I would do show dialer int Dialern. That would tell me directly the source and destination address of the packet that triggered the dialing. But I don't know whether that works with legacy DDR. Maybe something with show dialer map?

Otherwise, you could do a debug dialer events - that should also show you the source and destination IP address of the triggering packet.

Kevin Dorrell

Luxembourg

[dbellaze]

There doesn't seem to be anything in the configuratoin that would cause this dial issue.

Since the dial cause is to the all ones broadcast address you could add a rule into your access list 101 that denies dialing to that address. This will only prevent the router from dialing due to broadcast messages. If another mechanism triggers the call, like your floating static routes a broadcast would be allowed to flow across the link. The dialer list only applies to how a router can place a call, or restart the dialer idle timer.

access-list 101 deny ip any 0.0.0.0 255.255.255.255

Daniel

[Richard Burts]

I would prefer to understand what is happening and causing this dial activity. But if you just want to make it work, then Daniel's suggestion of having the dialer list deny broadcast traffic should work. He is correct in making the point that a deny in the dialer list does not deny the traffic from being transmitted if the dialer is already up, but it will prevent the traffic from causing a dial. Be sure that the line he suggests goes into the access list before the line with permit ip any any.

HTH

Rick

[aravindhs]

Rick, I think it would be better off to remove "network 20.0.0.0" from the eigrp config.

I see eigrp is denied for any interesting traffic. But why do we need it in the first place ? Any suggestions ?

Thanks,

Arav

[Richard Burts]

Arav

I think there are several parts to the answer to your question.

First EIGRP is not the cause of this problem. EIGRP sends to a multicast address but the traffic that brings up the BRI is to a broadcast address. Also EIGRP is not able to bring up the BRI since it is not interesting traffic (because it is denied in the dialer list).

Second EIGRP may include the BRI for a couple of reasons. If there is a network statement for 20.0.0.0 then that network gets advertised to all the EIGRP neighbors which makes the network reachable from all the other neighbors. Also it may depend on what is beyond the routers dialed by the BRI. When you use a dialing interface there must be a way to get the remote addresses into the routing table. Sometimes it is done by using static/floating static routes. Sometimes it is done by running a dynamic routing protocol. Especially if there are more than a couple of subnets behind the other routers reached via BRI it may be advantageous to run a dynamic routing protocol. This way when the BRI is up we know all of the remote networks and subnets that are reachable that way. (The disadvantage is that those networks and subnets are removed from the routing table when the dialer hangs up.)

The people who designed and operate this network can best decide whether the advantages of running EIGRP over the BRI are greater than any disadvantages to doing it.

As a side note to this discussion: for running a dynamic routing protocol over a dialer interface there are some advantages in OSPF compared to EIGRP. Particularly OSPF allows configuration of demand circuit which allows OSPF to maintain adjacencies over the dialer without requiring continuing hello messages. While with EIGRP it does require hello messages and if the hello is not interesting traffic then the adjacency will terminate when the dialer hangs up.

HTH

Rick

[Richard Burts]

In looking at the config again I see something that may explain what is happening here and why the dialer keeps dialing to a broadcast address.

I notice that the config includes the command service config. With that command the router will attempt to contact a tftp server over all of its interfaces. And since it does not know what address to use for the tftp server it uses a broadcast address.

I believe the activity on the dialer is an attempt to reach a tftp server via the dialer interface. I suggest that you remove service config (unless there is a real reason to have it in the config).

Try removing service config and let us know if that fixes the problem.

HTH

Rick

[seegomaa]

many thanks Rick when i deleted this command the router never dial again

[Richard Burts]

Thanks for letting us know that the problem has been solved. I am glad that my suggestion was able to help you achieve this.

HTH

Rick