1,047 Words. Plan about 7 minute(s) to read this.
Okay. We’ve made it to chapter 9. EIGRP, or enhanced interior gateway routing protocol. EIGRP is Cisco’s baby. It’s fast, smart, highly configurable, and scales to large enterprise networks. Not ideal for the Internet backbone, but for a large enterprise with low downtime and high availability requirements, it’s pretty wonderful. Arguably, OSPF fulfills that role, too. And these days, OSPF can be made to converge as quickly as EIGRP. And OSPF is interoperable, as it’s an open standard whereas EIGRP is – as I mentioned – Cisco’s baby. Even Cisco doesn’t interoperate well with Cisco when it comes to EIGRP. There’s no EIGRP on a PIX or ASA box, for instance, a problem which has probably kept Cisco from winning more than a few firewall deals. But EIGRP is wonderful, and it’s everywhere. It’s expected that if you work on large networks, you’re familiar with EIGRP.
But enough of my rambling. And onto my summarization of the Official Exam Certification Guide Chapter 9, EIGRP.
Let’s start with some bullet points:
- Transport is IP protocol 88. 88 is not a TCP or UDP port. EIGRP is his own IP protocol.
- The metric is potentially composed of 5 elements, 2 by default (bandwidth and delay) and 3 optionally (load, reliability and MTU). In the real world, you’ll typically see EIGRP networks calculate route costs based on bandwidth and delay.
- EIGRP sends “hello” messages at a “hello interval” time.
- The hold timer is the timer used to determine when a neighbor has failed. This is based on the router not getting any hello or other messages during the timer period.
- Updates are sent to the multicast address of
18.104.22.16822.214.171.124 [This was fixed in the 3rd edition of the OECG.]. Retransmissions are unicast.
- EIGRP can send full or partial updates. Full updates are sent when a new neighbor adjacency is formed. Partial updates are sent the rest of the time.
- MD5 authentication is supported, but that’s the only type.
- Variable length subnet mask (classless) networks are supported, as subnet masks are included for all routes.
- Route Tags are supported for redistribution into EIGRP. (This is an interesting feature. I set up BGP redistribution into EIGRP a while back. One of the bits of information in the route tag was the AS number of the BGP network where the redistributed route originated.)
- The next-hop field is there, so that a router can advertise routes with a next hop other than himself.
- Routes can be summarized by EIGRP anywhere in the network that you turn it on. (Compare this to OSPF, where you can only summarize at an area border router.)
- EIGRP supports more than just IP. IPX is also supported, as is AppleTalk. (Egads! Does anyone still need native AppleTalk routing?!? I’m having flashbacks of trying to find the guy who left his Chooser open…)
So…how do 2 EIGRP routers come to find out about one another?
- When an EIGRP router comes up on the network, he sends EIGRP hellos out all interfaces where EIGRP is running to 126.96.36.199.
- When 2 routers here each other say “Hello”, they become adjacent, assuming:
- They authenticate to one another, if authentication has been configured on one or both.
- The use the same AS number (you know, the “router eigrp xyz”, where xyz is your AS number. Yes, that means you can run more than one EIGRP process on the same router, but you have to think of it as if they 2 EIGRP instances were like running OSPF and EIGRP on the same router. Redistribution rules apply.)
- The routers must be on the same subnet, or at least think that they are. The router will source his multicast hello from the primary IP address of his interface. The receiving router’s interface must fall into that same subnet. It’s plausible that the 2 routers could have different subnet masks on their interfaces, but still believe they are on the same subnet.
- K values (the multipliers for each of the 5 potential elements that EIGRP can use to compute a route’s metric) must match. By default, the K values are 1 0 1 0 0…in effect, only the 2 values of bandwidth and delay multiplied by 1 will be used. The other 3 are multiplied by zero, their impact on the route metric computation negated. Cisco recommends that you do not change the K values.
What else are hellos good for? Why, they are effective little keepalives. EIGRP hellos are sent at the “hello interval” time. If the adjacent router doesn’t hear a hello from the EIGRP neighbor within the “hold time”, then the neighbor is considered to have gone away, and the routes through that neighbor therefore to have failed. How sad.
Now – it’s interesting to note that the hello and hold timers do not need to match for EIGRP to form a neighbor adjacency. However, the router will use the timers his neighbor sends him. “Hello there. When thinking warm EIGRP thoughts about me, please use these hello and hold timers. Thanks!”
So now we’ve got 2 EIGRP neighbors. They’ve said hello, they’ve settled on timers, matched K values, MD5 authentication, subnets and AS numbers. So let’s get down to the business at hand: exchanging routes.
- First go, all routes are sent – a full update, less split-horizon routes.
- Updates stop when all routes are exchanged.
- When routes change, partial updates are sent.
- If a neighbor dies, but comes back from the dead, it’s as if the routers never knew one another: full updates are sent. If a router forms a new neighbor adjacency, full updates are sent.
- With something as important as a routing table getting sent, you’d think EIGRP would use some sort of reliable transport, right? But EIGRP doesn’t use TCP, does it? No…EIGRP is his own animal, IP protocol 88. Included in IP/88 is RTP: reliable transport protocol.
- RTP starts the RTO, or retransmission timeout.
- RTP sends a multicast update to 188.8.131.52 (all neighbors on a segment).
- RTP anticipates receiving a unicast ACK response from all neighbors, acknowledging receipt of the update.
- If RTO expires for a particular neighbor, RTP will re-send the update as a unicast to the neighbor that didn’t ACK.
- RTP uses a one-for-one message/ACK. There’s no sliding window concept here, as with TCP. We’re keeping it simple. The update is sent with a sequence number, and the ACK message contains that sequence number. (Different again from TCP.)