ISDN Up But No Ping Response

Can anyone help with some ISDN advice.

I have a router with a remote ISDN connection. The router is able to successfully dial and authenticate to the remote ISDN device. When a ping is sent from an inside server to the remote end it fails.

Originally the ISDN solution was on an old 2600 with a PRI and this worked fine. I lifted the config off the 2600 and modified it slightly to drop onto a new 1841 router with a BRI and pings won't work. Put it back on the PRI router and it does.

A traceroute from an inside machine 10.20.0.10 (see NAT statement below) hits 10.20.100.2 and then stops. The ISDN authenticates fine but no ping responses even though I am seeing hits on my 'interesting traffic' ACL. I assume the router is just dropping the packets even though the ISDN authenticates. After the idle timeout period the ISDN closes.

Config as follows:

interface FastEthernet0/1 description Connection to LAN Switch ip address 10.20.100.2 255.255.0.0 ip address 212.X.X.113 255.255.255.252 secondary no ip redirects ip nat inside ip virtual-reassembly speed 100 full-duplex ! interface BRI0/1/0 description Test ISDN Link no ip address encapsulation ppp dialer pool-member 1 isdn switch-type basic-net3 no fair-queue no cdp enable ppp authentication chap ppp multilink ! interface Dialer10 description Test ISDN Dialer ip address 195.X.X.37 255.255.255.0 ip nat outside ip virtual-reassembly encapsulation ppp dialer pool 1 dialer remote-name blah dialer idle-timeout 30 dialer string 0012345678 dialer-group 2 no cdp enable ppp authentication chap ppp multilink

ip nat inside source static 10.20.0.10 212.X.X.114

ip route 147.X.X.X 255.255.255.0 195.X.X.X name ISDN Test

dialer-list 2 protocol ip list 102

access-list 102 permit icmp host 212.X.X.113 host 147.X.X.X access-list 102 permit tcp host 212.X.X.X host 147.X.X.X log access-list 102 permit icmp host 212.X.X.114 host 147.X.X.X log access-list 102 permit tcp host 212.X.X.114 host 147.X.X.X log

Regards

Darren

Reply to
Darren Green
Loading thread data ...
  1. Does an extended ping using source IP address of 195.X.X.37 (i.e. the real source Ip address) suceed ?

  1. Are you missing some NAT statements here ?

Reply to
Merv

Hi Merv,

The pings have to come from 212.X.X.113 or 212.X.X.114. There is a secondary address on the routers F0/1 which I can source the ping from, it was put there as a test. The other host is the .114 address which has the NAT statement

ip nat inside source static 10.20.0.10 212.X.X.114. Ethernet is inside and Dialer is outside.

So strange it works on the old router with the PRI and not the BRI router. As I mentioned everything authenticates but a ping sourced from the inside host of 10.20.0.10 stops at the router Lan port and goes no further even though the ISDN is up.

I thought that it could be an IOS issue or something to do with the new ISDN cards the 1841's run. I'll dig a bit more on the Cisco WWW site and see if I can turn anything up.

I take it that if I want to route to 147.X.X.X 255.255.255.0 via

195.X.X.1 that the router will assume it has a path to this endpoint as the Dialer has the ip address 195.X.X.37 255.255.255.0.

I did take the route out and added 147.X.X.X 255.255.255.0 dialer10. I got some ping responses but we tried again and no joy.

Regards

Darren

Reply to
Darren Green

Does the far-end router have a route to 212.x.x.114 via 195.xx.xx.37 - i.e over the BRI link ?

Was the same addressing that was used on the PRI moved to BRI or was a new address assigment for the BRI link used ?

Reply to
Merv

I will need to check the far end router setup as its not ours but as the config from the local router (IP addresses and all) mirrors the one replaced.

So putting the PRI back in works fine. Putting the BRI route in doesn't. I have obviously missed something on the configs (or it is down to the different physical setup). I will check them again.

Regards

Darren

Reply to
Darren Green

So if the link addressing used is the same fro both the PRI and BRI, then does the far end-router, which also might also be different router as a result of changing from PRI to BRI, have a static route pointing back to 212.x.x.114. You could ask for output of show ip route 212.x.x.114

if you enable debug ip icmp you should be able to see if the packets are actually being sent out the BRI interface.

Reply to
Merv

I will ask the maintainer of the far end kit to confirm what there set up is. When we try to swap this out again in a couple of days time I will run the debug.

BTW the ping is always initiated from a host on my LAN 212.X.X.113. The

213.X.X.114 address was put onto my router Fast Ethernet as a secondary address for testing purposes. Again this mirrored the PRI router at my end that I tired to swap out. The .114 address had been placed on it for testing also and worked OK.

Regards

Darren

Reply to
Darren Green

when you say " the ping is always initiated from a host on my LAN

212.X.X.113" is that the NAT'ed or the unNAT'ed source IP address on the LAN ?

So you can do an extended ping using source of 212.x.x.114 successfully but not 212.x.x.113 - is that correct ?

in additon to the debug ip icmp, you may also want to do a debug on the nat translation

Reply to
Merv

The host is a server on Fa0/1 (Nat inside) - IP = 10.20.0.10 and this is natted to the 213.x.x.114 address when exiting Dialer 10 (Nat outside).

IP address 213.X.X.113 /30 is the secondary address on Fa0/1 and was used for testing purpose.

I will give the debug ip nat translation a whirl in addition to ICMP and see what that tells me.

Regards

Darren

Reply to
Darren Green

So possible reasons not to receive a ping response:

  1. ICMP echo packet sourced from 10.20.0.10 does not get routed to outgoing ISDN dialer interface

  1. NAT does not occur properly on outgoing interface

  2. Far-end does not route ICMP echo packet properly to destination.

  1. Far-end does not know how to route ICMP echo reply back to your router

Let us know how your next set of testing goes

Reply to
Merv

Will do.

I think the next window to do this is likely to be back end of Week, Thursday poss Friday. Will post update then.

Regards

Darren

Reply to
Darren Green

Would you believe it.

Came to cut this over again this evening and it all worked OK. Haven't had to modify anything, how frustrating. Upshot is I don't know what the issue was & never got the chance the try the various bits of troubleshooting suggested.

Thanks to all who responded.

Regards

Darren

Reply to
Darren

maybe the network engineer at the other side reads this newsgroup too ;-))

Reply to
Merv

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.