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.

Saturday, December 26, 2009

Frame Relay Part 1: preparing the frame-relay switches

Hi all, I'm starting my CCIE R&S Lab preparation with a "classic" argument and a lot of good proposals for this new year... (first of all: more accuracy on my labs, I'm trying to get my digits!)

So let's take a look to my frame-relay topology and then we can start labbing and understanding how this old-times technology works.



As you can see, it's a 4 routers topology with two frame relay switches, just to refresh how to configure them in nni mode.

Let's begin with some basic configuration tasks and then we can start to explore the various interface modes and some dirty tricks.


1) Frame relay switches configuration
Here we have two switches, so we have to plan how to configure the various DLCIs.
The method I use to configure Frame relay switches is to build by hand a "sh frame-relay route" output on a scratchpaper before to start configuring, so I'll have no pain to forget any dlci when I go to the interfaces. A tip can be to start with the lowest number interfaces and lowest dlci, so you will write in the same order ad they will appear later in your sh frame-relay route
For our topology, the frame-relay route will be:

FR-SW1:
in interface in dlci out interface out dlci
ser 1/0:1 104 ser 2/0:1 111
ser 1/1:1 203 ser 2/0:1 222
ser 1/1:1 204 ser 2/0:1 333
ser 2/0:1 111 ser 1/0:1 104
ser 2/0:1 222 ser 1/1:1 203
ser 2/0:1 333 ser 1/1:1 204

FS-SW2:
in interface in dlci out interface out dlci
ser 1/2 302 ser 4/0:1 222
ser 1/3 401 ser 4/0:1 111
ser 1/3 402 ser 4/0:1 333
ser 4/0:1 111 ser 1/3 401
ser 4/0:1 222 ser 1/2 302
ser 4/0:1 333 ser 1/3 402

As you can see, between the two frame relay switches, you can use different DLCI numbers, just keep in mind the dlci modifications across your network: eg. in 104 -> out 111 -> in 111 -> out 401 .

Ok now let's configure the frame-relay switches:

FR-SW1#conf t

frame-relay switching

interface Serial1/0:1
description to R1
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 104 interface Serial2/0:1 111

interface Serial1/1:1
description to R2
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 203 interface Serial2/0:1 222
frame-relay route 204 interface Serial2/0:1 333

interface Serial2/0:1
description to FR-SW2
no ip address
encapsulation frame-relay
frame-relay intf-type nni
frame-relay route 111 interface Serial1/0:1 104
frame-relay route 222 interface Serial1/1:1 203
frame-relay route 333 interface Serial1/1:1 204
end

FR-SW1#sh frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial1/0:1 104 Serial2/0:1 111 inactive
Serial1/1:1 203 Serial2/0:1 222 inactive
Serial1/1:1 204 Serial2/0:1 333 inactive
Serial2/0:1 111 Serial1/0:1 104 inactive
Serial2/0:1 222 Serial1/1:1 203 inactive
Serial2/0:1 333 Serial1/1:1 204 inactive


note the different interface types, configured with the "frame-relay intf-type" command... you have 3 options: dce, dte and nni.
DTE is the default when encapsulation frame-relay is enabled
DCE is used (usually) on frame relay switch on interfaces connecting to the customers (our R1-4 here)
NNI is used (usually) to connect interfaces in network-to-network mode between frame-relay switches
Here I've assumed that the serial cables have DCE connector on frame-relay switch side (always verify with "sh controller | inc (DCE|DTE) " command).
Anyway, the DCE/DTE status configured under the frame-relay circuit has nothing to do with cabling, later we will try to do some dirty tricks just in case the proctors decide to do the virtual circuit assignment with dce interfaces on routers side.

The second Fr-Switch will have:

FR-SW2#conf t

frame-relay switching

interface Serial1/2
description to R3
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 302 interface Serial4/0:1 222

interface Serial1/3
description to R4
no ip address
encapsulation frame-relay
frame-relay intf-type dce
frame-relay route 401 interface Serial4/0:1 111
frame-relay route 402 interface Serial4/0:1 333

interface Serial4/0:1
description to FR-SW1
no ip address
encapsulation frame-relay
frame-relay intf-type nni
frame-relay route 111 interface Serial1/3 401
frame-relay route 222 interface Serial1/2 302
frame-relay route 333 interface Serial1/3 402
end

FW-SW2#sh frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial1/2 302 Serial4/0:1 222 inactive
Serial1/3 401 Serial4/0:1 111 inactive
Serial1/3 402 Serial4/0:1 333 inactive
Serial4/0:1 111 Serial1/3 401 inactive
Serial4/0:1 222 Serial1/2 302 inactive
Serial4/0:1 333 Serial1/3 402 inactive


