EIGRP FD Inaccessible PE/CE

I am finding an interesting behavior with EIGRP as the PE/CE routing protocol (another one!). Here is the topology:

 

image

 

The PEs in this picture are R2, R4, R5 and XR1. They are all PEs for the same VPN (A) and they are all importing/exporting the same RT. 

EIGRP is the PE/CE routing protocol everywhere, exept for between PE R2 and CE R1, where eBGP is used instead. 

Different EIGRP AS numbers are used for each section of the VPN (One side uses AS 19 and the other uses AS 12).

 

The interesting behavior that I'm seeing is that once that I do mutual redistribution on R4/R5, the routes appear as BGP on R2/XR1 as expected. XR1 and R2 receive the VPNv4 update with all of the EIGRP specific communites. I will not do redistribution on XR1 to observe the behavior. Once R2 receives the VPNV4 update, it passes the routes to R1 via BGP (no need to redistribute). R1 receives the routes via BGP but they now don't carry any of the EIGRP communities since from R1's perspective this is a regular eBGP peering. R1 then redistributes the routes into EIGRP. 

What would be the expected behavior to see on XR1? I was expecting for the EIGRP update to come in from XR2 and and win over the VPNv4 update that XR1 received from R4/R5. That is not the case...in fact, this is what XR1 sees in the topology table for R10's loopback:

 

XR1#show ip eigrp vrf A topology 192.168.1.10/32

EIGRP-IPv4 Topology Entry for AS(12)/ID(192.168.1.19) VRF(A)

EIGRP-IPv4(12): Topology base(0) entry for 192.168.1.10/32

  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295

  Descriptor Blocks:

  10.19.20.20 (Ethernet1/1), from 10.19.20.20, Send flag is 0x0

      Composite metric is (332800/307200), route is External

      Vector metric:

        Minimum bandwidth is 10000 Kbit

        Total delay is 3000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 2

        Originating router is 192.168.101.1

      External data:

        AS number of route is 201

        External protocol is BGP, external metric is 0

        Administrator tag is 100 (0x00000064)

 

This is the VPNv4 update:

 

XR1#show bgp vpnv4 unicast all 192.168.1.10/32

BGP routing table entry for 10:10:192.168.1.10/32, version 57

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

  Not advertised to any peer

  Local

    5.5.5.5 (metric 21) from 3.3.3.3 (3.3.3.3)

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

      Extended Community: RT:10:10 Cost:pre-bestpath:128:409600 

        0x8800:32768:0 0x8801:19:153600 0x8802:65281:256000 0x8803:65281:1500 

        0x8806:0:3232238090

      Originator: 5.5.5.5, Cluster list: 3.3.3.3

      mpls labels in/out nolabel/5024

 

So what is happening here? XR1 is preferring the BGP VPNv4 update over the EIGRP update. And it's marking the FD of the EIGRP update with an infinite FD!

Even though XR1 does not participate in EIGRP AS19 (its part of EIGRP AS12), the VPNv4 update that it receives from R4/R5 is an "internal" update. Where as the EIGRP route that XR1 gets via EIGRP is an "external" EIGRP route (R2 redistributed it from native BGP into EIGRP). 

So, just because the two sides of the VPN are on different EIGRP AS numbers, does not mean that update sent from one side to the other will be considered "external"...the communities attached to the VPNv4 route are what dictates this. 

If R10 were to redistribute a connected loopback (so that it would be exteral inside of AS19) then it would get to XR1 with the "external" community attributes:

R10 redistributes this prefix: 192.168.10.10/32

 

XR1#show bgp vpnv4 unicast all 192.168.10.10/32

BGP routing table entry for 10:10:192.168.10.10/32, version 60

Paths: (1 available, best #1, table A, RIB-failure(17) - next-hop mismatch)

  Not advertised to any peer

  Local

    5.5.5.5 (metric 21) from 3.3.3.3 (3.3.3.3)

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

      Extended Community: RT:10:10 Cost:pre-bestpath:129:409600 0x8800:0:0 

        0x8801:19:153600 0x8802:65281:256000 0x8803:65281:1500 

        0x8804:0:3232238090 0x8805:11:0 0x8806:0:3232238090

      Originator: 5.5.5.5, Cluster list: 3.3.3.3

      mpls labels in/out nolabel/5025

 

 

XR1#show ip eigrp vrf A topology  192.168.10.10/32

EIGRP-IPv4 Topology Entry for AS(12)/ID(192.168.1.19) VRF(A)

EIGRP-IPv4(12): Topology base(0) entry for 192.168.10.10/32

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 332800

  Descriptor Blocks:

  10.19.20.20 (Ethernet1/1), from 10.19.20.20, Send flag is 0x0

      Composite metric is (332800/307200), route is External

      Vector metric:

        Minimum bandwidth is 10000 Kbit

        Total delay is 3000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 2

        Originating router is 192.168.101.1

      External data:

        AS number of route is 201

        External protocol is BGP, external metric is 0

        Administrator tag is 100 (0x00000064)

 

Comments

  • Nice post,

    however wanted to tell you that the FD to infinite is not an unexpected behaviour. In fact i did see the same for OSPF a few days ago. It is like when we set the max-metric value by issuing the right command. This makes possible not to advertise a determined network/prefix on a determined domain. 

    However i will reproduce your topology asap because i am curious to see again (and better understand) this control plane behaviour myself !

    Much to do there [8-|]

    Thanks

    Alessio

     

  • However i will reproduce your topology asap because i am curious to see again (and better understand) this control plane behaviour myself !

    I can send you the .net file along with the configs if you need it. 

Sign In or Register to comment.