EIGRP PE-CE Routing Protocol Overview, Configuration, and Verification

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. As shown in Table 5-2, six extended BGP communities have been defined to carry the EIGRP routes across the MPLS backbone via MP-BGP.

Figure 5-21 gives the details on the extended BGP community attribute that are attached to sample routes 192.168.20.0 and 192.168.99.0.

Figure 5-21. BGP Extended Communities Explained

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 All PE Routers

Figure 5-22 shows an MPLS VPN provider network providing MPLS VPN services to Customer A. PE1-AS1 and PE2-AS1 are configured for EIGRP AS 101.

Figure 5-22. 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. Figure 5-22 shows that the VRF Cust_A routing table on 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. As shown in Figure 5-22, 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. As shown in the figure, 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 All 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. Figure 5-23 shows an MPLS VPN provider network using different EIGRP AS on PE routers PE1-AS1 and PE2-AS1. 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.

Figure 5-23. Route Propagation When EIGRP AS Is Different on PE Routers

The sequence shown in 1 through 4 in the section "Route Propagation When EIGRP AS Is Same on All PE Routers" 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. As illustrated in Figure 5-23, CE1-A receives 192.168.20.0/24 and 192.168.99.0/24 as external routes.

Configuration Flowchart for EIGRP PE-CE Routing

Figure 5-24 shows the configuration flowchart to configure EIGRP PE-CE routing.

Figure 5-24. EIGRP PE-CE Routing Configuration Flowchart

The following are key points to be noted from the configuration flowchart:

• Address family configuration mode is used to configure the EIGRP AS for a given VRF.
• To allow a single EIGRP process to be used, the EIGRP AS has to be configured within the EIGRP address family configuration mode.

Other EIGRP configuration steps are the same as with normal EIGRP configuration. The default metric should be specified for the redistribution of non-EIGRP routes.

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. Figure 5-25 shows an MPLS VPN service provider providing MPLS VPN services to Customer A and Customer B sites:

• Customer A Network – Customer A has CE1-A and CE2-A located in the same VPN, VPN-A. They are part of EIGRP AS 101. EIGRP AS 101 is configured for VRF Cust_A on PE1-AS1 and PE2-AS1.
• Customer B Network – Customer B has CE1-B and CE2-B located in the same VPN, VPN-B. CE1-B and CE2-B belong to different EIGRP AS, 201 and 202. PE1-AS1 and PE2-AS1 have EIGRP AS 201 and 202 configured for VRF Cust_B, respectively.

Figure 5-25. MPLS VPN Network Implementing EIGRP PE-CE Routing with Same and Different EIGRP

The steps to configure EIGRP PE-CE routing are as follows:

Final Configuration for PE Routers

Example 5-36 shows the final configuration for the PE routers.

Example 5-36. Final Configuration for the PE Routers

