- Bird-users - Mailing Lists

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

BGP keepalive_time
by Arvin Gan 08 Jun '18

08 Jun '18

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

1 0

dependent ospf areas
by Илья Шипицин 06 Jun '18

06 Jun '18

hello, we use BIRD with 2 ospf areas: external and internal. can someone give an advice how to implement dependent filters? i.e. "if there are no neighbors on internal, so do not export anything on external"? and "if there at least one neighbor on internal, export routes on external" thanks! Ilya Shipitsin

2 2

BIRD router/route server functions
by Rae Ho (ITSC) 04 Jun '18

04 Jun '18

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

1 0

BGP origin attribute
by Arvin Gan 01 Jun '18

01 Jun '18

Hi All, I notice the origin attribute in function bgp_update_attrs , if route source is BGP, I think it should set as ORIGIN_IGP, not INCOMPLETE, according to RFC or Cisco device . It seems there is mistake on Line 1443 in attrs.c . Line 1443: bgp_set_attr_u32(&attrs, pool, BA_ORIGIN, 0, src ? ORIGIN_INCOMPLETE : ORIGIN_IGP); ð bgp_set_attr_u32(&attrs, pool, BA_ORIGIN, 0, src ? ORIGIN_IGP : ORIGIN_INCOMPLETE ); // correct? Thanks Arvin

3 6

bgp_next_hop check?
by Job Snijders 29 May '18

29 May '18

Dear BIRD devs, On https://gitlab.labs.nic.cz/labs/bird/wikis/BGP_filtering I see the following curious snippet: function xx() { ... if bgp_next_hop != from then return false; ... } What in the above example does "from" mean? Is "from" some kind of magic keyword that expands into something? Kind regards, Job

2 2

Static route bgp_next_hop attribute.
by oldnick nsp 29 May '18

29 May '18

Hi all! I'm trying to use Bird to announce route with predefined bgp next hop and to avoid filter manipulation on this route to set next-hop on it. My goal is to put route configuration into separate include file with fewer lines as possible. Relevant part of my config is as follows: protocol bgp 'test_nbr' { local as 65001; neighbor 10.0.0.2 as 65002; hold time 30; multihop 5; import all; export all; next hop keep; } protocol static test { route 192.168.0.1/32 blackhole { bgp_next_hop = 172.16.0.1; }; } I can see that route has bgp_next_hop attribute with command "show route all": bird> show route all 192.168.0.1/32 blackhole [test 07:05:07] * (200) Type: static unicast univ BGP.next_hop: 172.16.0.1 But when neighbor receives this announce, it still gets the peer address as a next-hop. This is debug output at neighbor side: *May 29 14:05:02.327: BGP(0): 10.0.0.1 rcvd UPDATE w/ attr: nexthop 10.0.0.1, origin i, merged path 65001, AS_PATH *May 29 14:05:02.331: BGP(0): 10.0.0.1 rcvd 192.168.0.1/32 So, the question is: is there any way to keep bgp_next_hop attribute from static route into protocol bgp announces? -- Regards, Sergey

2 2

BGP Monitoring Protocol (BMP) support in Bird?
by Emerson Barea 29 May '18

29 May '18

Hi, is there BGP Monitoring Protocol support in Bird? I didn't get this information in Bird docs. Thank you. Tocha.

2 1