CCIE Pursuit Blog

August 17, 2009

Internetwork Expert Volume IV (Troubleshooting) Workbook Review: Part 3

Once you get the initial configurations loaded you’re ready to begin the lab.  This is when the “fun” begins.  Those of us who are used to starting labs with barebone configurations and searching for a few misconfigurations will be in for a bit of a shock.  This is not how this troubleshooting will go.  You’ll be looking at a fully configured network…which you did not build. It was at this point that I should have realized that this would not be easy and that the 2 hour time limit – which initially sounded like all of the time in the world – would be an issue.

When I tell you that you’re looking at a fully configured network, that means things like QoS, Multicast, and IP Services.  You can start to see how difficult Cisco can make these labs.  Throw in a number of devices that you cannot access and INE’s recommendation that you only use show and debug commands, and you’re looking at a bad day on the CLI.

The lab document starts with a “Baseline” section.  This will give you a list of the devices under your control as well as details about how the network has been configured.  This is broken down by well-known sections.  For instance, Bridging and Switching might tell you which devices are STP roots, which VLANs are present, which flavor of STP is running, if and how VTP is set up, etc.  The IGP section describes the routing protocols, any route filtering, redistribution (yes, there is plenty of that), etc.

I read through the baseline and then started making network maps.  INE has some nice examples of the maps that you’ll want to build and how long it should take in the solution guide:

We recommend making your own diagrams, including the following
information:
• IP addressing + IGPs.
• Layer 2 topology.
• BGP diagram.
• IPv6 topology.
• Multicast and Redistribution diagram.

Overall, don’t spend too much time building the baseline – the goal is to spend around 20 minutes. By the end of the baseline analysis phase, you should have clear understanding of the protocols and applications deployed in your network.

It took me a LOT longer than 20 minutes to get my head around what was going on in the network.  It’s much harder to get quickly up to speed on a complex CCIE network when you haven’t built it from scratch.  :-(

After getting a basic idea of what was going on, it was time to start looking at the tickets.  There are ten tickets, each with a point value between 2 to 4 points.  The total amount of points is 30 points, so each ticket will average 3 points.  Like the “classic lab”, you’ll need to fix each issue completely – no partial points are awarded.  There may also be tickets that you cannot resolve unless you’ve already fixed previous tickets.  For example, ticket 10 in lab 1 has the following requirements:

Ticket 10: Multicast
Note: Prior to starting with this ticket make sure you resolved Tickets 4 and 5

Since you need 80% to pass the troubleshooting portion of the lab, you’ll need to get at least 24 points.  This means that you can only really miss about 2 tickets (depending on point values).

Logging is turned off on the devices.  I would strongly suggest enabling logging buffered on all devices(remove the configuration before finishing the lab).  There are a number of logging messages that will point to some initial issues that you might miss if you’re not on the device when the log is generated.  This way you can issue “show log” and see what’s going on.

Another suggestion: work on the tickets that seem easy first.  Then work on any tickets that are requirements for other tickets.  Finally, work on the tougher tickets last.

I used some of my basic, initial troubleshooting habits to find a couple of issues.  In the lab – after building each section – I do basic troubleshooting.  For instance, once all Layer 2 configuration is complete, I verify that I can ping across each link.  After each IGP configuration, I verify that the proper routes are being advertised and received, as well as pinging (at least a subset) of the routes.  I would suggest putting together a “toolkit” of common commands to run on each device when approaching the troubleshooting section such as ‘show ip int br | e ass’, ‘show ip protocol’, ‘show ip [protocol] route’, etc.

Let’s look one of the (easy) tickets from Lab 1:

Ticket 4: Connectivity Issue
• Another ticket from VLAN7 users. They cannot reach any resource on VLAN 5 – all IP Phones have unregistered, and nothing else works.
• However, they are still able to reach the local resources.
• Using the baseline description as your reference, resolve this issue in optimal manner.

3 Points

You will notice this issue if you do a Layer 2 check by pinging across directly connected links.  Basically, you cannot ping from r4 to sw1 on VLAN41.  Looking at sw1, I could see that the SVI interface for VLAN41 was not up.  Sounds like an easy fix.  Make sure that VLAN 41 has been added to the VLAN database.

Actually, it VLAN41 was in the VLAN database.  The IP addressing was correct.  All of the other SVIs were up and working.  WTF?

Here is the configuration for the SVI:

interface Vlan41
ip address 164.16.47.7 255.255.255.0
ip access-group REMOTE_DESKTOP in
ip pim sparse-dense-mode
ntp broadcast client
ntp broadcast

Hmmm….I’ll bet that INE has a dastardly access-list configured.  Let’s see the configuration for that sucker:

ip access-list extended REMOTE_DESKTOP
dynamic RDP timeout 10 permit tcp any host 164.16.7.100 eq 3389
deny   tcp any host 164.16.7.100 eq 3389
permit ip any any

Oh fucking joy.  A dynamic access-list.  But I don’t see how this would be breaking connectivity, let alone keeping my SVI down.  Just to be sure I removed the ACL.  The SVI remained down, but I did catch a break when issued ‘no shut’ after readding the ACL:

*Mar  1 02:19:56.300: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/14 on VLAN0041.

Interesting.  According to our baseline guidelines sw1 should be the root bridge for all active VLANs.  The initial configuration reflects this:

spanning-tree vlan 1-4094 priority 8192

Fa0/14 is a trunk link to sw2:

interface FastEthernet0/14
switchport trunk encapsulation dot1q
switchport mode trunk
spanning-tree guard root

So it looks like someone is generating a better BPDU for VLAN41.  Wanna bet that it’s either sw3 or sw4 – the two switches that are restricted?  :-)