hostname PE1-AS1 ! ip cef ! ip vrf Cust_A rd 1:100 route-target export 1:100 route-target import 1:100 ! ip vrf Cust_B rd 1:200 route-target export 1:200 route-target import 1:200 ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Serial0/0 description connected to P1-AS1 ip address 10.10.10.1 255.255.255.252 mpls ip ! interface Serial1/0 description connected to CE1-A ip vrf forwarding Cust_A ip address 172.16.1.1 255.255.255.252 ! interface Serial2/0 description connected to CE1-B ip vrf forwarding Cust_B ip address 192.168.1.1 255.255.255.252 ! router eigrp 1 auto-summary ! address-family ipv4 vrf Cust_B redistribute bgp 1 metric 1000 100 255 1 1500 network 192.168.1.0 no auto-summary autonomous-system 201 exit-address-family ! address-family ipv4 vrf Cust_A redistribute bgp 1 metric 1000 100 255 1 1500 network 172.16.0.0 no auto-summary autonomous-system 101 exit-address-family ! router ospf 1 router-id 10.10.10.101 network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community extended exit-address-family ! address-family ipv4 vrf Cust_B redistribute eigrp 201 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf Cust_A redistribute eigrp 101 no auto-summary no synchronization exit-address-family _________________________________________________________________________ hostname PE2-AS1 ! ip cef ! ip vrf Cust_A rd 1:100 route-target export 1:100 route-target import 1:100 ! ip vrf Cust_B rd 1:200 route-target export 1:200 route-target import 1:200 ! interface Loopback0 ip address 10.10.10.102 255.255.255.255 ! interface Serial0/0 description connected to P1-AS1 ip address 10.10.10.5 255.255.255.252 mpls ip ! interface Serial1/0 description connected to CE2-A ip vrf forwarding Cust_A ip address 172.16.2.1 255.255.255.252 ! interface Serial2/0 description connected to CE2-B ip vrf forwarding Cust_B ip address 192.168.2.1 255.255.255.252 ! router eigrp 1 auto-summary ! address-family ipv4 vrf Cust_B redistribute bgp 1 metric 1000 100 255 1 1500 network 192.168.2.0 no auto-summary autonomous-system 202 exit-address-family ! address-family ipv4 vrf Cust_A redistribute bgp 1 metric 1000 100 255 1 1500 network 172.16.0.0 no auto-summary autonomous-system 101 exit-address-family ! router ospf 1 router-id 10.10.10.102 network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community extended exit-address-family ! address-family ipv4 vrf Cust_B redistribute eigrp 202 no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf Cust_A redistribute eigrp 101 no auto-summary no synchronization exit-address-family

Final Configuration for CE Routers

Example 5-37 shows the final configurations for the CE routers for Customer A (CE1-A and CE2-A) and Customer B (CE1-B and CE2-B).

Example 5-37. Final Configurations for CE1-A, CE2-A, CE1-B, and CE2-B

hostname CE1-A ! interface Ethernet0/0 description VPN-A Site 1 network ip address 172.16.10.1 255.255.255.0 ! interface Serial1/0 description connected to PE1-AS1 ip address 172.16.1.2 255.255.255.252 ! router eigrp 101 network 172.16.0.0 no auto-summary _________________________________________________________________________ hostname CE2-A ! interface Ethernet0/0 description VPN-A Site 2 network ip address 172.16.20.1 255.255.255.0 ! interface Serial1/0 description connected to PE2-AS1 ip address 172.16.2.2 255.255.255.252 ! router eigrp 101 network 172.16.0.0 no auto-summary _________________________________________________________________________ hostname CE1-B ! interface Ethernet0/0 description VPN-B Site1 network ip address 192.168.10.1 255.255.255.0 ! interface Serial1/0 description connected to PE1-AS1 ip address 192.168.1.2 255.255.255.252 ! router eigrp 201 network 192.168.1.0 network 192.168.10.0 no auto-summary _________________________________________________________________________ hostname CE2-B ! interface Ethernet0/0 description VPN-B Site2 network ip address 192.168.20.1 255.255.255.0 ! interface Serial1/0 description connected to PE2-AS1 ip address 192.168.2.2 255.255.255.252 ! router eigrp 202 network 192.168.2.0 network 192.168.20.0 no auto-summary

Verify Basic EIGRP PE-CE Routing

The steps to verify EIGRP PE-CE routing are as follows:

Routing Loops and Suboptimal Routing

Routing loop and suboptimal routing generally occur because of mutual redistribution taking place between EIGRP PE-CE and MP-BGP in an MPLS VPN environment.

Routing Loops

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

Figure 5-26 shows an MPLS VPN network for Customer A that has three sites, Site 1, Site 2, and Site 3. Site 3 is multihomed. The figure also shows that EIGRP route 172.16.20.0/24 received by the multihomed site (Site 3) is again redistributed into the backbone at PE1-AS1.

Figure 5-26. Multi-Homed 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

Figure 5-27 illustrates the other 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.

Figure 5-27. Backbone Reinjecting Routes into Multihomed Site

