Ping not working in Frame relay

[jattboy]

Hello All,

Here is the topology diagram for my lab:

(R1) -------- (FR/R2) ------- (R3)

R2 is configured as Frame Relay Switch and all the configuration is done correctly.
R1's Serial 0 is connected to R2's Serial 0 and R1 DLCi is 103
R3's Serial 1 is connected to R2's Serial 1 and R3 DLCi is 301

I am running OSPF on R1 and R3 and I am able to see the OSPF neighbor relationship on both R1 and R3 and can see all the OSPF routes. Also can ping from R1 to any R3 interface and vice-versa.

Only problem is that when on R1, can not ping R1's own Serial 0 interface AND when on R3, can not ping R3's own Serial 1 interface.

I tried to make the interfaces Network types Broadcast and Non-Broadcast but still could not ping.

Thanks for reading and looking forward to your suggestions.

 

[BeanDip]

Dusting off the cobwebs in my mind, I think I know the reason for this...

You need to do an extended ping choosing another router interface as the source (such as the FA0/0, or another serial port).


When you ping from a Cisco router it uses the interface closest to the target as the ping source.

Therefore when you are pinging the serial interface it is also the closest interface and therefore sends the ping but there is nothing out there to respond back.

Edit** - reading ScottMac's post triggered my memory. He is correct in that you have to have a DCLI mapping to your IP address.

 

[ScottMac]

(Assuming Cisco equipment)

Did you set up the "whole" interface to FR? (int s0/0, encaps Frame, ip addr xxxx xxxx) or did you use sub-interfaces (one for each PVC, i.e., int s0/0.1, encaps frame, ip addr xxxx xxxx)?

You may need to put in a Frame-relay interface DLCI mapping back to your interface to get ping to work. When you ping a frame interface (at least with Cisco) the ping goes out to the cloud and gets routed back ... you don't have a mapping or route back to your own interface.

You may be able to veirify this when you get it to work by pinging the far-end interface, then the local. The local ping time will be double (trip out, then back).

Try a search on Cisco's site for the full explanation.

Good Luck

Scott

 

[polm]

ScottMac is probably right, you need to setup some frame-relay mappings to provide the resolution.

In point-to-point I don't think InARP is going to work.

 

[spidey07]

Use sub interfaces, or put in the appropriate frame-realy map statements.

I think this has to do with proxy arp (-edit- doh! inverse arp). You can search cisco's site for a more detailed explanation. But if you aren't using sub-interfaces then this behavior is normal for a NBMA (non-broadcast multiple access) interface.

 

[polm]

Maybe Juliette Lewis knows ?

 

[jattboy]

Thanks ScottMac, you were right. I put "frame-relay map ip" to router's own interface and the ping works. Also the time is double to ping your own interface than to ping the other router on other side of the Frame-relay switch.

Here is what I did:
int s0
frame-relay map ip s0(IP address) DLCI

You guys are great. Thanks and keep up the good work.

 

[spidey07]

please use sub interfaces.

It will make all these kinds of nit-picky things disappear.

There are very rare instances where you would run frame-relay and NOT use sub-interfaces. I really can't think of a reason why you wouldn't.

 

[Garion]

Originally posted by: spidey07
please use sub interfaces.

It will make all these kinds of nit-picky things disappear.

There are very rare instances where you would run frame-relay and NOT use sub-interfaces. I really can't think of a reason why you wouldn't.

I'm very rusty on this stuff, but I recall that mapping frame relay DLCI's on an interface allows you to use a single IP subnet for the all the router nodes on the frame cloud. This is a lot easier for most admins to understand than sub-interfaces which require separate subnets (i.e., a /252) and add a fair amount of complexity for those not used to it. For us, sure. For your average joe, a frame relay map-ip is probably easier.

- G

 

[spidey07]

yeah, you can do it without sub-interfaces...but it introduces all kinds of quirks to whatever routing protocol you are running (split-horizon and NBMA network)