Frame Relay has several built-in Quality of Service (QoS) features. Each virtual circuit has two important service level parameters, the Committed Information Rate (CIR) and the Excess Information Rate (EIR). The CIR is the contracted minimum throughput of a virtual circuit. As long as you send data at a rate that is less than the CIR value, it should all arrive. The EIR is the available capacity above the CIR. The worst case is when the router is sending data through a single virtual circuit at the line speed of the physical circuit. The network will generally just drop all packets that exceed the EIR, so it is customary to have the sum of CIR and EIR for each virtual circuit equal the line speed of the physical circuit. This makes it physically impossible to exceed the EIR for any PVC.

When the router sends packets faster than the CIR rate that you have contracted with your network provider, the carrier network may drop some or all of the excess packets if there is congestion in the cloud. To indicate which packets are in the excess region, the first switch to receive them will often mark the Discard Eligible (DE) bit in their Frame Relay headers. If there is no congestion, the packet will be delivered normally. But, if the packet goes through a congested part of the carrier’s network, the switches will know that they can drop this packet without violating the CIR commitments. By just counting the packets that have their DE bit set on the receiving router, you get a useful measure of how often your network exceeds the CIR on each PVC. Because your traffic patterns will probably not be symmetrical in most networks, you should monitor the number of DE packets received separately on both ends of every PVC.

By default, the router will send frames into the cloud without the DE bit set. What happens next is up to the carrier, but it is common for the first switch to monitor the incoming traffic rate using some variation of the following. During each sample period (typically a short period of time such as a second), the switch will count the incoming bytes on each PVC. If there is more data than the CIR for this PVC, the switch will mark the DE bit in all of the excess frames.

However, it is also possible to configure the router to set the DE bit on low priority traffic in the hopes that the network will drop these low priority packets in preference to the high priority packets. This is something of a gamble, of course, and its success depends critically on the precise algorithm that your WAN vendor uses for handling congestion. You should consult with your vendor to understand their traffic shaping and policing mechanisms before attempting this type of configuration.

There are two other extremely useful flags in the Frame Relay header. These are the Forward Explicit Congestion Notification (FECN) and the Backward Explicit Congestion Notification (BECN) bits. These simply indicate that the packet encountered congestion somewhere in the carrier’s network. Congestion is most serious when you are sending at a rate higher than the CIR value; if your carrier marks the DE bit of these excess packets, then congestion in one of their switches could mean dropped packets.

If a packet encounters congestion in a carrier switch, that switch will often set the FECN flag in the packet’s header. Then, when the other router finally receives this packet, it will know that it was delayed. But this is actually not all that useful, because the receiving router is not able to directly affect the rate that the sending router forwards packets along this virtual circuit. So the Frame Relay standard also includes the BECN flag.

When a switch encounters congestion and needs to set the FECN flag on a packet, it looks for another packet traversing the same PVC in the opposite direction, and marks it with a BECN flag. This way, the sending router immediately knows that the packets it is sending are encountering congestion.

Note, however, that not all Frame Relay switches implement these features in the same way. So, just because you don’t see any FECN or BECN frames doesn’t mean you can safely assume that there is no congestion. Similarly, not seeing DE frames doesn’t necessarily mean that you aren’t exceeding the CIR for a PVC. In Recipe 10.6, for example, we show how to configure a router to act as a Frame Relay switch. But the router does not implement these congestion notification features at all. The DE counter is also not a meaningful indicator of how often you exceed CIR if your devices are configured to send low priority frames with the DE bit set.

By default, the router will not react to FECN and BECN markings. Recipe 10.9 shows how you can look at statistics on FECN and BECN frames to get an idea of the network performance. In the next chapter, Recipe 11.11 shows how to configure a router to automatically adapt to congestion in the carrier network by reading and responding to the BECN flags, reducing the sending rate until the congestion disappears.

You want to configure Frame Relay services so that every PVC is assigned to a separate subinterface.

Probably the cleanest way to set up a Frame Relay network is to use point-to-point subinterfaces. If you have a host site that connects to two or more branches through a Frame Relay WAN, you could configure the central host router like this:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#description Frame-Relay host circuit
Central(config-if)#no ip address
Central(config-if)#encapsulation frame-relay
Central(config-if)#exit
Central(config)#interface Serial0.1 point-to-point
Central(config-subif)#description PVC to first branch - DLCI 101
Central(config-subif)#ip address 192.168.1.5 255.255.255.252
Central(config-subif)#frame-relay interface-dlci 101
Central(config-fr-dlci)#exit
Central(config-subif)#exit
Central(config)#interface Serial0.2 point-to-point
Central(config-subif)#description PVC to second branch - DLCI 102
Central(config-subif)#ip address 192.168.1.9 255.255.255.252
Central(config-subif)#frame-relay interface-dlci 102
Central(config-fr-dlci)#end
Central#

And all of the branches would follow the same basic configuration, but with different IP addresses and DLCI numbers:

Branch1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Branch1(config)#interface Serial0
Branch1(config-if)#description Frame-Relay circuit
Branch1(config-if)#no ip address
Branch1(config-if)#encapsulation frame-relay
Branch1(config-if)#exit
Branch1(config)#interface Serial0.1 point-to-point
Branch1(config-subif)#description PVC to Central host - DLCI 50
Branch1(config-subif)#ip address 192.168.1.6 255.255.255.252
Branch1(config-subif)#frame-relay interface-dlci 50
Branch1(config-fr-dlci)#end
Branch1#

In this example, we have assumed that all of the Frame Relay circuits connect to serial interfaces on the routers. This is normally the case, but there are other options. Frame Relay is usually delivered on low speed 56 or 64Kbps circuits, or fractional or full T1 or E1 circuits. However, there are useful Frame Relay implementations all the way up to T3 speeds. The most common way to deliver Frame Relay service faster than T1 or E1 speeds is on either a coax T3 or a High Speed Serial Interface (HSSI) connection.

In all cases, the router is the Data Terminal Equipment (DTE) device, and the Frame Relay switch in the carrier’s network is the Data Communications Equipment (DCE). Make sure that you have the right type of cable on your router, with a DTE connector.

While many carriers currently offer T3 Frame Relay service, very few Frame Relay switches are able to reliably switch packets along a single PVC much faster than T1 or E1 speeds. This means that a T3 or HSSI circuit makes an excellent aggregation point for a large number of branches with T1, E1, or slower circuits. However, you should talk it over very thoroughly with your WAN provider before attempting to build a Frame Relay network that requires CIR rates greater than a T1 or E1.

By default, the router will use a Cisco proprietary encapsulation format for the data payload of each packet. If you have to connect to non-Cisco equipment, you may prefer to use the open standard encapsulation format described in RFC 1490 instead. You can configure this either for each subinterface separately, or globally for the entire interface. To configure one subinterface to use RFC 1490 encapsulation, use the ietf keyword:

Central(config)#interface Serial0.1 point-to-point
Central(config-subif)#frame-relay interface-dlci 101 ietf
Central(config-fr-dlci)#end

You can make RFC 1490 encapsulation the default for all subinterfaces on an interface as follows:

Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay ietf
Central(config-if)#end

When you do this, you do not need to specify the ietf keyword on each subinterface. However, if you want to use to the Cisco encapsulation format on a particular PVC, you can do so with the cisco keyword:

Central(config)#interface Serial0.1 point-to-point
Central(config-subif)#frame-relay interface-dlci 101 cisco
Central(config-fr-dlci)#end

It is extremely important to specify the point-to-point keyword here. The problem is that you can’t change a subinterface type. If you specify the wrong type of subinterface, you must delete the incorrect one, then reboot the router before you can re-create it with the correct type. This was particularly serious in earlier IOS releases, because the default was multipoint, rather than point-to-point. In Version 12.0 and higher, there is no default, and you must explicitly specify either point-to-point or multipoint. We will discuss multipoint subinterfaces in Recipe 10.4.

The show frame-relay pvc command shows the status and several useful statistics for every PVC:

Central#show frame-relay pvc

PVC Statistics for interface Serial0 (Frame Relay DTE)

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

  input pkts 4092          output pkts 1331         in bytes 573274
  out bytes 364868         dropped pkts 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 1277       out bcast bytes 361391
  pvc create time 21:16:46, last time pvc status changed 21:16:46

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0.2

  input pkts 0             output pkts 2            in bytes 0
  out bytes 566            dropped pkts 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 2          out bcast bytes 566
  pvc create time 00:02:08, last time pvc status changed 00:01:15
Central#

In this case, two DLCIs are configured on the router. Only one of these is in an active state, while the other shows as DELETED, which means that it is not configured on the switch. This command will also show you if there are other PVCs configured in the Frame Relay switch, but not on the router. These DLCIs are easy to spot because the DLCI USAGE field is listed as UNUSED:

Central#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

  input pkts 11            output pkts 14           in bytes 2218
  out bytes 1825           dropped pkts 3           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 9          out bcast bytes 1305
  pvc create time 00:02:45, last time pvc status changed 00:02:24

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0.2

  input pkts 0             output pkts 2            in bytes 0
  out bytes 566            dropped pkts 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 2          out bcast bytes 566
  pvc create time 00:02:08, last time pvc status changed 00:01:15

DLCI = 103, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial0

  input pkts 0             output pkts 0            in bytes 0
  out bytes 0              dropped pkts 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            Num Pkts Switched 0
  pvc create time 00:00:08, last time pvc status changed 00:00:08
Central#

In this case, you can see that a new PVC with DLCI 103 was created on the switch eight seconds ago on the circuit that connects to the router’s Serial0 interface. This new PVC is not associated with a subinterface, and it is not passing any traffic.

The show interface command gives other useful information, particularly about the Local Management Interface (LMI) protocol:

Branch#show interface serial0
Serial0 is up, line protocol is up
  Hardware is HD64570
  Description: Frame-Relay circuit
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
  LMI enq sent  7932, LMI stat recvd 7932, 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
  Broadcast queue 0/64, broadcasts sent/dropped 1320/0, interface broadcasts 2
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 22:01:52
  Input queue: 0/75/0 (size/max/drops); 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)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     12481 packets input, 720402 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
     9579 packets output, 500221 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
Branch1#

LMI provides many of Frame Relay’s useful features (such as keepalives) that can tell a router when one or more PVCs become unavailable. This example shows CISCO type LMI, which uses DLCI number 1023. If we had specified the CCITT or ANSI LMI standards, the router would use DLCI number 0 for LMI. Recipe 10.2 shows how to configure these different LMI options.

When you enable Frame Relay on an interface, the router automatically activates the Inverse ARP protocol, which is described in RFC 1293. The router uses Inverse ARP to make a dynamic mapping between a Frame Relay DLCI number and a Layer 3 address. This Layer 3 address could be for any supported protocol such as IP, Apple-Talk, IPX, and so forth.

In this recipe, we built a static mapping between the DLCI number and the IP address, so we don’t actually need Inverse ARP. Each subinterface always associates a particular DLCI number with a particular Layer 3 address. This means that we can safely disable Inverse ARP. You can do this for an individual protocol as follows:

Central(config)#interface Serial0
Central(config-if)#no frame-relay inverse-arp ip

Or you can disable Inverse ARP globally for all protocols:

Central(config)#interface Serial0
Central(config-if)#no frame-relay inverse-arp

In this case, if you want to reenable Inverse ARP just for a particular protocol you can do so:

Central(config)#interface Serial0
Central(config-if)#frame-relay inverse-arp ipx 100

This tells the router that it should use Inverse ARP to discover the IPX address of the device on the other end of the virtual circuit with DLCI number 100. If you don’t need Inverse ARP, we generally recommend disabling it.

Recipe 10.2; Recipe 11.11

You want to configure different LMI options on your Frame Relay circuit.

There are several different LMI options. The first specifies which version of LMI protocol you wish to use:

Branch1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Branch1(config)#interface Serial0
Branch1(config-if)#encapsulation frame-relay
Branch1(config-if)#frame-relay lmi-type ansi
Branch1(config-if)#end
Branch1#

By default, LMI sends keepalive packets through every PVC every 10 seconds to verify that the path is still available. You can adjust this value with the keepalive command:

Branch1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Branch1(config)#interface Serial0
Branch1(config-if)#encapsulation frame-relay
Branch1(config-if)#keepalive 5
Branch1(config-if)#end
Branch1#

LMI is not supported on all networks. If this is the case in your network, you must configure the router to announce its own DLCI number with the local-dlci command:

Branch1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Branch1(config)#interface Serial0
Branch1(config-if)#encapsulation frame-relay
Branch1(config-if)#frame-relay local-dlci 50
Branch1(config-if)#end
Branch1#

The first example in this recipe sets an alternative LMI type. The default LMI type is called cisco on the router, although this is slightly confusing because it is not a Cisco proprietary standard, but rather was developed jointly by Cisco and other vendors. This default setting is usually the one you want, because it is the default setting in many Frame Relay switches.

The example shows how to set the ANSI standard LMI type:

Branch1(config-if)#frame-relay lmi-type ansi

Another LMI option, q933a, is also available. This option configures the router to use the Annex A of the ITU-T standard. This is sometimes called the CCITT LMI standard:

Branch1(config-if)#frame-relay lmi-type q933a

You must ensure that the LMI type you use matches what your carrier uses. It is not even necessary for all routers in the network to use the same LMI type, as long as each router matches the settings on its respective Frame Relay switch.

The second example sets the LMI keepalive time. Once again, this parameter depends on what is configured on the switch. In fact, as long as you use a keepalive setting that is less than the period on the switch, you should have no problems. In networks that do not use LMI, you should disable this polling:

Branch1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Branch1(config)#interface Serial0
Branch1(config-if)#encapsulation frame-relay
Branch1(config-if)#no keepalive
Branch1(config-if)#end
Branch1#

The last option defines a local DLCI:

Branch1(config-if)#frame-relay local-dlci 50

Here we have set the router’s serial interface to use DLCI number 50. This command is required only on networks that do not use LMI, but there is no harm in configuring it for networks that do use LMI. In fact, some network engineers opt to configure this statement on all of their Frame Relay circuits as a mnemonic to remind them of the DLCI numbers that other devices use to reach this circuit. However, if you use the local DLCI number for this purpose, you should not disable keepalives—LMI requires them.

You want to configure Frame Relay services so that every PVC appears to share the same interface.

In its simplest form, the Frame Relay map configuration involves considerably less typing than the subinterface version of the same configuration:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0
Central(config)#description Frame Relay to branches
Central(config-if)#ip address 192.168.1.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101
Central(config-if)#frame-relay map ip 192.168.1.11 102
Central(config-if)#frame-relay map ip 192.168.1.12 103
Central(config-if)#end
Central#