This type of behavior is not noticed when the network is stable because the administrative distance makes sure that both PE routers prefer the route learned via EIGRP.

Count to Infinity

Referring to Figure 5-27, 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). As shown in Figure 5-27, 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, as illustrated in Figure 5-28, data packets from CE1-A to CE2-A will be forwarded by PE1-AS1 to CE3-A, causing suboptimal routing.

Figure 5-28. 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. Figure 5-29 shows the cost community attribute.

Figure 5-29. 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. It was integrated in Cisco IOS Release 12.0(27)S, 12.3(8)T, and 12.2(25)S. 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. Figure 5-30 shows the BGP cost community operation.

Figure 5-30. BGP Cost Community Operation

As shown in Figure 5-30, 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.

Multihomed Sites and EIGRP SoO

Figure 5-31 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.

Figure 5-31. Multihomed Site and EIGRP SoO

The following sequence takes place when 172.16.20.0/24 is propagated to CE1-A:

1. CE2-A originates a route 172.16.20.0/24.
2. PE2-AS1 forwards the route to CE4-A via EIGRP and to PE1-AS1 via MP-iBGP. The EIGRP route will be tagged with the new EIGRP attribute called SoO, here 1:101 to indicate that the route came from the MPLS backbone.
3. CE4-A forwards that 172.16.20.0/24 update to CE3-A.
4. 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 BGP-learned route; the EIGRP route from CE3-A is filtered out because it contains the same SoO value as the interface through which the route was received.

Backdoor Link and EIGRP SoO

Figure 5-32 illustrates EIGRP SoO in sites, interconnected with a backdoor link.

Figure 5-32. Backdoor Link and EIGRP SoO

The following sequence describes the process of route selection in this scenario:

1. CE2-A propagates 172.16.20.0/24 to PE2-AS1.
2. PE2-AS1 forwards 172.16.20.0/24, the route to CE4-A via EIGRP and to PE1-AS1 via MP-iBGP. The EIGRP route will be tagged with the EIGRP SoO value 1:20 to indicate that the route came from the MPLS backbone and was injected into Site 4 with 1:20.
3. PE1-AS1 receives two updates for 172.16.20.0, one via EIGRP from CE2 and one via MP-iBGP from PE2. Also note that the update, when traveling via the backdoor link, will carry EIGRP SoO value 1:20 when propagated to CE3-A, and CE3-A uses 1:10 to propagate this route to PE1-AS1.
4. PE1-AS1 receives two updates for 172.16.20.0/24, one via EIGRP from CE3-A with SoO 1:10, which it filters because it contains the same SoO value as the interface through which the route was received and only considers the one via MP-iBGP from PE2-AS1.

EIGRP SoO Configuration

Example 5-48 shows a sample EIGRP SoO configuration.

Example 5-48. EIGRP SoO Configuration

interface serial 2/0 ip vrf sitemap SOO-VPNA ! route-map SOO-VPNA permit 10 set extcommunity SoO 1:10

EIGRP PE-CE Configuration Scenario 2 – BGP Cost Community Feature and EIGRP SoO in MPLS VPN Network with Backdoor Link

Figure 5-32 shows an MPLS VPN environment where Customer A has four sites. CE1-A, CE2-A, CE3-A, and CE4-A belong to Sites 1, 2, 3, and 4, respectively. All customer edge routers are running EIGRP as a PE-CE routing protocol and belong to AS 101. PE1-AS1 and PE2-AS1 are configured to run EIGRP PE-CE routing.

The objective of this setup is to demonstrate EIGRP PE-CE routing in an MPLS VPN environment when there is

• No BGP cost community or EIGRP SoO
• BGP cost community and EIGRP SoO involved

No BGP Cost Community or EIGRP SoO

Figure 5-33 shows the MPLS VPN network with routing table for Cust_A VRF on PE1-AS1 and PE2-AS1. This figure also shows the routing table for CE3-A and CE4-A. With no BGP cost community (CC) or EIGRP SoO, the data path

