cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5338
Views
20
Helpful
24
Replies

Frame-relay can't ping local interface

bellocarico
Level 1
Level 1

Hello, I've got a small problem with frame-relay lab.

This is made by 1 FR switch + 3 routers.

R1>

interface Serial0

bandwidth 64

no ip address

encapsulation frame-relay

!

interface Serial0.1 multipoint

ip address 10.10.1.9 255.255.255.248

no arp frame-relay

no frame-relay inverse-arp

frame-relay map ip 10.10.1.10 103

frame-relay map ip 10.10.1.11 102

R2>

interface Serial0

bandwidth 64

ip address 10.10.1.10 255.255.255.248

encapsulation frame-relay

no arp frame-relay

no frame-relay inverse-arp

frame-relay map ip 10.10.1.9 301 broadcast

frame-relay map ip 10.10.1.11 301 broadcast

R3>

interface Serial0/2

ip address 10.10.1.11 255.255.255.248

encapsulation frame-relay

no arp frame-relay

no frame-relay inverse-arp

frame-relay map ip 10.10.1.9 201 broadcast

frame-relay map ip 10.10.1.10 201 broadcast

!

As you can see R1 is a "central" router

and all the traffic between R2 and R3 supposed to pass

trought R1

Everything works fine, I can successfully ping from anywhere.

The ony thing that doens't work is the ping to

the from R1 to 10.10.1.9 (local Ip on the subinterface)

There are no access lists at all.

Is there anything I'm missing?

Thanks for your help!

1 Accepted Solution

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

What you are running into is actually a fairly simple problem, which is harder to explain than it is to fix. You are running into a mapping issue. R1 knows that the address is on the subnet of the serial subinterface but it does not have a frame relay map that shows what to do with the address. You can fix this by adding this to your config:

frame-relay map ip 10.10.1.9 102

It seems almost counter-intuitive that you must map your own interface address, but on multipoint interfaces it is true that you must map your own address if you want to ping it.

As you have discovered almost everything works correctly without mapping your own address. The only things that will not work are attempting to send to your own interface address (like pinging yourself). Since the router hardly ever sends IP packets to its own interface address there is little impact if your do not map your own address. But if you want to be able to ping your own interface (on multipoint interfaces) then you must map it.

HTH

Rick

HTH

Rick

View solution in original post

24 Replies 24

Hello,

you need to add a mapping for the local IP address as well, as stated below. The nature of frame relay as a non-broadcast multiaccess network is that a ping to the local interface is sent to the other end of the connection first, and then back:

R1>

interface Serial0

bandwidth 64

no ip address

encapsulation frame-relay

!

interface Serial0.1 multipoint

ip address 10.10.1.9 255.255.255.248

no arp frame-relay

no frame-relay inverse-arp

--> frame-relay map ip 10.10.1.9 102

frame-relay map ip 10.10.1.10 103

frame-relay map ip 10.10.1.11 102

HTH,

GP

Richard Burts
Hall of Fame
Hall of Fame

What you are running into is actually a fairly simple problem, which is harder to explain than it is to fix. You are running into a mapping issue. R1 knows that the address is on the subnet of the serial subinterface but it does not have a frame relay map that shows what to do with the address. You can fix this by adding this to your config:

frame-relay map ip 10.10.1.9 102

It seems almost counter-intuitive that you must map your own interface address, but on multipoint interfaces it is true that you must map your own address if you want to ping it.

As you have discovered almost everything works correctly without mapping your own address. The only things that will not work are attempting to send to your own interface address (like pinging yourself). Since the router hardly ever sends IP packets to its own interface address there is little impact if your do not map your own address. But if you want to be able to ping your own interface (on multipoint interfaces) then you must map it.

HTH

Rick

HTH

Rick

Interesting Rick. I will try as soon as I get home.

I still miss 1 point. As my interface on R1 is multipoint (more DLCI) how do I decide to which DLCI I should map my local IP? You mentioned 102, but is there a reason for this?

Also in the real world, should I ask my ISP an additional DLCI to be able to map my own IP (when working in multipoint) or can I share the DLCI with another connection?

Regards

Hi,

with Cisco WAN switches it is possible for the SP to create a "loop" PVC f.e. 105 which starts and terminates on the FR switchport you are connected to.

The big advantage of this is, that you can test the local loop and FR port by pinging your own router interface.

