Category: Frame Relay

There are a variety of commands available for the purpose of monitoring Frame Relay on Cisco routers. Some of the commands that you should be familiar with include:

• show frame-relay lmi. This command provides detailed statistics on LMI traffic passed between a router and its local Frame Relay switch, as well the LMI type is use.
• show frame-relay map. This command shows a listing of the Network layer address to DLCI mappings defined on a router, along with their current status.
• show frame-relay pvc. This command provides a listing of all PVCs configured on the router, and their associated local DLCI numbers. The command also provides traffic statistics, such as the number of frames sent, received, dropped, marked discard eligible, or with their FECN or BECN bit set.
• show interface. This familiar command provides general interface data such as the encapsulation type in use, as well as information relating to LMI.

Having looked at both Frame Relay concepts and an example of the communication process, let’s take a look at configuring a Cisco router to use Frame Relay. Our network in this example is configured as illustrated in the figure below. Notice that the PVC between Chicago and Toronto is a point-to-point interface, while the PVCs between Chicago and San Jose, as well as Chicago and Miami are part of a multipoint configuration. Your goal is to properly configure Frame Relay on the Chicago router.

Figure: Frame Relay network used in configuration example.

You’ll begin by configuring settings on the Chicago router’s S0 interface. This includes the encapsulation method to be used, as well as the LMI type. After these steps are complete, you will configure two subinterfaces, one for DLCI 88 (the PVC to Toronto), and one other for DLCIs 92 and 107 (the PVCs to Miami and San Jose respectively).

Chicago#config t
Enter configuration commands, one per line. End with CNTL/Z.
Chicago(config)#int s0
Chicago(config-if)#encapsulation ?
atm-dxi ATM-DXI encapsulation
frame-relay Frame Relay networks
hdlc Serial HDLC synchronous
lapb LAPB (X.25 Level 2)
ppp Point-to-Point protocol
smds Switched Megabit Data Service (SMDS)
x25 X.25
Chicago(config-if)#encapsulation frame-relay ?
ietf Use RFC1490/RFC2427 encapsulation
Chicago(config-if)#encapsulation frame-relay
Chicago(config-if)#frame-relay lmi-type ?
cisco
ansi
q933a
Chicago(config-if)#frame-relay lmi-type cisco
Chicago(config-if)#exit

By default, the encapsulation method used on a Frame Relay interface will be Cisco, unless IETF is specified. Recall that it isn’t usually necessary to specify an LMI type, since the interfaces will auto-sense the LMI type in use by the local Frame Relay switch as of IOS version 11.2.

With the basic interface settings completed, you can move on to the configuration of the subinterfaces. You’ll begin with the subinterface that will be used to connect to the Toronto office, S0.88. This link represents a point-to-point connection, as shown below.

Chicago(config)#int s0.88 ?
multipoint Treat as a multipoint link
point-to-point Treat as a point-to-point link
Chicago(config)#int s0.88 point-to-point

Your next step involves configuring an IP address on subinterface S0.88, as well as its DLCI number.

Chicago(config-subif)#ip address 192.168.100.1 255.255.255.0
Chicago(config-subif)#frame-relay interface-dlci 88

At this point, configuration of a point-to-point Frame Relay interface on the Chicago router is complete. Of course, communication will not be possible until the Toronto router is also configured, and the no shutdown command is issued on interface S0. DLCI to IP address mappings are not configured on point-to-point Frame Relay interfaces, since only one other possible communication endpoint exists on the virtual circuit.

The configuration of multipoint interfaces is slightly different, and is the reason why I included both types in this example. The encapsulation method and LMI type have already been specified on interface S0, so there is no need to issue them again (remember that subinterfaces inherit settings from their “parent” interface). Because the connection between Chicago, Miami, and San Jose is multipoint (a single subnet), you can configure both virtual circuits on a single subinterface. You’ll use the DLCI number for the PVC to Miami as our subinterface number, if for no other reason than the fact that it’s the lower of the two.

Chicago(config)#int s0.92 ?
multipoint Treat as a multipoint link
point-to-point Treat as a point-to-point link
Chicago(config)#int s0.92 multipoint
Chicago(config-subif)#ip address 192.168.200.1 255.255.255.0
Chicago(config-subif)#frame-relay interface-dlci 92
Chicago(config-fr-dlci)#exit
Chicago(config-subif)#frame-relay interface-dlci 107
Chicago(config-fr-dlci)#exit

Communication over a multipoint interface requires that you somehow map remote IP addresses to the local DLCI number of the corresponding virtual circuit. By default, a multipoint interface will automatically map this pairing of information using inverse ARP. However, it is also possible (and generally recommended) to create static mappings. This is accomplished using the frame-relay map command, as outlined below.

