Saturday, March 3, 2012

Introduction to Frame Relay Switching


Advertisement

Advertisement

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