EIGRP: an MBA-Like Perspective
Ahmed was reading my EIGRP book (I know it’s hard to get, but fortunately he found a well-marked copy) and wanted to check his understanding of how EIGRP works. The first question was as good a summary as I’ve ever seen:
Does it just simply boil down to the fact that a router will choose not to have anything to do with a reported distance higher than its own cost to that route (feasible distance) for the (paranoid) fear that it could be a loop?
Next, he started wondering why a router would behave that way:
Is that just a strict protocol design decision that may lead to cases where a good (non-loop) may not be considered as a feasible successor but the design choice had to be made to ensure we avoid loops?
Actually, that was the best EIGRP designers could do with a distance vector routing protocol. The router, lacking the information on other routers' link costs, has no way of figuring out what next hop the neighbor reporting higher distance is using (contrary to Loop-Free Alternate feature in OSPF where the router knows its neighbor has a third-party next hop because it has full visibility into neighbor’s view of the area topology).
However, it was the follow-up e-mail I got from Ahmed that made my day – he explained EIGRP’s operation in business terms:
Would the EIGRP thought process be the business equivalent decision of never buying a commodity (accepting an RD) for more than you're selling it (feasible distance) because you may just be buying back your own product at a markup (loop condition)? But if your cheapest supplier goes away you immediately switch to the next cheapest one (feasible successor) provided you're not losing money (feasibility condition) while the customer (packet flow) sees no supply interruption. I imagine you would advertise the higher distance (price change) to your upstream neighbors right?
Yes you would. You want to operate at a fixed markup.
...and if supply dries up (route loss) and you don't have a feasible backup supplier on the books you abandon your existing (distance) price structure and have to "query" for a way to get a new price since you didn't have a backup supplier that could have let you continue supplying to the market (routing packets).
Is he good or is he good? He’d make a great teacher.
http://www.ciscopress.com/bookstore/product.asp?isbn=1587058952
...and judging from the 1st 2 chapters so far, is excellent and seems to serve as a standalone text for EIGRP on the CCIE exam. This is probably the book the training vendors have on their bookshelf.
I'll probably be skipping the AppleTalk/IPX sections, but the rest of the chapters look like an EIGRP tour de force tailored specifically for that section of the CCIE Blueprint (and whatever legacy EIGRP environments you may run into) and I wouldn't be surprised if giving the case studies in this book a serious look won't get you ALL points on the EIGRP section of the exam.
Compare the topics in the CCIE Blueprint vs. the Chapters in the book:
CCIE Blueprint
--------------------
2.50 Implement IPv4 Enhanced Interior Gateway Routing Protocol (EIGRP)
(a) Best path
(b) Loop-free paths
(c) EIGRP operations when alternate loop-free paths are available, and when they are not available
(d) EIGRP queries
(e) Manual summarization and autosummarization
(f) EIGRP stubs
EIGRP Network Design Solutions
--------------------------------
1. EIGRP Concepts and Technology.
2. Advanced EIGRP Concepts, Data Structures, and Protocols.
5. Scalability Issues in Large Enterprise Networks.
6. EIGRP Route Summarization.
7. Route Filters.
8. Default Routes.
12. Switched WAN Networks and Their Impact on EIGRP ***read Frame Relay***
13. Running EIGRP over WAN Networks.
15. Secure EIGRP Operation.
now for Wide Metrics he does need a new story -
maybe, maybe not ;)
Definitely a more specific example like "Sales in Clothes Shop"
"Actually, that was the best EIGRP designers could do with a distance vector routing protocol. The router, lacking the information on other routers' link costs, has no way of figuring out what next hop the neighbor reporting higher distance is using (contrary to Loop-Free Alternate feature in OSPF where the router knows its neighbor has a third-party next hop because it has full visibility into neighbor’s view of the area topology)."
I wouldn't describe it this way --this makes it sound like the router actually traces out the route to the destination using the LSDB to make certain, hop by hop, that it doesn't lie along this alternate path.
The reality is LFAs and EIGRP FS' work precisely the same way. In EIGRP, you use the neighbor's cost directly. In a LS protocol, you calculate the neighbor's cost by calculating an SPF from their perspective. In both cases the metric is the determining factor, not a "walk of the tree."
Using your neighbor's metric isn't "the best you can do sans topology information," it's the only thing you can do sans tunneling to make certain traffic sent down this path will actually forward the traffic correctly --that the alternate path is on the other side of the P/Q space, or the other branch of the waterfall.
The article on IP/FRR here might help explain it better:
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_15-2/ipj_15-2.pdf
Assume my cost is 1000 and neighbor's cost is 1010. EIGRP will never use the neighbor as FS (because RD is too large), whereas LFA might if the cost between the neighbors is more than 10 (and LFA knows what the remote cost is based on topology information EIGRP doesn't have).
Also, a router using LFA might actually be tracing out route to destination (running SPF from the perspective of the neighbor), which is even more important if you have to take in account SRLGs.
LFA gives you the best possible FRR coverage next to RSVP FRR. in addition, LSDB gives visibility to accommodate for things like node protect, which is not possible with EIGRP.
EIGRP is still a distance vector protocol. Enhanced/advanced, but still distance vector.
SRLG interaction with LFA is pretty weak though. with MPLS-TE, the PLR knows exactly what it has to deal with (SRLG links) upon a failure and builds a backup tunnel accordingly. with LFA, this is more complex as both the PLR *and* the new NH router have to make sure not to transverse the SRLG links. I don't think anyone ever went down this path, even the RFC AFAIK. SRLG in this context is limited to local links coloring, on the same node.