Networking

Serial interface

Frame relay is the fastest growing wide-area technology, yet it still seems like a mystery to most IT professionals. With the help of Cisco and Alexander Prohorenko, TechProGuild makes understanding frame relay simple.


Frame relay is the fastest growing wide-area technology and is being used more and more widely all over the world. Unfortunately, it is still a mystery for many of us. In this Daily Drill Down, I will demystify frame relay for you. I believe this will significantly help you in your work.

Frame relay: The basics
Frame relay is a high-performance WAN protocol that operates at the physical and data link layers of the OSI reference model. Frame relay was originally designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well.

Frame relay is a service that provides for "shared" leased lines. Frame relay is a multiplexed interface to a packet-switched network, which means that at the customer equipment interface, there is a single electrical interface, but there appears to be many distinct interfaces to specific systems. To access a frame relay network, the router or server connects to an end-point connection of the relay network. The end point, in turn, connects to at least one leased line that terminates at another end point. The connections are indirect—you are talking to a switch, which is in turn talking to your peer or to another switch.

Many switches are "store and forward" switches, which means that messages will be entirely stored before being switched and retransmitted. If there are five switches between one point and another, a message will be sent six times and none of these will overlap. However, this frame relay feature is vendor-specific.

Information that is to be exchanged over the network is formatted into small, variable-length frames that are routed through the network using a permanent virtual circuit (PVC).

PVCs and SVCs
PVCs are permanently established connections that are used for frequent and consistent data transfers between DTE devices across the frame relay network. Communication across a PVC does not require the call setup and termination states that are used with switched virtual circuits (SVCs). PVCs always operate in one of the following two operational states:
  • Data Transfer: Data is transmitted between the DTE devices over the virtual circuit.
  • Idle: The connection between DTE devices is active, but no data is transferred. Unlike SVCs, PVCs will not be terminated due to being in an idle state.

SVCs allow for dynamic connections to be made between systems. SVCs are temporary connections used in situations requiring only sporadic data transfer between DTE devices across the frame relay network. A communication session across an SVC consists of four operational states:
  • Call Setup: The virtual circuit between two frame relay DTE devices is established.
  • Data Transfer: Data is transmitted between the DTE devices over the virtual circuit.
  • Idle: The connection between DTE devices is still active, but no data is transferred. If an SVC remains in an idle state for a defined period of time, the call can be terminated.
  • Call Termination: The virtual circuit between DTE devices is terminated.

There are some RFCs that cover frame relays on a deeper level. I suggest you look through the Definitions of Managed Objects for Frame Relay Service (1596, 1604) and the Multiprotocol Interconnect over Frame Relay (1294, 1490) RFCs. I assure you that these will be worth your time if you're going to work a lot with frame relays.

Frame relay in practice
Okay, now that we have some theory on frame relays, let's put theory into practice. We can create frame relay connections using one of the following hardware configurations:
  • Connect routers and access servers directly to the frame relay switch.
  • Connect routers and access servers directly to a channel service unit/digital service unit (CSU/DSU), which then connects to a remote frame relay switch.

I'm going to show you the basic frame relay setup because each frame relay setup can be very specific, and I cannot cover all possible configurations in this Daily Drill Down. My goal is to give you the basic skills for working with frame relays. After that, you'll get an idea of how it works in real life, and I'm sure you'll be able to find a solution for your own specific configuration easily.

The router scheme is pretty easy—we have three routers: rtr1, rtr2, and rtr3. The rtr2 router has two serial interfaces (serial 0 for rtr1 and serial 1 for rtr3), to which rtr1 and rtr3 are connected, via serial 0.

We are going to configure rtr2 as a dedicated, DCE-only frame relay switch. Switching is based on Data Link Connection Identifiers (DLCIs). The incoming DLCI is examined, and the outgoing interface and DLCI are determined. Switching takes place when the incoming DLCI in the packet is replaced by the outgoing DLCI, and the packet is sent out the outgoing interface.

To enable frame relay on routers, we have to start from the frame-relay switching command. This enables support for frame relaying and gives us access for other commands.
rtr2#configure terminal
rtr2(config)#frame-relay switching


