What’s new and exciting with EIGRP (Enhanced Interior Gateway Routing Protocol)? Actually, lots… First a bit a background on EIGRP.
EIGRP is an advanced distance vector routing protocol used extensively by enterprise customers. It is very popular because it is simple to deploy and support. Some major attributes are:
- EIGRP does not mandate many network design requirements and is therefore perceived as “forgiving” and “flexible”. For example, EIGRP does not require support for multiple routing sub-domains or Areas.
- While route summarization is a recommended best practice to minimize route table size, it is optional with EIGRP.
- EIGRP can scale to support thousands of routers in a Hub and Spoke configuration. The Hub and Spoke design is especially popular in WAN networks.
For additional information on EIGRP, please click here. There is also a great BLOG that compares EIGRP and OSPF that I think you will find informative and is posted here.
While EIGRP has a large customer following, some customers have hesitated because of concerns of EIGRP being “proprietary”, which would prevent them from multi-vendor network support. In some cases this has caused customers to design their networks to limit usage of EIGRP, even though they would like to deploy it ubiquitously. One result has been non-optimal network design and traffic flow, resulting from multiple IGP (Interior Gateway Protocol) redistribution points.
That brings me back to what is new and exciting with EIGRP.
We recently submitted an IETF Internet Draft for EIGRP with the intent of making it an Informational RFC.
While many customers are utilizing EIGRP in their networks, some customers have expressed a desire for multi-vendor support. Cisco supports this position and feels it would provide customers with the flexibility to deploy EIGRP where it will best suit their needs.
We see EIGRP as a strategic protocol for many of our customers and therefore plan to continue our investment in EIGRP and to work with other vendors on supporting EIGRP. If you have additional questions on the IETF Internet Draft for EIGRP, there is a FAQ page and a video.
What about support for IPv6? With the advent of customers starting to deploy IPV6 networks and the fact that EIGRP provides seamless integration of IPV6 into their existing IPV4 network, we see expanding interest in EIGRP.
Outside of Cisco submitting EIGRP as an Informational Draft, here are some additional enhancements to EIGRP that were recently introduced. I welcome your questions, comments and feedback on EIGRP ….
Seems great opportunities for companies unsure of deploying it. Of course, still some years away of approval and other vendors support, but it might be an incentive for network engineers and decision makers planning at long term.
Usually one can always interoperate just fine with EIGRP with other protocols and vendors, usually with OSPF, providing it was well planned and engineered. Cisco design guides and architect professional career professionals provide very goo information about it. As of now, there is no reason to not consider using EIGRP if your large set up is Cisco.
I would agree that customers have become accustomed to supporting redistribution of multiple routing protocols. In fact, here is a Tech Note that reviews redistributing routing protocols.
For customers that support multi-vendor networks, having the option to deploy EIGRP without having to support multiple routing protocols and redistribution points could be advantageous. By opening up EIGRP, Cisco would like to make that an option in a multi-vendor network.
Yes, that is true. This means more flexible deployments and new solutions. Oh, thanks for the Tech Note cue!
I’ve heard some rumors about an upcoming enhancement which should help overcoming some scalability problems regarding routing when VRF-lite/EVN are used.
Is this something we could expect in the near feature?
Scalability is actually one of EIGRP’s main attributes. In fact, EIGRP is deployed extensively in the WAN, to support Branch connectivity, specifically for its scalability characteristics.
With respect to VRF-LITE/ EVN scalability, I would say it depends on the network configuration, the number of VRFs supported, and the number of prefixes and router peers. As customer scalability requirements are growing, we are exploring ways in which we can scale EIGRP even more than we have to date.
If you would like additional information on EVN, please access the following URL (http://www.cisco.com/go/evn) .
What about the support for MPLS-TE packets ? Only Link State protocols have that capability but I know EIGRP also uses some link-sate protocol features to discover and update the neighbor. It would be scalable for any Core Backbone network to use EIGRP as IGP protocol for MPLS labels switching since EIGRP is the only protocol that maintains three tables (neighbor, topology and routing )
Great Idea ! This is an enhancement to EIGRP that has been discussed. I will plan to bring your request to the attention of our EIGRP product marketing team ….
Keep those ideas coming !
Comments are closed.