Probably one of the most confusing topics for people studying BGP/MPLS VPNs are EIGRP SoO and Cost communities. Not the concepts themselves, but rather their purpose. Lack of clear documentation makes it hard to understand why and how the specific features are implemented. In this blog post we discuss the BGP Cost community and EIGRP SoO attribute. First, a brief overview of MP-BGP is given along with general concepts of route redistribution in MPLS/BGP VPNs. Next, the problems that arise when using EIGRP in multihomed VPN environment are demonstrated. Lastly, the two specific EIGRP features are described and their use demonstrated. As usual, a reader is assumed to have basic understanding of fundamental L3 VPNs and PE-CE routing concepts. You may download the post in PDF format at the following link: Understanding EIGRP SoO and BGP Cost Community

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

You can leave a response, or trackback from your own site.

19 Responses to “Understanding EIGRP SoO and BGP Cost Community”

  1. DarrellEscola says:

    Quite a comprehensive document – very useful for my SP Written Exam studies.

  2. zeus says:

    ***cking brilliant….i thought I understand this topic inside out but you have to make sure we feel humble and down after reading your blogs :-) thanks so much dude…

  3. Very good explainations Petr, as usual. So the fact that BGP looks at the POI first before any other attributes will make BGP prefer the VPN routes over the IGP routes learned through the backdoor.
    With OSPF, is there a way for the IOS to automatically take care of this problem? I know that we have to manually do it with a Sham-Link.
    I hope that there will be a part 2, because i really want to see how RIP takes care of this problem.

  4. [...] Understanding EIGRP SoO and BGP Cost Community [...]

  5. @Malick

    With OSPF, all BGP-learned route are considered inter-area. Therefore, no matter if you are using Cost community or not, OSPF will always prefer the CE-originated intra-area routes. Therefore, another solution – the sham-link – is required for OSPF.

    Cisco has not automatic support of the Cost community for RIP, and therefore RIP will always prefer the backdoor link over the SP core path.

    • Bruno says:

      Hi Petr,

      >Cisco has not automatic support of the Cost community for RIP, and >therefore RIP will always prefer the backdoor link over the SP core >path.

      Regarding this statement you are stating that when redistributing from RIP do BGP, cisco doesn’t provide support for insertion of the “Cost community”

      Regarding a way of RIP prefering the path trough the MPLS Backbone, I would say.yes… if we manipulate the metric in the link between both CE routers (with offset-list)…do you agree ?


  6. Youssef says:

    Thank you very much for this article.

    I have a question about the last scenario. I labbed your topology and i wonder how can you put ip vrf sitemap between the two CEs since they are not vrf aware?


    • @Youssef

      VRF sitemap has nothing to do with VRF really :) It is probably just bad name for the feature. It applies community tagging/filtering to EIGRP updates, but should always be used with MP-BGP on redistribution, as BGP preserves the community tagging.

  7. Kayoub says:

    Very useful documentation

    thanks Petr for your efforts :)

  8. Hello, Petr. There is an typo error in pdf document on page 15 in paragraph 1. “R1′s query reaches… “. There is should be CE1.

  9. [...] post from Petr which includes the link to free .PDF for this document may be found by clicking here. Thanks Marcel! Tags: ccie, MPLS Download this page as a [...]

  10. Tammy Burley says:

    Brilliant Petr – thanks for cutting to the chase and putting this information into a concise and clear format. Sometimes there’s a tipping point to how many mysteries a candidate can solve and you certainly did us all a HUGE favor with this piece. One more favor to ask. Could you write the doc cd? ;-) I think we would all appreciate your level of clarity!

  11. Hadi says:


    The two new attributes are optional non-transitive and not optional transitive as mention in the document


    2. Multiprotocol Reachable NLRI – MP_REACH_NLRI (Type Code 14):

    This is an optional non-transitive attribute

    3. Multiprotocol Unreachable NLRI – MP_UNREACH_NLRI (Type Code 15):

    This is an optional non-transitive attribute

  12. Snajdan says:

    Hi Petr, when CE1 sends query to CE2, CE2 is having PE2 as successor for prefix (because of BGP Cost Community), so

  13. Snajdan says:

    Hi Petr, when CE1 sends query to CE2, CE2 is having PE2 as successor for prefix (because of BGP Cost Community), so CE2 is passive for prefix Does it immediately reply to CE1 or send query to PE2?

    Thanks for your answer :)

  14. Safy says:

    Can we use admin-distance command on the PE router instead of using Site of Origin?
    If so, how should I do that?


Leave a Reply


CCIE Bloggers