MPLS – EIGRP PE-CE Routing

EIGRP PE-CE routing protocol is used by service providers for customers who use EIGRP as their IGP routing protocol and, hence, prefer to use EIGRP to exchange routing information between the customer sites across an MPLS VPN backbone.

In an MPLS VPN environment, to achieve this, the original EIGRP metrics must be carried inside MP-BGP updates. This is achieved by using BGP extended community attributes to carry and preserve EIGRP metrics when crossing the MP-iBGP domain. These communities define the intrinsic characteristics associated with EIGRP, such as the AS number or EIGRP cost metric like bandwidth, delay, load, reliability, and MTU.

BGP Extended Communities for EIGRP PE-CE Routing

EIGRP Route Propagation

Route propagation in MPLS VPN networks using EIGRP PE-CE routing is based on EIGRP AS configured on the PE routers. In an MPLS VPN environment, EIGRP AS can be the same on all PE routers or different on all PE routers.

Route Propagation When EIGRP AS Is Same on PE Routers

The following sequence takes place when CE2-A is sending 172.16.20.0 and 209.165.201.0 to CE1-A:

  1. CE2-A redistributes OSPF network 209.165.127.0/27 as an EIGRP external route (D EX) and 172.16.20.0/24 as an internal route (D) to PE2-AS1.

  2. PE2-AS1 receives 172.16.20.0/24 as internal route with EIGRP metric 2195456 and 209.165.127.0/27 as an external route with EIGRP metric 3097600.

  3. The EIGRP metrics for 172.16.20.0 and 209.165.127.0 are copied into extended BGP attributes as BGP MEDs, and extended communities containing EIGRP information such as AS, MTU, route type, and so on are attached when EIGRP routes are redistributed into MP-BGP. The routes 172.16.20.0 and 209.165.127.0 are then propagated to PE1-AS1 via MP-iBGP session.

  4. PE1-AS1 receives the BGP VPNv4 routes 172.16.20.0/24 and 209.165.127.0/27 from PE2-AS1. The EIGRP metric for the routes are not altered and remain the same when propagated though the MP-BGP backbone.

  5. PE2-AS1 checks the attributes received in the route, and, if route type is internal (if the MSB bit in the 0x8800 BGP extended community attribute is set) and the source AS matches what is configured on the receiving PE router, the route is advertised as EIGRP internal route. If the route type is external (MSB bit in 0x8800 is not set), the route is advertised to the CE as an external EIGRP route.
    • PE1-AS1, therefore, uses the extended community attribute information to reconstruct the original EIGRP routing update when redistributing from MP-BGP into EIGRP.
    • This redistribution behavior takes place only if the PE2-AS1 EIGRP AS number is equal to the PE1-AS1, PE’s EIGRP AS number.
    • The PE routers act as EIGRP query boundaries.
    • In this case, the route type for 172.16.20.0 is internal and source AS 101 matches on the receiving router PE1-AS1. Therefore, 172.16.20.0/24 is propagated as an EIGRP internal route to CE1-A. The route type for 209.165.127.0/27 is external and, therefore, is propagated to CE1-A as an external route.

  6. CE1-A receives the 172.16.20.0 as an internal route and 209.165.127.0 as an external route.

Route Propagation When EIGRP AS Is Different on PE Routers

If the two EIGRP AS numbers are different, the normal redistribution rules apply; that is, external EIGRP routes are created when the customer routes are redistributed into EIGRP from MP-BGP updates.

Because the MPLS backbone is transparent to the CE routing protocol, no EIGRP adjacency is formed or EIGRP updates and queries sent across the PE routers.

The sequence shown in 1 through 4 in the section remains the same except for networks 192.168.99.0 and 192.168.20.0 and the metric:

  1. PE2-AS1 checks the attributes received in the route, and, if the route type is internal and the source AS does not match or if the route type is external, the route is advertised to the CE as an external EIGRP route. The route will not use the extended community information because it did not originate from the same AS.
    • Route type for 192.168.20.0 is internal and source AS, which is 202, does not match the configured AS on PE1-AS1 (201). Therefore, PE1-AS1 propagates that as an external route to CE1-A. The route type for 192.168.99.0 is external, and, therefore, both routes are propagated to CE1-A as external routes.

  2. CE1-A receives 192.168.20.0/24 and 192.168.99.0/24 as external routes.

