Overlapping IP addresses in ONE VRF

[dtangent]

Assume the following scenario:

Hub A-------PE 1----MPLS VPN -------PE 3----Remote

Hub B-------PE 2----------|

Hub A and Hub B are on the SAME subnet (actually, mirrored IP addresses), and running EIGRP as the PE-CE protocol to two different PEs.

My understanding is that IGP metrics get redistributed into BGP-4 so you can use that as a mechanism for path selection; however, for MBGP, the IGP metric is carried in the extended community attribute. Thus, even if you change the EIGRP metric, both routes will be preceived as equal cost by PE 3.

Given this constraint, what mechanism (if any) can you configure on the PEs (or even CEs) so that routes to the Hub A is more preferred than to Hub B?

Any comments on the following methods?

1. Adjusting weight/local prefernece/whatever on PE3 for those specific routes?

2. Depending on IP addressing scheme, choose to either summarize routes or advertise more specific routes within EIGRP so the two routes are not preceived as "equal"?

3. Will something like BGP cost community work?

[Harold Ritter]

BGP Cost Community works in such a scenario. Please refer to the following document for a good example on how to achieve this:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a00801bbad4.html#wp1064143

Hope this helps,

[dtangent]

Harold,

Assuming that EIGRP is redistributed into BGP on the PE routers without a predefined metrics, wouldn't varying the EIGRP metric on the CE-PE link work auto-magically? BGP will just import the IGP metric and use it for best path selection.

Also, if you do choose to implement cost community, that does not get compared until further down the BGP path selection steps, after weight/local preference/etc tec... right?

[Harold Ritter]

The IGP cost evaluated by BGP is actually the IGP cost from one PE to another, not the IGP metric as it is redistributed in BGP.

By default the BGP cost community is evaluated after the IGP cost comparaison. You can change it to be evaluated before anything else (pre-bestpath instead of IGP).

Hope this helps,