EIGRP SoO and cost-community

Mukarram Jah Raheel · ‎05-31-2010

In above scenrio, if cost community is not configured PE1-AS1 will receive two routes for network 172.16.20.0 (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

Giuseppe Larosa · ‎05-31-2010

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.

see

http://www.cisco.com/en/US/docs/ios/iproute_bgp/configuration/guide/irg_cost_comm_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1054113

Hope to help

Giuseppe

Mukarram Jah Raheel · ‎06-01-2010

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...

So

Solution:

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