- Bird-users - Mailing Lists

Setting different facility parameter for logging
by Jakub Nowacki 06 Jan '19

06 Jan '19

Hi, I'm running BIRD on Arista switch that allows entering bash. What I want to achieve is to have logs from BIRD being integrated into Switch OS. Meaning when BIRD logs a message it will appear in the output of 'show logging' >From switch documentation I know it is possible, but it needs to set a certain "facility" parameter when running C function "openlog" >From BIRD source code for sysdep/unix/log.c: > if (new_syslog_name) > { > current_syslog_name = xstrdup(new_syslog_name); > > *openlog(current_syslog_name, LOG_CONS | LOG_NDELAY, LOG_DAEMON);* } What I need is instead of having LOG_DAEMON I need LOG_LOCAL4 Is it possible to set this via BIRD configuration or only way is to compile from source to achieve this? Perhaps there is another way to achieve that logging behavior? Kind regards -- Kuba

2 1

Trouble with IPv6 and VRFs: Cannot assign requested address
by Ralf Jung 01 Jan '19

01 Jan '19

Hi all, I am playing around with VRFs in our network, and I am having trouble getting bird6 to establish its BGP sessions inside a VRF. Strangely, bird for IPv4 works with pretty much the same configuration. I have attached the full configuration. The (I think) interesting bits are > template bgp ffrl_uplink { > table ffrl; > vrf "vrf_freifunk"; > local as 64899; > import keep filtered; > import filter ebgp_ffrl_import_filter; > export filter ebgp_ffrl_export_filter; > next hop self; > direct; > }; > > protocol bgp ffrl_b_ak from ffrl_uplink { > source address 2a03:2260:0:195::2; > neighbor 2a03:2260:0:195::1 as 201701; > }; In the logs, all I get (with `debug all;` added) is > Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connecting to 2a03:2260:0:195::1 from local address 2a03:2260:0:195::2 > Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Socket error: bind: Cannot assign requested address > Dez 28 13:05:25 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connection closed > Dez 28 13:05:26 gw1.saar.freifunk.net bird6[24900]: ffrl_b_ak: Connect delayed by 5 seconds I tried adding `interface "tun-up-ffrl_b_ak";` (that's the interface which has the address 2a03:2260:0:194::2), to no avail. I also tried adding `interface "vrf_freifunk";`, which made the error messages go away but still no peer is listed in `birdc6 show route table ffrl`. My IPv4 configuration is almost the same, and yet there finding peers works. (Actually routing traffic doesn't work yet, but that may also be a problem with our NAT setup.) Note that I have very little experience with BGP, we use it only in an internal instance for peering with our uplink. >From some googling I found <https://bird.network.cz/pipermail/bird-users/2017-August/011440.html> which recommends adding `direct;`, but I already have that set. This is using bird 1.6.4, Linux 4.18, Debian stable. Any help would be greatly appreciated. Kind regards, Ralf

4 11

Linux 4.20 / incomplete ipv4 addr list / RTM_GETADDR
by Arthur Gautier 31 Dec '18

31 Dec '18

Hello bird users, Today I tried to upgrade one of platform to from linux 4.19 to linux 4.20. I started noticing the bgp protocol could not start after this message: <TRACE> uplink: Waiting for 1.2.3.4 to become my neighbor The neighbor (directly connected on an interface) would never appear to bird (as in show interfaces) because the AF_INET/RTM_GETADDR reply from the kernel looks incomplete. It works fine in v6. The results from kernel are capped to 104 ip address (and we run servers with >700 ip address) on loopback. I confirm this behavour with nlmon / tcpdump / wireshark. Tested with bird v2.0.2 and v1.6.3 (debian stable). I haven't reproduced the behavior elsewhere than bird, but I believe this could prove useful to someone else. -- \o/ Arthur G Gandi.net

2 4

Sync with userspace instead of kernel
by Cody Doucette 29 Dec '18

29 Dec '18

Is there any way in BIRD to sync the routing table directly with userspace instead of the OS kernel? We are managing forwarding tables in a userspace (DPDK) application instead of the kernel and want to avoid duplicating the table in both. I see a possible way of doing this with a patch to set `nl_pid` in nl_send() inside of sysdep/linux/netlink.c. But has anyone used BIRD for this use case before?

3 2

[PATCH] Netlink: fix segfault on debug
by baloo＠gandi.net 28 Dec '18

28 Dec '18

From: Arthur Gautier <baloo(a)gandi.net> When enabling debug on netlink, the message formating will segfault in net_format(). From my understanding %N expects a pointer --- sysdep/linux/netlink.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c index 84591eb2ec488..36dc6f4e7b5f8 100644 --- a/sysdep/linux/netlink.c +++ b/sysdep/linux/netlink.c @@ -953,7 +953,7 @@ nl_parse_addr4(struct ifaddrmsg *i, int scan, int new) DBG("KIF: IF%d(%s): %s IPA %I, flg %x, net %N, brd %I, opp %I\n", ifi->index, ifi->name, new ? "added" : "removed", - ifa.ip, ifa.flags, ifa.prefix, ifa.brd, ifa.opposite); + ifa.ip, ifa.flags, &ifa.prefix, ifa.brd, ifa.opposite); if (new) ifa_update(&ifa); @@ -1045,7 +1045,7 @@ nl_parse_addr6(struct ifaddrmsg *i, int scan, int new) DBG("KIF: IF%d(%s): %s IPA %I, flg %x, net %N, brd %I, opp %I\n", ifi->index, ifi->name, new ? "added" : "removed", - ifa.ip, ifa.flags, ifa.prefix, ifa.brd, ifa.opposite); + ifa.ip, ifa.flags, &ifa.prefix, ifa.brd, ifa.opposite); if (new) ifa_update(&ifa); @@ -1525,7 +1525,7 @@ nl_parse_route(struct nl_parse_state *s, struct nlmsghdr *h) /* Do we know this table? */ p = HASH_FIND(nl_table_map, RTH, i->rtm_family, table_id); if (!p) - SKIP("unknown table %d\n", table); + SKIP("unknown table %d\n", table_id); if (a[RTA_SRC] && (p->p.net_type != NET_IP6_SADR)) SKIP("src prefix for non-SADR channel\n"); -- 2.20.1

2 1

ospf module code structure
by Alon Dotan 18 Dec '18

18 Dec '18

Hey All, can I get some reference to the section ion the code that OSPF make the routing decisions (add, merge, delete routs)? Thanks,

2 2

BGP developer question for implementing future feature
by Mattia Milani 17 Dec '18

17 Dec '18

Hello, I'm implementing a strange feature for a research. Protocol: BGP Bird version: 2.0.1 I would like to send an UPDATE message after received one that didn't update the RT (with some other constraints to avoid continuous UPDATE sending), but I'm stocked. I would like to do it at the end of the function: bgp_rx_update(struct bgp_conn *conn, byte *pkt, uint len) The UPDATE that I have to trigger use the same connection from the one I have received and the same network information, but I don't know how to trigger it. Do you have any suggestion? thanks, Mattia

1 0

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