bgp soft reconfiguration inbound

[Wolfgang Hennerbichler]

On Nov 20, 2009, at 16:17 , Ondrej Zajicek wrote:

> On Fri, Nov 20, 2009 at 02:19:05PM +0100, Wolfgang Hennerbichler wrote:
>> Fellow Bird Users, 
>> 
>> Now I realized that if I changed the definition for 'allnet' and do a
>> 'configure soft' these routes that are added or removed to 'allnet' are
>> not rejected or added, because it seems that there is no bgp soft
>> reconfiguration taking place (it works if I trigger a soft
>> reconfiguration outbound on the peer router, or if I restart the
>> protocol which causes bgp to flap).
> 
> BGP soft reconfiguration is not implemented. 'configure soft' just
> means 'ignore changes in filters'. So you have to restart the
> protocol or do the filtering in the pipe protocol, like in nix.cz.

hm. I feared this, and I have to say this is not optimal. 

> BTW, why do you want to filter routes in BGP protocols and not in
> pipes? I see just one problem with pipe setting - increase in
> memory consumption if peers would send too many unwanted routes.
> But this might be mitigated by 'route limit' option.

well, this is because our concept differs from the one of nic.cz. We filter at the border, and build pipes to every neighbor who has decided to peer. See this illustration I've made for the last euro-ix: http://tiny.wogri.at/PP (red is the filters, the arcs are the pipes). This means we have no "main" rib. This is good in certain ways: 

1) we have a web-interface for setting up the route-server - every peering coordinator can decide who to peer with by simply clicking around like crazy
2) we don't need to fiddle with bgp communities which pose a big question mark once 4 byte AS-Numbers are here
3) ISP's who have less understanding of the subject just need to peer with the route-servers and click around
4) we save memory by just exporting routes to the ribs that need it. 

there are a couple of more advantages to that concept, the main advantage, and the point that everybody likes is the webinterface and the super-simple setup at client-side. 

So one way I see to solve this problem is to build a second table per peer and apply the filter to a pipe that transports routes from one table to the other, but to be honest, I refuse to do that, this would be a bad and memory-wasting concept. The other workaround would be to bring the protocol down and up again, and rely on the second route-server to stay up and running. This puts unnecessary load on all peering devices and I think this is not great either. The 'route limit' thing is something I am not too fond of either, because I never know in advance how many routes a peer will announce, and this needs constant manual attention. 

> I probably look at the soft reconfiguration in near future, but
> i am not sure how problematic would be to implement it.

I have no idea how complicated this would be, but to be honest if you want bird to compete with other route-servers - and to make me and a whole neighbouring-country including most of the ISP's in that country happy :) - I think you really should consider looking into it. Also given that other Internet Exchanges are considering BIRD as a good alternative I think your effort would soon turn out to be valuable not only to a small country like Austria, but you are on the way to conquer the whole world (well, that's a little exaggerated, but it gives you the idea :))!  
I would really appreciate if you could look into that, and be sure, you're not only doing this for us, many people will use this soon. I am willing to help you testing as good as I can. Let me know what you think! 

Wolfgang

> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."

-- 
www.vix.at | www.aco.net
wh at univie.ac.at | WH844-RIPE
Vienna University Computer Center