Rack16SW2#sh spanning-tree root

Root    Hello Max Fwd
Vlan                   Root ID          Cost    Time  Age Dly  Root Port
—————- ——————– ——— —– — —  ————
VLAN0001          8193 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0003          8195 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0005          8197 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0007          8199 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0009          8201 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0013          8205 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0018          8210 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0026          8218 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0041          4137 0012.4337.1880        19    2   20  15  Fa0/17         <-NOTE!
VLAN0043          8235 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0055          8247 0017.0e3f.3900        19    2   20  15  Fa0/14
VLAN0062          8254 0017.0e3f.3900        19    2   20  15  Fa0/14

Rack16SW2#sh spanning-tree vlan 41
VLAN0041
Spanning tree enabled protocol ieee
Root ID    Priority    4137                <-less than 8233 on sw1
Address     0012.4337.1880
Cost        19
Port        19 (FastEthernet0/17)
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

Bridge ID  Priority    32809  (priority 32768 sys-id-ext 41)
Address     001f.9e4a.fa00
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
—————- —- — ——— ——– ——————————–
Fa0/4            Desg FWD 19        128.6    P2p
Fa0/14           Desg FWD 19        128.16   P2p
Fa0/17           Root FWD 19        128.19   P2p             <-goes to sw3 not sw1!

I think that I’ve found my problem.  sw3 is advertising a lower priority for VLAN 41.  I went ahead and set the STP priority to 0 for ALL VLANs.  INE chose to only change VLAN 41.

Me:
Rack16SW1(config)#spanning-tree vlan 1-4094 priority 0

INE:
spanning-tree vlan 41 priority 0

Either way, this unblocked f0/14 for VLAN41 and restored the STP instance on that VLAN, which brought up the SVI…which brought up IP connectivity.  :-)

*Mar  1 02:33:29.608: %SPANTREE-2-ROOTGUARD_UNBLOCK: Root guard unblocking port FastEthernet0/14 on VLAN0041.

That should give you an idea of one of the easier tickets.  Even though this was a fairly easy issue, it threw me off my game because 99.99% of the time when I see an SVI down, it’s because the VLAN is not in the VLAN database.

In the final part of the review I’ll discuss the solution guide as well as my overall impressions.

August 10, 2009

Internetwork Expert Volume IV (Troubleshooting) Workbook Review: Part 2

Access to the Volume IV workbook is the same as for all INE workbooks.  Once you’re logged in you’ll find (at present) three troubleshooting labs available.  The workbook will eventually contain 10 troubleshooting scenarios.  Each lab contains 10 trouble tickets which vary in value from 2 – 4 points.  You’ll also get the lab topology, along with initial configurations and the solution guide.

INE Workbook IV

INE Workbook IV

I rented some rack time at INE’s rack rental company, Graded Labs.  I booked a single, 5.5 hour session and planned to attempt the first two labs.  You’re allotted 2 hours for each lab, so I figured I should be able to complete both labs.  I was very wrong.

Graded Labs has a number of configurations for the INE product line which you can choose to have automatically loaded to your rack.  Unfortunately Graded Labs does not have the configs for the new Volume IV workbook yet.  This means that you will initially need to connect to each device and load in the appropriate config.  I had rented rack 16 and was worried that I would need to parse the initial configurations replacing IP addresses to fit the rack number, but INE has the initial configs for 31 different racks (1-30 and the mysterious rack 42) so you don’t need to go through the configs and change the IP addresses to match the rack.  It was just a matter of cutting and pasting in the appropriate configurations.

Initial Configurations For 31 Racks Included

Initial Configurations For 31 Racks Included

After loading the configurations, it was time to take a look at the lab.  I would very strongly recommend that you take the time to read the Workbook Introduction.  This six page PDF explains INE’s methodological approach to troubleshooting.  You will want to be familiar with it before attempting the labs as it will help you with troubleshooting as well as prepare you for the explanations in the solution guide.

After digesting the Workbook Introduction, it was time to look at the lab.  This is where the first surprises appear.

Lab Do’s and Don’ts:
•  Do not access the routers that are marked as restricted for your access.
•  Do not use the show running-config or show startup-config commands or their equivalents when performing troubleshooting.
•  Do not change or add any IP addresses from the initial configuration unless required for troubleshooting.
•  Do not change any interface encapsulations unless required for troubleshooting.
•  Do not change the console, AUX, and VTY passwords or access methods unless otherwise specified.
•  Do not use any static routes, default routes, default networks, or policy routing unless otherwise specified.
• Save your configurations often.

Those first two restrictions are killers.  While you will use the tried and true INE lab topology for these labs, each lab will include a number of restricted devices – outside of the normally restricted backbone devices.

The topology used for every scenario is the same that we use for all our RS products, including VOL1 (technology- focused labs), VOL2 (configuration mock lab scenarios) and VOL3 (core technologies scenarios).

However, unlike our previous workbooks, we restrict access to some of the devices in the lab topology. For every scenario this “restricted” set may be different and it is clearly outlined in the scenario’s baseline. Using this technique we increase the scenario complexity by allowing candidates to see only “one” side of the problem. When looking at the lab diagram, you will clearly see routers not under your control as being displayed in orange color. Also, when you log onto the “restricted” device, it will warn you using a banner message.

Lab 1 Topology - Note Restricted Devices in Orange

Lab 1 Topology - Note Restricted Devices in Orange

In lab 1 for instance, you are not allowed to access BB1, BB2, BB3, R2, R3, SW3, and SW4.  You’re pretty much on the honor system for the internal network devices as the you’ll be warned by a banner message, but only the first time you connnect (or if you telnet to the device(s)).

For instance, r3 is a restricted device:

Rack16R1#telnet 164.16.35.3
Trying 164.16.35.3 … Open

User Access Verification

Username: cisco
Password:

*****************************WARNING******************************
*                                                                *
*           Per the requirements of this scenario                *
*         You are not allowed to access this router              *
*                                                                *
*****************************WARNING******************************

Rack16R3>

You will not see the exec banner as long as the session to the console line is open from from the access server.  Regardless, it is important that you do not access the verboten devices during the lab.

While the restricted devices threw me an unexpected curve, it was the second requirement that really floored me.

In addition to the above restriction, we highly encourage you not using the show running-configuration, show startup-configuration commands or any other command that shows you the textual representation of the router’s configuration. This requirement makes you focus on using the show and debugging commands, which is invaluable when troubleshooting the real-world scenarios.

Our ultimate goal is not only prepare you for passing the Troubleshooting section of the CCIE R&S lab exam, but also to teach you a structured troubleshooting approach. As opposed to simple guessing and peeking at the routers running configurations you should learn using the debugging commands and interpreting various show commands output.

INE is serious about this too.  The solution guides will only use show and debugging commands to determine the root cause of each issue.  I don’t know if this will be a requirement in the actual lab; I certainly hope not!  In “real life” though, the use of debug commands is pretty much forbidden in the environments that I’ve worked in.  There’s a saying at my job “If you turn on a debugging command you had better have created a network change ticket, otherwise you’ve just created a job change ticket.”  Still, using the debug commands is a very good way to understand the underlying technology and there are some instances where you will get important troubleshooting information for a debug command that you cannot get in a show command.

For every ticket, we are going to follow the same structured procedure to resolve the issue.

Here is an outline of this procedure:

1. Build and Analyze the Baseline
2. Analyze the Symptoms (propose hypothesis)
3. Isolate the issue (gather more symptoms)
4. Fix the Issue (by comparing to the Baseline)

We recommend making your own diagrams, including the following
information:
• IP addressing + IGPs.
• Layer 2 topology.
• BGP diagram.
• IPv6 topology.
• Multicast and Redistribution diagram.

Overall, don’t spend too much time building the baseline – the goal is to spend around 20 minutes. By the end of the baseline analysis phase, you should have clear understanding of the protocols and applications deployed in your network.

This is a brief review of the systematic troubleshooting procedure that you’ll be using for the labs.  You’ll be familiar with the topology drawing bit from your practices labs.  Although, I did pick up some good tips from the solution guide about making topology maps.

Okay, enough jibba jabba about the labs.  Let’s actually dive into one.  That will be the focus of the next part of the review.

August 7, 2009

Internetwork Expert Volume IV (Troubleshooting) Workbook Review: Part 1

As we’re all painfully aware, the next version (4.0) of the CCIE lab exam goes live this October.  For those of us who did not nab a date before the cutover date, we’re looking at a different beast come October.  In addition to a number of new technologies (such as MPLS and Zone Based Firewall) and the dread Core Knowledge questions, there will be a brand new addition: troubleshooting.  Between the Core Knowledge section and the actual lab exam, there will be a troubleshooting section.  While details are still a little vague, here’s what Cisco has said about this section(may require CCO login):

Troubleshooting is allotted two of the eight hours required for the CCIE lab exam. Candidates will be presented with a series of trouble tickets for preconfigured networks and will need to diagnose and resolve the fault or faults. As with previous CCIE labs, the network will need to be up and running for the candidate to receive credit.  Candidates who finish the troubleshooting section early can move on to the configuration section, but they will not be allowed to go back to the troubleshooting section.

Here are some additional details culled from a recent Ask The Expert Section:

  • The Troubleshooting section will be independent from the Configuration section, i.e., it will be presented on a different scenario.
  • Once you finish the Troubleshooting you will move to the Configuration section that will be presented on a new scenario or topology.
  • The Troubleshooting section will have a maximum of 2 hours. The candidate will be presented a series of questions or ‘trouble tickets’ for a given scenario or topology. The referred topology will pre-configured.
  • Based on the information provided such as IP addressing diagrams, IGP routing diagrams, and so on you will work to identify and fix the issues. You will be given points for working scenarios.
  • The Troubleshooting section will have a certain number of trouble tickets and points allocated to the section. You will receive credits for the points you get. Your score on this section will show as, 30%, or 50%, or 80%, and so on.
  • You will need to get a minimum of 80% on each section of the exam to pass on the CCIE lab exam.
  • Yes, we are planning to post a sample Troubleshooting questions/trouble ticket for study reference.

Internetwork Expert has a poll up asking CCIE candidates which part of the new lab format scares them the most.  Troubleshooting is the number one choice.

I’ll admit that when I first heard about the addition of troubleshooting to the lab, I was unconcerned.  While I don’t spend any time(outside of practice labs) building complex OSPF networks, I do troubleshoot networks for probably a good 30% – 50% of each workday(not to mention after hours when on call).  Plus, I’ve always been pretty good at the initial troubleshooting sections in the vendor labs.

