OSPF Stub versus Totally Stubby Area Design Considerations

Recently, I couldn't sleep, so (naturally) my mind started wandering and I started thinking about how OSPF areas would converge if there are multiple links out of the area.  So, I drew up a quick lab and I'd like to share it with you.

Here is my hand-drawn diagram using my Wipebook:

On the link 10.2.3.0 /30, R3 should be .2, not .3.  Sorry for the typo.

And here is a much more legible version using Dia:

I chose to run this lab on my home lab instead of GNS3 since I wanted to add a few Layer 2 switches.

The equipment in this lab:

2) 1721 routers (R1 and R2)

1) 2621 router (R3)

2) 3550 switches (SW1 and SW2)

2) 2950 switches (AS1 and AS2)

I'm using serial connections between all of the routers (10.1.2.0, 10.1.3.0 and 10.2.3.0).  Ethernet connections on all the links connected from SW1 and SW2.

As you can see from the diagrams, the way that Area 11 extends to the routers and Area 22 is only extended to the first Layer 3 switch.  The reason I did this was to make the Link State Databases different on the Layer 3 switches.  From here we are going to change the area types and watch how the routing tables change on SW1 and SW2.  We'll also consider how traffic flows are going to change as we change the area types.

I cranked up the speed on the serial connections to 1,000,000 Kbits and left the Ethernet connections at 100,000 Kbits (FastEthernet) that way the links between the routers are the faster paths and I also changed the OSPF auto-cost reference-bandwidth to 1000 Mbits.  This way the preferred links will be the serial links.  Additionally, I've set R3 as the designated router for both of the Ethernet networks (10.13.1.0 and 10.23.2.0).

Since most of the changes we make will affect SW1, let's start with a baseline of SW1's OSPF database and SW1's IP routing table.

SW1's OSPF database:

SW1's IP routing table:

SW1 has all of the links and is load balancing when possible (to 2.2.2.2 and 10.1.3.0).  Also, note that there is no gateway of last resort (default gateway) on this topology.

Let's head over to R3 since that is at the center of the topology.

R3's OSPF database:

R3's IP routing table:

So, what are the different types of areas that Areas 11 and 22 can be?

Stub Area

Totally Stubby Area

Not-So-Stubby Area (NSSA)

Totally Not-So-Stubby Area (Totally NSSA)

Since I won't be adding an Autonomous System Boarder Router (ASBR) to this lab, let's focus on stub area versus totally stubby area.

Stub Area

Let's start with a stub area.  In a stub area, the Area Boarder Routers (ABRs) inject a default route into the area.  

Under the OSPF configuration on R1, R3, and SW1, we add the line: area 11 stub

Let's look at the IP routing table on R3:

No changes are made to R3's table.  Let's take a look at R3's OSPF database:

The main item to notice is the addition of 0.0.0.0 from 1.1.1.1 and 3.3.3.3 into Area 11.  Let's see how SW1 is viewing Area 11 now.

Here we can see the addition of 0.0.0.0 to SW1's OSPF database as well.

SW1's IP routing table:

Here we see that the gateway of last resort has changed to 10.13.1.2 and that 0.0.0.0/0 is load balancing between 10.13.1.2 and 10.13.1.1.  SW1 still has all of the links in the routing table since all of the links are part of the same OSPF network.  By changing Area 11 into a stub area, all we have done is added a load balanced default route from SW1 to R1 and to R3.

Totally Stubby Area

A totally stubby area removes all of the interarea entries from the area and relies on a default route for traffic leaving the area.

To configure this in this lab, we add the line: area 11 stub no-summary to R1 and R3.  We can add the line to SW1 as well (just for consistency), but this command only needs to be added at the ABRs since they are the devices that will be injecting the information into the area.

Starting with R3's OSPF database again:

The Summary Net Link States (Area 11) is reduced to only a default route.

R3's routing table is unchanged.

Over to SW1 now:

Just as R3 reported, the Summary Net Link States (Area 11) is reduced to a default route.

SW1's routing table:

SW1 now has a dramatically reduced routing table.  The table now holds the three directly connected networks and then the load balanced default route to R1 and R3.

But before we do a dance of joy, what does having a load balanced default route really do for Area 11?

In this case, it means that all traffic leaving SW1 to anywhere outside of Area 11 will be load balanced (alternating packets) to R1 and to R3.  Is that a problem?  Sort of is, in my opinion.

