SP Class on Demand: EIGRP SOO didnt work

Hi,

In the SP Class on Demand there was an example showing how EIGRP SOO works using EIGRP as PE-CE with backdoor links. This never actually worked and routes were not filtered as they should  have been. Brian mentioned that he would come back to this but never did.

I labbed this out myself and experienced exactly the same problem - does EIGRP SOO not work with the IOS and hardware for the current SP lab?

Has anyone got this to work and if so could they post some example configs?

Thanks in advance

Comments

  • I tried it once a few months ago, and I don't have any configs left :(

    Actually I used scenario from "MPLS Configuration on Cisco IOS Software" book and (as far as I remember) everything worked fine as expected.

  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">








    I remember this one. Brian said that most likely the
    problem was due to a Bug in the 3550's. I never tried to configure this but i
    will try to do it later today. I will update you with my
    findings.

     

    Regards,

    Antonio Soares,
    CCIE #18473 (R&S)

     





    From: [email protected] [mailto:[email protected]]
    On Behalf Of pkg
    Sent: segunda-feira, 21 de Julho de 2008
    11:08
    To: [email protected]
    Subject: [CCIE SP] SP Class on
    Demand: EIGRP SOO didnt work


    Hi,

    In the SP Class on Demand there was an example showing how EIGRP SOO works
    using EIGRP as PE-CE with backdoor links. This never actually worked and routes
    were not filtered as they should  have been. Brian mentioned that he would
    come back to this but never did.

    I labbed this out myself and experienced exactly the same problem - does
    EIGRP SOO not work with the IOS and hardware for the current SP lab?

    Has anyone got this to work and if so could they post some example
    configs?

    Thanks in advance




    Internetwork
    Expert - The Industry Leader in CCIE
    Preparation
    http://www.internetworkexpert.com

    Subscription information
    may be found
    at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

    Antonio Soares, CCIE #18473 (RS/SP/DC)
    [email protected]
    http://www.ccie18473.net

  • <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">






    Did you try the example from the IEWB-SP Volume 1 labs?



    Brian McGahan, CCIE #8593 (R&S/SP/Security)

    [email protected]

     

    Internetwork Expert, Inc.

    http://www.InternetworkExpert.com

    Toll Free: 877-224-8987 x 705

    Outside US: 775-826-4344 x 705

    Online Community: http://www.IEOC.com

    CCIE Blog: http://blog.internetworkexpert.com






    pkg wrote:

    Hi,

    In the SP Class on Demand there was an example showing how EIGRP
    SOO works using EIGRP as PE-CE with backdoor links. This never actually
    worked and routes were not filtered as they should  have been. Brian
    mentioned that he would come back to this but never did.

    I labbed this out myself and experienced exactly the same problem
    - does EIGRP SOO not work with the IOS and hardware for the current SP
    lab?

    Has anyone got this to work and if so could they post some example
    configs?

    Thanks in advance







    Internetwork Expert - The Industry Leader in CCIE Preparation

    http://www.internetworkexpert.com



    Subscription information may be found at:

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

  • Hi

    I tried the BGP SOO lab from Workbook 1 which worked fine - there is no EIGRP SOO example in the Workbook 1 labs, but I did create one to test as per the CoD example.

    Despite seeing the SoO set on the VPNv4 routes inbound on the PE routers, they still happily accepted the routes from the CE backdoor routers (which were also setting the SoO with a vrf sitemap).

    This was all done using 3640 routers via dynamips - there were no 3550s so that rules out any compatibility issues on those.

    All appeared to be doing what it should - only the PE routers accepted the routes with SoO set to the same value as the vrf sitemap - which is not correct.

  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">








    Well, i also made several tests and i don't see any effect
    when configuring "ip vrf sitemap" in the CE routers.

     

    And after reading the command reference, i don't get
    what this command has to do with EIGRP specifically:

     


     

    I
    changed the PE-CE routing protocol to RIP and i got exacly the same behaviour:
    CE routes are marked with the SoO extended community inbound in one PE and are
    filtered out in the other PE.

     

    For
    example, if you break the link between R7 and R8, they will have their rip or
    eigrp routing tables empty.

     

    Let's
    wait for Brian's clarification.

     
    <!>

    Regards,

    Antonio Soares, CCIE
    #18473 (R&S)

    Antonio Soares, CCIE #18473 (RS/SP/DC)
    [email protected]
    http://www.ccie18473.net

  • Guys, have tried scenario from "MPLS Configuration on Cisco IOS Software", pages 200-211?

    As I mentioned before, as far as I remember it was working fine for me. I don't have configuration backups, but I can simulate it later today again.

    I will post my findings.

  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">








    Hello Sebastian,

     

    I followed your advice and i still don't get it. The
    example starts with a sub-optimal routing situation that i don't have. For
    example, PE1-AS1 sees 172.16.20.0/24 network via CE3-A and PE2-AS1 sees
    172.16.10.0/24 via CE4-A. How is this possible ? The only way i see is breaking
    the connection between PE1-AS1 and PE2-AS1.

     

    And the logic seems strange to me:

     

    PE1-AS1 marks CE3-A routes with SoO=1:10, so it won't
    send back to CE3-A routes with SOO=1:10. But
    PE2-AS1 is marking CE4-A routes with
    SoO=1:20, so nothing will happen.
    The same
    happens for PE2-AS1.

     

    It would be great to have your inputs about
    this.

     

    Thanks.
    <!>

    Regards,

    Antonio
    Soares, CCIE #18473 (R&S)

    Antonio Soares, CCIE #18473 (RS/SP/DC)
    [email protected]
    http://www.ccie18473.net

  • All,

     

    I was really perplexed by this particular problem and had to look into it.  I have tried several examples, and I implemented them all with no success.  It seemed that the SoO community was being completely ignored no matter what I tried.  I tried this on the IPExpert gear, my own lab gear here at work, and on the InternetworkExpert gear.  This was what i got with the SOO implemented for prefix 200.0.0.6/32 in the EIGRP debug:

    *Aug 14 08:27:07.799: IP-EIGRP(NICE:18): Int 200.0.0.6/32 metric 4294967295 - 25600 4294967295 (yes my VRF name is NICE :) )

    This is a prefix that should have been denied due to route loop.  However, I also realized that in all my examples the path between the EIGRP routers at the same site was always the preferred path.  I wasn't sure what effect that would have on the SOO, so I changed the interface in question to have a much higer delay.

    R1(config)#int f0/1
    R1(config-if)#del
    R1(config-if)#delay 50000

    Once I changed the delay, I immediately got the following debug output on my PE routers:

    *Aug 14 08:27:07.867: IP-EIGRP(NICE:18): 200.0.0.6/32 - denied by SoO: loop detected

    It would appear that as long as the intra-site link is the more preferred path SOO does not apply on the PE routers.  I have duplicated this over and over again... This is just my observation.

  • Hi,

    I came back to this one and moved some devices around.

    I change the PE routers from 3640s (12.3T) to 7200s (12.2S) to see if this helped. It didnt. IOS 12.2S doesnt seem to support the BGP cost-community let alone the EIGRP SoO as routes were being preferred over the VPN site even though the EIGRP metric was lower across the MPLS backbone. I dont think the POI pre-bestpath was working at all.

    Info from Cisco website on EIGRP SoO suggests that to get it to work you need to run 12.0S on the PE routers - as this it not in the current lab blueprint is it safe to assume that they cannot test on EIGRP SoO on the current CCIE SP lab?

    http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_mvesoo.html

    "All PE routers that are configured to support the EIGRP MPLS VPN must run Cisco IOS Release 12.0(27)S, which provides support for the SoO extended community."

    I have serious concerns about this topic as even Brian couldnt get this to work on the CoD, and the Cisco Press 'MPLS Config on Cisco IOS' seems to have it wrong also suggesting that SoO is set when you send routes out from the PE (I've found it only gets set on routes inbound not outbound).

  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">








    I was able to make
    it work with 12.0S only. Check the mini-scenario i have
    called "PE-CE Routing (EIGRP Site of Origin)"
    taken from the book you mentioned:

     


     

    I also had those
    doubts related with who actually marks the routes and in which direction and my
    conclusion is the same as yours (only inbound).

     

    For
    example:

     

    - PE2 sends CE2
    route to CE4 via EIGRP.
    - PE2 sends CE2 route to PE1 via iBGP.
    - CE4 sends
    CE2 route to CE3.
    - CE3 marks inbound CE2 route with SoO=3:3 and sends it to
    PE1.
    - PE1 drops the route since it is configured with
     SoO=3:3 in the interface to CE3.
    - PE1 sends best CE2
    route to CE1 which is via PE2.

     

    - PE1 sends CE1
    route to CE3 via EIGRP.
    - PE1 sends CE1 route to PE2 via iBGP.
    - CE3 sends
    CE2 route to CE4.
    - CE4 marks inbound CE1 route with SoO=4:4 and sends it to
    PE2.
    - PE2 drops the route since it is configured with
    SoO=4:4 in the interface to CE4.
    - PE2 sends best CE1
    route to CE2 which is via PE1.

     

     

    It's
    very unlikely to deal with this feature in the lab but not impossible.
    In fact is it not supported in 12.2S but it is in 12.3T.

     


    Regards,
     
    Antonio Soares, CCIE #18473 (R&S)
    [email protected]





    From: [email protected] [mailto:[email protected]]
    On Behalf Of pkg
    Sent: quinta-feira, 11 de Setembro de 2008
    12:08
    To: [email protected]
    Subject: Re: [CCIE SP] RE: SP
    Class on Demand: EIGRP SOO didnt work


    Hi,

    I came back to this one and moved some devices around.

    I change the PE routers from 3640s (12.3T) to 7200s (12.2S) to see if this
    helped. It didnt. IOS 12.2S doesnt seem to support the BGP cost-community let
    alone the EIGRP SoO as routes were being preferred over the VPN site even though
    the EIGRP metric was lower across the MPLS backbone. I dont think the POI
    pre-bestpath was working at all.

    Info from Cisco website on EIGRP SoO suggests that to get it to work you need
    to run 12.0S on the PE routers - as this it not in the current lab blueprint is
    it safe to assume that they cannot test on EIGRP SoO on the current CCIE SP
    lab?

    http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_mvesoo.html

    "All PE routers that are configured to support the EIGRP MPLS VPN must run
    Cisco IOS Release 12.0(27)S, which provides support for the SoO extended
    community."

    I have serious concerns about this topic as even Brian couldnt get this to
    work on the CoD, and the Cisco Press 'MPLS Config on Cisco IOS' seems to have it
    wrong also suggesting that SoO is set when you send routes out from the PE (I've
    found it only gets set on routes inbound not outbound).




    Internetwork
    Expert - The Industry Leader in CCIE
    Preparation
    http://www.internetworkexpert.com

    Subscription information
    may be found
    at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

    Antonio Soares, CCIE #18473 (RS/SP/DC)
    [email protected]
    http://www.ccie18473.net

  • Thanks Antonio - that helps to clear things up a lot.

    I presume you could only get this to work using 12.0S on 7200s as your PE routers? My own experience is that this does not work running 12.3T on 3640s as PE routers - also failed for Brian on the CCIE SP CoD.

     

  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">








    Well, i was playing again with this and i found a quite
    strange behavior with 12.0S. Even without any SoO configurations, PE1 prefers
    routes from PE2 than from CE3. And why ? Because for some reason, it decides
    that iBGP has a lower administrative distance than EIGRP:

     

    +++++++++++++++++++++++++++++++++

    PE1#sh ip route vrf RED

     

    Routing Table: RED
    Codes: C - connected, S - static, I -
    IGRP, R - RIP, M - mobile, B - BGP
           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 - IS-IS, su - IS-IS summary, L1 -
    IS-IS level-1, L2 - IS-IS level-2
           ia -
    IS-IS inter area, * - candidate default, U - per-user static
    route
           o - ODR

     

    Gateway of last resort is not set

     

         172.16.0.0/16 is variably
    subnetted, 9 subnets, 2 masks
    B      
    172.16.40.0/24 [200/1764352] via 10.10.10.102,
    00:00:06
    D       172.16.30.0/24 [90/1764352]
    via 172.16.3.2, 00:03:07, Serial1/3
    B       172.16.20.0/24 [200/1764352]
    via 10.10.10.102,
    00:00:06

    D       172.16.10.0/24
    [90/1764352] via 172.16.1.2, 00:03:19,
    Serial1/0
    B       172.16.4.0/30 [200/0] via
    10.10.10.102, 00:00:06
    D       172.16.5.0/30
    [90/2273792] via 172.16.3.2, 00:03:07,
    Serial1/3
    C       172.16.1.0/30 is directly
    connected, Serial1/0
    B       172.16.2.0/30
    [200/0] via 10.10.10.102, 00:00:06
    C      
    172.16.3.0/30 is directly connected, Serial1/3
    PE1#
    PE1#deb ip routing vrf
    RED
    IP routing debugging is on for VRF RED
    PE1#
    PE1#clear ip bgp
    10.10.10.102
    PE1#
    PE1#
    00:07:14: %BGP-5-ADJCHANGE: neighbor
    10.10.10.102 Down User reset
    PE1#
    00:07:14: RT(RED): del 172.16.2.0/30 via
    10.10.10.102, bgp metric [200/0]
    00:07:14: RT(RED): delete subnet route to
    172.16.2.0/30
    00:07:14: RT(RED): del 172.16.4.0/30 via 10.10.10.102, bgp
    metric [200/0]
    00:07:14: RT(RED): delete subnet route to
    172.16.4.0/30
    00:07:14:
    RT(RED): del 172.16.20.0/24 via 10.10.10.102, bgp metric
    [200/1764352]
    00:07:14: RT(RED): delete subnet route to
    172.16.20.0/24
    00:07:14: RT(RED): del 172.16.40.0/24 via
    10.10.10.102, bgp metric [200/1764352]
    00:07:14: RT(RED): delete subnet route
    to 172.16.40.0/24
    PE1#
    PE1#
    00:07:14: RT(RED): add 172.16.4.0/30 via
    172.16.3.2, eigrp metric [90/2785792]
    00:07:14: RT(RED): add 172.16.40.0/24
    via 172.16.3.2, eigrp metric [90/2276352]
    00:07:14: RT(RED): add
    172.16.2.0/30 via 172.16.3.2, eigrp metric [90/3297792]
    00:07:14: RT(RED): add 172.16.20.0/24 via 172.16.3.2, eigrp metric
    [90/3300352]

    PE1#
    00:07:20: %BGP-5-ADJCHANGE: neighbor
    10.10.10.102 Up
    PE1#
    00:07:20: RT(RED): closer admin distance for
    172.16.2.0, flushing 1 routes
    00:07:20: RT(RED): add 172.16.2.0/30 via
    10.10.10.102, bgp metric [200/0]
    00:07:20: RT(RED): closer admin distance for
    172.16.4.0, flushing 1 routes
    00:07:20: RT(RED): add 172.16.4.0/30 via
    10.10.10.102, bgp metric [200/0]
    00:07:20: RT(RED): closer admin distance for 172.16.20.0,
    flushing 1 routes
    00:07:20: RT(RED): add 172.16.20.0/24 via 10.10.10.102, bgp
    metric [200/1764352]

    00:07:20: RT(RED): closer admin distance
    for 172.16.40.0, flushing 1 routes
    00:07:20: RT(RED): add 172.16.40.0/24 via
    10.10.10.102, bgp metric [200/1764352]
    PE1#

    +++++++++++++++++++++++++++++++++

     

    The
    exactly same scenario with 12.2S works as expected:

     

    +++++++++++++++++++++++++++++++++

    PE1#sh
    ip route vrf RED

     

    Routing Table: RED
    Codes: C - connected, S - static, R - RIP, M -
    mobile, B - BGP
           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 - IS-IS, su - IS-IS summary, L1 -
    IS-IS level-1, L2 - IS-IS level-2
           ia -
    IS-IS inter area, * - candidate default, U - per-user static
    route
           o - ODR, P - periodic downloaded
    static route

     

    Gateway of last resort is not set

     

         172.16.0.0/16 is variably subnetted, 9 subnets,
    2 masks
    D       172.16.40.0/24 [90/2684416] via
    172.16.3.2, 00:29:50, Serial1/3
    D      
    172.16.30.0/24 [90/2172416] via 172.16.3.2, 00:29:50, Serial1/3
    D       172.16.20.0/24
    [90/3708416] via 172.16.3.2, 00:29:50,
    Serial1/3
    D      
    172.16.10.0/24 [90/2172416] via 172.16.1.2, 00:29:50,
    Serial1/0
    D       172.16.4.0/30 [90/3193856]
    via 172.16.3.2, 00:29:50, Serial1/3
    D      
    172.16.5.0/30 [90/2681856] via 172.16.3.2, 00:29:50,
    Serial1/3
    C       172.16.1.0/30 is directly
    connected, Serial1/0
    D       172.16.2.0/30
    [90/3705856] via 172.16.3.2, 00:29:50,
    Serial1/3
    C       172.16.3.0/30 is directly
    connected, Serial1/3
    PE1#

    +++++++++++++++++++++++++++++++++

     

    Any ideas about what is causing this ? Is this a
    Bug or a Feature ? :)

     

     

    Thanks.
    <!>

    Regards,

    Antonio Soares, CCIE
    #18473 (R&S)
    [email protected]

    Antonio Soares, CCIE #18473 (RS/SP/DC)
    [email protected]
    http://www.ccie18473.net

  • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">








    Now i get it. It due to BGP Cost Community Feature. The
    composite metric is compared before the administrative
    distance.

     

    ++++++++++++++++++++++

    PE1#sh ip bgp vpnv4 all
    172.16.20.0
    BGP routing table entry for 1:1:172.16.20.0/24, version
    27
    Paths: (1 available, best #1, table RED)
    Flag: 0x820
      Not
    advertised to any peer
      Local
        10.10.10.102
    (metric 97) from 10.10.10.102 (10.10.10.102)
         
    Origin incomplete, metric 1764352, localpref 100, valid, internal,
    best
          Extended Community: RT:1:1

            Cost:pre-bestpath:128:1764352 (default-2145719295)
    0x8800:32768:0
            0x8801:101:514560
    0x8802:65281:1249792 0x8803:65281:1500
          mpls
    labels in/out nolabel/23
    PE1#

    ++++++++++++++++++++++

     

    So
    with 12.0S we don't need to use EIGRP SoO since BGP CC will take care of
    it.

     

    In the
    other hand, 12.2S does not support BGP CC and EIGRP SoO does not
    work.

     

    I have
    enough reasons to forget this stuff and move on :)
    <!>

    Regards,

    Antonio Soares,
    CCIE #18473 (R&S)
    [email protected]

    Antonio Soares, CCIE #18473 (RS/SP/DC)
    [email protected]
    http://www.ccie18473.net

  • Hi all,

    So actually SOO is just used to prevent CE from advertising the same routes to PE. I couldn't see loop happening in this example even SoO is not used. BGP routes is always prefered to EIGRP routes due to the Cost Community.

    Also, if SOO is configured, it will prevent PE from accepting routes with the same soo value to its configured Soo. So why when we do clear ip bgp *, PE still accept those routes? Is SOO only meaningful in case VPN is up?

    Thanks

  • And why Brian is trying to enable SOO on CE devices (R7 and R8). They have no idea of VRF at all. This config should go only on PE devices towards the CE interfaces. Please correct me if I am wrong.

  • Hi,

    I had problems figuring out the EIGRP SoO.

    I would like to recommend anyone also having problems with this, to read through pages 220 - 226 in "MPLS Fundamentals".

    It all seems much clearer to me at least, after having read this.

    :-)

    BR
    Toby

  • Verify support on PE and CE routers:



    EIGRP site-of-origin (SoO) introduced in 12.0(27)S, 12.1(18)SXE, 12.3(8)T and 12.4

     

    I had to filter based on tags because of this. 

Sign In or Register to comment.