Frame Relay NBMA Configuration and Verification

Frame relay NBMA configuration is very easy. In a Cisco-router internetwork, the only special configuration task we really have to do is tell IOS to perform frame relay encapsulation on the serial interface to which our frame relay local loop is connected. The encapsulation frame-relay interface configuration command does that. We are going to implement IP routing on a frame relay network, shown in Figure 3, to illustrate the basics of frame relay NBMA configuration.

Figure 3: Frame relay NBMA internetwork.

Since an NBMA network is treated as a single network with multiple hosts, all of the serial interfaces connected to the frame relay network are on the same IP subnet, 172.16.30.0/24. The frame relay local loops are connected to the Serial2 interfaces of each router. The PVCs are arranged in a partially meshed topology; therefore, we can expect traffic between FortWorth and Austin to go through Dallas.

Figure 4 shows the commands for the configuration on Dallas, Figure 5 shows the FortWorth configuration commands, and Figure 13-6 shows the Austin configuration commands.

1)  Dallas#configure terminal

2)  Enter configuration commands, one per line. End with CNTL/Z.

3)  Dallas(config)#interface serial2

4)  Dallas(config-if)#encapsulation frame-relay

5)  Dallas(config-if)#ip address 172.16.30.1 255.255.255.0

6)  Dallas(config-if)#no shutdown

7)  Dallas(config-if)#router rip

8)  Dallas(config-router)#network 172.16.0.0

9)  Dallas(config-router)#<Ctrl-Z>

10) Dallas#

Figure 4: Frame relay NBMA configuration on Dallas.

1)  FortWorth#configure terminal

2)  Enter configuration commands, one per line. End with CNTL/Z.

3)  FortWorth(config)#interface serial2

4)  FortWorth(config-if)#encapsulation frame-relay

5)  FortWorth(config-if)#ip address 172.16.30.2 255.255.255.0

6)  FortWorth(config-if)#no shutdown

7)  FortWorth(config-if)#router rip

8)  FortWorth(config-router)#network 172.16.0.0

9)  FortWorth(config-router)#<Ctrl-Z>

10) FortWorth#

Figure 5: Frame relay NBMA configuration on FortWorth.

1)  Austin#configure terminal

2)  Enter configuration commands, one per line. End with CNTL/Z.

3)  Austin(config)#interface serial2

4)  Austin(config-if)#encapsulation frame-relay

5)  Austin(config-if)#ip address 172.16.30.3 255.255.255.0

6)  Austin(config-if)#no shutdown

7)  Austin(config-if)#router rip

8)  Austin(config-router)#network 172.16.0.0

9)  Austin(config-router)#network 192.168.1.0

10) Austin(config-router)#<Ctrl-Z>

11) Austin#

Figure 6: Frame relay NBMA configuration on Austin.

The encapsulation frame-relay command (Line 4) tells IOS that the Serial2 interface is connected to a frame relay network, and any packets that are transmitted out from the interface should be encapsulated with a frame relay header and trailer. There are two types of frame relay encapsulation. The first type is Cisco’s own encapsulation, which is the default. Cisco’s frame-relay encapsulation can be used when both routers on each end of a PVC are Cisco routers. The second type is defined by the Internet Engineering Task Force (IETF); we use IETF frame-relay encapsulation when we have routers from multiple vendors on a PVC. We specify IETF encapsulation with the command encapsulation frame-relay ietf.

Each of the Serial2 interfaces now has an IP address from the 172.16.30.0/24 subnet (Line 5), and since the interfaces were shut down, we activated them with the no shutdown interface configuration command (Line 6). The interfaces actually came up when they started receiving LMI traffic from the frame relay switch. Because we removed our IP routing protocol in the preceding section, we needed to start one. We started RIP with the router rip global configuration command (Line 7) and the appropriate network router configuration commands.

We now have IP configured on the frame relay network, so let us check one of the IP routing tables. Figure 7 shows the IP routing table on the hub router, Dallas.

1)  Dallas#show ip route

2)  Codes: C - connected, S - static, I - IGRP, R - RIP,
           M - mobile, B - BGP

3)         D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

4)         N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

5)         E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

6)         i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
           * - candidate default

7)         U - per-user static route, o - ODR

8)

9)  Gateway of last resort is not set

10)

11)     172.16.0.0/24 is subnetted, 3 subnets

12) C      172.16.30.0 is directly connected, Serial2

13) R      172.16.20.0 [120/1] via 172.16.30.2, 00:00:04, Serial2

14) C      172.16.10.0 is directly connected, Ethernet0

15) R   192.168.1.0/24 [120/1] via 172.16.30.3, 00:00:23, Serial2

16) Dallas#

Figure 7: IP routing table on Dallas after NBMA configuration.

