MPLS VPN routes with core IGP costs

[Peter Cresswell]

Hi,

Is there any way to use the IGP cost between PEs, and pass that into the VRF prefixes?

For example:

A branch site has 2x CEs (CE-A & CE-B), each with a link to a different PE (PE-A & PE-B). EBGP is used between CE-PE. IBGP Between CE-A & CE-B. CE-C is also connected to PE-B with EBGP.

Without any manual intervention, the link from CE-A to PE-A and the link from CE-B to PE-B would be equal cost away. In reality it would be preferable (in our case at least) for traffic destined to CE-C to use the CE-B to PE-B link, because it would result in a shorter path in the core.

I have been looking for a way to use the IGP metric associated with the VRF route next hop. Ideally, I would like to have the option to copy the IGP cost to next hope into the VRF prefix's MED field... or if you're already using MED as a metric then perhaps the option to ADD the IGP cost to next hope to the existing MED value. I was hoping you would be able to do this with an Import Map on the VRF but I can't see a way of acheiving this.

Is there another way to get this result?

Thanks,

Peter

[Giuseppe Larosa]

Hello Peter,

on PE router connected to CE-C (PE-C) you could use a route-map applied inbound in VPNv4 address family to match BGP next-hop to be PE-B and you could increase the local preference of that specific VPNv4 routes so that those are installed in importing in local VRF.

to be more specific you can match on route target extended community and on BGP next-hop and you should rise local-preference inbound.

This has the advantage of providing limited impact.

To be honest lowest IGP metric to BGP next-hop should already make PE-B the preferred path on PE-C, unless PE-A is sending out with higher local preference.

For this reason you cannot find a a way to copy core IGP metric to VPNv4 MED it is not necessary.

Of course PE-A and PE-B have to use different RDs as commonly done for multihomed VRF sites.

Hope to help

Giuseppe

[Peter Cresswell]

Hi Giuseppe

Thanks very much for your response but I think perhaps I did not explain my question correctly...

What I was trying to acheive was to influence the rouitng at the branch (CE level with the use of MED), rather than at the PE VRF as you have described with Local Preference.

I would like the branch AS (consisting of CE-A & CE-B) to choose the link between CE-B - PE-B to get to CE-C's networks, because it is directly connected or has an IGP cost of 0.

I'm aware I can do this on CE-B by identifying the prefixes from that AS and applying a route-map on CE-B, but I was hoping there was a solution that would be more automatic and less admin overhead by being able to copy the IGP cost into the BGP MED field, as this would then be sent to the CE-B. The prefix sent from PE-A to CE-A would have a higher IGP cost and so would send a higher MED. I hope what I'm trying to explain makes sense.

If this is not possible (I can't find any reference to such a feature...) then are you aware of any other feature that would result in similar behaviour withou having to manually identify prefixes with route maps? The best I can come up with so far is to tag routes into each PE with a community and use a route-map outbound on PE to CE to add a higher MED value to prefixes that do not contain this same community... Or perhaps this can be done with the SOO attribute. The trouble with this method is it only works for PEs with directly connected CEs. It would be nice to leverage the information in the IGP routing table...

Thanks,

Peter

[Giuseppe Larosa]

Hello Peter,

sorry I could have misunderstood you, however provider IGP costs should not be exposed to customer for several reasons (the customer could detect failures in the SP network for example) it is not desirable for political reasons.

>>If this is not possible (I can't find any reference to such a feature...) then are you aware of any other feature that would result in similar behaviour withou having to manually identify prefixes with route maps? The best I can come up with so far is to tag routes into each PE with a community and use a route-map outbound on PE to CE to add a higher MED value to prefixes that do not contain this same community... Or perhaps this can be done with the SOO attribute. The trouble with this method is it only works for PEs with directly connected CEs. It would be nice to leverage the information in the IGP routing table...

using standard BGP communities as a way to tag  routes looks like feasible

SOO is a BGP extended community and should not be exchanged with CE nodes but used to assign a site-id to routes of multihomed VRF sites in order Pe-y to know that Pe-x's routes are related to the same site (loop avoidance)

Hope to help

Giuseppe

[Peter Cresswell]

Hi Giuseppe,

I am looking at an Enterprise MPLS network rather than a service provider MPLS network so we wouldn't have the requirement to hide IGP changes etc, but I can see your point and understand how this would be an issue to an SP.

Thanks again for your help.

Peter