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

NMC DOiT Vol.2 Scenario 3 Day 2 – EIGRP Authentication + RIP Distance

875 Words. Plan about 5 minute(s) to read this.

Today I completed the build out of the frame-relay network, assigned all IPv4 addresses, verified connectivity on all links, built the RIP system, and built the EIGRP system. That was about 3 hours of work, but should have been more like 2.

Part of that delay was the way the frame-relay section was worded – I didn’t read carefully enough. In my head, I thought I had to use physical interfaces for all of the frame-relay links. One of the links had 3 active DLCIs linking off to other routers, in different subnets. So I was puzzled as to how I was supposed to do this. Mapping DLCI numbers to secondary IP addresses or something goofy like that? So I wasted a bunch of time there, until I realized that I WAS allowed to use logical subinterfaces for a part of the frame connection on that particular router. That made it very simple to configure, and dovetailed nicely with a later OSPF requirement I knew was coming. I guess I’m expecting curveballs, so if I see something that doesn’t make sense, I just assume the problem is that I’m ignorant.

I was also a doofus by not having it stick in my head that I needed to configure EIGRP authentication on all of the routers. So I blew through a very simple EIGRP configuration, got all my adjacencies up, only to read that all the links were supposed to be authenticated. <groan> And I had read it before, I really had – it just didn’t stick in my noggin, and I got all carried away blasting through something that was straightforward.

So since I bring it up, how does one configure EIGRP authentication? The idea here is to include an MD5 digest hash (as best as I can tell, there is no other choice BUT to use MD5) in each EIGRP packet, which insures that no one you don’t want to hear from is talking EIGRP to your routers. So here’s an easy config for EIGRP authentication (you can do this with more complexity, but I’m keeping it simple):

  1. Build a keychain and add a key you’ll use for EIGRP.
    1. From global config mode, “key chain name-of-chain” creates a key chain, where name-of-chain is whatever you call it (A key chain is something you hang keys on, right? So think of this as a container to hold keys, but not the keys themselves. They come next.)
    2. Now we’re in the key-chain config sub-paragraph. So let’s create a key. “key x” creates a key, where x is a number you’ve chosen.
    3. Now we’re in the key-chain-key config sub-paragraph. So let’s define the key’s characteristics. “key-string text” defines what we would think of as our password, where text is a word of our choosing.
  2. Go to each interface running EIGRP and apply EIGRP authentication using your shiny new key-chain.
    1. Enter interface config mode.
    2. ip authentication mode eigrp x md5” turns on MD5 authentication for EIGRP packets, where x is your AS number.
    3. ip authentication key-chain eigrp x key-chain” tells the router what key-chain to use for the MD5 authentication, where x is the AS number, and key-chain is the name of the key-chain we created earlier.
  3. Note that if you configure EIGRP authentication for one side of the link, but not the other, your EIGRP adjacency will not form, or will go down if it had already formed before you started messing with authentication.

Read more about EIGRP authentication.

The only other task I ran into that I don’t do in my average day at work was setting the distance of specific routes learned by RIP. The idea here is assign a specific distance to incoming routes if they were learned from a specific neighbor. You can get more granular with this if you need to by assigning an ACL so that only routes matching the ACL will have their distance tweaked.

Tweaking distance can be handy if you need routes learned from a specific router via one protocol to be preferred over another protocol. In this case, RIP routes are AD of 120, right? So if we tweak them to be AD of 109, what’d we just accomplish? We just made it so that those routes would be preferred over the same routes learned via OSPF, AD 110. Why you’d need to do this, who can say…but at least you get the idea of what the distance command is for. So from inside the RIP paragraph:

  • distance 109 172.31.100.10 0.0.0.0” would assign a distance of 109 to all routes learned from RIP neighbor 172.31.100.10.
  • distance 210 172.18.19.0 0.0.0.255” would assign a distance of 210 to all routes learned from RIP neighbors in the 172.18.19.0/24 network.
  • distance 105 0.0.0.0 255.255.255.255 tweak-us” would assign a distance of 105 to routes learned from ANY RIP neighbor, as long as the route matched against an ACL called tweak-us.

While fiddling with the distance command, I found that I needed to do a “clear ip route *” (Okay, I didn’t HAVE to do “*”, but I’m lazy…) so that the routes would show up with the AD I was expected after fiddling with the distance command. Also note that the distance command is not unique to RIP. It just so happens I used it with RIP tonight, so that’s how I presented the information.

Read more about manipulating administrative distance.