The routing table entry for 192.168.1.0/24 (Line 15) has a next-hop gateway address of 172.16.30.3. Dallas learned about this route via a RIP broadcast from Austin. When Dallas wants to forward a packet to the 172.16.30.3 address, it must have a layer-2 address to put into the frame header. For frame relay, this address is a DLCI; Dallas must know the local DLCI for the PVC that leads to Austin. In most cases, routers can automatically map the layer-3 addresses on the remote ends of PVCs to the local DLCIs of those PVCs using inverse ARP. We can see these mappings with the show frame-relay map command. Figure 8 shows the output of the command on Dallas.

1)  Dallas#show frame-relay map

2)  Serial2 (up): ip 172.16.30.2 dlci 100(0x64,0x1840), dynamic,

3)                broadcast,, status defined, active

4)  Serial2 (up): ip 172.16.30.3 dlci 102(0x66,0x1860), dynamic,

5)                broadcast,, status defined, active

6)  Dallas#

Figure 8: Inverse ARP mappings on Dallas.

Both entries in the map table of Figure 8 are listed as dynamic; they were learned with inverse ARP. When inverse ARP is used, a router sends an inverse ARP request on a PVC asking for the layer-3 address of the device on the other end. The router learns the local DLCI of the PVC to reach the layer-3 address by reading the DLCI of the other device’s inverse ARP response packet. Inverse ARP is enabled by default.

A frame relay network has no broadcast address; therefore, when a router wants to send a broadcast packet across a frame relay network, the router can send the packet over just one PVC at a time. Both of the PVCs on Dallas have the broadcast capability turned on, as indicated by the broadcast parameter in the map entries (Figure 8, Lines 3 and 5). Dallas must transmit all of its RIP broadcasts twice out from the Serial2 interface—once for each PVC. The display of the mappings also shows us that both PVCs are active, as indicated by the word active on the entries.

We can also perform manual mappings with the frame-relay map interface configuration command. The frame-relay map command allows us to statically define the local DLCI to reach a network host. Normally the network host is one that is directly connected to the other end of a PVC. If we wanted to define a static mapping for a host with the IP address 172.16.30.3, the commands to do so would look like those in Figure 9, and the updating mappings are shown in Figure 10.

1)  Dallas#configure terminal

2)  Enter configuration commands, one per line. End with CNTL/Z.

3)  Dallas(config)#interface serial2

4)  Dallas(config-if)#frame-relay map ip 172.16.30.3 102 broadcast

5)  Dallas(config-if)#<Ctrl-Z>

6)  Dallas#

Figure 9: Static mapping configuration on Dallas.

1)  Dallas#show frame-relay map

2)  Serial2 (up): ip 172.16.30.2 dlci 100(0x64,0x1840), dynamic,

3)                broadcast,, status defined, active

4)  Serial2 (up): ip 172.16.30.3 dlci 102(0x66,0x1860), static,

5)                broadcast,

6)                CISCO, status defined, active

7)  Dallas#

Figure 10: Show frame-relay map output on Dallas.

A static mapping replaces a dynamic, inverse ARP mapping in the frame-relay map table. On the frame-relay map command, we must specify a keyword for the network protocol and a corresponding address for which we are mapping a DLCI (Figure 9, Line 4). In our example, we are telling Dallas that the host with IP address 172.16.30.3 can be reached from the Serial2 interface on the PVC with DLCI 102. We included the broadcast keyword on the command so that IOS would send any necessary broadcast message across the PVC. Without the broadcast keyword, IOS would not send RIP updates on the PVC to Austin because RIP updates are broadcast packets. The frame relay map table indicates that broadcasts are enabled on the PVC to Austin (Figure 10, Line 5).

The map table also shows that Cisco’s frame-relay encapsulation is being used on the PVC to Austin (Figure 10, Line 6). We can change the encapsulation on a single PVC by putting either the ietf keyword or the cisco keyword at the end of a frame-relay map command. By default, all PVCs use the encapsulation specified on the encapsulation frame-relay command.

In the overview of frame relay, we mentioned that there were two major types of LMI used between routers and frame relay switches—ANSI Annex D and Gang of Four. The type of LMI depends on how our service provider has provisioned the local switch. The default LMI on a Cisco router is the Gang of Four LMI; however, as of IOS version 11.3, the router can sense the LMI type and will automatically use whichever one the switch is sending. If we wanted to manually set the LMI type, we would use the frame-relay lmi-type interface configuration command. The form of the command for Gang of Four LMI is frame-relay lmi-type cisco, and the form of the command for ANSI Annex D LMI is frame-relay lmi-type ansi.

