On Fri, Mar 19, 2010 at 01:57:25PM +0100, Arnold Nipper wrote:
and if you do are you clearing the bgp sessions (in bird-speak reloading the protocols)?
good question :-) My impression was that "configure soft" should do the trick, but I'm not sure whether this really is true. Reloading the pipes for instance generates a mssive route update afais. That's definitely not what we want. I have even added "prefer older on;" to the bgp protocol section to make prefixes more stable across the IXP.
Essentially, you have three options what to do after a change in filters: 1) restart a protocol All routes from the protocol are withdrawn from the connected table and will appear later (after restart) If these routes are primary routes in that table, other protocols connected to that table receive two notifications (first about route disappear and later about route appear). 2) reload a protocol All routes are repropagated through the protocol If these repropagations does not change primary route in the connected tables, the event wouldn't be propagated tho other connected protocols. I will write more about it later. 3) do nothing (and have an inconsistent state of propagated routes) If you use 'configure soft' command, BIRD ignore changes in filters and in that case it does nothing. But it is expected that operator restarts or reloads affected protocols. The main reason for 'configure soft' is that BIRD can't decide whether the change in filters is important enough. For example if you found that you have a bug in common 'martians' filter function and you found that one BGP neighour sent you a martian route, then you update the common filter function but you know that you have to restart/reload just that one BGP neighbour. But if you use 'configure', BIRD decides to restart/reload all protocols that use the common filter function. For older (before 1.2.1) versions, 'configure' does not use protocol reload (just a restart [*]), so there was another reason for 'configure soft' (to choose reload instead of restart). [*] or reconfigure, which is used for OSPF and RIP and is unrelated to BGP or pipe.
Documentation says: Changes in filters usually lead to restart of affected protocols. If soft option is used, changes in filters does not cause BIRD to restart affected protocols, therefore already accepted routes (according to old filters) would be still propagated, but new routes would be processed according to the new filters.
However with _our_ current model, we only filter between customer table and master table, accepting everything from customer side. From what I've seen (more precise: meant to have seen) applying new filters does not trigger importing routes to the master table.
Another question: what exactly is reloading a table doing.
There is no such thing like reloading a table - we speak about reloading a protocol. As i wrote eariler, it is essencially repropagating routes through a protocol. There are two subcases - reload-in (used when import filter changes) and reload-out (used when export filter changes): reload-in for BGP protocol - BGP protocol sends route-refresh request and then the other side sends updates for all prefixes. reload-out for BGP protocol - BGP protocol sends updates for all prefixes in connected table (and accepted by export filter). reload-in/out for pipe protocol - all routes from one table are repropagated to the other table. This should not have direct impact on external behavior of route server (just causes some CPU load). In all cases that change a state of some routing table (reload-in for BGP and reload-in/out for a pipe), the repropagation of route might change primary route in that routing table and in that case the change is propagated to other protocols (and might cause sending updates for BGP protocols).
Reloading the pipes for instance generates a mssive route update afais.
That is strange, just reloading a pipe (if there is no real change in export/import) may cause some CPU load, but the primary routes should not change and therefore connected BGP protocols should not send any updates. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."