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.