Let's do a traceroute from SW1 to 1.1.1.1:

Load balanced between R1 and R3 as we expected.  However, 1.1.1.1 is directly connected to R1.  So, packet 2 needed to take an extra hop from R3 to R1 via 10.1.3.0 /30.

Going to 2.2.2.2, this is not as big of a deal since R1 and R3 have a direct link of equal bandwidth to R2.

Things get a little weird when we try to send data from SW1 to SW2.

First, traffic is load balanced to R1 and to R3 just as before.  But when we look at the routing table of R1 to 5.5.5.5, we have load balancing there as well since the link costs are the same from R1 to SW2 (via R3 and via R2).

If we had a small flow of 16 packets that needed to be sent from SW1 to SW2, 8 packets would be sent to R1 and 8 packets would be sent to R3.  Of the 8 packets sent to R1, 4 would go to R2 and 4 would go to R3 (and those 4 packets would have extra latency having gone to R1 first).  SW2 would receive 4 packets from R2 and 12 from R3.

If Area 11 was left as a stub area, SW1 would have an entry to 5.5.5.5 via R3.  R3 would then send the traffic directly to SW2.  Simple and deterministic.  Easy to troubleshoot and easy to follow the path.

But where this is now a totally stubby area, there is not an entry for 5.5.5.5 in SW1's routing table, the traffic is balanced to R1 and to R3.  R1 then load balances the traffic between R2 and R3.  Not very efficient, in my opinion.

However, totally stubby areas are great when there is a single entry and single exit point for an area.  If we were to convert Area 22 into a totally stubby area, we would not see an impact on SW2's routing table since it is an ABR, but we can reduce the size of SW2's OSPF database by making Area 22 a totally stubby area.

SW2's OSPF database as a normal area:

SW2's OSPF database as a totally stubby area:

Notice that the Summary Net Link States (Area 22) shrinks to a single entry of 0.0.0.0.

If there were another router downstream from SW2, the routing table would have the links within the area (such as 192.168.22.0 /24) and a default route to SW2.

Let's add a router to Area 22 and see how the OSPF database and IP routing table look from within a totally stubby area.

Here is the topology with R4 added via Dia:

R4's OSPF database:

Super small OSPF database.  Router Link States for the two routers (SW2 and R4), a Net Link State for the broadcast network of 192.168.22.0, and a Summary Net Link State with a default network out of the area.

And a super small routing table.  One entry for the connected network and a default route to leave the area.  If there was a loopback and a network statement to include that loopback, there would be three entries.

To summarize this post:

With multiple exit points from an area, a stub area might be a good idea to help load balance traffic out of the area.  But it also depends on how the backbone area is engineered.  A stub area will shrink the OSPF database if there are a lot of external OSPF networks.

Additionally, making the area a totally stubby area might cause traffic to become even more diffused.  This also depends on how the backbone area is engineered.  But for an area with only a single exit point, totally stubby areas can dramatically reduce the size of both the OSPF database and the IP routing table.

Please contact me if you have any questions on this.

Thank you for reading!

CCNP TSHOOT Takeaways and Strategy

Yesterday, I took and passed the CCNP TSHOOT exam.  I already passed the SWITCH and ROUTE exams, so I've completed the CCNP R&S Certification!

As far as the TSHOOT exam, I found it to be almost fun and not nearly as intimidating as the SWITCH and ROUTE exams.  However, I did run into a very frustrating item.

Lack of available commands.

I was thinking that all of the typical Cisco IOS commands would be available, but I was blindsided and had to regroup on the first two tickets.

All of the following commands are NOT available:

show interface status

show ip interface brief

show run interface ***
show run | section (eigrp | ospf | bgp)
traceroute (or 'tracert' from the clients)

Therefore, the only way to see a section of the running configuration is to do a 'show run'.  That's it.  You are forced to scroll up and down as needed.  On a few of the trouble tickets, I found it best to write a shorthand version of a section of the running config (like access list entries) on the laminated sheet and then scroll up to see how the access list entries are applied.  Not having the 'show run interface ***' command was the most frustrating.

Here was my strategy for studying for the CCNP TSHOOT exam:

1)  Build the topology on a home lab.  Cisco provides the entire topology and can be downloaded from Cisco's site:

https://learningnetwork.cisco.com/servlet/JiveServlet/previewBody/6741-102-1-23100/TSHOOT%20Exam%20Topology.pdf

