bird spawning huge amount of BGP traffic
Hi, i am participating in a virtual network which is created for computer enthusiasts to gain knowledge about advanced routing protocols and stuff. It is called the DN42 (http://dn42.net). Currently i am establishing BGP sessions with the help of quagga, but since it is quite bloated for my small setup, i would like to migrate to bird. I have configured bird4 with the example config provided in the DN42 wiki (https://dn42.net/howto/Bird) (sorry about the HTML entities). The result is: Bird populates my routing table with all the correct routes, but spawns very huge amounts of BGP traffic. I ran it overnight accidentally, and it spawned over 70GB traffic on some interfaces, so these particular peers closed their VPN tunnels to me, which is understandable. I have created a minimal config by myself, which has the same result. However, peering with quagga works as expected, with all routes and little traffic. But since i want to go away from quagga, and use bird, i am asking you for advice in this problem. Where is my error, and how can i use bird in the correct way? Additional info: I am using bird on Debian Wheezy Stable, and the virtual connections to my peers are set up with OpenVPN. I use IPv4 only (currently). So i would be thankful for any help or suggestions how to fix the error. Thanks in advance, Simon --- Before printing this email, think if it is really needed.
On Thu, Feb 19, 2015 at 04:55:21PM +0100, Simon Szustkowski wrote:
I have configured bird4 with the example config provided in the DN42 wiki (https://dn42.net/howto/Bird) (sorry about the HTML entities). The result is: Bird populates my routing table with all the correct routes, but spawns very huge amounts of BGP traffic. I ran it overnight accidentally, and it spawned over 70GB traffic on some interfaces, so these particular peers closed their VPN tunnels to me, which is understandable. I have created a minimal config by myself, which has the same result. However, peering with quagga works as expected, with all routes and little traffic.
Can you provide your configuration? Are you sure the large amount of traffic is BGP traffic, and not just a routing loop? You can try to log debug messages, see: http://bird.network.cz/?get_doc&f=bird-3.html#ss3.3 In your case, it's probably a good idea to use this in one of your BGP protocol: debug { packets }; (it may generate quite a lot of messages) Baptiste
On Thu, Feb 19, 2015 at 04:55:21PM +0100, Simon Szustkowski wrote:
Hi,
i am participating in a virtual network which is created for computer enthusiasts to gain knowledge about advanced routing protocols and stuff. It is called the DN42 (http://dn42.net).
Currently i am establishing BGP sessions with the help of quagga, but since it is quite bloated for my small setup, i would like to migrate to bird.
I have configured bird4 with the example config provided in the DN42 wiki (https://dn42.net/howto/Bird) (sorry about the HTML entities). The result is: Bird populates my routing table with all the correct routes, but spawns very huge amounts of BGP traffic. I ran it overnight accidentally, and it spawned over 70GB traffic on some interfaces, so these particular peers closed their VPN tunnels to me, which is understandable. I have created a minimal config by myself, which has the same result. However, peering with quagga works as expected, with all routes and little traffic.
Hi The likely cause of the problem is that some peer flapped by some routes and these were propagated by your router to other neighbors. BIRD does not implement minimal interval (MRAI) to counteract this, Quagga has it (which limits flapping and therefore you don't see the problem here). Solution would be to log routes ( debug protocols { routes }; ) to see which BGP neighbor and which routes caused the problem and either not peer with it or filter problematic routes. -- 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 (3)
-
Baptiste Jonglez -
Ondrej Zajicek -
Simon Szustkowski