Kernel protocol and IPv6 route issue with Bird 2.0
Hi guys,
I'm having an issue where IPv6 routes from the kernel routing table
don't appear to end up in my t_kernel6 table. Despite the next-hop being
link-local and the interface being UP.
IPv4 routes I have no problem with, working as expected.
I must be doing something wrong on my side, if someone could kindly
point me in the right direction.
(the below is configuration I'm testing with, I have manually set the
MAC addresses and IP's for testing purposes within a LXC container so I
can test results across configuration changes)
Here is the snippet of config with...
protocol device {
description "Device protocol";
scan time 10;
};
protocol kernel kernel4 {
description "Kernel protocol for IPv4";
metric 600;
learn;
ipv4 {
table t_kernel4;
export all;
import all;
};
};
protocol kernel kernel6 {
description "Kernel protocol for IPv6";
metric 600;
learn;
ipv6 {
table t_kernel6;
export all;
import all;
};
};
Here is the error I'm getting in my logs and fc11::/64 is not being
shown in my t _kernel6 table...
2019-09-11 11:40:36.653 KRT: Received route fc11::/64 with strange
next-hop fc10::2
The interface is however UP and fc10::2 is link local.
Here is the output of 'ip link'... (eth1 is UP)
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0@if3: mtu 1500 qdisc noqueue
state UP mode DEFAULT group default qlen 1000
link/ether 02:01:00:00:00:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0
4: *eth1*@if5: mtu 1500 qdisc
noqueue state *UP* mode DEFAULT group default qlen 1000
link/ether 02:01:00:00:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
Here is the output of 'ip -6 address'...
1: lo: mtu 65536 state UNKNOWN qlen 1
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0@if3: mtu 1500 state UP qlen 1000
inet6 fc00::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::1:ff:fe00:1/64 scope link
valid_lft forever preferred_lft forever
4: eth1@if5: mtu 1500 state UP qlen 1000
inet6 *fc10::1/64* scope global
valid_lft forever preferred_lft forever
inet6 fe80::1:ff:fe00:2/64 scope link
valid_lft forever preferred_lft forever
Here is the kernel routing table 'ip -6 route'...
fc00::/64 dev eth0 proto kernel metric 256 pref medium
fc10::/64 dev eth1 proto kernel metric 256 pref medium
*fc11::/64 via fc10::2 dev eth1 metric 1024 pref medium*
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
Kind Regards
-N
Re: Kernel protocol and IPv6 route issue with Bird 2.0
On 9/11/19 2:23 PM, Ondrej Zajicek wrote: > On Wed, Sep 11, 2019 at 12:31:16PM +0000, Nigel Kukard wrote: >> Hi guys, >> >> I'm having an issue where IPv6 routes from the kernel routing table >> don't appear to end up in my t_kernel6 table. Despite the next-hop being >> link-local and the interface being UP. >> ... >> Here is the error I'm getting in my logs and fc11::/64 is not being >> shown in my t _kernel6 table... >> >> 2019-09-11 11:40:36.653 KRT: Received route fc11::/64 with strange >> next-hop fc10::2 >> ... >> Here is the kernel routing table 'ip -6 route'... >> >> fc00::/64 dev eth0 proto kernel metric 256 pref medium >> fc10::/64 dev eth1 proto kernel metric 256 pref medium >> *fc11::/64 via fc10::2 dev eth1 metric 1024 pref medium* >> fe80::/64 dev eth0 proto kernel metric 256 pref medium >> fe80::/64 dev eth1 proto kernel metric 256 pref medium > Hi > > Works for me: > > bird> show route table t_kernel6 > Table t_kernel6: > fc11::/64unicast [kernel2 16:20:13.398] (10) > via fc10::2 on eth0 > > What is your 'show interfaces' status? > I believe I just found the issue. On the first kernel table scan, I get the "strange next-hop" for the IPv6 route. This is perhaps a second or so after the environment is created. On the second kernel table scan the route is correctly added. In normal circumstances it shouldn't be a problem. I triggered it by running tests a few seconds after bird started. Either adding a sleep after starting bird exceeding the scan time or reducing the scan time worked for me. My first guess would be IPv6 DAD causing it, however I've not looked further into it or tested disabling IPv6 DAD. Sorry for the noise. -N
Explicit as-path filtering (with prepending allowed)
Hi guys, Is there perhaps an equivalent in BIRD for the following... ^(65000_)+(65101_)+(65253_)+$ The closest I could come was the following, but I am unsure if it would match if any of the networks prepend. if (bgp_path ~ [= 65000 65101 65253 =]) -N
RTS_STATIC_DEVICE oddity
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 device1: Initializing
2020-08-21 05:57:43 kernel4: Channel ipv4 connected to table
t_kernel4
2020-08-21 05:57:43 kernel4: Initializing
2020-08-21 05:57:43 kernel6: Channel ipv6 connected to table
t_kernel6
2020-08-21 05:57:43 kernel6: Initializing
2020-08-21 05:57:43 p_master4_to_kernel4: Channel pri connected
to table master4
2020-08-21 05:57:43 p_master4_to_kernel4: Channel sec connected
to table t_kernel4
2020-08-21 05:57:43 p_master4_to_kernel4: Initializing
2020-08-21 05:57:43 p_master6_to_kernel6: Channel pri connected
to table master6
2020-08-21 05:57:43 p_master6_to_kernel6: Channel sec connected
to table t_kernel6
2020-08-21 05:57:43 p_master6_to_kernel6: Initializing
2020-08-21 05:57:43 static4: Channel ipv4 connected to table
t_static4
2020-08-21 05:57:43 static4: Initializing
2020-08-21 05:57:43 static6: Channel ipv6 connected to table
t_static6
2020-08-21 05:57:43 static6: Initializing
2020-08-21 05:57:43 p_static4_to_master4: Channel pri connected
to table t_static
Re: RTS_STATIC_DEVICE oddity
On 2020-08-22 17:02, Ondrej Zajicek wrote: > On Fri, Aug 21, 2020 at 06:23:57AM +0000, Nigel Kukard wrote: >> 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. > Hi > > RTS_STATIC_DEVICE was removed in BIRD 2 (we probably forgot it in > documentation and parser, so it does not generate errors). > > It does not make sense as one can have ECMP route with one direct > (device) and one indirect (gateway) nexthop. Thanks Ondrej, I checked over the code today and found no use of RTS_STATIC_DEVICE, I then checked where RTS_STATIC was used and saw the nexthop code, so I was bordering the same conclusion. Thanks again for clarifying, much appreciated. -N
PATCH: Added BGP attribute example to docs
Hi guys,
It took me some time to figure this out, perhaps a slight improvement to
the docs attached may help. :)
-N
>From 0975f466e6cdf53223c1f6a2dab62d1ee80a2268 Mon Sep 17 00:00:00 2001
From: Nigel Kukard
Date: Mon, 16 Nov 2020 12:16:26 +
Subject: [PATCH] Doc: Added example of static routes with BGP large
communities
Signed-off-by: Nigel Kukard
---
doc/bird.sgml | 4
1 file changed, 4 insertions(+)
diff --git a/doc/bird.sgml b/doc/bird.sgml
index a62d3371..10a856be 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -5167,6 +5167,10 @@ protocol static {
ospf_tag = 2; # Set extended attribute
bfd; # BFD-controlled route
};
+ route 192.168.11.0/24 via 198.51.100.100 {
+ bgp_community.add((65535, 65281)); # Set extended BGP attribute
+ bgp_large_community.add((64512, 1, 1)); # Set extended BGP attribute
+ };
}
--
2.29.2
Re: BGP with ECMP and weight control
On 11/19/20 9:25 PM, Maria Matějka wrote: > Hello! > > Would it be feasible for you to have a special route attribute to be > set in filters that would control the nexthop weight? That seems to be > probably a most simple solution. That would certainly work for me, one can then use any combination of the other attributes to set the weight in a filter. Not only simple, but probably the most flexible. -N
OSPF protocol and export filters for E2 routes
Hi guys, I'm wondering if someone knows the answer to this, here is the setup... R1 => R2 => R3 - R1 advertises a route (in this case 0.0.0.0/0) to R2 (from static or kernel) - R2 accepts the route with "import all" - R2 has a filter for the route with "export my_filter;" and in that filter there is a "reject;" - R3 should not receive the route, correct? What I am seeing is this works 100% as expected in RIP. When I try the same thing with OSPF, I am not seeing it being rejected on R2. Infact, I am not seeing the E2 route at all pass through the export filter. But I am receiving it on R3. I just want to make sure this is expected or unexpected behavior? My use case is if R1 advertises a default route via OSPF, I was looking at filtering that default route out on R2 so it is not advertised to R3. -N
Re: Garbage collection of unused dynamic BGP neighbours
On 9/21/22 08:37, Tore Anderson via Bird-users wrote: * Ondrej Zajicek i think that 'configure' CLI command should remove unused dynamic BGP instaces as a side-effect of its unused protocols cleanup code, even if there is no change in configuration. I had already tried that unsuccessfully, but did some more testing now and found out that it works IFF you manually disable the protocol instance first: $ birdc BIRD 2.0.10 ready. bird> show protocols dynbgp3 Name Proto Table State Since Info dynbgp3BGP---start 10:28:22.421 Passive Received: Administrative shutdown bird> configure Reading configuration from /etc/bird.conf Reconfigured bird> show protocols dynbgp3 Name Proto Table State Since Info dynbgp3BGP---start 10:28:22.421 Passive Received: Administrative shutdown bird> disable dynbgp3 dynbgp3: disabled bird> show protocols dynbgp3 Name Proto Table State Since Info dynbgp3BGP---down 10:29:02.779 bird> configure Reading configuration from /etc/bird.conf Reconfigured bird> show protocols dynbgp3 syntax error, unexpected CF_SYM_UNDEFINED, expecting END or CF_SYM_KNOWN or TEXT or ALL Thank you for pointing me in the right direction! If there's such a thing as a feature request list for BIRD, it would be nice to have a switch to have this done automatically added to it. After all, the client can always reconnect and get a new dynamic protocol instance. I'd also really really like a feature like this, for my use case it would be very nice to maybe have a switch where you can set the garbage collection interval. Like 1 hour, 1 day, 1 week ... etc. -N
Doing something wrong with VRF's
Hi there,
I'm wondering if someone could point out what I'm doing wrong here? all
my routes are being added to the system main table and not my VRF.
I could swear I had this working 100% (I took my config and added vrf
"vrf0" to each protocol), i then regenerated my config file using my
software, rebooted and its not worked since. I can't seem to find what I
broke.
Here is my interfaces... the t0p0 and t0p1 are ip6gretap's, dummy0 is
just a loopback dummy interface. All are slave to vrf0. lgtm.
4: dummy0: mtu 1500 qdisc noqueue master
vrf0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fe:dc:20:04:15:27 brd ff:ff:ff:ff:ff:ff
5: vrf0: mtu 65575 qdisc noqueue state UP
mode DEFAULT group default qlen 1000
link/ether 8a:8e:21:3d:c4:c9 brd ff:ff:ff:ff:ff:ff
8: t0p0@e0p0: mtu 1430 qdisc fq_codel
master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether b2:da:ee:78:04:1f brd ff:ff:ff:ff:ff:ff
9: t0p1@e0p0: mtu 1430 qdisc fq_codel
master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fa:61:19:72:65:d8 brd ff:ff:ff:ff:ff:ff
the output from ip rule is this... lgtm.
1000: from all lookup [l3mdev-table]
The routes within the VRF look like this, lgtm ... ip route show vrf vrf0
X/30 dev t0p0 proto kernel scope link src A
Y/30 dev t0p1 proto kernel scope link src B
Z/27 dev dummy0 proto kernel scope link src C
My main routing table looks like this... lgtm, I don't even have the
interfaces or anything configured for them in the main table outside the
VRF.
default via 169.254.1.1 dev e0p0 proto static metric 1000
169.254.1.1 dev e0p0 proto kernel scope link src D metric 256
E dev e0p0 proto kernel metric 256 pref medium
F via fe80::1 dev e0p0 proto static metric 300 pref medium
G via fe80::1 dev e0p0 proto static metric 300 pref medium
fe80::/64 dev e0p0 proto kernel metric 256 pref medium
default via fe80::1 dev e0p0 proto static metric 1000 pref medium
My bird config is below ... I made sure to add vrf "vrf0" to all
protocols. I searched the mailing list and I can't see what I did wrong
here.
OSPF comes up fine, I can ping inside the VRF fine, but all my routes
are being added to the main system table.
I cut out the filters, they're not doing anything interesting. Despite
BGP being mentioned in the config below, I don't have it configured atm.
# Kernel Table
ipv4 table t_kernel4;
ipv6 table t_kernel6;
# Direct Tables:
ipv4 table t_direct4;
ipv6 table t_direct6;
# OSPF Tables
ipv4 table t_ospf4;
ipv6 table t_ospf6;
...
protocol kernel kernel4 {
vrf "vrf0";
description "Kernel protocol for IPv4";
metric 600; # Set the BIRD metric to be used when creating kernel
routes to fall in line with our OS
learn; # Learn routes from the kernel
persist; # Dont remove routes on BIRD shutdown
merge paths on; # Merge similar BGP paths into a multi-hop
ipv4 {
table t_kernel4;
export all;
import all;
};
};
protocol kernel kernel6 {
vrf "vrf0";
description "Kernel protocol for IPv6";
metric 600; # Set the BIRD metric to be used when creating kernel
routes to fall in line with our OS
learn; # Learn routes from the kernel
persist; # Dont remove routes on BIRD shutdown
merge paths on; # Merge similar BGP paths into a multi-hop
ipv6 {
table t_kernel6;
export all;
import all;
};
};
protocol pipe p_master4_to_kernel4 {
vrf "vrf0";
description "Pipe from master4 to t_kernel4";
table master4;
peer table t_kernel4;
export filter f_master4_kernel4_export;
import filter f_master4_kernel4_import;
};
protocol pipe p_master6_to_kernel6 {
vrf "vrf0";
description "Pipe from master6 to t_kernel6";
table master6;
peer table t_kernel6;
export filter f_master6_kernel6_export;
import filter f_master6_kernel6_import;
};
protocol device {
vrf "vrf0";
description "Device protocol";
scan time 10;
};
protocol direct direct4 {
vrf "vrf0";
description "Direct protocol for IPv4";
ipv4 {
table t_direct4;
export none;
import all;
};
};
protocol direct direct6 {
vrf "vrf0";
description "Direct protocol for IPv6";
ipv6 {
table t_direct6;
export none;
import all;
};
};
protocol pipe p_master4_to_direct4 {
vrf "vrf0";
description "Pipe from master4 to t_direct4";
table master4;
peer table t_direct4;
export none;
import all;
};
protocol pipe p_master6_to_direct6 {
vrf "vrf0";
description "Pipe from master6 to t_direct6";
table master6;
peer table t_direct6;
export none;
import all;
};
protocol ospf v2 ospf4 {
vrf "vrf0";
description "OSPF protocol for IPv4";
ipv4 {
table t_ospf4;
export filter f_ospf_export;
import filter f_ospf_import;
};
area 0 {
interface "dummy0" {
cost 10;
ecmp weight 1;
stub;
};
interface "t0p0" {
cost 1000;
ecmp weight 1;
};
interface "t0p1" {
cost 1000;
ecmp weight 1;
};
};
};
protocol ospf v3 ospf6 {
vrf "vrf0";
description "OSPF protoc
Re: Doing something wrong with VRF's
Well .. I feel embarrassed now. The issue was a missing "kernel table
;" in the kernel protocol.
-N
On 9/28/23 15:29, Nigel Kukard via Bird-users wrote:
Hi there,
I'm wondering if someone could point out what I'm doing wrong here?
all my routes are being added to the system main table and not my VRF.
I could swear I had this working 100% (I took my config and added vrf
"vrf0" to each protocol), i then regenerated my config file using my
software, rebooted and its not worked since. I can't seem to find what
I broke.
Here is my interfaces... the t0p0 and t0p1 are ip6gretap's, dummy0 is
just a loopback dummy interface. All are slave to vrf0. lgtm.
4: dummy0: mtu 1500 qdisc noqueue master
vrf0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fe:dc:20:04:15:27 brd ff:ff:ff:ff:ff:ff
5: vrf0: mtu 65575 qdisc noqueue state UP
mode DEFAULT group default qlen 1000
link/ether 8a:8e:21:3d:c4:c9 brd ff:ff:ff:ff:ff:ff
8: t0p0@e0p0: mtu 1430 qdisc
fq_codel master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether b2:da:ee:78:04:1f brd ff:ff:ff:ff:ff:ff
9: t0p1@e0p0: mtu 1430 qdisc
fq_codel master vrf0 state UNKNOWN mode DEFAULT group default qlen 1000
link/ether fa:61:19:72:65:d8 brd ff:ff:ff:ff:ff:ff
the output from ip rule is this... lgtm.
1000: from all lookup [l3mdev-table]
The routes within the VRF look like this, lgtm ... ip route show vrf vrf0
X/30 dev t0p0 proto kernel scope link src A
Y/30 dev t0p1 proto kernel scope link src B
Z/27 dev dummy0 proto kernel scope link src C
My main routing table looks like this... lgtm, I don't even have the
interfaces or anything configured for them in the main table outside
the VRF.
default via 169.254.1.1 dev e0p0 proto static metric 1000
169.254.1.1 dev e0p0 proto kernel scope link src D metric 256
E dev e0p0 proto kernel metric 256 pref medium
F via fe80::1 dev e0p0 proto static metric 300 pref medium
G via fe80::1 dev e0p0 proto static metric 300 pref medium
fe80::/64 dev e0p0 proto kernel metric 256 pref medium
default via fe80::1 dev e0p0 proto static metric 1000 pref medium
My bird config is below ... I made sure to add vrf "vrf0" to all
protocols. I searched the mailing list and I can't see what I did
wrong here.
OSPF comes up fine, I can ping inside the VRF fine, but all my routes
are being added to the main system table.
I cut out the filters, they're not doing anything interesting. Despite
BGP being mentioned in the config below, I don't have it configured atm.
# Kernel Table
ipv4 table t_kernel4;
ipv6 table t_kernel6;
# Direct Tables:
ipv4 table t_direct4;
ipv6 table t_direct6;
# OSPF Tables
ipv4 table t_ospf4;
ipv6 table t_ospf6;
...
protocol kernel kernel4 {
vrf "vrf0";
description "Kernel protocol for IPv4";
metric 600; # Set the BIRD metric to be used when creating kernel
routes to fall in line with our OS
learn; # Learn routes from the kernel
persist; # Dont remove routes on BIRD shutdown
merge paths on; # Merge similar BGP paths into a multi-hop
ipv4 {
table t_kernel4;
export all;
import all;
};
};
protocol kernel kernel6 {
vrf "vrf0";
description "Kernel protocol for IPv6";
metric 600; # Set the BIRD metric to be used when creating kernel
routes to fall in line with our OS
learn; # Learn routes from the kernel
persist; # Dont remove routes on BIRD shutdown
merge paths on; # Merge similar BGP paths into a multi-hop
ipv6 {
table t_kernel6;
export all;
import all;
};
};
protocol pipe p_master4_to_kernel4 {
vrf "vrf0";
description "Pipe from master4 to t_kernel4";
table master4;
peer table t_kernel4;
export filter f_master4_kernel4_export;
import filter f_master4_kernel4_import;
};
protocol pipe p_master6_to_kernel6 {
vrf "vrf0";
description "Pipe from master6 to t_kernel6";
table master6;
peer table t_kernel6;
export filter f_master6_kernel6_export;
import filter f_master6_kernel6_import;
};
protocol device {
vrf "vrf0";
description "Device protocol";
scan time 10;
};
protocol direct direct4 {
vrf "vrf0";
description "Direct protocol for IPv4";
ipv4 {
table t_direct4;
export none;
import all;
};
};
protocol direct direct6 {
vrf "vrf0";
description "Direct protocol for IPv6";
ipv6 {
table t_direct6;
export none;
import all;
};
};
protocol pipe p_master4_to_direct4 {
vrf "vrf0";
description "Pipe from master4 to t_direct4";
table master4;
peer table t_direct4;
export none;
import all;
};
protocol pipe p_master6_to_direct6 {
vrf "vrf0";
description "Pipe from master6 to t_direct6";
table master6;
peer table t_direct6;
export none;
import all;
};
protocol ospf v2 ospf4 {
vrf "vrf0";
Re: Doing something wrong with VRF's
On 9/28/23 17:07, Daniel Gröber wrote: On Thu, Sep 28, 2023 at 04:03:33PM +, Nigel Kukard via Bird-users wrote: Well .. I feel embarrassed now. The issue was a missing "kernel table ;" in the kernel protocol. Don't feel bad. I was going to look into using VRFs with bird and now there's a nice worked example ready to play with at in my inbox :) --Daniel Awesome :), hope its some use! -N OpenPGP_signature.asc Description: OpenPGP digital signature
Possibly a way to match Kernel.source field?
Hi there fellow BIRD users, Does anyone perhaps know if there is a way to match this field? I'm trying to create a filter to prevent these from being imported into my one table which I feed into OSPF6. I've tried, Kernel.source and kernel.source sadly with no luck. This item corresponds to the "ip route" protocol field. Kind Regards Nigel
Re: Possibly a way to match Kernel.source field?
On 9/30/23 20:31, Alexander Zubkov wrote: Hi, I'm sure one of the attributes mentioned in the documentation fits your need: https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.7 <https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.7> Can't believe I am so blind, thanks! :) -N Regards, Alexander Zubkov On Sat, Sep 30, 2023, 22:20 Nigel Kukard via Bird-users wrote: Hi there fellow BIRD users, Does anyone perhaps know if there is a way to match this field? I'm trying to create a filter to prevent these from being imported into my one table which I feed into OSPF6. I've tried, Kernel.source and kernel.source sadly with no luck. This item corresponds to the "ip route" protocol field. Kind Regards Nigel
Re: notification scripts ?
On 12/13/23 10:14, Maria Matejka via Bird-users wrote: Hello! On 2023-12-13 10:19, Kees Meijs | Nefos wrote: Hi, On 12-12-2023 17:20, Maria Matejka via Bird-users wrote: We're prototyping a machine-friendly interface which should include, in some later versions, also subscribing to various notifications. Hear hear! Probably asked before, but being integrated (albeit with a shim) in SNMP would be lovely. We are finishing some SNMP support as well but mostly we're trying to have a YANG-defined API encoded in CBOR. And because this is quite a new technology, we may create some relevant tools during the process; if anybody is interested in some specifics, we may keep you informed about the development. Any API interface that can acquire the data available with birdc commands would be very greatly appreciated. Even if the commands just hand an option to return results were in some machine readable format like JSON. I currently have a python daemon that connects to the control socket which is rather tedious in terms of parsing all the command outputs. :) -N
Large communities indicating RPKI VALID status
Hi all, I was busy reading https://bgpfilterguide.nlnog.net/guides/reject_invalids/ and noticed the following text... Note: REALLY DONT store the validation state inside a bgp_community or bgp_large_community or bgp_ext_community variables. It can cause CPU & memory overload resulting in convergence performance issues. I was wondering if this is still an issue and if it would still be a bad idea to indicate that RPKI was VALID using communities on multiple full BGP feeds? Is anyone doing this at present? are you seeing significant load? Kind Regards Nigel
Re: Large communities indicating RPKI VALID status
Hi there Richard, On 4/29/24 19:14, Richard Laager wrote: Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes. Why would one want to accept INVALID at all? If we agree one would reject INVALID, then what is left to tag? For my specific use case I wanted to add a community for VALID and UNKNOWN. I'm going to look into the non-transitive extended communities to see how this works out. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Large communities indicating RPKI VALID status
On 4/29/24 19:33, Job Snijders wrote: On Mon, 29 Apr 2024 at 21:27, Nigel Kukard via Bird-users wrote: Hi there Richard, On 4/29/24 19:14, Richard Laager wrote: Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and simply reject INVALID routes. Why would one want to accept INVALID at all? If we agree one would reject INVALID, then what is left to tag? For my specific use case I wanted to add a community for VALID and UNKNOWN. I'm going to look into the non-transitive extended communities to see how this works out. Sure, but why add such communities? It reduces performance and doesn’t add security benefits. OTOH - it can satisfy curiosity about where traffic is flowing - then again, using a traffic analyser like pmacct or Kentik helps offer insight how much traffic is going to Valid vs Not-Found destinations, without the need to add any communities. I’m not saying you shouldn’t pursue adding a few non-transitive extended communities here and there for your use case; just that generally speaking, operators probably should not apply different policies for Valid and Not-Found states. Well, basically to summarize, I have quite a number of edges. My filtering occurs on the edges, including filtering of INVALID. I'm using bird to gather all prefixes from all routers using add-paths so I can easily do searches on my dashboard and graphically map paths to destinations and visually see other possible paths that are not best path. As my filtering occurs on the edge I don't have a way on my dashboard to see if the prefix was VALID or UNKNOWN. I thought it would be something useful to see so I can color the routes that are VALID in a dark green or have a small green box with [RPKI VALID] in it next to the prefix. But I certainly see the points raised. It's not used for anything more than analysis and visual display. I'm looking into pmacct and Opensearch to see if I can get Netflow/IPFIX data to help with insight into traffic flows (slightly different to visually seeing possible traffic paths). I'm very new to Elasticseach and Opensearch though and would appreciate if anyone has any recommendations of opensource platforms I can use to give me some info from Netflow/IPFIX data I'd really appreciate it. I did check out Kentik and Elastiflow, but my network is small and doesn't really have the income to support a paid product right now if I can achieve reasonable results with other options. -N OpenPGP_signature.asc Description: OpenPGP digital signature
