troubleshoot wan connection

[tomredmond]

any and all suggestions welcomed.

I have a remote site on a 1721 router connected to two core routers both 3660's by frame relay pvc's. One link is suppost to be a redundant link to the other. The two links are in two seperate subnets.

I can traceroute and or telnet from the core to the remote router but I cannot ping.

I can also traceroute/telnet from the remote router to the core and beyond but I can't ping.

I can ping from a pc in the core to either of the remote interfaces but a traceroute fails.

The ospf is not being shared and the ip ospf neighbor command say the state is EXSTART or down all though the neighbor id is correct.

I am happy to supply config's answer questions etc

Tom Redmond

[deilert]

'Can you ping across the PVC's when sourcing the ping ?

ping 52.5.84.2 sourcing from 52.2.84.1

I would also remove all parameters from the interface other than the ip address and the FR int DLCI commands , see if it works just with a bare bones config. maybe you have a spave in your PW for authentication .

[tomredmond]

I did a few pings and traceroutes to illustrate the problems. The 52.200.33.1 address at the end is a pc on our core LAN.

From that pc or any other on the LAN I can ping all the interfaces involved but I cannot traceroute to them. I can however telnet to them.

bar#ping

Protocol [ip]:

Target IP address: 52.5.84.2

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 52.5.84.1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 52.5.84.2, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

bar#ping

Protocol [ip]:

Target IP address: 52.5.84.130

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 52.5.84.1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 52.5.84.130, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

bar#ping 52.5.84.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 52.5.84.2, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

bar#trac

bar#traceroute 52.5.84.2

Type escape sequence to abort.

Tracing the route to 52.5.84.2

1 52.5.84.2 48 msec * 40 msec

bar#traceroute 52.5.84.130

Type escape sequence to abort.

Tracing the route to 52.5.84.130

1 52.5.84.130 68 msec * 52 msec

bar#ping 52.200.33.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 52.200.33.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

bar#tracer

bar#traceroute 52.200.33.1

Type escape sequence to abort.

Tracing the route to 52.200.33.1

1 52.5.84.130 64 msec 60 msec 60 msec

2 52.200.33.1 60 msec 60 msec 60 msec

[deilert]

Tom

If you can not ping directly connected netwrorks your OSPF will never establish a relationship.

You can trace because it is going around since the interface are up your traces are successful.

Try a few things

try clearing the CEF and or route-cache

try removing the ip helper from the serial interface

try going with a bare bones config

try making your subnet masks 30 bits

If all of this fail I would open a ticket with the FR provider telling them you are not able to pass data , .

[tomredmond]

I went with a barebones config on the primary link i.e. serial0.16 on remote router and serial1/0.134 on hq core router and I can now ping on that link.

I removed the ip helper address, ip ospf authentication-key, frame-relay compression and the ip directed broadcast. I will try add ing them one at a time and see at what point it fails but any suggestions are welcome.

[rjackson]

it looks like you have area 0.0.0.84 connected to area 0 and at the remote router to area 0.0.0.100, which is also connected to area 0. So when the data takes the path through area 0.0.0.100 it needs a virtual link. When it takes the other path it does not. I'm not sure you can make it work this way but try making area 0.0.0.100 a virual link. Or clean it up and use area 0.0.0.84 throughout.

[rjackson]

To make the virtual link work you will also need to specify area 0 authentication on the remote router.