What a RIP-off!

Posted on by
1

A few days ago, there were a couple of tweets in my stream about RIP. Yes, the much-maligned, older-than-the-hills Routing Information Protocol. These particular tweets came from a couple of people that are in the study process for their CCIE lab exam. Having had a couple of shots at the lab myself, I found it prudent to mention that while RIP was indeed on the exam, don’t believe for one second that it’s going to be easy. While I can’t and won’t discuss specifics about what I’ve seen, I think I can speak with generality about why RIP is still very much a topic on the now version 4 of the venerable CCIE exam.

Every entry-level networking student learns about RIP. It was the very first routing protocol, and as such serves as a prototype for beginners to learn about topics like hop counts, routing tables, and other more esoteric subjects. RIP was designed to do one thing and do it well. Because of that, it doesn’t take long before he complexity of RIP is exhausted and students move on to bigger and better routing topics. In fact, the only purpose that RIP serves past the very early point is as a yardstick, a way of measuring how much better something is at its job than RIP.  Students quickly learn why EIGRP is much better as an advanced distance vector routing protocol.  Or why link-state is much better for larger networks.  Because of this, CCNAs and JNCIAs all over quickly develop the idea that “RIP sucks”.

I’m not a RIP apologist by any stretch of the imagination.  But I also have a healthy respect for the fact that while RIP may not be the most impressive routing protocol by today’s lofty standards, its place in history is secure by it’s longevity and due to the fact that we wouldn’t have EIGRP and OSPF today if RIP hadn’t paved the way for them.  So, why then would a 22-year old protocol that has been eclipsed in almost every conceivable way still show up in the blueprint for the granddaddy of all routing and switching exams? In short, to screw with your head.

Anyone with a driver’s license can probably cite traffic laws.  And any of them can’t most likely describe the procedure to parallel park.  Or park on a hill.  But the second half of the US drivers test doesn’t quiz you on your knowledge of how to parallel park.  They make you go out and do it.  And often, you don’t get to parallel park in perfect conditions like you practiced for weeks and months before your test.  No, if the driving instructor is particularly insidious, they might make you parallel park on a hill in a school zone.  In much the same way, RIP is on the test to mess with you.  You know RIP inside and out.  If you’ve read Jeff Doyle’s Routing TCP/IP volume 1 you can likely diagram a RIP update packet with some toothpicks and a pencil.  But, the devious-minded proctors and test writers aren’t going to ask you CCNA-level RIP questions.  No, much like the driving instructor, they are going to make you apply your RIP knowledge to situations you might not have encountered in practice.  Like establishing RIP neighbor relationships across 4 routers with no tunnels allowed.  Or, more likely, they will give you a very simple setup followed by the most infamous of all CCIE candidate 4-letter words: redistribution.  Most people know how RIP ticks, but when you start injecting RIP into a perfectly stable OSPF topology, that’s when the rubber hits the road and most things start falling apart.  Knowing how to pick up the pieces after RIP trashes your orderly link-state protocol is one of the things that shows you are a RIP genius and aren’t scared to get your hands dirty.

You might ask yourself, “Well, anyone can write evil RIP questions all day long.  Why is it still on the exam.  Who even still uses RIP?” Good question? Who still uses frame relay?  Or dial up modems?  Or bridges?  Being a CCIE means that you aren’t phased when you run into something old and (relatively) complicated.  It means you understand why RIP and frame relay and bridges paid their dues so that today we could have OSPF and MPLS and TrILL.  And as long as there is still a mainframe out there that only speaks routed or a network that has two routers that were made during the Carter administration, you are still going to encounter RIP.  And if you think outside the box on that stressful day in a dark lab somewhere, you don’t have to worry about being RIPed off by your grandfather’s routing protocol.

The Five Most Important Clients You’ll Meet

Posted on by
1

I ran across this little config snip while switching a router from one ISP to another.  I’ve changed the IPs in the access-list to protect the guilty, but I’ve left enough to get the general idea across.  Anyone want to take a wild guess as to what’s wrong with the config? I’ll give you a little hint: The first five callers get an unexpected bonus!


aaa authentication login vty local
!
ip access-list extended VTY
permit ip 172.17.0.0 0.0.255.255 any
permit ip 192.168.10.0 0.0.0.255 any
!
line vty 0 4
login authentication vty
transport input telnet ssh
!
line vty 5 15
access-class VTY in
login authentication vty

