May 2017 - Bird-users - Mailing Lists

Re: Import directly connected routes
by Damien Clabaut 09 May '17

09 May '17

Hello again, Is there any way to declare a list of interfaces in a string set or something ? The goal would be to use it in direct protocol, and in pipe protocol (import where ifname ~ list_if1) Regards, On 08/05/17 03:47 PM, Ondrej Zajicek wrote: > On Mon, May 08, 2017 at 03:45:17PM -0400, Damien Clabaut wrote: >> Hello Ondrej, >> >> Thank you for your answer. >> >> I did not manage to do it with "device", but "direct" works: > Yes, that was my mistake. 'direct' is the correct one, > -- Damien Clabaut R&D vRouter ovh.qc.ca

3 3

Re: Import directly connected routes
by Damien Clabaut 08 May '17

08 May '17

Hello Ondrej, Thank you for your answer. I did not manage to do it with "device", but "direct" works: protocol direct direct_numa0 { table numa0; interface "eth4.800", "eth4.801"; } Thanks :) On 08/05/17 03:16 PM, Ondrej Zajicek wrote: > On Mon, May 08, 2017 at 02:51:55PM -0400, Damien Clabaut wrote: >> Hello, >> >> I have an issue with latest stable Bird (1.6.3) on Debian8. >> >> I have a bunch of directly connected networks, with route in main routing >> table: >> >> # ip route show >> default via 10.21.136.126 dev eth0 >> 10.21.136.0/25 dev eth0 proto kernel scope link src 10.21.136.19 >> 192.168.1.0/31 dev eth4.800 proto kernel scope link src 192.168.1.1 >> 192.168.1.2/31 dev eth4.801 proto kernel scope link src 192.168.1.3 >> 192.168.1.4/31 dev eth4.802 proto kernel scope link src 192.168.1.5 >> 192.168.1.6/31 dev eth4.803 proto kernel scope link src 192.168.1.7 > ... > >> But only the default (static) route is imported: >> >> bird> show route table default1 >> 0.0.0.0/0 via 10.21.136.126 on eth0 [kernel_default 20:32:40] * >> (10) >> >> Is there any way I can import them ? > Hello > > Kernel protocol in 'learn' mode does not learn 'native' kernel routes, > just routes added by other daemons/tools (like the default route). > > But 'device' protocol could do what you want. > -- Damien Clabaut R&D vRouter ovh.qc.ca

2 1

Import directly connected routes
by Damien Clabaut 08 May '17

08 May '17

Hello, I have an issue with latest stable Bird (1.6.3) on Debian8. I have a bunch of directly connected networks, with route in main routing table: # ip route show default via 10.21.136.126 dev eth0 10.21.136.0/25 dev eth0 proto kernel scope link src 10.21.136.19 192.168.1.0/31 dev eth4.800 proto kernel scope link src 192.168.1.1 192.168.1.2/31 dev eth4.801 proto kernel scope link src 192.168.1.3 192.168.1.4/31 dev eth4.802 proto kernel scope link src 192.168.1.5 192.168.1.6/31 dev eth4.803 proto kernel scope link src 192.168.1.7 I am trying to import them to bird, using the following configuration: table default1; protocol kernel kernel_default { table default1; learn; device routes yes; persist no; scan time 10; import all; export none; } But only the default (static) route is imported: bird> show route table default1 0.0.0.0/0 via 10.21.136.126 on eth0 [kernel_default 20:32:40] * (10) Is there any way I can import them ? Regards, -- Damien Clabaut R&D vRouter ovh.qc.ca

2 1

Question regarding announcing AS set in the bgp path
by Jae Hyun Park 08 May '17

08 May '17

Hi, I'm a graduate student at UCSD. I was wondering how to announce AS set in the bgp path using BIRD. I could only find an example of prepending an AS, but not AS set in the document. I tried a couple things such as bgp_path.prepend((ASN1, ASN2)) bgp_path.prepend({ASN1, ASN2}) to no avail. If anyone could help out, I would really appreciate it. Thanks. Warm regards, Jae

2 1

"enable route refresh off" question
by Alexander Shikov 08 May '17

08 May '17

Hello! Today I ran in situation where I need to have Route Refresh capability (RFC 2918) to be turned on, while Enhanced Route Refresh capability (RFC 7313) to be turned off. Some customers' routers, when see no "Route Refresh" capability, just drops BGP refresh messages, for example, today's output from customer's router: minotaur@br1-gdr.ki# run show bgp neighbor 193.25.180.255 | match "State|Refresh" Type: External State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Options: <Preference PeerAS Refresh> Peer does not support Refresh capability ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Input messages: Total 7022958 Updates 6696784 Refreshes 0 Octets 467801961 ^^^^^^^^^^^^^^^ I realize I could set "enable route refresh on" to all of customers but I'm afraid to hit a bug described here: http://comments.gmane.org/gmane.network.bird.user/4158 According to docs, "enable route refresh off" disables both of them. So is there a way to work somehow around that ? Thanks in advance! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 http://dtel-ix.net/

2 1

Re: Bird dying on nl_get_reply
by Vincent Bernat 05 May '17

05 May '17

❦ 2 mai 2017 16:47 +0200, Ondrej Zajicek <santiago(a)crfreenet.org> : >> Or maybe we could just ignore the error and wait for >> the next kernel sync to catch up. Or the 8192 value could be configured >> at build-time. What's the best option? > > Well, you could try increase NL_RX_SIZE to say 64k. But the best solution > would be to have a proper error handling in nl_get_reply(). The main > question is why the buffer was full as it is not the buffer that get > async notifications, it just gets responses. On the hundreds BIRD running on our systems for a few months, it's the first occurrence I had. The server doesn't have that many routes (less than a hundred) either (we have servers with far more routes). I'll wait if it happens again. -- 10.0 times 0.1 is hardly ever 1.0. - The Elements of Programming Style (Kernighan & Plauger)

2 2

Version 2.0.0-pre1
by Ondrej Filip 02 May '17

02 May '17

Dear BIRD users, Let me announce a new addition to 2.0.x branch. Please note, 2.0.x will be an _experimental_ branch. We will not guarantee configuration stability etc. And today we release 2.0.0-pre1. So that's experimental version of experimental branch. Keep this in mind and DO NOT USE IT IN PRODUCTION ENVIRONMENT. On the other hand, testers are more than welcome. Please use it and report (either positive or negative)! We will not provide packages for any distribution. Ondrej Version 2.0.0-pre1 (2017-04-29) o Support for MPLS next hops o VPNv4 and VPNv6 network types o BGP with MPLS labels (RFC 3107) o BGP MPLS/VPN support (RFC 4364) o BGP 6PE - IPv6 NLRI over IPv4 MPLS (RFC 4798) o BGP IPv4 NLRI with an IPv6 Next Hop (RFC 5549) o BGP Confederations (RFC 5065) o BGP: Simplify igp table options o BGP: Allow exchanging LOCAL_PREF with eBGP peers o BGP: Allow to specify interface for regular sessions o Babel support restored o Static: Minor overhaul o Netlink: Default kernel metric changed to 32 o Flowspec: Limit tcp mask length to 12 bits o Update of show route command Notes: Definitions of OSPFv2, OSPFv3 and RIP NG protocols now use keywords 'ospf v2', 'ospf v3' and 'rip ng' instead of 'ospf2', 'ospf3' and 'ripng'. Flows and ROAs no longer use phony next hops, so there is no need to use 'drop' or 'unreachable' in their static route definitions. See doc/bird.conf.example2 for configuration examples.

4 4

Bird dying on nl_get_reply
by Vincent Bernat 02 May '17

02 May '17

Hey! Just got an instance of BIRD dying unexpectedly after displaying the following message: nl_get_reply: No buffer space available It's from netlink.c: int x = recvmsg(nl->fd, &m, 0); if (x < 0) die("nl_get_reply: %m"); Manpage for netlink(7) says an application should expect such a condition: However, reliable transmissions from kernel to user are impossible in any case. The kernel can't send a netlink message if the socket buffer is full: the message will be dropped and the kernel and the user-space process will no longer have the same view of kernel state. It is up to the application to detect when this happens (via the ENOBUFS error returned by recvmsg(2)) and resynchronize. Another possibility would be to use NETLINK_NO_ENOBUFS socket option: This flag can be used by unicast and broadcast listeners to avoid receiving ENOBUFS errors. I don't think using this flag is a good idea. I thought this problem has already been reported recently, but I didn't find the thread back. The receive buffer could be increased dynamically when this happens. Or maybe we could just ignore the error and wait for the next kernel sync to catch up. Or the 8192 value could be configured at build-time. What's the best option? -- 10.0 times 0.1 is hardly ever 1.0. - The Elements of Programming Style (Kernighan & Plauger)

2 1

Re: Version 2.0.0-pre1
by Job Snijders 02 May '17

02 May '17

On Mon, May 01, 2017 at 11:45:58AM +0200, Ondrej Zajicek wrote: > On Sun, Apr 30, 2017 at 10:42:19AM +0200, Job Snijders wrote: > > On Sun, Apr 30, 2017 at 12:46:04AM +0200, Ondrej Filip wrote: > > > Let me announce a new addition to 2.0.x branch. > > > > Congratulations! > > > > Does this 2.0.0-pre1 version follow draft-ietf-grow-bgp-reject ? > > No, like 1.6.x, it has default policy of import all, export none. > > While i see that it is a good idea to have export none as default, i > do not see much advantage to have import none as default. I'd argue this is insecure behaviour and I'm disappointed you do not see an advantage. The default of "import all" fully relies on the EBGP neighbor not announcing crap to you. Relying on others to do the right thing means you are operating from a position of weakness rather then strength. And while today your peering partner may announce a pristine set of routes, tomorrow that might be different. Your EBGP peer could update their configuration, upgrade the software, or swap out their implementation for something with poor defaults. This can lead to surprises (outages) to both parties if they are not incentivized to ensure that both sides of the EBGP session make a conscience decision what to accept and what to reject. You may want to align with feela@ since it appears you have different opinions on the matter. Ondrej Filip told me that 2.0.x would be the right place for a change like this and earlier on committed to support this secure default behaviour. Kind regards, Job

5 4

Filters based on communities from other peer
by Przemyslaw Bromber 02 May '17

02 May '17

Hi Everyone I'm not sure if this is a proper group for asking about an issue I have. I'm new to BIRD and decided to build POC where I have a bunch of servers (SRV1, SRV2, SRVxx) with BIRD and the same /32 prefixes on loopback interfaces. Those prefixes are sent to RT-MAIN. To have only one active server with designated IP prefix I decided to prepend the prefix on other servers n times. This configuration works fine. Failovers work perfectly but with infrastructure I have with a lot of changes I have to use an agent to refresh BIRD configuration files very often. To get rid of this problem I came with an idea to use a management routers connected to all servers sending the same prefixes as on my servers but with communities, e.g. (65000,n) where n means how many times prefix should be prepended on server. Topology would look like this: NET | | RT-MAIN --- SRV2 | | || SRV1 --- RT-MGMT This is an idea but I have a problem with implementation. Is it possible with BIRD to write an export filter which will be able to use communities received prom other peer? For example, if SRV1 receives prefix 10.1.1.1/32 with community (65000,3) form RT-MGMT and this prefix is configured on interface lo then it should be send to RT-MAIN prepended three times

1 0