Setting Up Frame Relay with Point-to-Point Subinterfaces
Problem
You want to configure Frame Relay services so that each PVC is assigned to a separate subinterface.
Solution
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)#exit
Central(config-subif)#exit
Central(config)#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)#exit
Branch1(config-if)#exit
Branch1(config)#end
Branch1#
Discussion
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 64 Kbps 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 DTE type cable.
As an aside, 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 dynamically determine the encapsulation format for the data payload of each packet. If you have to connect to non-Cisco equipment, you may prefer to manually specify 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. The other option for payload encapsulation is a Cisco proprietary standard. 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, and then reboot the router before you can recreate 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 each 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; the other shows as DELETED, which means that it is not configured on the switch. This command also shows 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:
Router#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, Appletalk, 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 like this:
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.