Petr Lapukhov from INE emailed me recently and gave me access to the first couple of labs in the new Internetwork Expert Volume IV workbook.  This is INE’s new product covering the troubleshooting section of the lab.  I agreed to try the first couple of labs and write my thoughts.  My first thought? I vastly underestimated how potentially difficult the new troubleshooting section could be!

While I have spent a considerable amount of time troubleshooting networks over the last ten (sigh) years, they’ve always been MY networks.  Well, at least they’ve always been networks with which I was very familiar.  So if a server goon bitches about not being able to ping his heart beat IP address, I can quickly re-educate (an exercise in futility) him about the fact that this network exists on a layer-2 only network that is not trunked nor associated with an SVI so he’ll only be able to ping other heart beat IPs sourced from the heart beat IP address on his box.  If I was not aware of the design of this network, then I would have to start with the usual battery of pings and traceroutes to (hopefully) get to the same conclusion.  In other words, familiarity with the network design will make troubleshooting much easier and quicker.  I also overlooked the fact that a good 90% of my daily troubleshooting is really mundane shit like checking speed/duplex, verifying MAC addresses, checking ARP tables, etc.  It’s thankfully very rare that I ever troubleshoot any complicated layer 3 issues.

So while I might feel (justified or not) that I have a lot of troubleshooting experience, a lot of that experience will be worthless in a lab scenerio…as I was soon to discover.  :-)

April 28, 2008

Internetwork Expert Volume II: Lab 5 – Section 0

Troubleshooting – 2 Points

The lab advised that there are two errors.  I found three errors.  The IE solution guide does not list any errors, so you’re on your own.

Troubleshooting

1) IP address wrong on r1’s s0/0 interface

interface Serial0/0
 ip address 126.1.13.1 255.255.255.0
 encapsulation frame-relay
 frame-relay lmi-type cisco

r1(config)#int s0/0
r1(config-if)#ip add 162.1.13.1 255.255.255.0

2) Duplicate IP address on sw1

sw1#
00:24:23: %IP-4-DUPADDR: Duplicate address 162.1.38.8 on FastEthernet0/15, sourced by 0012.009c.ca42

sw1#sh run int fa0/15
Building configuration…

Current configuration : 86 bytes
!
interface FastEthernet0/15
 no switchport
 ip address 162.1.38.8 255.255.255.0 
end

sw1#sh cdp neigh fa0/15 detail
————————-
Device ID: sw2
Entry address(es):
  IP address: 162.1.38.8 
Platform: cisco WS-C3560-48PS,  Capabilities: Switch IGMP
Interface: FastEthernet0/15,  Port ID (outgoing port): FastEthernet0/15
Holdtime : 157 sec
—output truncated—

The network diagram shows that this address should be assigned to int vlan 8 on sw2:

sw2#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan8                  162.1.8.8       YES manual down                  down

Need to remove the address from sw1.

sw1(config)#int fa0/15
sw1(config-if)#no ip add
sw1(config-if)#switchport

3) Serial link on r4 should not be running Frame Relay encapsulation:

r4(config)#do sh run int s0/1
Building configuration…

Current configuration : 91 bytes
!
interface Serial0/1
 ip address 162.1.45.4 255.255.255.0
 encapsulation frame-relay
end

r4(config)#int s0/1
r4(config-if)#no encap frame
r4(config-if)#sh
r4(config-if)#no sh

r4(config-if)#do ping 162.1.45.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 162.1.45.5, timeout is 2 seconds:
!!!!!

April 9, 2008

Internetwork Expert Volume III: Lab 5 – Section 1

Troubleshooting – 2 Points

There are two faults in the initial configurations.  I actually found three and the one that was not listed in the IE Solution Guide was the most devious of the three.

1)  sw3 and sw4 both have an intitial configuration error on their fa0/16 interfaces:

interface FastEthernet0/16
 ip address 128.1.109.9 255.255.255.0

The “no switchport” command for is needed for these routed interfaces.  Without this command, IOS chokes on the ‘ip address’ command and you’re left with an ordinary L2 interface.