I was one router short from my CCNP ROUTE lab, so I acquired a fourth 1721 to finish it off.  Then, I went through the .pdf and set up the topology exactly.  There are a few items that are not given on the map: the loopbacks and the OSPF router-ids on the routers.  In fact, there is a second loopback on R4 (and it does tie into one of the tickets).  I built and rebuilt the topology three times.

2)  Print out a copy of each running config and spend some time memorizing it.  It won't be identical to what you will see on the exam, but it will help you to spot differences.

3)  Break a section of the topology and hook up a computer to the ASW1 and start troubleshooting from the computer first.  For example, break the trunk configuration between ASW1 and DSW1.  Then perform an 'ipconfig /release' and 'ipconfig /renew' and observe how the computer responds (no IP address since the DHCP server is located at R4).  Break one of the links between R3 and R4, break OSPF somewhere, break EIGRP, etc. and then repair the problem.

4)  Read the following books:

  CCNP TSHOOT Official Certification Guide (I went through this great book three times and took extensive notes)
  CCNP TSHOOT Foundation Learning Guide
  CCNP TSHOOT Quick Reference

Since this exam covers topics from the SWITCH and ROUTE exams, I refreshed my memory with the notes I took for those exams.

5)  Practice what you want to write down on the laminated card.  I used this strategy after not passing my first attempt at the CCNA.  Having a plan on what you want to have notes on before the exam is crucial.

I found the following strategy to work really well for the exam itself:

1)  Set up your notes on the laminated card during the tutorial time.  Here is what I wrote on the card and then followed them in order on each ticket:

Client 1
  ipconfig
  ping

Switches
  show interface status (not available on the exam!  Use 'show ip interface ***' instead.)
  show interface trunk
  show vlan ('show vlan brief' is not available)
  show spanning-tree (by the way, 'show spanning-tree summary' is not available)

Routers (including DSW1 and DSW2)
  show ip interface ***
  show ip protocols
  show ip eigrp interfaces (only applicable on DSW1, DSW2 and R4)
  show ip eigrp neighbors (only applicable on DSW1, DSW2 and R4)
  show ip eigrp topology (only applicable on DSW1, DSW2 and R4)
  show ip ospf interfaces (only applicable on R1, R2, R3, and R4)
  show ip ospf neighbors (only applicable on R1, R2, R3, and R4)
  show ip ospf database (only applicable on R1, R2, R3, and R4)
  show ip bgp neighbors (only applicable on R1)
  show ip bgp (only applicable on R1)
  show ip route
 
  show run ('show run | section' and 'show run interface ***' are not available)

With those commands you will have a great place to start troubleshooting.  Be sure to follow the commands in that order.  If EIGRP or OSPF are not running on the interface, then there is no way a neighborship can form.  If the neighborship has not formed, then the routes cannot be added to the topology or database.  If the routes are not in the topology or database, then they cannot be added to the routing table ('show ip route').

2)  Start each ticket from Client 1 and issue the 'ipconfig' command.  If you have a 169.x.x.x address, start looking at the ASW1 configuration, then to DSW1 and further.  If it has a 10.2.1.3 address, start pinging each IP address in order.  I also wrote these IP addresses on the laminated card so I didn't have to jump back and forth to the maps.

  10.2.1.254 (default gateway per by HSRP configuration)
  10.2.1.1 (DSW1)
  10.2.1.2 (DSW2; probably not necessary to ping, but I did)
  10.1.4.6 (DSW1)
  10.1.4.5 (R4)
  10.1.1.10 (R4)
  10.1.1.9 (R3)
  10.1.1.6 (R3)
  10.1.1.5 (R2)
  10.1.1.2 (R2)
  10.1.1.1 (R1)
  209.65.200.225 (R1)
  209.65.200.224 (ISP router)
  209.65.200.241 ('web server' on most of the tickets)

All of these addresses are on the Layer 2/3 map given on the above .pdf.  Since 'traceroute' is not available, 'ping' is your best friend on this exam.  Where the ping stops responding is the best place to start.

I also brought up both devices on the same link to compare configurations.  For example, if the ping stopped at R3, I brought up the console window for R3 and R4.  I then ran through my 'routers' script ('show ip interface ***', 'show ip protocols', and so on) on both devices until I found the problem.

With all the reading, all the preparation on the SWITCH and ROUTE exams, being very familiar with the topology and my lab configurations, and having my 'scripts', I was able to not only pass the exam, I scored a perfect 1000!

