Scenario: Shooting Trouble with Frame Relay
In the WAN world, it is always easy to blame things on someone else. Therefore, it is important to understand a bit about what happens in the cloud and on the user ends so that you can narrow down the problem as to whether it is your problem, someone else's problem or a service provider issue. The goal in this first scenario is to configure Frame Relay in a hybrid back-to-back configuration using r1, r2, and r3, as in Figure 8-1.
Figure 8-1. Shooting Trouble with Frame Relay (Hybrid Back-to-Back Topology)
As always, there is not always one right or wrong way to achieve this task or tasks presented. The ability to obtain the end result using good practices is extremely important in any real-world network. My troubleshooting and device configurations are presented starting in Example 8-1 so that you can compare your work and perhaps see a different approach to obtaining the end result. Use the previous checklists, your step-by-step troubleshooting methodology, and the Frame Relay checklist in Table 8-1 to assist in testing.
| Isolating Problems | Commands and Symptoms |
|---|---|
| Check IP address, subnet mask, and routing protocols. All of these are Layer 3 or above that ride on top of Frame Relay. Keep in mind that many routing protocols are multicast/broadcast, but Frame Relay is NBMA[*]. | ping
traceroute show ip protocols show ip route |
[*] NBMA = nonbroadcast multiaccess
| Isolating Problems | Commands and Symptoms |
|---|---|
| Check interface status and encapsulation. If the point-to-point PVC[**] is active, for example, line protocol for the subinterface is up. | show ip interface brief show interfaces serial 0 |
| Are you communicating with the provider? | show frame-relay lmi |
| Are your DLCIs active? | show frame-relay map
show frame-relay pvc clear frame-relay-inarp |
| Look at PVC statistics. Monitor the Frame traffic. | show frame-relay traffic |
| Verify the route statements on the frame switch. | show frame-relay route |
| Watch the interface communications. | debug serial interface |
| Watch the LMI[†] handshake. | debug frame-relay lmi |
| Watch the packets received. | debug frame-relay events |
| Watch the packets sent. | debug frame-relay packet |
[**] PVC = permanent virtual circuit
[†] LMI = Local Management Interface
Back-to-Back Frame Relay
A Frame Relay back-to-back configuration can be quite helpful in a testing environment once you get it to work. Refer to Cisco.com for assistance with a true back-to-back external link Frame Relay solution using no LMI. I want you to use sort of a hybrid back-to-back situation for testing where r2 acts as a pseudo frame switch as I do Example 8-1. It is a good idea to confirm that things are not broken to begin with if you are starting from existing configurations. Back-to-back frame is tricky enough, however, so I want you to erase the configurations on the three routers and configure back-to-back frame from the beginning.
Configure the routers starting with r2 first because it is acting as a back-to-back hub device for the other routers (see Figure 8-1 and Example 8-1). For now just configure the bare-bones configuration with no descriptions or passwords to concentrate on this Layer 2 technology in action. In a practical environment, this obviously should be a requirement.
Example 8-1. Configuring r2 as a Pseudo Frame Switch
Router(config)#hostname r2 r2(config)#frame-relay switching r2(config)#interface serial 0 r2(config-if)#bandwidth 64 r2(config-if)#ip address 192.168.5.9 255.255.255.252 r2(config-if)#encap frame-relay r2(config-if)#frame-relay intf-type dce r2(config-if)#frame-relay local-dlci 108 r2(config-if)#no shut r2(config-if)#interface serial 1 r2(config-if)#bandwidth 64 r2(config-if)#encap frame r2(config-if)#ip address 192.168.5.6 255.255.255.252 r2(config-if)#encap frame r2(config-if)#frame-relay intf-type dce r2(config-if)#frame-relay local-dlci 104 r2(config-if)#no shut |
I called r2 a pseudo frame switch because there are no frame route statements in the configuration. The encap frame-relay command changed the default High-Level Data Link Control (HDLC) encapsulation on the WAN interfaces to Frame Relay so that you could configure the other Frame Relay parameters. Now look at the frame map and PVCs in Example 8-2.
Example 8-2. Reviewing the Map and PVCs on the Frame Switch
r2#show frame-relay map r2#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DCE) DLCI = 108, DLCI USAGE = LOCAL, 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 pvc create time 00:01:30, last time pvc status changed 00:00:53 PVC Statistics for interface Serial1 (Frame Relay DCE) DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial1 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 pvc create time 00:00:31, last time pvc status changed 00:00:31 r2#copy running-config startup-config |
It certainly makes sense that there is no frame mapping at this point because the other ends (r1 and r3) are still configured for HDLC encapsulation, the default for serial interfaces. For the same reason, the PVCs are inactive. The DLCIs were assigned on the main interface using the frame-relay local-dlci command. Typically the frame interface-dlci command is used when using subinterfaces with LMI provided (as discussed later in this chapter).
NOTE
From a support standpoint, it is good to see the bouncing PVC state from active to inactive, because for future reference you now know this is a good indication the other end of the PVC has not been configured.
It is important to note that regardless of the physical DTE/DCE cable, Frame Relay has its own DTE/DCE configuration at Layer 2 as you witnessed with the frame-relay intf-type dce command for both interfaces on r2. If you issue the show controllers command as in Example 8-3, you will see that both are physical DTE interfaces. However, the preceding example portrays them as Frame Relay DCEs. This is absolutely correct. For there is a Layer 1 and Layer 2 DTE/DCE with this technology.
Example 8-3. show controllers for the Physical DTE
r2#show controllers s 0 HD unit 0, idb = 0x107EAC, driver structure at 0x10D340 buffer size 1524 HD unit 0, V.35 DTE cable cpb = 0x1, eda = 0x48DC, cda = 0x48F0 RX ring with 16 entries at 0x4014800 ... r2#show controllers s 1 HD unit 1, idb = 0x111648, driver structure at 0x116AE0 buffer size 1524 HD unit 1, V.35 DTE cable cpb = 0x2, eda = 0x3104, cda = 0x3118 |
NOTE
On a practical note, generating clock is also a Layer 1 DCE function and Layer 2 is not concerned with clocking.
Next configure r1 to communicate to r2 using Frame Relay as in Example 8-4. Turn on debug service timestamps and logging. Clear the counters to make sure you start your troubleshooting from this point on if necessary. Feel free to turn on logging synchronous, too. Because this is a lab, just before you bring up the interface turn on keepalive debugging to watch the goings-on.
Example 8-4. Back-to-Back Frame Relay r1 Configuration
Router(config)#hostname r1 r1(config)#service timestamps debug datetime localtime msec r1(config)#service timestamps log datetime localtime msec r1(config)#exit r1#clock set 5:21:00 Dec 9 2002 r1#clear counters r1#configure terminal r1(config)#line console 0 r1(config-line)#logging synchronous r1(config-line)#interface s1 r1(config-if)#bandwidth 64 r1(config-if)#clock rate 64000 r1(config-if)#ip address 192.168.5.5 255.255.255.252 r1(config-if)#encap frame r1(config-if)#end r1#debug frame-relay lmi Frame Relay LMI debugging is on Displaying all Frame Relay LMI data r1#configure terminal r1(config)#interface s1 r1(config-if)#no shut Dec 9 05:25:31.487: %LINK-3-UPDOWN: Interface Serial1, changed state to up Dec 9 05:25:31.527: Serial1(out): StEnq, myseq 1, yourseen 0, DTE up Dec 9 05:25:31.531: datagramstart = 0xE22EA4, datagramsize = 14 Dec 9 05:25:31.531: FR encap = 0x00010308 Dec 9 05:25:31.535: 00 75 95 01 01 00 03 02 01 00 Dec 9 05:25:31.539: Dec 9 05:25:31.539: Serial1(out): StEnq, myseq 1, yourseen 0, DTE up Dec 9 05:25:31.543: datagramstart = 0xE22EA4, datagramsize = 13 Dec 9 05:25:31.543: FR encap = 0x00010308 Dec 9 05:25:31.547: 00 75 51 01 00 53 02 01 00 Dec 9 05:25:31.551: Dec 9 05:25:31.551: Serial1(out): StEnq, myseq 1, yourseen 0, DTE up Dec 9 05:25:31.551: datagramstart = 0xE22EA4, datagramsize = 13 Dec 9 05:25:31.555: FR encap = 0xFCF10309 Dec 9 05:25:31.555: 00 75 01 01 00 03 02 01 00 Dec 9 05:25:31.559:!!!next is the full status from the frame switch Dec 9 05:25:31.571: Serial1(in): Status, myseq 1 Dec 9 05:25:31.575: RT IE 1, length 1, type 0 Dec 9 05:25:31.575: KA IE 3, length 2, yourseq 1 , myseq 1 Dec 9 05:25:31.579: PVC IE 0x7 , length 0x6 , dlci 104, status 0x4 , bw 0 Dec 9 05:25:31.579: %FR-5-DLCICHANGE: Interface Serial1 - DLCI 104 state changed to DELETED ... Dec 9 05:25:41.607: %FR-5-DLCICHANGE: Interface Serial1 - DLCI 104 state changed to DELETED Dec 9 05:25:42.519: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up ... Dec 9 05:26:31.543: Serial1(in): Status, myseq 7 Dec 9 05:26:31.547: RT IE 1, length 1, type 0 Dec 9 05:26:31.547: KA IE 3, length 2, yourseq 7 , myseq 7 Dec 9 05:26:31.551: PVC IE 0x7 , length 0x6 , dlci 104, status 0x2 , bw 0 r1(config)# Dec 9 05:26:31.551: %FR-5-DLCICHANGE: Interface Serial1 - DLCI 104 state changed to ACTIVE r1(config)#end r1#undebug all |
On r1 it was only necessary to turn on Frame Relay encapsulation. Everything else was accomplished via default Inverse Address Resolution Protocol (Inverse ARP) activity. Review the keepalive activity with the debug frame-relay lmi command. Notice the status inquiries going out from r1 to r2 (frame switch) about every 10 seconds. After six inquiries, the switch returns the DLCIs in a full status message. This is the normal LMI exchange between the local router and the Frame Relay carrier.
Regardless of troubleshooting the LAN or the WAN, show ip interface brief is still a quick way to show the interface status, as I do in the next example. View the interfaces, the Frame Relay mapping, and ping the other end of the PVC as in Example 8-5.
Example 8-5. r1 Testing
r1#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES unset administratively down down Ethernet1 unassigned YES unset administratively down down Serial0 unassigned YES unset administratively down down Serial1 192.168.5.5 YES manual up up r1#show interfaces s1 Serial1 is up, line protocol is up Hardware is HD64570 Internet address is 192.168.5.5/30 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 92, LMI stat recvd 93, 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 ... DCD=up DSR=up DTR=up RTS=up CTS=up r1#show frame-relay map Serial1 (up): ip 192.168.5.6 dlci 104(0x68,0x1880), dynamic, broadcast,, status defined, active r1#ping 192.168.5.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms r1#show frame-relay pvc PVC Statistics for interface Serial1 (Frame Relay DTE) DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1 input pkts 5 output pkts 5 in bytes 520 out bytes 520 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 pvc create time 00:15:17, last time pvc status changed 00:15:18 r1#show interface s1 Serial1 is up, line protocol is up Hardware is HD64570 Internet address is 192.168.5.5/30 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 6, LMI stat recvd 6, 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 FR SVC disabled, LAPF state down r1#copy running-config startup-config |
The output clearly shows that show ip interface brief is a quick check of the layers; however, show interfaces s1 provides more Frame Relay details for the interface. For example, the shaded lines display not only the IP address but also the subnet mask and the LMI keepalive activity. The encapsulation is frame. The default LMI type of Cisco is talking over DLCI 1023. The status inquiries sent (out) are equal to the messages received (in), and you are looking at the Frame Relay DTE end of the PVC.
The example output also illustrates ping to be successful and rightly so. Think of the Frame Relay PVC like a PVC pipe that carries water from one end to the other. The Frame PVC transports variable-length frames from the source network to the destination network through the service provider cloud.
Frame Relay maps a Layer 2 DLCI to a Layer 3 network address, such as IP, IPX, or AppleTalk for example. When you view your ending running configuration, note the individual protocols spelled out for Frame Relay. The default method of doing this Layer 2-to-Layer 3 dynamic mapping is by a process called Inverse ARP. You verified the mapping with the show frame-relay map command in the preceding example. Each PVC shows the DLCI number assigned, the usage of local compared to global, with a status of dynamic compared to static. The DLCI number is shown in decimal, hex, and what you might expect to see on the wire. The other PVC statistics are quite helpful in supporting Frame Relay, and you will experience them more throughout this chapter.
Now configure and test r3 as in Example 8-6 to finish up your hybrid back-to-back chapter scenario. Turn on Frame Relay event debugging to watch the major happenings.
Example 8-6. r3 Hybrid Back-to-Back Configuration
Router(config)#hostname r3 r3(config)#service timestamps debug datetime localtime msec r3(config)#service timestamps log datetime localtime msec r3(config)#end r3#clock set 5:50:00 Dec 9 2002 r3#clear counters r3(config)#line console 0 r3(config-line)#logging synchronous r3(config-line)#interface s0/0 r3(config-if)#bandwidth 64 r3(config-if)#clock rate 64000 r3(config-if)#ip address 192.168.5.10 255.255.255.252 r3(config-if)#encap frame r3(config-if)#no shut r3(config-if)#end r3#copy running-config startup-config r3#debug frame-relay events Frame Relay events debugging is on Dec 9 05:52:49.087: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed |
state to up
Dec 9 05:53:38.099: %FR-5-DLCICHANGE: Interface Serial0/0 - DLCI 108 state changed to ACTIVE
Dec 9 05:53:38.135: Serial0/0: FR ARP input
Dec 9 05:53:38.135: datagramstart = 0x240034E, datagramsize = 30
Dec 9 05:53:38.139: FR encap = 0x18C10300
Dec 9 05:53:38.139: 80 00 00 00 08 06 00 0F 08 00 02 04 00 09 00 00
Dec 9 05:53:38.139: C0 A8 05 09 18 C1 C0 A8 05 0A
Dec 9 05:53:38.139:
r3#Configuring r3 was as simple as configuring r1 because you used the default Inverse ARP once again. The shaded output of the show frame-relay map statement shows dynamic for this. The ping to r2 should be successful.
Save your configurations to a file named hybrid back-to-back frame relay in case you want to quickly return to the back-to-back configuration.
NOTE
There is not just one way to configure back-to-back Frame Relay. Research the topic at Cisco.com and try some of the other configurations.
In most real-world WAN applications, you configure the user ends of the PVCs that connect through the cloud in a hub-and-spoke topology using subinterfaces. You will get plenty of practice configuring and troubleshooting Frame Relay using subinterfaces throughout this chapter and in the practical environment. I want to turn your attention to using a router as a Frame Relay switch to get started.
Using a Router as a Frame Relay Switch
Many of the Cisco-certified classes have you work with Frame Relay but not all of them have you actually do this from a service provider perspective with building the frame switch. My purpose in configuring a router as the frame switch is so that you understand the cloud. What happens inside the mysterious Frame Relay cloud is really just passing the frames through some more switches depending on what the service provider is doing.
Use the following steps to set up a router as a Frame Relay switch:
1. | Give the frame switch a hostname. |
2. | Turn on Frame Relay switching. |
3. | Configure bandwidth. |
4. | Configure clock rate if physical DCE. |
5. | Configure encapsulation. (Default is cisco, or you can set to ietf.) |
6. | Configure LMI type. (Default is cisco, or you can set to ansi or q933a.) |
7. | Configure frame interface type. (Default is dte, or you can set to dce.) |
8. | Configure frame route statements. |
9. | Troubleshoot the frame switch as needed: show frame-relay route show frame-relay lmi show frame-relay pvc show ip interface brief no shut |
Instead of completely erasing r2, modify it so that it is a frame switch as in Figure 8-2 and Example 8-7.
Example 8-7. Configuring r2 as a Frame Switch
r2(config)#hostname frame switch ^ % Invalid input detected at '^' marker. r2(config)#hostname frame-switch frame-switch(config)#interface s0 frame-switch(config-if)#encap frame frame-switch(config-if)#frame-relay route ? <16-1007> input dlci to be switched frame-switch(config-if)#frame-relay route 108 ? interface outgoing interface for pvc switching frame-switch(config-if)#frame-relay route 108 interface s1 ? <16-1007> output dlci to use when switching frame-switch(config-if)#frame-relay route 108 interface s1 104 ? <cr> frame-switch(config-if)#frame-relay route 108 interface s1 104 frame-switch(config-if)#interface s1 frame-switch(config-if)#encap frame frame-switch(config-if)#frame route 104 interface s0 108 frame-switch(config-if)#end frame-switch#copy running-config startup-config |
Because frame-relay switching and frame-relay intf-type dce are already on from the back-to-back scenario, the frame relay route commands are really all you need to make r2 a true Frame Relay switch. These statements are interface configuration commands. Here, you route what comes in interface s0 as DLCI 108 out interface s1 as DLCI 104. For the other PVC, start at interface s1 to route what comes in s0 as DLCI 104 out interface s0 as DLCI 108.
You may not have removed the IP addresses from the previous exercise; a frame switch does not need IP addresses. In the future, you should be able to recognize whether you have an output for the show frame-relay map command on the frame switch as in Example 8-8. Fix this now and verify the frame switch with the show frame-relay route command. Feel free to remove the local DLCI statement from the preceding exercise, too, because it is no longer required.
Example 8-8. Verifying the Frame Switch
frame-switch#show frame-relay map Serial0 (up): ip 192.168.5.10 dlci 108(0x6C,0x18C0), dynamic, broadcast,, status defined, active Serial1 (up): ip 192.168.5.5 dlci 104(0x68,0x1880), dynamic, broadcast,, status defined, active frame-switch#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DCE) DLCI = 108, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 7 output pkts 6 in bytes 580 out bytes 550 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 1 pvc create time 01:20:18, last time pvc status changed 00:00:52 ... frame-switch#show frame-relay route Input Intf Input Dlci Output Intf Output Dlci Status Serial0 108 Serial1 104 active Serial1 104 Serial0 108 active |
NOTE
Use ? each step of the way when configuring the frame route statements. The familiar show frame-relay lmi, show frame-relay map, and show frame-relay pvc commands are ready to lend a hand with supporting Frame Relay on your routers, but add show frame-relay route to your tool bag for troubleshooting a frame switch.
Save your r2 ending configuration to a file named r2 as a frame switch for r1 and r3.
Before you make too many assumptions, you better make sure the r1 and r3 configuration still work with the newly configured frame switch. Pinging from one end to the other should fail at this point with the frame switch in the middle.
You would certainly have a route and be able to ping if you add static routes as in Example 8-9 to get to the destination network. Actually for the preceding back-to-back example it would be fine, but adding static routes or routing protocols here would be very odd things to do. Remember, Frame Relay is Layer 2.
Example 8-9. r1 and r3 Static Routes
r1(config)#ip route 192.168.5.8 255.255.255.252 s1 r3(config)#ip route 192.168.5.4 255.255.255.252 s0/0 r3(config)#end r1#ping 192.168.5.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms |
If you took the static route or routing protocol approach to fixing this problem, remove that portion of your configuration now. Instead, I want you to configure the IP addresses for r1s1 and r3s0/0 to be on the same subnet as in Figure 8-3 and Example 8-10. Use the existing IP address for r1.
Example 8-10. Configuring r1 and r3 on the Same Subnet
r1(config)#no ip route 192.168.5.8 255.255.255.252 r1(config)end r1#copy running-config startup-config r3(config)#no ip route 192.168.5.4 255.255.255.252 r3(config)#interface s0/0 r3(config-if)#ip address 192.168.5.6 255.255.255.252 r3(config-if)end r3#copy running-config startup-config |
Test the Frame Relay connections from the router point of view and then from the service provider point of view as in Example 8-11.
Example 8-11. Testing the Frame Relay Connections
r1#show frame-relay map Serial1 (up): ip 192.168.5.6 dlci 104(0x68,0x1880), dynamic, broadcast,, status defined, active r1#ping 192.168.5.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms r1#trace 192.168.5.6 Type escape sequence to abort. Tracing the route to 192.168.5.6 1 192.168.5.6 28 msec 28 msec * r1#show arp r3#show frame-relay map Serial0/0 (up): ip 192.168.5.5 dlci 108(0x6C,0x18C0), dynamic, broadcast,, status defined, active r3#ping 192.168.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms r3#trace 192.168.5.5 Type escape sequence to abort. Tracing the route to 192.168.5.5 1 192.168.5.5 28 msec 28 msec * frame-switch#show frame-relay route Input Intf Input Dlci Output Intf Output Dlci Status Serial0 108 Serial1 104 active Serial1 104 Serial0 108 active |
The shaded output clearly shows that the frame switch is transparent to r1 and r3. The pings are successful and trace shows no intermediary hops, and that is what you should expect. When you look at the output of show frame-relay map, think of it like looking at the ARP table in Ethernet.
For Frame Relay Inverse ARP issues, I suggest clear frame-relay-inarp or bouncing the serial interfaces on r1 and r3 so that they relearn the DLCI information and rebuild their maps. You may need to do that here. If the show frame-relay lmi command indicates timeouts, use the debug frame-relay lmi command after you bounce (shut/no shut)the interfaces to observe the communications between the router and the frame switch like in Example 8-12.
Example 8-12. Troubleshooting the Frame Connections
frame-switch(config)#interface s0 frame-switch(config-if)#shut frame-switch(config-if)#interface s1 frame-switch(config-if)#shut r1(config)#interface s1 r1(config-if)#shut r3(config)#interface s0/0 r3(config-if)#shut frame-switch(config-if)#interface s0 frame-switch(config-if)#no shut frame-switch(config-if)#interface s1 frame-switch(config-if)#no shut r1#debug frame-relay lmi Frame Relay LMI debugging is on Displaying all Frame Relay LMI data r1#configure terminal r1(config)#interface s1 r1(config-if)#no shut 01:13:47: %LINK-3-UPDOWN: Interface Serial1, changed state to up 01:13:47: Serial1(out): StEnq, myseq 1, yourseen 0, DTE up 01:13:47: datagramstart = 0xE22EA4, datagramsize = 14 01:13:47: FR encap = 0x00010308 01:13:47: 00 75 95 01 01 00 03 02 01 00 01:13:47: 01:13:47: Serial1(out): StEnq, myseq 1, yourseen 0, DTE up 01:13:47: datagramstart = 0xE22EA4, datagramsize = 13 01:13:47: FR encap = 0x00010308 01:13:47: 00 75 51 01 00 53 02 01 00 01:13:47: 01:13:47: Serial1(out): StEnq, myseq 1, yourseen 0, DTE up 01:13:47: datagramstart = 0xE22EA4, datagramsize = 13 01:13:47: FR encap = 0xFCF10309 01:13:47: 00 75 01 01 00 03 02 01 00 01:13:47: 01:13:47: Serial1(in): Status, myseq 1 01:13:47: RT IE 1, length 1, type 0 01:13:47: KA IE 3, length 2, yourseq 1 , myseq 1 01:13:47: PVC IE 0x7 , length 0x6 , dlci 104, status 0x2 , bw 0 01:13:47: %FR-5-DLCICHANGE: Interface Serial1 - DLCI 104 state changed to ACTIVE 01:13:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up 01:13:57: Serial1(out): StEnq, myseq 2, yourseen 1, DTE up 01:13:57: datagramstart = 0xE22EA4, datagramsize = 13 01:13:57: FR encap = 0xFCF10309 01:13:57: 00 75 01 01 01 03 02 02 01 01:13:57: 01:13:57: Serial1(in): Status, myseq 2 01:13:57: RT IE 1, length 1, type 0 01:13:57: KA IE 3, length 2, yourseq 2 , myseq 2 01:13:57: PVC IE 0x7 , length 0x6 , dlci 104, status 0x0 , bw 0 01:13:57: %FR-5-DLCICHANGE: Interface Serial1 - DLCI 104 state changed to INACTIVE r3(config-if)#no shut 01:14:44: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up 01:14:44: %FR-5-DLCICHANGE: Interface Serial0/0 - DLCI 108 state changed to ACTIVE 01:14:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up r3(config-if)#end r3#show frame-relay map Serial0/0 (up): ip 192.168.5.5 dlci 108(0x6C,0x18C0), dynamic, broadcast,, status defined, active r1(config-if)#end ... r1#undebug all ... r1#show frame-relay map Serial1 (up): ip 192.168.5.6 dlci 104(0x68,0x1880), dynamic, broadcast,, status defined, active r1#ping 192.168.5.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms r3#ping 192.168.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms !!!notice the following output where you can't ping yourself r3#ping 192.168.5.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.6, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) r3#copy running-config startup-config frame-switch#copy running-config startup-config r1#copy running-config startup-config |
The lessons learned from this exercise should reinforce that Frame Relay is a Layer 2 technology. Note that I turned up the frame switch interfaces first and then the spokes so that Inverse ARP would occur properly. The show frame-relay map command displays the Layer 2/Layer 3 mapping to assist you with why you may not be able to get to your destination. The clear frame-relay-inarp command should clear all the Inverse ARP learned entries so that they are relearned; if problems occur, however, you can always bounce the interfaces. If necessary, you can always change the encapsulation back to HDLC and then back to Frame Relay.
By the way, the shaded output illustrates that r1 can ping r3 and vice versa, yet r3 can't ping itself. This is the norm with multipoint interfaces in Frame Relay. If you really want it to work, you can put in a static map statement such as in Example 8-13.
Example 8-13. Adding a Static Frame Relay Map
r3(config-if)#frame-relay map ip 192.168.5.6 108 r3(config-if)#end r3#ping 192.168.5.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/124 ms r3#show frame-relay pvc PVC Statistics for interface Serial0/0 (Frame Relay DTE) DLCI = 108, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0 input pkts 55 output pkts 52 in bytes 4970 out bytes 4850 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 7 out bcast bytes 474 pvc create time 22:52:49, last time pvc status changed 22:52:49 !!!the line above is sort of a tattle tale line:o) r3#show frame-relay map Serial0/0 (up): ip 192.168.5.5 dlci 108(0x6C,0x18C0), dynamic, broadcast,, status defined, active Serial0/0 (up): ip 192.168.5.6 dlci 108(0x6C,0x18C0), static, CISCO, status defined, active |
The preceding example shows how simple it is to add a static map in the interface configuration mode. You can ping yourself, the PVC is active, and you now have a have a static entry in your frame map table along with the previous dynamic one.
NOTE
Always check the running configuration before you remove everything because Inverse ARP may very well be turned off on a protocol-by-protocol basis.
Also note that the frame switch is not configured for routing at all. For your IP packets to get to their destination, they need a route or need to be on the same network. With such a simple example, configuring the interfaces on the same subnet or a static route is fine. In larger networks it obviously is not practical to set up everything using static routes but rather more feasible to use a routing protocol and default routes. Frame Relay has its own issues with main interfaces and routing protocols because of its nonbroadcast multiaccess (NBMA) nature. Obviously, Frame Relay can't go out and ARP everything on the WAN like in the LAN. NBMA primarily means that multiple routers are supported without broadcasting capabilities. Hence routing updates must be replicated using this type of multipoint connection.
Save your configurations. The significant parts of my ending configurations are in Example 8-14.
Example 8-14. Shooting Trouble with Frame Relay Scenario Same Subnet Configurations
r1#show running-config interface Serial1 bandwidth 64 ip address 192.168.5.5 255.255.255.252 encapsulation frame-relay clockrate 64000 frame-switch#show running-config frame-relay switching interface Serial0 bandwidth 64 no ip address encapsulation frame-relay frame-relay intf-type dce frame-relay route 108 interface Serial1 104 ! interface Serial1 bandwidth 64 no ip address encapsulation frame-relay frame-relay intf-type dce frame-relay route 104 interface Serial0 108 r3#show run interface Serial0/0 bandwidth 64 ip address 192.168.5.6 255.255.255.252 encapsulation frame-relay clockrate 64000 frame-relay map ip 192.168.5.6 108 |
Keep in mind that the service provider can pretty much do what they want inside the cloud and it doesn't necessarily have to be Frame Relay. They may be doing ATM MPLS with the appropriate encapsulation on entry to the cloud and appropriate encapsulation on leaving the cloud to your destination, or just re-encapsulating in IP.
Figure 8-4 shows an example of a Frame Relay cloud with more switches to give you a better feel for the appropriate route statements in the real world. If you have multiple routers in your environment, feel free to experiment with supporting a more complex cloud.
Now I want to review some Frame Relay history and terminology before you move on to shooting more Frame Relay troubles. If you are already comfortable with the terminology, feel free to move directly into the “Frame Relay Frames” and “Frame Relay Addressing” sections.