Feature request? Setting bgp_med to IGP metric

Keenan Tims ktims at gotroot.ca
Thu Apr 21 02:51:35 CEST 2016


Hi all,

I am working today to try to have BIRD propagate my calculated IGP  
metric to an eBGP peer via MED. This is implemented in commercial  
routers typically with a flag in the BGP configuration (ie. on JunOS  
you set 'metric-out igp' in the peer configuration), which will  
propagate to eBGP the calculated IGP metric to the BGP next-hop as MED  
MED. This allows MED to update dynamically based on changes to the  
internal path to that exit, and be automatically calculated by the IGP  
SPF algorithm, assuming you have set your link costs appropriately.

My network uses OSPF to propagate interface and loopback routes only,  
and iBGP for all 'real' routes. While there is a full mesh in iBGP,  
obviously not all nodes are directly connected, so OSPF costs are used  
to determine the path to the destination using 'gateway recursive'.  
The IGP cost may change if e.g. a node goes down, and I would like to  
facilitate eBGP peers moving their traffic to the optimal node in such  
cases, as well as leveraging the IGP data to automatically use the  
correct entry point in the normal case as well.

Is there a way to do this in BIRD? I tried a few different parameters  
that might contain this information, but none were set in an eBGP  
export filter (igp_metric, preference, ospf_metric1).

The only solution I could come up with, even for the normal case, was  
using a community for 'route learned at', but this requires every  
router's configuration to include the path cost to every other router,  
which quickly becomes cumbersome to maintain as the network grows.

I think the ideal solution would be to expose the IGP cost in a new  
attribute (or maybe use igp_metric as it doesn't seem to be set), such  
that a filter could work with it to set an appropriate bgp_med.  
Internally it's obviously available, since birdc shows it as part of  
the preference for BGP routes. I guess the difficulty would be making  
sure changes propagate through eBGP peerings. Alternatively, a knob  
could be provided in the peer configuration, perhaps as a special  
setting for default bgp_med. Or both :).

Keenan Tims
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: PGP Digital Signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160421/c0b3d12f/attachment.asc>


More information about the Bird-users mailing list