EIGRP SoO Not Working

I have the following topology with the same SoO set at all sites. On the PE’s the SoO is set on the PE-CE interface. On the CE’s it is set on the CE-CE interface.


Theoretically, this should break IP routing between the sites but is not. I have tried shutting down the PE-CE link on the PE1/CE1 pair, the link on the PE2/CE2 (after enabling the  PE1/CE1), and the link on the CE1/CE2 connection (after enable the PE2/CE2 connection).

In all of the above scenarios, CE1 and CE2 have full routing which they should not based on my understanding of the SSO feature.

My understanding is that the SoO feature is supposed to set the SoO outbound on routes sent out of the interface. If a route is received inbound with an SoO set and it matches the locally configured SoO, the route is discarded. Likewise, if a route is sent out of the interface and it already has an SoO applied that matches the locally configured SoO it is supposed to be discarded.

Based on this, in the above diagram setting the same SoO on all four routers should break routing between the sites but it is not.

Below is the configuration I am using.

route-map SET-SOO permit 10
 set extcommunity soo 100:1
interface GigabitEthernetX
 ip vrf sitemap SET-SOO

Any ideas what I am doing wrong?

Thank you.




The route-maps are applying the SoO. So when I say it is not working, I mean the routers are not performing the filtering but they are setting the SoO.


R5#sh ip bgp vpnv4 vrf VPN_A
BGP routing table entry for 100:1:, version 248
Paths: (1 available, best #1, table VPN_A)
  Advertised to update-groups:
  Refresh Epoch 1
  Local (via vrf VPN_A) from (
      Origin incomplete, metric 2690816, localpref 100, weight 32768, valid, sourced, best
      Extended Community: SoO:100:1 RT:100:1
        Cost:pre-bestpath:128:2690816 (default-2144792831) 0x8800:32768:0
        0x8801:100:2688256 0x8802:65282:2560 0x8803:65281:1500
      mpls labels in/out 19/nolabel
      rx pathid: 0, tx pathid: 0x0



  • What version of code are you using? I recall running into this issue on several versions of code, where the SoO tag would not get applied as expected. 

    When I ran into is that the SoO tag would only get applied if the router with the Sitemap applied received the route, not if it sent the route. 

    This seems to be fixed in newer version - I've tested this on IOS-XE 3.12 and its working as expected. 

  • I got stuck on EIGRP SoO in the past as well,  here are my notes that ended up landing on:


    Only gets SET ingress on the PE only.

    - However, it gets checked:

       - egress on PE

       - ingress on PE

       - ingress (NOT egress) on CE

    Try your testing by activating another site, then see if you can get your desired result.  Even in your current topolgoy and your config,  if you shutdown your CE to CE backdoor link, your two routers should not have connectivty to each other... do they presently ?

  • This is the version of code I am running:


    Cisco IOS XE Software, Version 03.13.01.S - Extended Support Release

    Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.4(3)S1, RELEASE SOFTWARE (fc3)

    After shutting down the CE-CE link and I do not have connectivity between the sites which indicates the the PE filtering is working. I.e., I cannot use the MPLS VPN to pass the traffic between CE's.



    However, I should not be able to use the CE-CE link either as it has the
    same sitemap applied as the PE-CE links. However The CE-CE link can
    pass traffic just fine. My understanding from reading the INE white
    paper on SoO and from reading the current workbook entry on SoO is that
    the CE-CE link should also not work if the SoO is the same on both sides
    but it is working.


    Should'nt the CE-CE link drops the routes as well with the sitemap applied?


    Thank you for the IOS top plucena24 and thank you 1000BaseT for finding and sharing your notes with me.


    EDIT: I read your notes for the 4th time and it clicked, the SoO is not being set on the CE's at all thus the SoO is not set when learning routes from the other CE.


    As a result, if I shutdown one of the PE-CE links, the SoO that is set never makes it to any of the CE's. I would need to change the topology somehow for that to happen since it is only set inbound on the PE's.


    I wish the documentation (both INE and cisco) was as to the point as your notes.



  • Hi,

       I'm not sure what you expect to work or not, but the SITEMAP applied on the CE-CE link is NOT used to set the SOO value, but only for route filtering. The SOO value can only get set as IPv4 prefixes are exported from EIGRP (PE-CE routing) into BGP and become VPNv4 routes, thus the SOO value can be set; EIGRP by itself can make use of the SOO value, but EIGRP cannot set it, thus on the CE-CE link you can never set any SOO values. SOO is a BGP extended community, thus it can be set only by BGP for VPNV4 prefixes.



  • That makes sense when looking at what I am seeing. That you all for the help. 

  • Due to the cost-community bespath attribute, eigrp soo should not need to be configured manually, it should just work. Am I wrong?

  • Hi,

    EIGRP SOO prevents only against routing loops which can happen in very specific corner cases, and you need to set it manually; at some point in the IOS/IOS-XR code, cisco added the BGP cost-comunity which protects against both routing loops and sub-optimal routing, and this is automatically set by the routers; so SOO is obsolete/legacy now.

    I don't understand what do you mean by "it should just work".



    Due to the cost-community bespath attribute, eigrp soo should not need to be configured manually, it should just work. Am I wrong?


  • Hi Christian,


    I mean what you are saying - since it is now automatically set by the routers, we do not need to configure it manually with maps etc. The protection against loops when having EIGRP as PE-CE protocol is now built-in. 

    Whereas for PE-CE BGP with multihomed sites with usage of as-override or allowas-in we must still manually configure BGP SoO. 


Sign In or Register to comment.