If you have any questions or comments, please submit them below.

Thank you for reading!

On to the CCIE next!

Passed the CCNP ROUTE exam today; Exam takeaways

Day 1238 on my Cisco study chain resulted in a pass on the CCNP ROUTE exam.  Scored a 941 out of 1000.  I was given 50 questions and needed a 790 to pass.  I was given 120 minutes and I finished with about 30 minutes to spare.  Looking back, I should have slowed down a bit in the labs, but from my first CCNA exam attempt (when I ran out of time with 3 questions to go and missed passing the test by 7 points), I push myself to work quickly.  Too bad Cisco doesn't allow us to go back through the test to see if we would like to change an answer.

On the major topics, I did pretty well:

Implement an EIGRP based solution: 93%
Implement a multi area OSPF network: 100%
Implement an eBGP based solution: 100%
Implement an IPv6 based solution: 100%
Implement an IPv4 or IPv6 based redistribution solution: 89%
Implement Layer 3 Path Control solution: 100%

But...

Implement basic teleworker and branch services:  0%

So, that 0% is super embarrassing.  Obviously, it wasn't a major part of the exam, but I gave away points on my overall score by missing those questions.  The only questions that come to mind had to do with GRE tunnels.  To be honest, I did not spend much time on GRE tunnels (obviously!) and most of the materials (including Cisco Press ebooks) did not make this a focal point at all.  So, I felt blindsided by those questions.  I gave them my best shot, but I completely tanked on those questions.

Some of the lab/simlets are goofy.  For example, not all the routes will show up on a remote router, but the pings will work both directions.  There was also a line in another scenario that said "it needs to respond to a ping and telnet", but when I ran the telnet command to test, the telnet command failed and wasn't an option.  So, either I misunderstood how to test the telnet or I misconfigured the redistribution.  The traceroute followed the correct path, but maybe I missed something.  Either way, I think that's why I scored an 89% on the redistribution section.

The main takeaways from my CCNP ROUTE experience:

• Focus on EIGRP and OSPF.  Theory and implementation.  There are a couple of simlets for both protocols.
• BGP was not covered as much as I expected.  All theory; no simlets.
• There is a Policy Based Routing (PBR) simlet, so have a solid understanding of ACLs and route maps because there are questions where you read through a section of a router config and need to explain what the route map does to the traffic.
• Not a lot of IPv6, but 
• Lastly, know your stuff when it comes to GRE!

Overall, I feel like it is a fair exam and (other than the GRE section) I felt prepared for everything I was tested on.  And while I would have loved to score a 1000, a pass is a pass!

I'm gong to spend the next few weeks learning about GRE while starting my CCNP TSHOOT prep.  Gotta keep that chain going...

In Pursuit of Mastery

Lately, I've noticed a trend on motivational and educational books and websites:  mastery.

One of the most sited concepts is the idea of becoming an expert or a master after 10,000 hours or practice or work:

A Better Way to Practice

What Mozart and Kobe Bryant Can Teach Us About Deliberate Practice

Don't Just Learn - Overlearn!

This idea of the "10,000 hour rule" is also mentioned in Robert Greene's book, Mastery.

I learned about Robert Greene's book via 'The First Key to Mastery: Finding Your Life's Task"

---

After reading the above articles and book, my thoughts drifted towards two occupations:  musicians and IT workers.  Why?  Because I strived to make a career in both fields.

Obviously, musicians must practice consistently and constantly, but I believe this also applies to IT workers.  With the constant change in the computing and networking fields, practice and further education are absolutely necessary in order to stay relevant and capable.

Much like a musician who learns multiple techniques to make music, a network technician or engineer must also learn about the multiple technologies available to design, maintain and troubleshoot a computer or a network.  For example, it is important to learn the advantages and disadvantages of the different Internal Gateway Protocols (RIP, EIGRP, OSPF) for the different topologies (hub-and-spoke, star, etc.) and transport methods (Ethernet, Frame Relay, MPLS, Serial).

Practice methods are pretty straight forward for musicians (for example, taking lessons, listening to different genres of music, watching educational DVDs from their favorite musicians, reading sheet music, instructional books, and most importantly, actually playing their instrument).  What practice methods are available for IT workers and network technicians?  Strangely, some of the exact same methods:

