Back
Content
Back-to-Back Frame Relay
A Frame Relay back-to-back configuration can be quite helpful in a testing environmentonce 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 framerelay local-dlci command. Typically the frame interface-dlci command is used when using subinterfaces with LMI provided (as discussed later in this chapte r). 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 struc ture 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 = 0x0001 0308 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, yourse q 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 Seria l1 (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 recv d 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 s Think of the Frame Relay o. 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: d atagramstart = 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#undebug all r3#copy runni ng-config startup -config r3#show frame -relay map Serial0/0 (up): ip 192.168.5.9 dlci 108(0x6C,0x18C0), dynamic, broadcast,, status defined, active r3#ping 192.168.5.9 Type escape sequence to abort. Sending 5, 100 -byte ICMP Echos to 192.168.5.9, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round -trip min/avg/max = 28/30/32 ms
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.
A Frame Relay back-to-back configuration can be quite helpful in a testing environmentonce 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 framerelay local-dlci command. Typically the frame interface-dlci command is used when using subinterfaces with LMI provided (as discussed later in this chapte r). 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 struc ture 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 = 0x0001 0308 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, yourse q 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 Seria l1 (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 recv d 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 s Think of the Frame Relay o. 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: d atagramstart = 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#undebug all r3#copy runni ng-config startup -config r3#show frame -relay map Serial0/0 (up): ip 192.168.5.9 dlci 108(0x6C,0x18C0), dynamic, broadcast,, status defined, active r3#ping 192.168.5.9 Type escape sequence to abort. Sending 5, 100 -byte ICMP Echos to 192.168.5.9, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round -trip min/avg/max = 28/30/32 ms
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.
