unnecessary and frequency kernel routing update
bird router got from BGP peer update don't change routing table: 26-04-2013 15:49:55 <TRACE> le2 > added [best] 209.142.140.0/24 via 10.90.90.92 on vlan1 and send unneeded routing update to kernel (old route is same): 26-04-2013 15:49:55 <TRACE> kernel1 < replaced 209.142.140.0/24 via 10.90.90.92 on vlan1
On Fri, Apr 26, 2013 at 05:12:47PM +0400, Slawa Olhovchenkov wrote:
bird router got from BGP peer update don't change routing table: ... and send unneeded routing update to kernel (old route is same): ...
From this BGP peer similar updates got very frequence (50 per second and higher). How to prevent unneeded routing update to kernel?
Hello If the received route update is exactly the same, then it should be ignored and not propagated further, but there is probably some minor change (like in BGP attributes) that forces the propagation. BIRD currently does not support anything that could prevent propagation of frequent updates. For the kernel protocol it could be hacked by removing the code that handles route updates and depending just on periodic routing table scans for BIRD-kernel routing table synchronization. -- 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 Sun, Apr 28, 2013 at 09:17:54PM +0200, Ondrej Zajicek wrote:
On Fri, Apr 26, 2013 at 05:12:47PM +0400, Slawa Olhovchenkov wrote:
bird router got from BGP peer update don't change routing table: ... and send unneeded routing update to kernel (old route is same): ...
From this BGP peer similar updates got very frequence (50 per second and higher). How to prevent unneeded routing update to kernel?
Hello
If the received route update is exactly the same, then it should be ignored and not propagated further, but there is probably some minor change (like in BGP attributes) that forces the propagation.
How I can see in debug log whats chnged?
BIRD currently does not support anything that could prevent propagation of frequent updates.
I thinks this is useful feature.
For the kernel protocol it could be hacked by removing the code that handles route updates and depending just on periodic routing table scans for BIRD-kernel routing table synchronization.
This is bad point. For external BGP update this semi-reasonably, but for OSPF/etc this is unacceptable.
On Mon, Apr 29, 2013 at 10:41:24PM +0400, Slawa Olhovchenkov wrote:
If the received route update is exactly the same, then it should be ignored and not propagated further, but there is probably some minor change (like in BGP attributes) that forces the propagation.
How I can see in debug log whats chnged?
There is no easy way, either you could put print commands to import/export filters for specific route attributes (like bgp_path), or you coud try to catch it interactively by 'show route all'.
BIRD currently does not support anything that could prevent propagation of frequent updates.
I thinks this is useful feature.
Yes, but problematic to implement in the current design.
For the kernel protocol it could be hacked by removing the code that handles route updates and depending just on periodic routing table scans for BIRD-kernel routing table synchronization.
This is bad point. For external BGP update this semi-reasonably, but for OSPF/etc this is unacceptable.
Well, for OSPF such problem cannot happen, as OSPF recalculates routes at most once per second. But it is true that it is a hack. -- 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 Wed, May 01, 2013 at 10:10:35PM +0200, Ondrej Zajicek wrote:
On Mon, Apr 29, 2013 at 10:41:24PM +0400, Slawa Olhovchenkov wrote:
If the received route update is exactly the same, then it should be ignored and not propagated further, but there is probably some minor change (like in BGP attributes) that forces the propagation.
How I can see in debug log whats chnged?
There is no easy way, either you could put print commands to import/export filters for specific route attributes (like bgp_path), or you coud try to catch it interactively by 'show route all'.
BIRD currently does not support anything that could prevent propagation of frequent updates.
I thinks this is useful feature.
Yes, but problematic to implement in the current design.
Why? protocol kernel know about current route. If this route don't changed (same next hop, weight if support, etc) -- don't propagate this update to kernel.
For the kernel protocol it could be hacked by removing the code that handles route updates and depending just on periodic routing table scans for BIRD-kernel routing table synchronization.
This is bad point. For external BGP update this semi-reasonably, but for OSPF/etc this is unacceptable.
Well, for OSPF such problem cannot happen, as OSPF recalculates routes at most once per second.
uhhh. What about support OSPF sub-second timers?
But it is true that it is a hack.
kenel routing update collected from OSPF and BGP together.
On Wed, May 01, 2013 at 11:57:56PM +0400, Slawa Olhovchenkov wrote:
Why? protocol kernel know about current route. If this route don't changed (same next hop, weight if support, etc) -- don't propagate this update to kernel.
I thought about more generic flap damping solution, your suggestion for ignoring irrelevant kernel updates is fine and could be easily done.
Well, for OSPF such problem cannot happen, as OSPF recalculates routes at most once per second.
uhhh. What about support OSPF sub-second timers?
Well, we should move from second-based timers to something more fine-grained. -- 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."
participants (2)
-
Ondrej Zajicek -
Slawa Olhovchenkov