Chicago(config-subif)#frame-relay map ip 192.168.200.2 92 broadcast
Chicago(config-subif)#frame-relay map ip 192.168.200.3 107 broadcast

If you take a closer look at the commands above, you’ll notice that they create a mapping between the IP address of the remote router and the local DLCI number of the appropriate virtual circuit. When the Chicago router needs to reach address 192.168.200.2 (the Miami office), it now knows that frames must be assigned to the virtual circuit identified by DLCI 92. When traffic needs to reach address 192.168.200.3 (the San Jose office), the virtual circuit identified by DLCI 107 should be used. You may have also noticed the use of the broadcast keyword at the end of the frame-relay map commands. The broadcast keyword tells the router to forward broadcasts (like routing protocol updates) across the PVC as required. This is necessary because by default, Frame Relay networks are non-broadcast multi-access (NBMA). As such, they would not forward routing table updates from broadcast-based protocols like RIP or IGRP without the broadcast keyword configured. For practical purposes, it’s worth noting that broadcasts will be forwarded across point-to-point Frame Relay interfaces by default as of IOS 11.1

Now that you’ve taken a look at the key concepts associated with Frame Relay, let’s take a look at an example of how communication occurs across a Frame relay network. I am going to assume that the network is configured as shown in the figure below, and that Computer1 at the New Orleans location ultimately wants to communicate with Server3 in the Austin office. Both PVCs are configured as point-to-point links.

Figure: Example network used to describe the communication process across a Frame Relay WAN.

The steps below outline how an IP packet from Computer 1 will ultimately reach Server 3.

1. Through the ANDing process, Computer 1 will recognize that Server 3 is on a remote network. As such will ARP for the MAC address of its default gateway, interface E0 on the New Orleans router. The IP packet will be framed for Ethernet and sent to the router’s E0 interface.
2. After receiving the Ethernet frame, the New Orleans router will calculate the CRC to ensure it is not corrupt, strip off the header, and will pass the packet up to the Network layer. At this point, it will look in its routing table to see where it should forward the packet next. In this case, the destination would be 192.168.100.1, the router at the Chicago office.
3. Before forwarding the packet, the New Orleans router will obviously need to reframe it to travel over the Frame Relay network. In order to do this, it must identify the DLCI of the virtual circuit that connects to the Chicago location. Let’s assume that the router is configured correctly, and knows address 192.168.100.1 is accessible via DLCI 10. The router will reframe the packet, and forward it out sub-interface S0.10.
4. Ultimately, this frame will reach the switching equipment of the service provider. Because DLCIs are usually only locally significant, the DLCI number in the frame header may, in fact, be changed many times as it moves between the switching equipment of the service provider. You can’t tell for certain which mappings the provider uses to identify the virtual circuit within its own network. However, you do know that upon exiting the last switch before the Chicago router, its DLCI value should be set to 13, as per Figure 22.
5. Upon reaching the Chicago router’s S0.13 interface, the frame’s CRC will be recalculated, the framing striped off, and the packed will be passed to the Network layer. At this point, the Chicago router will consult its routing table, look at the destination address, and will determine that the packets destined for network 192.168.3.0/24 should be forwarded to address 192.168.200.2. I will again assume that the router is configured correctly, and knows that address 192.168.200.2 is accessible via DLCI 73. The router will reframe the packet, and forward it out subinterface S0.73.
6. This frame will also traverse the provider’s Frame Relay network through a variety of switches, where the DLCI information stored in the frame header may again change many times. Again, the final DLCI number in the header once it reaches the Austin router should be 75, as per our diagram.
7. Upon reaching the Austin router’s S0.75 interface, the frame’s CRC will be recalculated, the framing will be stripped away, and the packet will be passed to the Network layer. At this point, the router will search for the destination network address is its routing table, and will determine that the packet should be forwarded out interface E0. The router will ARP for the MAC address associated with Server C (if the MAC address is not already stored in its ARP cache), and once obtained, will reframe the packet for Ethernet and forward it out interface E0.
8. Upon receiving the Ethernet frame, Server C will identify the MAC address as its own, recalculate the CRC, strip off the framing, and then pass the packet up to the Network layer for further processing.

Obviously there are many steps involved when Computer 1 wishes to communicate with Server 3. You may be asking yourself why the company doesn’t simply add another PVC between the New Orleans and Austin offices. While entirely valid, the need for another PVC would largely depend on the volume of data that would be passed between these two offices regularly. Don’t forget that provisioning another PVC would incur additional costs, which may or may not be justifiable. In most cases, companies will configure PVCs between a branch office and a central location, rather than between branch offices directly. However, additional PVCs connecting locations (forming a mesh) does provide an additional degree of fault tolerance.

