Eigrp

EIGRP can be the PE-CE routing protocol. The usual disadvantage of the redistribution between iBGP and the routing protocol between the PE and CE router is present here, too. This means that redistributing the routes from BGP into EIGRP makes all the routes external EIGRP routes. However, as much EIGRP information as possible is coded in new BGP extended communities to alleviate the problem. This enables the remote PE router to reconstruct the EIGRP route with all its characteristics, including metric components, AS, TAG and, for external routes, the remote AS number, the remote ID, the remote protocol, and the remote metric. These are the EIGRP characteristics of a prefix that you can find in the topology table. If the EIGRP-advertised route is internal, the route is advertised as an internal route into the remote site if the destination AS matches the source AS carried by the BGP extended community. If the AS numbers do not match, the route is reconstructed as an external EIGRP route. Table 7-4 shows the extended BGP communities that convey the EIGRP information.

Table 7-4 BGP Extended Communities for EIGRP

Type

Usage

Value

0x8800

General route information

Flags + TAG

0x8801

Route metric information and autonomous system

Autonomous System + Delay

0x8802

Route metric information

Reliability + Hop Count + BW

0x8803

Route metric information

Reserved field + Load + MTU

0x8804

External route information

Remote Autonomous System + Remote ID

0x8805

External route information

Remote Protocol + Remote Metric

Example 7-29 demonstrates how BGP carries these extended communities. The prefix 10.10.100.1/32 is an internal EIGRP prefix, and the prefix 10.200.200.1/32 is an external EIGRP prefix.

Example 7-29 BGP Extended Communities for EIGRP

amsterdam#show ip bgp vpnv4 all 10.10.100.1

BGP routing table entry for 1:1:10.10.100.1/32, version 28