• For traffic originating from CE1-A (172.16.10.0) to CE2-A (172.16.20.0) is from CE1-A via CE3-A, CE4-A, and PE2-AS1 to destination network on CE2-A, and vice versa.
• For traffic originating from CE3-A (172.16.30.0) to CE4-A (172.16.40.0) is from CE3-A to CE4-A via the backdoor link and vice versa.
• For traffic originating from CE3-A (172.16.30.0) to CE2-A (172.16.20.0) is from CE3-A to CE4-A via the backdoor link, then to PE2-AS1, and then to destination network on CE2-A, and vice versa.
• For traffic originating from CE4-A (172.16.40.0) to CE1-A (172.16.10.0) is from CE4-A to CE3-A via the backdoor link, then to PE1-AS1, and then to the destination network on CE1-A, and vice versa.

Figure 5-33. Suboptimal Routing Without BGP CC and EIGRP SoO

In other words, all these traffic paths are forwarded through the backdoor link connecting CE3-A and CE4-A. An example of the traceroute to 172.16.20.1 and 172.16.40.1 is shown in Example 5-49.

Example 5-49. Traceroute to 172.16.20.1 and 172.16.40.1

CE1-A#traceroute 172.16.20.1 Type escape sequence to abort. Tracing the route to 172.16.20.1 1 172.16.1.1 20 msec 20 msec 20 msec 2 172.16.3.2 20 msec 20 msec 8 msec 3 172.16.5.2 60 msec 40 msec 40 msec 4 172.16.4.1 40 msec 48 msec 40 msec 5 172.16.2.2 40 msec 40 msec * _________________________________________________________________________ CE1-A#traceroute 172.16.40.1 Type escape sequence to abort. Tracing the route to 172.16.40.1 1 172.16.1.1 20 msec 20 msec 32 msec 2 172.16.3.2 20 msec 20 msec 20 msec 3 172.16.5.2 40 msec 40 msec * _________________________________________________________________________ CE3-A#traceroute 172.16.40.1 Type escape sequence to abort. Tracing the route to 172.16.40.1 1 172.16.5.2 16 msec 20 msec * _________________________________________________________________________ CE3-A#traceroute 172.16.20.1 Type escape sequence to abort. Tracing the route to 172.16.20.1 1 172.16.5.2 20 msec 24 msec 20 msec 2 172.16.4.1 20 msec 20 msec 20 msec 3 172.16.2.2 28 msec 20 msec *

Using BGP CC or EIGRP SoO

There is no configuration required for BGP CC. Check Cisco.com for Cisco IOS using the BGP CC for EIGRP-based MPLS VPN networks with backdoor links. This scenario was performed using 12.0(31)S. EIGRP SoO is configured on PE1-AS1 and PE2-AS1 and on the backdoor links connecting CE3-A and CE4-A. Figure 5-34 shows routing with BGP CC and EIGRP SoO.

Figure 5-34. Routing with BGP CC and EIGRP SoO

Final Configurations for Networks Using BGP CC and EIGRP SoO

The final configurations for networks using BGP CC and EIGRP SoO are shown in Example 5-50.

Example 5-50. CE and PE Configuration for Network Using BGP CC and EIGRP SoO

