Introduction
Frame Relay is an important exam topic in the CCNA (mostly ICND2 exam), CCNP, and CCIE certifications for the routing and switching track. Frame Relay is not as popular for WAN connectivity strategy because of the rise in newer technologies like Multiprotocol Label Switching (MPLS) and other VPN strategies that create a private communication link over a public network (like IPSec tunneling). Many organizations continue to use traditional point to point dedicated lines (T1, T3, etc). Frame Relay switching is a possible way for a service provider to switch frames between a customer's site. Frame Relay is considered a Layer 2 technology (compare with other layer 2 technologies like Ethernet and Asynchronous Transfer Mode [ATM]). Frame Relay operates differently from other protocols in that the destination is addressed from the sender's perspective instead of the recipients perspective. To clarify this, consider how Ethernet switching works: A station sends a frame to the destination MAC address of another system. The MAC address uniquely identifies the system within the layer 2 switching topology (which can traverse multiple switches).
For Frame Relay, the switch on the service provider's network notifies a router of the permanent virtual circuits (PVCs) that are available to be switched and the data link connection identifiers (DLCIs) that need to be used to transmit on each PVC. This notification happens using the Local Management Interface (LMI) messages that are passed from the frame relay switch to the routers. In this case, the DLCIs only need to be unique between the router and the frame-relay switch. In the example below, R1 and R2 could both use DLCI 100 and have a functional data path between them because the DLCI only needs to be unique between the router and the first hop switch on the service provider portion of the network.
Below I use different DLCIs for clarity (and in practice some customers use the globally unique DLCI addressing practice instead of relying on the local significance property of DLCIs). When I write DLCI 101, this really means "the PVC that connects R2 and R1 that is addressed from R2's perspective."
In this Cisco frame relay lab, I show the easiest topology that can be created with three routers (2 acting as customer edge devices and one acting as a Frame Relay switch). I built the lab in GNS3/Dynamips using 3 Cisco c3725 routers with WIC-2T cards. A single PVC is created between routers R1 and R2 and basic IP connectivity is established. Understanding this is the first step to understanding how to configure a frame relay cloud.
Configuration of the Frame Relay Switch
Configuration of the frame relay switch is fairly straightforward. In global configuration mode, the frame-relay switching command is needed.FRS(config)#frame-relay switching
For the serial interfaces, a couple of pieces need to be done. The encapsulation type needs to be set to frame-relay and the frame-relay interface types need to be set to DCE. The frame-relay route command needs to be used to identify how to switch DLCIs on the interfaces that they are received on. The format of the command is:
frame-relay route <received_dlci> interface <outgoing_interface> <outgoing_dlci>
Options also exist to route frames across Frame-Relay Multilink and tunnel interfaces. The configurations for Serial 0/0 (connecting to R1) and Serial 0/1 (Connecting to R2) are shown below:
interface Serial0/0
no ip address
encapsulation frame-relay
clock rate 2000000
frame-relay intf-type dce
frame-relay route 100 interface Serial0/1 101
interface Serial0/1
no ip address
encapsulation frame-relay
clock rate 2000000
frame-relay intf-type dce
frame-relay route 101 interface Serial0/0 100
From the configurations, any frames received on Serial 0/0 with a DLCI of 100 are sent out Serial 0/1 with a new DLCI of 101. Frames received on Serial 0/1 with DLCI 101 are sent out Serial 0/0 with DLCI 100. The main command that is useful for verification on the frame-relay switch is the show frame-relay route command:
FRS#show frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial0/0 100 Serial0/1 101 inactive
Serial0/1 101 Serial0/0 100 inactive
Since our customer edge routers are not configured yet, the switching status shows as inactive. It should be noted that no IP configuration is necessary on the frame-relay switch (since Frame Relay is a layer 2 protocol).
Configuration of the Customer Edge Devices
Configuration of the customer edge devices is fairly straightforward. Since we only have a single PVC between R1 and R2, a point-to-point subinterface on each router (for the respective output DLCI) is all that is required. IP addresses need to be configured to achieve layer 3 connectivity. The relevant configurations for R1 and R2 are shown below:On Customer Router R1:
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.100 point-to-point
ip address 10.0.0.100 255.255.255.0
frame-relay interface-dlci 100
On Customer Router R2:
interface Serial0/1
no ip address
encapsulation frame-relay
!
interface Serial0/1.101 point-to-point
ip address 10.0.0.101 255.255.255.0
frame-relay interface-dlci 101
On subinterfaces, the frame-relay interface-dlci command is necessary because the subinterface configuration is not known by the frame relay switch and the subinterface configuration is not part of the LMI messages exchanged between the service provider and customer edge devices. The network engineers for the customer are responsible for determining higher layer configuration (such as IP connectivity) and depending on the PVC layout, it may make more sense to use point-to-multipoint subinterfaces (these will be demonstrated in the next post on Frame Relay that shows provider and customer configurations for three sites).
Verification of the Solution
Verification is fairly straightforward, for this example I will demonstrate a top-down approach (layer 3 -> layer 2 -> layer 1).
Layer 3 (IP Connectivity)
Can R1 ping R2's S0/1.101 interface?R1#ping 10.0.0.101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.101, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/44 ms
Can R2 ping R1's S0/0.100 interface?
R2#ping 10.0.0.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/20/52 ms
We should also only see a single hop in a traceroute (since there is no IP configuration on the frame-relay switch and it is not a routed connection from the provider's perspective)...
R1#traceroute 10.0.0.101
Type escape sequence to abort.
Tracing the route to 10.0.0.101
1 10.0.0.101 44 msec * 44 msec
R2#traceroute 10.0.0.100
Type escape sequence to abort.
Tracing the route to 10.0.0.100
1 10.0.0.100 40 msec * 44 msec
Layer 2 Verification (Frame Relay)
From the frame relay switch, the most useful command is show frame-relay route. This shows which switching paths are actually active.FRS#show frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
Serial0/0 100 Serial0/1 101 active
Serial0/1 101 Serial0/0 100 active
Running a show frame-relay pvc command from the switch also shows some useful information. :
FRS#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DCE)
Active Inactive Deleted Static
Local 0 0 0 0
Switched 1 0 0 0
Unused 0 0 0 0
DLCI = 100, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
input pkts 45 output pkts 43 in bytes 10976
out bytes 10328 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
switched pkts 45
Detailed packet drop counters:
no out intf 0 out intf down 0 no out PVC 0
in PVC down 0 out PVC down 0 pkt too big 0
shaping Q full 0 pkt above DE 0 policing drop 0
pvc create time 01:29:17, last time pvc status changed 00:28:25
PVC Statistics for interface Serial0/1 (Frame Relay DCE)
Active Inactive Deleted Static
Local 0 0 0 0
Switched 1 0 0 0
Unused 0 0 0 0
DLCI = 101, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0/1
input pkts 43 output pkts 46 in bytes 10328
out bytes 11300 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
switched pkts 43
Detailed packet drop counters:
no out intf 0 out intf down 0 no out PVC 0
in PVC down 0 out PVC down 0 pkt too big 0
shaping Q full 0 pkt above DE 0 policing drop 0
pvc create time 01:28:13, last time pvc status changed 00:29:01
Items that can quickly be seen from this command are misconfigured interface types, excessive dropped frames, attempts to switch on nonexistent/down PVCs, and PVCs marked inactive or deleted (that should be active or should exist).
On the customer side, the show-frame-relay route command is not applicable and the show frame-relay pvc command shows PVC information gathered from the LMI messages passed between the provider switch and the customer edge device. For brevity, I will only show the output from R1,
Nothing here because we are not switching on R1:
R1#show frame-relay route
Input Intf Input Dlci Output Intf Output Dlci Status
This shows that we only have 1 PVC defined on the switch for this interface (specifically the PVC with DLCI 100 that goes to R2). This also shows that we configured S0/0.100 for the communication on the PVC.:
R1#show frame-relay pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 1 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.100
input pkts 52 output pkts 55 in bytes 13244
out bytes 14216 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 40 out bcast bytes 12960
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:39:20, last time pvc status changed 00:37:30
Also worth noting is that Cisco Discovery Protocol (CDP) does not show the provider switch, it only shows the router on the other end of the PVC:
R1#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
R2 Ser 0/0.1 152 R S I 3725 Ser 0/1.1
R2#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
R1 Ser 0/1.1 140 R S I 3725 Ser 0/0.1
Layer 1 Verification
Verification of layer 1 (and layer 2) is possible by examining the output from the show interface command. I will show the output from R1 for the Serial 0/0 and Serial 0/0.100 interfaces:R1#show int s0/0
Serial0/0 is up, line protocol is up
Hardware is GT96K Serial
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
CRC checking enabled
LMI enq sent 271, LMI stat recvd 272, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 46/0, interface broadcasts 0
Last input 00:00:08, output 00:00:09, output hang never
Last clearing of "show interface" counters 00:45:28
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/1/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
331 packets input, 19121 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
336 packets output, 19736 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
R1#show int s0/0.100
Serial0/0.100 is up, line protocol is up
Hardware is GT96K Serial
Internet address is 10.0.0.100/24
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY
CRC checking enabled
Last clearing of "show interface" counters never
Here we clearly see that the interface is in an up/up status. We also see other useful information such as statistics regarding LMI messages, LMI type, and general interface statistics.
This post mainly detailed basic switching between two customer sites. Future posts will go into more complex customer/provider scenarios and will eventually get into the QoS and routing protocol complexities associated with frame relay.
See Also:
The Road to the CCIE
Cisco Frame Relay Switching Lab: Partially Meshed PVCs
Cisco Frame Relay Switching Lab: Fully Meshed PVCs
No comments:
Post a Comment