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:
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 upR2:
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 upSo 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/1Wait 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!!!!!
0 comments:
Post a Comment