EIGRP SOO (same or different value) with backdoor link

Hello,

working with SOO I tried to understund how it work on three different schenarios with dual CE multihomed/backdoor link:

 

- SAME SOO value only on PE: 

          1) no MPLS link are allowed for backup or transit for reachability of internal CE network between CE. De by PE filtering

          2) the external/remote networks reachability work fine using both path (backup or MPLS)

 

 

- DIFFERENT SOO value only on PE

          1)  MPLS link are allowed for backup or transit for reachability of internal CE network between CE. (No filtering by PE)

          2) the external/remote network reachability work fine using both path (backup or MPLS)

          3) the route are discarded on the same PE that set the SOO (when thr route come back from CE)

 

- DIFFERENT SOO value on PE/CE

          1)  MPLS link are allowed for backup or transit for reachability of internal CE network between CE.

          2) the external/remote network reachability work fine using both path (backup or MPLS)

          3) the route are discarded on the CE

 

Any comment about this ?

 

Thanks

Isacco

Comments

  • SOO is a legacy EIGRP loop-prevention feature with it's goal being to prevent routing loops when using EIGRP as the PE-CE routing protocol.

     

    In IOS pre 12.0(24)S codes you would use the same soo value inbound on both PE routers facing the CEs to prevent the same routes re-entering back into the CE site in a dual-homed scenario.

     

    From IOS 12.0(24)S the BGP Cost Community Support for EIGRP MPLS VPN PE-CE with Backdoor Links was introduced which prevents 1.routing loops and 2.the race condition this is out of the box leaving you with nothing to do apart from understand the theory image

     

    Once you do mutual redistribution between EIGRP and BGP then a POI (point of insertion) is applied automatically to EIGRP routes that are redistributed into BGP. The "pre-best path" POI carries the EIGRP route type and metric. This POI influences the best path calculation process by influencing BGP to consider this POI before any other comparison step i.e so no WEIGHT, LP, MED, AS_PATH comparison is done but POI is considered first, this is to depict a true end-to-end Intra-AS EIGRP network in an MPLS VPN backbone.

     

    Cisco says:

     

    "The BGP Cost Community feature introduces the cost extended community attribute. The cost community is a non-transitive extended community attribute that is passed to internal BGP (iBGP) and confederation peers but not to external BGP (eBGP) peers. The cost community feature allows you to customize the local route preference and influence the best path selection process by assigning cost values to specific routes."

     

     

    So if you're asked this question both IOS and IOS-XR support BGP cost community out of the box

     

    It is disabled with...

     

    IOS-XR

    "

    To configure a router that is running the Border Gateway Protocol (BGP) to not evaluate the cost community attribute during the best-path selection process, use the bgp bestpath cost-community ignore command in an appropriate configuration mode. To restore the system to its default condition, use the no form of this command.

     

    bgp bestpath cost-community ignore

    no bgp bestpath cost-community ignore

    "

     

    IOS

    "

    bgp bestpath cost-community ignore

    no bgp bestpath cost-community ignore

    "

     

    Now if the scenario is not using the BGP cost community i.e it's disabled and you cannot re-enable it and you are asked to prevent loops then here you can use the same EIGRP SOO value on the PE routers in a dual-homed MPLS VPN.

     

    Once SoO is set, it is automatically converted from an EIGRP TLV to be carried in a BGP ext community.

    The same soo values matching the soo that was set will not be candidates for redistribution back into EIGRP.

     

    For redundancy purposes using the default bgp cost community in IOS and XR will provide this out of the box.

     

    Happy labbing!


    On Thu, Sep 25, 2014 at 4:41 PM, isacco <[email protected]> wrote:

    Hello,

    working with SOO I tried to understund how it work on three different schenarios with dual CE multihomed/backdoor link:

     

    - SAME SOO value only on PE: 

              1) no MPLS link are allowed for backup or transit for reachability of internal CE network between CE. De by PE filtering

              2) the external/remote networks reachability work fine using both path (backup or MPLS)

     

     

    - DIFFERENT SOO value only on PE

              1)  MPLS link are allowed for backup or transit for reachability of internal CE network between CE. (No filtering by PE)

              2) the external/remote network reachability work fine using both path (backup or MPLS)

              3) the route are discarded on the same PE that set the SOO (when thr route come back from CE)

     

    - DIFFERENT SOO value on PE/CE

              1)  MPLS link are allowed for backup or transit for reachability of internal CE network between CE.

              2) the external/remote network reachability work fine using both path (backup or MPLS)

              3) the route are discarded on the CE

     

    Any comment about this ?

     

    Thanks

    Isacco




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • JoeMJoeM ✭✭✭

    Hi Sukhji,

    If you have time, can you take a look at this other thread about cost community.  

    IEOC Thread:  RIB-failure using BGP cost community in MPLS VPN

    There is some confusion about how cost community works when comparing BGP vpnv4 imported routes (using cost community) vs matching EIGRP routes.  I do not understand this well enough, to verify or test it.  The BGP routes shows up with an AD of 200.  Of course, an EIGRP route (CE->PE) trumps this with an AD of 90.

    In my last post of this thread, I linked a GNS3 setup with the imported configs for the scenario.

     

    If you have time, thanks. I like your last explanation here.   ;-)


  • Hi Joe

    Ok so a few observations firstly....this maybe down to your own testing ;)

    1.the same 11.1.1.1/32 is present in CE1 as with CE2
    2.delay value facing CE2 configured on P2
    3.setting the metric to 10 in the EIGRP>BGP statement on the P's ensures the metric is overridden to 10 in the VPNv4 update but ultimately achieves nothing as it's the POI 128 which is the FD value which is transferred back to EIGRP on the other side (it's still carried in the extended cost community), so metric is not required and does not achieve anything, remember POI 128 means we consider the POI cost i.e the FD inserted metric over BGP best path selection


    I would start by removing the above and keeping it a tad more simple, admittedly this is a complex subject

    so once everything is removed and you have simply (on the P's)

    address-family ipv4 vrf test
      redistribute eigrp 50
     exit-address-family


    then you will see things work out for the best i.e the P routers for any of the opposite CE loopbacks will route over VPNv4 BGP and MPLS core as the POI 128 cost i.e the FD will be lower vs the CE facing FD value (ultimately two link costs min bandwidth + culmative delay P2-CE2-lo0 vs three P1-CE1-CE2-lo0, the MPLS core is transparent where no costs are added)

    good point to remember is think of this behaviour as a true distance vector EIGRP topology hence you still have FC and a loop free topology.

    It's always good to check with "show ip eigrp vrf test topology 11.1.1.1/32" to see the FD/AD values first hand

    finally the point on the using a lower community ID of 1 is lost when trying to advertise this over VPNv4 BGP as you have on P2 and will be ignored, this needs to be influenced on P1 IF you want P1 to prefer CE1 for 11.1.1.1/32 in a twisted path selection scenario....remember by default the VPNv4 path is preferred

    so if you do this P1 will have Cost:pre-bestpath:1:9999 to trump the VPNv4 received cost value of Cost:pre-bestpath:128:156160 **Note here when you check the eigrp topology table it will show the higher FD 158720 facing the CE router as the best path, it means the locally configured Cost:pre-bestpath:1:9999 ensures you ignore the VPNv4 received Cost:pre-bestpath:128:156160 for path selection....also the POI 128 will still be configured in the locally redistributed EIGRP>BGP cost community behind the POI 1 and advertised to P2 and will be used should the P2-CE2 link fail...

    For background the RFC for this behaviour is still draft:


    main points to consider is Cisco implemented POI's 128 and 129 (not tried 129 but feel free and update this thread ;))

    POI = 128, use Cost Community before anything else
    POI = 129, use Cost Community after the IGP cost to next-hop has been compared
    POI = 130, use Cost Community after the paths advertised by BGP speakers in a neighboring autonomous system (if any) have been selected
    POI = 131, use Cost Community after BGP IDs have been compared

    and the main bits of extended cost community to consider when you're wondering what the values mean are as follows:

    0×8800 = Route Flag and Tag
    0×8801 = AS Number and Delay
    0×8802 = Reliability, Next Hop, and Bandwidth
    0×8803 = Reserve, Load and MTU
    0×8804 = (for external routes) Remote AS Number and Remote ID
    0×8805 = (for external routes) Remote Protocol and Remote Metric
    The MP-BGP cloud is interpreted as a metric zero (0)

    so 0×8804 is important to distinguish between D and D EX

    HTH




    On Thu, Sep 25, 2014 at 8:44 PM, JoeM <[email protected]> wrote:

    Hi Sukhji,

    If you have time, can you take a look at this other thread about cost community.  

    IEOC Thread:  RIB-failure using BGP cost community in MPLS VPN

    There is some confusion about how cost community works when comparing BGP vpnv4 imported routes (using cost community) vs matching EIGRP routes.  I do not understand this well enough, to verify or test it.  The BGP routes shows up with an AD of 200.  Of course, an EIGRP route (CE->PE) trumps this with an AD of 90.

    In my last post of this thread, I linked a GNS3 setup with the imported configs for the scenario.

     

    If you have time, thanks. I like your last explanation here.   ;-)




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Hi,

     

    I've decided to reproduce it. Here is my topology:

    image

    By default XR1 routes to 20.20.20.20 via R2. I would like to change it by means of cost community.

     

    RP/0/0/CPU0:XR1#show bgp vpnv4 unicast rd 1:1 20.20.20.20/32

    BGP routing table entry for 20.20.20.20/32, Route Distinguisher: 1:1

    Versions:

      Process           bRIB/RIB  SendTblVer

      Speaker                193         193

    Last Modified: Oct  1 17:16:08.180 for 00:00:18

    Paths: (1 available, best #1)

      Not advertised to any peer

      Path #1: Received by speaker 0

      Not advertised to any peer

      Local

        2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)

          Received Label 22

          Origin incomplete, metric 512, localpref 100, valid, internal, best, group-best, import-candidate, imported, import suspect

          Received Path ID 0, Local Path ID 1, version 193

          Extended community: COST:128:128:512 EIGRP route-info:0x8000:0 EIGRP AD:1:512 EIGRP RHB:255:1:256000 EIGRP LM:0xff:1:1500 0x8806:0x00:0x00:0x14:0x14:0x14:0x14 RT:1:1 

          Source VRF: A, Source Route Distinguisher: 1:1

     

    RP/0/0/CPU0:XR1#show eigrp vrf all topology all-links 

     

    IPv4-EIGRP Topology Table for AS(1)/ID(19.19.19.19) VRF: A

     

    Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

           r - reply Status, s - sia Status 

     

    P 1.1.1.1/32, 1 successors, FD is 512, RIB is 512, serno 90

            via 10.0.119.1 (512/256), GigabitEthernet0/0/0/0.100

    P 10.0.119.0/24, 1 successors, FD is 256, RIB is 256, serno 72

            via Connected, GigabitEthernet0/0/0/0.100

    P 10.0.120.0/24, 1 successors, FD is 512, RIB is 512, serno 91

            via 10.0.119.1 (512/256), GigabitEthernet0/0/0/0.100

    P 10.0.220.0/24, 1 successors, FD is 256, RIB is 256, serno 98

            via VPNv4 Sourced (256/0)

    P 20.20.20.20/32, 1 successors, FD is 512, RIB is 512, serno 99

            via VPNv4 Sourced (512/0)

            via 10.0.119.1 (768/512), GigabitEthernet0/0/0/0.100

     

    RP/0/0/CPU0:XR1#show route vrf A 

     

    Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

           E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

           i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

           ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

           U - per-user static route, o - ODR, L - local, G  - DAGR

           A - access/subscriber, a - Application route, (!) - FRR Backup path

     

    Gateway of last resort is not set

     

    D    1.1.1.1/32 [90/512] via 10.0.119.1, 00:53:02, GigabitEthernet0/0/0/0.100

    C    10.0.119.0/24 is directly connected, 22:09:50, GigabitEthernet0/0/0/0.100

    L    10.0.119.19/32 is directly connected, 22:09:50, GigabitEthernet0/0/0/0.100

    D    10.0.120.0/24 [90/512] via 10.0.119.1, 00:53:02, GigabitEthernet0/0/0/0.100

    B    10.0.220.0/24 [200/0] via 2.2.2.2 (nexthop in vrf default), 00:01:03

    B    20.20.20.20/32 [200/512] via 2.2.2.2 (nexthop in vrf default), 00:01:03

    As I understand: EIGRP is installing 20.20.20.20/32 in its toplogy with the FD of 512 based on Cost community it is receiving from R2. However when I change this cost community on R2 in order to influence this I am getting the same result: XR1 is still prefring to reach 20.20.20.20/32 over 2.2.2.2:

     

    BGP routing table entry for 20.20.20.20/32, Route Distinguisher: 1:1

    Versions:

      Process           bRIB/RIB  SendTblVer

      Speaker                197         197

    Last Modified: Oct  1 17:20:43.180 for 00:00:03

    Paths: (1 available, best #1)

      Not advertised to any peer

      Path #1: Received by speaker 0

      Not advertised to any peer

      Local

        2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)

          Received Label 22

          Origin incomplete, metric 512, localpref 100, valid, internal, best, group-best, import-candidate, imported

          Received Path ID 0, Local Path ID 1, version 197

          Extended community: COST:128:128:99999 EIGRP route-info:0x8000:0 EIGRP AD:1:512 EIGRP RHB:255:1:256000 EIGRP LM:0xff:1:1500 0x8806:0x00:0x00:0x14:0x14:0x14:0x14 RT:1:1 

          Source VRF: A, Source Route Distinguisher: 1:1

    RP/0/0/CPU0:XR1#show eigrp vrf all topology all-links       

     

    IPv4-EIGRP Topology Table for AS(1)/ID(19.19.19.19) VRF: A

     

    Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

           r - reply Status, s - sia Status 

     

    P 1.1.1.1/32, 1 successors, FD is 512, RIB is 512, serno 90

            via 10.0.119.1 (512/256), GigabitEthernet0/0/0/0.100

    P 10.0.119.0/24, 1 successors, FD is 256, RIB is 256, serno 72

            via Connected, GigabitEthernet0/0/0/0.100

    P 10.0.120.0/24, 1 successors, FD is 512, RIB is 512, serno 91

            via 10.0.119.1 (512/256), GigabitEthernet0/0/0/0.100

    P 10.0.220.0/24, 1 successors, FD is 768, RIB is 768, serno 101

            via 10.0.119.1 (768/512), GigabitEthernet0/0/0/0.100

    P 20.20.20.20/32, 1 successors, FD is 512, RIB is 512, serno 99

            via VPNv4 Sourced (512/0)

            via 10.0.119.1 (768/512), GigabitEthernet0/0/0/0.100

     

    RP/0/0/CPU0:XR1#show route vrf A            

     

    Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

           E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

           i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

           ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

           U - per-user static route, o - ODR, L - local, G  - DAGR

           A - access/subscriber, a - Application route, (!) - FRR Backup path

     

    Gateway of last resort is not set

     

    D    1.1.1.1/32 [90/512] via 10.0.119.1, 00:57:46, GigabitEthernet0/0/0/0.100

    C    10.0.119.0/24 is directly connected, 22:14:34, GigabitEthernet0/0/0/0.100

    L    10.0.119.19/32 is directly connected, 22:14:34, GigabitEthernet0/0/0/0.100

    D    10.0.120.0/24 [90/512] via 10.0.119.1, 00:57:46, GigabitEthernet0/0/0/0.100

    D    10.0.220.0/24 [90/768] via 10.0.119.1, 00:02:47, GigabitEthernet0/0/0/0.100

    B    20.20.20.20/32 [200/512] via 2.2.2.2 (nexthop in vrf default), 00:01:12

     

    Is it the correct way to influence path selection over MPLS core? If we could influence FD of VPNv4 route that is being imported into EIGRP, I guess it would be possibe to influence this. But Cost community is not helping to acheive this. 

     

    Here are my configs:

     

    ####R1####

     

    hostname R1

    !

    i!

    interface Loopback0

     ip address 1.1.1.1 255.255.255.255

     delay 1

    !

    interface FastEthernet0/0

     no ip address

     shutdown

     duplex full

    !

    interface Ethernet1/0

     ip address 10.0.119.1 255.255.255.0

     delay 1

     duplex full

    !

    interface Ethernet1/1

     ip address 10.0.120.1 255.255.255.0

     delay 1

     duplex full

    !

    interface Ethernet1/2

     no ip address

     shutdown

     duplex full

    !

    interface Ethernet1/3

     no ip address

     shutdown

     duplex full

    !

    !

    router eigrp 1

     metric weights 0 0 0 1 0 0

     network 0.0.0.0

     

    ####R2####

     

    hostname R2

    !

    boot-start-marker

    boot-end-marker

    !

    !

    vrf definition A

     rd 1:1

     route-target export 1:1

     route-target import 1:1

     !

     address-family ipv4

     exit-address-family

    !

    !         

    interface Loopback0

     ip address 2.2.2.2 255.255.255.255

    !

    interface Ethernet1/0

     ip address 10.0.219.2 255.255.255.0

     ip ospf authentication message-digest

     ip ospf message-digest-key 1 md5 cisco

     ip ospf network point-to-point

     duplex full

    !

    interface Ethernet1/1

     vrf forwarding A

     ip address 10.0.220.2 255.255.255.0

     delay 1

     duplex full

    !

    interface Ethernet1/2

     no ip address

     shutdown

     duplex full

    !

    interface Ethernet1/3

     no ip address

     shutdown

     duplex full

    !

    !

    router eigrp 1

     !

     address-family ipv4 vrf A 

      redistribute bgp 1 metric 2 2 2 3 3

      network 0.0.0.0

      metric weights 0 0 0 1 0 0

      autonomous-system 1

     exit-address-family

    !

    router ospf 1

     router-id 2.2.2.2

     network 0.0.0.0 255.255.255.255 area 0

     mpls ldp autoconfig

    !

    router bgp 1

     bgp log-neighbor-changes

     no bgp default ipv4-unicast

     neighbor 19.19.19.19 remote-as 1

     neighbor 19.19.19.19 update-source Loopback0

     !

     address-family ipv4

     exit-address-family

     !

     address-family vpnv4

      neighbor 19.19.19.19 activate

      neighbor 19.19.19.19 send-community both

      neighbor 19.19.19.19 route-map R20 out

     exit-address-family

     !

     address-family ipv4 vrf A

      redistribute eigrp 1

     exit-address-family

    !

    ip forward-protocol nd

    !

    !

    no ip http server

    no ip http secure-server

    !

    !

    ip prefix-list R20 seq 5 permit 20.20.20.20/32

    !

    route-map COST permit 10

     match ip address prefix-list 20

    !

    route-map R20 permit 10

     match ip address prefix-list R20

     set extcommunity cost pre-bestpath 128 99999

     

     

    #####XR1#####

     

    hostname XR1

    cdp

    vrf A

     address-family ipv4 unicast

      import route-target

       1:1

      !

      export route-target

       1:1

      !

     !

    !

    vrf Management

    !

    line template TELNET

     exec-timeout 0 0

    !

    line console

     exec-timeout 0 0

    !

    line default

     exec-timeout 0 0

    !

    vty-pool default 0 99 line-template TELNET

    ipv4 access-list R20

     10 permit ipv4 host 20.20.20.20 any

    !

    interface Loopback0

     ipv4 address 19.19.19.19 255.255.255.255

    !

    interface MgmtEth0/0/CPU0/0

     vrf Management

     ipv4 address 172.16.33.206 255.255.255.0

    !

    interface GigabitEthernet0/0/0/0

     cdp

    !

    interface GigabitEthernet0/0/0/0.100

     vrf A

     ipv4 address 10.0.119.19 255.255.255.0

     encapsulation dot1q 100

    !

    interface GigabitEthernet0/0/0/0.101

     ipv4 address 10.0.219.19 255.255.255.0

     encapsulation dot1q 101

    !

    route-policy R1

      if destination in (1.1.1.1/32) then

        set extcommunity cost (Pre-Bestpath:128:300000)

      else

        pass

      endif

    end-policy

    !

    router static

     vrf Management

      address-family ipv4 unicast

       0.0.0.0/0 172.16.33.254

      !

     !

    !

    router ospf 1

     mpls ldp auto-config

     area 0

      interface Loopback0

       passive enable

      !

      interface GigabitEthernet0/0/0/0.101

       authentication message-digest

       message-digest-key 1 md5 encrypted 02050D480809

       network point-to-point

      !

     !

    !

    router bgp 1

     address-family vpnv4 unicast

     !

     neighbor 2.2.2.2

      remote-as 1

      update-source Loopback0

      address-family vpnv4 unicast

       route-policy R1 out

      !

     !

     vrf A

      rd 1:1

      address-family ipv4 unicast

       redistribute eigrp 1

      !

     !

    !

    mpls ldp

     router-id 19.19.19.19

    !

    router msdp

     peer 9.9.0.15

     !

    !

    router eigrp 1

     vrf A

      address-family ipv4

       metric weights 0 0 0 1 0 0

       metric rib-scale 1

       metric version 32bit

       router-id 19.19.19.19

       default-metric 2 2 2 2 2

       autonomous-system 1

       redistribute bgp 1

       interface GigabitEthernet0/0/0/0.100

        metric delay 1

       !

      !

     !

    !

    end

     

    #####XR2#####

     

    hostname XR2

    telnet vrf default ipv4 server max-servers 10

    telnet vrf Management ipv4 server max-servers 10

    cdp

    vrf Management

    !

    line console

     exec-timeout 0 0

    !

    line default

     exec-timeout 0 0

    !

    vty-pool default 0 99 line-template TELNET

    interface Loopback0

     ipv4 address 20.20.20.20 255.255.255.255

     ipv6 address 2001::7/128

    !

    interface MgmtEth0/0/CPU0/0

     vrf Management

     ipv4 address 172.16.33.161 255.255.255.0

    !

    interface GigabitEthernet0/0/0/0

     cdp

    !

    interface GigabitEthernet0/0/0/0.102

     ipv4 address 10.0.220.20 255.255.255.0

     encapsulation dot1q 102

    !

    interface GigabitEthernet0/0/0/0.103

     ipv4 address 10.0.120.20 255.255.255.0

     encapsulation dot1q 103

    !

    router static

     vrf Management

      address-family ipv4 unicast

       0.0.0.0/0 172.16.33.254

      !

     !

    !

    router eigrp 1

     address-family ipv4

      metric weights 0 0 0 1 0 0

      metric rib-scale 1

      metric version 32bit

      interface Loopback0

       metric delay 1

      !

      interface GigabitEthernet0/0/0/0.102

       metric delay 1

      !

      interface GigabitEthernet0/0/0/0.103

       metric delay 1

      !

     !

    !

    end




  • Hello,
    relating use of cost I'm experiencing a probem:

    If I try to change the cost on PE during the redistribution EIGRP-TO-BGP the choice is the same: the ext routes from other PE come back from EIGRP Why ? I have to clear the neig to resolve the problem... Any comments ?

    I think the last chances are: 

    1) increase AD of EIGRP (>BGP)
    or
    2) use route tag to avoid the routes coming back from CE

    R9#sh run |  s bgp

    router bgp 1009
     bgp router-id 9.9.0.9
     no bgp default ipv4-unicast
     bgp log-neighbor-changes
     neighbor 9.9.0.1 remote-as 1009
     neighbor 9.9.0.1 update-source Loopback0
     neighbor 9.9.0.8 remote-as 1009
     neighbor 9.9.0.8 update-source Loopback0
     neighbor 2002:9:9::1 remote-as 1009
     neighbor 2002:9:9::1 update-source Loopback0
     !
     address-family ipv4
      no synchronization
      network 9.9.0.9 mask 255.255.255.255
      neighbor 9.9.0.1 activate
      neighbor 9.9.0.8 activate
      no auto-summary
     exit-address-family
     !
     address-family vpnv4
      neighbor 9.9.0.8 activate
      neighbor 9.9.0.8 send-community extended
     exit-address-family
     !
     address-family ipv6
      no synchronization
      network 2002:9:9::9/128
      neighbor 2002:9:9::1 activate
     exit-address-family
     !
     address-family ipv4 vrf ABC
      no synchronization
      redistribute eigrp 109 route-map EIGRP-TO-BGP
     exit-address-family


    route-map EIGRP-TO-BGP permit 10
     set extcommunity cost pre-bestpath 1 100

    or

    route-map EIGRP-TO-BGP permit 10
     set extcommunity cost pre-bestpath 1 200000




    R9#sh bgp vpnv4 unicast vrf ABC 172.9.0.10/32
    BGP routing table entry for 1009:9:172.9.0.10/32, version 77
    Paths: (2 available, best #2, table ABC)
      Advertised to update-groups:
         64
      Local
        9.9.0.10 (metric 10) from 9.9.0.8 (9.9.0.8)
          Origin incomplete, metric 0, localpref 100, valid, internal
          Extended Community: RT:1009:9 Cost:pre-bestpath:128:128256
            0x8800:32768:0 0x8801:109:128000 0x8802:65280:256 0x8803:65281:1514
            0x8806:0:2886270986
          Originator: 9.9.0.10, Cluster list: 9.9.0.8
          mpls labels in/out 30/53
      Local
        172.9.195.15 from 0.0.0.0 (9.9.0.9)
          Origin incomplete, metric 4425984, localpref 100, weight 32768, valid, sourced, best
          Extended Community: SoO:109:3 RT:1009:9 Cost:pre-bestpath:1:200000
            Cost:pre-bestpath:128:4425984 (default-2143057663) 0x8800:32768:0
            0x8801:109:4423424 0x8802:65283:2560 0x8803:65281:1500
            0x8806:0:2886270986
          mpls labels in/out 30/nolabel


    R9#sh bgp vpnv4 unicast vrf ABC 172.9.0.10/32
    BGP routing table entry for 1009:9:172.9.0.10/32, version 2
    Paths: (2 available, best #2, table ABC)
      Advertised to update-groups:
         67
      Local
        9.9.0.10 (metric 10) from 9.9.0.8 (9.9.0.8)
          Origin incomplete, metric 0, localpref 100, valid, internal
          Extended Community: RT:1009:9 Cost:pre-bestpath:128:128256
            0x8800:32768:0 0x8801:109:128000 0x8802:65280:256 0x8803:65281:1514
            0x8806:0:2886270986
          Originator: 9.9.0.10, Cluster list: 9.9.0.8
          mpls labels in/out 30/53
      Local
        172.9.195.15 from 0.0.0.0 (9.9.0.9)
          Origin incomplete, metric 4425984, localpref 100, weight 32768, valid, sourced, best
          Extended Community: SoO:109:3 RT:1009:9 Cost:pre-bestpath:1:100
            Cost:pre-bestpath:128:4425984 (default-2143057663) 0x8800:32768:0
            0x8801:109:4423424 0x8802:65283:2560 0x8803:65281:1500
            0x8806:0:2886270986
          mpls labels in/out 30/nolabel

     


    From: [email protected]
    To: [email protected]
    Date: Wed, 1 Oct 2014 08:28:59 -0700
    Subject: Re: [CCIE SP] EIGRP SOO (same or different value) with backdoor link

    Hi,

     

    I've decided to reproduce it. Here is my topology:



    By default XR1 routes to 20.20.20.20 via R2. I would like to change it by means of cost community.

     

    RP/0/0/CPU0:XR1#show bgp vpnv4 unicast rd 1:1 20.20.20.20/32

    BGP routing table entry for 20.20.20.20/32, Route Distinguisher: 1:1

    Versions:

      Process           bRIB/RIB  SendTblVer

      Speaker                193         193

    Last Modified: Oct  1 17:16:08.180 for 00:00:18

    Paths: (1 available, best #1)

      Not advertised to any peer

      Path #1: Received by speaker 0

      Not advertised to any peer

      Local

        2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)

          Received Label 22

          Origin incomplete, metric 512, localpref 100, valid, internal, best, group-best, import-candidate, imported, import suspect

          Received Path ID 0, Local Path ID 1, version 193

          Extended community: COST:128:128:512 EIGRP route-info:0x8000:0 EIGRP AD:1:512 EIGRP RHB:255:1:256000 EIGRP LM:0xff:1:1500 0x8806:0x00:0x00:0x14:0x14:0x14:0x14 RT:1:1 

          Source VRF: A, Source Route Distinguisher: 1:1

     

    RP/0/0/CPU0:XR1#show eigrp vrf all topology all-links 

     

    IPv4-EIGRP Topology Table for AS(1)/ID(19.19.19.19) VRF: A

     

    Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

           r - reply Status, s - sia Status 

     

    P 1.1.1.1/32, 1 successors, FD is 512, RIB is 512, serno 90

            via 10.0.119.1 (512/256), GigabitEthernet0/0/0/0.100

    P 10.0.119.0/24, 1 successors, FD is 256, RIB is 256, serno 72

            via Connected, GigabitEthernet0/0/0/0.100

    P 10.0.120.0/24, 1 successors, FD is 512, RIB is 512, serno 91

            via 10.0.119.1 (512/256), GigabitEthernet0/0/0/0.100

    P 10.0.220.0/24, 1 successors, FD is 256, RIB is 256, serno 98

            via VPNv4 Sourced (256/0)

    P 20.20.20.20/32, 1 successors, FD is 512, RIB is 512, serno 99

            via VPNv4 Sourced (512/0)

            via 10.0.119.1 (768/512), GigabitEthernet0/0/0/0.100

     

    RP/0/0/CPU0:XR1#show route vrf A 

     

    Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

           E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

           i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

           ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

           U - per-user static route, o - ODR, L - local, G  - DAGR

           A - access/subscriber, a - Application route, (!) - FRR Backup path

     

    Gateway of last resort is not set

     

    D    1.1.1.1/32 [90/512] via 10.0.119.1, 00:53:02, GigabitEthernet0/0/0/0.100

    C    10.0.119.0/24 is directly connected, 22:09:50, GigabitEthernet0/0/0/0.100

    L    10.0.119.19/32 is directly connected, 22:09:50, GigabitEthernet0/0/0/0.100

    D    10.0.120.0/24 [90/512] via 10.0.119.1, 00:53:02, GigabitEthernet0/0/0/0.100

    B    10.0.220.0/24 [200/0] via 2.2.2.2 (nexthop in vrf default), 00:01:03

    B    20.20.20.20/32 [200/512] via 2.2.2.2 (nexthop in vrf default), 00:01:03

    As I understand: EIGRP is installing 20.20.20.20/32 in its toplogy with the FD of 512 based on Cost community it is receiving from R2. However when I change this cost community on R2 in order to influence this I am getting the same result: XR1 is still prefring to reach 20.20.20.20/32 over 2.2.2.2:

     

    BGP routing table entry for 20.20.20.20/32, Route Distinguisher: 1:1

    Versions:

      Process           bRIB/RIB  SendTblVer

      Speaker                197         197

    Last Modified: Oct  1 17:20:43.180 for 00:00:03

    Paths: (1 available, best #1)

      Not advertised to any peer

      Path #1: Received by speaker 0

      Not advertised to any peer

      Local

        2.2.2.2 (metric 2) from 2.2.2.2 (2.2.2.2)

          Received Label 22

          Origin incomplete, metric 512, localpref 100, valid, internal, best, group-best, import-candidate, imported

          Received Path ID 0, Local Path ID 1, version 197

          Extended community: COST:128:128:99999 EIGRP route-info:0x8000:0 EIGRP AD:1:512 EIGRP RHB:255:1:256000 EIGRP LM:0xff:1:1500 0x8806:0x00:0x00:0x14:0x14:0x14:0x14 RT:1:1 

          Source VRF: A, Source Route Distinguisher: 1:1

    RP/0/0/CPU0:XR1#show eigrp vrf all topology all-links       

     

    IPv4-EIGRP Topology Table for AS(1)/ID(19.19.19.19) VRF: A

     

    Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

           r - reply Status, s - sia Status 

     

    P 1.1.1.1/32, 1 successors, FD is 512, RIB is 512, serno 90

            via 10.0.119.1 (512/256), GigabitEthernet0/0/0/0.100

    P 10.0.119.0/24, 1 successors, FD is 256, RIB is 256, serno 72

            via Connected, GigabitEthernet0/0/0/0.100

    P 10.0.120.0/24, 1 successors, FD is 512, RIB is 512, serno 91

            via 10.0.119.1 (512/256), GigabitEthernet0/0/0/0.100

    P 10.0.220.0/24, 1 successors, FD is 768, RIB is 768, serno 101

            via 10.0.119.1 (768/512), GigabitEthernet0/0/0/0.100

    P 20.20.20.20/32, 1 successors, FD is 512, RIB is 512, serno 99

            via VPNv4 Sourced (512/0)

            via 10.0.119.1 (768/512), GigabitEthernet0/0/0/0.100

     

    RP/0/0/CPU0:XR1#show route vrf A            

     

    Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

           E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

           i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

           ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

           U - per-user static route, o - ODR, L - local, G  - DAGR

           A - access/subscriber, a - Application route, (!) - FRR Backup path

     

    Gateway of last resort is not set

     

    D    1.1.1.1/32 [90/512] via 10.0.119.1, 00:57:46, GigabitEthernet0/0/0/0.100

    C    10.0.119.0/24 is directly connected, 22:14:34, GigabitEthernet0/0/0/0.100

    L    10.0.119.19/32 is directly connected, 22:14:34, GigabitEthernet0/0/0/0.100

    D    10.0.120.0/24 [90/512] via 10.0.119.1, 00:57:46, GigabitEthernet0/0/0/0.100

    D    10.0.220.0/24 [90/768] via 10.0.119.1, 00:02:47, GigabitEthernet0/0/0/0.100

    B    20.20.20.20/32 [200/512] via 2.2.2.2 (nexthop in vrf default), 00:01:12

     

    Is it the correct way to influence path selection over MPLS core? If we could influence FD of VPNv4 route that is being imported into EIGRP, I guess it would be possibe to influence this. But Cost community is not helping to acheive this. 

     

    Here are my configs:

     

    ####R1####

     

    hostname R1

    !

    i!

    interface Loopback0

     ip address 1.1.1.1 255.255.255.255

     delay 1

    !

    interface FastEthernet0/0

     no ip address

     shutdown

     duplex full

    !

    interface Ethernet1/0

     ip address 10.0.119.1 255.255.255.0

     delay 1

     duplex full

    !

    interface Ethernet1/1

     ip address 10.0.120.1 255.255.255.0

     delay 1

     duplex full

    !

    interface Ethernet1/2

     no ip address

     shutdown

     duplex full

    !

    interface Ethernet1/3

     no ip address

     shutdown

     duplex full

    !

    !

    router eigrp 1

     metric weights 0 0 0 1 0 0

     network 0.0.0.0

     

    ####R2####

     

    hostname R2

    !

    boot-start-marker

    boot-end-marker

    !

    !

    vrf definition A

     rd 1:1

     route-target export 1:1

     route-target import 1:1

     !

     address-family ipv4

     exit-address-family

    !

    !         

    interface Loopback0

     ip address 2.2.2.2 255.255.255.255

    !

    interface Ethernet1/0

     ip address 10.0.219.2 255.255.255.0

     ip ospf authentication message-digest

     ip ospf message-digest-key 1 md5 cisco

     ip ospf network point-to-point

     duplex full

    !

    interface Ethernet1/1

     vrf forwarding A

     ip address 10.0.220.2 255.255.255.0

     delay 1

     duplex full

    !

    interface Ethernet1/2

     no ip address

     shutdown

     duplex full

    !

    interface Ethernet1/3

     no ip address

     shutdown

     duplex full

    !

    !

    router eigrp 1

     !

     address-family ipv4 vrf A 

      redistribute bgp 1 metric 2 2 2 3 3

      network 0.0.0.0

      metric weights 0 0 0 1 0 0

      autonomous-system 1

     exit-address-family

    !

    router ospf 1

     router-id 2.2.2.2

     network 0.0.0.0 255.255.255.255 area 0

     mpls ldp autoconfig

    !

    router bgp 1

     bgp log-neighbor-changes

     no bgp default ipv4-unicast

     neighbor 19.19.19.19 remote-as 1

     neighbor 19.19.19.19 update-source Loopback0

     !

     address-family ipv4

     exit-address-family

     !

     address-family vpnv4

      neighbor 19.19.19.19 activate

      neighbor 19.19.19.19 send-community both

      neighbor 19.19.19.19 route-map R20 out

     exit-address-family

     !

     address-family ipv4 vrf A

      redistribute eigrp 1

     exit-address-family

    !

    ip forward-protocol nd

    !

    !

    no ip http server

    no ip http secure-server

    !

    !

    ip prefix-list R20 seq 5 permit 20.20.20.20/32

    !

    route-map COST permit 10

     match ip address prefix-list 20

    !

    route-map R20 permit 10

     match ip address prefix-list R20

     set extcommunity cost pre-bestpath 128 99999

     

     

    #####XR1#####

     

    hostname XR1

    cdp

    vrf A

     address-family ipv4 unicast

      import route-target

       1:1

      !

      export route-target

       1:1

      !

     !

    !

    vrf Management

    !

    line template TELNET

     exec-timeout 0 0

    !

    line console

     exec-timeout 0 0

    !

    line default

     exec-timeout 0 0

    !

    vty-pool default 0 99 line-template TELNET

    ipv4 access-list R20

     10 permit ipv4 host 20.20.20.20 any

    !

    interface Loopback0

     ipv4 address 19.19.19.19 255.255.255.255

    !

    interface MgmtEth0/0/CPU0/0

     vrf Management

     ipv4 address 172.16.33.206 255.255.255.0

    !

    interface GigabitEthernet0/0/0/0

     cdp

    !

    interface GigabitEthernet0/0/0/0.100

     vrf A

     ipv4 address 10.0.119.19 255.255.255.0

     encapsulation dot1q 100

    !

    interface GigabitEthernet0/0/0/0.101

     ipv4 address 10.0.219.19 255.255.255.0

     encapsulation dot1q 101

    !

    route-policy R1

      if destination in (1.1.1.1/32) then

        set extcommunity cost (Pre-Bestpath:128:300000)

      else

        pass

      endif

    end-policy

    !

    router static

     vrf Management

      address-family ipv4 unicast

       0.0.0.0/0 172.16.33.254

      !

     !

    !

    router ospf 1

     mpls ldp auto-config

     area 0

      interface Loopback0

       passive enable

      !

      interface GigabitEthernet0/0/0/0.101

       authentication message-digest

       message-digest-key 1 md5 encrypted 02050D480809

       network point-to-point

      !

     !

    !

    router bgp 1

     address-family vpnv4 unicast

     !

     neighbor 2.2.2.2

      remote-as 1

      update-source Loopback0

      address-family vpnv4 unicast

       route-policy R1 out

      !

     !

     vrf A

      rd 1:1

      address-family ipv4 unicast

       redistribute eigrp 1

      !

     !

    !

    mpls ldp

     router-id 19.19.19.19

    !

    router msdp

     peer 9.9.0.15

     !

    !

    router eigrp 1

     vrf A

      address-family ipv4

       metric weights 0 0 0 1 0 0

       metric rib-scale 1

       metric version 32bit

       router-id 19.19.19.19

       default-metric 2 2 2 2 2

       autonomous-system 1

       redistribute bgp 1

       interface GigabitEthernet0/0/0/0.100

        metric delay 1

       !

      !

     !

    !

    end

     

    #####XR2#####

     

    hostname XR2

    telnet vrf default ipv4 server max-servers 10

    telnet vrf Management ipv4 server max-servers 10

    cdp

    vrf Management

    !

    line console

     exec-timeout 0 0

    !

    line default

     exec-timeout 0 0

    !

    vty-pool default 0 99 line-template TELNET

    interface Loopback0

     ipv4 address 20.20.20.20 255.255.255.255

     ipv6 address 2001::7/128

    !

    interface MgmtEth0/0/CPU0/0

     vrf Management

     ipv4 address 172.16.33.161 255.255.255.0

    !

    interface GigabitEthernet0/0/0/0

     cdp

    !

    interface GigabitEthernet0/0/0/0.102

     ipv4 address 10.0.220.20 255.255.255.0

     encapsulation dot1q 102

    !

    interface GigabitEthernet0/0/0/0.103

     ipv4 address 10.0.120.20 255.255.255.0

     encapsulation dot1q 103

    !

    router static

     vrf Management

      address-family ipv4 unicast

       0.0.0.0/0 172.16.33.254

      !

     !

    !

    router eigrp 1

     address-family ipv4

      metric weights 0 0 0 1 0 0

      metric rib-scale 1

      metric version 32bit

      interface Loopback0

       metric delay 1

      !

      interface GigabitEthernet0/0/0/0.102

       metric delay 1

      !

      interface GigabitEthernet0/0/0/0.103

       metric delay 1

      !

     !

    !

    end




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • I tried on my lab. To make a verification of use cost-community we have to use "pre-bestpath 1 <value>" on all PE to garant match:

     

    router eigrp 65535

     !

     address-family ipv4 vrf ABC autonomous-system 109

      default-metric 100000 100 255 1 1500

      redistribute bgp 1009

      network 172.9.0.9 0.0.0.0

      network 172.9.195.0 0.0.0.255

    !


    router bgp 1009

    !



     address-family ipv4 vrf ABC

      no synchronization

      redistribute eigrp 109 route-map EIGRP-TO-BGP

    !


    route-map EIGRP-TO-BGP permit 10

     set extcommunity cost pre-bestpath 1 300




  • So I'm realized :

    1) With the use of Cost-community without any change we can protect for loop and sub-optimal routing (internal and external routes (from mb-bgp)).

    2) If we have multihomed site (dual CE) with backdoor link the embedded cost-community can protect the customer sites and soo on PE isn't necessary (this garant the use of mpls link as backup/transit.

     

    Isacco

  • With bgp cost-community enabled on all PE what appen if the external routes haven't the Cost community set (for example due by redistribution of other protocols) ?

    As you can see after clearing iBGP on PE (R10) the route arrive from internal eigrp BUT the metric is changing to  infinite... clear after some second disappear due count to infinity!!!! Terrible !!! My expectation is the external route disappear immediatly when iBGP peer come up due the cost-community..

    Any comments ?

    To resolve my headache SO I used TAG and Distribute list in on eigro to avoid the external routes can be installed by eigrp on PE. Now ALL same perfect !!

     

    FOLLOW THE PROBLEM:

     

    R10#clear ip bgp *

    R10#sh bgp vpnv4 unicast vrf ABC 172.9.0.1

    BGP routing table entry for 1009:9:172.9.0.1/32, version 0

    Paths: (1 available, no best path)

      Not advertised to any peer

      Local

        172.9.106.16 from 0.0.0.0 (9.9.0.10)

          Origin incomplete, metric 51968, localpref 100, weight 32768, valid, sourced

          Extended Community: RT:1009:9 Cost:pre-bestpath:129:51968 0x8800:0:0

            0x8801:109:26368 0x8802:65283:25600 0x8803:65281:1500

            0x8804:1009:2886270985 0x8805:9:0 0x8806:0:2886270985

    R10#sh bgp vpnv4 unicast vrf ABC 172.9.0.1

    BGP routing table entry for 1009:9:172.9.0.1/32, version 45

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

      Advertised to update-groups:

         8

      Local

        172.9.106.16 from 0.0.0.0 (9.9.0.10)

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

          Extended Community: RT:1009:9 Cost:pre-bestpath:129:52736 0x8800:0:0

            0x8801:109:27136 0x8802:65286:25600 0x8803:65281:1500

            0x8804:1009:2886270985 0x8805:9:0 0x8806:0:2886270985

          mpls labels in/out 26/nolabel

    R10#sh bgp vpnv4 unicast vrf ABC 172.9.0.1

    BGP routing table entry for 1009:9:172.9.0.1/32, version 59

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

      Advertised to update-groups:

         8

      Local

        172.9.106.16 from 0.0.0.0 (9.9.0.10)

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

          Extended Community: RT:1009:9 Cost:pre-bestpath:129:54272 0x8800:0:0

            0x8801:109:28672 0x8802:65292:25600 0x8803:65281:1500

            0x8804:1009:2886270985 0x8805:9:0 0x8806:0:2886270985

          mpls labels in/out 26/nolabel

  • Have you seen this document? http://blog.ine.com/wp-content/uploads/2010/04/understanding-eigrp-soo-bgp-cost-community.pdf

    Looks like you have reproduced the case that was described here, when there is a race condition between EIGRP and BGP when EIGRP route is finally discarded due to hop count reaching the limit.




  • Hello,
    I tried with SOO (with different values on PE and CE) no results... If i use the same value I loose the backup mpls link...

    So I used tag (bgp to eigrp) and distribute-list in on PE to avoid the PE reach external routes from eigrp...
    This resolved the problem


    from Cisco TAC: " The cost community is used for EIGRP route only not for another routing protocol . Like OSPF has their community , BGP has their attribute as well .  and EIGRP  cost community is there for the suboptimal routing . not for the loop avoidance method ."

    I

    From: [email protected]
    To: [email protected]
    Date: Mon, 6 Oct 2014 11:46:29 -0700
    Subject: Re: [CCIE SP] EIGRP SOO (same or different value) with backdoor link

    Have you seen this document? http://blog.ine.com/wp-content/uploads/2010/04/understanding-eigrp-soo-bgp-cost-community.pdf

    Looks like you have reproduced the case that was described here, when there is a race condition between EIGRP and BGP when EIGRP route is finally discarded due to hop count reaching the limit.



    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

Sign In or Register to comment.