Monday, December 28, 2009

Frame Relay Part 2: encapsulation and inverse arp

Hi all,
here the second part of my frame-relay studies. In the last post we have seen the frame relay switches configuration and some details about lmi.

The topology still the same:




The frame relay switches are already configured, I've just added some DLCIs to introduce some enthropy to enhance our inarp experience ;-)

Let's begin talking about encapsulation. In Frame Relay interfaces the ip, ipv6 and other protocols packets are encapsulated within a L2 frame.
The frame format can vary according to the coosen encapsulation, our Cisco toys support the encapsulation Cisco (enabled by default) or IETF (also referred as RFC1490/RFC2427 ).
Just remember that the frame relay switches doesn't decapsulate the data, they act only as layer 2 switches using DLCI and frame-relay route.

The encapsulation can be specified on the physical interface and per dlci using the frame-relay map command.
eg:

R3(config-if)#do sh run int ser 0/3/0 | beg int
interface Serial0/3/0
ip address 10.0.0.3 255.255.255.0
encapsulation frame-relay IETF
end

Here the encapsulation is specified on the physical interface, so it's valid for each DLCI on that interface. The L2 to L3 mapping is done via inverse-arp, as default.
Another example with the encapsulation specified by dlci

R4#sh run int ser 0/3/0 | beg int
interface Serial0/3/0
ip address 10.0.0.4 255.255.255.0
encapsulation frame-relay
frame-relay map ip 10.0.0.2 402 broadcast
frame-relay map ip 10.0.0.1 401 broadcast IETF
no frame-relay inverse-arp
end

R4#sh frame-relay map
Serial0/3/0 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), static,
broadcast,
IETF, status defined, active
Serial0/3/0 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), static,
broadcast,
CISCO, status defined, active


Here the dlci 402 is using cisco encapsulation, the dlci 401 is using IETF as shown in the sh frame-relay map.

Well, let's talk about inverse-arp, one of the most annoying/exciting features of frame-relay.
The point is: I have a frame-relay interface, eg, R4 with his serial interface configured with an ip address like 10.0.0.4/24. R4 must know how to reach the other routers on his subnet, knowing the ip address, like 10.0.0.2, he must know at which DLCI it belongs.
One method is to map the ip addresses manually, with the frame-relay map ip 10.0.0.2 402 command as in the previous example, the other way is to let R4 "discover" the right dlci through inverse arp.

an example, on R4:
R4# sh run int ser 0/3/0
Building configuration...

Current configuration : 91 bytes
!
interface Serial0/3/0
ip address 10.0.0.4 255.255.255.0
encapsulation frame-relay
end

R4#sh frame-relay pvc | inc DLCI
DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 402, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 403, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 404, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/3/0
DLCI = 405, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/3/0
DLCI = 406, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0/3/0

R4#sh frame-relay map
Serial0/3/0 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), dynamic,
broadcast,, status defined, active
Serial0/3/0 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), dynamic,
broadcast,, status defined, active
Serial0/3/0 (up): ip 10.0.0.3 dlci 403(0x193,0x6430), dynamic,
broadcast,, status defined, active

Here R4 is configured with the ip address and the encapsulation frame relay only, inverse arp is enabled by default, and when the router receives an lmi update message with any dlci in active status, it sends an inverse-arp for that dlci requesting which ip address is reachable through that dlci.
The receiving station maps the requesting router (or ignores it) and then responds with his own ip/ipv6 address.
When receives the response, R4 uses it to form the frame-relay map, as you can see from the command outputs. The inverse-arp learned addresses are "dynamic". (See RFC 2390 - Inverse Address Resolution Protocol )

Sometimes happens that your frame-relay interface learns wrong ip addresses, that doesn't belongs to your frame-relay network, as our R4 has learned R3 ip address... or even that don't have a real ip address, like a 0.0.0.0 entry.
In this case, there are several things to do to correct this kind of mistakes:
(obviously after have removed the cause of that problem, eg a misconfigured interface.
1) shut down the serial interface and perform a "clear frame-relay inarp" and "clear frame-relay counters"
2) in the worst case, save your config and reload the router

To avoid these issues you have to remember that all your DLCIs area assigned by default to the physical interface, so you can use subinterfaces and assign the correct DLCIs according to your topology with the "frame-relay interface-dlci" command, or you can disable manually the inarp for some DLCIs with the "no frame-relay inverse-arp ip" command.

Here the previous example fixed with disabling inverse arp for dlci 403:
R4#sh run int ser 0/3/0 | beg int
interface Serial0/3/0
ip address 10.0.0.4 255.255.255.0
encapsulation frame-relay
no frame-relay inverse-arp IP 403
end

R4#sh frame-relay pvc | inc \ ACT
DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 402, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 403, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0

R4#sh frame-relay map
Serial0/3/0 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), dynamic,
broadcast,
CISCO, status defined, active
Serial0/3/0 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), dynamic,
broadcast,, status defined, active
R4#

This is not a good method, in my opinion, doesn't "protect" against other DLCI eventually configured later.
If you configure a subinterface instead....
R4#sh run int ser0/3/0 | beg int
interface Serial0/3/0
no ip address
encapsulation frame-relay
end

R4#sh run int ser0/3/0.1 | beg int
interface Serial0/3/0.1 multipoint
ip address 10.0.0.4 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 401
frame-relay interface-dlci 402
end

R4#sh frame-relay pvc | inc \ ACT
DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0.1
DLCI = 402, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0.1
DLCI = 403, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0

R4#sh frame-relay map
Serial0/3/0.1 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), dynamic,
broadcast,, status defined, active
Serial0/3/0.1 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), dynamic,
broadcast,, status defined, active
R4#

you will have inverse-arp enabled only for the assigned dlci.
However, with this configuration, from R4 you can't ping R4 ip address, always due to lack of L3 to L2 mapping.

To avoid any problem like this, you have to disable inverse arp and use static mapping for your DLCIs.
for example:

R4#sh run int ser 0/3/0 | beg int
interface Serial0/3/0
ip address 10.0.0.4 255.255.255.0
encapsulation frame-relay
frame-relay map ip 10.0.0.1 401
frame-relay map ip 10.0.0.2 402
no frame-relay inverse-arp
end

R4#sh frame-relay pvc | inc \ ACT
DLCI = 401, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 402, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0
DLCI = 403, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial0/3/0

R4#sh frame-relay map
Serial0/3/0 (up): ip 10.0.0.1 dlci 401(0x191,0x6410), static,
CISCO, status defined, active
Serial0/3/0 (up): ip 10.0.0.2 dlci 402(0x192,0x6420), static,
CISCO, status defined, active

!-- on R2...
R2#sh run int ser 0/2/0:1 | beg int
interface Serial0/2/0:1
ip address 10.0.0.2 255.255.255.0
encapsulation frame-relay
end

R2#sh frame-relay pvc | inc \ ACT
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/0:1
DLCI = 204, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/2/0:1

R2#sh frame-relay map
Serial0/2/0:1 (up): ip 10.0.0.3 dlci 203(0xCB,0x30B0), dynamic,
broadcast,, status defined, active
Serial0/2/0:1 (up): ip 10.0.0.4 dlci 204(0xCC,0x30C0), dynamic,
broadcast,, status defined, active
R2#

In the example above, inverse arp is disabled on R4, see the "static" entries in the frame-relay map, but note also that R4 still answer to the inverse arp requests made for example by R2, that has inverse arp enabled.

!-- END of Part 2, the next part will be about Frame Relay interface types, pros and cons.

No comments: