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

No comments: