Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Multi-VRF - end-to-end metric based on IGP?


I am currently running a Multi-VPM enterprise network.

These VPNs are interconnected through several Inter-VPN gateways (Layer-2 firewalls). Each firewall is facing a PE terminating many VRFs of the network. In order to ensure stateful packet inspection I must make sure that the flows are symmetric. The easiest way to do so is to be able to have an end-to-end metric based on the addition of all IGP metrics along the way.

Our core IGP is OSPF and I run OSPF facing the Inter-VPN gateway.

My problem is that I could not find an easy way to have an end-to-end metric based on IGP metrics from network A attached to VRF Blue on site 1 to network B attached to VRF Red on site 2.

For example each PE facing the Inter-VPN gateway will have the same MP-BGP metric to a particular site. So when I redistribute I loose the information on the metric to reach the end site. I would like to be able somehow to add the next-hop metric to build an end-to-end metric based on IGP...

I hope it makes sense. I have attached a diagram showing the overall setup.

FYI I currently rely on extended communities to manipulate the metric at the Inter-VPN gateway level to try to simulate an end-to-end metric. But this is not scalable and I have route-maps growing at n*n rate...

Many Thanks in advance,



Re: Multi-VRF - end-to-end metric based on IGP?


you need to have a look at the BGP path selection process.

Prefer highest weight (local to router)

• Prefer highest local preference (within AS)

• Prefer route originated by the local router (next hop =

• Prefer shortest AS path

• Prefer lowest origin code (IGP < EGP < incomplete)

• Prefer lowest MED

• Prefer EBGP path over IBGP path

• Prefer the path through the closest IGP neighbor

• Prefer oldest route for EBGP paths

• Prefer the path with the lowest neighbor BGP router ID

So you could use the MED value during redistribution or make sure that you reach the decision step "closest IGP neighbor (i.e. lowest OSPF metric to BGP next hop)"

Now writing all this I do start to understand you problem:

From Boston to "Apps. net" you´d like to prefer NY FW over Herndon, right?

This is indeed tricky, because one of the main ideas of MPLS VPN is to hide the MPLS backbone from the customer. Well more generally speaking: BGP does not include IGP core metrics in updates. This info is not there and so you can´t use it in the VRFs.

The only way I can think of is to manually set the metric based on BGP next hop, when redistributing back into OSPF (external metric) towards the FW. Use OSPF metric then to copy into BGP MED (redistribute FW->PE) and thus transport the info across the FW.

This way you would at least have only one route-map for redistribution with an entry per PE and not n*n.

Hope this helps! PLease rate all posts.

Regards, Martin

New Member

Re: Multi-VRF - end-to-end metric based on IGP?


Thanks for your prompt reply. Your idea is more elegant than my original setup, for sure!

You are right in your assumption that I would like to always use the nearest gateway between two networks (I also have gateways on the west coast or in Europe).

I have started to test it and I have no problem redistributing from MP-BGP to OSPF towards the firewalls. But I am a little bit puzzled on how to manipulate the MED while redistributing FW->PE. Would you be kind enough to show me a test configuration or point me in the right direction?



Re: Multi-VRF - end-to-end metric based on IGP?

Hello Nicolas,

when reditributing an IGP into BGP the MED attribute is automatically set to the IGP metric in Cisco routers. This is why the MED column in the "show ip bgp" output is titled "metric".

So I would assume that you do not need any special treatment during redistribution, you should get the desired behaviour "for free".

Hope this helps! Please rate all posts.

Regards, Martin