Updating export filter for OSPF
Hi, I was wondering if it's somehow possible to update the export filter for an OSPF instance without having to completely restart that OSPF instance. From the tests I've performed, the only way to have bird pick up the new export filter, is to restart the protocol in question. The downside of this is that that leads to a downtime of several seconds before OSPF gets into a fully established state again. Am I missing something or is restarting a protocol the only way to for a protocol to pick up filter changes? I guess the same would apply to, the much more common, BGP import/export filters. Regards, Ruben Laban
On Monday 24 October 2011 at 12:12 (CET), Ruben Laban wrote:
I was wondering if it's somehow possible to update the export filter for an OSPF instance without having to completely restart that OSPF instance. From the tests I've performed, the only way to have bird pick up the new export filter, is to restart the protocol in question. The downside of this is that that leads to a downtime of several seconds before OSPF gets into a fully established state again. Am I missing something or is restarting a protocol the only way to for a protocol to pick up filter changes? I guess the same would apply to, the much more common, BGP import/export filters.
Speaking of which, lines like these: Routes: 374804 imported, 3 exported, 374801 preferred are a bit "misleading". As my peer claims to only 2 routes being advertized by me. Being able to "refresh" those advertizements without completely restarting the respective BGP session would be nice. Regards, Ruben Laban
On Mon, Oct 24, 2011 at 03:15:14PM +0200, Ruben Laban wrote:
Speaking of which, lines like these:
Routes: 374804 imported, 3 exported, 374801 preferred
are a bit "misleading". As my peer claims to only 2 routes being advertized by me. Being able to "refresh" those advertizements without completely restarting the respective BGP session would be nice.
Yes, export counter is unreliable under some circumstances (esp. when 'configure soft' is used). You can 'refresh' advertisements using 'reload' command. -- 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."
On Mon, Oct 24, 2011 at 12:12:38PM +0200, Ruben Laban wrote:
Hi,
I was wondering if it's somehow possible to update the export filter for an OSPF instance without having to completely restart that OSPF instance. From the tests I've performed, the only way to have bird pick up the new export filter, is to restart the protocol in question.
That is strange, just 'configure' should be enough (since ~ early 1.2.x ersions). Works for me (just tested on 1.3.1).
I guess the same would apply to, the much more common, BGP import/export filters.
On BGP it depends if neighbor supports route refresh feature. If so, just 'configure' should be enough. Otherwise it is impossible to change an import filter without session reset (an export filter is OK). -- 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."
On Monday 24 October 2011 at 15:31 (CET), Ondrej Zajicek wrote:
On Mon, Oct 24, 2011 at 12:12:38PM +0200, Ruben Laban wrote:
I was wondering if it's somehow possible to update the export filter for an OSPF instance without having to completely restart that OSPF instance. From the tests I've performed, the only way to have bird pick up the new export filter, is to restart the protocol in question.
That is strange, just 'configure' should be enough (since ~ early 1.2.x ersions). Works for me (just tested on 1.3.1).
I guess the same would apply to, the much more common, BGP import/export filters.
On BGP it depends if neighbor supports route refresh feature. If so, just 'configure' should be enough. Otherwise it is impossible to change an import filter without session reset (an export filter is OK).
Doh! For some reason it had gotten into my head that "configure" (as opposed to "configure soft") was the sledgehammer appraoch to re-configuring bird (including downtime for any "affected" protocols). Doing just "configure" instead of "configure soft" seems to do the trick just fine indeed based on some quick tests. Thanks for the nudge in the right direction! Regards, Ruben Laban
On Mon, Oct 24, 2011 at 03:27:43PM +0200, Ruben Laban wrote:
On Monday 24 October 2011 at 15:31 (CET), Ondrej Zajicek wrote:
On Mon, Oct 24, 2011 at 12:12:38PM +0200, Ruben Laban wrote:
I was wondering if it's somehow possible to update the export filter for an OSPF instance without having to completely restart that OSPF instance. From the tests I've performed, the only way to have bird pick up the new export filter, is to restart the protocol in question.
That is strange, just 'configure' should be enough (since ~ early 1.2.x ersions). Works for me (just tested on 1.3.1).
I guess the same would apply to, the much more common, BGP import/export filters.
On BGP it depends if neighbor supports route refresh feature. If so, just 'configure' should be enough. Otherwise it is impossible to change an import filter without session reset (an export filter is OK).
Doh! For some reason it had gotten into my head that "configure" (as opposed to "configure soft") was the sledgehammer appraoch to re-configuring bird (including downtime for any "affected" protocols).
Real 'sledgehammer' is restart command. Configure command tries to be gentle, but restart the protocol if necessary (like if BGP import filter is changed and the neighbor does not support route refresh). Configure soft is a variant of configure which ignores filter changes, probably obsolete today (was implemented in times when we does not support filter changes without protocol restarts). -- 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."
On Mon, Oct 24, 2011 at 04:06:29PM +0200, fredrik danerklint wrote:
is changed and the neighbor does not support route refresh). Configure soft is a variant of configure which ignores filter changes, probably
Can you put that description into the client (birdc) for the help command?
With current interactive documentation (available under '?'), i do not see how to squash that to one short sentence. But implementing useful 'help' command is probably a good idea. -- 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."
On Monday 24 October 2011 at 16:18 (CET), Ondrej Zajicek wrote:
Real 'sledgehammer' is restart command. Configure command tries to be gentle, but restart the protocol if necessary (like if BGP import filter is changed and the neighbor does not support route refresh).
Ok, clear. But aren't route refreshes a fundamental part of BGP? Or am I missing/misunderstanding something here? What I don't understand though, when I was just altering null-routes and export filters, a configure did result in a hard clear according to my peer. Are there any other scenarios where configure could lead to a hard clear and not a soft clear? One thing that comes to mind is that I enabled 'next hop self' as well, though I don't see why that'd warrant a hard clear either?
Configure soft is a variant of configure which ignores filter changes, probably obsolete today (was implemented in times when we does not support filter changes without protocol restarts).
This is quite likely what caused my configure=sledgehammer confusion. Regards, Ruben Laban
On Mon, Oct 24, 2011 at 04:38:32PM +0200, Ruben Laban wrote:
On Monday 24 October 2011 at 16:18 (CET), Ondrej Zajicek wrote:
Real 'sledgehammer' is restart command. Configure command tries to be gentle, but restart the protocol if necessary (like if BGP import filter is changed and the neighbor does not support route refresh).
Ok, clear. But aren't route refreshes a fundamental part of BGP? Or am I missing/misunderstanding something here?
No, they are an extension (RFC 2918), but widely implemented.
What I don't understand though, when I was just altering null-routes and export filters, a configure did result in a hard clear according to my peer. Are there any other scenarios where configure could lead to a hard clear and not a soft clear? One thing that comes to mind is that I enabled 'next hop self' as well, though I don't see why that'd warrant a hard clear either?
Proper reconfiguration of BGP sessions is not implemented in BIRD, so changing other parameters (than import/export) of BGP (like 'next hop self') will lead to session restart. -- 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."
On Tuesday 25 October 2011 at 10:13 (CET), Ondrej Zajicek wrote:
On Mon, Oct 24, 2011 at 04:38:32PM +0200, Ruben Laban wrote:
On Monday 24 October 2011 at 16:18 (CET), Ondrej Zajicek wrote:
Real 'sledgehammer' is restart command. Configure command tries to be gentle, but restart the protocol if necessary (like if BGP import filter is changed and the neighbor does not support route refresh).
Ok, clear. But aren't route refreshes a fundamental part of BGP? Or am I missing/misunderstanding something here?
No, they are an extension (RFC 2918), but widely implemented.
Ah, I see. Never really looked deeply into the inner workings of BGP. And a "normal" user shouldn't have to I'd say. Yet, learn something new (or even more) every day ;-)
What I don't understand though, when I was just altering null-routes and export filters, a configure did result in a hard clear according to my peer. Are there any other scenarios where configure could lead to a hard clear and not a soft clear? One thing that comes to mind is that I enabled 'next hop self' as well, though I don't see why that'd warrant a hard clear either?
Proper reconfiguration of BGP sessions is not implemented in BIRD, so changing other parameters (than import/export) of BGP (like 'next hop self') will lead to session restart.
Good to know. On Tuesday 25 October 2011 at 10:22 (CET), Ondrej Zajicek wrote:
On Mon, Oct 24, 2011 at 03:15:14PM +0200, Ruben Laban wrote:
Speaking of which, lines like these:
Routes: 374804 imported, 3 exported, 374801 preferred
are a bit "misleading". As my peer claims to only 2 routes being advertized by me. Being able to "refresh" those advertizements without completely restarting the respective BGP session would be nice.
Yes, export counter is unreliable under some circumstances (esp. when 'configure soft' is used). You can 'refresh' advertisements using 'reload' command.
Again, good to know. I guess it's getting about time I'd create a "cheatsheet" for my co-workers so they won't be "misled" easily by stuff like this. Thanks for all the info/pointers/etc! Regards, Ruben Laban
participants (3)
-
fredrik danerklint -
Ondrej Zajicek -
Ruben Laban