We can issue the show frame-relay lmi command to see LMI statistics and the type of LMI being used. Figure 11 shows the output on Dallas. The LMI type is given at the end of the first line displayed (Line 3). Our test internetwork is using ANSI Annex D LMI. The statistics are for types of LMI messages. Two that we have already mentioned are the Status Enquiry message and the Status message (Line 9). The router transmits a Status Enquiry message every six LMI keepalives by default, and the switch is supposed to reply with a Status message containing the PVC DLCIs and their status.

1)  Dallas#show frame-relay lmi

2)

3)  LMI Statistics for interface Serial2 (Frame Relay DTE) LMI TYPE 5 ANSI

4)Invalid Unnumbered info 0         Invalid Prot Disc 0

5)Invalid dummy Call Ref 0          Invalid Msg Type 0

6)Invalid Status Message 0          Invalid Lock Shift 0

7)Invalid Information ID 0          Invalid Report IE Len 0

8)Invalid Report Request 0          Invalid Keep IE Len 0

9)Num Status Enq. Sent 29           Num Status msgs Rcvd 23

10)Num Update Status Rcvd 0          Num Status Timeouts 7

11) Dallas#

Figure 11: Show frame-relay LMI output on Dallas.

We can see the status of all of the PVCs ourselves by issuing the show frame-relay pvc command. The output of this command is shown in Figure 12. From the output, we can see that Dallas has two PVCs, both coming into Serial2, and their DLCIs are 100 and 102 (Lines 5 and 14); the status of both PVCs is ACTIVE. We also get to see some statistics on the total number of bytes and packets transmitted and received per PVC.

1)  Dallas#show frame-relay pvc

2)

3)  PVC Statistics for interface Serial2 (Frame Relay DTE)

4)

5)  DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE,
    INTERFACE = Serial2

6)

7)    input pkts 11         output pkts 10      in bytes 1084

8)    out bytes 1014        dropped pkts 1      in FECN pkts 0

9)    in BECN pkts 0        out FECN pkts 0     out BECN pkts 0

10)   in DE pkts 0          out DE pkts 0

11)   out bcast pkts 10     out bcast bytes 1014

12)   pvc create time 00:03:46, last time pvc status changed 00:03:06

13)

14) DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE,
    INTERFACE = Serial2

15)

16)   input pkts 10          output pkts 10     in bytes 1054

17)   out bytes 1014         dropped pkts 0     in FECN pkts 0

18)   in BECN pkts 0         out FECN pkts 0    out BECN pkts 0

19)   in DE pkts 0           out DE pkts 0

20)   out bcast pkts 10      out bcast bytes 1014

21)   pvc create time 00:03:46, last time pvc status changed 00:03:06

22) Dallas#

Figure 12: Show frame-relay PVC output on Dallas.

We have checked many things about the frame relay operation itself, but we have yet to check the most basic thing on the router—the interface. Figure 13 shows the output of the show interfaces command for Serial2 on Dallas. The interface is up/up (Line 2) and it is using frame relay encapsulation (Line 6). Since IETF is not specified with the encapsulation, Cisco’s frame-relay encapsulation is being used. The output contains a few statistics for LMI messages (Lines 7 and 8) and the type of LMI being used (Line 9).

1)  Dallas#show interfaces serial2

2)  Serial2 is up, line protocol is up

3)    Hardware is CD2430 in sync mode

4)    Internet address is 172.16.30.1/24

5)    MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec,
      rely 255/255, load 1/255

6)    Encapsulation FRAME-RELAY, loopback not set,
      keepalive set (10 sec)

7)    LMI enq sent 36, LMI stat recvd 30, LMI upd recvd 0,
      DTE LMI up

8)    LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0

9)    LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE

10)   FR SVC disabled, LAPF state down

11)   Broadcast queue 0/64, broadcasts sent/dropped 22/0,
      interface broadcasts 11

12)   Last input 00:00:05, output 00:00:05, output hang never

13)   Last clearing of “show interface” counters never

14)   Input queue: 0/75/0 (size/max/drops); Total output drops: 0

15)   Queuing strategy: weighted fair

16)   Output queue: 0/1000/64/0 (size/max total/threshold/drops)

17)      Conversations 0/1/256 (active/max active/max total)

18)      Reserved Conversations 0/0 (allocated/max allocated)

19)   5 minute input rate 0 bits/sec, 0 packets/sec

20)   5 minute output rate 0 bits/sec, 0 packets/sec

21)      55 packets input, 3102 bytes, 0 no buffer

22)      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

23)      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

24)      64 packets output, 3051 bytes, 0 underruns

25)      0 output errors, 0 collisions, 3 interface resets

26)      0 output buffer failures, 0 output buffers swapped out

27)      6 carrier transitions

28)      DCD=up DSR=up DTR=up RTS=up CTS=up

29) Dallas#

Figure 13: Show interfaces output for frame relay local loop on Dallas.