Eric Stewart: Running Off At The Mouth

Work procured for me download access to INE‘s CCIEv5 Advance Technologies Course and the CCIEv5 ATC Workbook.  I’ve finished up through RIPv2 on the videos and now I’m working through the RIPv2 labs.

What Is RIPv2?

RIPv2 is Version 2 of the Routing Information Protocol.  It’s rarely something you’ll see in a production environment.  It’s a fairly simple routing protocol, where the metric is essentially the “hop count” from the router looking to get to a particular network and the source router (a route on a router with a metric of “1” should be right next to the router that actually owns the route –  that router being directly connected to the destination network).  RIP is a fairly old protocol, from the times when routing was usually classful and didn’t pay attention to subnets much.  Some might say it really doesn’t have any use being on the CCIE exams.

The thing is, I’ve come to realize that RIPv2 is a great protocol to use as a starter protocol.  It’s useful when you’re attempting to learn stuff that’s mostly protocol independent, because, being a simple protocol, it doesn’t have a lot that’s specific to it, thereby keeping stuff that is specific to a given protocol mostly out of your way as you learn the generalities.  It’s a little more predictable than other protocols when you’re trying to modify its behavior.

auto-summary

On by default, “auto-summary” is usually one of the first things you set to “no auto-summary” when configuring RIPv2 (one of the others being “version 2”).  Without giving too much away too soon, “auto-summary”, when advertising networks to another router, means that the source router will advertise a classful network to its neighbors, even if there is only a subnet of that classful designation connected to the router.  Already, one might be able to see how this could cause issues: if a bunch of routers are all using subnets of a couple of larger classful networks, you might have a router sending out a summary network that claims to be the source of networks actually connected to other routers.  This would cause a loss of connectivity (packets routed into a black hole).

What I Learned Today

One of the labs I did today tells you to take a RIPv2 network with auto-summarization off on all routers, and turn it on on one of them to see what the results were.

For those not familiar with INE’s lab layout, each router has a loopback with a /32 that starts 150.1.x.x. All other connectivity (with one exception not relevant to this post) uses /24s in 155.1.y.x.

When I turned on auto-summary on the router in question, I saw the expected route of 150.1.0.0/16 being advertised from the router in question. However (and this is due to what I think now is a misunderstanding), I did not see a 155.1.0.0/16 being advertised as well. It’s not that the neighboring routers were receiving and ignoring it (verified by a “debug ip rip” on the router with auto-summary), but that the router wasn’t sending the route out.

The answer as to why came from visiting the Cisco docs for “auto-summary” under RIP – more specifically, “IOS IP Routing: RIP Command Reference”:

Command Default

Enabled (the software summarizes subprefixes to the classful network boundary when crossing classful network boundaries).

It took me a couple of read throughs to fully absorb what that statement says. It’s now my understanding that auto-summary (at the very least on RIP and possibly on other protocols, but that could be protocol dependent), when advertising on a given network the other networks the router has connected to it, doesn’t provide a summary for a network that’s within the same classful boundary. In other words, if advertising out a 155.1.1.1/24 addressed interface a network for a different interface that’s 155.1.2.1/24 addressed, it won’t provide the 155.1.0.0/16 summary (only the 155.1.2.0/24) because it doesn’t cross the classful boundary. But since 150.1.1.1/32 is in a different class B range (yes, I know it’s a /32 host route, but it falls within the designated range of the collection of “class B” networks), it does provide the 150.1.0.0/16 summary (it “crosses the classful network boundary”).

It also does not advertise the network it’s sending the update over, as the destination router should already know about that network, being connected to it … but noticing that was more of a “duh” moment that an “a ha!” one.

It was a new understanding for me that “auto-summary” doesn’t summarize “everything”. And I think that’s the kind of behavior that Cisco could potentially put on a test that would trip up someone.  And, depending on the protocol (most of which actually default to “no auto-summary” these days), “auto-summary” may have the same behavior.