- Bird-users - Mailing Lists

BGP Connection reset on fast timers
by saksham 15 Jun '18

15 Jun '18

Hi All, I am testing BGP stability with extremely aggressive timers. The timers are 1/3. I see BGP flapping 2-3 times every 24 hours. Attached is a packet capture, captured on the system running bird. 10.194.8.11 is a Cisco ASR. 10.194.8.13 is the running bird instance. I see multiple keep-alives coming in from .11, but the bird instance responds with hold timer expired. This was about after 12 hours in established state. Connection opens right back up again. I don't see the same issue on upping the timers to 3/9 seconds. Anyone see anything like this before? Thanks, Saksham

4 4

BGP: AS private number check
by Arvin Gan 15 Jun '18

15 Jun '18

Hi All, According to RFC1930, the AS number 64512 to 65535 are reserved for private, I cannot find the implementation for checking private AS number in BIRD, anybody know it or it's lost in BGP ? RFC1930 10<https://tools.ietf.org/html/rfc1930.html#section-10>. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 Thanks Arvin

2 5

Recall: BGP: AS private number check
by Arvin Gan 15 Jun '18

15 Jun '18

Arvin Gan would like to recall the message, "BGP: AS private number check ".

1 0

Recall: BGP: AS private number check
by Arvin Gan 15 Jun '18

15 Jun '18

Arvin Gan would like to recall the message, "BGP: AS private number check ".

1 0

RE: BGP: AS private number check
by Arvin Gan 15 Jun '18

15 Jun '18

Hi all, Sorry, my understand is incorrect, can ignore the mail. Thanks Arvin From: Arvin Gan Sent: Friday, June 15, 2018 2:14 PM To: bird-users(a)network.cz Subject: BGP: AS private number check Hi All, According to RFC1930, the AS number 64512 to 65535 are reserved for private, I cannot find the implementation for checking private AS number in BIRD, anybody know it or it's lost in BGP ? RFC1930 10<https://tools.ietf.org/html/rfc1930.html#section-10>. Reserved AS Numbers The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535 Thanks Arvin

1 0

RE: BIRD router/route server functions
by Rae Ho (ITSC) 14 Jun '18

14 Jun '18

Dear MO, Thank you very much for your response. Yes, I followed the sample to set up the routers but don’t why the peering session between them is not established. Rae From: mo(a)linx.net <mo(a)linx.net> Sent: Monday, June 4, 2018 4:40 PM To: Rae Ho (ITSC) <raeho(a)cuhk.edu.hk> Cc: bird-users(a)network.cz Subject: Re: BIRD router/route server functions On 4 Jun 2018, at 07:08, Rae Ho (ITSC) <raeho(a)cuhk.edu.hk<mailto:raeho@cuhk.edu.hk>> wrote: Dear All, I’m Rae of CUHK. We are exploring BIRD router/route server functions. Now I set up 2 BIRD routers to from BGP session between them, seems It can’t form the peering (in active status). Questions: 1. Is there any pre-config need to be set up? (i.e. interface? Internal Subnet?) 2. Would you mind sending me some sample configurations? Rae Try looking here. https://gitlab.labs.nic.cz/labs/bird/wikis/Examples Mo

7 19

RE: BGP keepalive_time
by Arvin Gan 13 Jun '18

13 Jun '18

Hi all, Anyone meet the issue as below reason that cause BGP hold timer timeout (keepalive_time > hold_time) and switch action between closing and opening session? Thanks Arvin From: Arvin Gan Sent: Friday, June 08, 2018 3:22 PM To: 'Ondrej Zajicek' <santiago(a)crfreenet.org> Cc: bird-users(a)network.cz Subject: BGP keepalive_time Hi all, When I used bird, found a question that BGP session received OPEN message, hold_time is updated with min(config_hold_time, peer_hold_time), but keepalive_time is not updated if keepalive_time is not zero, that maybe cause keepalive_time is more than the updated hold_time after received OPEN message. Line 702 in packets.cc for bgp protocol : conn->keepalive_time = p->cf->keepalive_time ? : conn->hold_time / 3; RFC 4271: 4.4. KEEPALIVE Message Format BGP does not use any TCP-based, keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more frequently than one per second. An implementation MAY adjust the rate at which it sends KEEPALIVE messages as a function of the Hold Time interval. Thanks Arvin

2 3

BGP make client (default) announcement depend on ibgp/upstream peers being "up"
by Patrick Schaaf 12 Jun '18

12 Jun '18

