01-03-2006 10:36 AM - edited 03-03-2019 11:21 AM
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!
Solved! Go to Solution.
01-03-2006 11:13 AM
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
01-03-2006 11:09 AM
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
01-03-2006 11:13 AM
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
01-04-2006 01:51 AM
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
01-04-2006 02:04 AM
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
01-04-2006 07:04 AM
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
01-04-2006 11:09 AM
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?
01-04-2006 01:36 PM
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
01-05-2006 10:39 AM
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
01-05-2006 10:58 AM
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
01-05-2006 11:18 AM
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
01-05-2006 12:05 PM
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
01-05-2006 04:04 PM
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
01-06-2006 01:42 AM
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
01-06-2006 07:40 AM
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.
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: