Re: BIRD 2.0.0: RFC8097 extended communities and rpki-light
On Tue, Dec 12, 2017 at 06:47:44PM +0100, Pier Carlo Chiodi wrote: > Hello, > > while I was running some tests on BIRD 2.0.0 I've noticed that the > handling of RFC8097 extended communities is different from 1.6.3. > The results I get follow: > > - when 1.6.3 is used on the route server, BIRD treats the community > strictly according to RFC4360: > >If a route has a non-transitivity extended community, then before >advertising the route across the Autonomous System boundary the >community SHOULD be removed from the route. > > - when 2.0.0 is used, the community is treated accordingly to > draft-ietf-sidrops-route-server-rpki-light-02 and is propagated to the > client. Hi Thanks for report, this seems like a bug. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
Re: BIRD 2.0.0: RFC8097 extended communities and rpki-light
Dear all,
On Tue, Dec 12, 2017 at 06:47:44PM +0100, Pier Carlo Chiodi wrote:
> while I was running some tests on BIRD 2.0.0 I've noticed that the
> handling of RFC8097 extended communities is different from 1.6.3.
>
> Scenario:
> - AS10 announces a route to the route server;
> - the route server adds the (0x4300, 0, 1) ext community (RFC8097);
> - AS20 receives the route;
> - clients are always both on 1.6.3.
>
> This is the filter I'm using:
>
> filter from_client {
> bgp_ext_community.add((unknown 0x4300, 0, 1));
> accept;
> }
>
> The results I get follow:
>
> - when 1.6.3 is used on the route server, BIRD treats the community
> strictly according to RFC4360:
>
>If a route has a non-transitivity extended community, then before
>advertising the route across the Autonomous System boundary the
>community SHOULD be removed from the route.
Hmm... I think it is in everyone's best interest that non-transitive BGP
extended communities are actually treated as non-transitive (like in
1.6.3). This prevents surprises.
> - when 2.0.0 is used, the community is treated accordingly to
> draft-ietf-sidrops-route-server-rpki-light-02 and is propagated to the
> client.
>
> Since I didn't find any reference to RFC8097/rpki-light on the web site,
> I was wondering if I missed something or if this is the expected
> behaviour.
Please note that draft-ietf-sidrops-route-server-rpki-light is still
heavily in flux, and the authors indicated that they'd move towards
using a transitive extended community and abandon the non-transitive
extended communities in the current revision of the draft.
Kind regards,
Job
BIRD 2.0.0: RFC8097 extended communities and rpki-light
Hello,
while I was running some tests on BIRD 2.0.0 I've noticed that the
handling of RFC8097 extended communities is different from 1.6.3.
Scenario:
- AS10 announces a route to the route server;
- the route server adds the (0x4300, 0, 1) ext community (RFC8097);
- AS20 receives the route;
- clients are always both on 1.6.3.
This is the filter I'm using:
filter from_client {
bgp_ext_community.add((unknown 0x4300, 0, 1));
accept;
}
The results I get follow:
- when 1.6.3 is used on the route server, BIRD treats the community
strictly according to RFC4360:
If a route has a non-transitivity extended community, then before
advertising the route across the Autonomous System boundary the
community SHOULD be removed from the route.
- when 2.0.0 is used, the community is treated accordingly to
draft-ietf-sidrops-route-server-rpki-light-02 and is propagated to the
client.
Since I didn't find any reference to RFC8097/rpki-light on the web site,
I was wondering if I missed something or if this is the expected
behaviour.
Configs and 'show route' output attached.
Bests,
--
Pier Carlo Chiodi
https://pierky.com
router id 192.0.2.10;
log "/var/log/bird.log" all;
log syslog all;
debug protocols all;
protocol device { }
protocol static own_prefixes {
route 1.0.1.0/24 reject;
}
protocol bgp the_rs {
local as 10;
neighbor 192.0.2.2 as 999;
import all;
export all;
connect delay time 1;
connect retry time 1;
}
router id 192.0.2.20;
log "/var/log/bird.log" all;
log syslog all;
debug protocols all;
protocol device { }
protocol bgp the_rs {
local as 20;
neighbor 192.0.2.2 as 999;
import all;
export all;
connect delay time 1;
connect retry time 1;
}
With BIRD 2.0.0 on the route server:
rs$ birdcl show route all
BIRD 2.0.0 ready.
Table master4:
1.0.1.0/24 unicast [AS10 17:33:32.159] * (100) [AS10i]
via 192.0.2.10 on eth0
Type: BGP univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)
rs$ birdcl show route all export AS20
BIRD 2.0.0 ready.
Table master4:
1.0.1.0/24 unicast [AS10 17:33:32.159] * (100) [AS10i]
via 192.0.2.10 on eth0
Type: BGP univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)
from the receiving client:
receiver$ birdcl show route all
BIRD 1.6.3 ready.
1.0.1.0/24 via 192.0.2.10 on eth0 [the_rs 17:33:32 from 192.0.2.2] *
(100) [AS10i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)
With BIRD 1.6.3 on the route server:
rs$ birdcl show route all
BIRD 1.6.3 ready.
1.0.1.0/24 via 192.0.2.10 on eth0 [AS10 17:36:56] * (100) [AS10i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)
rs$ birdcl show route all export AS20
BIRD 1.6.3 ready.
1.0.1.0/24 via 192.0.2.10 on eth0 [AS10 17:36:56] * (100) [AS10i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
BGP.ext_community: (generic, 0x4300, 0x1)
from the receiving client:
receiver$ birdcl show route all
BIRD 1.6.3 ready.
1.0.1.0/24 via 192.0.2.10 on eth0 [the_rs 17:36:56 from 192.0.2.2] *
(100) [AS10i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 10
BGP.next_hop: 192.0.2.10
BGP.local_pref: 100
router id 192.0.2.2;
define rs_as = 999;
log "/var/log/bird.log" all;
log syslog all;
debug protocols { states, routes, filters, interfaces, events };
protocol device {};
table master sorted;
filter from_client {
bgp_ext_community.add((unknown 0x4300, 0, 1));
accept;
}
protocol bgp AS10 {
description "AS10";
local as 999;
neighbor 192.0.2.10 as 10;
rs client;
passive on;
ttl security off;
interpret communities off;
secondary;
import keep filtered on;
import filter from_client;
export all;
}
protocol bgp AS20 {
description "AS20";
local as 999;
neighbor 192.0.2.20 as 20;
rs client;
passive on;
ttl security off;
interpret communities off;
secondary;
import keep filtered on;
import filter from_client;
export all;
}
router id 192.0.2.2;
define rs_as = 999;
log "/var/log/bird.log" all;
log syslog all;
debug protocols { states, routes, filters, interfaces, events };
protocol device {};
ipv4
Re: birdc 2.0.0 crashes
> Note that .birdc_history is created during exit from birdc, not during > start of birdc. Do you get .birdc_history if you use new birdc, do some > commands and exit from it without crashing it? Yes, works fine. And it also appears to be read when I restart birdc, because now I can crash it with ^P or ↑ without having typed a command before. (strace confirmed: .birdc_history is read successfully) > What version of readline and history libraries do you have? ~/builds/bird-2.0.0> ldd birdc linux-vdso.so.1 => (0x7fff445fa000) libhistory.so.6 => /lib/x86_64-linux-gnu/libhistory.so.6 (0x7f41f2bfd000) libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x7f41f29b7000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f41f278d000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f41f257) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f41f21a6000) /lib64/ld-linux-x86-64.so.2 (0x55d339f07000) /var/log/syslog has: Dec 12 16:45:37 kernel: birdc[6756]: segfault at 10 ip 7f0243394a0b sp 7ffec5ef7df8 error 4 in libreadline.so.6.3[7f0243366000+3d000] Groetjes, Clemens
Re: birdc 2.0.0 crashes
On Tue, Dec 12, 2017 at 04:00:23PM +0100, Clemens Schrimpe wrote: > Hello all - > > I just compiled and installed BIRD 2.0.0 on a x86_64 Ubuntu 16.04.3 LTS (with > ZFS root) test-machine and (most) things look pretty dandy so far. > > Though ... birdc crashes inside lib-readline when I attempt to go back in the > command history (^P or ↑), but only if there already is something to go back > to. It also fails to create the .birdc_history file in the first place. > Thankfully the 1.6.3 birdc still works fine, so I can continue playing for > now. > > Has anyone else found this as well already? Otherwise I'd dig deeper (would > have to install debug tools on the target machine, etc.) Hi Thanks for the testing and report. It works for us on several platforms, from Debian to NetBSD. Note that .birdc_history is created during exit from birdc, not during start of birdc. Do you get .birdc_history if you use new birdc, do some commands and exit from it without crashing it? What version of readline and history libraries do you have? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@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."
birdc 2.0.0 crashes
Hello all - I just compiled and installed BIRD 2.0.0 on a x86_64 Ubuntu 16.04.3 LTS (with ZFS root) test-machine and (most) things look pretty dandy so far. Though ... birdc crashes inside lib-readline when I attempt to go back in the command history (^P or ↑), but only if there already is something to go back to. It also fails to create the .birdc_history file in the first place. Thankfully the 1.6.3 birdc still works fine, so I can continue playing for now. Has anyone else found this as well already? Otherwise I'd dig deeper (would have to install debug tools on the target machine, etc.) Thanks, Clemens PS: Great Work, Team!!! I really appreciate your efforts!