2)  Incorrect IP addresses on SVIs on sw1:

sw1(config)#do sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan27                 128.1.27.7      YES manual up                    up
Vlan72                 192.10.1.7      YES manual up                    up
Loopback0              150.1.7.7       YES manual up                    up

You just need to swap the IP addresses.

3)  VTP password on sw2 is CISC0 (last character is a zero) rather than CISCO.  This is the fault that is not listed in the solution guide.  I occurs on only one switch, and that switch is the only one that has trunking to the other three switches, so if this was an unintended fault, it was a doozy.   :-)

 

February 18, 2008

Internetwork Expert Volume II: Lab 12 – Section 1

Troubleshooting – 3 Points

There are three initial faults in this lab.  The troubleshooting section has this interesting requirement:

“Use the minimum commands needed to solve these issues.”

1) PPP configuration on r1

I had issues right away.  The initial configuration for r1’s s0/1 interface is as follows: 

interface Serial0/1
 ip address 129.1.13.1 255.255.255.0
 ppp pap sent-username PPP password 0 CISCO
 no shutdown

The problem with this is that the router will not accept this configuration because it’s missing “encap ppp” and “ppp authentication pap”:

r1(config-if)#interface Serial0/1
r1(config-if)# ip address 129.1.13.1 255.255.255.0
r1(config-if)# ppp pap sent-username PPP password 0 CISCO
                        ^
% Invalid input detected at ‘^’ marker.

The interface will end up with only the IP address configured:

interface Serial0/1
 ip address 129.1.13.1 255.255.255.0

This is where the “minimal configuration” requirement comes into play.  r1 and r2 each have point-to-point serial connections that terminate on r3.  r3 is running ppp with pap authentication.  It is expecting a username of “PAP” and a password of “CISCO”.

r1:
interface Serial0/1
 ip address 129.1.13.1 255.255.255.0   <- HDLC encapsulation (default)

r2:
interface Serial0/1/0
 ip address 129.1.23.2 255.255.255.0
 encapsulation ppp
 ppp pap sent-username PPPpassword 0 CISCO  <-wrong username

r3:
username PAP password 0 CISCO
!
interface Serial0/2:0
 ip address 129.1.13.3 255.255.255.0
 encapsulation ppp
 ppp authentication pap
!
interface Serial0/3:0
 ip address 129.1.23.3 255.255.255.0
 encapsulation ppp
 ppp authentication pap

The solution guide says that the fix is to change the password on r3 from “PAP” to “PPP”.  That would make sense and would meet the “minimum configuration” requirement IF the PPP configuration on r1 wasn’t messed up.  Due to the intial configuration snafu, I did the following:

r1:
r1(config)#int s0/1
r1(config-if)#enc ppp
r1(config-if)#ppp pap sent-username PAPpass CISCO

r2:
r2(config-if)#noppp pap sent-username PPPpassword 0 CISCO
r2(config-if)#ppp pap sent-user PAPpass CISCO

2) sw1’s SVI interface Vlan7 should be Vlan 17

sw1#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan7                  129.1.17.7      YES NVRAM  down                  down

after:
sw1#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan17                 129.1.17.7      YES manual down                  down

3) r4’s fa0/1 has wrong IP address

I didn’t catch this one until later.  The first octet is incorrect:

interface FastEthernet0/1
 ip address 192.1.46.4 255.255.255.0

After:
interface FastEthernet0/1
 ip address 129.1.46.4 255.255.255.0 

4?)  sw1’s fa0/7 and fa0/8 should not be assigned to a VLAN???

Task 2.1 requires you to configure sw1 to match this output exactly:

sw1(config)#do sh vlan br | e (unsup|^1 |^ )

VLAN Name                             Status    Ports
—- ——————————– ——— ——————————-
3    VLAN0003                         active    Fa0/3
17   VLAN0017                         active    Fa0/1
22   VLAN0022                         active
33   VLAN0033                         active
38   VLAN0038                         active
45   VLAN0045                         active
46   VLAN0046                         active
58   VLAN0058                         active    Fa0/5 

Here’s what I had:

sw1(config-if)#do sh vlan br | e (unsup|^1 |^ )

VLAN Name                             Status    Ports
—- ——————————– ——— ——————————-
3    VLAN0003                         active    Fa0/3
17   VLAN0017                         active    Fa0/1, Fa0/7, Fa0/8
22   VLAN0022                         active
33   VLAN0033                         active
38   VLAN0038                         active
45   VLAN0045                         active
46   VLAN0046                         active
58   VLAN0058                         active    Fa0/5

sw1(config-if)#do sh run int fa0/7
interface FastEthernet0/7
 switchport access vlan 17 

sw1(config-if)#do sh run int fa0/8
interface FastEthernet0/8
 switchport access vlan 17

I defaulted the interfaces and my output match the requirement.  Unfortunately, this would come back to bite me in the butt later.  I think that the problem was a misprint in the lab guide and not an initial fault.

January 26, 2008

Internetwork Expert Volume III: Lab 4 – Section 1

Troubleshooting – 2 Points

There are supposedly two faults in the initial configurations.  There are at least four faults and as many as six – depending on how you count them.  I’ll just list the two (I counted this as four because there were four misaddressed IP addresses) that IE shows in the solution guide.  I will point out the other two in the sections that I discovered them.

1) VLAN 3 is configured with the wrong subnet (sw3 and r3)

r3#sh ip int br | i net0/1
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/1            152.1.39.3      YES manual up                    up

r3(config)#int fa0/1
r3(config-if)#ip add 152.1.3.3 255.255.255.0

sw3#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan39                 152.1.39.9      YES manual down                  down

sw3(config)#no int vlan39
sw3(config)#no vlan39
sw3(config)#vlan 3
sw3(config)#int vlan 3
sw3(config-if)#ip add 152.1.3.9 255.255.255.0

2) VLAN 5 is configured with the wrong subnet (sw4 and r5)

r5#sh ip int br | i net0/1
FastEthernet0/1            152.1.105.5     YES manual up                    up

r5(config)#int fa0/1
r5(config-if)#ip add 152.1.5.5 255.255.255.0

sw4#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
Vlan105                152.1.105.10    YES manual down                  down

sw3(config)#no int vlan105
sw3(config)#no vlan 105
sw3(config)#vlan 5
sw3(config)#int vlan 5
sw3(config-if)#ip add 152.1.3.9 255.255.255.0

January 17, 2008

Internetwork Expert Volume III: Lab 2 – Section 1

Troubleshooting – 2 Points

It’s the little things that throw you off.  My wife has my laptop so I’m using an old desktop to complete this lab.  The position of the control key is different than any other keyboard that I use.  So every time that I break out of configuration mode cntl+z or go back to the access server cntl+shift+6 x, I’m tripping over myself.  Yet another good lesson before the lab.

There are faults to find in this lab.  I found the first error in my initial examination of the network (checking that all interfaces are configured per the lab diagram and looking anything funky in the initial configurations):

1)  Incorrect mask on r3’s fa0/0 (should be /24 and not /25):

r3#sh run int fa0/0
interface FastEthernet0/0
 ip address 192.10.1.3 255.255.255.128
 duplex auto
 speed auto

The second error was found later on in the lab.  I overlooked this because although the interface did not have an IP address configured, sometimes this is by design as you are asked to configure it later in the lab.  As it turned out I needed to make a couple of changes to bring up VLAN23.

2) r3’s fa0/1 is not configured with an IP address

r3(config-router)#do sh run int fa0/1
interface FastEthernet0/1
 no ip address
 shutdown

 duplex auto
 speed auto

r3(config-router)#int fa0/1
r3(config-if)#desc ->r2 vlan 23
r3(config-if)#ip add 161.1.23.3 255.255.255.0
r3(config-if)#no sh

r3(config-router)#do sh cdp neigh fa0/1
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
                  S – Switch, H – Host, I – IGMP, r – Repeater

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
sw3              Fas 0/1            176        R S I      WS-C3560- Fas 0/3

Need to add vlan 23

sw3(config)#do sh run int fa0/3
interface FastEthernet0/3
end