Instead of treating the Frame Relay WAN as a series of point-to-point logical connections as we did in Recipe 10.1, you can configure it to look similar to a LAN segment with a contiguous block of IP addresses. There are two ways to do this, either by using frame-relay map statements as in this recipe, or by using multipoint sub-interfaces as in Recipe 10.4. In general, we prefer to use point-to-point subinterfaces for Frame Relay networks because it gives you more detailed controls over the routing protocol.

Furthermore, when you use point-to-point subinterfaces, the router can generate a trap when a DLCI becomes inactive, which makes network management much easier. With multipoint subinterfaces, the router will generate a trap only when all of the associated DLCIs become unavailable, but not for individual failures. And when you use frame-relay map statements, the router will not provide any notification of DLCI failures. However, while the Frame Relay map method lacks some of the features of subinterfaces, it is still perfectly acceptable in less complicated networks.

The frame-relay map command has several useful options. In the example, we used the simplest version of the command:

Central(config-if)#frame-relay map ip 192.168.1.10 101

This associates the IP address 192.168.1.10 with DLCI number 101. If you have other protocols, such as IPX or AppleTalk, you must configure them separately:

Central(config-if)#frame-relay map ipx 10AF.0.0.1 101
Central(config-if)#frame-relay map appletalk 1.15 101

The configuration of the router on the other end of this PVC can use either a similar map statement, or a subinterface, as in Recipe 10.1. If you use a map statement on the remote router, it should be configured with the IP address and DLCI number for the router on this end:

Branch1(config-if)#frame-relay map ip 192.168.1.1 50

When you configure a Frame Relay map like this, you create a static mapping between a DLCI number and a Layer 3 protocol address, IP in this case. In Recipe 10.1 we mentioned that when you create a static mapping, you can disable Inverse ARP. If you don’t need the router to make dynamic associations between Frame Relay DLCI numbers and Layer 3 addresses, we recommend disabling Inverse ARP:

Central(config)#interface Serial0
Central(config-if)#no frame-relay inverse-arp

When you set up a TCP/IP network using map statements, you have to bear in mind that the Frame Relay network does not handle broadcasts to the remote sites like a LAN segment. In fact, it is the classic example of a Non-Broadcast Multiple Access (NBMA) network. This can make OSPF configuration somewhat more complex, and it can cause serious problems for routing protocols that don’t handle NBMA media well.

The default configuration for most routing protocols assumes that you can reach all of the adjacent routers through a particular interface with either a broadcast or a multicast advertisement packet. With some protocols, you can configure the neighbors statically and instruct them to use unicast packets to exchange routing information instead. However, if you leave this in the default configuration, the routing protocols will not work at all.

Cisco routers also allow you to cheat a little bit and treat the Frame Relay network as if it were a broadcast medium by simply adding the broadcast keyword to the map statement:

Central(config-if)#frame-relay map ip 192.168.1.10 101 broadcast

In this case, if you were to send a packet to the broadcast address, 192.168.1.255, the router would make copies of the broadcast packet and send it out to all of the remote sites configured on this interface. Please refer to Chapters Chapter 6, Chapter 7, and Chapter 8 for more information on routing protocols.

The ietf keyword is another useful option in some situations. This tells the router to use RFC 1490 encapsulation instead of the default Cisco proprietary encapsulation:

Central(config-if)#frame-relay map ip 192.168.1.10 101 ietf

The default encapsulation does not work well with equipment from some vendors. So, if you have problems connecting to non-Cisco equipment, this option might help. You can also enable RFC 1490 encapsulation globally on the whole interface as follows:

Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay ietf
Central(config-if)#end

In this case, it is no longer necessary to specify the ietf keyword on each map statement. However, if you want to revert to the default Cisco encapsulation on a particular PVC, you can use the cisco keyword:

Central(config-if)#frame-relay map ip 192.168.1.10 101 cisco

We discuss some more options for the frame-relay map command in Recipe 10.8.

Recipe 10.1; Recipe 10.8; Recipe 10.9; Chapter 6; Chapter 7;

You want to configure Frame Relay so that many PVCs share the same subinterface.

You can connect several virtual circuits to a single subinterface as follows:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0.1 multipoint
Central(config-subif)#description Frame Relay to branches
Central(config-subif)#ip address 192.168.1.1 255.255.255.0
Central(config-subif)#frame-relay interface-dlci 101
Central(config-subif)#frame-relay interface-dlci 102
Central(config-subif)#frame-relay interface-dlci 103
Central(config-subif)#frame-relay interface-dlci 104
Central(config-subif)#end
Central#

Recipe 10.1 showed how to create a separate subinterface for each Frame Relay DLCI. Recipe 10.3 showed how to configure all of the DLCIs to share the same interface and the same address range. This recipe shows a method that is somewhere in between these two extremes, with several virtual circuits sharing a common subinter-face. You can even combine these multipoint subinterfaces with point-to-point sub-interfaces on the same physical interface if you wish to create a hybrid of the two styles.

