- Bird-users - Mailing Lists

Re: Recommended way to shutdown a working BGP session -- ordered bgp session stop -- bgp session shutdown
by Francis Brosnan Blázquez 17 Dec '18

17 Dec '18

Hello Kurt. By your solution, would it be possible to announce no prefix over the upstream that you want to shutdown (export none;)? About "local preference", I thought it is only applicable for IBGP not for EBGP but it seems it can now be used for eBGP neighbors (as described by allow bgp_local_pref switch at bird BGP doc). We will keep you updated with our results so others can take advantage of them too. Best Regards. > You could announce more specific routes on the upstream that you want > to keep and make sure you're outgoing traffic goes via the upstream > you want to keep by example higher local pref. > > > > kurt > > > > Op vr 7 dec. 2018 22:53 schreef Francis Brosnan Blázquez > <francis.brosnan(a)aspl.es: > > Hello. > > We are using bird with several upstream providers, all of them > with a > share of traffic. > > We are in the process of shutting down one of them but we are > unsure > how to proceed to minimize loss of traffic. > > We have been reading and looking for general recommendations > but it is > not clear (besides using graceful shutdown which is not > supported by > the upstream we want to shutdown). > > We have been looking at mailing list but we haven't found > anything > treating this matter. > > So far, solutions we have come up are: > > 1) Use AS-path prepend to increase metric on the uptstream to > be > shutted down and once nearly no traffic comes in through that > link, shutdown > BGP and unplug. Something like: > > export filter > { > > if source = RTS_STATIC then { # Export only static > routes > # Assign our > community > > bgp_community.add((65000,64501)); > # Artificially increase path > length > # by advertising local AS number > twice > if bgp_path ~ [= 65000 =] > then > bgp_path.prepend(65000); > bgp_path.prepend(65000); > > accept; > } > > reject; > }; > > 2) Another solution is to just shutdown BGP session but leave > upstream > connected and configured (so outdated routers we still reach > us...). > > 3) And the obvious, just shutdown BGP session and unplug the > cable. > > It would be great to know your opinion and what's the > recommended way > to proceed. > > What do you think? > > Many thanks > Best Regards. > > > > > -- Francis Brosnan Blázquez - ASPL http://www.asplhosting.com/ http://www.aspl.es/ https://twitter.com/aspl_es https://twitter.com/asplhosting https://twitter.com/francisbrosnanb https://es.linkedin.com/in/francis-brosnan-blázquez-1353a218 91 134 14 22 - 91 134 14 45 - 91 116 07 57 Av. Juan Carlos I 13, 2ºC, Torre Garena 28806 - Alcalá de Henares (España) AVISO LEGAL En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, le informamos de que sus datos de carácter personal, recogidos de fuentes accesibles al público o datos que usted nos ha facilitado previamente, proceden de bases de datos propiedad de Advanced Software Production Line, S.L. (ASPL). ASPL garantiza que los datos serán tratados con la finalidad de mantener las oportunas relaciones comerciales o promocionales con usted o la entidad que usted representa. No obstante, usted puede ejercitar sus derechos de acceso, rectificación, cancelación y oposición dispuestos en la mencionada Ley Orgánica, notificándolo por escrito a ASPL - Protección Datos, Av. Juan Carlos I 13, 2ºC, Alcalá de Henares (Madrid).

2 2

Re: Recommended way to shutdown a working BGP session -- ordered bgp session stop -- bgp session shutdown
by Francis Brosnan Blázquez 17 Dec '18

17 Dec '18

Hello Michael. Just report our results. After removing BGP upstream configuration (commented out), run "config", our traffic was instantly directed to the rest of BGP sessions. We didn't lose any traffic (at least noticeable) during the transition. This confirms your response and Ondrej's: it takes seconds or at most a few minutes (not hours). Also confirm condition change you are describing: most of the traffic was directed to a less preferable BGP session because it has same As-path length and bigger uptime. We will have to increase as-path length by prepending (export filter { ... bgp_path.prepend .. } at the BGP session we want to have with less weight). Given these results, it is not necessary to increase AS-path length before shutting down the session: it is already fast and smooth. Best Regards. El mar, 11-12-2018 a las 17:05 +0600, Michael Rack escribió: > Correct, it will remove routes faster. This is because of the logic > behind BGP. > > > If you add a new upstream peer / transit peer the new route will not > be in use if the as-path is the same as the old one. Traffic is > directed to that port wich session that have longer uptime. > > > The routes gets active when a condition will change. > > > But back to your question in timeouting a BGP Session. When a BGP > Session will timeoute, your neighbor will send withdraws to his > neighbors. So after 20secs no neighbour will see the route to your > shutted down interface anymore. > > > Correct: Shutdown Inferace after traffic disappears. > > > > > > Am Mo., 10. Dez. 2018, 15:33 hat Francis Brosnan Blázquez > <francis.brosnan(a)aspl.es> geschrieben: > > Hello Michael. > > Thanks for the info; very useful. > > Considering this, could we say BGP is faster removing routes > when > session is lost/closed/shut down than when they are added? > > Even though you start receiving traffic right away you setup a > BGP > session, we have seen it takes hours (even days) to fully > propagate new > BGP upstream we added in the past. > > Did you find this behavior too? > > Thanks Michael. > Best Regards. > > > PD: Just to clarify point 2) Another solution is to just > shutdown BGP > session but leave upstream connected and configured (so > outdated > routers we still reach us...) AND unplug the cable after > traffic disappears. > > > > We are using option number 2. > > > > > > After 600 seconds, all routes via the shutted down peer will > > get invalid. > > > > > > So just wait 10 Minutes and your inbound traffic should > > stop. > > > > > > ......... > > > > > > But there was a another thread with a feature request to > > send withdraws to your peer, so you can immediatley shutdown > > your network interface after shutting down the bgp session. > > > > > > > > Am Sa., 8. Dez. 2018, 04:03 hat Francis Brosnan Blázquez > > <francis.brosnan(a)aspl.es> geschrieben: > > > > > > Hello. > > > > We are using bird with several upstream providers, > > all of them with a > > share of traffic. > > > > We are in the process of shutting down one of them > > but we are unsure > > how to proceed to minimize loss of traffic. > > > > We have been reading and looking for general > > recommendations but it is > > not clear (besides using graceful shutdown which is > > not supported by > > the upstream we want to shutdown). > > > > We have been looking at mailing list but we haven't > > found anything > > treating this matter. > > > > So far, solutions we have come up are: > > > > 1) Use AS-path prepend to increase metric on the > > uptstream to be > > shutted down and once nearly no traffic comes in > > through that link, shutdown > > BGP and unplug. Something like: > > > > export filter > > { > > > > if source = RTS_STATIC then { # Export > > only static > > routes > > # Assign our > > community > > > > bgp_community.add((65000,64501)); > > # Artificially increase path > > length > > # by advertising local AS number > > twice > > if bgp_path ~ [= 65000 =] > > then > > bgp_path.prepend(65000); > > bgp_path.prepend(65000); > > > > accept; > > } > > > > reject; > > }; > > > > 2) Another solution is to just shutdown BGP session > > but leave upstream > > connected and configured (so outdated routers we > > still reach us...). > > > > 3) And the obvious, just shutdown BGP session and > > unplug the cable. > > > > It would be great to know your opinion and what's > > the recommended way > > to proceed. > > > > What do you think? > > > > Many thanks > > Best Regards. > > > > > > > > > > > > > > -- > Francis Brosnan Blázquez - ASPL > http://www.asplhosting.com/ > http://www.aspl.es/ > https://twitter.com/aspl_es > https://twitter.com/asplhosting > https://twitter.com/francisbrosnanb > https://es.linkedin.com/in/francis-brosnan-blázquez-1353a218 > > 91 134 14 22 - 91 134 14 45 - 91 116 07 57 > Av. Juan Carlos I 13, 2ºC, Torre Garena > 28806 - Alcalá de Henares (España) > > AVISO LEGAL > > En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de > diciembre, de Protección de Datos de Carácter Personal, le informamos de > que sus datos de carácter personal, recogidos de fuentes accesibles al > público o datos que usted nos ha facilitado previamente, proceden de > bases de datos propiedad de Advanced Software Production Line, S.L. > (ASPL). > > ASPL garantiza que los datos serán tratados con la finalidad de mantener > las oportunas relaciones comerciales o promocionales con usted o la > entidad que usted representa. No obstante, usted puede ejercitar sus > derechos de acceso, rectificación, cancelación y oposición dispuestos en > la mencionada Ley Orgánica, notificándolo por escrito a ASPL - > Protección Datos, Av. Juan Carlos I 13, 2ºC, Alcalá de Henares > (Madrid) -- Francis Brosnan Blázquez - ASPL http://www.asplhosting.com/ http://www.aspl.es/ https://twitter.com/aspl_es https://twitter.com/asplhosting https://twitter.com/francisbrosnanb https://es.linkedin.com/in/francis-brosnan-blázquez-1353a218 91 134 14 22 - 91 134 14 45 - 91 116 07 57 Av. Juan Carlos I 13, 2ºC, Torre Garena 28806 - Alcalá de Henares (España) AVISO LEGAL En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, le informamos de que sus datos de carácter personal, recogidos de fuentes accesibles al público o datos que usted nos ha facilitado previamente, proceden de bases de datos propiedad de Advanced Software Production Line, S.L. (ASPL). ASPL garantiza que los datos serán tratados con la finalidad de mantener las oportunas relaciones comerciales o promocionales con usted o la entidad que usted representa. No obstante, usted puede ejercitar sus derechos de acceso, rectificación, cancelación y oposición dispuestos en la mencionada Ley Orgánica, notificándolo por escrito a ASPL - Protección Datos, Av. Juan Carlos I 13, 2ºC, Alcalá de Henares (Madrid).

1 0

Route server on a Bird2.0.2
by Noémie Clémençon 15 Dec '18

15 Dec '18

Hi all, We are using Bird v2.0.2 as a route-server, and I have a question about the use of i-BGP sessions on a Bird RS. We have the following topology : 2 RS (RS1 and RS2) are connected to several peers, and some of those peers are connected to only one RS. In order to get the same amount of prefixes on both RS, a i-BGP session was created between RS1 and RS2. i-BGP RS1 ----------------- RS2 | | | | Peer1 Peer2 This topology was working really well between a Bird 1.6.3 and a Cisco ASR, and we were able to announce the prefixes without the RS AS in the AS-Path and with the proper next-hop regardless of from where the prefixes were learnt (RS1 or RS2). To clarify, if Peer1 was peering with RS1, and learning the prefixes of someone, Peer2, who was peering exclusively with RS2, Peer1 would get the prefixes with the as path starting with the AS of peer2 and the next-hop would be peer2 router IP. We wanted to use the same topology with a Bird 2.0.2 in place of a ASR, but it seems to be treating i-BGP prefixes differently. With a bird 2.0.2, Peer1 is receiving the prefixes from Peer2 however the prefixes are announced with the RS AS in the AS path and the next hop is the RS1 IP, hence the prefixes were unusable by Peer1. We are using the following tweak to correct the next hop : the use of 'direct' and 'gateway direct' has corrected the next hop IP. Below an example of the configuration we used. We still haven't found a solution for the AS path. protocol bgp RS1 { local as 65001; neighbor 192.168.2.1 as 65001; ... direct; ipv4 { import ...; gateway direct; export ...; }; } Since we never noticed this problem for bird 1.6.3, is this a different behavior for Bird 2.0.2 ? Or is there a better way to have the intended announcements on both RS ? I-BGP sessions between RS are really handy in case of failure, and we would like to keep this topology. Kind regards, Noémie

4 8

[PATCH] bird: treat former classe addresses as valid addresses
by Dave Taht 13 Dec '18

13 Dec '18

replying via gmail as taht.net's server mandates starttls and someone doesn't have that enabled for outgoing mail. >On Tue, Dec 11, 2018 at 03:26:08PM -0800, Dave Taht wrote: >> There is no reason to disallow the former class e address >> space, except in a bogon file. >Hi >> static inline int ip4_is_unicast(ip4_addr a) >> -{ return _I(a) < 0xe0000000; } >> +{ return _I(a) < 0xe0000000 || (_I(a) >= 0xf0000000 && _I(a) != 0xffffffff); } >Well, this summarises the reason why to disallow former class E address >space. If these addresses are not defined / reserved for future use, how >can we say that they are unicast and not multicast or for some complete >different but not yet defined purpose? As best as we can tell they have been treated as unicast by linux, freebsd, and OSX since at least about 2010, perhaps longer. >IMHO first should IETF redefine it as a regular unicast range, then >routing software should change its behavior. Please correct me if >that already happened. The deployment is all unicast in the 240/4 range. Try it - in linux: ip addr add 255.255.255.254/24 dev whatever Over the last few months we've tested apple IOS, OSX, Freebsd, most modern linux linuxes use the iproute suite per above, and just work, and those few that don't, like openwrt, use an ifconfig ioctl that we also have a few line patch awaiting approval to the linux kernel. The original patch in this series goes back to 2008 (https://lkml.org/lkml/2008/1/7/370 ). Multiple switches, APs, and devices "just work". Only windows, currently cannot route to or accept a 240/4 address, and we're hoping to address that. document in progress on that... So even if the IETF wanted to change the unicast interpretation, it would be unwise. as for how these addresses could be used, well, that's a subject for a new RFC (pending) but the technical feasibility appears bright at the moment. We (john gilmore, rob landley, others) behind this are trying to gain approval for a worldwide test opening up a few of these ranges, especially the "hard" one, 255/8, for analysis. >OTOH, perhaps we could allow all possible routes regardless of address >classification (even for prefixes from multicast range) in routing table. That's what the babeld patch does, currently. Under test. Many bogon files also filter out this range. one line changed, and voila! >OSes allow that and sometimes even uses that (e.g. route for multicast range in regular unicast table is used for selection of default multcast interface on clients). Thank you for pointing this out. We have been using things like searchcode for all the public sources in the world, and thus far... all but the IN_MULTICAST macros are essentially unused in userspace. I'll go look harder for other potential multicast/unicast conflicts like that, but the linux kernel, at least, looked clean. ... only the main routing daemons had issues. http://www.taht.net/classe/ has the tiny patch sets for everything so far We're in the FRR process over here: https://github.com/FRRouting/frr/pull/3462 does anyone still use xorp? -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740

1 0

[PATCH] bird: treat former classe addresses as valid addresses
by Dave Taht 12 Dec '18

12 Dec '18

There is no reason to disallow the former class e address space, except in a bogon file. --- lib/ip.c | 8 ++++++-- lib/ip.h | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/lib/ip.c b/lib/ip.c index 2050d19e..022c7d74 100644 --- a/lib/ip.c +++ b/lib/ip.c @@ -100,8 +100,12 @@ ip4_classify(ip4_addr ad) if (b >= 0xe0 && b <= 0xef) return IADDR_MULTICAST | SCOPE_UNIVERSE; - if (a == 0xffffffff) - return IADDR_BROADCAST | SCOPE_LINK; + if (b >= 0xf0) + if(a == 0xffffffff) { + return IADDR_BROADCAST | SCOPE_LINK; + } else { + return IADDR_HOST | SCOPE_UNIVERSE; + } return IADDR_INVALID; } diff --git a/lib/ip.h b/lib/ip.h index 4fbe4407..2d1b4cff 100644 --- a/lib/ip.h +++ b/lib/ip.h @@ -312,7 +312,7 @@ static inline int ip6_is_v4mapped(ip6_addr a) #endif static inline int ip4_is_unicast(ip4_addr a) -{ return _I(a) < 0xe0000000; } +{ return _I(a) < 0xe0000000 || (_I(a) >= 0xf0000000 && _I(a) != 0xffffffff); } static inline int ipa_classify_net(ip_addr a) { return ipa_zero2(a) ? (IADDR_HOST | SCOPE_UNIVERSE) : ipa_classify(a); } -- 2.17.1

2 1

Problems while experimenting some new features in BGP
by Mattia Milani 12 Dec '18

12 Dec '18

Hello all, I'm experimenting some new features in BGP but I'm stuck in a problem that I can't reach the solution. I want to trigger a Route Refresh every time after an update some constraints are violated. I thought that the right place to do that is inside this function: static void bgp_rx_update(struct bgp_conn *conn, byte *pkt, uint len) { .... if (Constraints are violated){ Trigger Route Refresh } return; } This was my idea, first of all, do you think this is the right place to trigger the route reresh? After that, I was trying to trigger the route refresh calling this function: void bgp_feed_begin(struct channel *C, int initial) But I didn't get the result I want, the node in the log wrote: Sending BEGIN-OF-RR But nothing else happened, so what is the right way to trigger a Route refresh? Thanks a lot for the help, I know that is a strange request but it could help a lot my experiments, Mattia

1 0

BIRD 2.0.2 documentation build failure
by Robert Scheck 11 Dec '18

11 Dec '18

Hello, I'm trying to build the documentation of BIRD 2.0.2 on Fedora and RHEL/ CentOS 7 which fails like this: --- snipp --- + /usr/bin/make -j4 -C doc make: Entering directory `/builddir/build/BUILD/bird-2.0.2/doc' make: Leaving directory `/builddir/build/BUILD/bird-2.0.2/doc' make: *** No rule to make target `/tools/progdoc', needed by `prog.sgml'. Stop. --- snapp --- When I decided to replace "$(srcdir)" in doc/Makefile by ".." it goes further, but still fails. Replacing "$(objdir)" by "../obj" and finally replacing "$(doc-srcdir)" by "." leads to the message that bird.sgml has a loop reference (which leads to an empty bird.sgml). And when removing this target, $(o)%.sgml: $(s)%.sgml $(objdir)/.dir-stamp cp $< $@ the documentation build even succeeds. In total that's then this diff: --- snipp --- --- bird-2.0.2/doc/Makefile 2018-01-16 10:46:06.000000000 +0100 +++ bird-2.0.2/doc/Makefile.doc 2018-11-25 16:38:22.988423717 +0100 @@ -1,7 +1,7 @@ # Force rebuilds .PHONY: progspell docs progdocs userdocs -doc-srcdir := $(shell cd $(s) && pwd) +doc-srcdir = . sgml2 := $(doc-srcdir)/sgml2 docs: progdocs userdocs @@ -16,11 +16,8 @@ userdocs: $(o)bird.html $(o)bird.pdf progspell: $(o)prog.spell -$(o)prog.sgml: $(srcdir)/tools/progdoc $(objdir)/.dir-stamp - $(srcdir)/tools/progdoc $(srcdir) $@ - -$(o)%.sgml: $(s)%.sgml $(objdir)/.dir-stamp - cp $< $@ +$(o)prog.sgml: ../tools/progdoc ../obj/.dir-stamp + ../tools/progdoc .. $@ $(o)%.html: $(o)%.sgml cd $(dir $@) && $(sgml2)html $(notdir $<) --- snapp --- Do you have any pointers? Is this a bug in BIRD or is this a Fedora/RHEL build system issue? Regards, Robert

2 5

ospf with bfd ecmp conf
by Alon Dotan 11 Dec '18

11 Dec '18

Hey All, Im trying to configure the folowing topology: lns box (multiple ppp devices that connect and disconnect) -> multiple default gw (gw load balance) the issue is if one of the multiple gw crash I got routing blackhole... Im trying to configurefd to delete dead peers from the osp routing table, this is my conf: debug protocols all; log "/var/log/bird.log" all; router id 10.10.11.10; protocol device { scan time 1; # Scan interfaces every 10 seconds export all; } protocol direct { interface "ppp*"; export all; } protocol kernel { scan time 1; # Scan kernel routing table every 20 seconds export all; # Default is export none import all; kernel table 100; learn; persist; } protocol bfd { interface "eth1" { min rx interval 20 ms; min tx interval 50 ms; idle tx interval 300 ms; }; } protocol ospf MyOSPF { ecmp yes; export filter { if (net ~ 10.10.11.0/24) then reject; accept;}; # export all; import all; merge external; area 0 { interface "eth1" { hello 5; bfd yes; }; }; } protocol static { import all; } routs learned by ospf: [root@lns-testing-01 centos]# ip r show table 100 default proto bird nexthop via 10.10.11.11 dev eth1 weight 1 nexthop via 10.10.11.12 dev eth1 weight 1 [root@lns-testing-01 centos]# bfd status: [root@lns-testing-01 centos]# birdc show bfd sessions BIRD 1.4.5 ready. bfd1: IP address Interface State Since Interval Timeout 10.10.11.11 eth1 Up 08:09:55 0.050 0.250 10.10.11.12 eth1 Down 08:10:41 0.300 0.000 what Im missing? Thanks,

1 0

segfault when adding OSPF virtual link on Bird 1.6.4
by Cybertinus 10 Dec '18

10 Dec '18

Hello everybody, Today I was experimenting with a Bird setup. All the Bird machines are CentOS 7.6 VMs running in Virtualbox on my laptop. When I add an OSPF virtual link to hook up two area 0's together I get a segfault of Bird 1.6.4 itself. All the links between the VMs are defined as "Internal Network" links. Each connection between routers got it's own internal network, so there should be no overlap between those connections. Steps to reproduce: 1. Create a bird.conf with the following contents specified in the attached bird.conf 2. Start Bird 3. Add the following line to the area 1 config: virtual link 2.2.2.2; 4. Run `birdc configure` 5. Observe the following error in your syslog: Dec 8 21:01:35 r3 kernel: bird[3469]: segfault at 32 ip 0000000000429fe0 sp 00007fff599d3350 error 4 in bird[400000+73 I've ran Bird 1.6.4 in a gdb session with the debug symbols installed and I created a stack trace after the crash. This gives the output which can be found in the attached gdb.txt. What is interesting to note is that the segfault only occurs when I reconfigure Bird. I can start it just fine right after the crash and the OSPF sessions come back online and everything. I hope this gives some useful information about what is happening. If you need any more information please don't hesitate to ask. It is a test network, so I can tell you absolutely everything about it, nothing is a company secret or something like that :). Kind regards, Cybertinus

2 3

FLAPPING PEER
by Rwakagabo Janvier 10 Dec '18

10 Dec '18

Hello bird user I am using bird 1.4.0 version on route server (RS) to peer on IXP players, One of the peer is flapping with this error Can you help to understand the cause. Regards, Janvier R.

1 0