Hi, new bird / BGP user here, please bear with me :) Consider a scenario with a bird box acting as (one of several possible) gateway for a set of clients, while having an iBGP and/or upstream BGP connection where the "real routes" come from. Towards the client(s) a default route should be announced. Is it possible to make the client default route announcement depend on at least one of the upstream peers (iBGP, real upstream) being "up" and having sent us all its routes? Or, even more ideally, one of them being up, having sent all its routes, _and_ bird having gotten around to installing them all in the kernel (data plane)? Conversely, if for any reason no more upstream peers are up, kernel routes are withdrawm (shutdown), withdraw that default announce to the clients? Is this possible? (using bird 2.0.2) Is there a different approach to make sure the clients won't be fooled into sending us data plane traffic already while we're not ready for it yet? best regards Patrick

2 2

Route Reflector issue
by knet solutions 12 Jun '18

12 Jun '18

Hi, I am implementing this below topology (BGP IGP), R1--------------------------------R2------------------------------------------R3 (192.168.2.2) 192.168.2.1/1.1 192.168.1.2 Here R1 and R3 are bird routers R2 is RYU BGP Speaker (act as Route reflector). This is not working as expected. Bird routers(R1) sends error notification to R2. BIRD R Attached the packet traces. Can you help me to identify what went wrong? -- *Regards, * *Knet solutions.* https://github.com/knetsolutions/KNet http://knet-topology-builder.readthedocs.io/ http://knetsolutions.in/

2 2

Babel + IPv4 = parse error
by Julian Schuh 12 Jun '18

12 Jun '18

Hi all, for a current project I’m planning on using Babel as a lightweight, dual-stack routing protocol for a couple of simple tasks. For a proof of concept I’ve been using BIRD, and a plan to continue using BIRD at least in the backend. Sadly, I quickly hit a showstopper: none of the routes (neither v4 nor v6) exported from one side were imported on the other side. While investigating the problem I quickly stumbled over the following line in the debug log: “bird: bb: Bad TLV from fe80::xxx via vh type 8 pos 16 - parse error” After playing around for a little bit I found out: The problem appears whenever the route advertisement contains v4 routes. I’m using BIRD 2.0.2. I used the following setup to reproduce the problem: Two network namespaces, “default" and “test", connected via an veth pair. In both namespaces I’m running a BIRD instance with the following configs: default: ############################################ debug protocols all; router id 127.0.0.17; protocol device { } protocol babel bb { interface "v*" { }; ipv4 { import all; export none; }; ipv6 { import all; export none; }; }; ############################################ test: ############################################ debug protocols all; router id 127.0.0.18; protocol device { } protocol kernel v4 { ipv4 { import all; export all; }; learn; } protocol kernel v6 { ipv6 { import all; export all; }; learn; }; protocol babel bb { interface "v*" { }; ipv4 { import none; export all; }; ipv6 { import none; export all; }; } ############################################ (1) In test, I create an IPv6 route. It gets propagates to default: test> show route: fd77:8888::/32 unicast [v6 09:02:15.854] * (10) via fd54:7777::1 on gre0 test> show route export bb: fd77:8888::/32 unicast [v6 09:02:15.854] * (10) via fd54:7777::1 on gre0 test> show protocol all bb: ipv4: 0 exported, ipv6: 1 exported default> show route: fd77:8888::/32 unicast [bb 09:04:23.648] * (130/96) [00:00:00:00:7f:00:00:12] via fe80::3028:9aff:fea7:4a62 on vh default> show protocol all bb: ipv4: 0 imported, ipv6: 1 imported (2) Now, I add a v4 route on test: test> ip r a 1.2.3.0/24 via 10.10.10.16 dev gre0 show route [export] now shows both routes, v4 and v6. show protocol all bb show 1 exported for each v4 and v6. In this moment, I start receiving parse errors in the debug log of the other side (default): Bad TLV from fe80::3028:9aff:fea7:4a62 via vh type 8 pos 16 - parse error Interestingly, when retracting the route, the update seems to work: test> ip r d 1.2.3.0/24 via 10.10.10.16 dev gre0 Debug output on other side (default): Handling update for 1.2.3.0/24 with seqno 1 metric 65535 TL;DR: There _seems_ to be a bug in the babel protocol implementation that leads to parse errors and thus missed route advertisements if ipv4 routes are conveyed. This does not happen with ipv4 route retractions. I would really appreciate any help. If it’s a bug I would happily test source code patches. Thanks in advance and best Regards Julian Schuh

3 7