When you use a multipoint configuration, the subinterface will appear to be active unless all of the DLCIs associated with it become unavailable. If this happens, the subinterface will go into a down state and the router will send a trap. This is different from the behavior when using Frame Relay maps on the physical interface, as discussed in Recipe 10.3. In that case, the interface will change state only if the signaling on the physical interface fails. For this reason, we recommend using multipoint configuration instead of Frame Relay maps.

As an interesting aside, you can configure Frame Relay maps on a multipoint sub-interface. This could be useful if you need to mix point-to-point and multipoint interface types on a network that doesn’t support Inverse ARP.

As we mentioned in Recipe 10.1, it is not a simple matter to change the subinterface type between point-to-point and multipoint. If you have already defined a subinter-face as one type and you want to change it to the other, you must delete the subinterface and reboot the router. Then you can add the subinterface configuration back to the router with the correct type.

The biggest difference between using multipoint subinterfaces and any of the previous examples is that here we do not configure a static mapping between a particular DLCI number and a remote IP address. So, to make this association, the router must use Inverse ARP. If you disable Inverse ARP here, as we did in the previous recipes, the network will not work.

You can see that Inverse ARP is correctly mapping IP addresses to DLCI numbers with the show frame-relay map command:

Central#show frame-relay map
Serial0.1 (up): ip 192.168.55.6 dlci 100(0x64,0x1840), dynamic,
              broadcast,, status defined, active
Central#

If we reconfigure this same DLCI to use a point-to-point subinterface instead (which requires rebooting the router, as we mentioned earlier), you see that the output of the show frame-relay map command changes significantly to tell you about the static mapping:

Central#show frame-relay map
Serial0.1 (up): point-to-point dlci, dlci 100(0x64,0x1840), broadcast
          status defined, active
Central#

Recipe 10.1; Recipe 10.3; Recipe 10.5

You want to configure the router to support Frame Relay SVCs.

Frame Relay SVCs are not extremely common, but some carrier networks support them. The advantage to using SVCs is that the router can add and remove inactive virtual circuits dynamically in a lightly used network. Because of the extra complexity and the management problems associated with dynamic network topologies, most network engineers will only use this feature if it offers significant cost advantages.

You can configure SVCs to use subinterfaces as in Recipe 10.1:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay lmi-type q933a
Central(config-if)#frame-relay svc
Central(config-if)#exit
Central(config)#interface Serial0.10 point-to-point
Central(config-subif)#ip address 192.168.1.129 255.255.255.252
Central(config-subif)#frame-relay interface-dlci 100
Central(config-subif)#map-group SVCMAP
Central(config-fr-dlci)#class SVCclass
Central(config-fr-dlci)#exit
Central(config-subif)# exit
Central(config)#map-list SVCMAP source-addr X121 1234 dest-addr X121 4321
Central(config-map-list)#ip 192.168.55.6 class SVCclass ietf
Central(config-map-list)#exit
Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay traffic-rate 56000 128000
Central(config-map-class)#end
Central#

You can also configure Frame Relay SVCs using map statements, similar to Recipe 10.3:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial
Central(config-if)#ip address 192.168.55.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay lmi-type q933a
Central(config-if)#frame-relay svc
Central(config-if)#map-group SVCMAP
Central(config-if)#frame-relay interface-dlci 50
Central(config-fr-dlci)#class SVCclass
Central(config-fr-dlci)#exit
Central(config-if)#exit
Central(config)#map-list SVCMAP source-addr X121 1234 dest-addr X121 4321
Central(config-map-list)#ip 192.168.55.6 class SVCclass ietf
Central(config-map-list)#exit
Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay traffic-rate 56000 128000
Central(config-map-class)#end
Central#

You can enable Frame Relay SVCs on an interface simply by including the frame-relay svc command. This is required whether you use maps or subinterfaces:

Central(config-if)#frame-relay svc

However, this doesn’t tell the network how to actually build the virtual circuits. To do that, you need to define a map list and a map class:

Central(config)#map-list SVCMAP source-addr X121 1234 dest-addr X121 4321
Central(config-map-list)#ip 192.168.55.6 class SVCclass ietf
Central(config-map-list)#exit
Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay traffic-rate 56000 128000
Central(config-map-class)#end

The map list associates an IP address with either X.121 or E.164 source and destination addresses. We have used X.121 addresses in the example, but if your carrier’s network uses E.164 addressing instead, you can simply replace the keyword X121 with E164 and specify the appropriate E.164 addresses:

Central(config)#map-list SVCMAP source-addr E164 1234 dest-addr E164 4321

The map-class command tells the router about the actual SVC parameters such as CIR and EIR. In this example, we want the network to create SVCs with CIR of 56,000 and total burst rate (CIR+EIR) of 128,000 bits per second.

