- Bird-users - Mailing Lists

Filtering Flowspec Routes from/to BGP Peer
by Tim Weippert 23 Jul '18

23 Jul '18

Hi List, i currently search some informations of what filtering is possible in Bird on Flowspec (flow4/flow6) routes. As i currently understand is, that the BGP Common Fields (Community, AS_Path, etc.) is accesible and filterable, but no flow specific attribute (src, dst, ...). As i understand it correctly, it wouldn't be possible to filter flowpsec routes on source/destination attributes. So in a normal BGP environment, i can filter flowspec per AS, but not granular as this AS are allowed to send flowspec routes with src/dst from a given prefix!? Is something planned to implement or is it there and i'm unable to find it? regards, tim

2 1

After update bird 1.6.3->1.6.4 my filter don't working
by Владислав Гришин 20 Jul '18

20 Jul '18

After update bird not announce prefixes with the same filter in config filter AS8905_out { if ( source = RTS_STATIC_DEVICE && net = 91.211.216.0/22 ) then { bgp_community = add(bgp_community,(8905,1050)); #backup community bgp_origin = 0; bgp_path.prepend(48720); bgp_path.prepend(48720); bgp_path.prepend(48720); bgp_path.prepend(48720); accept; } if ( source = RTS_STATIC_DEVICE && net = 193.9.244.0/22 ) then { bgp_community = add(bgp_community,(8905,1050)); #backup community bgp_origin = 0; bgp_path.prepend(48720); bgp_path.prepend(48720); bgp_path.prepend(48720); bgp_path.prepend(48720); accept; } if ( source = RTS_STATIC_DEVICE && net = 91.142.72.0/22 ) then { bgp_community = add(bgp_community,(8905,1050)); #backup community bgp_origin = 0; bgp_path.prepend(48720); bgp_path.prepend(48720); bgp_path.prepend(48720); bgp_path.prepend(48720); accept; } if ( source = RTS_STATIC_DEVICE && net = 91.142.76.0/22 ) then { bgp_community = add(bgp_community,(8905,1050)); #backup community bgp_origin = 0; bgp_path.prepend(48720); bgp_path.prepend(48720); bgp_path.prepend(48720); bgp_path.prepend(48720); accept; } reject; }; output for ver 1.6.4 bird> show route export bgpcifra bird> show route preexport bgpcifra 184.0.184.0/21 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS209?] 208.0.208.0/22 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS26759i] 208.0.208.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS26759i] 168.0.168.0/22 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS265257i] 210.0.210.0/23 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS9304i] 154.0.154.0/23 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS36909i] 188.0.188.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS49724i] 131.0.131.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS52232i] 169.0.169.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS37611i] 138.0.138.0/23 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS264550i] 194.0.194.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS42315i] 161.0.161.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS262237i] 40.0.40.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS4249i] 169.1.173.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS37611i] 200.1.204.0/24 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS27795i] 196.1.192.0/20 via 91.211.219.10 on eth3.500 [bgpborder2 2018-07-18 11:55:54] * (100/0) [AS15706?] ... bird> show protocols all bgpcifra name proto table state since info bgpcifra BGP master up 11:55:55 Established Description: CIFRA1 Router ID: 212.34.35.82 Preference: 100 Input filter: AS8905_in Output filter: AS8905_out Routes: 0 imported, 0 exported, 0 preferred Route change stats: received rejected filtered ignored accepted Import updates: 1415686 0 1415686 0 0 Import withdraws: 102 0 --- 1415788 0 Export updates: 1415361 0 1415361 --- 0 Export withdraws: 84 --- --- --- 707172 BGP state: Established Neighbor address: 212.34.35.81 Neighbor AS: 8905 Neighbor ID: 10.0.4.10 Neighbor caps: refresh restart-aware AS4 Session: external AS4 Source address: 212.34.35.82 Hold timer: 81/90 Keepalive timer: 3/60 output for ver 1.6.3 # birdc BIRD 1.6.3 ready. bird> show route export bgpcifra 193.9.244.0/22 dev lo [static1 2018-07-18 12:03:25] * (254) 91.142.72.0/22 dev lo [static1 2018-07-18 12:03:25] * (254) 91.142.76.0/22 dev lo [static1 2018-07-18 12:03:25] * (254) 91.211.216.0/22 dev lo [static1 2018-07-18 12:03:25] * (254) bird> show route preexport bgpcifra count 707133 of 1411221 routes for 709431 networks bird> show route export bgpcifra count 4 of 1411220 routes for 709430 networks bird> show protocol all bgpcifra name proto table state since info bgpcifra BGP master up 12:03:29 Established Description: CIFRA1 Router ID: 212.34.35.82 Preference: 100 Input filter: AS8905_in Output filter: AS8905_out Routes: 704077 imported, 4 exported, 4599 preferred Route change stats: received rejected filtered ignored accepted Import updates: 729703 0 3254 0 726449 Import withdraws: 657 0 --- 3265 646 Export updates: 1187031 460231 726796 --- 4 Export withdraws: 589 --- --- --- 0 BGP state: Established Neighbor address: 212.34.35.81 Neighbor AS: 8905 Neighbor ID: 10.0.4.10 Neighbor caps: refresh restart-aware AS4 Session: external AS4 Source address: 212.34.35.82 Hold timer: 74/90 Keepalive timer: 10/60 bird> Vladislav Grishin

4 3

segmentation fault in radv protocol
by Julian Schuh 19 Jul '18

19 Jul '18

Hi everyone, while poking around with bird I stumbled upon a reproducible segmentation fault in the radv protocol (I think). I’m using bird 2.0.2 with the following config (simplified for debugging purposes): log syslog all; debug protocols all; protocol device { } protocol radv { interface "br_client"; } When flushing the addresses on interface br_client ip addr flush dev br_client the segmentation fault occurs, but only if the daemon has been running for a little bit longer than 60 seconds. Before running the command, the interface is up and has a couple of IP addresses configured. The configuration is performed before bird is started: ip addr add 192.168.27.1/24 dev br_client ip addr add xxxx:xxxx:xxxx:xxxx::1/64 dev br_client ip addr add fe80::27/64 dev br_client Relevant log output starting from the moment when the flush command is executed: Jul 19 08:24:15 bird: device1: Scanning interfaces Jul 19 08:24:15 bird: radv1 < interface br_client goes up Jul 19 08:24:15 bird: radv1: Adding interface br_client Jul 19 08:24:15 bird: radv1 < address 192.168.27.0/24 on interface br_client added Jul 19 08:24:15 bird: radv1 < address xxxx:xxxx:xxxx:xxxx::/64 on interface br_client added Jul 19 08:24:15 bird: radv1 < address fe80::/64 on interface br_client added Jul 19 08:24:18 bird: radv1 < address 192.168.27.0/24 on interface br_client removed Jul 19 08:24:18 bird: radv1: Event Init on br_client Jul 19 08:24:18 bird: radv1: Adding new prefix xxxx:xxxx:xxxx:xxxx::/64 on br_client Jul 19 08:24:18 bird: radv1: Timer fired on br_client Jul 19 08:24:18 bird: radv1: Sending RA via br_client Jul 19 08:24:18 bird: radv1 < address xxxx:xxxx:xxxx:xxxx::/64 on interface br_client removed Jul 19 08:24:18 bird: radv1: Event Change on br_client I would appreciate any help. Thanks in advance and best regards Julian Schuh

2 1

FreeBSD 11 and mixed BGP password issues?
by Thomas Johnson 18 Jul '18

18 Jul '18

I recently updated a couple of my routers from FreeBSD 10.3 to 11.2, both running BIRD 1.6 (1.6.3 -> 1.6.4). After the upgrade, I noticed that my BGP protocol instances without a password fail to connect, while those with a password work as expected. For reference, my topology is as follows. I have a pair of routers (matching OS/BIRD versions), each with a BGP session to an upstream router. These eBGP protocol instances use a BGP password, which was previously handled by manually configuring the ipsec.conf file (changed to let BIRD manage while troubleshooting this issue). Additionally, there is an iBGP session between the two BIRD routers, which does not utilize a password. +-------+ +-------+ | ISP1 | | ISP2 | +--+----+ +--+----+ | | |(MD5) |(MD5) | | +--+----+ +--+----+ | BIRD1 +------+ BIRD2 | +-------+ +-------+ IIRC, the IPSec/TCP-MD5 changes in FreeBSD 11 have been discussed here previously. If I understand their effect on BIRD correctly, setting TCP_MD5SIG on the BGP listen socket in FreeBSD 11 mandates that all packets in/out on the socket MUST be MD5-signed (per tcp(4)). By comparison, the behavior in earlier FreeBSD releases was more of an opportunistic model. If my limited understanding of the BIRD code is correct, when the configuration of a BGP protocol instance specifies a password, the TCP_MD5SIG option is set on the listen socket (and appropriate connect sockets). Because of the change in behavior for the TCP_MD5SIG option, this effectively bars any non-MD5 connections to the listen socket. If I change the (non-password) iBGP session configuration to use a password and reconfigure BIRD, the session comes up (as expected). Interestingly, if I then remove the password from the iBGP instance and reconfigure (both BIRD hosts), the session is restarted and works without MD5 (as shown by tcpdump). My guess is that BIRD is removing the relevant option from the listen socket when the configuration is re-read? This is not a particularly good solution (or kludge), as new/restarted sessions that require MD5 would probably fail? Can anyone confirm if I am on the right track, that FreeBSD 11 changes effectively force all BGP sessions on a given BIRD [1.6] instance to either use a password, or no password? Reading the BIRD 2.0 documentation, it appears that there is a partial solution to be had. The 'strict bind' option appears to allow binding the listen socket to a specific IP. Would this allow IP address "1" to listen for sessions with passwords, and address "2" to listen for sessions without? This still would not address another situation I have, where multiple BGP sessions connect to the same local IP, some with passwords, some without (IXP connection). This would seem to be more of a FreeBSD issue than a BIRD issue. However, I'm curious if anyone else has run into it, and has some clever idea that I have overlooked? Configuration snippet for IPv4 follows, although I see the same behavior on IPv6 as well (omitted for brevity). # START BIRD CONFIG template bgp ebgp { local as 12345; } template bgp ibgp { multihop 2; } protocol bgp bgp_uplink from ebgp { neighbor 10.20.207.131 as 54321; import filter bgp_in_uplink; password "a_password"; #setkey off; source address 10.20.207.133; } protocol bgp ibgp_border from ibgp { local 192.168.166.247 as 12345; neighbor 192.168.166.246 as 12345; # Password added to allow session to connect. password "wtf"; } # END BIRD CONFIG % setkey -D 192.168.166.246 192.168.166.247 tcp mode=any spi=96441423(0x05bf944f) reqid=0(0x00000000) A: tcp-md5 777466 seq=0x00000000 replay=0 flags=0x00000040 state=mature created: Jul 17 13:49:03 2018 current: Jul 17 13:49:30 2018 diff: 27(s) hard: 0(s) soft: 0(s) last: Jul 17 13:49:06 2018 hard: 0(s) soft: 0(s) current: 1626176(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2226 hard: 0 soft: 0 sadb_seq=9 pid=12858 refcnt=1 192.168.166.247 192.168.166.246 tcp mode=any spi=152346577(0x09149fd1) reqid=0(0x00000000) A: tcp-md5 777466 seq=0x00000000 replay=0 flags=0x00000040 state=mature created: Jul 17 13:49:03 2018 current: Jul 17 13:49:30 2018 diff: 27(s) hard: 0(s) soft: 0(s) last: Jul 17 13:49:06 2018 hard: 0(s) soft: 0(s) current: 3066573(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 2530 hard: 0 soft: 0 sadb_seq=8 pid=12858 refcnt=1 10.20.207.131 10.20.207.133 tcp mode=any spi=146229653(0x08b74995) reqid=0(0x00000000) A: tcp-md5 6321794e 783039 seq=0x00000000 replay=0 flags=0x00000040 state=mature created: Jul 17 10:49:14 2018 current: Jul 17 13:49:30 2018 diff: 10816(s) hard: 0(s) soft: 0(s) last: Jul 17 10:49:19 2018 hard: 0(s) soft: 0(s) current: 17378925(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 13433 hard: 0 soft: 0 sadb_seq=7 pid=12858 refcnt=1 10.20.207.133 10.20.207.131 tcp mode=any spi=128063495(0x07a21807) reqid=0(0x00000000) A: tcp-md5 6321794e 783039 seq=0x00000000 replay=0 flags=0x00000040 state=mature created: Jul 17 10:49:14 2018 current: Jul 17 13:49:30 2018 diff: 10816(s) hard: 0(s) soft: 0(s) last: Jul 17 10:49:19 2018 hard: 0(s) soft: 0(s) current: 453718(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 7494 hard: 0 soft: 0 sadb_seq=6 pid=12858 refcnt=1

2 1

BIRD - 6PE functionality support
by Thiruvazhiyan Lakshmanan 17 Jul '18

17 Jul '18

Hi, We are looking for using BIRD in our VM for BGP 3107 functionality with 6PE support. Basically BIRD should peer with peering router with ipv6-label-unicast family and advertise its v6 loopback address with the label value of 2 (Explicit null label) and the next-hop of the route to be set to its v4 loopback address. Does BIRD support this currently? Regards, Thiruvazhiyan L ============================================================================================================================ Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html <http://www.techmahindra.com/Disclaimer.html> externally http://tim.techmahindra.com/tim/disclaimer.html <http://tim.techmahindra.com/tim/disclaimer.html> internally within TechMahindra. ============================================================================================================================

2 2

Fwd: [Babel-users] Babel@IETF meeting Tuesday 17th -- please participate remotely
by Toke Høiland-Jørgensen 16 Jul '18

16 Jul '18

In case anyone is interested in the development of the Babel protocol. -Toke

1 0

BIRD version route server example
by Isaac HO 12 Jul '18

12 Jul '18

Dear All, My BIRD version is 1.6.4. and Would like use BIRD to set up a route server. Seems there many version of BIRD..May I know the follow example config is it suitable for ersion is 1.6.4. to build up the route server. https://github.com/pierky/arouteserver/blob/master/examples/bird_hooks/bird… Thanks, Isaac

4 3

Re: How to show community value
by Mo Shivji 12 Jul '18

12 Jul '18

> On 12 Jul 2018, at 10:58, Isaac HO <isaacho.jc(a)gmail.com> wrote: > > Thanks all but tried two method no luck. > > echo "show route all x.x.x.0/24" | sudo /usr/bin/birdc -s /var/run/bird.ctl > sudo: /usr/bin/birdc: command not found Perhaps birdc is under a different path on your box. > > birdc 'show route for x.x.x.0/24 all' > BIRD 1.6.4 ready. > 5.195.208.0/24 <http://5.195.208.0/24> via 192.168.199.202 on ens160 [R77654x1 14:32:50] * (100) [AS77654i] > Type: BGP unicast univ > BGP.origin: IGP > BGP.as_path: 77654 > BGP.next_hop: 192.168.199.202 > BGP.med: 0 > BGP.local_pref: 100 > I guess the community attribute is not showing because the prefix is not tagged with any communities. The above works for me also and shows the tagged communities. Mo

1 0

How to show community value
by Isaac HO 12 Jul '18

12 Jul '18

sh ip bgp x.x.x.0/24 <-- Cisco birdc show route where net ~ x.x.x.0/24 all BIRD 1.6.4 ready. root: variable expected. <-- Can't see any information. May I know have any other command? Thanks,

3 2

[PATCH] babel: Check TLV framing before dereferencing tlv->type
by Toke Høiland-Jørgensen 11 Jul '18

11 Jul '18

Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/packets.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proto/babel/packets.c b/proto/babel/packets.c index d4ecf649..991c1520 100644 --- a/proto/babel/packets.c +++ b/proto/babel/packets.c @@ -1373,10 +1373,6 @@ babel_process_packet(struct babel_pkt_header *pkt, int len, (byte *)tlv < end; tlv = NEXT_TLV(tlv)) { - /* Ugly special case */ - if (tlv->type == BABEL_TLV_PAD1) - continue; - /* The end of the common TLV header */ pos = (byte *)tlv + sizeof(struct babel_tlv); if ((pos > end) || (pos + tlv->length > end)) @@ -1386,6 +1382,10 @@ babel_process_packet(struct babel_pkt_header *pkt, int len, break; } + /* Ugly special case */ + if (tlv->type == BABEL_TLV_PAD1) + continue; + msg = sl_alloc(p->msg_slab); res = babel_read_tlv(tlv, &msg->msg, &state); if (res == PARSE_SUCCESS) -- 2.18.0

2 2