`default cost` setting is not applied
Hi,
I have the following configuration:
```
define ospf_v4_routes = [
198.19.0.0/16
];
filter ospf_export {
if (net.type = NET_IP4 && ! (net ~ [ 0.0.0.0/0 ])) then reject;
accept;
}
filter ospf_import {
if (net.type = NET_IP4 && net ~ ospf_v4_routes) then accept;
reject;
}
protocol ospf v2 ospfv4 {
debug all;
ipv4 {
import filter ospf_import;
export filter ospf_export;
};
area 0.0.0.0 {
interface "lo1" { stub yes; };
interface "vlan600" {
type ptp;
cost 15;
bfd on;
};
};}
```
I would expect the metric around 300 + cost of the interface but I get this
route metric
"E2 0.0.0.0/0 [15/1] via 198.19.4.65, vlan600"
in the switch.
When I set the metric manually in the export function:
```
filter ospf_export {
if (net.type = NET_IP4 && ! (net ~ [ 0.0.0.0/0 ])) then reject;
ospf_metric1 = 300; unset(ospf_metric2);
accept;}
```
I get the correct metric:
```
E1 0.0.0.0/0 [315] via 198.19.4.65, vlan600
```
Any idea what could be the issue ?
Did I misunderstood the usage of the `default cost` setting?
Benoît
Re: OSPF bad packet
OK I see thanks for the feedback. This may be related to the upgrade to freebsd 14 and latest bird 1.15.1 which is compiled now by default with netlink support instead of rtsock. I I will try the rtsock version to compare. Benoit On Monday, April 15th, 2024 at 16:37, Ondrej Zajicek wrote: > On Mon, Apr 15, 2024 at 02:22:01PM +0000, Benoit Chesneau wrote: > > > Hi Ondrej, > > > > Not sure I undersand, these are the IPs of this router itself: > > > > `root@gw0:~ # ifconfig vlan600 vlan600: > > flags=1008843 metric 0 mtu > > 9000 description: backbone > > options=1c680703 > > ether fa:9b:80:06:d7:f9 inet 198.19.4.33 netmask 0xffe0 broadcast > > 198.19.4.63 inet6 fe80::f89b:80ff:fe06:d7f9%vlan600 prefixlen 64 scopeid > > 0x5 inet6 2001:7f8::2:103::1 prefixlen 64 groups: vlan vlan: 600 vlanproto: > > 802.1q vlanpcp: 0 parent interface: mce0 media: Ethernet 25GBase-SR > > status: active nd6 > > options=21` > > > > I didn't find equivalent router id on the network. I also tried to uniquely > > change the ID but the same error appears. Is there anything I could do to > > debug this issue ? > > > Hi > > It seems like the OSPF receives its own packets back. There is a check > that should make them to be silently ignored: > > /* We want just packets from sk->iface. Unfortunately, on BSD we cannot filter > > out other packets at kernel level and we receive all packets on all sockets */ > if (sk->lifindex != sk->iface->index) > > return 1; > > But for some reason it does not work in your case, AFAIK it worked in > older BSDs. It should be harmless outside of spanning your logs. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) > "To err is human -- to blame it on a computer is even more so."
Re: OSPF bad packet
Hi Ondrej,
Not sure I undersand, these are the IPs of this router itself:
```
root@gw0:~ # ifconfig vlan600
vlan600: flags=1008843 metric
0 mtu 9000
description: backbone
options=1c680703
ether fa:9b:80:06:d7:f9
inet 198.19.4.33 netmask 0xffe0 broadcast 198.19.4.63
inet6 fe80::f89b:80ff:fe06:d7f9%vlan600 prefixlen 64 scopeid 0x5
inet6 2001:7f8::2:103::1 prefixlen 64
groups: vlan
vlan: 600 vlanproto: 802.1q vlanpcp: 0 parent interface: mce0
media: Ethernet 25GBase-SR
status: active
nd6 options=21
```
I didn't find equivalent router id on the network. I also tried to uniquely
change the ID but the same error appears. Is there anything I could do to debug
this issue ?
OSPF configuration (I edited IPV6 address):
```
define ospf_v4_routes = [ 198.19.0.0/16 ];
define ospf_v6_routes = [ 2001:7f8:2:100::/56 ];
filter ospf_export {
if (net.type = NET_IP4 && net ~ [ 0.0.0.0/0 ]) then accept;
if (net.type = NET_IP6 && net ~ [ ::0/0 ]) then accept;
ospf_metric1 = 200; unset(ospf_metric2);
reject;
}
filter ospf_import {
if (net.type = NET_IP4 && net ~ ospf_v4_routes) then accept;
if (net.type = NET_IP6 && net ~ ospf_v6_routes) then accept;
reject;
}
protocol ospf v2 ospfv4 {
debug all;
ipv4 {
import filter ospf_import;
export filter ospf_export;
};
area 0.0.0.0 {
interface "lo1" { stub yes; };
interface "vlan600" {
type ptp;
cost 15;
bfd on;
};
};
}
protocol ospf v3 ospfv6 {
ipv6 {
import filter ospf_import;
export filter ospf_export;
};
area 0 {
interface "lo1" { stub yes; };
interface "vlan600" {
type ptp;
cost 15;
bfd off;
};
};
}
```
Benoit
On Monday, April 15th, 2024 at 01:12, Benoit Chesneau
wrote:
> Hi,
>
> I have installed latest bird 2.15.1 with ntet link support on Freebsd and I
> contunuously get the following messages:
>
> ```
> 2024-04-14 23:09:12.386 ospfv6: Bad packet from
> fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0)2024-04-14
> 23:09:12.386 ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own
> router ID (0)
> 2024-04-14 23:09:12.386 ospfv6: Bad packet from
> fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0)
> 2024-04-14 23:09:12.386 ospfv4: Bad packet from 198.19.4.33 via vlan600
> - my own router ID (0)
> 2024-04-14 23:09:18.155 ospfv4: HELLO packet received from nbr
> 198.19.0.2 on vlan600
> 2024-04-14 23:09:22.382 ospfv4: HELLO packet sent via vlan600
> 2024-04-14 23:09:22.383 ospfv6: Bad packet from
> fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0)
> 2024-04-14 23:09:22.383 ospfv4: Bad packet from 198.19.4.33 via vlan600
> - my own router ID (0)
> 2024-04-14 23:09:22.383 ospfv6: Bad packet from
> fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0)
> 2024-04-14 23:09:22.383 ospfv4: Bad packet from 198.19.4.33 via vlan600
> - my own router ID
> ```
>
> What could be the reason for such error? MTU looks fine, and I can retrieve
> the route via osf.
>
>
> Benoît
OSPF bad packet
Hi, I have installed latest bird 2.15.1 with ntet link support on Freebsd and I contunuously get the following messages: ``` 2024-04-14 23:09:12.386 ospfv6: Bad packet from fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0) 2024-04-14 23:09:12.386 ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own router ID (0) 2024-04-14 23:09:12.386 ospfv6: Bad packet from fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0) 2024-04-14 23:09:12.386 ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own router ID (0) 2024-04-14 23:09:18.155 ospfv4: HELLO packet received from nbr 198.19.0.2 on vlan600 2024-04-14 23:09:22.382 ospfv4: HELLO packet sent via vlan600 2024-04-14 23:09:22.383 ospfv6: Bad packet from fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0) 2024-04-14 23:09:22.383 ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own router ID (0) 2024-04-14 23:09:22.383 ospfv6: Bad packet from fe80::f89b:80ff:fe06:d7f9 via vlan600 - my own router ID (0)2024-04-14 23:09:22.383 ospfv4: Bad packet from 198.19.4.33 via vlan600 - my own router ID ``` What could be the reason for such error? MTU looks fine, and I can retrieve the route via osf. Benoît
Re: announce IPV4 loopback via an OSPF v3 backbone
correction: the error message is not related particularly to bird but seems
related to this issue in latest freebsd release:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275341
Once fixed though, I have the same results. routes are not applied to the
kernel. ospfv3. Applying a `/31` to the point to point interface:
```
vlan200: flags=1008843 metric
0 mtu 150
0
options=4600703
ether 9a:c7:bd:e8:62:dc
inet 10.200.1.1 netmask 0xfffe broadcast 255.255.255.255
inet6 fe80::98c7:bdff:fee8:62dc%vlan200 prefixlen 64 scopeid 0x4
groups: vlan
vlan: 200 vlanproto: 802.1q vlanpcp: 0 parent interface: iavf0
media: Ethernet autoselect (10Gbase-SR )
status: active nd6 options=23
```
allows the route to be shared . Configuration is :
```
protocol ospf v3 ospfv4 {
ipv4 {
import filter ospf_import;
export filter ospf_export;
};
area 0 {
interface "lo1" { stub yes; };
interface "vlan200" {
type ptp;
cost 10;
};
};}
```
Benoît Chesneau, Enki Multimedia
—
t. +33608655490
Sent with [Proton Mail](https://proton.me/) secure email.
On Sunday, March 31st, 2024 at 01:42, Benoit Chesneau
wrote:
> I get the same result as well. On freebsd when starting I also get this
> message " Cannot find next hop address".
>
> Benoît
>
> On Saturday, March 30th, 2024 at 16:04, Pim van Pelt via Bird-users
> wrote:
>
>> Hoi,
>>
>> On 3/30/24 15:50, Pim van Pelt wrote:
>>
>>> OSPFv3 adjacency did establish, but no routes were exchanged (also none
>>> with filter 'export all; import all;') --
>>
>> As a quick follow up to this: routes are exchanged, but they are not emitted
>> to the kernel.
>> root@vpp0-2:~# birdc show ospf state
>> BIRD 2.14 ready.
>>
>> area 0.0.0.0
>>
>> router 192.168.10.2
>> distance 0
>> router 192.168.10.3 metric 5
>> stubnet 192.168.10.2/32 metric 0
>> stubnet 192.168.10.2/32 metric 0
>> stubnet 192.168.10.2/32 metric 0
>> external 192.168.10.2/32 metric2 1
>> external 192.168.10.0/24 metric2 1
>>
>> router 192.168.10.3
>> distance 5
>> router 192.168.10.2 metric 5
>> stubnet 192.168.10.3/32 metric 0
>> stubnet 192.168.10.3/32 metric 0
>> stubnet 192.168.10.3/32 metric 0
>> external 192.168.10.3/32 metric2 1
>> I am not seeing any Netlink route messages for any of the LSAs from neighbor
>> 192.168.10.3 (colored in red above).
>> Could it be that when using an ipv4 channel with OSPFv3, Bird ought to
>> program these across address families?
>>
>> pim@vpp0-2:~$ sudo ip ro add 192.168.10.3/32 via inet6
>> fe80::5054:ff:fef0:1130 dev e1
>> groet,
>> Pim
>>
>> --
>> Pim van Pelt
>> PBVP1-RIPE -
>> https://ipng.ch/
Re: announce IPV4 loopback via an OSPF v3 backbone
I get the same result as well. On freebsd when starting I also get this message " Cannot find next hop address". Benoît On Saturday, March 30th, 2024 at 16:04, Pim van Pelt via Bird-users wrote: > Hoi, > > On 3/30/24 15:50, Pim van Pelt wrote: > >> OSPFv3 adjacency did establish, but no routes were exchanged (also none with >> filter 'export all; import all;') -- > > As a quick follow up to this: routes are exchanged, but they are not emitted > to the kernel. > root@vpp0-2:~# birdc show ospf state > BIRD 2.14 ready. > > area 0.0.0.0 > > router 192.168.10.2 > distance 0 > router 192.168.10.3 metric 5 > stubnet 192.168.10.2/32 metric 0 > stubnet 192.168.10.2/32 metric 0 > stubnet 192.168.10.2/32 metric 0 > external 192.168.10.2/32 metric2 1 > external 192.168.10.0/24 metric2 1 > > router 192.168.10.3 > distance 5 > router 192.168.10.2 metric 5 > stubnet 192.168.10.3/32 metric 0 > stubnet 192.168.10.3/32 metric 0 > stubnet 192.168.10.3/32 metric 0 > external 192.168.10.3/32 metric2 1 > I am not seeing any Netlink route messages for any of the LSAs from neighbor > 192.168.10.3 (colored in red above). > Could it be that when using an ipv4 channel with OSPFv3, Bird ought to > program these across address families? > > pim@vpp0-2:~$ sudo ip ro add 192.168.10.3/32 via inet6 > fe80::5054:ff:fef0:1130 dev e1 > groet, > Pim > > -- > Pim van Pelt > PBVP1-RIPE - > https://ipng.ch/
announce IPV4 loopback via an OSPF v3 backbone
Hi everyone, I was reading the ospv3 spec and this link https://networklessons.com/ospf/ospfv3-for-ipv4- and was wondering if such features is supported in bird 2. Can we announce loopbacks via OSPFv3 and remove the need to use OSPFv2 and ptp subnets ? I see it as a good opportunity to reduce the usage of the IPv4 addresses if we can just advertise loopbacks... Benoît
Re: point to point connection but no routes imported.
So I have checked the log and I get this from the one that is supposed to
received the full view:
```
2024-02-17 14:26:39.745 ccre1_ipv4_1: State changed to up2024-02-17
14:26:39.745 ccre1_ipv4_1.ipv4 < added 1.1.1.184/29 0L 5G blackhole
2024-02-17 14:26:39.745 ccre1_ipv4_1.ipv4 < filtered out 1.1.1..85/32
9L 9G unicast
2024-02-17 14:26:39.745 ccre1_ipv4_1.ipv4 < filtered out 1.1.1..200/31
9L 9G unicast
2024-02-17 14:26:39.745 ccre1_ipv4_1.ipv4 < filtered out 10.99.1.0/24
7L 8G unicast
2024-02-17 14:26:39.745 ccre1_ipv4_1: Sending UPDATE
2024-02-17 14:26:39.745 ccre1_ipv4_1: Sending END-OF-RIB
2024-02-17 14:26:39.749 ccre1_ipv4_1: Got UPDATE
2024-02-17 14:26:39.749 ccre1_ipv4_1.ipv4 > added [best] 0.0.0.0/0 0L
10G unicast
2024-02-17 14:26:39.749 ccre1_ipv4_1.ipv4 < rejected by protocol
0.0.0.0/0 0L 10G unicast
2024-02-17 14:26:50.944 KRT: Error sending route 1.1.1..85/32 to kernel:
File exists
```
Atter that no routes are sent. I don't really see what's wrong. R2 seems to
correctly send the routes :
```
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 72.11.128.0/19 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 190.5.224.0/22 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 203.146.227.0/24
0L 15G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 156.0.64.0/23 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 154.63.140.0/24 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 102.190.36.0/22 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 87.221.202.0/24 0L
15G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 201.124.8.0/23 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 170.247.208.0/22
0L 16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 180.150.14.0/23 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 190.52.76.0/24 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 109.239.96.0/20 0L
16G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 192.12.54.0/24 0L
15G unicast
2024-02-17 14:17:25.838 home_65001_ipv4.ipv4 < added 36.138.206.0/24 0L
15G unicast
```
Is there any template I could use to send the full view to peer connected to
the router directly using a vlan?
Benoît
On Saturday, February 17th, 2024 at 11:49, Alexander Zubkov
wrote:
> Hi,
>
> Just to be sure. 1.1.1.1 and 1.1.1.2 are not in the single /31.
> Please also provide more details. What protocol output do you show? What
> route do you want from R2 to R1. Please look at things like these:
> show route all
> show route all export
> show route all protocol
>
> On Sat, Feb 17, 2024, 00:21 Benoit Chesneau
> wrote:
>
> > Hi all,
> >
> >
> > I have an issue witth the route import onbetween two machine. They are
> > connected to each others by a vlan and at each end ana /31 is setup. I can
> > ping between each end.
> >
> > R1: VLAN330(1.1.1.1) > R2 : VLAN330(1.1.1.2)
> >
> >
> > R2( 1.1.1.2) is connected to upstreams transit and collect correctly the
> > routes. But when I do the following config on this rouyer (R2):
> >
> > R2 is showing some exported routes but R1 received nothing:
> >
> > ```
> > Route change stats: received rejected filtered ignored accepted
> > Import updates: 1 0 0 0 1
> > Import withdraws: 0 0 --- 0 0
> > Export updates: 934590 27 0 --- 934563
> > Export withdraws: 18 --- --- --- 18
> > ```
> >
> > What could be the issue ?
> >
> >
> >
> >
> > I have the following configuratiosn:
> >
> >
> > R1:
> > ```
> > define AS65001_IPV4 = [ 1.1.1.184/29{29,32}
> > ];
> >
> >
> > filter ebgp_home_as65001_import {
> > if (net.type = NET_IP4 && ! (net ~ AS65001_IPV4)) then reject;
> > accept;
> > }
> >
> > filter ebgp_home_as65001_export {
> >
> > protocol bgp home_65001_ipv4 {
> > local 1.1.1.2 as 209823;
> > neighbor 1.1.1.1 as 65001;
> > default bgp_med 0;
> > default bgp_local_pref 400;
> > ipv4 {
> > import keep filtered;
> > import filter ebgp_home_as65001_import;
> > export all;
> > next hop self on;
> > };
> > };
> > ```
> >
> > R2:
> >
> > ```
> > router id 1.1.1.1;
> >
> > log syslog all;
> >
> > log "/var/log/bird.log" all;
> > debug protocols all;
> >
> >
> > watchdog warning 5 s;
> > watchdog timeout 30 s;
> >
> >
> > protocol device {
> > scan time 30
point to point connection but no routes imported.
Hi all,
I have an issue witth the route import onbetween two machine. They are
connected to each others by a vlan and at each end ana /31 is setup. I can
ping between each end.
R1: VLAN330(1.1.1.1) > R2 : VLAN330(1.1.1.2)
R2( 1.1.1.2) is connected to upstreams transit and collect correctly the
routes. But when I do the following config on this rouyer (R2):
R2 is showing some exported routes but R1 received nothing:
```
Route change stats: received rejected filteredignored accepted
Import updates: 1 0 0 0 1
Import withdraws:0 0--- 0 0
Export updates: 934590 27 0--- 934563
Export withdraws: 18--------- 18
```
What could be the issue ?
I have the following configuratiosn:
R1:
```
define AS65001_IPV4 = [1.1.1.184/29{29,32}
];
filter ebgp_home_as65001_import {
if (net.type = NET_IP4 && ! (net ~ AS65001_IPV4)) then reject;
accept;
}
filter ebgp_home_as65001_export {
protocol bgp home_65001_ipv4 {
local 1.1.1.2 as 209823;
neighbor 1.1.1.1 as 65001;
default bgp_med 0;
default bgp_local_pref 400;
ipv4 {
import keep filtered;
import filter ebgp_home_as65001_import;
export all;
next hop self on;
};
};
```
R2:
```
router id 1.1.1.1;
log syslog all;
log "/var/log/bird.log" all;
debug protocols all;
watchdog warning 5 s;
watchdog timeout 30 s;
protocol device {
scan time 30;
}
protocol direct {
ipv4;
ipv6;
check link yes;
}
protocol kernel kernel4 {
ipv4 { import all; export where source != RTS_DEVICE; };
learn off;
scan time 300;
}
protocol kernel kernel6 {
ipv6 { import all; export where source != RTS_DEVICE; };
learn off;
scan time 300;
}
protocol static static4 {
ipv4 { export all; };
# Reject default route
route 0.0.0.0/0 unreachable;
# main route
route 1.1.1.184/29 blackhole;
}
filter bgp_export {
if (net.type = NET_IP4 && ! (net ~ [ 1.1.1.184/29 ])) then reject;
accept;
}
template bgp T_GW4 {
local 1.1.1.1 as 65001;
default bgp_med 0;
default bgp_local_pref 400;
multihop;
ipv4 { import keep filtered; import all; export filter bgp_export; next hop
self on; };
}
protocol bgp ccre1_ipv4_1 from T_GW4 { neighbor 1.1.1.2 as ; };
```
Benoît Chesneau, Enki Multimedia
—
t. +33608655490
Sent with Proton Mail secure email.
Re : Re: BIRD at CSNOG and NANOG
disregard . I misread the first slide :) benoît Le mer. 24 janv. 2024 à 11:54, Benoit Chesneau <[beno...@enki-multimedia.eu](mailto:Le mer. 24 janv. 2024 à 11:54, Benoit Chesneau < a écrit : > this is pretty cool. Will it works on freebsd as well? > > benoît > > Le mer. 24 janv. 2024 à 11:10, Ondrej Zajicek > <[santi...@crfreenet.org](mailto:Le mer. 24 janv. 2024 à 11:10, Ondrej > Zajicek < a écrit : > >>> > On Jan 16, 2024, at 20:02, Pim van Pelt via Bird-users >>> > wrote: >>> > >>> > Hoi Maria, >>> > >>> > Thanks for the headsup! I have been anticipating learning more about the >>> > MPLS plans (particularly now that we have Linux CP implementation of MPLS >>> > P/PE). I'd love to learn more, even if my Czech isn't fabulous :) >>> > Ondrej - if there's a presentation or other artefact with details that >>> > you can share after your talk, perhaps I can use some Czech friends, or >>> > Generative AI to translate it and learn about these upcoming capabilities! >>> >>> I’d be interested in the same material as well, but for the EVPN part ;) >> >> Hi, here are slides (attached), they are in english. >> >> The talk was in czech, there is/will be video recording public somewhere >> (AFAIK), but most info are in slides, although just in basic points. >> >> If you have any questions, feel free to ask. >> >> -- >> Elen sila lumenn' omentielvo >> >> Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) >> "To err is human -- to blame it on a computer is even more so."
Re : Re: BIRD at CSNOG and NANOG
this is pretty cool. Will it works on freebsd as well? benoît Le mer. 24 janv. 2024 à 11:10, Ondrej Zajicek <[santi...@crfreenet.org](mailto:Le mer. 24 janv. 2024 à 11:10, Ondrej Zajicek < a écrit : >> > On Jan 16, 2024, at 20:02, Pim van Pelt via Bird-users >> > wrote: >> > >> > Hoi Maria, >> > >> > Thanks for the headsup! I have been anticipating learning more about the >> > MPLS plans (particularly now that we have Linux CP implementation of MPLS >> > P/PE). I'd love to learn more, even if my Czech isn't fabulous :) >> > Ondrej - if there's a presentation or other artefact with details that you >> > can share after your talk, perhaps I can use some Czech friends, or >> > Generative AI to translate it and learn about these upcoming capabilities! >> >> I’d be interested in the same material as well, but for the EVPN part ;) > > Hi, here are slides (attached), they are in english. > > The talk was in czech, there is/will be video recording public somewhere > (AFAIK), but most info are in slides, although just in basic points. > > If you have any questions, feel free to ask. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) > "To err is human -- to blame it on a computer is even more so."
initiate a graceful shutdown on a session
Hi, Is there a way to send an admin shutdown for one connection only? Should i add a `graceful shutdown on the prodtocol and do a soft configure? Benoît
Re: hardware preference
This would be interresting to compare to FreeBSD performance .I wonder if DDPK on on FreeBSD worth it. Are people still using freebsd on networking platforms? It seems that even Bird support is lagging behind linux support sometimes. Benoît --- Original Message --- On Thursday, August 24th, 2023 at 19:57, Pim van Pelt via Bird-users wrote: > Hoi > > I write a lot about (kernel and user space) routing performance on > https://ipng.ch/s/articles/ including hardware and dataplane acceleration > (with VPP and DPDK) on small (Fitlet2 or PCEngines), medium (Supermicro Xeon > 1518D or Netgate 6100), and very large (Ryzen/Milan/Xeon Platinum) systems, > from 100kpps and 1Gbit, all the way to 180Gbit/150Mpps. > > As a control plane, the choice of software be it Bird or FRR or OpenBGPd et > al, is less relevant than your choice of kernel or dataplane acceleration. > > Please take a look and let me know what you think. > > Groet, > Pim > > On Thu, 24 Aug 2023 at 19:33, Ömür Yavuz via Bird-users > wrote: > >> Hello community, I don't know if there is any obstacle for me to ask this >> kind of question. Everything is fine in terms of software, but can I get a >> hardware suggestion that millions of packages will pass through live with >> the servant? Do you have experience with an intel cpu and chelsio t4 nic or >> intel x5xx series? Which enterprise level devices can I use as hardware? >> >> >> Ömür Yavuz > > -- > > Pim van Pelt > PBVP1-RIPE - http://www.ipng.nl/
Re: issue with next hop using freebsd loopback?
Sorry for the cross posting. Just wanted to update there. But I'm not sure it's
an issue with freebsd or bird there. I think Freebsd behaves normally there.
Why the loopback address can't be used as the next hop there if a route exists?
--- Original Message ---
On Friday, June 16th, 2023 at 12:23, Benoit Chesneau
wrote:
> After doing more testing onf Freebsd 13.2 , bird 2.13:
>
> When 1.1.1.1/31 and 1.1.1.2/31 are set on the vlan interface, bird correctly
> announce them as the next hop.
>
> However when 1.1.1.1/32 and 1.1.1.2/32 are set on the loopback interface of
> each instances then the local ip address of the vlan is used.
>
> However when 1.1.1.1/31 and 1.1.1.2/31 are set on the loopback interface of
> each instances then nothing happen. On each nodes 1.1.1.1/31 and 1.1.1.2/31
> resolve to the loopback interface instead of the remote node.
>
>
> Is the behaviour expected ?
>
>
> Benoît
> --- Original Message ---
> On Friday, June 16th, 2023 at 09:49, Benoit Chesneau
> beno...@enki-multimedia.eu wrote:
>
>
>
> > I first posted this issue on the freebsd ml but it's probably more an issue
> > to post there.
> >
> > I have the loopbacks `1.1.1.1` and `1.1.1.2` of 2 nodes distributed using
> > OSPF:
> > `filter ospfexport { if (source = RTS_DEVICE) then accept; reject; }
> > protocol ospf v2 { tick 2; ipv4 { import all; export filter ospfexport; };
> > area 0 { stub no; interface "vlan1", "vlan2" { type ptp; cost 5; };
> > interface "lo1" { stub; }; }; }`
> >
> > `1.1.1.1` is set on the loopback:
> >
> > ```# ifconfig lo1lo1: flags=8049 metric 0
> > mtu 16384
> >
> > options=680003
> >
> > inet6 ::1 prefixlen 128
> > inet6 fe80::1%lo1 prefixlen 64 scopeid 0x9
> > inet 1.1.1.1 netmask 0x
> > groups: lo
> > nd6 options=21
> >
> > # birdc show route for 1.1.1.1BIRD 2.13 ready.
> > Table master4:
> > 1.1.1.1/32 unicast [ospf1 15:56:43.054] ! I (150/0) [1.1.1.1]
> > dev lo1
> > `The distribution works OK and I can ping each others:`
> > # route -n get 1.1.1.2 route to: 1.1.1.2
> > destination: 1.1.1.2
> > gateway: 10.3.1.1
> > fib: 0
> > interface: vlan2212
> > flags:
> >
> > recvpipe sendpipe ssthresh rtt,msec mtu weight expire
> > 0 0 0 0 9000 1 0
> > `But the IP of the loopback can't be used as BGP next hop in the following
> > configuration:` protocol bgp rr_par_ipv4 { local 1.1.1.1 as 65001;
> > neighbor 1.1.1.1.2 as 65001;
> > default bgp_local_pref 40;
> > rr client;
> > ipv4 {
> > import all;
> > export all;
> > next hop self;
> > };
> > };
> > ``The source IP used as next hop is not 1.1.1.1 but the IP `10.3.1.2` of
> > vlan1 used for the connection between 2 nodes:``
> > # ifconfig vlan1vlan2212:
> > flags=8843 metric 0 mtu 9000
> >
> > options=680703
> >
> > ether 50:65:f3:8b:98:71
> > inet 10.3.1.2 netmask 0xff00 broadcast 10.3.1.255
> > inet6 fe80::5265:f3ff:fe8b:9871%vlan2212 prefixlen 64 scopeid 0xd
> > groups: vlan
> > vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: mlxen0
> > media: Ethernet autoselect (40Gbase-CR4 )
> >
> > status: active
> > nd6 options=21
> >
> > ``**Even if I force the next hop address (using `next hop address`) it
> > still take the IP of the vlan. What's wrong?***``
> > $ bird --versionBIRD version 2.13
> > $ uname -nmr
> > myhostname 13.2-RELEASE amd64
> > ```
> >
> > Benoît
Re: issue with next hop using freebsd loopback?
After doing more testing onf Freebsd 13.2 , bird 2.13:
When 1.1.1.1/31 and 1.1.1.2/31 are set on the vlan interface, bird correctly
announce them as the next hop.
However when 1.1.1.1/32 and 1.1.1.2/32 are set on the loopback interface of
each instances then the local ip address of the vlan is used.
However when 1.1.1.1/31 and 1.1.1.2/31 are set on the loopback interface of
each instances then nothing happen. On each nodes 1.1.1.1/31 and 1.1.1.2/31
resolve to the loopback interface instead of the remote node.
Is the behaviour expected ?
Benoît
--- Original Message ---
On Friday, June 16th, 2023 at 09:49, Benoit Chesneau
wrote:
> I first posted this issue on the freebsd ml but it's probably more an issue
> to post there.
>
> I have the loopbacks `1.1.1.1` and `1.1.1.2` of 2 nodes distributed using
> OSPF:
> `filter ospfexport { if (source = RTS_DEVICE) then accept; reject; } protocol
> ospf v2 { tick 2; ipv4 { import all; export filter ospfexport; }; area 0 {
> stub no; interface "vlan1", "vlan2" { type ptp; cost 5; }; interface "lo1" {
> stub; }; }; }`
>
> `1.1.1.1` is set on the loopback:
>
> ```# ifconfig lo1lo1: flags=8049 metric 0 mtu
> 16384
>
> options=680003
>
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo1 prefixlen 64 scopeid 0x9
> inet 1.1.1.1 netmask 0x
> groups: lo
> nd6 options=21
>
> # birdc show route for 1.1.1.1BIRD 2.13 ready.
> Table master4:
> 1.1.1.1/32 unicast [ospf1 15:56:43.054] ! I (150/0) [1.1.1.1]
> dev lo1
> `The distribution works OK and I can ping each others:`
> # route -n get 1.1.1.2 route to: 1.1.1.2
> destination: 1.1.1.2
> gateway: 10.3.1.1
> fib: 0
> interface: vlan2212
> flags:
>
> recvpipe sendpipe ssthresh rtt,msec mtu weight expire
> 0 0 0 0 9000 1 0
> `But the IP of the loopback can't be used as BGP next hop in the following
> configuration:` protocol bgp rr_par_ipv4 { local 1.1.1.1 as 65001;
> neighbor 1.1.1.1.2 as 65001;
> default bgp_local_pref 40;
> rr client;
> ipv4 {
> import all;
> export all;
> next hop self;
> };
> };
> ``The source IP used as next hop is not 1.1.1.1 but the IP `10.3.1.2` of
> vlan1 used for the connection between 2 nodes:``
> # ifconfig vlan1vlan2212: flags=8843
> metric 0 mtu 9000
>
> options=680703
>
> ether 50:65:f3:8b:98:71
> inet 10.3.1.2 netmask 0xff00 broadcast 10.3.1.255
> inet6 fe80::5265:f3ff:fe8b:9871%vlan2212 prefixlen 64 scopeid 0xd
> groups: vlan
> vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: mlxen0
> media: Ethernet autoselect (40Gbase-CR4 )
>
> status: active
> nd6 options=21
>
> ``**Even if I force the next hop address (using `next hop address`) it still
> take the IP of the vlan. What's wrong?***``
> $ bird --versionBIRD version 2.13
> $ uname -nmr
> myhostname 13.2-RELEASE amd64
> ```
>
> Benoît
Re: issue with next hop using freebsd loopback?
To complete previous mail:
```
# birdc show route for 45.13.104.0/22
BIRD 2.13 ready.
Table master4:
45.13.104.0/22 unicast [lumen_3356_ipv4 18:00:36.953] * (100) [ASXXX]
via 212.3.237.177 on vlan53
unicast [rr_par_ipv4 10:01:46.790 from 195.24.245.2]
(100/5) [ASXXX]
via 10.3.1.1 on vlan2212
```
Benoît Chesneau, Enki Multimedia
—
t. +33608655490
Sent with Proton Mail secure email.
--- Original Message ---
On Friday, June 16th, 2023 at 09:49, Benoit Chesneau
wrote:
> I first posted this issue on the freebsd ml but it's probably more an issue
> to post there.
>
> I have the loopbacks `1.1.1.1` and `1.1.1.2` of 2 nodes distributed using
> OSPF:
> `filter ospfexport { if (source = RTS_DEVICE) then accept; reject; } protocol
> ospf v2 { tick 2; ipv4 { import all; export filter ospfexport; }; area 0 {
> stub no; interface "vlan1", "vlan2" { type ptp; cost 5; }; interface "lo1" {
> stub; }; }; }`
>
> `1.1.1.1` is set on the loopback:
>
> ```# ifconfig lo1lo1: flags=8049 metric 0 mtu
> 16384
>
> options=680003
>
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo1 prefixlen 64 scopeid 0x9
> inet 1.1.1.1 netmask 0x
> groups: lo
> nd6 options=21
>
> # birdc show route for 1.1.1.1BIRD 2.13 ready.
> Table master4:
> 1.1.1.1/32 unicast [ospf1 15:56:43.054] ! I (150/0) [1.1.1.1]
> dev lo1
> `The distribution works OK and I can ping each others:`
> # route -n get 1.1.1.2 route to: 1.1.1.2
> destination: 1.1.1.2
> gateway: 10.3.1.1
> fib: 0
> interface: vlan2212
> flags:
>
> recvpipe sendpipe ssthresh rtt,msec mtu weight expire
> 0 0 0 0 9000 1 0
> `But the IP of the loopback can't be used as BGP next hop in the following
> configuration:` protocol bgp rr_par_ipv4 { local 1.1.1.1 as 65001;
> neighbor 1.1.1.1.2 as 65001;
> default bgp_local_pref 40;
> rr client;
> ipv4 {
> import all;
> export all;
> next hop self;
> };
> };
> ``The source IP used as next hop is not 1.1.1.1 but the IP `10.3.1.2` of
> vlan1 used for the connection between 2 nodes:``
> # ifconfig vlan1vlan2212: flags=8843
> metric 0 mtu 9000
>
> options=680703
>
> ether 50:65:f3:8b:98:71
> inet 10.3.1.2 netmask 0xff00 broadcast 10.3.1.255
> inet6 fe80::5265:f3ff:fe8b:9871%vlan2212 prefixlen 64 scopeid 0xd
> groups: vlan
> vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: mlxen0
> media: Ethernet autoselect (40Gbase-CR4 )
>
> status: active
> nd6 options=21
>
> ``**Even if I force the next hop address (using `next hop address`) it still
> take the IP of the vlan. What's wrong?***``
> $ bird --versionBIRD version 2.13
> $ uname -nmr
> myhostname 13.2-RELEASE amd64
> ```
>
> Benoît
issue with next hop using freebsd loopback?
I first posted this issue on the freebsd ml but it's probably more an issue to
post there.
I have the loopbacks `1.1.1.1` and `1.1.1.2` of 2 nodes distributed using
OSPF:
```
filter ospfexport { if (source = RTS_DEVICE) then accept;
reject;
}
protocol ospf v2 { tick 2;
ipv4 {
import all;
export filter ospfexport;
};
area 0 {
stub no;
interface "vlan1", "vlan2" {
type ptp;
cost 5;
};
interface "lo1" { stub; };
};
}
```
`1.1.1.1` is set on the loopback:
```# ifconfig lo1lo1: flags=8049 metric 0 mtu
16384
options=680003
inet6 ::1 prefixlen 128
inet6 fe80::1%lo1 prefixlen 64 scopeid 0x9
inet 1.1.1.1 netmask 0x
groups: lo
nd6 options=21
# birdc show route for 1.1.1.1BIRD 2.13 ready.
Table master4:
1.1.1.1/32 unicast [ospf1 15:56:43.054] ! I (150/0) [1.1.1.1]
dev lo1
```
The distribution works OK and I can ping each others:
```
# route -n get 1.1.1.2 route to: 1.1.1.2
destination: 1.1.1.2
gateway: 10.3.1.1
fib: 0
interface: vlan2212
flags:
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 9000 1 0
```
But the IP of the loopback can't be used as BGP next hop in the following
configuration:
```protocol bgp rr_par_ipv4 { local 1.1.1.1 as 65001;
neighbor 1.1.1.1.2 as 65001;
default bgp_local_pref 40;
rr client;
ipv4 {
import all;
export all;
next hop self;
};
};
```
The source IP used as next hop is not 1.1.1.1 but the IP `10.3.1.2` of vlan1
used for the connection between 2 nodes:
```
# ifconfig vlan1vlan2212: flags=8843
metric 0 mtu 9000
options=680703
ether 50:65:f3:8b:98:71
inet 10.3.1.2 netmask 0xff00 broadcast 10.3.1.255
inet6 fe80::5265:f3ff:fe8b:9871%vlan2212 prefixlen 64 scopeid 0xd
groups: vlan
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: mlxen0
media: Ethernet autoselect (40Gbase-CR4 )
status: active
nd6 options=21
```
**Even if I force the next hop address (using `next hop address`) it still take
the IP of the vlan. What's wrong?***
```
$ bird --versionBIRD version 2.13
$ uname -nmr
myhostname 13.2-RELEASE amd64
```
Benoît
Re: peering between route reflectors
Hi Douglas, That's good advices, I have considered also using specific rr for customers connections, that's a good idea to use distinct nodes for it with 2 per regions... However, my description of the issue was lacking some clarity. The purpose of the route reflectors there was to share the routing providing by the local transit to other pops as a backup. I have the following infra: 3 POPS linked each others by 1 or more L2 links. Each POP has one or more transit links and different peers: R1 / \ / \ R2 R3 Each POP share its loopback using OSPF. The problem I What I would like to do is the following: when one POP has no more direct route (transit link down, route disabled, ...), it fallback to another pop to get the route I was thinking to do it by having each node acting as a route reflector to only share the current pop route to the others. Each nodes would reflect their route to each others. Is there another pattern to do it? I think I found a way to fix possible conflicts by ensureing the backup has a lower pref. Are there any other consideration or patterns I could use? Benoît --- Original Message --- On Thursday, June 15th, 2023 at 22:24, Douglas Fischer wrote: > Hello Benoit! > > From what you described, I imagine that there may be a confusion between > redundancy and load distribution. > > You mentioned having a route-reflector per pop. > This is load distribution. Each such route-reflector will process route > exchanges with local peers. > And that is indeed a good thing! > Because it has positives like the fact that if you have 15-20 Peers in this > pop, even if this pop is isolated, the routes between these peers will still > be exchanged. > But it's also something that can be bad! > Because it will require that you have equipment that is chosen to perform > this Route-Reflector function. > It will also have different configurations to be applied on the routers in > the BGP peer part with the Route-Reflector. Each POP a configuration. > > You also talked about establishing neighborhoods between Route-Reflectors. > This is also part of the concept of load sharing, and this is what will make > all POPs aware of all networks. > > But putting a single Route-Reflector on each POP IS NOT redundancy! > > From what I could understand from what you described, if one of these > route-reflectors in these POPs becomes inoperative, the rest of the network > will continue operating... But during this inoperative time, the exchange of > routes between the Peers of the same POP (and with the other POPs on the > network) will not occur. > > For you to have REDUNDANCE you would have to have 2 (or more) > Route-Reflectors DOING THE SAME ROLE. In your scenario, 2 in each POP. > > And going a little further, and getting into a controversial topic, these 2 > sets of Route-Reflectors COULD NOT exchange routes with each other! Precisely > to prevent, for example, a malformed route that affects the functioning of > one of the Route-Reflectors from being propagated to the other and affecting > that other route-reflector as well. > > > The recipe that I most often see being used for this type of scenario is to > have 2 Route-Reflectors in different geographic positions, positioned in such > a way as to be OFF-Path, thus trusting the IGP, and each one of them peering > with each network neighbor. > > Em qua., 14 de jun. de 2023 às 17:04, Benoit Chesneau > escreveu: > > > For redundancy I am thinking to have a router reflector per pop . Each > > route reflector would peer with each others. The issue is that since each > > POP has a transit, i have duplicate route and sometimes a loop is created. > > How can it be prevented?? I tried to put them in the same cluster but it > > doesn't seem to be enough. > > > > Any idea is welcome :) > > > > > > Benoît > > > > -- > Douglas Fernando Fischer > Engº de Controle e Automação
peering between route reflectors
For redundancy I am thinking to have a router reflector per pop . Each route reflector would peer with each others. The issue is that since each POP has a transit, i have duplicate route and sometimes a loop is created. How can it be prevented?? I tried to put them in the same cluster but it doesn't seem to be enough. Any idea is welcome :) Benoît
need help to use freebsd fib and bgp
Hi all,
What I am trying to achieve is to connect to remote peers using information
found in fib1 routing table setup in freebsd and export / import routing
information in this table using BGP. The issue I have right now is that this
configuratin doesn't work. It can't connect to the remote A.B.C.0 ip and I get
such errors in logs:
```
2023-06-06 02:05:58.571 enkiv4: A.B.C.D/24: ignored
2023-06-06 02:05:58.571 enkiv4: A.B.C.D/32: [alien] created
2023-06-06 02:05:58.571 enkiv4.ipv4 > added [best] A.B.C.D/32 0L 4G
unicast
2023-06-06 02:05:58.571 enkiv4.ipv4 < rejected by protocol A.B.C.D/32
0L 4G unicast
```
Is this pattern expected to work? I am wondering if it's not an issue in
Freebsd 13.2p0 version. I tried different combination these days without
success. Any help would be much appreciated :)
The connection used for bgp arrived on a vlan 20 on nic2 which I setup on fib1,
while the management interface is on another nic (bge0) and get its IP using
DHCP:
```
bge0 ---> fib 0 (used for management) DHCP
vlan20 -> fib 1 (connect to remote BGP peer) , static /31 IPV4
```
Here is a snippet of network setup:
```
# ifconfig bge0
bge0: flags=8843 metric 0 mtu 1500
options=c019b
ether 94:18:82:7b:88:20
inet6 fe80::9618:82ff:fe7b:8820%bge0 prefixlen 64 scopeid 0x3
inet 192.168.88.249 netmask 0xff00 broadcast 192.168.88.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=21
# ifconfig vlan20
vlan2021: flags=8843 metric 0 mtu 1500
options=680703
ether 50:65:f3:8b:98:71
inet A.B.C.1 netmask 0xfffe broadcast 255.255.255.255
inet6 fe80::5265:f3ff:fe8b:9871%vlan2021 prefixlen 64 scopeid 0xb
groups: vlan
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: mlxen0
fib: 1
media: Ethernet autoselect (40Gbase-CR4 )
status: active
nd6 options=21
$ sudo netstat -rn4
Routing tables
Internet:
DestinationGatewayFlags Netif Expire
A.B.C.0/31link#11U vlan2021
A.B.C.1 link#11UHS lo0
127.0.0.1 link#7 UHS lo0
```
A minimal setup (edited for anonymization) in Bird is the following
```
router id A.B.C.1;
ipv4 table tabv4 sorted;
protocol kernel enkiv4 {
learn;
kernel table 1;
ipv4 {
table tabv4;
import all;
export all;
};
}
protocol bgp transit_ipv4_1 {
local A.B.C.1 as ;
neighbor A.B.C.0 as ;
default bgp_med 0;
default bgp_local_pref 50;
password "somepass";
ipv4 {
table tabv4;
import keep filtered;
import filter ebgp_import;
export filter ebgp_export;
next hop self;
};
};
```
routes that will be adverised are setup as blackhole routes directly in
FreeBSD. Should I setup them using the static protocol?
Benoît