By default, the router will keep an idle SVC for 120 seconds before tearing it down. You can change this period using the frame-relay idle-timer command. There are three ways to specify an idle time. You can have the router tear down an idle PVC if there is no traffic in either direction for a specified time period like this:

Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay idle-timer 60

Or you can specify the inbound and outbound directions separately:

Central(config)#map-class frame-relay SVCclass
Central(config-map-class)#frame-relay idle-timer in 20
Central(config-map-class)#frame-relay idle-timer out 30

In each case, the argument is the time period specified in seconds.

You can view the SVC map information on a router with the show frame-relay svc command:

Central#show frame-relay svc maplist SVCMAP
Map List : SVCMAP
Address : Source X121 1234 <----> Destination X121 4321

Protocol : ip 192.168.55.6                              Encapsulation : IETF

FMIF (Frame Mode Information Field Size), bytes
Configured : In = 1500, Out = 1500

CIR (Committed Information Rate), bits/sec
Configured : In = 56000,        Out = 56000,

Minimum Acceptable CIR, bits/sec
Configured : In = 56000,        Out = 56000,

Bc (Committed Burst Size), bits
Configured : In = 56000,        Out = 56000,

Be (Excess Burst Size), bits
Configured : In = 56000,        Out = 56000,

Central#

Remember that whether you use maps or subinterfaces, you can combine SVCs and PVCs on the same physical interface.

Recipe 10.1; Recipe 10.3

You want to use a router to simulate a Frame Relay cloud in the lab.

A Cisco router can function as a Frame Relay switch. This is mostly useful when you are trying to simulate a Frame Relay cloud in a lab to test your router configurations:

Cloud#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Cloud(config)#frame-relay switching
Cloud(config)#interface Serial0
Cloud(config-if)#description Frame-relay connection to Central - DLCI 50
Cloud(config-if)#encapsulation frame-relay
Cloud(config-if)#clock rate 125000
Cloud(config-if)#frame-relay lmi-type cisco
Cloud(config-if)#frame-relay intf-type dce
Cloud(config-if)#frame-relay route 101 interface Serial1 50
Cloud(config-if)#frame-relay route 102 interface Serial2 50
Cloud(config-if)#exit
Cloud(config)#interface Serial1
Cloud(config-if)#description Frame-relay connection to Branch1 - DLCI 101
Cloud(config-if)#encapsulation frame-relay
Cloud(config-if)#clock rate 125000
Cloud(config-if)#frame-relay lmi-type cisco
Cloud(config-if)#frame-relay intf-type dce
Cloud(config-if)#frame-relay route 50 interface Serial0 101
Cloud(config-if)#exit
Cloud(config)#interface Serial2
Cloud(config-if)#description Frame-relay connection to Branch2 - DLCI 102
Cloud(config-if)#encapsulation frame-relay
Cloud(config-if)#clock rate 125000
Cloud(config-if)#frame-relay lmi-type cisco
Cloud(config-if)#frame-relay intf-type dce
Cloud(config-if)#frame-relay route 50 interface Serial0 102
Cloud(config-if)#end
Cloud#

This type of configuration can be extremely useful when you need to test basic Frame Relay functionality in a lab, but don’t have a real Frame Relay switch available. However, it’s extremely important to remember that a router is not a Frame Relay switch, and it doesn’t emulate all of the functionality of the switch. In particular, no matter how congested you conspire to make the router, it will never generate FECN or BECN notifications. So, if you are using this type of configuration to test adaptive traffic shaping (or any other feature that relies on BECN notifications), it will not give you a reliable simulation of a real cloud.

To use the router as a Frame Relay switch, you must first enable the frame-relay switching option. Then you must configure each interface as DCE with the frame-relay intf-type command and supply a clock signal with the clock rate command. Cisco routers will not allow you to configure this command unless you use a DCE cable on the interface. Finally, you need to map the PVCs. In this case, we have configured a central hub router and two branch routers, as in Recipe 10.1. The central router can see both of the branch routers, one with DLCI 101, and the other with DLCI 102. Both of the branch routers see the central router with DLCI 50. The two branch routers cannot see one another directly.

In this example, all three of the Frame Relay connections are to DTE devices such as routers, so all of the interfaces are configured for DCE signaling. However, you can also configure connections to other switching devices. This might be useful if you were interested in constructing your own private Frame Relay cloud. In this case, you would still need to designate one of the devices to be the physical DCE and supply the clock. Then you would configure the interface type on both devices as Network to Network Interfaces (NNI) with the nni keyword:

Cloud#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Cloud(config)#interface Serial2
Cloud(config-if)#description Frame-relay connection to next switch
Cloud(config-if)#encapsulation frame-relay
Cloud(config-if)#clock rate 125000
Cloud(config-if)#frame-relay lmi-type cisco
Cloud(config-if)#frame-relay intf-type nni
Cloud(config-if)#end
Cloud(config)#

You would also use frame-relay route statements to configure one or more PVCs to be served by this neighboring switch. The PVC routing commands in this case are identical to those for DCE interfaces.