Paths: (1 available, best #1, table cust-one) Advertised to update-groups: 1

Local

Origin incomplete, metric 409600, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:1 Cost:pre-bestpath:128:409600 0x8800:32768:0

0x8801:42:153600 0x8802:65281:256000 0x8803:65281:1500, mpls labels in/out 22/nolabel sydney#show ip bgp vpnv4 all 10.200.200.1

BGP routing table entry for 1:1:10.200.200.1/32, version 91

Paths: (1 available, best #1, table cust-one)

Flag: 0x820

Not advertised to any peer Local

10.200.254.2 (metric 4) from 10.200.254.2 (10.200.254.2)

Origin incomplete, metric 409600, localpref 100, valid, internal, best Extended Community: RT:1:1 Cost:pre-bestpath:129:409600 0x8800:0:0 0x8801:42:153600 0x8802:65281:256000 0x8803:65281:1500 0x8804:0:168453121 0x8805:11:0, mpls labels in/out nolabel/31

Figure 7-24 shows how an EIGRP route is propagated across the MPLS VPN backbone from one EIGRP site to another.

Figure 7-24 Propagation of an EIGRP Route Across the MPLS VPN Backbone

MPLS-VPN Backbone

PE-1 Redistributes EIGRP In iBGP and Sets Extended Communities

VPNv4 BGP Udate With Extended Communities For EIGRP

EIGRP Route Originated With:

Route-Type = Internal Metric Components: Bandwidth Load, Delay Reliablility, MTU, Hop pe-1 5c"

CE-1 EIGRP AS-1

VPNv4 BGP Udate With Extended Communities For EIGRP

EIGRP AS-1

PE-2 and PE-3 Redistribute iBGP In EIGRP and Set EIGRP Characeristics According To the Extended Communities

EIGRP AS-1

On the right side, PE-2 and PE-3 redistribute the vpnv4 route from iBGP into EIGRP. However, the same route can be received as an EIGRP route from the other PE router in the same site. Nevertheless, the vpnv4 route that is learned from PE-1 is always preferred over the EIGRP route that is learned from the other PE in the same site. That is because the metric of the received routes is compared, and the lowest metric always wins. This is always the vpnv4 route from the remote PE router, if the cost of the EIGRP route is computed from reconstructing the metric components from the extended communities. This is why EIGRP does not need a down bit as OSPF does. The cost of traversing the MPLS VPN backbone is 0 for the EIGRP routes.

Configuration

Similarly to RIPv2, EIGRP has been extended with support for address families so that it can support MPLS VPN. Therefore, the VRF configuration on the PE routers for EIGRP is under address family IPv4 vrf. The regular EIGRP commands are available for each VRF that is configured. Because VPN customers usually use different EIGRP AS numbers (and the AS number has to match between EIGRP neighbors), the new EIGRP command autonomous-system as-number lets you specify the autonomous system number for the specified VRF. Example 7-30 shows the configuration of one PE router that is configured for two VRFs running EIGRP. Obviously, as with all other PE-CE routing protocols, you need to configure redistribution of BGP into EIGRP and vice versa.

Example 7-30 EIGRP VRF Configuration Example

router eigrp 1

!

address-family ipv4 vrf cust-two

redistribute static metric 64 2000

255 1 1500

redistribute bgp 1 metric 300 40001

255 1 1500

network 10.10.0.0 0.0.255.255

no auto-summary

autonomous-system 33

!

address-family ipv4 vrf cust-one

redistribute bgp 1 metric 300 40000

255 1 1500

network 10.0.0.0

no auto-summary

autonomous-system 42

!

The cost community in BGP is a nontransitive community that is passed to iBGP and confederation peers, but not beyond. It influences the BGP best path selection process by assigning cost values to specific routes. The cost community is set with the set extcommunity cost command in a route map. You can set a cost community ID (0-255) and a cost value (04,294,967,295). The cost community ID indicates the preference of this BGP path versus the others. The lower the cost ID, the more preferred it is.

The point of insertion (POI) is the place in the BGP best path selection process where BGP considers the cost community. The pre-bestpath POI indicates that BGP is to consider the cost community before any of the regular BGP comparisons steps in the well-known BGP best path selection process. You can configure a pre-bestpath cost community by configuring the cost community with the pre-bestpath keyword in a route map. The cost community is of the form Cost:POI:ID:value.

It is the cost community with pre-bestpath that is set when EIGRP is redistributed into BGP. Without the cost community for EIGRP on the PE router, the PE router always prefers the locally sourced BGP route above the route learned from a BGP peer. In the case of having a backdoor link between two EIGRP sites, this means that the backdoor link is the preferred path. With the cost community for EIGRP, the backdoor link and the path learned from iBGP through the MPLS VPN backbone are compared. The path with the lowest EIGRP cost is the preferred path. Cost community for EIGRP over MPLS VPN is turned on automatically in the case of EIGRP as the PE-CE routing protocol, so you do not need to configure it. The POI is pre-bestpath. The cost community ID is either 128 or 129: 128 for EIGRP internal routes and 129 for EIGRP external routes. Therefore, the EIGRP internal routes are always preferred over the EIGRP external routes. The value is the EIGRP composite metric value set on the PE router that redistributes the route into BGP. Routes that have a lower value are preferred over routes that have a greater value. If the cost community ID of the route and the value are the same, Cisco IOS prefers the EIGRP route over the BGP route on the PE router.

Example 7-31 shows the cost community that EIGRP uses in an MPLS VPN scenario. Two PE routers advertise the vpnv4 prefix 10.10.100.1/32, and each sets the cost community to an ID of 128 and a value that represents the composite EIGRP metric as seen by the sydney PE router. The sydney PE can choose the best path based on the cost community value that the PE routers advertise, ignoring the other BGP attributes.

Example 7-31 Cost Community for EIGRP over MPLS VPN sydney#show ip bgp vpnv4 all 10.10.100.1

BGP routing table entry for 1:1:10.10.100.1/32, version 1259 Paths: (2 available, best #2, table cust-one) Advertised to update-groups: 1

Local

10.200.254.2 (metric 3) from 10.200.254.2 (10.200.254.2)

Origin incomplete, metric 256384000, localpref 100, valid, internal Extended Community: RT:1:1

Cost:pre-bestpath:128:256384000 (default-1891099647) 0x8800:32768:0 0x8801:42:256128000 0x8802:65281:256000 0x8803:65281:1500, mpls labels in/out 16/16 Local

10.10.4.2 from 0.0.0.0 (10.200.254.5) Origin incomplete, metric 2323456, localpref 100, weight 32768, valid, sourced, best Extended Community: SoO:10:10 RT:1:1

Cost:pre-bestpath:128:2323456 (default-2145160191) 0x8800:32768:0 0x8801:42:665600 0x8802:65282:1657856 0x8803:65281:1500, mpls labels in/out 16/nolabel

EIGRP PE-CE with Backdoor Links

Backdoor links are supported between EIGRP sites that are connected to the MPLS VPN backbone. However, when a route disappears, routing can take longer to reconverge, which is typical in the case of redistribution between routing protocols. The cause of the longer convergence is redistribution between EIGRP and BGP. To help speed up the reconverging, you can use Site-of-Origin (SOO) for EIGRP. It can be defined on the PE routers on the VRF interfaces toward the CE routers and on the routers with a backdoor link. You need to configure ip vrf sitemap on the interface, setting the extended community SOO. This route map sets the SOO on the EIGRP route, either on the PE or on the backdoor link router. When the router receives a route across the interface with this route map configured and the SOO of the route matches the configured SOO, the router rejects the route. When the PE router receives a vpnv4 update with the SOO set, it extracts the SOO and adds it to the EIGRP route when it is reconstructed.

Figure 7-25 shows a network with a backdoor link between EIGRP sites and EIGRP SOO configured on the PE and backdoor routers.

Figure 7-25 Backdoor Link Between EIGRP Sites

Interface SerlalS/1 IP VRF Forwarding Cust-one IP VRF Sitemap SOO IP Address 10.10.2.2 255.255.255.0

Interface Serial5/1 IP VRF Forwarding Cust-one IP VRF Sitemap SOO IP Address 10.10.4.1 255.255.255.0

Route-map SOO Permit 10 Set Extcommunity SOO 10:11

Route-map SOO Permit 10 Set Extcommunity SOO 10:10

Interface SerlalS/1 IP VRF Forwarding Cust-one IP VRF Sitemap SOO IP Address 10.10.2.2 255.255.255.0

Route-map SOO Permit 10 Set Extcommunity SOO 10:11

CE-1

PE-1

MPLS-VPN Backbone

PE-2

MPLS-VPN Backbone

PE-2

CE-1

CE-2 Backdoor Router

Backdoor Router

CE-2 Backdoor Router

Backdoor Router

Backdoor Link

Backdoor Link

Interface FastEthernet1/1 IP VRF Sitemap SOO IP Address 10.10.90.2 255.255.255.0

Interface FastEthernet1/0 IP VRF Sitemap SOO IP Address 10.10.90.1 255.255.255.0

Route-map SOO Permit 10 Set Extcommunity SOO 10:11

Route-map SOO Permit 10 Set Extcommunity SOO 10:10

When no SOO for EIGRP is used anywhere, a count-to-infinity problem might exist across the EIGRP sites and across the MPLS VPN backbone. This means that when a route disappears, EIGRP routers see that the hop count slowly increases up to infinity. With EIGRP, infinity is a hop count of 100 by default. That means that it might take quite some time for the route to disappear, while in the meantime traffic is looped. You can lower the default maximum hop count of EIGRP by configuring the command metric maximum-hops hops. You must take care, however, not to configure this value too low. The value must be big enough for regular operation, but also in case the shortest path is unavailable and a longer path routes the traffic.

The disadvantage of using the SOO for EIGRP on the PE and backdoor routers is that one part of the site cannot reach the other part of the site across the backdoor link and the MPLS VPN backbone if the site is split. The backdoor router or the PE router blocks the route that is needed to get to the other part of the site. To work around this problem, you can configure the sitemap for SOO only on the PE routers and not the backdoor routers. The count-to-infinity problem does not occur in this case, but the routing might take a bit longer to reconverge. Example 7-32 shows the SOO for an EIGRP route.

Example 7-32 SOO Set for an EIGRP Route

PE-1#show ip eigrp vrf cust-one topology 10.10.100.3 255.255.255.255 IP-EIGRP (AS 42): Topology entry for 10.10.100.3/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856 Routing Descriptor Blocks:

10.200.254.5, from VPNv4 Sourced, Send flag is 0x0

Composite metric is (2297856/0), Route is Internal (VPNv4 Sourced) Vector metric:

Minimum bandwidth is 1544 Kbit Total delay is 25000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 Extended Community: SoO:10:10

Micro Expression Master

Micro Expression Master

If You Could Read Everyone Life A Book You Can Have Better Career, Great Relationships And Become Successful. This Book Is One Of The Most Valuable Resources In The World When It Comes To Reading the smallest and tiniest body Language and know what people are thinking about.

Get My Free Ebook


Post a comment