I need to assign this port to VLAN23:
sw3(config)#int fa0/3
sw3(config-if)#swi acc vla 23
sw3(config-if)#^Z

r3(config-router)#do p 161.1.23.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 161.1.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

The interesting thing about this section is that the IE solution guide shows the second error as r3′ s Frame Relay interfaces being flopped.  My initial configuration did not contain this error.

January 6, 2008

Internetwork Expert Volume III: Lab 1 – Section 1

1 Troubleshooting

First error:

I initially missed this error on my fly-by at the beginning of the lab, but caught it later on.  It was an SVI that had been configured with an incorrect second octet:

sw2(config)#do sh run int vlan82
interface Vlan82
 ip address 192.1.1.8 255.255.255.0
end

sw2(config)#int vlan82
sw2(config-if)#ip add 192.10.1.8 255.255.255.0

Second error:

The second error was a little more complicated, but easier to spot as you won’t be able to build your Layer 3 Etherchannels until you fix it.

As you try to configure a Layer 3 Etherchannel with the IP address and mask listed on the topology, you’ll encounter the following error:

sw2(config-if)#ip add 140.1.0.8 255.255.255.128
Bad mask /25 for address 140.1.0.8

If you take a look at the final octet of the address and the mask, you’ll find that the address is in the zero (140.1.0.0) subnet:

Address  .8    0|0001000
Mask     .128  1|0000000

This should not be a problem as “ip subnet-zero” is enabled by default:

ip subnet-zero

But, IE turned it off in the initial configuration:

sw2(config-if)#do sh run | i subnet-zero
no ip subnet-zero

sw2(config-if)#ip subnet-zero
sw2(config)#int po23
sw2(config-if)#ip add 140.1.0.8 255.255.255.128

December 31, 2007

Internetwork Expert Volume III: Lab 3 – Section 1

1 Troubleshooting

Although this is the first section, you will very rarely discover the two errors in the network right off the bat (or in the 10 minutes assigned to this task).  It’s a better strategy to make an initial check of the network for obvious errors and then look closer at the devices once you start configuring them.  In most cases the errors will prevent you from successfully completing a task so they’ll be quite obvious once you encounter them.

In this lab I quickly found one of the errors because it was on the first device that I was configuring:

sw1#
01:14:53: %IP-4-DUPADDR: Duplicate address 190.1.17.1 on FastEthernet0/1, sourced by 0011.93b0.7640

Initial config error or just my screw up? [I have to alter the initial configurations to work on my rack so it is possible that I accidentally changed the IP address.  I reviewed the intial configuration and found that it was not my mistake.]  A quick look at sw1 and r1 shows that they are sharing an IP address:

sw1#sh ip int br | e ass
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/1 190.1.17.1      YES manual up                    up
Loopback0              150.1.7.7       YES manual up                    up

r1#sh ip int br | e ass
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0  190.1.17.1      YES manual up                    up
Loopback0                  150.1.1.1       YES manual up                    up

sw1 should be using the .7 address:

sw1(config)#int fa0/1
sw1(config-if)#desc ->r1 fa0/0
sw1(config-if)#ip add 190.1.17.7 255.255.255.0
sw1(config-if)#^Z

One error down!

The second error popped up later (still in the layer 2 configuration though).  I was configuring an SVI on sw3:

sw3(config-if)#int vlan 2569
sw3(config-if)#ip add 190.1.0.9 255.255.255.0
190.1.0.0 overlaps with Vlan2596
Interface              IP-Address      OK? Method Status                Protocol
Vlan2596               190.1.0.9       YES manual down                  down

Nicely played IE.  :-)  There was an existing SVI configured that had the last two digits transposed.  I got rid of that SVI and configured the correct one:

sw3(config-if)#no int vlan2596
sw3(config)#int vlan 2569
sw3(config-if)#ip add 190.1.0.9 255.255.255.0
sw3(config-if)#no sh

sw3(config-if)#do sh ip int br | i Vlan
Interface              IP-Address      OK? Method Status                Protocol
Vlan2569            190.1.0.9       YES manual up                    up

Next Page »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 114 other followers