March 2022 - Bird-users - Mailing Lists

Can pagination be disabled on the Bird console?
by Adrian Brooks 11 Mar '22

11 Mar '22

Hello, Is it possible to configure the Bird console so that the output isn't interrupted with '-More-' statements please? (similar to the Cisco 'terminal length 0' command) I'm using Expect in a Python script to collect data from Bird, so it would be handy to be able to switch this off (I'm using 2.0.9) Many thanks for your time, Adrian Adrian BROOKS Telecom Networks - Fixed Services Platforms Tel. : +352 2424 2301 adrian.brooks(a)post.lu<mailto:adrian.brooks@post.lu> POST Technologies 20, Rue de Reims L-2417 Luxembourg www.posttechnologies.lu<http://www.posttechnologies.lu/> [logo_technologies(a)2x.png] Ce message et toutes les pièces jointes (ci-après le "message") sont établis à l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. Internet ne permettant pas d'assurer l'intégrité de ce message, POST Luxembourg décline toute responsabilité au titre de ce message, dans l'hypothèse où il aurait été modifié.

5 5

Re: comparing open source BGP stacks performance
by Justin Pietsch 04 Mar '22

04 Mar '22

(added bird-users@ back, I didn't mean to remove them before) Sorry that I missed that you'd already added the pull request. I merged it. we do need a way to specify exabgp vs bird, but that's just another thing to add. I agree about containers and versions. Just haven't had time to think it through carefully. The policy support is what bgperf had before I forked it. I don't use it, I don't know how to usefully test with it. One more feature I'd like to see, yet I'm not sure how to do this > properly – to make the measurement more accurate, the target should not > only run on its own machine, but bgperf with all the testers should also > watch their load, issuing warning when the bgperf suite may be the > bottleneck. This will probably help testing some hardware routers in a > somehow comparable way. > I agree. My best quick hack for this is to make sure that there are extra resources on the CPU when running. That's why bgperf now tracks %idle. As you can probably tell, bgperf isn't a great architecture now, and I'm trying to get useful results as quickly as possible. So much could be done here. thanks a lot! Justin On Tue, Aug 31, 2021 at 2:30 AM Maria Matejka <maria.matejka(a)nic.cz> wrote: > Hello! > > On 8/31/21 1:29 AM, Justin Pietsch wrote: > > I meant to ask if you'd compared exabgp to bird as testers? I'll try to > > compare later if I have some time. > Well, I have no exact numbers, I just implemented the bird tester and it > seems to eat less memory and less time. You could probably run the same > batch first with exabgp testers and then with bird testers, comparing > how much this affects the results. > > > On Mon, Aug 30, 2021 at 4:27 PM Justin Pietsch <jpietsch(a)gmail.com > > <mailto:jpietsch@gmail.com>> wrote: > > > > This is fantastic!!!! Can you submit those changes as PRs to my > > bgperf? I'm working on moving it to a more permanent place. Then we > > can track issues! :) > > Well, yes, the tester exchange is already there pending: > > https://github.com/jopietsch/bgperf/pull/1 > > and it seems that there are two more from somebody else. > > The tester exchange is anyway quite stupid and may need some similar > code to MRT testers instead of what is there now. > > > your suggestion for specifying branches used to work in bgperf, but > > I broke it in trying to get everything working. I moved some of the > > targets to just download prebuilt docker images, which makes it > > harder. Also with batch I'm not sure how to have multiple versions > > of the same container. Just more things to figure out, but that all > > makes sense. > > I think it would be better to have separate containers for different > branches, yet I couldn't figure out how to do that, except for brutal > solutions which were too disgusting to implement. > > Anyway, when BIRD is used as tester, it shouldn't imho change with the > target, which is probably the main reason why I prefer separate > containers for branches. > > One more thing – when running update -c, the container should also pull, > not only checkout, imho. (Haven't had time to fix this yet.) > > > * fixed policy configuration in BIRD (no clue whether it works > with > > other stacks) > > This may need thorough examination first to formally define what the > policies should mean. It would be really stupid to compare route > filtering with different policies in each stack. > > One more feature I'd like to see, yet I'm not sure how to do this > properly – to make the measurement more accurate, the target should not > only run on its own machine, but bgperf with all the testers should also > watch their load, issuing warning when the bgperf suite may be the > bottleneck. This will probably help testing some hardware routers in a > somehow comparable way. > > Maria >

3 2

Bird BFD is not compliant to RFC5881
by Christian Bruns 02 Mar '22

02 Mar '22

Hi all, we experienced issues with non-functional BFD Sessions. Debugging yielded that bird does not use RFC compliant BFD Port ranges. RFC 5881 states: "" The source port MUST be in the range 49152 through 65535. ""; however, the port range is not restricted within bird and thus using arbitrary high ports. Some tier 1 transit providers like "Deutsche Telekom" apply strict filter for BFD and only allow RFC5881 compliant ports, hence the issue. There is a workaround to limit the port range globally at system level (/proc/sys/net/ipv4/ip_local_port_range); this seems to work, but we have the strong feeling that restriction of port range for BFD sessions should happen within bird itself. Kind regards, Christian

4 4

Understanding BIRD log messages
by Jon Langemak 01 Mar '22

01 Mar '22

Im trying to make sure I understand the log messages Im seeing during BGP convergence events. Was hoping someone could validate what the following messages meant... added - A route was received from the peer listed and added to the RIB added [best] - A route was received from the peer listed and added to the RIB and is now the best option in the RIB removed - A route originally received from the peer listed was removed removed [replaced] - Im not clear on what this one actually means ignored - A route was received from the peer listed but ignored. Does ignored in this case mean that it wasn't put in the RIB? If so - does that imply that it was filtered? Is there a list of what all these log messages mean? Also - I assume that the < and > signify direction - that is received or sent but clarification on that would be good as well. Thanks!

2 1