In case this is not an option then mapping it to any other DLCI on the same subnet would help. The thing is your router would send it over the PVC to the connected router. This one would in turn route the packet and send it back through the same DLCI.

Same story for ICMP reply.

Hope this helps

Martin

Stefano

It does not matter which DLCI you use. I chose 102 because it was the lower number but 103 would work just as well. It matters that the local IP is mapped to a working DLCI but does not matter which one.

In the real world there would be no reason to ask the ISP for an additional DLCI. Just map the local IP to one of the working DLCIs.

It may help if we understand the underlying logic of this. On serial links when you ping your own IP address the router actually forwards the ping packet on the line to your neighbor who forwards it back to you. You might try some time this experiment: ping the IP of your neighbor on a serial connection and then ping your own IP address of the serial interface. The time to ping your own address should be just about double the time to ping your neighbors address. So on multipoint Frame Relay if you ping your own IP address the router needs to send the packet out the interface to a neighbor (and it does not matter which neighbor) and needs to have a mapping of its IP to some working DLCI.

HTH

Rick

HTH

Rick

Actually, what about point-to-point subinterfaces?

There, AFAIK if I should use

"frame-relay interface-dlci XXX"

rahter than

"frame-realy map ip XXX X"

and again as far as I'm aware these 2 commands are mutually exclusive.

Any suggestion?

Stefano

The commands frame-relay interface-dlci and frame-relay map are not really mutually exclusive. they perform different functions. While you typically would use one or the other, it is possible to configure both on the same interface (for multipoint). You are correct that you would use frame-relay inteface-dlci for point-to-point subinterface and not frame-relay map.

point-to-point subinterfaces in frame relay work significantly differently than multipoint interfaces do (and in general point-to-point is preferable to multipoint). One of the differences is that the mapping of layer 3 address to layer 2 address is automatic with p-t-p and does not require any frame-relay map commands.

As far as suggestions are concerned, as I said above I believe that most of the time you are better off implementing p-t-p subinterfaces rather than multipoint.

HTH

Rick

HTH

Rick

I appreciate that, however the problems I'm getting are surprisly more on p2p rather than point 2 multipoint.

Q1)Are the Phisical interfaces (no sub-interface) treated like multipoint by default?

Q2) In point-to-point is it enough use the

frame-relay interface-dlci XXX

command or do I also have to enable inverse ARP?

Q3) Can anybody help me with this last issue I'm experiencing?

I've got R-A with this config:

interface Serial0.2 point-to-point

ip address 10.10.1.12 255.255.255.248

frame-relay interface-dlci 104

and R-B with this config

interface Serial0.1 point-to-point

ip address 10.10.1.13 255.255.255.248

frame-relay interface-dlci 401

When I try a ping I get many half of the packets lost

R-A#ping 10.10.1.13

Type escape sequence to abort.

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

!.!.!

Success rate is 60 percent (3/5), round-trip min/avg/max = 60/61/64 ms

Same behaviour pinging from R-B to R-A

Thanks to read

Hi,

A1) I don´t remember, but I guess multipoint.

A2) FR inverse arp is enabled by default in a cisco router.

A3) There seems something missing as in a back-to-back configuration this would not work (DLCI values have to match). So which FR switch is inbetween R-A and R-B? is there policing performed on the FR switch? This could result in the ping performance seen.

What is missing in the picture? Please provide the complete setup for us to be able to understand the problem.

Hope this helps

Martin

Q1) Thanks

Q2) Ok it is enable by default, but do I need it if I use the interface-dlci command on p2p links?

Q3) Yes I'm using a switch and they are not connected back to back.I'm also pretty sure when I say the the DLCI match the switch mapping. No policy on the switch.

Regards

Q1) Yes indeed physical interfaces are treated as multipoint by default.

Q2) Inverse ARP is really not used on p-t-p frame relay. The function of inverse arp is to build mapping of layer 3 to layer 2 addresses. p-t-p has a different mechanism to relate layer 3 to layer 2 and does not need inverse arp. You certainly do not want to try to enable inverse arp on p-t-p frame relay.

Q3) This problem sounds like a routing issue where the router thinks that there are two ways to get to the destination but only one way really works. This time you got 60% and if you immediately repeat the ping I guess that you get 40%. Would you post more of the config of the central router. I am guessing from the symptoms that both DLCIs are in the same subnet. If router A is .12 and router B is .13 did you perhaps configure router C with .14 (or any other address that is in the same subnet)?

