R&S Advanced Troubleshooting Video-on-Demand

WAN Troubleshooting


Table of Contents
Course Files
  • 1 Troubleshooting Overview Closed Caption 0h 22m
    2 CCIEv4 Blueprint Closed Caption 0h 11m
    3 Troubleshooting Overview II Closed Caption 0h 31m
    4 WAN Troubleshooting Closed Caption 0h 36m
    5 Frame Relay Troubleshooting Closed Caption 0h 41m
    6 LAN Troubleshooting Part 1 Closed Caption 0h 48m
    7 LAN Troubleshooting Part 2 Closed Caption 0h 40m
    8 IPv4 Troubleshooting Overview Closed Caption 0h 53m
    9 IPv4 Troubleshooting Closed Caption 0h 40m
    10 RIP Troubleshooting Closed Caption 0h 32m
    11 EIGRP Troubleshooting Closed Caption 0h 50m
    12 Troubleshooting RIP & EIGRP Advertisement Closed Caption 0h 27m
    13 EIGRP Unequal Cost Load Balancing Closed Caption 0h 09m
    14 OSPF Troubleshooting Closed Caption 0h 49m
    15 Troubleshooting OSPF Authentication Part 1 Closed Caption 0h 36m
    16 Troubleshooting OSPF Authentication Part 2 Closed Caption 0h 17m
    17 BGP Troubleshooting Part 1 Closed Caption 0h 36m
    18 BGP Troubleshooting Part 2 Closed Caption 0h 38m
    19 BGP Troubleshooting Part 3 Closed Caption 0h 56m
    20 MPLS Troubleshooting Part 1 Closed Caption 0h 43m
    21 MPLS Troubleshooting Part 2 Closed Caption 0h 32m
    22 Multicast Troubleshooting Closed Caption 0h 53m
    23 Miscellaneous Troubleshooting Closed Caption 0h 13m
    Total Duration   13h 33m
  • 0:00:14 Ok, so let's take a look at our first technical topic
    0:00:16 for the day here which is going to be layer 2
    0:00:19 WAN troubleshooting.
    0:00:21 Now the examples that I'm going to be going through
    0:00:24 are going to be fairly basic from a topology point of view.
    0:00:29 I'm basically going to be looking at just configuration of
    0:00:33 the back to back devices. Now everyone in class here
    0:00:37 should also be allocated a rack for graded labs
    0:00:41 so if you check your e-mail, you should see some rack
    0:00:44 login information from them and you could feel free to
    0:00:47 follow along with any of the examples that I am working through.
    0:00:50 Now technically you won't need the rack until Thursday when we
    0:00:53 actually go through the full scale troubleshooting labs
    0:00:57 but if you want to try out any of the examples that I'm going
    0:00:59 through, you will have the ability to do that any time
    0:01:03 throughout the week.
    0:01:05 Now as we looked at before with the CCIE version 4
    0:01:08 blueprint, the three WAN protocols
    0:01:11 that the exam is going to be focusing on our HDLC
    0:01:14 PPP and frame relay.
    0:01:18 Now we are going to be looking at these from a
    0:01:20 pure layer 2 point of view
    0:01:23 and not dealing with layer 1 issues like dealing with packet over
    0:01:27 sonet interfaces or channelized T1 -- or
    0:01:33 T1 or PRI interfaces, we're looking at just a basic generical
    0:01:37 layer 2 encapsulation
    0:01:39 there really doesn't matter what the media, the physical
    0:01:43 media that it is running over, so in the troubleshooting
    0:01:47 section there will be no layer 1 issues that we need to
    0:01:49 deal with. In the configuration section, the layer 1 issues should be
    0:01:53 should be minor, but we will talk about what those
    0:01:56 potential problems could be.
    0:02:01 Now to start here with HDLC, there are effectively no
    0:02:05 features that are available for the encapsulation
    0:02:08 very, very straightforward configuration. For our serial link
    0:02:12 we just say encapsulation hdlc and that is it from a
    0:02:16 configuration point of view.
    0:02:18 Now really the only other issue that we could run into
    0:02:20 with HDLC relates to the layer 1 physical
    0:02:26 link and to do with the physical clocking of the line.
    0:02:30 Now for back-to-back configurations of point-to-point links
    0:02:34 that do not go to an external switch or to an external CSU
    0:02:38 DSU, you need to remember that the DCE end of the link
    0:02:43 must perform the line clocking.
    0:02:46 So the line clocking is a synchronization issue
    0:02:49 that determines from a physical one framing point of view
    0:02:52 how do we actually encapsulate the frames onto the link.
    0:02:58 Now the actual clocking value and the encoding type is
    0:03:04 going to be based on the physical link, so obviously
    0:03:07 there would be a different clocking on a slow-speed
    0:03:09 serial interface versus a DS 3 high speed serial interface
    0:03:15 but from our point of view, we're going to be dealing with
    0:03:18 just basic slow speed serial links on the network, so
    0:03:22 things like WICK 1 T, WICK 2 T I would expect.
    0:03:26 Now when you look at just the basic serial link
    0:03:29 with no configuration on it, we want to look at first off
    0:03:33 what is the line status. Now any time we look at the
    0:03:37 show interface or the show ip interface, show ip
    0:03:41 interface brief, there are two different attributes that
    0:03:44 we want to look at for the physical link.
    0:03:46 It is going to be the line status or the link status
    0:03:49 and the protocol status.
    0:03:51 Now if everything is working properly, we should see that
    0:03:54 the link status or the line status is up and the
    0:03:58 line protocol is up, so it's going to be the up/up state.
    0:04:02 It means that there are no physical layer 1 problems
    0:04:05 and whatever your layer 2 protocol is has its requirements
    0:04:09 met. For example with frame relay, up/up would mean that
    0:04:12 the physical link is fine and that you are receiving LMI keepalive
    0:04:15 from the frame relay network. Now in the case of HDLC
    0:04:20 it's much simpler than this. As long as the link is not
    0:04:24 down/down, so if the link is up/down or up/up, this indicates
    0:04:29 that there is no physical layer 1 problem.
    0:04:33 So any time you look at the link and it says for the
    0:04:37 first portion if this says down, this is always a
    0:04:39 physical layer 1 issue, so it could be on the other side of the
    0:04:43 link, maybe it's shut down or there's actually a physical
    0:04:46 physical cabling problem.
    0:04:48 If we see the state as up/down, this means that layer 1 is fine
    0:04:54 but something in layer 2 is not. In the case of HDLC really the only
    0:04:59 issue that you could see here would be with the clocking.
    0:05:03 So if the DCE end of the link is not performing the clocking
    0:05:06 then the link is going to be in the up/down state.
    0:05:11 Now verification to this is going to be fairly straightforward
    0:05:13 if we look at the show controllers serial, it should tell us
    0:05:17 which end is the DCE, which is the DTE, who is
    0:05:21 performing the clocking or I should say whether the
    0:05:24 clocking is being performed or not and then what the actual
    0:05:27 clocking value is, so let's take a look at this on the
    0:05:31 command line.
    0:05:34 So here on our standard hardware topology we have
    0:05:37 a back-to-back connection that is between router 1
    0:05:41 and router 3, now, on router 1's side of the link
    0:05:45 this is interface serial 0/1
    0:05:49 On router 3's side of the link, this is interface serial 1/2
    0:05:54 Now we can see from both devices there's no configuration
    0:05:57 we have no IP address and the interface is shut down.
    0:06:01 So if we look at the show interface serial 1/2
    0:06:07 interface status is administratively down, so
    0:06:09 it basically means it's just shut down.
    0:06:11 But by default in any case the encapsulation is HDLC.
    0:06:17 Keepalive is 10 seconds by default.
    0:06:20 Now loopback is not set, this means a physical loopback
    0:06:24 not referring to like an interface loopback 0, a physical loopback
    0:06:28 would be for a line test to loop the packets back to the
    0:06:31 router itself basically to figure out is the problem in your
    0:06:36 local loop, is it between the provider edge devices
    0:06:42 so when we're doing a physical layer 1 circuit testing
    0:06:45 from a low level point of view, the provider will
    0:06:48 loop the line at different points of the network
    0:06:50 to figure out exactly where the problem is occurring.
    0:06:54 Now you can actually configure this on the router at the link level
    0:06:58 you just simply say loopback, but this is not going to actually
    0:07:03 affect anything unless there's a physical device
    0:07:05 on the other end that will loop the traffic back.
    0:07:08 So usually you go out to a CSU DSU, then the CSU DSU
    0:07:13 is configured to loop the traffic back to you.
    0:07:22 no loopback
    0:07:26 ok, so without any configuration let's bring both these links up
    0:07:32 on both ends of the configuration.
    0:07:35 Now assuming there are no layer 1 problems
    0:07:39 we should see that the link status is up
    0:07:42 but the line protocol should be down
    0:07:44 because no one is performing the clocking at this point. If we
    0:07:47 look at the show ip interface brief, it says, we can see it says
    0:07:53 serial 0/1 is up/up, after the keepalive expires
    0:07:58 we should see that the link is going to go to the up/down status
    0:08:01 and there we can see line protocol is going down.
    0:08:05 So any time we look at show ip interface brief
    0:08:07 and it says the link is up/down, it means that
    0:08:10 layer 1 is fine, but there is some problem at layer 2
    0:08:15 Now the actual problem at layer 2 depends on the encapsulation.
    0:08:18 So we'll see that HDLC basically has no options that we
    0:08:22 can configure, but when we get involved with things like
    0:08:24 PPP or frame relay, there are additional configurations
    0:08:28 that could cause the link status to be up, but the
    0:08:31 protocol status to be down, for example, PPP authentication
    0:08:35 or frame relay LMI
    0:08:38 so it will be specific to the individual protocol that we are using.
    0:08:44 Now from an Ethernet perspective as we'll see later
    0:08:47 there's basically pretty much nothing that will send the link to the
    0:08:51 up/down status other than a physical problem
    0:08:57 assuming we do not have any complex configurations like
    0:09:00 spanning tree filtering or any other layer 2 options.
    0:09:04 So with Ethernet, there's basically no configuration
    0:09:07 from just the basic layer 2 point of view. Either the link is
    0:09:11 up/up or the link is down/down and it's a physical layer 1 problem.
    0:09:16 Now on router 1 if we look at the show controllers
    0:09:22 serial 0/1
    0:09:25 it says that this is the DTE end of the link
    0:09:29 and the clocks are stopped so this is telling us two things.
    0:09:34 It says we are the DTE end, we are the receiving
    0:09:38 end of the link and clocks are stopped, we are not receiving
    0:09:41 a clocking from the other end.
    0:09:44 Now you don't need to know these specific options
    0:09:47 unless there's a physical layer 1 problem, then the
    0:09:50 the service provider would go through a line test with you
    0:09:54 since this is back-to-back, the only thing we're basically
    0:09:57 caring about here is the clocking in the protocol status.
    0:10:01 So on router 3 likewise if we look at the show interface
    0:10:05 serial 1/2
    0:10:08 or excuse me, show controllers
    0:10:15 serial 1/2
    0:10:17 this is the DCE end.
    0:10:20 We are DCE, but we are not providing the clocking.
    0:10:24 So at the link level
    0:10:26 we need to go to the link
    0:10:30 and specify what is the clock rate.
    0:10:33 Now the individual rate that the link supports is
    0:10:35 going to be based on the physical hardware. In this case
    0:10:38 on router 3, I believe this is NM 4 A/S which is an
    0:10:44 asynchronous port
    0:10:48 and if I let's say show hardware
    0:10:55 4 low-speed sync/async interfaces
    0:10:58 so basically these are a 128 k WICKs
    0:11:02 so from router 3's perspective I would not want to clock the link
    0:11:05 higher than a 128 thousand because the physical link does
    0:11:08 not support that. Now basically every interface
    0:11:12 will support at least a clock rate of 64 k which is a DS 0
    0:11:21 but different links can support higher.
    0:11:24 Now in a lot of examples, in a lot of documentation
    0:11:27 you will see the clock rate set as 64 because it's
    0:11:30 it's kind of a baseline value that regardless of what lab
    0:11:33 equipment you have you'll always know that the link is going to
    0:11:35 support at least 64 k
    0:11:39 Now we can see that the link or excuse me, the
    0:11:42 line protocol status comes up now that we have the clocking
    0:11:46 and if we look at now the output of the show
    0:11:56 show controllers serial 1/2
    0:12:03 we can see we are the DCE
    0:12:06 but now we are actually providing the clocking.
    0:12:10 If we were to go to router 1's side which is the DTE
    0:12:22 it says we are the DTE end and the clocks are detected.
    0:12:26 So from the customer's point of view who typically is the
    0:12:30 DTE, this would mainly be the thing that we would be focusing
    0:12:34 on if the CSU DSU is not providing the clocking down to us
    0:12:37 then this is the way that we are going to tell.
    0:12:40 So really pretty straightforward configuration. With HDLC there's
    0:12:44 effectively no configuration that you need to do
    0:12:47 at the link level that would relate to the direct layer 2
    0:12:51 Now you can debug the serial interface
    0:12:58 and we'll see this when we look at, we'll look at PPP
    0:13:05 this may not be the correct debug for the HDLC, but we
    0:13:09 will see -- actually yeah it is here
    0:13:12 we'll see that there is a basic sequencing that takes place
    0:13:16 between the neighbors and this is going to happen
    0:13:19 every 11 or excuse me, every 10 seconds based on the
    0:13:22 keepalive that I have, so basically what this is saying
    0:13:25 is that router 1 incremented the sequence number from
    0:13:28 10 to 11
    0:13:30 and it also got a reply back in from the other side
    0:13:34 saying I saw your sequence number go to 11
    0:13:38 so basically this is just showing us basic bidirectional
    0:13:41 communication over the link, my sequence number is 13
    0:13:45 router 3 is acknowledging that it saw 13
    0:13:48 If I were to go to router 3 and do the same debug
    0:13:52 I would see router 3 sending out these sequence number and
    0:13:55 then router 1 acknowledging it.
    0:14:01 Ok, the next one we have here is PPP.
    0:14:05 So PPP is going to be a little bit more involved than
    0:14:07 HDLC because there's other types of features that we can
    0:14:11 apply onto the link, but from a very low-level perspective
    0:14:16 when PPP is enabled, we would want to go through the
    0:14:19 same basic layer 1 check so if we look at the show interface
    0:14:23 or the show ip interface brief and the link is down/down
    0:14:27 this would not be a layer 2 related issue. Any time
    0:14:31 the link status itself is down, it relates to layer 1
    0:14:35 If the link is up/down, then it could relate to problems with our
    0:14:39 layer 2 negotiation specifically in PPP is going to relate to the
    0:14:45 link control protocol or LCP phase of negotiation.
    0:14:49 Now PPP is actually built out of or it's made up of two
    0:14:53 different phases of negotiation, link control protocol and
    0:14:57 network control protocol. LCP is where we negotiate
    0:15:01 basic link options like authentication and the magic
    0:15:04 number, the NCPs or network control protocols
    0:15:08 this is where we negotiate things like our IP address or
    0:15:13 IPv6 over PPP CDP over PPP
    0:15:19 Ok, so again, for the first phase
    0:15:25 of PPP, the link control protocol phase
    0:15:29 this is where we're looking at mainly two things. It's going to be
    0:15:33 the magic number and authentication.
    0:15:36 Now authentication is optional, but the vast majority
    0:15:39 of time when we're running PPP, we are going to be
    0:15:44 running authentication, so if authentication is off
    0:15:47 the only thing that we would need to negotiate here is the magic
    0:15:49 number. This doesn't have anything to do with our
    0:15:52 configuration, so if magic number negotiation fails
    0:15:55 it most likely means that there's a layer 1 problem
    0:15:58 of the link, so the packets are not getting through or
    0:16:01 they're getting corrupted as they go across the link.
    0:16:04 Now what we should see when we look at the show
    0:16:08 interface for a link running PPP is that the LCP is open
    0:16:14 the link control protocol is open.
    0:16:16 Now assuming LCP is open, it means that the link should be in the
    0:16:19 up and up state. If we see LCP is waiting or
    0:16:23 LCP is closed or the link is up/down, most of the time
    0:16:27 this is going to be a problem in PPP authentication
    0:16:31 because other options we configure in PPP like multi-link
    0:16:37 or link quality monitoring, those technically do not have to be a
    0:16:41 100 percent negotiated in order for the basic link status to come up.
    0:16:47 So we'll look here at the debug PPP negotiation
    0:16:50 this will show us the details of the individual LCP negotiation
    0:16:54 and then also for the NCP, the network control protocol
    0:16:59 negotiation.
    0:17:01 Now you'll also see a link there it says understanding
    0:17:03 debug PPP negotiation output, this is a detailed troubleshooting
    0:17:08 guide on Cisco's website about PPP, you'll see that I have
    0:17:12 these links in throughout the week as we're going through
    0:17:15 different technologies, a lot of information or a lot of
    0:17:19 technologies I should say on Cisco's website will have
    0:17:21 associated troubleshooting guides.
    0:17:24 So once we go through PPP and frame relay here
    0:17:29 we'll look at specifically where these are located on the
    0:17:32 the documentation as well.
    0:17:37 Ok, now once the link control protocol negotiation is done
    0:17:41 when we look at the show interface, we should see that the
    0:17:45 LCP is open or if we show ip interface brief, the link is going to be
    0:17:49 up/up, then we actually negotiate the protocol that is going to
    0:17:52 run on top of PPP
    0:17:56 Now even without any other configuration if we were to go to
    0:17:59 router 1 and router 3 here and just say encapsulation PPP
    0:18:03 at a minimum, we would be negotiating the CDP CP, the
    0:18:07 CDP, Cisco Discovery Protocol Control Protocol.
    0:18:12 Now once IP is on there, we would also be running
    0:18:18 the IP control protocol or for IPv6, IP version 6
    0:18:23 that should not say IPv6 IP, that should say IPv6 CP
    0:18:27 IPv6 control protocol.
    0:18:29 So this would be the state at which we negotiate
    0:18:33 things like the IP address if we're doing IP address negotiated
    0:18:38 through DHCP, things like the peer neighbor route to install
    0:18:43 the route for the other end of the link
    0:18:46 but you will see here if the NCP negotiation fails
    0:18:51 it does not necessarily mean that the link will be
    0:18:54 in the up/down or the down/down state.
    0:18:57 The link itself from PPP will be declared up, but it will mean
    0:19:02 that whatever network protocol you were running over the link
    0:19:06 is not going to be functional.
    0:19:09 So for IP, there's not really many cases where this would happen
    0:19:14 it could be for example you have IP configured on
    0:19:16 one side, but not the other, in that case
    0:19:19 IP CP would say listen as opposed to open
    0:19:23 it basically means that the protocol is not fully enabled.
    0:19:27 In both cases like we'll see here with both LCP and NCP
    0:19:32 both of these would be verified through the debug
    0:19:35 PPP negotiation output.
    0:19:38 Ok, there's a question here
    0:19:41 "Is there a value in the debug up/down status
    0:19:45 for HDLC?"
    0:19:48 Do you mean why it would be up/down?
    0:19:52 Can you identify the issue?
    0:19:55 Not really because basically the only thing that would relate to
    0:19:59 HDLC is either a layer 1 issue or a lack of the
    0:20:06 a lack of the layer 2 clocking.
    0:20:09 So when you look at the show controllers serial
    0:20:15 these different outputs here
    0:20:21 these are different alarm codes that would be significant
    0:20:25 to the service provider, so let's say you buy a
    0:20:28 point-to-point T1 link from the provider, if there is
    0:20:31 some sort of layer 1 or basic low-level layer 2 issue
    0:20:35 they would request this output from you, the show controllers
    0:20:38 and it's going to tell them what the particular alarm is.
    0:20:42 But from our perspective, this is kind of outside of our scope
    0:20:45 because it's more of like a Telco troubleshooting issue
    0:20:49 this type of stuff would not be within the scope of the exam.
    0:20:54 So from our point of view, as long as the link is clocked
    0:20:58 so the DCE end is providing the clocking, that's really the
    0:21:01 only issue that we would look at HDLC from a network point of view.
    0:21:07 Now with PPP, let's look at the debug PPP negotiation
    0:21:11 on router 3
    0:21:13 and we're going to enable the protocol on both sides.
    0:21:16 So really straightforward configuration, the only thing I'm
    0:21:20 saying here is encapsulation PPP
    0:21:32 Now we can see from the output first off it says
    0:21:36 that LCP is opening.
    0:21:40 It says that there is an outbound configuration request
    0:21:44 for this particular magic number, so basically what this is saying
    0:21:49 is that router 3 is starting to open the connection
    0:21:52 we're asking router 1 to use this particular magic number
    0:21:55 for negotiation, so this is the magic number from
    0:21:59 3 to 1
    0:22:00 router 1 replies through LCP with an inbound configuration
    0:22:04 acknowledgement saying I will use that particular magic
    0:22:08 number that you wanted.
    0:22:10 Now likewise, router 1 sends a request, inbound
    0:22:14 configuration request saying this is the magic number that
    0:22:17 I want to use, router 3 is acknowledging this saying
    0:22:20 this magic number is correct.
    0:22:22 Now this phase here inside of LCP, you could also see the
    0:22:27 final result it says the LCP state is open.
    0:22:29 This is where negotiation would or excuse me
    0:22:32 the authentication negotiation would occur, so if we were running
    0:22:37 PAP, CHAP, MS CHAP, EAP
    0:22:40 this is where we would see the individual authentication output
    0:22:44 who was asking to do the authentication
    0:22:48 so who was originating the challenge and then
    0:22:50 what are the particular responses.
    0:22:53 Now any time authentication fails, LCP will fail to get to the
    0:22:58 state "open".
    0:22:59 So if we look at the show interface
    0:23:05 and then the actual link
    0:23:09 we can see that the encapsulation is PPP and LCP is open.
    0:23:14 If LCP does not say open, this is an indication of either a
    0:23:19 layer 1 problem or a layer 2 PPP authentication problem.
    0:23:26 It could be a layer 1 issue like a -- if there's like cross
    0:23:29 talk on the line and the packet is getting dropped
    0:23:33 then there's going to be a problem in the PPP negotiation.
    0:23:38 There's a question. "How are the magic numbers
    0:23:41 assigned allocated?" It's basically going to be like a
    0:23:44 pseudo random algorithm that PPP is using, it doesn't really
    0:23:49 matter what the magic number is, it's only
    0:23:52 significant internally to PPP, it's basically a sequence number
    0:23:56 and it's also used as a seed or a salt value for the
    0:24:00 CHAP authentication algorithm.
    0:24:03 So it makes the MD5 algorithm a little bit more
    0:24:06 secure for CHAP because to break the password
    0:24:12 you would need to know not only the -- what the actual
    0:24:15 clear text string is to put in the MD5, but you would
    0:24:17 also need to know what is the magic number that the neighbors
    0:24:20 negotiated.
    0:24:22 So from our point of view, it really doesn't matter what
    0:24:24 the number is, but PPP internally is using it for
    0:24:28 its negotiation.
    0:24:30 Now we can also see it says for a network control protocol
    0:24:34 NCP, we have one that is open. It is the
    0:24:37 Cisco discovery protocol control protocol, CDP CP
    0:24:41 Basically this means if we look at the show cdp neighbors
    0:24:45 by default CDP is running on the interface.
    0:24:50 So for every payload protocol that runs on top of
    0:24:54 PPP whether it's IP, IP version 6, IPX
    0:25:00 CDP, compression
    0:25:03 they are all going to have individual network control
    0:25:06 protocol negotiation phases where they specify their own
    0:25:10 individual options. Now IP CP for example, this would be where
    0:25:16 we would be negotiating what is the actual address that we
    0:25:19 want to use on the link. This could come from
    0:25:22 a DHCP request, it could come from a static assignment
    0:25:26 then it would also include the peer neighbor route installation.
    0:25:31 So let's say for example we go to router 1
    0:25:35 and we enable IP
    0:25:37 IP address is
    0:25:48 router 3 is going to do the same thing here. On serial 1/2
    0:25:53 IP address is
    0:26:05 Now we can see once IP is configured, now we go
    0:26:09 through the IP CP negotiation phase for internet protocol
    0:26:14 control protocol
    0:26:15 router 3 is basically saying to router 1, "I want to run IP"
    0:26:19 "This is my address."
    0:26:21 Router 1 is replying -- actually here inbound
    0:26:25 configuration ack saying, "I know that you are running IP."
    0:26:28 "I know that this is your address." So once we get
    0:26:31 through this bidirectional negotiation, now the IP CP
    0:26:35 state is open and we're also installing the route to the
    0:26:38 other end of the link, this is the peer neighbor route.
    0:26:41 So this negotiation phase is what allows us to have
    0:26:44 unnumbered links in PPP or completely unrelated
    0:26:48 subnets on both ends of the interface, so let's say for
    0:26:52 example I go back to the link and I say my
    0:26:56 address is
    0:27:05 so basically I'm telling router 1 this is my IP address.
    0:27:09 Router 1 is acknowledging it, router 1 should then install a route
    0:27:12 towards me. If I go to router 1 and look at the routing table
    0:27:18 we can see is installed as a connected route, this is the peer
    0:27:22 neighbor route that's coming from the IP CP negotiation phase
    0:27:25 of PPP.
    0:27:27 So even though they're on two separate subnets
    0:27:30 they still should have IP reachability because IP CP is
    0:27:34 allowing that through the negotiation.
    0:27:39 Now from our point of view from a troubleshooting
    0:27:42 perspective, the main issue that would go along with
    0:27:45 PPP problems is going to be the authentication.
    0:27:49 So let's say that I go to router 3
    0:27:53 and I'm going to shut down the interface
    0:27:58 so this should close LCP
    0:28:02 LCP state is now closed
    0:28:05 and I'm going to enable PPP authentication
    0:28:09 and run let's say MS CHAP
    0:28:26 Now any time you are debugging here PPP negotiation
    0:28:30 you do need to be careful because depending on certain
    0:28:32 configurations, it can generate a lot of output and can be
    0:28:36 very taxing on the command line access process, on the console
    0:28:42 process, but if we look at what happened here
    0:28:46 we'll start at the top of the negotiation, it says
    0:28:49 LCP is coming up.
    0:28:51 I have an outbound configuration request, so I am generating
    0:28:57 a request saying that I want to run MS CHAP
    0:29:00 and this is my magic number. Now router 1 replies saying
    0:29:07 I will run the magic number and I do support that authentication
    0:29:12 protocol, but now we go into our next phase which is the
    0:29:16 actual authentication, router 1 is not configured for this
    0:29:21 so we see that we're going into LCP termination.
    0:29:25 So inbound termination request, outbound termination acknowledgement.
    0:29:29 This is basically router 3 telling router 1 you have to
    0:29:32 shut down the link because you failed authentication.
    0:29:35 The final result is that LCP is closed and the PPP
    0:29:39 negotiation is down, so if I was to look at now the
    0:29:44 show ip interface brief
    0:29:47 we can see the link status is up, but the protocol status
    0:29:51 is down and if we look at the show interface
    0:29:54 serial 1/2
    0:29:59 LCP is termination sent.
    0:30:02 So if we see anything basically that says anything
    0:30:05 other than LCP is open, this is a problem with the
    0:30:09 low level PPP negotiation.
    0:30:11 So either it means it is a physical layer 1 problem
    0:30:14 of the link or it is related to PPP authentication
    0:30:18 which in this case it's authentication because router 1
    0:30:20 is not configured for MS CHAP, router 3 is configured for MS CHAP.
    0:30:27 Now I'm not going to go into all the detail of the different
    0:30:31 PPP authentication methods, you can see this covered in
    0:30:35 a number of different resources we have like the advanced technologies
    0:30:38 class on demand, a lot of the volume 1 stuff and volume 2 stuff
    0:30:41 also covers PPP authentication. If you take a look at that link
    0:30:45 that's on the slide for the understanding debug PPP
    0:30:48 negotiation, it also has links to things about PPP authentication.
    0:30:54 But the key is here you can tell that it is broken because the link
    0:30:58 is up/down and LCP is not open.
    0:31:14 So we should see once authentication is disabled
    0:31:17 we can see now the line protocol status comes back to up.
    0:31:20 When we look at the show interface, LCP is now open
    0:31:25 we proceed on to the NCP negotiations which in this case
    0:31:29 were IP CP and CDP CP
    0:31:34 Ok, so before we proceed on let's take a look at where
    0:31:37 this would be located on the documentation CD
    0:31:40 so I'm going to go back to Cisco's main website here
    0:31:44 Cisco to cisco.com
    0:31:46 and this will be under support
    0:31:51 then either troubleshoot or configure.
    0:31:56 Ok, this is the screen that you should see when you get
    0:31:58 to the actual exam and you open up the documentation.
    0:32:02 Now it either is going to stay, configure or troubleshoot
    0:32:05 but it's going to be going down to the same screen here.
    0:32:08 Now what is different between what we're going to
    0:32:11 look at here and what we would normally use for the exam
    0:32:14 is that for the exam we would normally go to products
    0:32:17 then IOS and then Cisco IOS and then go to the actual release like
    0:32:22 12.4 T
    0:32:23 In this case we are going to go technology.
    0:32:27 Now the technology documentation I do not believe this is available in the
    0:32:31 actual exam. You want to spend some time reading through this
    0:32:34 before you actually get to your exam day
    0:32:37 and what we'll find here for a lot of the different features,
    0:32:40 a lot of the different technologies, this is where there will be
    0:32:44 frequently asked questions along with different troubleshooting guides.
    0:32:49 Now specifically in this case I want to go to WAN
    0:32:53 and then let's say HDLC.
    0:33:06 HDLC configurations.
    0:33:10 Ok, you can see HDLC is very, very, very minimal.
    0:33:13 There's only two different examples. One is just HDLC
    0:33:17 back-to-back, one is ISDN over HDLC, so really there's not
    0:33:20 a lot going on there. If we go back under WAN
    0:33:24 then to PPP
    0:33:31 configuration examples and tech notes
    0:33:40 a lot of times this is where you will find the
    0:33:43 troubleshooting guides.
    0:33:46 Let me try here
    0:33:54 troubleshooting guides
    0:34:01 you'll see for these WAN protocols, there's not a
    0:34:03 whole lot that is related to it. There should be
    0:34:06 the one that said
    0:34:09 understanding the
    0:34:15 PPP output. You can find that link again from the slides that I have
    0:34:19 up there, but you can see there's really not a lot that's
    0:34:22 related to these two WAN protocols directly either
    0:34:25 PPP or HDLC.
    0:34:29 Now again, if you go under WAN, this is also where
    0:34:33 frame relay would be documented.
    0:34:35 So technology, wide are networking, then frame relay
    0:34:40 if we go to configuration guides here
    0:34:46 you see they keep changing this format around of the documentation
    0:34:49 all the time. This is what I'm looking for here.
    0:34:52 Comprehensive guide to configuring and troubleshooting
    0:34:55 frame relay and I believe there's a secondary one that
    0:34:59 is...
    0:35:02 is troubleshooting frame relay, but we'll come back and reference
    0:35:06 this document here in a second here, the troubleshooting guide.
R&S Advanced Troubleshooting Video-on-Demand
Title: R&S Advanced Troubleshooting Video-on-Demand
Duration: 13h 33m
Instructor: Brian McGahan, #8593 CCIEx4, CCDE #2013::13
The CCIE Routing & Switching Advanced Troubleshooting Bootcamp is a combination of lectures focused on structured troubleshooting approach, and advanced hands-on troubleshooting lab scenarios. The class is designed for students seeking to solidify their troubleshooting skills, master structured troubleshooting approach and spot their weak areas. The ultimate goal is fully preparing candidates for the Troubleshooting section of the new CCIE Routing & Switching Exam.
Get instant access to our entire library!
Sign Up

© 2003 - 2015 INE All Rights Reserved