From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

Bootcamp with Narbik – Day 3 Comments

429 Words. Plan about 2 minute(s) to read this.

Day 3 was focused on OSPF.  Narbik’s OSPF lecture was about 3.5 hours, and covered everything you ever wanted to know about OSPF.  I’ve mentioned it before, but Narbik’s lecture style is focused.  He doesn’t waste words.  You have to stay right with him, or you’ll quickly lose track of him.  In his OSPF lecture, LSAs, area types, filtering, summarization, authentication, the adjacency formation process, and more were all covered.  He did a great chart for the LSA types.  Narbik also did a great network diagram explaining OSPF areas by demonstrating how many routes of various types would appear in each area of the diagram, depending on what type of area it was.

The rest of the day was labs.  Although it seems like I should have gotten a lot more labs done than I did, I managed to finish off the EIGRP section and make a good start on the OSPF yesterday.  For all the time I was in front of the rack, it seems that I should have accomplished more lab work.  I am not hurrying through the labs just to get them done, though.  I’ve been going through every task in detail and verifying the results, no matter how simple the task.  I’m making very sure that I understand what’s going on with all of the labs.

Narbik’s lab books are detailed.  For example, the OSPF lab section is broken into 11 small labs:  Optimization & Timers; Authentication; Cost; Summarization; Virtual-Links & GRE; Stub, Totally Stubby, and NSSA Areas; Filtering; Redirecting Traffic; Limiting Redistributed Routes; OSPF & NBMA; and Forward Address Suppression.  Within each lab, there are generally 7 to 12 tasks.  Almost every task is documented with command output that shows you how to verify what you just did, usually as a “before and after” kind of thing.  If you read and understand it all, and then track down any discrepancies on your rack, it takes a while to complete.  That is time well-spent, however.  When I’m done with a task, I have a complete understanding of what I did, how to verify it, and where I could use that functionality if asked in the future.

Here’s a few miscellaneous facts from yesterday.

  • Virtual links cannot traverse stub areas.
  • ip ospf dead-interval min hello-multiplier 4 – how many hellos to send within the minimum dead interval time of 1 second, which in this case results in a hello sent every 250ms.  This setting must match on both sides of the link to form adjacency.  The idea here is “fast neighbor down detection”.
  • NSSA areas do not receive a default route by default.