Weird ping problem

[netops01]

This one is making me pull my hair out!

We have a central office with branch offices connecting in. Some remote offices connect to a branch which then connects to central. We were using OSPF everywhere and all was well with the world.

Then one branch office was sold off, this branch had a remote office hanging off of it. I have to bring the connection in via a firewall now. So I removed OSPF from the branch and remote offices and put static routes in. All is working well and traffic flows normally. BUT... When I telnet to the remote office from central office and try to ping central, requests time out. From remote I can ping branch and serial i/f at branch that leads to central, but no futher. NOW.. still telneted to remote office I do an extended ping and it goes through OK!! Why?? Configs below.

Setup

Central Office

|

|Serial link

|

Branch Office

|

|serial link

|

Remote office

Branch Config

!

version 12.0

service timestamps debug uptime

service timestamps log datetime localtime

service password-encryption

service linenumber

!

hostname Branch Office

!

enable password

!

ip subnet-zero

!

process-max-time 200

!

interface Serial0

Description Connection to central office

bandwidth 128

ip address 172.x.x.x 255.255.255.252

ip redirects

ip directed-broadcast

no ip mroute-cache

compress stac

!

interface Serial1

Description Connection to Remote office

bandwidth 64

ip address 172.x.x.x 255.255.255.252

ip redirects

ip directed-broadcast

ip ospf authentication-key 7 120A0916001F15

no ip mroute-cache

compress stac

!

description Branch Office - Ethernet LAN

ip address 172.x.x.1 255.255.255.128

ip directed-broadcast

full-duplex

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.x.x.x Serial IP of Central

ip route 0.0.0.0 0.0.0.0 Serial0

ip route 172.x.x.x 255.255.255.240 172.x.x.x Serial IP of remote

no ip http server

!

Edited out.

Remote config

version 12.1

service config

service timestamps debug datetime localtime

service timestamps log datetime localtime

service password-encryption

!

hostname Remote Office

!

logging buffered 4096 debugging

enable password

!

!

!

!

!

memory-size iomem 25

ip subnet-zero

!

interface Serial0

description Remote to branch

bandwidth 64

ip address 172.x.x.x 255.255.255.252

ip directed-broadcast

compress stac

!

interface FastEthernet0

ip address 172.x.x.129 255.255.255.240

ip directed-broadcast

speed auto

full-duplex

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.x.x.x Serial 1 Branch office

no ip http server

!

end

Any thoughts and suggestions as to why data flows ok but a lousy ping fails, extended ping works!!

Ian

[rjackson]

Sounds like the central office doesn't have a route to the serial side of the remote.

[rlcarr]

What are you changing when you use extended? (Source address?)

Try doing an extended traceroute with both your outbound facing interface and one using you LAN as the source. With both of these traces use the Record option from your extended commands. You will find out which router doesn't know about which network.

Also, why change your standard. Re-terminate the remote office to another branch and run OSPF. By maintaining standards throughout the network you will lessen your support problems.

[netops01]

Yes, extended ping from remote office I add the remote office fast ethernet address of router and all works.

Central office can ping and traceroute to every address in the chain to remote office.

Extended traceroute works from remote to central when I add source address.

Normal traceroute from central works every time!!!!

So, Central office knows route to remote OK. All data traffic passes from remote to central with no problems. Its just ping that bombs out past the branch office, so I did a icmp debug at central office and it shows the pings recieved and echo reply being sent, to serial interface of remote router, as it should be. But they never get there. This is so weird!!!!!

[netops01]

OK people I have sorted the problem. I added a static route at the central office to cover the network used on the serial link between remote and branch. It works fine now. Obvious with 20/20 hindsight!