EIGRP and not needing the Down Bit with Dual Homed CEs - does it work?

I'm going through MPLS Fundamentals and labbing concepts to help learn them. Page 222 has an example of a CE advertising a route to a PE which then advertises it to two other PE that are dual homed to a CE. EIGRP is the PE-CE protocol.

The point made is that because BGP propagates the EIGRP metric values in the BGP metric the PEs will compare the metric of an EIGRP route learnt from the CE to the metric in the BGP route for the same route. Both PEs will thus prefer the iBGP route (AD 200) over the CE's EIGRP route (AD 170 or 90).

However, I'm not seeing this behaviour. What I'm seeing is that the PE is preferring the CE's eigrp route because it is installed in the route table a EIGRP and then redistributed into BGP, setting the weight to 32768, and BGP likes this path best, not the iBGP route.

Once I removed redistribution from EIGRP to BGP on the offending PE, the problem stops and the PE does prefer the iBGP route (AD 200) over the EIGRP route (AD 90 in this case). If I put the redistribution back on then the problem recurs.

 

Here is my lab setup and some output showing the behaviour.

 

R2 is the PE advertising R9's (CE loopback) address 9.9.9.9/32 to R1 and R4 PEs (via R3 route-reflector). R7 is dual homed to R1 and R4 via EIGRP. Mutual redistribution between BGP ipv4 vrf ONE and eigrp ipv4 vfr ONE is configured on all PEs. All RD's and RT's are 1:1.

 

