The EIGRP Support for 6PE/6VPE feature enables native IPv6 Enhanced Interior Gateway Routing Protocol (EIGRP) routes to preserve their original characteristics (metric and other attributes like type, delay, bandwidth, and the maximum transmission unit [MTU]) while being redistributed from one IPv6 EIGRP site to another over a service-provider VPN cloud or an IPv6 provider edge (6PE) Multiprotocol Label Switching-VPN (MPLS-VPN) network. The EIGRP 6PE/6VPE implementation allows native IPv6 EIGRP routes to run on provider-edge (PE) and customer-edge (CE) devices while preserving their original characteristics. MPLS supports only IPv4. Therefore, the Border Gateway Protocol (BGP) is used to redistribute IPv6 routes over a service-provider VPN cloud or a 6PE MPLS-VPN network.

Figure 1. EIGRP 6PE/6VPE Functionality

The figure above shows two EIGRP sites connected through a service-provider VPN cloud. The two sites are also connected through a backdoor link, which is a backdoor device that is not part of the VPN network. Typically, a backdoor link is a high-cost, low-speed satellite link that is used as a backup path between the EIGRP sites in case the primary VPN is down or unavailable. The CE devices in the EIGRP sites are connected to the service-provider PE devices. The ideal path for both the EIGRP sites to connect with each other is through the VPN cloud. Before the EIGRP Support for 6PE/6VPE feature, a route redistributed from the CE in EIGRP site 1, through the PEs in the VPN cloud, into EIGRP site 2 would appear as an external route in the target CE cloud. This behavior is due to the route losing its original route attributes when it traverses through an external cloud. External routes have higher administrative distances than internal routes. Therefore, the EIGRP route that now appears as an external route in the target CE cloud has a higher administrative distance than the backdoor link, which is an internal route. The external EIGRP route becomes the less preferred route, resulting in the backdoor link becoming the primary route between the EIGRP sites, which is an undesirable behavior.

The EIGRP Support for 6PE/6VPE feature enables EIGRP route metrics to be preserved across a service-provider VPN network or a 6PE MPLS-VPN backbone through the use of BGP Extended Communities. When an EIGRP route with preserved metrics is received by the target PE device, the route is advertised to the receiving CE device as an internal route, along with the original metric and type. Because an internal route has a lower administrative distance than an external route, the internal route becomes the preferred route of communication between the two EIGRP sites.

For the Enhanced Interior Gateway Routing Protocol (EIGRP) to recreate route metrics derived from the originating customer site, the original metrics are encoded into Border Gateway Protocol (BGP) Extended Communities by the provider-edge (PE) device that receives the routes from the transmitting customer-edge (CE) device. These extended communities are then transported across the Multiprotocol Label Switching-VPN (MPLS-VPN) backbone by BGP from one customer site to the other (peering customer site). After the peering customer site receives the routes, BGP redistributes the routes into EIGRP. EIGRP, then, extracts the BGP Extended Community information and reconstructs the routes as they appeared in the original customer site.

The following rules govern BGP Extended Communities:

Non-EIGRP-Originated Routes: If a non-EIGRP-originated route is received through BGP and the route has no extended community information for EIGRP, BGP advertises the route to the receiving CE as an external EIGRP route by using the route’s default metric. If no default metric is configured, BGP does not advertise the route to the CE.

EIGRP-Originated Internal Routes: If an EIGRP-originated internal route is received through BGP and the route has extended community information for EIGRP, the PE sets the route type to “internal” if the source autonomous system number matches the autonomous system number configured for this VPN routing and forwarding (VRF) instance. BGP, then, reconstructs and advertises the route to the receiving CE as an internal EIGRP route by using the extended community information. If there is no autonomous system match, these routes are treated as non-EIGRP-originated routes.

EIGRP-Originated External Routes: If an EIGRP-originated external route is received through BGP and the route has extended community information for EIGRP, the PE sets the route type to “external” if the source autonomous system number matches the autonomous system number configured for this VRF instance. BGP, then, reconstructs and advertises this external route to the receiving CE as an external EIGRP route by using the extended community information. If there is no autonomous system match, these routes are treated as non-EIGRP-originated routes.

