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.