July 2019 - Bird-users - Mailing Lists

sets in bgpmasks ?
by Clemens Schrimpe 06 Aug '19

06 Aug '19

Hello all - I wonder: Is there a "nice" syntax to have sets (lists of ASs) inside of bgpmasks? I.e., [= 123 [234, 345] * =] does not work (syntax error). Any other ideas? Thanks, Clemens

4 6

Option --runstatedir in BIRD 2.0.4 broken?
by Robert Scheck 06 Aug '19

06 Aug '19

Hello folks, when trying to use --runstatedir in BIRD 2.0.4, it looks like this here: + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --runstatedir=/run/bird BUILDSTDERR: configure: error: unrecognized option: `--runstatedir=/run/bird' https://kojipkgs.fedoraproject.org//work/tasks/7262/33807262/build.log is the full buildsystem log. So is --runstatedir in BIRD 2.0.4 broken? When looking to configure, it feels very much like a autoconf generation issue. Because in difference to that BIRD 2.0.3 doesn't complain, buildsystem log: https://kojipkgs.fedoraproject.org//work/tasks/7292/33807292/build.log Regards, Robert

3 4

[bird-users] cz.nic debian mirror and bullseye
by Christoffer Hansen 31 Jul '19

31 Jul '19

bird-users@, Was wondering why the CZ.NIC mirror[0] only contains the packages for jessie (8), and stretch (9). Not yet buster (10) or bullseye (testing) ? Imho it makes sense to either keep [0] up-to-date with [1]. Or just plainly close the CZ.NIC mirror[0]. [0]: http://bird.network.cz/debian/dists/ [1]: https://packages.debian.org/search?keywords=bird&searchon=names&suite=all&s… -- Christoffer

1 0

segmentation fault
by Илья Шипицин 30 Jul '19

30 Jul '19

hello, I'm running bird git-master config (OSPF +BFD): ------------------------ log "/var/log/bird.log" all; debug protocols all; router id X.X.X.X; filter deny_default { if net = 0.0.0.0/0 then reject; else accept; } filter permit_white { if net ~ [ X.X.X.X/32 ,X.X.X.X/32,X.X.X.X/32 ] then accept; else reject; } filter permit_internal { if net ~ [ X.X.X.X/32 ] then accept; else reject; } filter change_src { if net = 0.0.0.0/0 then { krt_prefsrc = X.X.X.X; accept; } else accept; } protocol direct { interface "*"; ipv4; } protocol kernel { scan time 20; ipv4 { import all; export filter change_src; }; } protocol device { scan time 10; } protocol ospf External { rfc1583compat yes; ipv4 { import all; export filter permit_white; }; area 100.0.0.0 { interface "eno1.1498" { type pointopoint; authentication cryptographic; password "XXX"; bfd yes; }; interface "eno2.1500" { type pointopoint; authentication cryptographic; password "XXX"; bfd yes; }; }; } protocol ospf Internal1 { rfc1583compat yes; ipv4 { import filter deny_default; export filter permit_internal; }; area 0.0.0.20 { interface "eno1.1497" { type pointopoint; authentication cryptographic; password "XXX"; bfd yes; }; }; } protocol ospf Internal2 { rfc1583compat yes; ipv4 { import filter deny_default; export filter permit_internal; }; area 0.0.0.20 { interface "eno2.1499" { type pointopoint; authentication cryptographic; password "XXX"; bfd yes; }; }; } protocol bfd bfd_proto { interface "eno1.1497" { interval 50ms; idle tx interval 2s; multiplier 3; authentication keyed sha1; password "XXX"; }; interface "eno1.1498" { interval 50ms; idle tx interval 2s; multiplier 3; authentication keyed sha1; password "XXX"; }; interface "eno2.1500" { interval 50ms; idle tx interval 2s; multiplier 3; authentication keyed sha1; password "XXX"; }; interface "eno2.1499" { interval 50ms; idle tx interval 2s; multiplier 3; authentication keyed sha1; password "XXX"; }; } ---------------------- on SIGHUP sometimes bird crashes (gdb) bt #0 _IO_vfprintf_internal (s=0x0, format=0x4ddaf9 "%s <%s> ", ap=ap@entry=0x7f9954af06d8) at vfprintf.c:1271 #1 0x00007f9954b45287 in __fprintf (stream=<optimized out>, format=<optimized out>) at fprintf.c:32 #2 0x000000000040352b in log_commit (class=2, buf=0x7f9954af0ce0) at sysdep/unix/log.c:192 #3 0x000000000040368d in vlog (class=2, msg=0x4e5c1a "%s: Sending CTL to %I [%s%s]", args=0x7f9954af0d20) at sysdep/unix/log.c:220 #4 0x0000000000403764 in log_msg (msg=0x4e5c1a "%s: Sending CTL to %I [%s%s]") at sysdep/unix/log.c:244 #5 0x000000000045d2be in bfd_send_ctl (p=0x25bf510, s=0x25f5028, final=0) at proto/bfd/packets.c:315 #6 0x0000000000466086 in bfd_tx_timer_hook (t=0x25f6010) at proto/bfd/bfd.c:387 #7 0x000000000047b1ce in timers_fire (loop=0x25e1c58) at lib/timer.c:235 #8 0x000000000045c956 in birdloop_main (arg=0x25e1c10) at proto/bfd/io.c:526 #9 0x00007f9954ec6dd5 in start_thread (arg=0x7f9954af1700) at pthread_create.c:307 #10 0x00007f9954befead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) in case someone interested, please have a look cheers, Ilya Shipitsin

3 4

Question in relation to draft-sa-grow-maxprefix
by Hansen, Christoffer 29 Jul '19

29 Jul '19

bird-users@, https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/?include_text=1 Do the current bird 1.6.4 and 2.0.4 releases *not* support any of these mentioned scenarios? Christoffer """ 2.1. Type A: Pre-Policy Inbound Maximum Prefix Limits The Adj-RIBs-In stores routing information learned from inbound UPDATE messages that were received from another BGP speaker Section 3.2 [RFC4271]. The Type A pre-policy limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI) as input into its threshold comparisons. For example, when an operator configures the Type A pre-policy limit for IPv4 Unicast to be 50 on a given EBGP session, and the other BGP speaker announces its 51st IPv4 Unicast NLRI, the session MUST be terminated. Type A pre-policy limits are particularly useful to help dampen the effects of full table route leaks and memory exhaustion when the implementation stores rejected routes. 2.2. Type B: Post-Policy Inbound Maximum Prefix Limits RFC4271 describes a Policy Information Base (PIB) that contains local policies that can be applied to the information in the Routing Information Base (RIB). The Type B post-policy limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI), after application of the Import Policy as input into its threshold comparisons. For example, when an operator configures the Type B post-policy limit for IPv4 Unicast to be 50 on a given EBGP session, and the other BGP speaker announces a hundred IPv4 Unicast routes of which none are accepted as a result of the local import policy (and thus not considered for the Loc-RIB by the local BGP speaker), the session is not terminated. Type B post-policy limits are useful to help prevent FIB exhaustion and prevent accidental BGP session teardown due to prefixes not accepted by policy anyway. 3. Outbound Maximum Prefix Limits An operator MAY configure a BGP speaker to terminate its BGP session with a neighbor when the number of address prefixes to be advertised to that neighbor exceeds a locally configured upper limit. The BGP speaker then MUST send the neighbor a NOTIFICATION message with the Error Code Cease and the Error Subcode "Threshold reached: Maximum Number of Prefixes Send", and MAY support other actions. Reporting when thresholds have been exceeded is an implementation specific consideration, but SHOULD include methods such as Syslog [RFC5424]. By definition, Outbound Maximum Prefix Limits are Post-Policy. The Adj-RIBs-Out stores information selected by the local BGP speaker for advertisement to its neighbors. The routing information stored in the Adj-RIBs-Out will be carried in the local BGP speaker's UPDATE messages and advertised to its neighbors Section 3.2 [RFC4271]. The Outbound Maximum Prefix Limit uses the number of NLRIs per Address Family Identifier (AFI) per Subsequent Address Family Identifier (SAFI), after application of the Export Policy, as input into its threshold comparisons. For example, when an operator configures the Outbound Maximum Prefix Limit for IPv4 Unicast to be 50 on a given EBGP session, and were about to announce its 51st IPv4 Unicast NLRI to the other BGP speaker as a result of the local export policy, the session MUST be terminated. Outbound Maximum Prefix Limits are useful to help dampen the negative effects of a misconfiguration in local policy. In many cases, it would be more desirable to tear down a BGP session rather than causing or propagating a route leak. """

1 1

[PATCH] RPKI: fix allocation of hostname when using an IPv6 address
by Vincent Bernat 29 Jul '19

29 Jul '19

--- proto/rpki/config.Y | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proto/rpki/config.Y b/proto/rpki/config.Y index a88a29a1c004..63c7105cd073 100644 --- a/proto/rpki/config.Y +++ b/proto/rpki/config.Y @@ -97,7 +97,7 @@ rpki_cache_addr: rpki_check_unused_hostname(); RPKI_CFG->ip = $1; /* Ensure hostname is filled */ - char *hostname = cfg_allocz(sizeof(INET6_ADDRSTRLEN + 1)); + char *hostname = cfg_allocz(INET6_ADDRSTRLEN + 1); bsnprintf(hostname, INET6_ADDRSTRLEN+1, "%I", RPKI_CFG->ip); RPKI_CFG->hostname = hostname; } -- 2.22.0

2 1

Limitation on stubnet prefixes
by Andre Cunha 27 Jul '19

27 Jul '19

Hello, Is there a limit on the number of stubnet prefixes that we can configure? I have configured 50000 stubnets but my router receives only 1084 routes. protocol ospf v2 { area 0 { interface "virbr1"; include "/home/acunha/routes.txt"; }; } acunha@staging:~$ more /home/acunha/routes.txt stubnet 1.0.0.0/24; stubnet 1.0.1.0/24; stubnet 1.0.2.0/24; stubnet 1.0.3.0/24; stubnet 1.0.4.0/24; stubnet 1.0.5.0/24; stubnet 1.0.6.0/24; stubnet 1.0.7.0/24; stubnet 1.0.8.0/24; stubnet 1.0.9.0/24; stubnet 1.0.10.0/24; .... If I configure the routes as static and redistribute in OSPF, it works fine. I have tested with both 1.6 and 2.0 and the behavior is the same Thanks Andre

2 3

OSPF MD5 Authentication Fails When Using Instance ID
by St. Hilaire, Joshua 25 Jul '19

25 Jul '19

OSPF MD5 authentication appears to fail with an unknown auth type 1026 when you specify an "instance ID" in BIRD, regardless of whether you specify the instance ID on the interface or not. Removing all occurrences of "instance ID" from bird.conf and re-committing the configuration appears to restore the correct auth type "cryptographic (2)". BIRD configuration and tcpdump info below. protocol ospf v2 IPv4_OSPF { instance id 4; ecmp yes limit 8; area 0 { interface "eth3" instance 4 { type pointopoint; authentication cryptographic; password "<text removed>" { algorithm keyed md5; }; }; }; } Jul 25 17:31:31.124 UTC: ospf[1007]: Rcv pkt from 192.168.1.1, GigabitEthernet0/0/0/14: Mismatch Authentication type. Input packet specified type 1026, we use type 2 Frame 16: 94 bytes on wire (752 bits), 94 bytes captured (752 bits) Ethernet II, Src: [removed], Dst: IPv4mcast_05 (01:00:5e:00:00:05) Internet Protocol Version 4, Src: 192.168.1.1, Dst: 224.0.0.5 Open Shortest Path First OSPF Header Version: 2 Message Type: Hello Packet (1) Packet Length: 44 Source OSPF Router: 192.168.1.1 Area ID: 0.0.0.0 Checksum: 0x0000 (None) Auth Type: Unknown (1026) Auth Unknown: 000001105d39f2a3 OSPF Hello Packet

2 2

BIRD 2.0.4 (with RPKI support) in EPEL 7/8 (for RHEL/CentOS 7/8)
by Robert Scheck 24 Jul '19

24 Jul '19

Hello all, BIRD 2.0.4 (with RPKI support) is available in EPEL 7 and 8 (for RHEL/ CentOS 7 and 8). And there is also a package in EPEL 6, but without RPKI due to too old libssh version in RHEL/CentOS 6. - RHEL/CentOS 7: yum install --enablerepo=epel-testing bird2 - RHEL 8: https://koji.fedoraproject.org/koji/buildinfo?buildID=1319598 Please note that the packaging is slightly different related to upstream's RPM packages (e.g. BIRD drops root privileges and its configuration files and directories are not world readable; /run/bird/bird.ctl socket rather /var/run/bird.ctl), but it also covers more architectures (x86_64, aarch64, ppc64le; and EL8 even s390x). The BIRD package for EPEL 8 is likely to enter the regular repository once there is one, currently the best for RHEL 8 is to grab the build directly from the buildsystem (or the koji buildsystem repo). Regards, Robert

3 4

Re: bfd does not work in a vrf
by Ondrej Zajicek 24 Jul '19

24 Jul '19

Hello Yes, this is currently not implemented properly, i forgot about it. Would require some substantial work. There are two possibilities: - Multiple BFD instances, each in VRF, with proper dispatch of BFD requests to instances based on VRF. - One BFD instance, with multiple listening sockets, each with appropriate VRF. That would require more work. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago(a)crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

2 10