The EIGRP 6PE/6VPE feature manages native and non-native Enhanced Interior Gateway Routing Protocol (EIGRP) routes by using the redistribute and the default metric commands, respectively. By using the redistribute bgp as-number command, you can ensure that only Border Gateway Protocol (BGP) routes with BGP Extended Community information are distributed into EIGRP. EIGRP uses this information to recreate the original EIGRP route. If the BGP Extended Community information is missing and the default metric is not specified, EIGRP will not learn the route from BGP.

By using the redistribute bgp as-number metric-type type-value command, you can ensure that the metric values configured using this command are used only for BGP routes redistributed into EIGRP. EIGRP looks for BGP Extended Community information, and if this information is found, EIGRP uses this information to recreate the original EIGRP route. If the Extended Community information is missing, EIGRP uses the metric values configured using this command to determine whether the route is the preferred route.

By using the default-metric bandwidth delay reliability loading mtu command, you can ensure that the metric values configured using this command are used for any non-EIGRP routes being redistributed into EIGRP. If the received route is a BGP route, EIGRP looks for BGP Extended Community information, and if this information is found, EIGRP uses this information to recreate the original EIGRP route. If the extended community information is missing, EIGRP uses the metric values configured to determine whether the route is the preferred route.

The EIGRP 6PE/6VPE Site of Origin (SoO) functionality allows an Enhanced Interior Gateway Routing Protocol (EIGRP) network to support complex topologies, such as Multiprotocol Label Switching-VPN (MPLS-VPN) links between sites with backdoor links, customer-edge (CE) devices that are dual-homed to different provider-edge (PE) devices, and PEs supporting CEs from different sites within the same VPN routing and forwarding (VRF) instance. Path selection within the EIGRP network containing PE-CE links is based on route metrics that allow either the link through the VPN or the EIGRP backdoor to act as the primary (best) link or the backup link, if the primary link fails. EIGRP accomplishes this path selection by retrieving the Site of Origin (SoO) attribute from routes redistributed from the Border Gateway Protocol (BGP) network. This BGP/EIGRP interaction takes place through the use of the BGP Cost Community Extended Community attribute.

When routes are redistribued into EIGRP from a BGP network, BGP Cost Community Extended Community attributes are added to the routes. These attributes include the SoO attribute. The SoO attribute is used to identify the site of origin of a route and prevent advertisement of the route back to the source site. To enable the EIGRP SoO functionality, you must configure the ip vrf sitemap command on the PE interface that is connected to the CE device. This command enables SoO filtering on the interface. When EIGRP on the PE device receives CE routes on the interface that has a SoO value defined, EIGRP checks each route to determine whether there is an SoO value associated with the route that matches the interface SoO value. If the SoO values match, the route will be filtered. This filtering is done to stop routing loops.

When EIGRP on the PE receives a route that does not contain an SoO value or contains an SoO value that does not match the interface SoO value, the route will be accepted into the topology table so that it can be redistributed into BGP. When the PE redistributes an EIGRP route that does not contain an SoO value into BGP, the SoO value that is defined on the interface used to reach the next hop (CE) is included in the Extended Communities attribute associated with the route. If the EIGRP topology table entry already has an SoO value associated with the route, this SoO value, instead of the interface SoO value, will be included with the route when it is redistributed into the BGP table. Any BGP peer that receives these prefixes will also receive the SoO value associated with each prefix, identifying the site, where each prefix originated.

The EIGRP SoO functionality ensures that BGP does not follow its normal path-selection behavior, where locally derived routes (such as native EIGRP routes redistributed into BGP) are preferred over BGP-derived routes.

For more information on the Site of Origin functionality, see the “EIGRP MPLS VPN PE-CE Site of Origin” chapter in the IP Routing: EIGRP Configuration Guide.