• Educational books and classes
• Training videos (youtube, CBTNuggets, INE, TrainSignal, etc.)
• Various websites (www.freeccnaworkbook.com, etc.)
• Simulators/Emulators (gns3)
• Home lab equipment

Which method(s) would be best to move towards mastery?  In my opinion, all of them are useful but more emphasis should be pointed towards the simulators and home lab equipment.

Practicing the actual implementations and configurations on real equipment would be similar to a musician playing their instrument instead of just watching or reading about it.

---

"To know but not to do is really not to know."  -- Steven R. Covey, The 7 Habits of Highly Effective People

We can read all the books and websites we want, but until we actually get on the equipment and implement the configurations and see what works (and more importantly, what doesn't work), we don't really "know".

---

Another great book that talks about mastery is Jim Collins' "Good to Great".  In this book he talks about the "Hedgehog Concept" which involves three circles:  what you can be best in the world at, makes money and what you have a passion for.  Where the three circles intersect is your "Hedgehog Concept".  In the context of mastery, I believe that the three circles also pertain to mastery.  Where the three circles intersect is also lies the possibility of mastery.

The first circle is the toughest:  What can you be best in the world at?  That's a tall, tall order.

Jim Collins uses the following analogy (which I will paraphrase):  Imagine you take the SAT and score highly on the math portion.  Does this mean you should pursue a career in mathematics?  Not necessarily.  There are people who are "genetically encoded" for math.  Their brains are just wired for math.  The same would apply to musicians and network technicians.

If we spend the "10,000 hours" to move toward mastery but are not "genetically encoded", can we realistically become a master?  I don't know, but after 10,000 hours of deliberate practice, I think one would at least be considered an expert or (at least) highly competent.

---

Another concept Jim Collins brings up is the idea of "Pushing on the Flywheel".  Once we find our "Hedgehog Concept", the next task is to consistently push on the flywheel and build momentum over time.  Any tasks outside of "Hedgehog Concept" take momentum away from the flywheel.

Mastery is not just about the amount of time spent, but also the quality of time spent.  If we spend those hours just mindlessly reading the same books over and over (and I'm guilty of this), we may not be moving towards mastery as quickly as we would like.

---

Another Jim Collins' book "Great by Choice" discusses the idea of a "20 Mile March" where no matter what one pushes to march 20 miles a day regardless of the weather instead of marching 40 miles in good weather and 2 miles in bad weather.  A synopsis can be found at the artofmanliness.com:  What's Your 20 Mile March?

The idea of a "20 Mile March" or "Pushing on the Flywheel" also ties back into one of my favorite motivational tactics:  Don't Break the Chain as taught by Jerry Seinfeld.  I think it is important to be consistently pushing towards a goal (such as a certification or to start learning about new technologies).

---

In conclusion, I'd like to paraphrase a quote from Bill Walsh (the former San Francisco 49ers head coach) from his book "The Score Takes Care of Itself":

"Mastery is a process, not a destination."

Sports, music and even networking are all similar in this regard.  True mastery is never achieved.  There is always some aspect of our skills that needs to be improved and worked on.

Moving towards mastery in the IT fields is about learning more about current technologies (depth), learning about new and emerging technologies (width) and consistently moving towards our goals (20 Mile March/Pushing on the Flywheel).

My hope is that those of us who are pursuing Cisco certifications are pursuing them for the right reason:  to learn the material in pursuit of mastery (even if mastery can never be fully achieved).

Resources for the CCENT and CCNA Exams

After participating in this Google+ post, I thought it would be nice to list the resources I used when studying for the CCENT and CCNA exams.  Please keep in mind that I earned the 'v1.1' certifications that were recently updated by Cisco.

I imagine that most of the information in these resources will still be relevant to the new exam, but make sure that most of your material is geared toward the new v2.0 exams.

---

The first concept I recommend is the "Don't Break the Chain" concept I learned on lifehacker.com.  You can accomplish damn-near any goal through consistent effort over time.

---

Next, be sure to grab the syllabus from Cisco's website for the exam.  If you are going to break the CCNA into two parts (which is what I did), the first exam to take is the 100-101 (CCENT).  After you click on the link, click on 'Exam Topics'.

Also, head over to the Cisco Learning Network and create your Cisco.com account.  Once you create an account, you'll have access to download white papers and PDFs for the exams.

https://learningnetwork.cisco.com/index.jspa

---

The Cisco Press website is also a mandatory stop.  These materials are geared specifically for the exams and are published with Cisco's blessing, so they better be good enough to help you pass the exam!

CCENT:  http://www.ciscopress.com/markets/detail.asp?st=44701

CCNA:  http://www.ciscopress.com/markets/detail.asp?st=44711

Personally, I would start with the Foundation Learning Guides.  I didn't know these guides were available when I took the CCENT/CCNA, but I started using them when studying for the CCNP SWITCH and CCNP ROUTE exams.  Highly recommended!

CCENT:  http://www.ciscopress.com/store/interconnecting-cisco-network-devices-part-1-icnd1-9781587143762

CCNA:  http://www.ciscopress.com/store/interconnecting-cisco-network-devices-part-2-icnd2-9781587143779

The Official Certifcation Guide would be my next stop.  These are aimed directly at passing the exam.  A lot fo the same material will be presented between the Foundation Learning Guide and the Official Certification Guide, but my method of study isn't just to learn, but to overlearn.

Last in this section, grab the Portable Command Guide.  The Portable Command Guide on it's own won't help you much but once you have the Foundation Learning Guide and Official Certification Guide under your belt, the Portable Command Guide is where the rubber meets the road.

Think of these three books this way:  The Foundation Learning Guide is the 'high level' book to show you the overall picture with some detail.  The Offical Certification Guide is a more focused view of the same terrain (middle level).  But the Portable Command Guide is the ground level, 'roll up your sleeves and get dirty' book.  If you haven't seen the overall picture of the exam and the technology, it makes it more difficult (in my opinion) to really know what each command is going to do, what commands are needed to implement the technology and what the consequences of those commands might create.

The whole purpose of these exams is to prove we have the knowledge and skills to configure and troubleshoot Cisco equipment and networks.  If we lack the fundamental knowledge and skills and just study to pass the exam, we're cheating ourselves and cheapening what the exam is worth.  The Foundation Learning Guides are to learn about the theory and implementation behind the technology, not just to pass the exam.  Start at the high level; work down to the ground level.

---

Next, you need to ask yourself how far you want to take this.  If you are just going after the CCENT and CCNA, you can probably get by with a simulator.  But I recommend using both simulators/emulators and real equipment.

Hit ebay and look for great deals.  There are other suppliers that can be found, but I've purchased all my Cisco gear via ebay.

For crossover and serial cables, monoprice is a great site.

When I took on the CCNA, I used two routers and three 2950 switches, but mostly, I used GNS3 especially for the Frame Relay topics.

GNS3 is a Cisco router simulator/emulator program available for Windows, Mac and Linux.

Another great resource that ties into GNS3 is http://www.freeccnaworkbook.com/workbooks/ccna.  This site provides a great framework to build labs in GNS3 and to help prepare you for the exams.  I recommend actually typing in the configurations (since that what you're trying to learn anyway!) instead of 'copy and paste'.

---

Next:  YouTube

There are so many great videos to learn Cisco and networking technology on YouTube that it would be difficult to list them all here.  Search for the topic you are wanting to study next (RIP, Frame Relay, VLANs, etc.) and you'll find plenty.

Here are some channels that I subscribe to:

CBT Nuggets
Cisco
INE Training
Keith Barker
Kevin Wallace

---

There are also plenty of video courses out there.  Check out their samples and if you think you might like their teaching style, go for it.

CBT Nuggets
Chris Bryant
INE

---

After reading a number of articles about what study methods work and which don't, flash cards were consistently at the top of the list.  Cisco has flash cards available, but if you want a free program check out AnkiDroid.  I have AnkiDroid installed on my phone and tablet.  It's a great study tool when you have a few minutes of downtime.  I've been doing more book reading than using flash cards lately, but memorizing terms is crucial for these exams.

Practice exams are also listed as great educational tools.  I see that Cisco does offer some practice tests, but I've never used them so I can't say if they are any good or not.

---

Also, it might be worth your time to head down to your local library and see if they happen to have any Cisco books.  The books will likely be outdated, but take advantage of as many free resources as possible.

If (and this is a big if) you can grab a copy of 'Routing TCP/IP Volume I' by Jeff Doyle, the first chapters will be very educational.  It's an intense and immense book, but there's good reason why it's been called the 'Networking Bible'.

---

I've acquired most of my books in ebook format and uploaded them to my Google Play Books account.  It has been so nice to be able to read these books on my tablet and my phone.  The syncing works OK, but the portability is the biggest benefit.  Highly recommended.

---

In conclusion, there are so many resources to study for the Cisco exams that you will probably have more trouble deciding which ones to use instead of having trouble finding anything at all.

If I find any more resources, I'll add them here.

Good luck!

Hey, wait. There's a tree missing here!

Yesterday, while planning a network switch replacement, I noticed a little problem that could have been a big problem if that switch was moved up one spot in the network.

I'm recreating the problem on my home lab and walking through how it was found and how to fix it:

First, here is the lab topology using dia (http://dia-installer.de/):

Straight forward physical topology.

So, I started my planning session with a quick 'show vlan brief' to verify which VLANs were running on each switch.  For this lab, we'll have VLANs 1, 11, 22, 33 and 44.

AS2

AS3

All five VLANs are configured on both switches.

The next command I issued was 'show spanning-tree summary' to verify the path back to the root switch.

AS2

Using this command we see that AS2 is the root switch for all the spanning-tree instances.

AS3

Do you see the problem?

VLAN0022 is missing from spanning-tree!

As you can see from the 'show vlan brief' command, VLAN 22 is configured on the switch, but it doesn't have a spanning-tree instance.

To verify this, you can run a 'show spanning-tree vlan 22' command:

This was the first time I've ever ran into a VLAN not running spanning-tree.

So, what is causing the problem?

I first starting by looking at the trunks.  If a VLAN does not have at least one port using the VLAN on the switch, then the VLAN is shutdown to prevent a black hole.  So, I ran a 'show interfaces trunk' command on each switch to verify each VLAN was allowed on the trunk:

AS2

No problem on AS2.  All five VLANs are allowed on the trunk.

AS3

Same deal here.  All five VLANs are allowed on the trunk.

Again, what is causing the problem?

Next, I ran a simple 'show running-config' on the problem switch (AS3 in this lab).  I'm not gonna lie, I had to run through the running-config a few times before I noticed it:

Why this command was running on a production switch, I'll never know.  But we were relieved that this configuration was on a 'spoke' switch and not on a 'hub' switch and that there was only one uplink.  If this switch was a 'hub' switch or had a redundant trunk, a broadcast storm surely would have happened.

So, the simple solution:

Ran a 'show spanning-tree summary' to confirm there is now a spanning-tree instance for VLAN 22:

If you have any questions, please leave a comment.

Thank you for reading!

Troubleshooting Trunk Links and Spanning Tree using Dia - Part 5 of 5

Welcome back to the conclusion of this series!

We are now on to VLAN 44 which will show just how useful making a spanning tree map in dia can be.

Just like on the previous posts, here is the original physical layer map:

And once again, let's start with the 'show spanning-tree vlan 44' command on DS1:

Only two of the six trunks are forwarding VLAN 44.  Gi0/1 is the root port back to the root switch and Gi0/2 is in the blocking state to prevent a loop.  First update to the map is as follows:

Next, the 'show spanning-tree vlan 44' command on DS2:

On DS2, we can see that all six trunks are forwarding VLAN 44 and that DS2 is the root switch.  The updated dia map is:

Forwarding on to AS1 and the 'show spanning-tree vlan 44' command:

Here, we can see that only two of the four links are being used for VLAN 44.  Fa0/13 is the root port back to DS2 and Fa0/14 is blocking to prevent a loop.  Of course, we document this on the map adding the circled-x on the end of the blocking port:

Last, we head over to AS2 and run the 'show spanning-tree vlan 44' command:

Now, we have some interesting information shown here.  Notice, AS2 believes it is the root switch for VLAN 44.  But we documented that DS2 is the root switch.  How is possible?

It is possible because AS2 doesn't have a connected neighbor using VLAN 44, but AS2 does have an active port on VLAN 44 (Fa0/21 and Fa0/22).  Since AS2 does not have a neighbor using VLAN 44 on their trunks (and AS2 is not using Fa0/23 or Fa0/24 on its trunk links up to DS2), AS2 believes it is the root switch for the VLAN.

Once we document this misconfiguration on the dia map, it becomes very clear.  Remember, I use the blue links to indicate that the VLAN is not on one end of the trunk link and the circled-x is used to indicate with end of the link the VLAN is not available on.

Because there are zero green links coming from AS2, it is clear that AS2 is cut off from the rest of the network on VLAN 44.

Now that Layer 2 is documented, let's verify where the HSRP Active router for the VLAN is located.  First, the 'show standby vlan 44' on DS1:

DS1 appears to the Standby router indicated by the 'State is Standby' and the 'Standby router is local' lines.  Let's verify that DS2 is indeed the Active HSRP router.

And DS2 is the Active router.  So, the finished map shows as:

---
Let's take a look at the finalized maps for each VLAN:

VLAN 1

VLAN 11

VLAN 22

VLAN 33

VLAN 44

So, now that we have our finalized maps, what would be some options to repair and optimize the current configurations?

At the beginning, I wrote that the odd numbered VLANs (1, 11 and 33) were going to use DS1 as the root switch for spanning tree and use DS1 as the HSRP Active Router and that the even numbered VLANs (22 and 44) were going to use DS2 as the root switch for spanning tree and use DS2 as the HSRP Active Router.  Additionally, when there are dual uplinks, I think it makes much more sense to utilize EtherChannels (logically combining two or more connections into a single connection).  EtherChannels optimize bandwidth (more connections toward the root switch) and simplifies the spanning tree instance (no blocking ports towards the root switch).

First off, this might be an opportune time to change the spanning tree protocol to rapid-pvst (rapid per VLAN spanning tree).

So, let's start there.  On each switch, we run the command 'spanning-tree mode rapid-pvst' in configuration mode:

When we change the spanning tree mode type, the spanning tree instance will need to reconverge and since the other switches are still in Per VLAN Spanning Tree (pvst), we will have to wait through the Listening and Learning stages before moving along to each switch.

We can see that the HSRP sessions break down as well.  Once spanning tree has reconverged, the HSRP sessions reconnect and routing is back online.  Once all four switches are running rapid-pvst, the following configuration changes will update the spanning tree much quicker.

Secondly, we will need to configure the trunk links to be identical (all the VLANs will need to be allowed on all the trunks).

The easiest way to do this is to use a range command on each switch that adds the line 'switchport trunk allowed vlan 1,11,22,33,44'

We can use the dia map to find out which ports can be added to the 'interface range' command instead of having to go through each port individually.  Remember, when a trunking command is added or changed, spanning tree will reconverge.  Obviously, this type of work needs to be done off-hours since the convergence will temporarily take down each VLAN.

Once each switch has identical allowed VLANs, it's time to plan our EtherChannels.  Again, dia can be used to help with this planning as well.

Under the SDL group of icons in dia, there is a circle that can be used to indicate an EtherChannel.

We can add the circles and change the shape into an oval and add a label to plan out the EtherChannel port numbers so the numbers don't overlap on the same switch.

There are a few different ways to configure EtherChannels (which will be a topic for another series).  So, for this article, let's just choose a quick configuration and move along.  Also, remember that when you change the configuration on one end of the links, the ports will go down until the other end is configured.  So, it is best to start with the remote end first so that you don't "cut your own arm off".

Once the EtherChannels are in place, it's time to make sure that the odd numbered VLANs are using DS1 as the root switch and that the even numbered VLANs are using DS2 as the root switch.

One of the many goofy things about spanning tree is that the 'priority' setting is backwards (at least in my way of thinking).  The switch with the LOWEST priority is the root switch (which is the opposite in the HSRP configuration).

Spanning Tree = lowest priority is the root switch
HSRP = highest priority is the root switch

So, when I set up a spanning-tree priority, I like to set the root switch with a priority of 4096, the secondary switch with a priority of 8192 and the other switches with a priority of 40960.

For DS1:

For the even numbered VLANs 22 and 44, we'll set the priority as 4096 on DS2, 8192 on DS1 and 40960 on the other two switches.

We can verify that spanning tree and HSRP are working as planned with the 'show spanning-tree summary' and 'show standby brief' commands:

We can see that DS1 is the Root bridge (root switch) for VLANs 1, 11 and 33 and is also the Active router for VLANs 1, 11 and 33.

DS2 confirms that it is the Root bridge (root switch) for VLANs 22 and 44 and is also the Active router for VLANs 22 and 44.

Now that we have the rapid-pvst running, the trunks configured, EtherChannels set up and the spanning tree priorities configured, our final maps look like this:

Odd numbered VLANs (1, 11, 33):

Even numbered VLANs (22, 44):

---

I sincerely hope that you download and become comfortable with using dia and that this series has been helpful to you in learning, configuring and troubleshooting trunks and spanning-tree instances.

Thank you for reading!