Back in the CIR section of this chapter, you looked at how the discard eligibility (DE) bit is used to “mark” frames that are transmitted above the CIR on a Frame relay virtual circuit. Making certain frames discard-eligible provides a way to determine which frames should be discarded first if a Frame Relay switch is experiencing congestion. However, Frame Relay also uses two additional techniques to help make end devices aware of congestion on the Frame Relay network – Forward Explicit Congestion Notification (FECN) and Backwards Explicit Congestion Notification (BECN).

• FECN. If a Frame Relay switch is experiencing congestion, it will set what is known as the FECN bit in the Frame Relay header. This bit is used to notify the receiving device that the network is experiencing congestion and that it should expect some delay in the receipt of frames. Ultimately, this information should be passed to higher-layer protocols for processing.
• BECN. By the same token, a switch experiencing congestion will also set the BECN bit in frames that are being sent back to the original sender. BECN alerts the sender to a congestion situation, effectively letting the sender known that it should throttle back the rate at which it sends data. In the same way, this information should be passed to higher-layer protocols for processing.

Back in Chapter 7 you looked at the concept of subinterface. Subinterfaces allow you to configure a single physical interface in such a way that it can act as multiple interfaces, each of which can have different properties. When configuring Frame Relay on a router, each virtual circuit is usually assigned to its own serial subinterface. This not only allows multiple virtual circuits to function across a single physical interface, but also allows the properties of each subinterface to be configured individually.

As an example, consider the figure below. In it, a company has one head office and three branch locations. Each of the branch offices connects to the head office location using a dedicated PVC. Router interface S0 at the head office is divided into 3 subinterfaces, each of which would be configured with an appropriate IP address and its associated DLCI number. In order to simplify the management of subinterfaces (and make things easier to remember), subinterfaces are usually given a number that maps directly to a PVC’s DLCI number. This is not a requirement, but rather an easy way to keep track of which PVC is associated with a given subinterface. For example, DLCI 23 at the head office would be configured on subinterface S0.23.

Figure: Subinterface numbers that correspond to DLCI values simplify subinterface management.

In order for a Frame Relay network to function correctly, interfaces will still need to be configured according to a logical addressing scheme. I’m going to assume that our network runs only IP in this example, but it could be running other Network layer protocols like IPX or AppleTalk as well. The issue at hand is how logical addressing should take place over the Frame Relay network. For example, each PVC could be treated as a point-to-point network and, as such, would require its own IP subnet. However, if multiple PVCs are connected into a single router in a hub-and-spoke type configuration, it’s also possible to configure the connections as a single subnet instead – this configuration is known as multipoint. Point-to-point connections are generally more common when connecting locations by Frame Relay, but either configuration is valid. Both are illustrated in the figure below.

Figure: PVCs connecting locations can be made part of either point-to-point or multipoint links.

Another important reason for the use of subinterfaces on a Frame Relay network relates to issues associated with distance vector routing protocols. If you’ll recall, split horizon prevents a router from sending routing table updates that were received on a given interface back out the same interface. As such, if you had the multipoint configuration shown in the figure below, where the head office location does not use subinterfaces, routing table updates from Router B could never reach Router C or vice versa. Quite simply, Router A would not be allowed to forward updates received from B to C over the same interface.

Figure: Without the use of subinterfaces, routing table updates from Router B could never reach Router C via Router A because of split horizon rules.

This is not an issue when subinterfaces are used, since the routing protocol will consider subinterfaces as distinct and separate. If subinterfaces were used on Router A in Figure 21, routing table updates could pass between all three routers via Router A without issue.

The Local Management Interface (LMI) is a set of extensions to the Frame Relay protocol that were designed to provide information about the status of Frame Relay networks, and extend the technology’s capabilities. LMI is primarily concerned with diagnostic functions. For example, LMI is used to send keepalive messages between a router and a Frame Relay switch. These messages verify the status of PVCs, and help to ensure that data can be transferred between Frame Relay DTE and DCE equipment. The LMI extensions also allow DLCI values to be made globally significant, and bring multicast capabilities to Frame Relay networks.

Both ANSI and the ITU-T have also developed LMI standards. As of IOS version 11.2, a Cisco router interface using Frame Relay encapsulation will auto-sense the LMI type used by a Frame Relay switch. However, it is still possible to configure the LMI type manually. The three different LMI types supported on a Frame Relay interface include:

• Cisco. This is the “Group of Four” LMI type, and is the default used on Frame Relay interfaces prior to IOS version 11.2. It uses DLCI 1023 to exchange status information.
• ANSI. This is the LMI type defined by ANSI. It uses DLCI 0 to exchange status information.
• Q.933a. This is the LMI type defined by the ITU-T. It uses DLCI 0 to exchange status information.

A router and its local Frame Relay switch must be using the same LMI type in order for diagnostic messages to be passed between them.

