- Bird-users - Mailing Lists

Fwd: Unable to get Bird 2 to listen on the BGP socket
by Skyler Mäntysaari 06 Sep '20

06 Sep '20

Ah, seems that I were mistaken. I needed to use /128 prefix for the addresses and it works now as expected. On 05/09/2020 16.18, Ondrej Zajicek wrote: > On Sat, Sep 05, 2020 at 02:29:34PM +0300, Skyler Mäntysaari wrote: >> Hi, >> >> My bird version is 2.0.7, running on aarch64 with 5.7.16 kernel using raspberrypi kernel tree for BCM2711. >> The exact same behavior happens if the source is built from the bird ebuild in the Gentoo portage tree, or directly from source. >> >> show interfaces: https://dpaste.com/GRHNJS2D3 > Hi > > Seems to me like misconfiguration: > > wg1 up (index=7) > PtP Multicast AdminUp LinkUp MTU=1340 > fe80:10::2/127 (Preferred, opposite fe80:10::3, scope link) > > as213021_hel_node: Waiting for fe80:10::1%wg1 to become my neighbor > > > You have fe80:10::2/127 prefix on wg1, which contains fe80:10::2 and > fe80:10::3, but waiting for fe80:10::1, which is outside of the range (it > would be in fe80:10::0/127 network). >

1 0

Re: Unable to get Bird 2 to listen on the BGP socket
by Skyler Mäntysaari 03 Sep '20

03 Sep '20

You probably missed the fact that I’m using Link-Local Addresses. "Multihop BGP cannot be used with link-local addresses" > On 3. Sep 2020, at 17.52, Valery Lutoshkin <vpluto(a)gmail.com> wrote: > > Try it. > It is not about real multihop session, it is about how bird choose interfaces to listen. > > From: Skyler Mäntysaari <sm(a)samip.fi> <mailto:sm@samip.fi> > Reply: Skyler Mäntysaari <sm(a)samip.fi> <mailto:sm@samip.fi> > Date: 3 September 2020 at 21:51:41 > To: Valery Lutoshkin <vpluto(a)gmail.com> <mailto:vpluto@gmail.com> > Subject: Re: Unable to get Bird 2 to listen on the BGP socket > >> They're directly connected, so it's not a multihop session so no. >> >> On Thu, Sep 3, 2020, at 17:49, Valery Lutoshkin wrote: >>> Hi! >>> >>> Have you tried to add option “multihop” in the BGP peer configuration? Usually it helps. >>> >>> Best regards. >>> Valery >>> >>> >>> >>> From: Skyler Mäntysaari <sm(a)samip.fi> <mailto:sm@samip.fi> >>> Reply: Skyler Mäntysaari <sm(a)samip.fi> <mailto:sm@samip.fi> >>> Date: 3 September 2020 at 21:48:13 >>> To: bird-users(a)network.cz <mailto:bird-users@network.cz> <bird-users(a)network.cz> <mailto:bird-users@network.cz> >>> Subject: Re: Unable to get Bird 2 to listen on the BGP socket >>> >>>> >>>> Yes, absolutely nothing appears to be binded according to netstat and nmap. >>>> >>>> I only saw bird bind the control socket when debugging with strace. >>>> >>>> The logs only has the "Waiting for fe80:10::1%wg1 to bocame my neighbor". >>>> >>>> The user is root, and I can ping/nmap fine over the tunnel. >>>> >>>> On Thu, Sep 3, 2020, at 10:04, Alexander Zubkov wrote: >>>>> Hi, >>>>> >>>>> So nothing in netstat? And what have you seen in strace? Maybe >>>>> something in logs? >>>>> >>>>> On Thu, Sep 3, 2020 at 1:05 AM Skyler Mäntysaari <sm(a)samip.fi <mailto:sm@samip.fi>> wrote: >>>>> > >>>>> > Hi there, >>>>> > >>>>> > I’m fairly certain that my issue is something rather small, or stupid but I’m unable to get Bird to listen on the 179 port. >>>>> > >>>>> > The other side has direct in the protocol definition which is correct, and I tried this side with that as well but it only says “as213021_hel_node: Waiting for fe80:10::1%wg1 to become my neighbor” so I don’t really have more clues. >>>>> > >>>>> > I did try to do strace and look for bind events, but couldn’t find any except for the control socket. >>>>> > >>>>> > My config can be seen here: https://dpaste.com/6P6NAUPNX <https://dpaste.com/6P6NAUPNX> & peer config: https://dpaste.com/HJ3SNL8RH <https://dpaste.com/HJ3SNL8RH> >>>>> > >>>>>

1 0

[patch] Assertion failed in add_tail caused by default_log_list
by Mikael 31 Aug '20

31 Aug '20

Hello, the following configuration file (without a log configuration) causes assertion failed in add_tail. There is no output but it can be seen with gdb. protocol device { interface "*"; } Tested version: git dc8d9dec Proposed patch see attachment. /Mikael

1 0

OSPF - lost routes and socket error
by Boris Tassou 27 Aug '20

27 Aug '20

Hi, I use bird 2.0.7 on FreeBSD 12.1 for 3 routers with bgp and ospf/ospf v3. This is my weathermap : https://librenms.securmail.fr/weathermap/ (to help for understand my network architecture) I have a configuration for my internal subnet : protocol ospf ospf_ipv4_internal { ipv4 { import keep filtered; import limit 200 action block; import filter { if (net ~ [ 10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+ ]) then { accept; } else { reject; } }; export none; }; area 0.0.0.0 { interface "tap0"; }; }; The same for IPv6 : protocol ospf v3 ospf_ipv6_internal { ipv6 { import all; import keep filtered; import limit 200 action block; import filter { if (net ~ [ ::/0 ]) then { reject; } if (net ~ [ fd00:208::/32+ ]) then accept; }; export none; }; area 0.0.0.0 { interface "tap0"; }; }; But, sometimes, ospf_ipv4_internal on 2 routers (always the same) lost routes learn by this ospf configuration. On the router who has the routes (on iFog router) : bird> show route all protocol ospf_ipv4_internal Table master4: 192.168.0.0/24 unicast [ospf_ipv4_internal 06:16:20.781] E2 (150/10/64) [172.16.56.3] via 172.16.56.3 on tap0 Type: OSPF-E2 univ OSPF.metric1: 10 OSPF.metric2: 64 OSPF.tag: 0x00000000 OSPF.router_id: 172.16.56.3 172.16.55.0/24 unicast [ospf_ipv4_internal 06:16:14.779] I (150/20) [172.16.55.7] via 172.16.56.2 on tap0 Type: OSPF univ OSPF.metric1: 20 OSPF.router_id: 172.16.55.7 172.16.56.0/24 unicast [ospf_ipv4_internal 06:01:36.079] I (150/10) [193.148.249.128] dev tap0 Type: OSPF univ OSPF.metric1: 10 OSPF.router_id: 193.148.249.128 On the router who lost them (on Scipio router) : bird> show route all protocol ospf_ipv4_internal Table master4: 172.16.56.0/24 unicast [ospf_ipv4_internal 09:33:17.530] I (150/10) [89.234.186.30] dev tap0 Type: OSPF univ OSPF.metric1: 10 OSPF.router_id: 89.234.186.30 On this router, in the log file i have this error : 2020-08-27 09:50:12.349 <ERR> ospf_ipv4_internal: Socket error on tap0: Invalid argument The configuration is the same between all routers. I missed something but i don't understand what ^^ Can you help me on this? Thanks

1 0

bird6 replacing linknet routes with indirect OSPF routes when BFD flaps
by Alasdair Muckart 27 Aug '20

27 Aug '20

I've come across a problem that's bitten me a couple of times doing a 'birdc6 configure soft' where bird6 removes the interface route for a BGP neighbour with BFD enabled and the router ends up learning it via OSPF on a different interface. I've also seen this on connected routers where the OSPF reconvergence clobbers the static route even for interfaces not directly connected on the router where the reload is happening. I'm running version 1.6.3 - not the latest but upgrading the routers is a non- trivial exercise at the moment. The neighbour config (without import/export lists) is simple: protocol bgp ns3 from customer { description "ns3"; neighbor aaaa:bbb:ff00:30::1 as 64514; ttl security; bfd; } It doesn't happen every time, and it doesn't happen with every neighbour, but I can't see why BIRD is withdrawing the route to begin with and it means we can't read in new BIRD configuration without an outage window. One telltale is bird6 complaining about receiving a route with a "strange next-hop" because it doesn't have a route for it. Jul 23 19:01:27 ns3 bird6[2912]: KRT: Received route ::/0 with strange next- hop aaaa:bbb:ff00:30:: Jul 23 19:01:28 ns3 bird6[2912]: KRT: Received route ::/0 with strange next-hop aaaa:bbb:ff00:30:: ifdown/ifup on the interface isn't sufficient to bring the route back, it has to be manually added with: ip -6 route replace aaaa:bbb:ff00:30::/127 dev eth0.551 metric 256 Some of the relevant logs: root@prod-router1:~# grep ns3 /var/log/syslog.1 | tail -6 Jul 23 20:00:45 prod-router1 bird6: ns3: Connecting to aaaa:bbb:ff00:30::1 from local address aaaa:bbb:ff00:30:: Jul 23 20:00:45 prod-router1 bird6: ns3: Connection lost (Network is unreachable) Jul 23 20:00:45 prod-router1 bird6: ns3: Connect delayed by 5 seconds Jul 23 20:00:46 prod-router1 bird6: Disabling protocol ns3 Jul 23 20:00:46 prod-router1 bird6: ns3: Shutdown requested Jul 23 20:00:46 prod-router1 bird6: ns3: Down Connected route being removed and replaced with a route learned from OSPF from a different device: root@prod-router1:/var/log# grep bird6 syslog.1 | grep aaaa:bbb:ff00:30:: | grep -v "Connecting to" | grep -v bfd1: Jul 23 18:30:03 prod-router1 bird6: edge > removed [replaced] aaaa:bbb:ff00:30::/127 dev eth0.551 Jul 23 18:30:03 prod-router1 bird6: kernel1 < added aaaa:bbb:ff00:30::/127 via fe80::42f2:e9ff:feef:a855 on eth2.540 Jul 23 18:30:03 prod-router1 bird6: edge > added [best] aaaa:bbb:ff00:30::/127 dev eth0.551 Jul 23 18:30:03 prod-router1 bird6: kernel1 < removed aaaa:bbb:ff00:30::/127 via fe80::42f2:e9ff:feef:a855 on eth2.540 Jul 23 19:23:04 prod-router1 bird6: edge > removed [replaced] aaaa:bbb:ff00:30::/127 dev eth0.551 Jul 23 19:23:04 prod-router1 bird6: kernel1 < added aaaa:bbb:ff00:30::/127 via fe80::42f2:e9ff:feef:a855 on eth2.540 Jul 23 19:23:05 prod-router1 bird6: ns3: Waiting for aaaa:bbb:ff00:30::1 to become my neighbor Jul 23 19:23:08 prod-router1 bird6: edge > added [best] aaaa:bbb:ff00:30::/127 dev eth0.551 Jul 23 19:23:08 prod-router1 bird6: kernel1 < removed aaaa:bbb:ff00:30::/127 via fe80::42f2:e9ff:feef:a855 on eth2.540 Has anyone else experienced this? Any known workarounds? If a direct route is in the BIRD routing table, will that prevent OSPF from trying to install the same route in the kernel table? I'm wondering if putting the direct routes into the BIRD table would stop that behaviour from OSPF. Thanks. -- Alasdair Muckart Network Engineer Catalyst IT - Expert Open Source Solutions Mobile: +64 22 638 5141 | DDI: +64 4 897 7794 | www.catalyst.net.nz CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267.

1 0

ospf routes
by Mehdi Rukmawan 24 Aug '20

24 Aug '20

Hello, I'm just starting bird with vm and i'm running it on gns3. first of all the ospf is running and can see the routes from he neighbour as we can see below : root@gns3:/etc/netplan# birdc show route BIRD 1.6.3 ready. 1.1.1.1/32 via 192.168.70.1 on ens3 [ospf1 07:36:32] * I (150/6) [1.1.1.1] 192.168.70.0/30 dev ens3 [ospf1 07:34:53] * I (150/5) [192.168.168.1] 192.168.40.0/30 via 192.168.70.1 on ens3 [ospf1 07:36:32] * I (150/6) [1.1.1.1] 192.168.10.0/30 via 192.168.70.1 on ens3 [ospf1 07:36:32] * I (150/6) [1.1.1.1] 192.168.20.0/30 via 192.168.70.1 on ens3 [ospf1 07:36:32] * I (150/6) [1.1.1.1] 192.168.168.1/32 dev lo [ospf1 07:34:53] * I (150/0) [192.168.168.1] but i can't see the routes from the machine which is running bird. is this a bug ? or i have something wrong with ospf configuration ? root@gns3:/etc/netplan# ip route 169.254.0.0/16 dev ens3 scope link metric 1000 192.168.70.0/30 dev ens3 proto kernel scope link src 192.168.70.2 metric 100 regards,

4 6

RTS_STATIC_DEVICE oddity
by Nigel Kukard 22 Aug '20

22 Aug '20

Hi guys, I may be going blind or just dumb, but I could of sworn this worked like a year ago in v2. I have a t_static4 table, with a static device route, I pipe this to my master4 table, then pipe my master4 table to RIP and only pick out the RTS_STATIC_DEVICE routes. However the source is set to RTS_STATIC not RTS_STATIC_DEVICE? enum(30)1 Full config file attached. I tried to summarize it a bit below. I also attached a diagram.svg of the r1 setup below. -N ipv4 table t_static4; protocol static static4 { ipv4 { table t_static4; export none; import all; }; * route 192.168.20.0/24 via "eth1";* }; protocol pipe p_static4_to_master4 { table t_static4; peer table master4; export all; import none; }; ipv4 table t_rip4; filter f_rip_export4 { # Redistribute static device routes if (source = RTS_STATIC_DEVICE) then { accept; } # Redistribute RIP routes if (source = RTS_RIP) then { accept; } reject; }; filter f_rip_import4 { # Import all RIP routes by default accept; }; filter f_rip_master4_export { # Do not export default route to master if (net = 0.0.0.0/0) then { reject; } # Only export RIP routes o the master table if (source = RTS_RIP) then { accept; } # Reject everything else; reject; }; filter f_rip_master4_import { print "rip to master"; print source; * # Import static device routes into RIP (redistribute static_device) if (source = RTS_STATIC_DEVICE) then { accept; }* reject; }; protocol rip rip4 { description "RIP protocol for IPv4"; ipv4 { table t_rip4; export filter f_rip_export4; import filter f_rip_import4; }; interface "eth0" { update time 5; metric 2; }; }; Here is the result.... (sorry its in JSON)... ------------------------------------------------------------------------------------- RIP4(r1) -------------------------------------------------------------------------------------- {} ------------------------------------------------------------------------------------ STATIC4(r1) ------------------------------------------------------------------------------------ {'192.168.20.0/24': [{'nexthops': [{'interface': 'eth1'}], 'pref': '200', 'prefix_type': 'unicast', 'protocol': 'static4', 'since': '2020-08-21 05:57:43', 'type': ['static', 'univ']}]} ------------------------------------------------------------------------------------ MASTER4(r1) ------------------------------------------------------------------------------------ {'192.168.20.0/24': [{'nexthops': [{'interface': 'eth1'}], 'pref': '200', 'prefix_type': 'unicast', 'protocol': 'static4', 'since': '2020-08-21 05:57:43', 'type': ['static', 'univ']}]} ------------------------------------------------------------------------------------ KERNEL4(r1) ------------------------------------------------------------------------------------ {'192.168.20.0/24': [{'nexthops': [{'interface': 'eth1'}], 'pref': '200', 'prefix_type': 'unicast', 'protocol': 'static4', 'since': '2020-08-21 05:57:43', 'type': ['static', 'univ']}]} And the full log... ------------------------------------------------------------------------------------ LOGFILE(r1) ------------------------------------------------------------------------------------ 2020-08-21 05:57:43 <TRACE> device1: Initializing 2020-08-21 05:57:43 <TRACE> kernel4: Channel ipv4 connected to table t_kernel4 2020-08-21 05:57:43 <TRACE> kernel4: Initializing 2020-08-21 05:57:43 <TRACE> kernel6: Channel ipv6 connected to table t_kernel6 2020-08-21 05:57:43 <TRACE> kernel6: Initializing 2020-08-21 05:57:43 <TRACE> p_master4_to_kernel4: Channel pri connected to table master4 2020-08-21 05:57:43 <TRACE> p_master4_to_kernel4: Channel sec connected to table t_kernel4 2020-08-21 05:57:43 <TRACE> p_master4_to_kernel4: Initializing 2020-08-21 05:57:43 <TRACE> p_master6_to_kernel6: Channel pri connected to table master6 2020-08-21 05:57:43 <TRACE> p_master6_to_kernel6: Channel sec connected to table t_kernel6 2020-08-21 05:57:43 <TRACE> p_master6_to_kernel6: Initializing 2020-08-21 05:57:43 <TRACE> static4: Channel ipv4 connected to table t_static4 2020-08-21 05:57:43 <TRACE> static4: Initializing 2020-08-21 05:57:43 <TRACE> static6: Channel ipv6 connected to table t_static6 2020-08-21 05:57:43 <TRACE> static6: Initializing 2020-08-21 05:57:43 <TRACE> p_static4_to_master4: Channel pri connected to table t_static4 2020-08-21 05:57:43 <TRACE> p_static4_to_master4: Channel sec connected to table master4 2020-08-21 05:57:43 <TRACE> p_static4_to_master4: Initializing 2020-08-21 05:57:43 <TRACE> p_static6_to_master6: Channel pri connected to table t_static6 2020-08-21 05:57:43 <TRACE> p_static6_to_master6: Channel sec connected to table master6 2020-08-21 05:57:43 <TRACE> p_static6_to_master6: Initializing 2020-08-21 05:57:43 <TRACE> rip4: Channel ipv4 connected to table t_rip4 2020-08-21 05:57:43 <TRACE> rip4: Initializing 2020-08-21 05:57:43 <TRACE> rip6: Channel ipv6 connected to table t_rip6 2020-08-21 05:57:43 <TRACE> rip6: Initializing 2020-08-21 05:57:43 <TRACE> p_rip4_to_master4: Channel pri connected to table t_rip4 2020-08-21 05:57:43 <TRACE> p_rip4_to_master4: Channel sec connected to table master4 2020-08-21 05:57:43 <TRACE> p_rip4_to_master4: Initializing 2020-08-21 05:57:43 <TRACE> p_rip6_to_master6: Channel pri connected to table t_rip6 2020-08-21 05:57:43 <TRACE> p_rip6_to_master6: Channel sec connected to table master6 2020-08-21 05:57:43 <TRACE> p_rip6_to_master6: Initializing 2020-08-21 05:57:43 <TRACE> device1: Starting 2020-08-21 05:57:43 <TRACE> device1: Scanning interfaces 2020-08-21 05:57:43 <TRACE> device1: State changed to up 2020-08-21 05:57:43 <TRACE> kernel4: Starting 2020-08-21 05:57:43 <TRACE> kernel4: State changed to up 2020-08-21 05:57:43 <TRACE> kernel6: Starting 2020-08-21 05:57:43 <TRACE> kernel6: State changed to up 2020-08-21 05:57:43 <TRACE> p_master4_to_kernel4: Starting 2020-08-21 05:57:43 <TRACE> p_master4_to_kernel4: State changed to up 2020-08-21 05:57:43 <TRACE> p_master6_to_kernel6: Starting 2020-08-21 05:57:43 <TRACE> p_master6_to_kernel6: State changed to up 2020-08-21 05:57:43 <TRACE> static4: Starting 2020-08-21 05:57:43 <TRACE> static4: State changed to up 2020-08-21 05:57:43 <TRACE> static4 > added [best] 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> static6: Starting 2020-08-21 05:57:43 <TRACE> static6: State changed to up 2020-08-21 05:57:43 <TRACE> static6 > added [best] fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> p_static4_to_master4: Starting 2020-08-21 05:57:43 <TRACE> p_static4_to_master4: State changed to up 2020-08-21 05:57:43 <TRACE> p_static6_to_master6: Starting 2020-08-21 05:57:43 <TRACE> p_static6_to_master6: State changed to up 2020-08-21 05:57:43 <TRACE> rip4: Starting 2020-08-21 05:57:43 <TRACE> rip4: State changed to up 2020-08-21 05:57:43 <TRACE> rip6: Starting 2020-08-21 05:57:43 <TRACE> rip6: State changed to up 2020-08-21 05:57:43 <TRACE> p_rip4_to_master4: Starting 2020-08-21 05:57:43 <TRACE> p_rip4_to_master4: State changed to up 2020-08-21 05:57:43 <TRACE> p_rip6_to_master6: Starting 2020-08-21 05:57:43 <TRACE> p_rip6_to_master6: State changed to up 2020-08-21 05:57:43 <INFO> Started 2020-08-21 05:57:43 <TRACE> kernel4 < interface lo goes up 2020-08-21 05:57:43 <TRACE> kernel4 < interface eth0 goes up 2020-08-21 05:57:43 <TRACE> kernel4 < interface eth1 goes up 2020-08-21 05:57:43 <TRACE> kernel6 < interface lo goes up 2020-08-21 05:57:43 <TRACE> kernel6 < interface eth0 goes up 2020-08-21 05:57:43 <TRACE> kernel6 < interface eth1 goes up 2020-08-21 05:57:43 <TRACE> p_static4_to_master4 < added 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> p_static4_to_master4 > added [best] 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> p_master4_to_kernel4 < added 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> p_master4_to_kernel4 > added [best] 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> p_master4_to_kernel4 < rejected by protocol 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> kernel4 < added 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> p_static4_to_master4 < rejected by protocol 192.168.20.0/24 unicast 2020-08-21 05:57:43 <INFO> rip to master 2020-08-21 05:57:43 <INFO> (enum 30)1 2020-08-21 05:57:43 <TRACE> p_rip4_to_master4 < filtered out 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> p_static4_to_master4 < rejected by protocol 192.168.20.0/24 unicast 2020-08-21 05:57:43 <TRACE> p_static6_to_master6 < added fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> p_static6_to_master6 > added [best] fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> p_master6_to_kernel6 < added fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> p_master6_to_kernel6 > added [best] fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> p_master6_to_kernel6 < rejected by protocol fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> kernel6 < added fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> p_static6_to_master6 < rejected by protocol fc20::/64 unicast 2020-08-21 05:57:43 <INFO> rip to master 2020-08-21 05:57:43 <INFO> (enum 30)1 2020-08-21 05:57:43 <TRACE> p_rip6_to_master6 < filtered out fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> p_static6_to_master6 < rejected by protocol fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> rip4 < interface lo goes up 2020-08-21 05:57:43 <TRACE> rip4 < interface eth0 goes up 2020-08-21 05:57:43 <TRACE> rip4: Adding interface eth0 2020-08-21 05:57:43 <TRACE> rip4 < interface eth1 goes up 2020-08-21 05:57:43 <TRACE> rip6 < interface lo goes up 2020-08-21 05:57:43 <TRACE> rip6 < interface eth0 goes up 2020-08-21 05:57:43 <TRACE> rip6: Adding interface eth0 2020-08-21 05:57:43 <TRACE> rip6 < interface eth1 goes up 2020-08-21 05:57:43 <INFO> rip to master 2020-08-21 05:57:43 <INFO> (enum 30)1 2020-08-21 05:57:43 <TRACE> p_rip4_to_master4 < filtered out 192.168.20.0/24 unicast 2020-08-21 05:57:43 <INFO> rip to master 2020-08-21 05:57:43 <INFO> (enum 30)1 2020-08-21 05:57:43 <TRACE> p_rip6_to_master6 < filtered out fc20::/64 unicast 2020-08-21 05:57:43 <TRACE> kernel4: Scanning routing table 2020-08-21 05:57:43 <TRACE> kernel4: Pruning table t_kernel4 2020-08-21 05:57:43 <TRACE> kernel4: Pruning inherited routes 2020-08-21 05:57:43 <TRACE> kernel6: Pruning table t_kernel6 2020-08-21 05:57:43 <TRACE> kernel6: Pruning inherited routes 2020-08-21 05:57:43 <TRACE> rip6: Starting interface eth0 2020-08-21 05:57:43 <TRACE> rip4: Starting interface eth0 2020-08-21 05:57:43 <TRACE> rip4: Interface timer fired for eth0 2020-08-21 05:57:43 <TRACE> rip4: Sending triggered updates for eth0 2020-08-21 05:57:43 <TRACE> rip6: Interface timer fired for eth0 2020-08-21 05:57:43 <TRACE> rip6: Sending triggered updates for eth0 2020-08-21 05:57:45 <TRACE> rip4: Interface timer fired for eth0 2020-08-21 05:57:45 <TRACE> rip4: Sending regular updates for eth0 2020-08-21 05:57:46 <TRACE> rip6: Interface timer fired for eth0 2020-08-21 05:57:46 <TRACE> rip6: Sending regular updates for eth0 2020-08-21 05:57:50 <TRACE> rip4: Interface timer fired for eth0 2020-08-21 05:57:50 <TRACE> rip4: Sending regular updates for eth0

2 2

Route prefix aggregation
by Michal Humpula 20 Aug '20

20 Aug '20

Hi, is it possible to do a route aggregation in BGP or OSPF in current bird? I have found only old discussion from 2012, which suggested it's not possible. My use case is simple: before exporting routes from internal OSPF to external BGP I would like to aggregate them a little bit before propagating them to external peer (so he receives only one or two, instead of hundreds). Cheers Michal

2 1

[BFD] BFD is Not working after system reboot.
by seunghwan hwang 18 Aug '20

18 Aug '20

Hello. BFD is Not working normally. My configuration is shown below. OS: Ubuntu 18.04 Kernel: 4.15.0-54-generic BIRD ver: 1.6.8 ================================== protocol bfd { multihop { min rx interval 300 ms; min tx interval 300 ms; multiplier 3; }; } protocol bgp as1 { import all; export all; local ~ as ~; neighbor ~ as ~; enable route refresh off; hold time 90; bfd on; } protocol bgp as2 { import all; export all; local ~ as ~; neighbor ~ as ~; enable route refresh off; hold time 90; bfd on; } ================================== After system reboot(# shutdown -r now), BGP neighbor is established, But BFD sessions are stuck in 'INIT' status. And BIRD does not send BFD packets. BFD sessions have recovered after restart protocol bfd1(# birdc restart bfd1). Is it a normal situation? I think BFD has to start the mechanism after BGP neighbor is UP. Is there any missing part of my configurations? Please check it. Regards

3 11

BGP VPNv4 Ext Community Filter
by Hombach, Tobias (external - Project) 17 Aug '20

17 Aug '20

Hi, we use BIRD 2.0.7 BGP VPNv4 and need to filter extended BGP communities on ingress. Config snippet: define PFILTER_RT = [ (rt, 65100, *), (rt, 65101, *), (rt, 65102, *) ]; filter IMPORT_FILTER { bgp_ext_community.filter(PFILTER_RT_MASTER); accept; } protocol bgp 'my-router' from VPN4_S3_TPL_BGP_DEFAULT { vpn4 mpls { import filter IMPORT_FILTER; }; } This is working as expected. We discovered that RO communities are filtered too (not a surprise) and we extended the definition: define PFILTER_RT = [ (rt, 65100, *), (rt, 65101, *), (rt, 65102, *), (ro, 65100, *), (ro, 65101, *), (ro, 65102, *) ]; We dont need to filter strict for RO communities and best would be to allow all. Is there a better way to allow only defined RT and all RO communities? Are there any plans to allow wildcard or range in these definitions? Like: (ro, *, *) or (ro, 100..300, *) Another question: Are other extended community sub types beside RO and RT (as defined in RFC 7153) filtered by function bgp_ext_community.filter() ? Thanks in advance Regards Tobias

1 0