You just cannot assume anything when you sit for your Version 4.0 CCIE R&S Lab Exam. One of the former assumptions we could make with Version 3.x was that our Frame Relay Switch is going to be just fine and dandy. Therefore, if you examined your PVC health (status) and you saw DELETED, you could immediately inspect your Frame Relay map statements, or your frame-relay interface-dlci commands for a typo in the DLCI.
But in this new exam (Troubleshooting section or Configuration section), nothing is off limits from your problem scope. OK, well, to be more accurate, most Layer 1 issues are still indeed out of scope. In fact, in the Troubleshooting section, Layer 1 really cannot be an issue since the devices we are troubleshooting are actually virtual routers. You cannot even run up against a bad cable there! But still, there is a lot more that we can be asked to troubleshoot than in the past. And if you think about the Core Knowledge section, they could even ask Layer 1 troubleshooting-related questions there instead!
In this blog post (dedicated to my current Advanced Troubleshooting Bootcamp Live Class), we will examine Frame Relay troubleshooting where the Frame Relay Switch rears its rather ugly head.
I am going to carefully configure the R1 and R2 interfaces for Frame Relay in this scenario. I am going to “slow down to speed up” in these configurations and make sure they are letter for letter perfect. First, R1 and then R2:
R1:
R1(config)#interface serial 0/1 R1(config-if)#shutdown R1(config-if)#encapsulation frame-relay R1(config-if)#no frame-relay inverse-arp R1(config-if)#ip address 10.20.20.1 255.255.255.0 R1(config-if)#frame-relay map ip 10.20.20.2 102 broadcast R1(config-if)#no shutdown R1(config-if)# ... Mar 2 14:54:33.156: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
R2:
Rack8R2(config)#interface serial0/1 Rack8R2(config-if)#shutdown Rack8R2(config-if)#encapsulation frame-relay Rack8R2(config-if)#no frame-relay inverse-arp Rack8R2(config-if)#ip address 10.20.20.2 255.255.255.0 Rack8R2(config-if)#frame-relay map ip 10.20.20.1 201 broadcast Rack8R2(config-if)#no shutdown Rack8R2(config-if)# ... Mar 2 14:59:23.362: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
So far so good!I am thrilled to see the magic UP/UP system messages and I am ready to rock with a PING test.
Rack8R2#ping 10.20.20.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Rack8R2#
Not what I want to see! Let me do some further information gathering:
Rack8R2#show frame-relay pvc PVC Statistics for interface Serial0/1 (Frame Relay DTE) Active Inactive Deleted Static Local 0 0 1 0 Switched 0 0 0 0 Unused 0 0 0 0 DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/1
Wait a minute! DELETED???? I triple-checked my DLCI configuration per the diagram. Can I access the device connecting these routers (R3 in my case)? I sure can…let me view the relevant configuration on the device.
Rack8R3#sh run ... hostname Rack8R3 ! frame-relay switching ! interface Serial1/2 no ip address encapsulation frame-relay clock rate 64000 frame-relay intf-type dce ! interface Serial1/3 no ip address encapsulation frame-relay clock rate 64000 frame-relay intf-type dce ... Rack8R3#
It looks like someone made a nice attempt at the Frame Relay Switch configuration here (note the highlighted commands), but they have forgotten the “static routes” for PVC switching on the device.
Rack8R3(config)#interface serial 1/2 Rack8R3(config-if)#frame-relay route 102 interface serial 1/3 201 Rack8R3(config)#interface serial 1/3 Rack8R3(config-if)#frame-relay route 201 interface serial 1/2 102 Rack8R3(config-if)#
Now, drum roll please, let us try that PING again.
Rack8R2#ping 10.20.20.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/61 ms Rack8R2#
Now that is more like it!!!!!
About Anthony Sequeira, #15626:
Anthony Sequeira brings decades of teaching, technical writing, and consulting experience to INE. Anthony began his career as an author and lecturer within the IT community, featuring best-selling titles for Microsoft and Cisco Press. Best known as one of the training voices for the revolutionary e-learning company called KnowledgeNet, Anthony now teaches online and in-classroom exclusively for INE. When not helping his students master Cisco networking, Anthony can be found at the poker tables, or flying the Florida skies in a Cessna.
You can leave a response, or trackback from your own site.
7 Responses to “Frame Relay Troubleshooting – the Frame Switch”
Leave a Reply


Thanks for this great blog post Anthony!
Would the ‘connect xyz Serial1/2 102 Serial 1/3 201′ be an option?
Nice article. For those who are using dynamips, and emulating a router as frame-relay switch, their hard work is paid off in new V4.
Same goes for those that built a home/personal lab. It seems rediculous that they’d find testing an IOS frame relay switch configuration as a relevant topic these days, I’d welcome (with open arms) seeing something along these lines in the troubleshooting or config sections of the lab exam!
Yes the ‘connect’ is a viable option here. Both the L2 ‘connect’ statement and frame-relay route accomplish the same thing.
@Matt and @martijn
It is so fun learning something every day in the CCIE world.
Thanks for your participation in this blog.
I would love to have a frame relay switch problem in the lab, easy points!