Configuring Frame Relay SVCs

Configuring Frame Relay SVCs

Problem

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

Solution

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 use this feature only 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)#exit
Central(config)#end
Central#

And you can also configure Frame Relay SVCs without subinterfaces, similar to the map configuration for PVCs, which we discussed in Recipe 10.3:

Central#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Central(config)#interface Serial0
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)#exit
Central(config)#end
Central#

Discussion

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 as follows:

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. In the example, we have used X.121 addresses, but if your carrier's network uses E.164 addressing instead, you would 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 56000 and total burst rate (CIR+EIR) of 128000 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#

It is useful to remember that whether you use maps or subinterfaces, you can combine SVCs and PVCs on the same physical interface.

See Also

Using Multipoint Subinterfaces

Using Multipoint Subinterfaces

Problem

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

Solution

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)#exit
Central(config)#end
Central#

Discussion

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 subinterface. You can even combine these multipoint subinterfaces with point-to-point subinterfaces on the same physical interface if you wish to create a hybrid of the two styles.

When you use multipoint configuration as in this recipe, the subinterface will appear to be active unless all of the DLCIs associated with it become unavailable. Then the subinterface will go into a down state and the router will send a trap. This is different from using frame-relay maps on the physical interface, as we discussed in Recipe 10.3. In that case, the interface will only change state 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 subinterface. 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.

Note that, 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 subinterface 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 the same DLCI to use a point-to-point subinterface instead (which requires rebooting the router, as we mentioned earlier), you see 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#

See Also

Adjusting LMI Options

Adjusting LMI Options

Problem

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

Solution

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)#exit
Branch1(config)#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)#exit
Branch1(config)#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)#exit
Branch1(config)#end
Branch1#

Discussion

The first example in this recipe sets an alternative LMI type. By default, Cisco routers will attempt to detect the LMI type. There are three options. The first 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. In fact, this default setting is usually the one you want because it is the default setting in many Frame Relay switches. The second LMI-type option is called ANSI, and the third is Q933A.

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. The Q933A LMI type is most commonly used for SVCs, although it can also support Frame Relay PVCs:

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 that all routers in the network use the same LMI type, as long as each router matches the settings on its respective Frame Relay switch. In most cases, the router is able to successfully auto-detect the LMI type, so you would only use these commands if there is a problem with this process.

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 as follows:

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)#exit
Branch1(config)#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 only required 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 because LMI requires them.

Setting Up Frame Relay with Point-to-Point Subinterfaces

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.

See Also

Setting Up Frame Relay with Map Statements

Setting Up Frame Relay with Map Statements

Problem

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

Solution

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)#exit
Central(config)#end
Central#

Discussion

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 set configure it to look similar to a LAN segment with a contiguous block of IP addresses. There are two ways to do thiseither by using frame-relay map statements, as in this recipe, or using multipoint subinterfaces, 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, as in this recipe, 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

Note that 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 map between these Layer 2 and Layer 3 parameters, 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 Nonbroadcast 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 Chapter 6 for more information on RIP, andChapter 8 for OSPF.

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 nonCisco 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.9.

Finally, we note in passing that with Inverse ARP you can automatically discover the Frame Relay DLCIs and associated IP addresses. So a particularly simple and elegant way of creating a Frame Relay network is to allow the routers to automatically detect the LMI type, the encapsulation method and all DLCIs. To do this, you just configure an IP address and the default Frame Relay encapsulation on the physical interface as follows:

Central(config)#interface Serial0
Central(config-if)#ip address 192.168.1.1 255.255.255.0
Central(config-if)#encapsulation frame-relay

Then a show frame-relay map command shows that Inverse ARP has done all of the other work for you:

Central#show frame map
Serial0/0 (up): ip 172.19.1.6 dlci 201(0xC9,0x3090), dynamic,
             broadcast,, status defined, active
Serial0/0 (up): ip 192.168.1.10 dlci 101(0x65,0x18C0), dynamic,
             broadcast,, status defined, active
Serial0/0 (up): ip 192.168.1.11 dlci 102(0x66,0x18D0), dynamic,
             broadcast,, status defined, active
Serial0/0 (up): ip 192.168.1.12 dlci 103(0x67,0x1870), dynamic,
             broadcast,, status defined, active
R3#

Notice in this output that Inverse ARP has also discovered DLCI 201 connected to another router, which is on a different subnet. So this method can very quickly help with troubleshooting as well.

However, as simple and elegant as this configuration method is, we still prefer to use point-to-point subinterfaces wherever we can. This is because it gives us so much greater control. For example, we can specify different routing protocol costs for PVCs with different CIR values, and we avoid a lot of the complications involved in running routing protocols over the NBMA multipoint Frame Relay network. Further, as we mentioned earlier, point-to-point subinterfaces provide the only way to get SNMP alerts when the corresponding DLCI goes away in the Frame Relay cloud. And a final compelling reason to avoid simply relying on Inverse ARP is that it can take a considerable length of time for the router to discover all of the remote devices.

See Also