Data Link Connection Identifiers (DLCIs): Frame Relay virtual circuits (PVCs) are identified by DLCIs. A Frame Relay service provider, such as the telephone company, typically assigns DLCI values, which are used by Frame Relay to distinguish between different virtual circuits on the network. Because many virtual circuits can be terminated on one multipoint Frame Relay interface, many DLCIs are often affiliated with it. For the IP devices at each end of a virtual circuit to communicate, their IP addresses need to be mapped to DLCIs. This mapping can function as a multipoint device—one that can identify to the Frame Relay network the appropriate destination virtual circuit for each packet that is sent over the single physical interface. The mappings can be done dynamically through IARP or manually through the Frame Relay map command.
Frame Relay uses DLCIs the same way that X.25 uses X.121 addresses, and every DLCI number can be given either global or local meaning everywhere within the Frame Relay network. Sometimes a provider can give a site a DLCI that is advertised to all remote sites as the same PVC. This PVC is said to have a global significance. For example, a corporate office might have a DLCI of 20. All remote sites would know that the corporate office is DLCI 20 and use this PVC to communicate to the corporate office. However, the customary implementation is to give each DLCI local meaning. What does this mean? It means that DLCI numbers do not necessarily need to be unique. Two DLCI numbers can be the same on different sides of a link because Frame Relay maps a local DLCI number to a virtual circuit on each interface of the switch. Each remote office can have its own DLCI number and communicate with the corporate office using unique DLCI numbers. DLCI numbers, used to identify a PVC, are typically assigned by the provider and start at 16. Configuring a DLCI number to be applied to an interface is shown below:
The Local Management Interface (LMI) was developed in 1990 by Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation and became known as the Gang-of-Four LMI or Cisco LMI. This gang took the basic Frame Relay protocol from the CCIT and added extensions onto the protocol features that allow internetworking devices to communicate easily with a Frame Relay network.
The LMI is a signaling standard between a CPE device (router) and a frame switch. The LMI is responsible for managing and maintaining status between these devices. LMI messages provide information about the following:
If you’re not going to use the auto-sense feature, you’ll need to check with your Frame Relay provider to find out which type to use instead. The default type is Cisco, but you may need to hange to ANSI or Q.933A. The three different LMI types are depicted in the router output below.
As seen in the output, all three standard LMI signaling formats are supported:
Cisco LMI defined by the Gang of Four (default)
ANSI Annex D defined by ANSI standard T1.617
ITU-T (q933a) Annex A defined by Q.933
Routers receive LMI information on a frame-encapsulated interface and update the virtual circuit status to one of three different states: Active state Everything is up and routers can exchange information.
Inactive state The router’s interface is up and working with a connection to the switching office, but the remote router is not working.
Deleted state This means that no LMI information is being received on the interface from the switch. It could be a mapping problem or a line failure.
Partial Meshed Networks
You can use subinterfaces to mitigate partial meshed Frame Relay networks and split horizon protocols. For example, say you were running the IP protocol on a LAN network. If, on the same physical network, Router A can talk to Router B, and Router B to Router C, you can usually assume that Router A can talk to Router C. Though this is true with a LAN, it’s not true with a
Frame Relay network, unless Router A has a PVC to Router C. In Figure 5, Network 1 is configured with five locations. To be able to make this network function, you would have to create a meshed network as shown in Network 2. However, even though Network 2’s example works, it’s an expensive solution—configuring subinterfaces as shown in the Network 3 solution is much more cost-effective.
In Network 3, configuring subinterfaces actually works to subdivide the Frame Relay network into smaller subnetworks—each with its own network number. So locations A, B, and C connect to a fully meshed network, while locations C and D, and D and E, are connected via point-to-point connections.
Locations C and D connect to two subinterfaces and forward packets. Subinterfaces also solve the problem with routing protocols that use split horizon. As you may recall, split horizon protocols do not advertise routes out the same interface they received the route update on. This can cause a problem on a meshed Frame Relay network. However, by using subinterfaces, routing protocols that receive route updates on one subinterface can send out the same route update on another subinterface.
Frame Relay uses DLCIs the same way that X.25 uses X.121 addresses, and every DLCI number can be given either global or local meaning everywhere within the Frame Relay network. Sometimes a provider can give a site a DLCI that is advertised to all remote sites as the same PVC. This PVC is said to have a global significance. For example, a corporate office might have a DLCI of 20. All remote sites would know that the corporate office is DLCI 20 and use this PVC to communicate to the corporate office. However, the customary implementation is to give each DLCI local meaning. What does this mean? It means that DLCI numbers do not necessarily need to be unique. Two DLCI numbers can be the same on different sides of a link because Frame Relay maps a local DLCI number to a virtual circuit on each interface of the switch. Each remote office can have its own DLCI number and communicate with the corporate office using unique DLCI numbers. DLCI numbers, used to identify a PVC, are typically assigned by the provider and start at 16. Configuring a DLCI number to be applied to an interface is shown below:
RouterA(config-if)#frame-relay interface-dlci ?Local Management Interface (LMI)
<16-1007> Define a DLCI as part of the current
subinterface
RouterA(config-if)#frame-relay interface-dlci 16
The Local Management Interface (LMI) was developed in 1990 by Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation and became known as the Gang-of-Four LMI or Cisco LMI. This gang took the basic Frame Relay protocol from the CCIT and added extensions onto the protocol features that allow internetworking devices to communicate easily with a Frame Relay network.
The LMI is a signaling standard between a CPE device (router) and a frame switch. The LMI is responsible for managing and maintaining status between these devices. LMI messages provide information about the following:
Keepalives Verify data is flowing
Multicasting Provides a local DLCI PVC
Multicast addressing Provides global significance
Status of virtual circuits Provides DLCI status
If you’re not going to use the auto-sense feature, you’ll need to check with your Frame Relay provider to find out which type to use instead. The default type is Cisco, but you may need to hange to ANSI or Q.933A. The three different LMI types are depicted in the router output below.
RouterA(config-if)#frame-relay lmi-type ?
cisco
ansi q933a
As seen in the output, all three standard LMI signaling formats are supported:
Cisco LMI defined by the Gang of Four (default)
ANSI Annex D defined by ANSI standard T1.617
ITU-T (q933a) Annex A defined by Q.933
Routers receive LMI information on a frame-encapsulated interface and update the virtual circuit status to one of three different states: Active state Everything is up and routers can exchange information.
Inactive state The router’s interface is up and working with a connection to the switching office, but the remote router is not working.
Deleted state This means that no LMI information is being received on the interface from the switch. It could be a mapping problem or a line failure.
Partial Meshed Networks
You can use subinterfaces to mitigate partial meshed Frame Relay networks and split horizon protocols. For example, say you were running the IP protocol on a LAN network. If, on the same physical network, Router A can talk to Router B, and Router B to Router C, you can usually assume that Router A can talk to Router C. Though this is true with a LAN, it’s not true with a
Frame Relay network, unless Router A has a PVC to Router C. In Figure 5, Network 1 is configured with five locations. To be able to make this network function, you would have to create a meshed network as shown in Network 2. However, even though Network 2’s example works, it’s an expensive solution—configuring subinterfaces as shown in the Network 3 solution is much more cost-effective.
In Network 3, configuring subinterfaces actually works to subdivide the Frame Relay network into smaller subnetworks—each with its own network number. So locations A, B, and C connect to a fully meshed network, while locations C and D, and D and E, are connected via point-to-point connections.
Locations C and D connect to two subinterfaces and forward packets. Subinterfaces also solve the problem with routing protocols that use split horizon. As you may recall, split horizon protocols do not advertise routes out the same interface they received the route update on. This can cause a problem on a meshed Frame Relay network. However, by using subinterfaces, routing protocols that receive route updates on one subinterface can send out the same route update on another subinterface.
Creating Subinterfaces
You define subinterfaces with the int s0.subinterface number command as shown below. You first set the encapsulation on the serial interface, then you can define the subinterfaces.
RouterA(config)#int s0
RouterA(config)#encapsulation frame-relay
RouterA(config)#int s0.?
<0-4294967295> Serial interface number
RouterA(config)#int s0.16 ?
multipoint Treat as a multipoint link
point-to-point Treat as a point-to-point link
You can define an almost limitless number of subinterfaces on a given physical interface (keeping router memory in mind). In the above example, we chose to use subinterface 16 because that represents the DLCI number assigned to that interface. However, you can choose any number between 0 and 4,292,967,295.
There are two types of subinterfaces: Point-to-point Used when a single virtual circuit connects one router to another. Each point-to-point subinterface requires its own subnet.
Multipoint Used when the router is the center of a star of virtual circuits. Uses a single subnet for all routers’ serial interfaces connected to the frame switch.
An example of a production router running multiple subinterfaces is shown below. Notice that the subinterface number matches the DLCI number. This is not a requirement but helps in the administration of the interfaces.
Also notice that there is no LMI type defined, which means they are running either the default of Cisco or using autodetect if running Cisco IOS version 11.2 or newer. This configuration was taken from one of my customers’ production routers (used by permission). Notice that each interface is defined as a separate subnet, separate IPX network, and separate Apple-Talk cable range (AppleTalk is beyond the scope of this course):
interface Serial0Mapping Frame Relay
no ip address
no ip directed-broadcast
encapsulation frame-relay
!
interface Serial0.102 point-to-point
ip address 10.1.12.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 12-12 12.65
appletalk zone wan2
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 12
frame-relay interface-dlci 102
!
interface Serial0.103 point-to-point
ip address 10.1.13.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 13-13 13.174
appletalk zone wan3
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 13
frame-relay interface-dlci 103
!
interface Serial0.104 point-to-point
ip address 10.1.14.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 14-14 14.131
appletalk zone wan4
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 14
frame-relay interface-dlci 104
!
interface Serial0.105 point-to-point
ip address 10.1.15.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 15-15 15.184
appletalk zone wan5
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 15
frame-relay interface-dlci 105
!
interface Serial0.106 point-to-point
ip address 10.1.16.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 16-16 16.28
appletalk zone wan6
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 16
frame-relay interface-dlci 106
!
interface Serial0.107 point-to-point
ip address 10.1.17.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 17-17 17.223
appletalk zone wan7
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 17
frame-relay interface-dlci 107
!
interface Serial0.108 point-to-point
ip address 10.1.18.1 255.255.255.0
no ip directed-broadcast
appletalk cable-range 18-18 18.43
appletalk zone wan8
appletalk protocol eigrp
no appletalk protocol rtmp
ipx network 18
frame-relay interface-dlci 108
As we explained earlier, in order for IP devices at the ends of virtual circuits
to communicate, their addresses must be mapped to the DLCIs. There are
two ways to make this mapping happen:
* Use the Frame Relay map command.
* Use the inverse-arp function.
Here’s an example using the Frame Relay map command:
RouterA(config)#int s0Here’s what we did: First, we chose configured interface serial 0 to use the encapsulation type of Cisco (default), then we created our subinterface. We then turned off inverse arp and mapped three virtual circuits and their corresponding DLCI numbers.
RouterA(config-if)#encap frame
RouterA(config-if)#int s0.16 point-to-point
RouterA(config-if)#no inverse-arp
RouterA(config-if)#ip address 172.16.30.1 255.255.255.0
RouterA(config-if)#frame-relay map ip 172.16.30.17 16 ietf
broadcast
RouterA(config-if)#frame-relay map ip 172.16.30.18 17
broadcast
RouterA(config-if)#frame-relay map ip 172.16.30.19 18
Notice that we changed the encapsulation type for the first mapping. The frame map command is the only way to configure multiple frame encapsulation types on an interface. The broadcast keyword at the end of the map command tells the router to forward broadcasts for this interface to this specific virtual circuit.
Remember that Frame Relay is a nonbroadcast multiaccess (NBMA) encapsulation method, which will not broadcast routing protocols. You can either use the map command with the broadcast keyword or the neighbor command within the routing process. Instead of putting in map commands for each virtual circuit, you can use the inverse-arp function to perform dynamic mapping of the IP address to the DLCI number. This makes our configuration look like this:
RouterA(config)#int s0.16 point-to-pointYes, this configuration is a whole lot easier to do, but it’s not as stable as using the map command. Why? Sometimes, when using the inverse-arp function, configuration errors occur because virtual circuits can be insidiously and dynamically mapped to unknown devices.
RouterA(config-if)#encap frame-relay ietf
RouterA(config-if)#ip address 172.16.30.1 255.255.255.0
Frame Relay Congestion Control
In this section we will define how the Frame Relay switch handles Congestion problems.
DE (Discard Eligibility) When a Frame Relay router detects congestion on the Frame Relay network, it will turn the DE bit on in a Frame Relay packet header. If the switch is congested, the Frame Relay switch will discard the packets with the DE bit set first. If your bandwidth is configured with a CIR of zero, the DE will always be on.
FECN (Forward-Explicit Congestion Notification) When the Frame Relay network recognizes congestion in the cloud, the switch will set the FECN bit to 1 in a Frame Relay packet header. This will indicate to the destination DCE that the path just traversed is congested. BECN (Backward-Explicit Congestion Notification) When the switch detects congestion in the Frame Relay network, it will set the BECN bit in a Frame Relay packet and send it to the source router, telling it to slow down the rate at which it is transmitting packets. Committed Information Rate (CIR)
Frame Relay provides a packet-switched network to many different customers at the same time. This is a great idea because it spreads the cost of the switches among many customers. However, Frame Relay is based on the assumption that not all customers need to transmit constant data all at the same time. Frame Relay works best with bursty traffic. Think of Frame Relay as a party line. Remember party lines? That is when many people on your block had to share the same phone number. Okay, I am showing my age here, but understand that party lines were created on the assumption that few people needed to use the phone each day. If you needed to talk excessively, you had to pay for the more expensive dedicated circuit. Frame Relay works somewhat on the same principle, except many devices can transmit at the same time. However, if you need a constant data-stream connection, then Frame Relay is not for you. Buy a dedicated, point-to-point T-1 instead.
Frame Relay works by providing a dedicated bandwidth to each user, who is committed to that bandwidth at any given time. Frame Relay providers allow customers to buy a lower amount of bandwidth than what they really might need. This is called the Committed Information Rate (CIR). What this means is that the customer can buy bandwidth of, for example, 256k, but it is possible to burst up to T-1 speeds. The CIR specifies that as long as the data input by a device to the Frame Relay network is below or equal to the CIR, then the network will continue to forward data for the PVC. However, if data rates exceed the CIR, it is not guaranteed.
It is sometimes possible to also purchase a Bc (Committed Burst), which allows customers to exceed their CIR for a specified amount of time. In this situation, the DE bit will always be set. Choose a CIR based on realistic, anticipated traffic rates. Some Frame Relay providers allow you to purchase a CIR of zero. You can use a zero CIR to save money if retransmission of packets is acceptable. However, understand that the DE bit will always be turned on in every frame.
Monitoring Frame Relay
There are several ways to check the status of your interfaces and PVCs once you have Frame Relay encapsulation set up and running:
RouterA>sho frame ?
ip show frame relay IP statistics
lmi show frame relay lmi statistics map Frame-Relay map table
pvc show frame relay pvc statistics
route show frame relay route
traffic Frame-Relay protocol statistics
Show Frame-Relay Lmi
The show frame-relay lmi command will give you the LMI traffic statistics exchanged between the local router and the Frame Relay switch.
Router#sh frame lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) 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. Sent 0 Num Status msgs Rcvd 0
Num Update Status Rcvd 0 Num Status Timeouts 0
Router#
The router output from the show frame-relay lmi command shows you LMI errors as well as the LMI type.
Show Frame-Relay Pvc
The show frame pvc command will list all configured PVCs and DLCI numbers.
It provides the status of each PVC connection and traffic statistics. It
will also give you the number of BECN and FECN packets received on the
router.
RouterA#sho frame pvcTo see information about only PVC 16, you can type the command show frame-relay pvc 16.
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 16,DLCI USAGE = LOCAL,PVC STATUS =ACTIVE,INTERFACE
= Serial0.1
input pkts 50977876 output pkts 41822892 in bytes
3137403144
out bytes 3408047602 dropped pkts 5 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 9393 out DE pkts 0
pvc create time 7w3d, last time pvc status changed 7w3d
DLCI = 18,DLCI USAGE =LOCAL,PVC STATUS =ACTIVE,INTERFACE =
Serial0.3
input pkts 30572401 output pkts 31139837 in bytes
1797291100
out bytes 3227181474 dropped pkts 5 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 28 out DE pkts 0
pvc create time 7w3d, last time pvc status changed 7w3d
Show Interface : We can also use the show interface command to check for LMI traffic.
The show interface command displays information about the encapsulation as well as layer-2 and layer-3 information.
The LMI DLCI, as bolded in the command, is used to define the type of
LMI being used. If it is 1023, it is the default LMI type of Cisco. If the LMI
DLCI is zero, then it is the ANSI LMI type.
RouterA#sho int s0The show interface command displays line, protocol, DLCI, and LMI information.
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/
255, load 2/255
Encapsulation FRAME-RELAY, loopback not set, keepalive
set (10 sec)
LMI enq sent 451751,LMI stat recvd 451750,LMI upd recvd
164,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
Broadcast queue 0/64, broadcasts sent/dropped 0/0,
interface broadcasts 839294
Show Frame Map: The show frame map command will show you the Network layer–to–DLCI
mappings.
RouterB#show frame mapNotice that the search interface has two mappings, one for IP and one for IPX. Also, notice that the Network layer addresses were resolved with the dynamic protocol Inverse ARP (IARP). If an administrator mapped the addresses, the output would say “static.”
Serial0 (up): ipx 20.0007.7842.3575 dlci 16(0x10,0x400),
dynamic, broadcast,, status defined, active
Serial0 (up): ip 172.16.20.1 dlci 16(0x10,0x400),
dynamic,
broadcast,, status defined, active
Serial1 (up): ipx 40.0007.7842.153a dlci 17(0x11,0x410),
dynamic, broadcast,, status defined, active
Serial1 (up): ip 172.16.40.2 dlci 17(0x11,0x410),
dynamic,
broadcast,, status defined, active
After the DLCI number is listed, you can see some numbers in parentheses. Notice the first number is 0x10, which is the hex equivalent for the DLCI number 16 used on serial 0, and the 0x11 is the hex for DLCI 17 used on serial 1. The second numbers, 0x400 and 0x410, are the DLCI numbers configured in the Frame Relay frame. They are different because of the way the
bits are spread out in the frame.
Debug Frame Lmi: The debug frame lmi command will show output on the router consoles by default. The information from this command will allow you to verify and troubleshoot the Frame Relay connection by helping you to determine whether the router and switch are exchanging the correct LMI information.
Router#debug frame-relay lmi
Serial3/1(in): Status, myseq 214
RT IE 1, length 1, type 0
KA IE 3, length 2, yourseq 214, myseq 214
PVC IE 0x7 , length 0x6 , dlci 130, status 0x2 , bw 0
Serial3/1(out): StEnq, myseq 215, yourseen 214, DTE up
datagramstart = 0x1959DF4, datagramsize = 13
FR encap = 0xFCF10309
00 75 01 01 01 03 02 D7 D6
Serial3/1(in): Status, myseq 215
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 215, myseq 215
Serial3/1(out): StEnq, myseq 216, yourseen 215, DTE up
datagramstart = 0x1959DF4, datagramsize = 13
FR encap = 0xFCF10309
00 75 01 01 01 03 02 D8 D7