EIGRP PE-CE Routing Configuration

Scenario 1: Basic EIGRP PE-CE Routing Configuration

The objective of this configuration scenario is to demonstrate EIGRP PE-CE configuration and EIGRP route propagation when PE routers belong to the same EIGRP AS for a VRF and when they are in different EIGRP AS for a VRF.

Step 1: Enable the global EIGRP routing process

  • Enable the global EIGRP routing process on PE routers.

Step 2: Define per VRF EIGRP routing context and parameters

  • Ensure that no auto-summary is configured; otherwise, EIGRP summarizes networks at their classful boundaries. The command no auto-summary may be enabled by default depending on the version of IOS in use.
  • To allow a single global EIGRP process to be used, the EIGRP AS has to be configured within the EIGRP address family configuration mode. This is accomplished by configuring autonomous-system as-number in address-family mode. This allows the same EIGRP AS number to be used in multiple VRFs.
				
					hostname PE1-AS1
!
router eigrp 1
 address-family ipv4 vrf Cust_B
 network 172.16.0.0
 no auto-summary
 autonomous-system 201
exit-address-family
				
			
				
					hostname PE2-AS1
!
router eigrp 1
 address-family ipv4 vrf Cust_B
 network 172.16.0.0
 no auto-summary
 autonomous-system 202
exit-address-family
				
			

Step 3: Redistribute EIGRP routes in BGP

Step 4: Redistribute BGP VPNv4 routes in EIGRP

				
					router bgp 1
 address-family ipv4 vrf Cust_A
 redistribute eigrp 101
exit
!
router eigrp 1
 address-family ipv4 vrf Cust_A
  redistribute bgp 1 metric 1000 100 255 1 1500
				
			
				
					router bgp 1
 address-family ipv4 vrf Cust_A
 redistribute eigrp 101
exit
!
router eigrp 1
 address-family ipv4 vrf Cust_A
  redistribute bgp 1 metric 1000 100 255 1 1500
				
			

Verify Basic EIGRP PE-CE Routing

Step 1: Verify EIGRP neighbor relationship

Step 2: Verify EIGRP route propagation for Cust_A and for Cust_B

Cust_A VRF RIB on PE2-AS1
Cust_B RIB on PE2-AS1

The EIGRP metric for 192.168.20.0 and for 172.16.20.0 is copied into these attributes when the EIGRP route is redistributed into MP-BGP. The command show ip bgp vpnv4 all x.x.x.x shows the extended BGP attributes that are attached to the route.

BGP VPNv4 Information for 172.16.20.0 on PE2-AS1
BGP VPNv4 Information for 192.168.20.0 on PE2-AS1

PE1-AS1 redistributing back from MP-BGP into EIGRP uses this information to reconstruct the original EIGRP routing update.

Shows that the EIGRP metric for 192.168.20.0 and 172.16.20.0 are preserved when crossing an MP-BGP domain by using the BGP extended community attributes.

BGP VPNv4 Information for 172.16.20.0 on PE1-AS1
BGP VPNv4 Information for 192.168.20.0 on PE1-AS1

Step 3: Verify EIGRP routes on CE Routers

For Customer B, the two EIGRP AS numbers are different (201 on PE1-AS1 and 202 on PE2-AS1); therefore, normal redistribution rules apply. External EIGRP routes (D EX) are created when the 192.168.20.0 is redistributed into EIGRP from MP-BGP updates received on PE1-AS1 from PE2-AS1.

For Customer A, shows that CE1-A has received EIGRP internal routes for 172.16.20.0 because ingress PE’s PE2-AS1 EIGRP AS number 101 is equal to the egress PE’s PE1-AS1 EIGRP AS number.

CE1-A RIB
CE1-B RIB