You can look at the routing of the virtual circuits on a router that is configured for Frame Relay switching with the show frame-relay route command:

Cloud#show frame-relay route
Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial0         101             Serial1         50              active
Serial0         102             Serial2         50              inactive
Serial0         103             Serial3         50              inactive
Serial1         50              Serial0         101             active
Serial1         102             Serial2         101             inactive
Serial1         103             Serial3         101             inactive
Serial2         50              Serial0         102             inactive
Serial2         101             Serial1         102             inactive
Serial2         103             Serial3         102             inactive
Serial3         50              Serial0         103             inactive
Serial3         101             Serial1         103             inactive
Serial3         102             Serial2         103             inactive
Cloud#

This output shows, for example, that traffic received on DLCI number 101 through interface Serial0 is forwarded to DLCI number 50 on Serial1. And, a few lines lower you can see the reverse path as well. The status for both of these lines is active, so this virtual circuit is working properly.

Recipe 10.1

You want to configure your router to do Frame Relay compression on a subinterface.

Cisco offers several different types of compression with Frame Relay. You can opt to compress only the TCP headers as follows:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay ip tcp header-compression passive
Central(config-if)#end
Central#

This command also works at the subinterface level:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-subif)#frame-relay ip tcp header-compression passive
Central(config-subif)#end
Central#

There are also two different payload compression options. The first uses the FRF.9 Frame Relay compression standard:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-if)#frame-relay payload-compression frf9 stac
Central(config-if)#end
Central#

The second uses Cisco’s proprietary packet-by-packet compression:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-if)#frame-relay payload-compression packet-by-packet
Central(config-if)#end
Central#

The nice thing about the first example in this recipe is that, with the passive keyword, the router will send packets with compressed TCP headers only if it receives packets with compressed headers. So if you have a variety of remote sites, some of which have routers that don’t support header compression, this can be a useful configuration option. You need to configure the device at least one end without the passive keyword:

Branch1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Branch1(config)#interface Serial0
Branch1(config-if)#encapsulation frame-relay
Branch1(config-if)#frame-relay ip tcp header-compression
Branch1(config-if)#end
Branch1#

Note that Cisco recommends shutting down the interface before changing this feature. It is not dangerous, but with some routers you need to reset the interface to ensure that it picks up the new configuration. The cleanest way to do this is to shut it down before making the change, then bring it back up when you are done.

For the payload compression examples, it is critical to configure the same compression algorithm on both ends. This is a subinterface level command, so you can configure each PVC to use compression or not according to what the device on the other end supports.

By default, the router will do the compression in a Compression Service Adapter (CSA) if one exists. If the router doesn’t have a CSA, then it will use a Versatile Interface Processor (VIP-2) card instead. And, if it doesn’t have either of these hardware options, then it will do the compression in software using the router’s CPU. Some external Frame Relay Access Devices (FRAD) also include FRF.9 compression, but it is unlikely that you will find a FRAD that supports Cisco’s packet-by-packet compression.

The FRF.9 compression command can also take several different options that allow you to force different hardware options. For example, you can force the router to use a particular CSA:

Central(config-if)#frame-relay payload-compression frf9 stac csa 1

Or, if you want to force the router to do the compression in its CPU, you can use the software keyword:

Central(config-if)#frame-relay payload-compression frf9 stac software

The stac keyword in all of these FRF.9 examples specifies the standard Stacker algorithm. In fact, this is the only option available for FRF.9 compression.

In general, we recommend using FRF.9 rather than packet-by-packet compression because it is an open standard, while packet-by-packet will only work with Cisco equipment. There is no noticeable performance difference between the two compression types. Cisco introduced its own packet-by-packet compression method before the FRF.9 standard was available, and continues to support it primarily for backward compatibility.

You can see statistics on the header compression with the following command:

Router#show frame-relay ip tcp header-compression
  DLCI 100       Link/Destination info:  point-to-point dlci
  Interface Serial1:
    Rcvd:    220 total, 219 compressed, 0 errors
             0 dropped, 0 buffer copies, 0 buffer failures
    Sent:    482 total, 481 compressed,
             17001 bytes saved, 229749 bytes sent
             1.7 efficiency improvement factor
    Connect: 16 rx slots, 16 tx slots, 1 long searches, 1 misses
             99% hit ratio, five minute miss rate 0 misses/sec, 0 max

Router#

Recipe 10.9; Recipe 10.8

You want to configure your router to do Frame Relay compression with map statements.

The same Frame Relay compression options that we discussed for subinterfaces are also available with map statements. You can turn on FRF.9 compression by simply including a few additional keywords in the frame-relay map statement as follows:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#description Frame Relay to branches
Central(config-if)#ip address 192.168.1.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101 payload-compression frf9 stac
Central(config-if)#end
Central#

Or you can opt to use Cisco’s proprietary packet-by-packet compression instead:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#description Frame Relay to branches
Central(config-if)#ip address 192.168.1.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101 payload-compression packet-by-
packet
Central(config-if)#end
Central#

