1.3.c Operations (EIGRP)

1.3.c Operations

Let’s just burn through a list of commands we need to memorize:

Basic Config:
router eigrp 100
network 10.1.1.0 0.0.0.255
! Disabling auto-summarization isn’t required anymore, it’s the default.
no auto-summary

1.2.i Routing protocol authentication

Authentication with EIGRP is just MD5 in classic mode. Named Mode lets you do MD5 or SHA-256. Let’s set up the keychain first.

key chain KEY_EIGRP
key 1
key-string C!sco123

Classic EIGRP
interface gig 0/0
ip authentication mode eigrp 10 md5
ip authentication key-chain eigrp 10 KEY_EIGRP

Named Mode
router eigrp R17
address-family ipv4 vrf 1 auto 10
af-interface gig 0/0
authentication mode md5
authentication key-chain KEY_EIGRP

Stub Routers:
As we’ll learn in 1.3.c iii, routes hang out in the active state waiting for a reply to the query they sent. What if we know for sure that the route we’re trying to learn about is definitely not down that alley behind that building over there. Do we really need to send queries down there and sit and wait for a response that we know is going to come back as, “Sorry boss, it’s a dead end.” No. We know it’s a dead end, so lets not send those queries.

R23:
router eigrp 100
eigrp stub

By default R23 will only send updates about connected and summary routes. But we can modify the stub command a little if we need more info from R23. If we want, we can set it for static or redistributed routes, as well.

R23:
router eigrp 100
eigrp stuf connected redistributed static summary

Note, there’s also a leak-map option, but that comes later in the blueprint. Then there’s the receive-only option, which means, “I’m not sending any routes to you. None…”

1.3.c i General operations

Let’s use this section to screw up our metrics and timers. We’ll start with the metric weights which are the K values that we should really never touch. Default is 1 0 1 0 0. Note the first 0 is the TOS, which says we can put a value of 0-8, but only 0 is allowed.

Metrics:
router eigrp 100
metric weight 0 2 0 2 0 0

Now that we modified the metrics, we can’t have any EIGRP neighborships unless they all modify their metrics, too. What a mess.

Timers:
interface gig 0/1
ip hello-interval eigrp 1
ip hold-time eigrp 3

Default timers are 5 and 15. We set them to 1 second hello interval and 3 second wait time to receive a hello. Note that if we didn’t change the peer to send faster than 5 seconds, then our 3 second timeout will kill the neighborship.

1.3.c ii Topology table

What’s there to say here besides show ip eigrp topology? The received routes get funneled down into the topology table (if they qualify per our FC), from there the best routes get chosen and sent to our routing table.

1.3.c iii Packet types

Just a couple packet types, and two of them are really just the same packet.

• Hello/Ack: Hellos are multicast and unreliable. If it’s empty hello, it’s an Ack. Acks are always unicast, but still unreliable.
• Updates: Updates use reliable delivery and contain… routing updates, of all things. They can be multicast or unicast. If I decide to send them because I had a topology or metric change, then I’ll multicast them. But if my peer is requesting an update, I’ll just unicast it.
• Queries/Replies: If we get an input event, we know something in the network has changed and we have to do our DUAL calculations again. This is where routes go from passive (normal state) to active (querying and waiting for replies). Some of the things that trigger this are:
  • Directly connected link goes up or down, or the cost changes.
  • We receive an update, query, or reply.
• Requests: These aren’t actually used. Forget about them.
• SIA-query/SIA-reply: We’ll talk about these in the next section.

1.3.c iv Stuck In Active

SIA is when our route is hanging out waiting for replies from ALL neighbors that we sent queries to, and those neighbors are all hanging out waiting for replies from all the neighbors that they sent queries too, and on and on. Stuck-in-Active is bad because it causes the router that’s waiting for the reply to just say, “Oh well, I guess he’s dead, blow away those routes.” Then we start over with a new neighborship, and that cycle can repeat. That’s why they made the SIA-retransmit timer and the SIA-query and SIA-reply.

• SIA-retransmit timer: This is set to half of the active timer (so 90 seconds). When it expires, we send an SIA-query.
• SIA-query/SIA-reply: These basically say, “Hey man, I’m still waiting on a reply from my query.” and the neighbor sends an SIA-reply that says, “Hang tight, duder. I’m working on it. Don’t blow me away yet, though, I’m still here.” This causes the regular query timer to reset so the neighbor has more time to get his act together.

1.3.c v Graceful shutdown

There’s not really anything to configure here. Graceful Shutdown is a mechanism where a router can notify a neighbor that says, “Hey, my EIGRP is going down, so don’t waste your time trying to figure out if I’m still alive or not.” You can trigger graceful shutdown a couple ways.

• reload
• no router eigrp
• no network [peer subnet]
• clear ip eigrp neighbor

Effectively what the router does is send a Hello message to the peer with the K values all set to 255. The peer recognizes this as code-word for graceful shutdown.