HTH

Rick

HTH

Rick

Hi Rick,

just to maybe learn something new: why are you insisting on not using FR inverse ARP on a p2p connection?

I have used this regularly, it works, and I can not understand your objections. OK, it costs a little bandwidth and you can also turn it off and use frame-relay map statements. Still in the lab environment of this post this shouldn´t be such a big difference and issue. Would be nice to get some more insight in your opinion on this matter.

Regards

Martin

Rick: you're right if I run the ping again I get either 40% or 60%.

Martin: According to this page

http://www.ciscopress.com/articles/article.asp?p=170741&seqNum=6

"On point-to-point subinterfaces, you do not need to use the frame-relay map command to perform static address mapping, because it is always assumed that the end point of the point-to-point connection automatically resides on the same subnet as the start point. It is also not required to enable or disable Inverse ARP, because there is only a single remote destination on a point-to-point PVC and discovery is not necessary."

This means to me that you "could" use inverse-arp but it is not a requirement.

##################################################

R-A connects to Serial1 where R-B connects to Serial4

Here is my the frame-relay switch config (Cisco 2523)

##################################################

Current configuration : 5518 bytes

!

version 12.3

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

service udp-small-servers

service tcp-small-servers

!

hostname 2523

!

boot-start-marker

boot-end-marker

!

enable secret 5FJKAEBEVW243FD

!

no aaa new-model

ip subnet-zero

no ip domain lookup

!

frame-relay switching

!

!

!

interface Serial0

no ip address

encapsulation frame-relay

shutdown

clockrate 64000

no fair-queue

cdp enable

no frame-relay inverse-arp

frame-relay intf-type dce

frame-relay route 101 interface Serial2 100

!

interface Serial1

no ip address

encapsulation frame-relay

clockrate 64000

cdp enable

no frame-relay inverse-arp

frame-relay intf-type dce

frame-relay route 102 interface Serial2 201

frame-relay route 103 interface Serial3 301

frame-relay route 104 interface Serial4 401

frame-relay route 105 interface Serial5 501

frame-relay route 106 interface Serial6 601

frame-relay route 107 interface Serial7 701

frame-relay route 108 interface Serial8 801

frame-relay route 109 interface Serial9 901

!

interface Serial2

no ip address

encapsulation frame-relay

clockrate 64000

no frame-relay inverse-arp

frame-relay intf-type dce

!

interface Serial3

no ip address

encapsulation frame-relay

clockrate 64000

no frame-relay inverse-arp

frame-relay intf-type dce

!

interface Serial4

no ip address

encapsulation frame-relay

clockrate 64000

no frame-relay inverse-arp

frame-relay intf-type dce

frame-relay route 401 interface Serial1 104

frame-relay route 402 interface Serial2 204

frame-relay route 403 interface Serial3 304

frame-relay route 405 interface Serial5 504

frame-relay route 406 interface Serial6 604

frame-relay route 407 interface Serial7 704

frame-relay route 408 interface Serial8 804

frame-relay route 409 interface Serial9 904

!

interface Serial5

no ip address

encapsulation frame-relay

clockrate 64000

no frame-relay inverse-arp

frame-relay intf-type dce

!

interface Serial6

no ip address

encapsulation frame-relay

clockrate 64000

no frame-relay inverse-arp

frame-relay intf-type dce

!

interface Serial7

no ip address

encapsulation frame-relay

clockrate 64000

no frame-relay inverse-arp

frame-relay intf-type dce

!

interface Serial8

no ip address

encapsulation frame-relay

clockrate 64000

no frame-relay inverse-arp

frame-relay intf-type dce

!

interface Serial9

no ip address

encapsulation frame-relay

shutdown

clockrate 64000

frame-relay intf-type dce

!

interface TokenRing0

no ip address

shutdown

ring-speed 16

!

interface BRI0

no ip address

shutdown

!

no ip http server

ip classless

!

!

!

alias exec s do show ip inter brief

!

line con 0

exec-timeout 0 0

logging synchronous

transport preferred none

line aux 0

transport input all

line vty 0

exec-timeout 0 0

password c

login

length 25

transport preferred none

line vty 1 4

exec-timeout 0 0

password c

login

transport preferred none

!

!

end

I think the config of RA and RB will be more helpful. They are likely the one wrongly configured. Check the routing table and the frame relay maps on this two routers.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco