- Bird-users - Mailing Lists

Add random number
by Max Tulyev 11 Feb '24

11 Feb '24

Hi All, is it possible to add a random number to some variable in the filter? For example, like this: filter myfilter { if net ~ 192.168.11.0/24 then preference = preference + random(10); ...

5 8

Multiple ebgp neighbours to the same peer
by Prem Anand 11 Feb '24

11 Feb '24

Hi all, New user here I am trying to get 2 ebgp neighbours on bird to peer with a remote bgp endpoint on frr node. One between 10.100.101.1 <—> 10.100.1.1 and other between 10.100.102.1 <—> 10.100.1.1 ┌──────────────────┐ ┌─────────────┐ 10.100.101.1 │ │ensp5s0 │ │ loop1 * Bird │◄──────────────────────►┘ Frr │ │ 2.0.10 │10.100.1.2 10.100.1.1 │ loop2 * │ │ │ 10.100.102.1 │ │ │ │ └──────────────────┘ └─────────────┘ I find that only the first ebgp neighbour comes up and moves to "Established” state whereas the second ebgp neighbour remains in “Idle” state. However if I restart the bgp neighbour in “Established” state, the other bgp neighbour comes up and moves to “Established” state, but the restarted one remains in Idle state. Is there any limitation that I can’t have 2 neighbours to the same peer? Or do I have to ensure that the 2 neighbours use different tables? I have already disabled rp_filter sysctl -w net.ipv4.conf.all.rp_filter=0 Regards Prem Config ====== log "/var/log/trex/bird.log" all; debug protocols all; router id 10.100.1.2; protocol device { # scan time 10; interface "loop1"; interface "loop2"; interface "enp5s0"; } protocol bgp bgp_peer1 { local 10.100.101.1 as 65001; neighbor 10.100.1.1 as 65500; ipv4 { import all; export all; }; } protocol bgp bgp_peer2 { local 10.100.102.1 as 65002; neighbor 10.100.1.1 as 65500; ipv4 { import all; export all; }; } protocol static bird_cfg_routes { ipv4 { export all; import all; }; route 200.1.1.1/32 via 10.100.2.100; } Logs ==== bird> show protocols Name Proto Table State Since Info device1 Device --- up 13:05:16.761 bgp_peer1 BGP --- up 13:05:21.497 Established bgp_peer2 BGP --- start 13:05:16.761 Idle bird_cfg_routes Static master4 up 13:05:16.761 bird> bird> bird> bird> restart bgp_peer1 bgp_peer1: restarted bird> bird> bird> show protocols Name Proto Table State Since Info device1 Device --- up 13:05:16.761 bgp_peer1 BGP --- start 13:07:13.673 Idle bgp_peer2 BGP --- up 13:07:18.328 Established bird_cfg_routes Static master4 up 13:05:16.761 bird> show interfaces lo up (index=1) MultiAccess AdminUp LinkUp Loopback Ignored MTU=65536 127.0.0.1/8 (Preferred, scope host) ::1/128 (Preferred, scope host) mgmt0 up (index=2) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 192.168.121.163/24 (Preferred, scope site) fe80::b203:e9ff:fe02:100/64 (Preferred, scope link) enp5s0 up (index=3) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.100.1.2/24 (Preferred, scope site) enp6s0 up (index=4) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.100.2.1/24 (Preferred, scope site) fc00:64:2::1/120 (Preferred, scope site) fe80::b203:e9ff:fe02:102/64 (Preferred, scope link) loop1 up (index=5) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.100.101.1/24 (Preferred, scope site) fe80::78f9:91ff:fe2c:83ed/64 (Preferred, scope link) loop2 up (index=6) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 10.100.102.1/24 (Preferred, scope site) fe80::a4fc:34ff:fefd:11ce/64 (Preferred, scope link) bird> bird> bird> show route all Table master4: 200.1.1.1/32 unicast [bird_cfg_routes 13:05:16.761] * (200) via 10.100.2.100 on enp6s0 Type: static univ bird> Debugs ====== 2023-01-21 13:05:16.761 <TRACE> device1: Initializing 2023-01-21 13:05:16.761 <TRACE> bgp_peer1: Initializing 2023-01-21 13:05:16.761 <TRACE> bgp_peer2: Initializing 2023-01-21 13:05:16.761 <TRACE> bird_cfg_routes: Initializing 2023-01-21 13:05:16.761 <TRACE> device1: Starting 2023-01-21 13:05:16.761 <TRACE> device1: Scanning interfaces 2023-01-21 13:05:16.761 <TRACE> device1: State changed to up 2023-01-21 13:05:16.761 <TRACE> bgp_peer1: Starting 2023-01-21 13:05:16.761 <TRACE> bgp_peer1: State changed to start 2023-01-21 13:05:16.761 <TRACE> bgp_peer2: Starting 2023-01-21 13:05:16.761 <TRACE> bgp_peer2: State changed to start 2023-01-21 13:05:16.761 <TRACE> bird_cfg_routes: Starting 2023-01-21 13:05:16.761 <TRACE> bird_cfg_routes: State changed to up 2023-01-21 13:05:16.761 <TRACE> bird_cfg_routes.ipv4 > added [best] 200.1.1.1/32 unicast 2023-01-21 13:05:16.761 <INFO> Started 2023-01-21 13:05:16.762 <TRACE> bgp_peer1: Started 2023-01-21 13:05:16.762 <TRACE> bgp_peer1: Connect delayed by 5 seconds 2023-01-21 13:05:21.495 <TRACE> bgp_peer1: Connecting to 10.100.1.1 from local address 10.100.101.1 2023-01-21 13:05:21.496 <TRACE> bgp_peer1: Connected 2023-01-21 13:05:21.496 <TRACE> bgp_peer1: Sending OPEN(ver=4,as=65001,hold=240,id=0a640102) 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: Got OPEN(as=65500,hold=30,id=192.168.121.230) 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: BGP session established 2023-01-21 13:05:21.497 <TRACE> bgp_peer1: State changed to up 2023-01-21 13:05:21.497 <TRACE> bgp_peer1.ipv4 < added 200.1.1.1/32 unicast 2023-01-21 13:05:23.049 <TRACE> bgp_peer1: Got UPDATE 2023-01-21 13:05:23.049 <TRACE> bgp_peer1: Got END-OF-RIB 2023-01-21 13:05:23.049 <TRACE> bgp_peer1: Sending UPDATE 2023-01-21 13:05:23.049 <TRACE> bgp_peer1: Sending END-OF-RIB 2023-01-21 13:05:30.958 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:05:31.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:05:38.689 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:05:41.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:05:46.842 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:05:51.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:05:54.864 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:06:01.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:06:03.759 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:06:11.499 <TRACE> bgp_peer1: Got KEEPALIVE 2023-01-21 13:06:11.843 <TRACE> bgp_peer1: Sending KEEPALIVE 2023-01-21 13:06:16.764 <TRACE> device1: Scanning interfaces ... ... ... 2023-01-21 13:07:13.673 <INFO> Restarting protocol bgp_peer1 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Shutting down 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Shutdown requested 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: State changed to stop 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: BGP session closed 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Sending NOTIFICATION(code=6.4) 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Down 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: State changed to flush 2023-01-21 13:07:13.673 <TRACE> bgp_peer2: Started 2023-01-21 13:07:13.673 <TRACE> bgp_peer2: Connect delayed by 5 seconds 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: State changed to down 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: Starting 2023-01-21 13:07:13.673 <TRACE> bgp_peer1: State changed to start 2023-01-21 13:07:16.761 <TRACE> device1: Scanning interfaces 2023-01-21 13:07:18.326 <TRACE> bgp_peer2: Connecting to 10.100.1.1 from local address 10.100.102.1 2023-01-21 13:07:18.327 <TRACE> bgp_peer2: Connected 2023-01-21 13:07:18.327 <TRACE> bgp_peer2: Sending OPEN(ver=4,as=65002,hold=240,id=0a640102) 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: Got OPEN(as=65500,hold=30,id=192.168.121.230) 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: Sending KEEPALIVE 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: Got KEEPALIVE 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: BGP session established 2023-01-21 13:07:18.328 <TRACE> bgp_peer2: State changed to up 2023-01-21 13:07:18.328 <TRACE> bgp_peer2.ipv4 < added 200.1.1.1/32 unicast 2023-01-21 13:07:19.880 <TRACE> bgp_peer2: Got UPDATE 2023-01-21 13:07:19.880 <TRACE> bgp_peer2: Got END-OF-RIB 2023-01-21 13:07:19.880 <TRACE> bgp_peer2: Sending UPDATE 2023-01-21 13:07:19.880 <TRACE> bgp_peer2: Sending END-OF-RIB 2023-01-21 13:07:27.298 <TRACE> bgp_peer2: Sending KEEPALIVE 2023-01-21 13:07:28.329 <TRACE> bgp_peer2: Got KEEPALIVE 2023-01-21 13:07:36.478 <TRACE> bgp_peer2: Sending KEEPALIVE

4 12

Doc suggestion - clarifying behaviour when routes are moving between protocols
by Mark Shuttleworth 09 Feb '24

09 Feb '24

Hi folks Thank you for Bird, I have enjoyed working with it over the holidays for a personal project routing between offices. Along the way I got stuck on an issue that might catch other people as well, so I thought to describe it here in the hope that docs are updated to make the behaviour more clear. I have a metropolitan area network between a few sites. Each of those sites has its own internet connection, but the MAN is much faster, so my goal was to route traffic to whichever exit point had the best bandwidth, using the different sites as backup internet gateways. At each site, I was testing the local connectivity (looking beyond simple link up to whether I could reach common sites) and then, if the link was good, adding a static route out from that location. I wanted to use Bird to export and distribute those static routes to other sites, with custom metrics to prioritise the gateways that had the best bandwidth. The expected behaviour for me was that a local, statically defined default route would be imported and have the custom metric set based on its bandwidth, and that the 'best' route would then win and be distributed by OSPF to the other sites. The problem I ran into was that the implicit protocol preference comparison prevented the local route from even being considered at all. So once a route had propagated to a site with Bird, it could not be displaced by a 'better' static route, because of the relative preferences. I ended up with a config like this, where the explicit preference solved the issue: protocol kernel { learn; # Learn alien routes from the kernel ipv4 { # Connect protocol to IPv4 table by channel import filter { if net = 0.0.0.0/0 then { # We only want default routes added manually to this machine ospf_metric2 = 1000; preference = 150; accept "Accepted default route from kernel"; } reject; }; export all; # Install all Bird routes in kernel }; } I couldn't find any documentation that explained the role of 'preference' in the import process, so I was stuck on this for an embarrassing amount of time :blush: In the end, this blog https://mk16.de/blog/bird-preference/ and some tangential comments in mailing lists led me to try the explicit preference, and that solved the issue. Apologies if I missed this in the docs, but if it isn't already covered, perhaps a more detailed explanation of the way routes are compared for import into a table would help others. Again, thank you for Bird! I think we might build it into Ubuntu in some interesting ways :) Mark

4 4

upgrade from 2.13 to 2.14
by Marek Zarychta 08 Feb '24

08 Feb '24

Dear List, today, after 299 days of machine uptime I broke 7-months lasting BGP sessions and upgraded both: FreeBSD and BIRD on our router from 13.2-STABLE to 14.0-STABLE. Now bird2-netlink-2.14 is installed and it seems to be working fine, though surprising notifications showed up in the log file: bird: /usr/local/etc/bird.conf:114:57: Inferring function check_import_v4 return type from its return value: bool bird: /usr/local/etc/bird.conf:162:58: Inferring function check_import_v6 return type from its return value: bool These lines are respectively: if (net.len < 8) || (net.len > 24) then return false; and if (net.len < 16) || (net.len > 48) then return false; I believe the warnings are harmless since "configure check" passes, but please let me know if anything is wrong with this syntax. Cheers -- Marek Zarychta

2 1

bird 2.14 segfault
by ico 08 Feb '24

08 Feb '24

Hello, We are running few routers, all Slackware Linux, 64bit. The setup is like this: router A is a gateway for whole network, speaking BGP on the outside, OSPF on the inside. There are a few routers on the inside, let's say B, C, D, ..., all of them are OSPF neighbors to A and each other. Routers B, C, etc. are running bird 2.14. I wanted to upgrade bird on router A from 1.6 to 2.14. As soon as new bird started up on A, almost all of B, C, etc. started crashing. Today I started to look into this. I found out I messed up the configuration on router A, I didn't filter out all routes from BGP and all those prefixes (IPv4 only, ~100k) were exported to OSPF. The bird on router A handled it quite OK, but routers B, C, etc. segfaulted after few seconds of exporting all those prefixes to kernel. And that happened repeatedly after bird started again. And again.. In bird's log file I found nothing. In system log were 2 lines for each segfault: [Thu Feb 1 01:51:10 2024] bird[23724]: segfault at 7ffe0e092ff8 ip 00007f2c4fb219a7 sp 00007ffe0e093000 error 6 in libc-2.33.so[7f2c4fabe000+15e000] [Thu Feb 1 01:51:10 2024] Code: 48 89 d9 49 8b 7f 28 49 8b 5f 30 48 39 df 73 bf 48 29 fb 4c 39 f3 49 0f 47 de 48 83 fb 14 76 a3 48 89 ce 48 89 da 48 89 0c 24 <e8> f4 c8 f9 ff 48 8b 0c 24 49 89 47 28 48 01 d9 eb 90 0f 1f 80 00 I will try again to upgrade router A without all those prefixes exported to OSPF, that should work I believe. I am not good at this, but maybe someone could use this information to find a bug somewhere in bird. Maybe I can help and try something with the same failing setup? Thanks ico

2 1

freebsd mbuf cluster leak with bird 2.14
by Thomas Steen Rasmussen 07 Feb '24

07 Feb '24

Hello :) Yesterday I had one of my FreeBSD routers stop forwarding because it ran out of mbuf clusters. It usually operates far from the limit, but there is (was) something leaking mbuf clusters bad, and I suspect it might be bird. ---- Some background: Due to a missing/misconfigured kernel export filter bird was repeatedly trying to export some routes to the kernel which the kernel already knew (from statically configured blackhole routes). So these errors have been repeating in the logs for some time (more than a year): Jan 11 19:09:04 dgncr2a bird[30963]: KRT: Error sending route 2a09:94c0::/29 to kernel: File exists Jan 11 19:10:04 dgncr2a syslogd: last message repeated 1 times Jan 11 19:10:04 dgncr2a bird[30963]: KRT: Error sending route 85.209.116.0/22 to kernel: File exists Jan 11 19:11:04 dgncr2a syslogd: last message repeated 1 times Over the holidays I upgraded from bird 2.0.9 to bird 2.14, as well as upgrading FreeBSD from 13-STABLE-384a885111ad to 13-STABLE-2cbd132986a7. I suspect one of these two changes made this problem appear. I made no changes to bird or router config other than the upgrades. ---- The mbuf cluster leak was pretty bad, like 8-10 clusters per second at a pretty steady rate. The kern.ipc.nmbclusters limit on my routers was around 2 million and I raised it to 4 million now. Since I had no idea what was causing the leak and I was desperate for a fix I at one point tried adding the missing kernel export filter (as to at least silence the noisy warnings in the logs), and imagine my surprise when the mbuf cluster leak stopped. I tried removing the filers again, the leak started again, and stopped again when I re-added the filters. It appears some combination of bird 2.14 and exporting routes already found in the kernel means leaking mbuf clusters like crazy. I have no idea if this is a bird or a freebsd problem but I have to start somewhere :) I can to some extent test stuff, but the routers are in production (BGP with 1 ebgp and 1 ibgp peer and no full table) so nothing too wild. Thanks! :) Best regards, Thomas Steen Rasmussen / Tykling

3 3

[PATCH] birdc: Do not execute cmd on non interactive help request
by Inrin 06 Feb '24

06 Feb '24

Hi! A pal of mine noticed that `echo <cmd> ? | birdc` executes the command <cmd> after showing it's help text is shown. I later confirmed that `birdcl` in comparison to `birdc` does not show this behaviour. Since this is a non intuitive side effect on birdc's side, here a proposed patch to align birdc and birdcl's behaviour. Please advise if fixing it on another part might be preferred. I chose birdc.c, to minimize the changes needed. Below a full report: -------------------------------------------- # Scenario ## Setup ./bird -l ## birdcl no side effect bird (v2.14)> echo 'restrict ?' | ./birdcl -l BIRD v2.14 ready. bird> restrict ? restrict Restrict current CLI session to safe commands bird> bird (v2.14)> ## birdc side effect bird (v2.14)> echo 'restrict ?' | ./birdc -l BIRD v2.14 ready. bird> restrict ? restrict Restrict current CLI session to safe commands bird> restrict Access restricted bird (v2.14)> # Expected behaviour Like birdcl, just show help and exit # Actual behaviour Executes the <cmd> after showing the help # Tested version BIRD v2.14 (birdc.c last edited on 2017, so I guess this is on all versions the same) --------------------------------------------

2 1

OSPF Type 5 LSA route install behavior difference
by Bala Sajja 05 Feb '24

05 Feb '24

Hi Bird users, I am seeing different behavior with respect to OSPF type 5 LSA routes. The setup contains two routers R1,R2 as shown below. OSPF is running on eth2 of both routers R1,R2. R1 router eth1 interface is in OSPF passive mode. We are configuring a static route on R1 and it is getting advertised into the OSPF domain. The static route configured on R1 is: 33.0.0.0/8 gateway 172.19.13.1 (eth1:172.19.13.128/24) R1 (eth2:55.55.55.100/24 ) <--------------------------> (eth2: 55.55.55.200/24) R2 CASE 1: When Static routes first get added on R1, after that eth1 interface added to OSPF on R1. We can see the Static route always present on R2 as a type 5 route and there is no impact of removing eth1 from OSPF on the R1 router. CASE 2: When eth1 added as OSPF interface on R1 first, then static route added later. Deletion eth1 from OSPF on R1 , deletes static route also from R2. Incase of Case 2, the behavior we observe is a bug ? Case 1, 2 bird logs are attached. Regards, Bala.

1 0

Setting the source IP for routes injected by bird
by Nico Schottelius 04 Feb '24

04 Feb '24

Good evening, I have seen that the static protocol has the attribute "krt_prefsrc" which seems to fit the source IP as seen by the kernel: [18:44] server120.place15:~# ip route get 2001:4860:4860::8888 2001:4860:4860::8888 from :: via 2001:7f8:24::4a dev eth7 proto bird src 2001:7f8:24::ae metric 32 pref medium On this particular machine bird (?) selected 2001:7f8:24::ae as the source address, which makes sense as it is the only IP address on the interface. However that address is a peering IP address and traffic to it is not forwarded outside of the peering. Now I can easily add another ip address on the interface that is within a prefix that I control, but how do I ensure that the route is changed with another source ip address? I think what I am looking for is something on the line of -------------------------------------------------------------------------------- protocol kernel kernel_v6 { ipv6 { export all; prefsrc ... ; }; } -------------------------------------------------------------------------------- Above obviously has a problem, as the preferred address is different, depending on which device the route is applied to...but as far as I can see bird adds the route, so bird probably also need to set the preferred source? Or is it something better solved in the kernel somehow? Cheers, Nico -- Sustainable and modern Infrastructures by ungleich.ch

2 2

Question about MPLS L3VPN
by Marcel Menzel 27 Jan '24

27 Jan '24

Hello List, I am doing a test setup with the new MPLS L3VPN feature (for background information: I am running IPsec with L2TP on top, with OSPF as IGP and iBGP between loopbacks) with one router receiving an IPv6 fulltable via eBGP and the other one establishing the BGP session through a tunnel described above, and I noticed periodic high CPU usage on the router receiving the routes at the end of the tunnel. It seems, that BIRD keeps exporting the whole table to the kernel every 30 seconds, as it is configured in the kernel protocol scan time with the "vrf" directive set: root@sendak ~ # ip monitor | grep --line-buffered 2001:1568::/33 | gawk '{ print strftime(), $0 }' Sat Jan 27 13:21:10 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:21:40 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:22:09 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:22:37 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:23:04 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:23:30 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium Sat Jan 27 13:23:57 CET 2024 2001:1568::/33 encap mpls 1000 via fe80::9cd4:daff:feb9:cf5d dev l2tp1s0 table 1 proto bird metric 32 pref medium although there's no update for that route (I'm taking here the prefix to monitor where the bird webserver lies in) received from upstream: root@lotor ~ # ip monitor | grep --line-buffered 2001:1568::/33 <empty> I set different timers on the kernel protocols because trying to debug these was just too much noise in my logs. As I don't think that this is desired behavior, has anyone else noticed this? It might also be that systemd-networkd or strongswan keeps interfering here (at least systemd-networkd shows high CPU usage when the kernel RIB changes, strongswan did this aswell but I tweaked config for it to ignore BIRD routes), but I don't see the reason why. "ManageForeignRoutingPolicyRules=no" and "ManageForeignRoutes=no" is set in networkd.conf and the ip monitor above only shows inserts. The setup without MPLS but with separate XFRM tunnels per VRF (that's why I want to use L3VPN, to just have 1 Tunnel with MPLS on top) works flawlessly. The (I think) relevant parts for the config on the 2nd router with the tunnel are: ipv4 table master4; ipv6 table master6; mpls table mtab; mpls domain mdom { label range bgprange { start 2000; length 1000; }; } vpn4 table vpntab4; vpn6 table vpntab6; ipv4 table t_as207781_ipv4; ipv6 table t_as207781_ipv6; protocol device { scan time 5; } protocol kernel { scan time 60; mpls { table mtab; export all; }; } protocol kernel { scan time 30; <- this timer causes BIRD to re-export the whole table over and over again learn; vrf "vrf-as207781"; kernel table 1; ipv6 { table t_as207781_ipv6; import none; export accept; }; } protocol ospf v3 o_mclnet_ipv6 { vrf default; ipv6 { import all; export where source ~ [ RTS_DEVICE, RTS_STATIC ]; }; area 0 { interface "l2tp*" { hello 1; type pointopoint; }; interface "br*", "dummy*" { stub; }; }; } protocol l3vpn m_as207781 { vrf "vrf-as207781"; ipv4 { table t_as207781_ipv4; }; ipv6 { table t_as207781_ipv6; }; vpn4 { table vpntab4; }; vpn6 { table vpntab6; }; mpls { label policy vrf; }; rd 64512:1; import target [(rt, 64512, 1)]; export target [(rt, 64512, 1)]; } protocol bgp i_lotor { mpls { label policy aggregate; }; vpn4 mpls { table vpntab4; import all; export all; extended next hop on; next hop self on; }; vpn6 mpls { table vpntab6; import all; export all; extended next hop on; next hop self on; }; local fd00::3 as 64512; neighbor fd00::2 as 64512; } Kind regards, Marcel Menzel

2 3