Step 4: Verify connectivity between sites

Routing Loops and Suboptimal Routing

Routing loops can occur in the following scenarios:

  • A route received by a multihomed site from the backbone through one link can be forwarded back to the backbone via the other link.
  • A route originated in a multihomed site and sent to the backbone through one link can come back through the other link.

Multihomed Site Reinjecting Routes into the Backbone

The following sequence takes place when reinjecting an EIGRP route into the backbone:

  1. 172.16.20.0/24 is advertised as EIGRP internal route to PE2-AS1.
  2. PE2-AS1 propagates 172.16.20.0/24 to CE4-A via EIGRP and sends 172.16.20.0/24 via the MP-iBGP session to PE1-AS1.
  3. CE4-A propagates 172.16.20.0/24 as an EIGRP internal route to CE3-A.
  4. CE3-A propagates 172.16.20.0/24 as an EIGRP internal route to PE1-AS1.

PE1-AS1 has to make the decision of which route to choose:

  • If the BGP update for 172.16.20.0/24 arrives first, it will be redistributed into EIGRP and sent to CE3-A. Because of the better composite metric, it will be preferred over the other EIGRP update because MPLS VPN does not add any delay or bandwidth limitation. This means that PE1-AS1 will never receive a second update and will, therefore, have only one possible path.
  • If the EIGRP update arrives first, it will be redistributed into BGP and sent back to PE2-AS1. PE2-AS1 will still prefer the original EIGRP update, but PE1-AS1 will never select the BGP derived path because it always prefers locally originated routes.

Overall, in this network, even if the administrative distance for EIGRP and BGP are the same, the routing table prefers the route with the lowest administrative distance (EIGRP is 90 or 170; iBGP is 200) by default.

Backbone Reinjecting Routes into Multihomed Site

Anoother scenario in which the route 172.16.50.0/24 originating in the multihomed site might be advertised back through the link connected to the PE router.

When the network is stable, PE1-AS1 and/or PE2-AS1 have two available paths for 172.16.50.0/24: one learned via MP-iBGP and one directly via EIGRP. If 172.16.50.0/24 goes down for some reason, the following sequence takes place:

  1. CE3-A and CE4-A routers send out query messages.

  2. Assuming PE1-AS1 has two routes, one via EIGRP and the other via MP-iBGP, when PE1-AS1 receives a query message, it will respond with an alternate path that is still available via MP-iBGP.

  3. CE3-A will get an alternate path to 172.16.50.0/24 via PE1-AS1.

  4. PE1-AS1 will receive a withdrawal message from PE2-AS1.

  5. PE1-AS1 will now have to withdraw the route that it has just advertised to CE3-A, which has propagated this information to CE4-A in the meantime, and CE4-A has already propagated it back to PE2-AS1.

  6. The query message originated by the PE1-AS1 router is now trying to catch the previous advertisement of 172.16.50.0/24. By the time the query message reaches PE2-AS1, PE2-AS1 has already advertised a new reachable update via MP-iBGP to PE1-AS1, which will again create an EIGRP update that will try to catch the previous query message.

  7. This process of looping reachable/unreachable messages continues until the maximum number of hops is reached.

This type of behavior is referred to as “count to infinity.”

Suboptimal Routing

Suboptimal routing often occurs because EIGRP (90 for internal and 170 for external routes) has a better administrative distance than iBGP (200). A routing table will always prefer an IGP-learned route because all IGPs have a better administrative distance (5 to 170) than internal BGP (200).

PE1-AS1 receives two updates for 172.16.20.0/24: one via EIGRP from CE3-A and one via MP-iBGP from PE2. PE1-AS1 will use the EIGRP-learned route because it has a better administrative distance (90 or 170) than an internal BGP route (200). Therefore, data packets from CE1-A to CE2-A will be forwarded by PE1-AS1 to CE3-A, causing suboptimal routing.

BGP Cost Community Feature and EIGRP Site of Origin