The map configuration also supports TCP header compression:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#description Frame Relay to branches
Central(config-if)#ip address 192.168.1.1 255.255.255.0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101 compress
Central(config-if)#end
Central#

As we discussed in Recipe 10.7, Cisco routers are able to compress the data payload of packets before sending them through Frame Relay circuits. This recipe simply shows how to do the same thing using map statements instead of subinterfaces. Note that the header compression example shown in Recipe 10.7 applies to the physical interface, so the configuration for header compression is identical whether you are using maps or subinterfaces.

You can combine the payload compression option with the other options we discussed in Recipe 10.3 by specifying all of the required options on the same command line:

Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay map ip 192.168.1.10 101 ietf broadcast payload-
compression frf9 stac
Central(config-if)#end

Note that you can specify these keywords in any order, as long as the compression options are last. However, you cannot combine the different compression options with one another.

Recipe 10.3; Recipe 10.7

You want to check the status of a Frame Relay circuit or VC.

There are several useful show commands for looking at Frame Relay circuits and virtual circuits. It is usually best to start at the physical layer and work upward through the protocol layers. You can look at the physical interface with the show interfaces command:

Central#show interfaces serial

The show frame-relay pvc command allows you to see information about each of your Frame Relay PVCs:

Central#show frame-relay pvc

And sometimes it is also useful to look at the LMI status:

Central#show frame-relay lmi

The show interfaces command has a lot of useful information. When the interface is configured for Frame Relay, this command shows the LMI configuration, whether the interface is configured for SVCs as well as PVCs, and whether the interface is set up to be DCE or DTE. But the most important thing to look at is always the first line, which shows the physical and the protocol statuses:

Central#show interfaces serial
Serial0 is up, line protocol is up
  Hardware is HD64570
  Description: Frame Relay connection
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 3/255, rxload 3/255
  Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)
  LMI enq sent  263, LMI stat recvd 263, LMI upd recvd 0, DTE LMI up
  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0
  LMI DLCI 0  LMI type is CCITT  frame relay DTE
  FR SVC enabled, LAPF state down
  Broadcast queue 0/64, broadcasts sent/dropped 44/0, interface broadcasts 0
  Last input 00:00:03, output 00:00:03, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/2/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
  5 minute input rate 24000 bits/sec, 0 packets/sec
  5 minute output rate 23000 bits/sec, 0 packets/sec
     2838 packets input, 1604468 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
     2951 packets output, 1623730 bytes, 0 underruns
     0 output errors, 0 collisions, 20 interface resets
     0 output buffer failures, 0 output buffers swapped out
     2 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
Central#

If the interface is up you should be able to see useful PVC information:

Central#show frame-relay pvc

PVC Statistics for interface Serial1 (Frame Relay DTE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.1

  input pkts 1271          output pkts 1312         in bytes 843519
  out bytes 856138         dropped pkts 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 11320
  pvc create time 01:08:11, last time pvc status changed 00:39:42
Central#

This output tells you, for example, that the PVC with DLCI 100 is active and configured on subinterface Serial0.1. None of the packets received on this subinterface have had their FECN, BECN, or DE bits set. This is the most useful place to check for congestion in the Frame Relay cloud. Note that the router is unlikely to ever set the FECN or BECN bits when sending packets, so the inbound counters are the most useful here.

The last line of this output for each PVC is particularly useful if you have a problem with flapping PVCs in the carrier cloud. In this case, you can see that the PVC has been active for just over an hour, but it had a status change 39 minutes ago. This doesn’t tell you what caused the status change, though. In a stable network, you should not expect to see frequent PVC status changes. So this gives you a useful indication of problems either in the carrier cloud, or with your remote router.

Note that the show frame-relay pvc command will list all of the PVCs on a router, including any that are configured on the router but not in use. It will also list any PVCs that are configured on the switch, but not on the router. If you want to focus on a particular PVC, you can specify the one you want by its DLCI number:

Central#show frame-relay pvc 100

If you suspect an LMI problem, it is useful to look at the output of the show frame-relay lmi command:

Central#show frame-relay lmi

LMI Statistics for interface Serial1 (Frame Relay DTE) LMI TYPE = CCITT
  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 299              Num Status msgs Rcvd 299
  Num Update Status Rcvd 0              Num Status Timeouts 0
Central#

The first line of this output shows that the LMI type in this case is CCITT, which is configured with the frame-relay lmi-type q933a command. The other options are cisco and ansi, which both use the same type field in the output of this command as in the configuration command.

Because LMI is the Frame Relay management protocol between the router and the switch, the usual symptom of an LMI problem is that the physical interface is up, but the protocol is down and none of the PVCs will come up. If you repeatedly check the show frame-relay lmi command, you will see the Num Status Timeouts field incrementing. Because it can take several seconds for an interface to come up, it is sometimes hard to tell immediately if you have the right LMI type field. This field gives you a relatively quick indication of when you have the right configuration.