minor bird crash

[Ondrej Zajicek]

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 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20100319/73ebca16/attachment-0001.asc>