Routing loops and suboptimal routing can be avoided by using:

  • The BGP cost community feature, which can be used to force BGP to compare locally originated EIGRP routes and MP-iBGP routes based on the EIGRP metric
  • The EIGRP site of origin (SoO) feature on PE and CE routers that can be used to prevent routing loops

BGP Cost Community Feature

The BGP cost community feature introduces a new BGP extended community attribute called the cost community.

  • The cost community is a non-transitive extended community attribute that is passed to internal BGP and confederation peers but not external BGP peers.
  • The cost community feature allows you to customize the local route preference and influence the best path selection process by assigning cost values to specific routes.
  • The feature allows the PE router to compare routes coming from different protocols using different administrative distance values based on their metric.
  • BGP routes carrying the BGP cost community attribute will use EIGRP administrative distance instead of iBGP administrative distance to enable this comparison without the need to statically modify the administrative distance of either protocol.
  • When routes are redistributed from EIGRP into MP-BGP, they will be tagged with the BGP cost community attribute that will carry the composite EIGRP metric in addition to individual EIGRP attributes.
BGP Cost Community Attribute
  • The point of insertion (POI) value makes sure that the BGP route selection uses the BGP cost community before evaluating whether the route is locally originated or not. This allows the comparison of iBGP routes with EIGRP routes.
  • The BGP cost community will also be able to distinguish between internal and external EIGRP routes using the ID field:
    • internal routes will be encoded using ID 128
    • external routes will be encoded using ID 129
  • The route selection process, when using BGP cost communities, prefers the lowest BGP Cost Community ID, which in turn behaves like a normal EIGRP route selection in which internal routes are preferred over external routes. Internal EIGRP routes have a lower BGP Cost Community ID than external EIGRP routes.
  • The route selection will typically depend on the value in the BGP cost community’s Cost field, which carries the composite EIGRP metric.

The pre-best path POI was introduced in the BGP cost community feature to support mixed EIGRP-based MPLS VPN network topologies that contain backdoor links.

This POI is applied automatically to EIGRP routes that are redistributed into BGP. The pre-best path POI carries the EIGRP route type and metric. This POI influences the best path calculation process by influencing BGP to consider this POI before any other comparison step. There is no configuration required for inducing POI.

BGP Cost Community Operation

The following sequence takes place in which PE1-AS1 is able to select the best route based on the EIGRP metric and not based on administrative distance between EIGRP and iBGP:

  1. CE2-A originates 172.16.20.0/24 to PE2-AS1.

  2. PE2-AS1 forwards the route to CE4-A via EIGRP and to PE1-AS1 via MP-iBGP.

  3. PE1-AS1 receives two updates for 172.16.20.0/24, one via EIGRP from CE3-A and one via MP-iBGP from PE2-AS1. PE1-AS1 will use the MP-iBGP learned route because it is now capable of comparing the EIGRP composite metric between the real EIGRP route (from CE3-A) and the MP-iBGP route (from PE2-AS1) that is using the BGP cost community attribute to carry the original EIGRP composite metric.

  4. Packets from CE1-A to CE2-A will be forwarded by PE1-AS1 to PE2-AS1 because the routing table of VRF A contains the MP-iBGP route, which carried a lower composite EIGRP metric.

EIGRP SoO Attribute

To prevent routing loops, the EIGRP SoO attribute has been added to enable the tagging of internal and external EIGRP routes. This attribute is automatically exchanged between routing protocols (SoO-enabled EIGRP and MP-BGP) to prevent routing loops in multihomed environments where two-way redistribution is used. All CE routers must support this feature to enable the propagation of this attribute throughout the VPN, or at the minimum, the multihomed sites. The EIGRP SoO feature is used on PE and CE routers for the most effective loop prevention. Backdoor links are configured with EIGRP SoO for fastest convergence upon route loss.

EIGRP SoO Attribute Operation

Illustrates how routes that are injected into a multihomed site get tagged with an EIGRP SoO value 1:101. The receiving PE router will check all updates against the SoO value configured on the interface through which the update was received. If the values are equal, the update will be rejected, preventing routing loops as well as ensuring optimal routing.

Leave a Reply

Related Post