hostname CE1-A ! interface Ethernet0/0 description VPN-A Site 1 network ip address 172.16.10.1 255.255.255.0 ! interface Serial1/0 description connected to PE1-AS1 ip address 172.16.1.2 255.255.255.252 ! router eigrp 101 network 172.16.0.0 no auto-summary _________________________________________________________________________ hostname CE2-A ! interface Ethernet0/0 description VPN-A Site 2 network ip address 172.16.20.1 255.255.255.0 ! interface Serial1/0 description connected to PE2-AS1 ip address 172.16.2.2 255.255.255.252 ! router eigrp 101 network 172.16.0.0 no auto-summary _________________________________________________________________________ hostname CE3-A ! interface Ethernet0/0 ip address 172.16.30.1 255.255.255.0 ! interface Serial1/0 bandwidth 1000 ip vrf sitemap SOO-VPNA ip address 172.16.5.1 255.255.255.252 ! interface Serial2/0 ip address 172.16.3.2 255.255.255.252 ! router eigrp 101 network 172.16.0.0 no auto-summary ! route-map SOO-VPNA permit 10 set extcommunity soo 1:10 _________________________________________________________________________ hostname CE4-A ! interface Ethernet0/0 ip address 172.16.40.1 255.255.255.0 ! interface Serial1/0 bandwidth 1000 ip vrf sitemap SOO-VPNA ip address 172.16.5.2 255.255.255.252 ! interface Serial2/0 ip address 172.16.4.2 255.255.255.252 ! router eigrp 101 network 172.16.0.0 no auto-summary ! route-map SOO-VPNA permit 10 set extcommunity soo 1:20 _________________________________________________________________________ hostname PE1-AS1 ! ip cef ! ip vrf Cust_A rd 1:100 route-target export 1:100 route-target import 1:100 ! interface Loopback0 ip address 10.10.10.101 255.255.255.255 ! interface Serial0/0 description connected to P1-AS1 ip address 10.10.10.1 255.255.255.252 mpls ip ! interface Serial1/0 description connected to CE1-A ip vrf forwarding Cust_A ip address 172.16.1.1 255.255.255.252 ! interface Serial2/0 description connected to CE3-A ip vrf forwarding Cust_A ip vrf sitemap SOO-VPNA ip address 172.16.3.1 255.255.255.252 ! router eigrp 1 ! address-family ipv4 vrf Cust_A redistribute bgp 1 metric 1000 100 255 1 1500 network 172.16.0.0 no auto-summary autonomous-system 101 exit-address-family ! router ospf 1 router-id 10.10.10.101 network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization neighbor 10.10.10.102 remote-as 1 neighbor 10.10.10.102 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.102 activate neighbor 10.10.10.102 send-community both exit-address-family ! address-family ipv4 vrf Cust_A redistribute eigrp 101 no auto-summary no synchronization exit-address-family ! route-map SOO-VPNA permit 10 set extcommunity soo 1:10 _________________________________________________________________________ hostname PE2-AS1 ! ip cef ! ip vrf Cust_A rd 1:100 route-target export 1:100 route-target import 1:100 ! interface Loopback0 ip address 10.10.10.102 255.255.255.255 ! interface Serial0/0 description connected to P1-AS1 ip address 10.10.10.5 255.255.255.252 mpls ip ! interface Serial1/0 description connected to CE2-A ip vrf forwarding Cust_A ip address 172.16.2.1 255.255.255.252 ! interface Serial2/0 description connected to CE4-A ip vrf forwarding Cust_A ip vrf sitemap SOO-VPNA ip address 172.16.4.1 255.255.255.252 ! router eigrp 1 ! address-family ipv4 vrf Cust_A redistribute bgp 1 metric 1000 100 255 1 1500 network 172.16.0.0 no auto-summary autonomous-system 101 exit-address-family ! router ospf 1 router-id 10.10.10.102 network 10.0.0.0 0.255.255.255 area 0 ! router bgp 1 no synchronization neighbor 10.10.10.101 remote-as 1 neighbor 10.10.10.101 update-source Loopback0 no auto-summary ! address-family vpnv4 neighbor 10.10.10.101 activate neighbor 10.10.10.101 send-community both exit-address-family ! address-family ipv4 vrf Cust_A redistribute eigrp 101 no auto-summary no synchronization exit-address-family ! route-map SOO-VPNA permit 10 set extcommunity soo 1:20

Verify BGP CC and EIGRP SoO

The steps to verify BGP CC and EIGRP SoO are

EIGRP PE-CE Routing Command Summary

Table 5-3 shows the relevant EIGRP PE-CE routing commands used in this chapter.