Multihomed EIGRP sites in MPLS VPN network

Deploying EIGRP as the PE-CE routing protocol in MPLS VPN networks is easy if all sites have a single PE-CE link and there are no backdoor links between the sites. Real life is never as simple as that; you have to cope with various (sometimes undocumented) network topologies. Even that would be manageable if the customer networks would have a clean addressing scheme that would allow good summarization (that happens once in a blue moon) or if the MPLS VPN core could announce the default route into the EIGRP sites (wishful thinking; the customer probably has one or more Internet exit points).

In the end, you’re left with two-way route redistribution between core MP-BGP and edge EIGRP, resulting in nightmarish scenarios (probably a good half of the blog posts of the CCIE candidates talk about redistribution horrors). Fortunately, Cisco implemented two extra features supporting EIGRP-to-MP-BGP redistribution: BGP cost community and BGP Site-of-Origin. The Multihomed MPLS VPN sites running EIGRP article I wrote in CT³ wiki describes how you can use both features to get a reliable network even when doing two-way redistribution.

Simple EIGRP in MPLS VPN networks

A few days ago I've been involved in an interesting EIGRP-within-MPLS/VPN troubleshooting session. I wanted to reproduce the behavior in the lab, so I set up a simple EIGRP lab … and realized that it's been a while since we wrote the MPLS and VPN Architectures, Volume II, which covers EIGRP used as PE-CE routing protocol. To make things more interesting, a few details have changed in the meantime; you have to configure the following features to get EIGRP running within MPLS/VPN environment:

• The autonomous-system command within the VRF address family is mandatory, even if the VRF AS number matches the EIGRP process number.
• The default BGP-to-EIGRP redistribution metric has to be configured, otherwise remote EIGRP routes will not be redistributed even though they have EIGRP metric encoded in extended BGP communities.
• Things work best if you disable auto-summary on PE-routers.

You can find more details and complete configuration examples in the EIGRP in MPLS VPN networks article I wrote in the CT³ wiki.

Routing protocol redistribution

Routing protocol redistribution is one of those tough Cisco IOS topics that everyone struggles with sooner or later. To ease your path to mastering the redistribution issues, Petr Lapuhkov wrote two articles: the theory of route redistribution and a simple case study.

Change the routing protocol in your network

A while ago, one of my readers asked an interesting question: “are there any generic guidelines or steps to follow if you want to change the routing protocol in your network?” The October IP Corner article, Changing the Routing Protocol in Your Network, describes a potential scenario that you can apply to networks of medium complexity that have a single interior routing protocol and do not use two-way route redistribution.

Note: This article is part of You've asked for it series.

Display the EIGRP stub neighbors

If you've deployed EIGRP stub routers in your network, you'd probably like to know which neighbors of a particular router are stub routers. Unfortunately, the only command to display a neighbor's stub status is the show ip eigrp neighbor detail command, which is a bit too verbose for what we need. In my latest IP Corner article, Enhance the IOS User Interface, I'm focusing on the stub routers in the EIGRP example section, where you'll find how to minimize the length of the show ip eigrp neighbor detail printout.

Note: You can get in-depth information on EIGRP stub routers in the virtual classroom recording available free-of-charge from www.nil.com.

EIGRP stub routers: virtual classroom recording

In my April IP Corner article, Scaling EIGRP Networks with Stub Routers, I've described how you can use EIGRP stub routers to improve the convergence time of large EIGRP networks and increase their stability. Now you can augment the article with a recording of the virtual classroom presentation I did a few days ago, which gives you even more in-depth details on the stub router technology and modifications Cisco made to EIGRP algorithms.

Changes in EIGRP summary address are no longer disruptive

Earlier IOS versions treated changes in EIGRP summary address configuration (configured with the ip summary-address eigrp interface configuration command) very disruptively: all EIGRP sessions across the affected interface were cleared, sometimes resulting in a large number of routes entering active state, potentially leading to a stuck-in-active condition.

Recent IOS releases are more lenient: router with a change in summary address requests a resync (logged as graceful-restart on adjacent routers). A lot of updates and queries are still sent, but the adjacencies themselves are preserved:

• When configuring a summary route, all more specific prefixes on downstream routers enter active state.
• When a summary is removed, only the summary prefix itself enters active state and the affected router sends queries to all its neighbors, while the more specific prefixes are sent as regular EIGRP updates to the neighbors across the affected interface.

A change in EIGRP summary generates the following output on the router under configuration:

a1(config)#interface serial 0/0/0.100
a1(config-subif)#ip summary-address eigrp 1 0.0.0.0 0.0.0.0
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.2 (Serial0/0/0.100) is resync: summary configured
a1(config-subif)#no ip summary-address eigrp 1 0.0.0.0 0.0.0.0
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.2 (Serial0/0/0.100) is resync: summary configured

... and the downstream router generates log messages similar to these:

b1#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.1 (Serial0/0/0.100) is resync: peer graceful-restart

Scaling EIGRP networks with stub routers

The April IP Corner article describes EIGRP stub routers, a feature that can significantly improve the stability of large EIGRP networks. I'm describing the theory behind EIGRP stub routers, how they reduce EIGRP traffic and decrease the convergence times in large hub-and-spoke networks as well as how you use undocumented IOS features to build fully redundant dual router stub sites.

EIGRP load balancing based on interface load

EIGRP computes its composite metric from five parameters, one of them being interface load, therefore raising the theoretical possibility of having route metrics that include interface load. However, tweaking EIGRP K-values with the metric weights command to include interface load in metric calculations is highly discouraged - every change in interface load could lead to network instability. Even worse, whenever an interface load would increase, the increased composite metric of the afftected routes in EIGRP topology table would cause them to enter active state (and the router to start the DUAL algorithm trying to find more optimum paths toward the destination).

To make the whole idea even more impractical, EIGRP does not scan the interface load (and other parameters influencing the metric) on periodical basis, but only when triggered by a change in network topology (for example, interface or neighbor up/down even).

Note: this article is part of You've asked for it series.

Practice EIGRP configuration in MPLS VPN environment

If you would like to test how EIGRP works within an MPLS VPN, you can do that in our remote labs. If you have partner-level Cisco Connection Online access, you can do it free of charge:

• Start Partner e-learning connection.
• After landing on the main PEC page, click here (or paste http://cisco.partnerelearning.com/peclms/lang-en/management/LMS_TrainLedInfo.asp?UserMode=0&LEDefId=20318 in the browser address bar)

If you're note working for a Cisco partner, you can buy the whole set of MPLS remote labs from NIL Data Communications.

EIGRP goodbye message

In IOS release 12.3(1.4), Cisco has added Goodbye message to EIGRP protocol. Previously, whenever the router would need to tear down EIGRP adjacency (for example, due to changed summary addresses), it would simply erase the neighbor from its EIGRP neighbor table and pretend the it's just encountered a new neighbor on the next hello message. As the adjacent device does not participate in this charade, it becomes confused resulting in delayed adjacency establishment. The whole process is described in details in my EIGRP book, which is unfortunately out-of-print for a few years and is available only as an on-line book on Safari.

With the Goodbye message, both neighbors tear down the adjacency in an orderly fashion and reestablish it immediately after receiving the EIGRP HELLO message.You can monitor the new EIGRP hello messages with the debug eigrp packet hello command, the Goodbye message also triggers a logging message if the EIGRP logging is enabled with the eigrp log-neighbor-changes command (default settings):

a1#debug eigrp packet hello
EIGRP Packets debugging is on
(HELLO)
21:27:50: EIGRP: Received HELLO on Serial0/0/0.100 nbr 172.16.1.2
21:27:50: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
21:27:50: Inteface goodbye received
21:27:50: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.2 (Serial0/0/0.100) is down: Interface Goodbye received
21:27:54: EIGRP: Sending HELLO on Serial0/0/0.100
21:27:54: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
21:27:54: EIGRP: Received HELLO on Serial0/0/0.100 nbr 172.16.1.2
21:27:54: AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
21:27:54: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.2 (Serial0/0/0.100) is up: new adjacency