R4 knows 9.9.9.9 (R9's loopback) via iBGP. This is redistributed into EIGRP and advertised to R7.


Rack1R4#sh ip route vrf ONE 9.9.9.9

Routing entry for 9.9.9.9/32

  Known via "bgp 1", distance 200, metric 146432, type internal

  Redistributing via eigrp 1

  Advertised by eigrp 1 metric 1 1 1 1 1

  Last update from 150.1.2.2 00:35:08 ago

  Routing Descriptor Blocks:

  * 150.1.2.2 (Default-IP-Routing-Table), from 150.1.3.3, 00:35:08 ago

      Route metric is 146432, traffic share count is 1

      AS Hops 0

 


Rack1R7#sh ip route 

     9.0.0.0/32 is subnetted, 1 subnets

D       9.9.9.9 [90/158208] via 1.1.47.4, 00:21:41, FastEthernet1/4 <- R4

 

R7 advertises this to R1.

 

R1 is supposed to check the EIGRP metric and compare this against the metric in the iBGP route from R2 according to the book, stopping R1 from redistributing it back to BGP and negating the need for EIGRP to have a down bit like OSPF and IS-IS.

 

However, R1 is installing the EIGRP route because it likes the locally originated BGP route with a weight of 32768 before it compares metrics.

 


Rack1R1#sh ip bgp vpnv4 all 9.9.9.9 

BGP routing table entry for 1:1:9.9.9.9/32, version 8219

Paths: (2 available, best #1, table ONE)

  Advertised to update-groups:

     1         

  Local

    1.1.17.7 from 0.0.0.0 (150.1.1.1)

      Origin incomplete, metric 160768, localpref 100, weight 32768, valid, sourced, best

      Extended Community: RT:1:1 0x8800:32768:0 0x8801:1:135168 

        0x8802:65283:25600 0x8803:65281:1500,

      mpls labels in/out 26/nolabel

  Local

    150.1.2.2 (metric 2) from 150.1.3.3 (150.1.3.3)

      Origin incomplete, metric 146432, localpref 100, valid, internal

      Extended Community: RT:1:1 0x8800:32768:0 0x8801:1:130048 

        0x8802:65281:16384 0x8803:65281:1514

      Originator: 150.1.2.2, Cluster list: 150.1.3.3,

      mpls labels in/out 26/20

 


Rack1R1#sh ip route vrf ONE

     9.0.0.0/32 is subnetted, 1 subnets

D       9.9.9.9 [90/160768] via 1.1.17.7, 00:05:27, FastEthernet0/0.2

 

R1 is supposed to prefer the iBGP route from R2 according to the book, but it just isn't doing this. It advertises this redistributed route back to R3.

 


Rack1R1#sh ip bgp vpnv4 all neighbors 150.1.3.3 advertised-routes        

BGP table version is 8230, local router ID is 150.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

 

   Network          Next Hop            Metric LocPrf Weight Path

Route Distinguisher: 1:1 (default for vrf ONE)

*> 9.9.9.9/32       1.1.17.7            160768         32768 ?

...

 

The behaviour described in the book only seems to happen when R1 does not redistribute EIGRP back to BGP. The it does install the iBGP route over the EIGRP route. This isn't desirable though, because R7 no longer has the benefit of dual homing, R1 doesn't advertise any of it's routes via MP-BGP.

 

Am I doing something weird? Should the PE's always prefer the iBGP vpnv4 route over the EIGRP route when dual homed like this? That makes sense as it stops potential looping like the down bit does, but it isn't doing it in my lab.

 

Comments

  • It seems something strange is happening when I take off EIGRP to BGP redistribution on R1. Debug shows the route going active constantly.

    Something funky is happening... no idea what it is yet.

  • I reloaded all my routers. Now it works, (sort of, but not because of what the book says). R1 and R4 both have the route as iBGP and are advertising it to R7. Thing is, R7 doesn't advertise it back to either of them due to split horizon, so R1 and R4 never see the EIGRP route to do the comparison on. I bet if I kill BGP on R1 and let it learn the EIGRP route, when it comes back EIGRP will win and it will be redistributing this into BGP. Yep, now R2 prefers the EIGRP route and redistributes this back to BGP.

     

    The next section is about the cost community, stating that it can be compared before the weight or any other BGP best path checks. This sounds like what I need, but my routes are not getting a pre-bestpath cost assigned as shown in the book.

     

    Edit: I manually created a route-map setting the cost community pre-bestpath to 1:1. Now R1 and R4 will always prefer the iBGP route. Is it because the routers are not automatically assigning this cost community as it says they do with EIGRP to BGP redistribution? I'm confused.

     


    Rack1R1#sh ip bgp vpnv4 all 9.9.9.9

    BGP routing table entry for 1:1:9.9.9.9/32, version 747

    Paths: (1 available, best #1, table ONE)

    Flag: 0x820

      Not advertised to any peer

      Local

        150.1.2.2 (metric 2) from 150.1.2.2 (150.1.2.2)

          Origin incomplete, metric 146432, localpref 100, valid, internal, best

          Extended Community: RT:1:1 Cost:pre-bestpath:1:1 0x8800:32768:0 

            0x8801:1:130048 0x8802:65281:16384 0x8803:65281:1514,

          mpls labels in/out nolabel/23

     


    Rack1R2# sh ip bgp  vpnv4 all 9.9.9.9

    BGP routing table entry for 1:1:9.9.9.9/32, version 75

    Paths: (1 available, best #1, table ONE)

    Multipath: iBGP

      Advertised to update-groups:

         1         

      Local

        1.1.209.9 from 0.0.0.0 (150.1.2.2)

          Origin incomplete, metric 146432, localpref 100, weight 32768, valid, sourced, best

          Extended Community: RT:1:1 Cost:pre-bestpath:1:1 0x8800:32768:0 

            0x8801:1:130048 0x8802:65281:16384 0x8803:65281:1514,

          mpls labels in/out 23/nolabel

  • The book MPLS Configuration on Cisco IOS Software has a much better explanation of this feature than MPLS Fundamentals does.

    What happens is, during redistribution of EIGRP to BGP a community is set, the cost community with the value of 128:EIGRP_Metric for internal routes and 129:EIGRP_Metric for external routes. It is inserted with a pre-bestpath POI, which means BGP considers the cost community before any of the regular best path selection checks.

    Furthermore, it will skip the usual rules of comparing administrative distance between routing protocols and directly compare the EIGRP route's cost and the MP-iBGP route's cost community value to determine which route is best. This makes sense because admin distance is only compared because the cost values of different routing protocols are not able to be directly compared (RIP hop count makes no sense to OSPF for example). With the EIGRP cost carried in an extended community we can directly compare two EIGRP costs.

    This should mean that in my scenario both PE's prefer the MP-iBGP route. However, 9.9.9.9 is not getting this cost community added to the route. I'm thinking the IOS is a bit old, as this didn't become default until 12.2(25)S on the 7200 platform, which is the code we are running, but which sub-release did it get added at? I've tried 12.2(25)S9 and 12.2(25)S15, neither add the cost community.

    When I look at another route redistributed from EIGRP to BGP on the 3640's running 12.4(12), the cost community is right there as documented.

     


    Rack1R4#sh ip bgp vpnv4 all 7.7.7.7

    BGP routing table entry for 1:1:7.7.7.7/32, version 8

    Paths: (1 available, best #1, table ONE)

      Advertised to update-groups:

         1         

      Local

        1.1.47.7 from 0.0.0.0 (150.1.4.4)

          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:1:153600 0x8802:65281:256000 0x8803:65281:1500

          mpls labels in/out 23/nolabel

     

    So the answer is, the IOS on the 7200's do not support this feature as documented.

    Does anyone know what code will support it on the 7200's? I might have a look at the feature navigator.

  • I've tried 12.2(25)S9 and 12.2(25)S15, both of which do not attach the cost community when redistributing vrf EIGRP to BGP.

    The feature navigator says it is supported. Am I doing something wrong?

Sign In or Register to comment.