In this example, the rtr2 router switches two PVCs between interfaces serial 0 and 1. Frames with DLCI 100 received on serial 0 will be transmitted with DLCI 200 on serial 1.

Now we have to configure our serial interfaces to rtr1 and rtr3. Below, you’ll see the configuration for serial 0 on rtr2 (the connection with rtr1). We have to set these interfaces as DCE devices. This can be done with the frame-relay intf-type dce command. The rtr1 and rtr3 interfaces should be configured as DTEs with frame-relay intf-type dte.
rtr2#show running-config interface serial 0
Building configuration...

Current configuration:
!
interface Serial0
 description Frame Relay to rtr1
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay IETF
 load-interval 30
 no fair-queue
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay route 100 interface Serial1 200
 frame-relay route 101 interface Serial1 201
end


We use almost exactly the same configuration for serial interface serial 1, connected to serial 0 on rtr3.
rtr2#show running-config interface serial 1
Building configuration...

Current configuration:
!
interface Serial1
 description Frame Relay to rtr3
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay IETF
 load-interval 30
 no fair-queue
 frame-relay lmi-type ansi
 frame-relay intf-type dce
 frame-relay route 200 interface Serial0 100
 frame-relay route 201 interface Serial0 101
end


In our example, the LMI type is ANSI T1.617 Annex D. It was set with the frame-relay lmi-type ansi configuration command. There are more types available, such as Cisco or ITU-T Q.933 Annex A. If the router or access server is attached to a public data network (PDN), the LMI type must match the type used on the public network. In our case, we are choosing the LMI type, keeping in mind the needs of our private frame relay network.

Let's look at the state of our interface:
rtr2#show interface serial 0
Serial0 is up, line protocol is up
Hardware is M4T
Description: Frame Relay to rtr1
MTU 1500 bytes, BW 2048 Kbit, DLY 20000 usec,
reliability 255/255, txload 22/255, rxload 1/255
Encapsulation FRAME-RELAY IETF, crc 16, loopback not set
Keepalive set (10 sec)
LMI enq sent  0, LMI stat recvd 0, LMI upd recvd 0
LMI enq recvd 146788, LMI stat sent  146788, LMI upd sent  0, DCE LMI up
LMI DLCI 0  LMI type is ANSI Annex D  frame relay DCE
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 24448/3, interface broadcasts 0
Last input 00:00:04, output 00:00:00, output hang never
Last clearing of "show interface" counters 2w3d
Queueing strategy: fifo
Output queue 0/40, 6037 drops; input queue 0/75, 1 drops
30 second input rate 2000 bits/sec, 6 packets/sec
30 second output rate 183000 bits/sec, 39 packets/sec
5392872 packets input, 1161800903 bytes, 1 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 1 throttles
48 input errors, 32 CRC, 0 frame, 1 overrun, 0 ignored, 15 abort
39046336 packets output, 2509658161 bytes, 0 underruns
0 output errors, 0 collisions, 107 interface resets
0 output buffer failures, 0 output buffers swapped out
109 carrier transitions     DCD=up  DSR=up  DTR=up  RTS=up CTS=up
That's it!

Conclusion
You may say this was too simple, but frame relays are simple! The most important rule to remember is that the parameters should be the same on both interfaces, as in X.25 networking. Such conformity of frame relay with X.25 is understandable because frame relay is often described as a streamlined version of X.25 (offering fewer of the robust capabilities, such as windowing and retransmission of lost data, that are offered in X.25). This is because frame relay typically operates over WAN facilities that offer more reliable connection services and a higher degree of reliability than the facilities available during the late 1970s and early 1980s that served as the common platforms for X.25 WANs.

Though frame relay networking was developed more than 10 years ago, its scheme enables frame relay to offer high performance and great transmission efficiency and makes frame relay suitable for current WAN applications, such as LAN interconnection. It’s probably already being used in your company, and mastering it will give you a lot of bonuses. Take care and the best of luck to you!
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox