[PATCH RFC v2] Preserve BGP attributes from non-BGP protocols

[Matthias Schiffer]

On 05/22/2013 12:36 PM, Ondrej Zajicek wrote:
> On Fri, May 17, 2013 at 04:31:07PM +0200, Matthias Schiffer wrote:
>> There is no reason to overwrite attributes like AS path, next hop, etc. when the
>> route source is not BGP. Preserving them has several advantages:
>>
>>  * no attributes are lost by using opaque pipes
>>  * BGP attributes can by pre-populated in other protocols' import filters
> 
> I agree with the point that BGP should not overwrite BGP attributes from
> foreign routes exported to it. But the current behavior is both
> established and consistent with other protocols (like OSPF, where the
> situation is ever worse), so NACK for current minor releases. I plan to
> do some major changes to attribute behavior to make it more consistent
> and such change will be a part of it.
Yes, I saw that issue as well... so I guess I'll have to use patched
Bird versions till a major release includes this or something similar.

> 
> There is also a question of how BGP attribute on non-BGP route should be
> interpreted by BGP protocol - either like BGP routes, or like non-BGP
> routes with the attribute assigned by BGP export filter. I would prefer
> the second behavior - the difference is in implicit modifications of
> current attributes (like bgp_next_hop), in the first variant it would be
> modified as it is from BGP route, in the second variant it is not
> modified as all (because it is set as a local policy). Therefore if you,
> e.g., originate a static route and export it to a BGP protocol, it
> wouldn't make a difference if you modify BGP attributes in the import
> filter of the static protocol or in the export filter of the BGP protocol.
I think all routes should be handled the same way, without regard for
the source protocol. I'd like the BGP protocol to handle route
attributes which come from other protocols the same way attributes from
BGP protocol instances are handled, my use case is the following config
snippet, which works just like a eBGP peering (okay, I don't handle
things like MED and other attributes that shouldn't be distributed over
eBPG yet, but of course that can be added easily). Without my patch it
works only for routes that come from BGP, but not those from static
protocols and similar.

table ffhl;
table ffhh;
function bgp_peer(int import_as; int export_as) {
        if (!defined(bgp_path)) then bgp_path = +empty+;
        if (bgp_path ~ [= * import_as * =]) then return false;
        bgp_path.prepend(export_as);
        return true;
};
protocol pipe pipe_ffhl_ffhh {
        table ffhl;
        peer table ffhh;
        export where bgp_peer(65044, 65052);
        import where bgp_peer(65054, 65044);
};

> 
> BTW, do you need this because you use opaque pipes? One of my long-term
> plans is to remove support for opaque pipes and replace them with
> transparent pipes (i.e. pipes retaining type and attributes) configured
> to propagate just the best route. Could this 
Nope, I don't use opaque pipes at the moment.

> 
>> As a side effect of moving code from bgp_create_attrs() to bgp_update_attrs(),
>> the BGP protocol now uses the same logic to determine if the "gw" attribute
>> should be used as next hop for routes from BGP sources as for those from other
>> sources. Previously, the "gw" attribute was never for routes from BGP.
> 
> Well, as a side effect the code for NEXT_HOP attribute modification
> becames incomprehensible (altought the original code is also horrible
> from this point of view).
> 
> BTW, is there any non-broken case in which 'gw' attribute is used for
> routes from BGP in your code? I cannot find any.
Me neither, so that case could probably just be removed - I just kept
that else-branch to change as little of the curent behaviour as possible.

I hope my config snippet has made my use case a bit clearer, and I'd
love to have this use case supported by Bird in some way :)

Regards,
Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130523/4abe6bfa/attachment-0001.asc>