In order for upper-layer data to be transmitted across a Frame Relay network, it obviously needs to be framed. Cisco routers support two different Frame Relay encapsulation types, known as Cisco and IETF. By default, a Cisco router will use Cisco encapsulation on Frame Relay interfaces, unless IETF is explicitly specified. IETF encapsulation is usually used when connecting both Cisco and non-Cisco devices across a Frame Relay network. However, another issue at hand is the framing method in use by your service provider. As a general rule, it’s always a good idea to obtain this information before beginning the configuration process.

In order to ensure that data reaches its proper destination through a packet-switched network, virtual circuits somehow need to be identified. On a Frame relay network, virtual circuits are identified using what are known as Data Link Connection Identifiers (DLCIs).
A DLCI is a 10-bit number that is stored in the header of a frame that traverses a Frame Relay network. DLCI numbers are issued by the service provider and uniquely identify a virtual circuit. These numbers are said to be only locally significant, in that they may not be the same (or consistent) throughout a Frame Relay network. This concept can be confusing and is best illustrated with an example.

Imagine that you were to provision a Frame Relay PVC between two locations from a service provider. The provider would issue two DLCI numbers – one for each location. While these numbers could be the same, there is no guarantee that will be the case, and it doesn’t really matter anyhow. The DLCI number is only used to ensure that the provider’s switching equipment can properly identify the customer’s virtual circuit at any point in the network. So, although your virtual circuit (VC) may be identified as DLCI 99 between your Toronto router and the first Frame Relay switch it encounters, intermediate switches may use different DLCI numbers to identify the same virtual circuit. At each switch, the DLCI stored in the header will be translated if necessary. As such, the very same virtual circuit may be identified using DLCI 101 at the New York office. In this way, the DLCI value stored in the header is only locally significant. This is illustrated in the figure below.

Figure: A single PVC is usually identified by different DLCI numbers across a Frame Relay network.

While less common, it is also possible for DLCI numbers to have global significance in a service provider’s network. When globally significant, each customer location would be identified by a single DLCI value. While this makes a Frame Relay network easier to manage, it also seriously limits the number of possible PVCs that can be configured.
Because a DLCI number is a 10-bit value, up to 1024 (210) DLCI numbers (0-1023) can be used to identify virtual circuits. However, some of these numbers are reserved for management functions. On a Cisco router, up to 992 DLCIs can be defined, ranging from DLCI 16 up to 1007.

When a company provisions a leased line from a service provider, that link provides a fixed, dedicated amount of bandwidth. For example, a company might implement a dedicated 256 Kbps link between two locations. Things work a little bit differently in the world of Frame Relay. Instead of providing fixed bandwidth over a dedicated circuit, bandwidth is allocated using what is referred to as a Committed Information Rate (CIR).

A CIR is an average transmission capacity agreed upon for a virtual circuit that connects one company location to another. For example, a company may provision a circuit with a CIR of 64Kbps. What this means is that the company is basically guaranteed that they will always have at least 64 Kbps of bandwidth available to them. However, because the physical circuits of the Frame Relay network are shared amongst many subscribers, there will often be excess bandwidth available at any point in time. This allows a customer’s traffic to actually “burst” to higher speeds, as available network bandwidth permits. The speed to which data can burst is referred to as the Committed Burst Information Rate (CBIR). For example, a virtual circuit with a CIR of 64 Kbps may have a CBIR of 128 Kbps.

The fact that companies can potentially use more bandwidth than they have paid for makes Frame Relay an attractive option, but it obviously presents an issue. What would stop one company’s traffic from monopolizing available bandwidth? This issue is dealt with by designating certain frames “discard eligible” (DE). For example, let’s say that a company has paid for a CIR of 64Kbps. When sending data, all frames that are within this 64 K bandwidth allotment are sent out normally. However, once the CIR is met, any additional frames that need to be sent have a special bit (known as the DE bit) in their frame header set to 1. The DE bit marks the frame as eligible to be discarded, should the network be congested. This is illustrated in the figure below.

Figure: Frames sent at rates above the CIR will have their discard eligibility (DE) bit set.

Another benefit of Frame Relay is that CIRs need not necessarily be the same throughout a customer’s network. For example, a company may have two branch office locations connected to their head office, as illustrated in the figure below. In this example, the PVC between the Montreal branch office and the head office has a CIR of 64Kbps, while the PVC connecting the head office to the much smaller Utah office has a CIR of only 16Kbps. CIR values are usually made available in multiples as small as 4 or 8 Kbps. In fact, it is also possible to provision Frame Relay services with a CIR of 0 – while this connection would be valid; all frames sent over the PVC with this CIR would be marked discard eligible. In reality, many Frame Relay networks have enough excess capacity that a CIR of 0 is not necessarily a bad choice for connecting to small offices, or as an interim solution while a more reasonable CIR is being determined.

Figure: PVC connections across a Frame Relay network can have different CIRs.