Houston, It’s Making a Funny Noise

Posted on by
2

I’ve always said that when I finally get tired of doing networking stuff, I’m going to write a book about teaching people structured troubleshooting.  This would be useful for not only computer work, but a large variety of things like figuring out when your sink is backing up or how to change the serpentine belt on your car.  The key to structured troubleshooting is thinking logically and taking it step by step.  For the record, I’m going to call my book “Did You Plug the Damn Thing In?”

So, I figured I’d share some of my troubleshooting steps just to give people an idea about how I go about figuring out what’s wrong with something.  Starting with how to know you’ve got a problem.

Step 1:  Find out (specifically) what’s wrong.

Yes, that sounds simplistic and little condescending.  And you’d be surprised at the number of people that can’t tell you what is wrong with something.  Want to piss off your mechanic?  Tell him your car is “making a funny noise”.  Want to raise the ire of your network admin?  Tell her the problem must be because “the network is slow”.  Problems are specific.  It’s not making a funny noise, it sounds like dragging a drawer full of silverware across a washboard.  The network isn’t slow, it takes forever for me to open up http://www.google.com.  Giving a problem a specific diagnosis means you can narrow your focus on what to start investigating.  As the troubleshooter, you have to remember to ask probing questions.  Don’t settle for ‘yes’ or ‘no’.  Make the other person describe, in excruciating detail if necessary, what exactly is wrong.  And take lots of notes.  As the blog title suggests, the Apollo 13 astronauts didn’t tell Houston that their problem was a funny noise.  It was a very specific diagnosis.

Step 2: Repeat the problem, if possible

Most problems are repeatable.  There’s nothing worse that hearing that you’ve got a problem, only to be told “Well, it’s not happening right now.  It’s pretty random.”  No problem should be totally random, especially in the computer/technology realm.  You should always know what steps it takes to make the problem happen.  Granted, lots of catastrophic failures are sudden, such as power outages, blown fuses/power supplies, or outright parts failures.  But, for the most part, things like routing loops or broadcast storms can be traced down to a specific event.  Remember the old joke about the patient that tells the doctor, “Every time I move my arm like this it hurts”?  All joking aside, that’s a great problem diagnosis.  Because you can make it happen over and over again.

Step 3:  Take LOTS of notes

I hate writing things down.  My desk if filled with half-scribbled sticky notes with information that will be useless the next time I look at it.  But when you start troubleshooting something, be sure to write down every detail.  Why?  Because you may often find yourself referring to your notes and find out that some minor detail at the start is the cause/solution to your problem.  Such as, “We were cleaning the other day in the server room.”  Not really important at the beginning, but after you determine there is a network outage to the e-mail server and find out someone unplugged the cord to make it look pretty under the desk, that little nugget of information could be very handy.

At this point, you should know exactly what you are facing and how to repeat it as necessary.  You should also have a head start on documenting everything so you know when you’ve fixed the problem.  Next time, we’ll explore how to get info about how to fix what ails you.

The End is the Beginning is the End

Posted on by
4

If you’re seeing this post, it means that I’ve finally gotten started on a blog.  Or, months from now, it means that you’ve reached the end of my posting in reverse chronological order.  Either way, I hope will be (has been ) a fun read.

This is a place for me to condense thoughts and post things I might need to find later that would end up getting lost in the dark recesses of my mind.  Be warned that there are LOTS of things that pass through there on a regular basis, so you never know what’s going to end up here.

For the most part, this is going to be a technical place.  I’m a Cisco partner engineer, and I’m a CCNA, CCDA, CCNP, CCDP, CCVP, CCSP, and a whole host of partner specializations.  I’m also a CISSP, MCSE: Messaging, MCSE: Security, Novell Master CNE, VMWare VCP, and a litany of other things.  I say this not to toot my own horn, but to show that I’m pretty much all over the map when it comes to technical nerdage.  I work on a lot of things in my job, and if they call that ‘wearing many hats’ I should open a haberdashery.

I’m also on Twitter, so feel free to follow me.  I’m @networkingnerd.  This place will probably end up being a repository for my thoughts that run longer than 140 characters, but rest assured that the same snark that accompanies my tweets will probably leak over here.

So, look for more content to come.  Unless you’ve already waded through the content and found this last (first) entry.  In which case, start over again and make sure I’m keeping up with things.