Dec
01

Sample Trouble Ticket

Your junior administrator has reported that R1 and R3 are unable to establish their EIGRP adjacency.

Screen shot 2009-12-01 at 8.46.38 PM

The first thing I want to do is engage in some “ground up” troubleshooting here. How are Layers 1 and 2 starting at R1?

R1#show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES unset  administratively down down
Serial0/0                  178.10.0.1      YES manual up                    up

OK – things look fine so far. Let me check the interface configuration to learn more.

R1#show run int s0/0
Building configuration...
Current configuration : 184 bytes
!
interface Serial0/0
ip address 178.10.0.1 255.255.248.0
encapsulation frame-relay
clock rate 2000000
frame-relay map ip 178.10.0.3 103 broadcast
no frame-relay inverse-arp
end

OK – we are using Frame Relay here. I am guessing the device that separates R1 and R3 (R2) is going to be acting as a Frame Relay Switch. I grab my scratch paper and draw this three router topology providing more details like IP addresses and DLCIs. Speaking of DLCIs, it is time to check the status of the Frame Relay PVCs on R1.

R1#show frame pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

 Active     Inactive      Deleted       Static
 Local          0            1            0            0
 Switched       0            0            0            0
 Unused         0            0            0            0

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial0/0

 input pkts 3             output pkts 5            in bytes 312       
 out bytes 520            dropped pkts 0           in pkts dropped 0         
 out pkts dropped 0                out bytes dropped 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         
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 pvc create time 00:33:18, last time pvc status changed 00:21:51
R1#

We do indeed have a Layer 2 problem. The LMI status is INACTIVE. This means our connection is fine, but the remote connection is not. Let me jump to R3 and check the status there.

R3#show frame pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

 Active     Inactive      Deleted       Static
 Local          0            0            1            0
 Switched       0            0            0            0
 Unused         0            0            0            0

DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0

 input pkts 3             output pkts 3            in bytes 312       
 out bytes 312            dropped pkts 0           in pkts dropped 0         
 out pkts dropped 0                out bytes dropped 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         
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 pvc create time 00:10:22, last time pvc status changed 00:00:57
R3#

Yes, there is a problem on this side of the link all right. The LMI status reports as DELETED. This means we have a configuration issue with the Frame Relay Switch device. Let me examine the relevant pieces of the configuration there.

R2#show run
!
hostname R2
!
frame-relay switching!
!
interface Serial0/0
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
frame-relay route 103 interface Serial0/1 301
!
interface Serial0/1
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
!

All of the required commands appear to be in place, with one big exception. The frame-relay route command is missing on the interface that leads to R3. This would be consistent with our DELETED PVC status on R3! Let me quickly drop in the fix.

R2(config)#int s0/1
R2(config-if)#frame-relay route 301 interface serial 0/0 103

Jumping over to R3 – I see some great news – we have just completed another Trouble Ticket:

R3#
*Mar  1 00:50:18.407: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 178.10.0.1 (Serial0/0) is up: new adjacency

Want more practice with Troubleshooting? Be sure to check out other great products that focus on this exam section exclusively:


You can leave a response, or trackback from your own site.

12 Responses to “CCIE R&S – Sample Trouble Tickets – Part 3”

 
  1. Nick G says:

    Wait a second, I thought the FR switch would be something that we wouldn’t have to touch?

    I would assume that since this is the “troubleshooting” section that is run on the virtual unix fancy pants platform, anything is fair game?

    I guess this would make troubleshooting easier if I could see the FR switch as well, either that or make things more complicated as when you cannot touch it – it’s configured right and it’s the end points that have issues.

    -Nick

  2. Ian Finlayson says:

    Thanks!!!

  3. MCL.Nicolas says:

    Very nice !!!!! thanks for this layered troubleshooting ticket !

    it will Help me in my everyday job !

  4. [...] CCIE R&S – Sample Trouble Tickets – Part 3 [...]

  5. Thank`s!!! Good excercise!!! Nowadays, I been having troubles configuring FR DTE Routers because of these issues on my ISP. Now I understand the reason why FR connection failed on my side. Excellent!!!

  6. Nick G says:

    Well I guess that makes things more fun now doesn’t it? :)

  7. As was announced at last year’s Networkers, while Frame-Relay may be “less” on this version of the blueprint, the frame-relay switch will NOT necessarily be configured for you.

    So just like in the old days (my time!) you will need to be aware of how to configure it. One quick and easy way (for customers of ours) is to take a look at the configuration of the BB1 router which acts as the frame-relay switch in our topology.

  8. CCIE Pilot says:

    Nick, I would certainly be familiar of how a FR switch be configured, troubleshoot and work. :-)

  9. Sandeep says:

    Thanks
    This is very helpful information

  10. Marlon says:

    To this date I always thought that as a CCIE R&S candidate we do not need troubleshoot or get involved with frame-relay switch configuration, since that has been presented as a ‘black blox’ to us.

    Now we are saying that we should expect to fix configuration on the frame-relay switch(or the router simulating a frame-relay switch), right? OKKKKK.

    Thanks.

  11. Kristopher Climie says:

    Scott is correct — FRS *may or may not* be on the exam, and it *may or may not* be configured for you in either the Troubleshooting or the Configuration section.

    Regardless of what you thought to be the case, or how they have tested in the last few years, you *must* know how to do this. In the grand scheme of things that we have to know for the current lab blueprint, FRS is one of the easiest and is a pretty much a gimme.

    Now how their stupid troubleshooting virtual environment reacts to the config is a completely separate issue…

 

Leave a Reply

Categories

CCIE Bloggers