ISDN legacy DDR problem

ping 172.16.3.3 from router bottom_right doesn't work.

A call gets set up from isdnr but no replies are sent. I've resolved the issue by making modifications on the configuration on isdnl.

These being:
1. removing the dialer string command
2. changing the dialer string command to dialer string 4444444 (second line of isdnr), but that causes it to unneccessarily open the second channel.

To me it seems, that when the ping doesn't work, isdnl is trying to dial the first line of isdnr (which is already on a call).

This scenerio is on live working equipment (lab environment only)

I doubt something like this will be covered on the exam, but it's something I would like to figure out.

Assuming it is a dialing issue, why would isdnl try to dial out when there is already an open channel from isdnr?

Note: I've changed the dial string to generic values, there may be typos.

ISDNR
isdnr#sh ru
%SYS-5-CONFIG_I: Configured from console by console
Building configuration...

Current configuration:
!
version 11.3
service password-encryption
!
hostname isdnr
!
enable secret 5 $1$js4v$gXGoMxFmJ7yUrr.SSXavr1
!
username isdnl password 7 074F0ABA04
isdn switch-type basic-ni
!
!
interface Ethernet0
ip address 172.16.1.3 255.255.255.0
!
interface BRI0
ip address 172.16.2.2 255.255.255.0
encapsulation ppp
dialer string 1111111
dialer-group 1
isdn switch-type basic-ni
isdn spid1 204333333300 3333333
isdn spid2 204444444400 4444444
ppp authentication chap
hold-queue 75 in
!
ip classless
ip route 172.16.3.0 255.255.255.0 172.16.2.1
access-list 1 permit 172.16.1.0 0.0.0.255
dialer-list 1 protocol ip list 1
!
line con 0
line vty 0 4
login
!
end

isdnr#

ISDNL
isdnl# sh run
Building configuration...

Current configuration:
!
version 11.2
service password-encryption
no service udp-small-servers
no service tcp-small-servers
!
hostname isdnl
!
enable secret 5 $1$La48$KoAq3vL1XUO4P6b.UOKq0.
!
username isdnr password 7 074F0ABA04
isdn switch-type basic-ni1
!
interface Ethernet0
ip address 172.16.3.3 255.255.255.0
!
interface BRI0
ip address 172.16.2.1 255.255.255.0
encapsulation ppp
dialer string 3333333
dialer-group 1
isdn spid1 204111111100 1111111
isdn spid2 204222222200 2222222
ppp authentication chap
hold-queue 75 in
!
ip classless
ip route 172.16.1.0 255.255.255.0 172.16.2.2
access-list 1 permit 172.16.3.0 0.0.0.255
dialer-list 1 protocol ip list 1
!
line con 0
line vty 0 4
login
!
end

isdnl#

Didn't know how to attach topology directly to post. Map is at url listed below. Thanks mikej412.

http://www.mts.net/~clarabs/isdn_trouble.bmp

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

EdTheLad

Dialer string isnt legacy, try replacing dialer-string with dialer-map and see what happens.If you still have problems i will sim it up when i get a chance.
Also have you considered using dialer profiles?

hedhrts

ed_the_lad wrote:

Dialer string isnt legacy, try replacing dialer-string with dialer-map and see what happens.If you still have problems i will sim it up when i get a chance.
Also have you considered using dialer profiles?

I understand dialer string isn't legacy. I guess I was refering to the legacy "concept" where the dial string is programmed in the interface rather than in a dialer profile (virtual interface) eg. "interface dialer 1" which by the way is the next topic in the book I'm following.

I will try the dialer-map solution you suggested. Thanks.

Yankee

I'm not sure exactly what the problem is from your description, but I can say you should have only one router doing the calling. When you place a dialer string on both routers, each will try to initiate a call when they are triggered. Decide which router you want to be the caller (for me it usually was the remote site dialing the core) and remove the dialer string from the other.

Yankee

hedhrts

Yankee wrote:

I'm not sure exactly what the problem is from your description, but I can say you should have only one router doing the calling. When you place a dialer string on both routers, each will try to initiate a call when they are triggered. Decide which router you want to be the caller (for me it usually was the remote site dialing the core) and remove the dialer string from the other.

Yankee

I agree with your scenario. If all you're going to have is one way calling then, yes, I should have a dial sting on one end and this specific topology will work.

Yankee

then I guess I don't understand your problem

Yankee

Yankee

edit

hedhrts

Yankee wrote:

You assist, tell them what is wrong, get told they knew that and then you wonder why they asked if they knew...
Ain't the IT industry great.

If I may say from experience as a hiring manager, don't BS in an interview. If you don't know, say you don't know, but will look up the answer when you get home.

Yankee

Haven't had a chance to reply. Trying to get to the point of writing the exam either late this week or early next week. Keep in mind this is just a lab scenario using this specific method of initiating calls. I was just trying to understand why the called router trys to open up a second bri channel if one is available for the icmp reply.

I doubt this paticular configuration would be used in a working environment, but I've seen instances where either end will initiate the call (only using dialer profiles instead, which works fine as I suspected).

I thought someone else might have come across the same issue and be able to explain why it works the way it does.