well, our frame-relay route looks exactly as planned.

In our example here, we have left all the default behaviors of our frame-relay interfaces, but when configuring a frame-relay switch we can play with lmi (not with encapsulation, since the frame-relay switch doesn't decapsulate the frame.... , it's a switch ;-) )

FR-SW1#sh frame-relay lmi int ser 1/0:1

LMI Statistics for interface Serial1/0:1 (Frame Relay DCE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Rcvd 281 Num Status msgs Sent 281
Num Update Status Sent 0 Num St Enq. Timeouts 23


Here we have left the Lmi type Cisco, that is the default on DCE intf-type, but we can change it, choosing between cisco | ansi | q933a as required.


FR-SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
FR-SW1(config)#int ser 1/0:1
FR-SW1(config-if)#frame-relay lmi-type ?
cisco
ansi
q933a

FR-SW1(config-if)#frame-relay lmi-type ansi
FR-SW1(config-if)#do sh frame-relay lmi int ser 1/0:1

LMI Statistics for interface Serial1/0:1 (Frame Relay DCE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Rcvd 386 Num Status msgs Sent 386
Num Update Status Sent 0 Num St Enq. Timeouts 23
FR-SW1(config-if)#


note: if you have already configured the router attacched to this interface, it's a good idea to shut the serial interface, that's because by default your router (dte) will perform lmi autosense, so if you change the lmi type with the interface up, he will bring it in protocol down shortly due to lmi mismatch (switch has ansi, router thinks to use cisco type)

Another important thing to remember is that LMI is significant only on your local link, so R1 and FR-SW1 can use lmi type ansi and FR-SW2 and R4 can use lmi type cisco, this doesn't affect the virtual circuit status in any way.

About LMI, just remember that you enable LMI as "keepalive" on Serial interfaces, so look at show interface output:

FW-SW2#sh int ser 1/2
Serial1/2 is up, line protocol is down
Hardware is M4T
Description: to R3
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, crc 16, loopback not set
Keepalive set (10 sec)
LMI enq sent 0, LMI stat recvd 0, LMI upd recvd 0
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0, DCE LMI down
LMI DLCI 1023 LMI type is CISCO frame relay DCE
FR SVC disabled, LAPF state down
[...]


This "keepalive set" is the keepalive time interval, that is the Lmi time interval too. Your router exchanges lmi keepalives with the fr-switch every 10 seconds by default, and requests for a full lmi update every 6x keepalive interval, so 60 secs by default.

To change this default behavior and change the lmi full updates requests, you can:
-change the keepalive interval on both sides (router and Fr-switch)
-change the number of keepalives on router side to request lmi full status updates

frame-relay lmi-n391dte 3 !-- set full status polling counter <1-255>


Also note from the previous output that there is a reserved DLCI number for LMI, Cisco lmi uses DLCI 1023, ansi lmi and q933a uses DLCI 0.

!-- END OF PART 1 : next part will be about Frame-Relay encapsulation and inverse arp

Sunday, December 20, 2009

Happy Holydays

Happy Studying Holydays to all networkers!



I'll pass studing too! ;-)


Marco

Wednesday, December 16, 2009

Back to office: New Fw ... new platform to learn!

Hi all, after an intense study-week today I'm back to office with a "preliminary score report" in my hand (... and can't say nothing about it until confirmed ;-) ).

Anyway, after a strong Cisco exam, and the CCNA CCAI Instructor Course, I was a bit surprised when I see the new firewall waiting on my desk at office.... It's a new Ju(hemhemmmm) a new Juniper SRX-650 !!

the nice thing is that I feel like a ccna using junos, I have to learn cli commands from basics again ! ;-)

Well doesn't matter, here the shots :







Well, this week I'll prepare some general fw policies, next week I'll follow the new Wism and Wcs Server installation, then, after Holydays will be the turn of this firewall.....

Stay tuned!

Marco ;-)

Saturday, December 5, 2009

Today's work in a shot: switch installation in a new building

Hi all,

today was my last working day before holydays.

I'll spend the next 10 days studying on written topics (exam planned on Dec 16th) and trying to become a CCNA instructor (CCNA CCAI course by Europa Networking Bg)

So what's better than finish your week with a simple 4 switches installation?

here are two shots:






The white one is obviuosly not mine (wrong vendor ;) )

Ehehe too few cables here... I'll see what happening when people will move into this new building (not a new spaghetti rack hopefully) ;-)


Marco