The rest of this chapter hits the highlights of configuring RIP. It isn’t brain surgery, but I was a little surprised at just how much flexibility there is in RIP. Even though using hop-count as a metric is hokey, and even though either of my Grandmas (who don’t know IP and are both dead) could converge faster, there’s a bunch of nifty things you can do with RIP. If…someone put a gun to your head. Which is what the CCIE is all about, now that I think about. A gun to my head with an expensive, shiny bullet inside. :-)
- “router rip” is the command to start up the RIP process.
- “version 2” tells the router to use RIP v2, and ignore RIP v1. (Remember that there’s no concept of a neighbor adjacency with RIP. Updates are broadcast out an interface whether anyone’s listening or not. So it’s possible a router could get an unexpected RIP v1 on an interface. You can set up RIP to unicast to a “neighbor” – more on that in a moment.)
- “network 10.0.0.0” enables RIP on all 10.x interfaces.
- These network statements must be classful.
- If you don’t want RIP running on a particular interface, you use the “passive-interface” command in “router rip”.
- Or – you could run a distribute list to filter off all of the advertised routes that RIP learns. In effect, the router would see the RIP advertisement, but the distribute-list would filter all of the learned routes such that they would not hit the local routing table.
- Or – if you don’t want RIP to tell other routers about a particular connected 10.x interface, you could use a distribute list outbound (instead of inbound, like above). In this way, you control what routes RIP will tell other routers about.
- The “neighbor” command tells RIP to send unicast updates to that one neighbor, rather than broadcasting.
- RIP will autosummarize routes on classful boundaries by default. In other words, if you’ve got on a router a 10.1.0.0/16 and a 10.2.0.0/16 route, the router’s going to send a 10.0.0.0/8 auto-summarized route by default, not the 2 separate VLSM routes. If you don’t want this behavior (and who could blame you), use “no auto-summary” under “router rip”.
You may wish to control who your router learns routes from. It wouldn’t be nice for any old nasty hacker-type to throw a rogue RIP router on your network and advertise himself as a default route. Could really make for a short lunch hour. So…RIP allows you to set up authentication. Secure authentication with keys, no less, although plaintext is supported.
- To set up keys that your router will use for RIP authentication, use the “key-chain” command to set up some keys.
- To use these keys for RIP authentication, in the interface paragraph use “ip rip authentication mode md5” followed by “ip rip authentication key-chain keys” where “keys” is the key chain you defined earlier.
- If you don’t use “md5” as the mode, then the mode is plaintext.
You can control split-horizon per interface. You remember what split-horizon is, right? That’s where the router doesn’t advertise routes it learned from a certain interface back out that interface. This is an anti-looping mechanism. You may wish to disable this feature in some cases, which you can do with “no ip split-horizon” on the interface in question.
Now, you can also force RIP to advertise a different next-hop than the advertising router. It’s possible for RIPv2 to carry in his route advertisement a next-hop that is not himself, but the router that advertised the route to him originally. (If you think it through, it should occur to you that you’ll have to turn off split-horizon to demonstrate this to yourself.)
A RIP offset list is a way you can artificially manipulate the metric of an advertised route. Specifically, you can add extra metric to a route. The offset list is built to match a list of subnets, and is applied in either an inbound or outbound direction. If you had in your router rip paragraph a line that said “offset-list 11 out 10 FastEthernet0/0”, then routes matching access-list 11 would have 10 added to their natural metric, then advertised.
While an offset list allows you to artificially weight routes, you can also filter what routes you’re accepting or sending with distribute lists and prefix lists. Let’s say in your router rip paragraph you had a statement like this: “distribute-list 9 in FastEthernet0/0”, you’d be saying, “Any inbound route matching access-list 9 can hit the routing table. All other routes will be ignored.” If ACL9 was “permit 10.1.0.0 0.0.1.255”, then you’d only accept routes falling within the 10.1.0.0/23 range (10.1.0.0 – 10.1.1.254).
Distribute lists can also refer to a prefix-list instead of a access list. Prefix lists are syntactically pleasant to work with, in that they give you the ability to filter a route not just on the range it falls in, but also the size of the route. You could filter off all routes that are /30, for instance. Or that are /24 or smaller. For instance, “ip prefix-list supernets-only seq 5 deny 0.0.0.0/0 le 24” would create a prefix-list named “supernets-only” that denies all routes that are /24’s or smaller (le = less than or equal to, ge = greater than or equal to). Prefix-lists have an implicit deny at the bottom, so you’d need to put in “ip prefix-list supernets-only seq 10 permit 0.0.0.0/0 le 32 to make sure you get everything else.