EIGRP SoO and cost-community

Unanswered Question
May 31st, 2010


In above scenrio, if cost community is not configured PE1-AS1 will  receive two routes for network (from site-2) and will prefer MP-iBGP route since MPLS VPN does not add any  delay or bandwidth limitation.

this issue can also be solved with the usage of SoO on PE1-AS1 and PE2-AS1, so we dont need cost community....

where do we need implementation of cost community

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Giuseppe Larosa Mon, 05/31/2010 - 13:26

Hello Mukarram,

the network diagram suggests that the only multihomed VRF site is site 3 including CE3-A, CE-4A with VRF access links to PE1-AS1 and PE2-AS2

VRF sites 1 and 2 are shown as distinct sites that should have different route distinghisher but importing and exporting the same route target value.

In some ways site3 implements a sort of backdoor but Site of origin applies to locally generated routes and only for site3

in importing routes for VRF site1 PE1-AS1 can still see two routes one coming from MP-iBGP and one coming from itself and exported from VRF site3

cost community is used to deal with backdoors a correct definition of backdoor is an horizontal link connecting two VRF sites without going through the SP network.

In this the picture is misleading and can create confusion, it would be a backdoor if there are only two VRF sites

site 1B including CE1-A and CE3-A and site2B including CE4-A and CE2-A, in this case there would be a true backdoor.



Hope to help


Mukarram Jah Raheel Tue, 06/01/2010 - 01:44

hi giuslar,

i will ponder over ur explanation later regarding cc and soo, but i have another confusion....

following are my assumptions...

routing loop is possible in following directions.

  • A route received by a      multihomed site from the backbone through one link can be forwarded back      to the backbone via the other link.
  • A route originated in a      multihomed site and sent to the backbone through one link can come back      through the other link.

this means DN-bit and SoO prevents routing loops in two different directions...



     for first case we use DN-bit in ospf

     for second case we use SoO

lets take the routing protolcols to fit in above scenrios:

OSPF : for first case : DN-bit will be used

            for second case : SoO is not recommended for use with OSPF, than which mechanism will prevent routing loop ...

BGP :   for first case : a PE that receives a route and has its own AS# number in the update will not accept such route. AS-Path list preventing loop

            for second case: SoO solves the problem

what about routing loops with EIGRP / RIP / Static and connected routes.... how is the DN-bit mechanism incorporated in them and do we need SoO with them


This Discussion