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 +, 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: babel RTT metric false samples
On Sat, Apr 13, 2024 at 04:38:47PM +0200, Erin Shepherd wrote: > I guess it might not fit with bird's abstractions (or perhaps the Babel > protocol), but has thought been given to using SO_TIMESTAMPING to have the > kernel compute TX/RX timestamps? Yeah, that is definitely a better solution. -- 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
On Mon, Apr 15, 2024 at 02:22:01PM +, 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: BGP on /32 (/128) interfaces
On Mon, Apr 15, 2024 at 12:10:05PM +0200, Daniel Gröber wrote: > Hi Arzhel, > > On Fri, Apr 12, 2024 at 11:57:38AM +0200, Arzhel Younsi wrote: > > But for IPv6, it's cleaner to only require the router's link local address: > > testvm2006:~$ ip -6 addr > > inet6 2620:0:860:140:10:192:24:4/128 scope global > > testvm2006:~$ ip -6 route > > default via fe80::2022:22ff:fe22:2201 dev ens13 metric 1024 pref medium > > > > In Bird: > > neighbor fe80::2022:22ff:fe22:2201%ens13 external; > > > > But then the link local address doesn't work with multihop (for obvious > > reason). > > bird: /etc/bird/bird.conf:22:1 Multihop BGP cannot be used with link-local > > addresses > > I use lladdrs for BGP endpoints in my network and that works fine. I think > using `direct` instead of `multihop` in the v6-lladdr case would make it > work for you. > > One word of advice: don't use the %scope syntax, use the `interface` > directive instead. I don't recall exactly why but I had some subtle problem > with that. > > As for your v4/32 problem, give `multihop 1` a try. That enforces no > routers on the path to the peer like direct but allows off-subnet > endpoints. Do keep in mind the docs recommend setting the source address > explicitly when enabling multihop. Hi Note that using multihop fixes the issue with waiting for the address range to appear, but there is still an issue with next hop resolution. Multihop routes use recursive next hop resolution and in the case of /32 address ranges, there is no route for resolving neighbor IP announced as next hop. One would need a static route like: route NBR-IP/32 via "IFACE"; So the next hop will be resolved. Thinking about it, it makes sense to have something like direct mode that works with unnumbered interfaces (or ones with /32 address). -- 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
Re: BGP on /32 (/128) interfaces
Hi Arzhel, On Fri, Apr 12, 2024 at 11:57:38AM +0200, Arzhel Younsi wrote: > But for IPv6, it's cleaner to only require the router's link local address: > testvm2006:~$ ip -6 addr > inet6 2620:0:860:140:10:192:24:4/128 scope global > testvm2006:~$ ip -6 route > default via fe80::2022:22ff:fe22:2201 dev ens13 metric 1024 pref medium > > In Bird: > neighbor fe80::2022:22ff:fe22:2201%ens13 external; > > But then the link local address doesn't work with multihop (for obvious > reason). > bird: /etc/bird/bird.conf:22:1 Multihop BGP cannot be used with link-local > addresses I use lladdrs for BGP endpoints in my network and that works fine. I think using `direct` instead of `multihop` in the v6-lladdr case would make it work for you. One word of advice: don't use the %scope syntax, use the `interface` directive instead. I don't recall exactly why but I had some subtle problem with that. As for your v4/32 problem, give `multihop 1` a try. That enforces no routers on the path to the peer like direct but allows off-subnet endpoints. Do keep in mind the docs recommend setting the source address explicitly when enabling multihop. multihop [number] Configure multihop BGP session to a neighbor that isn't directly connected. Accurately, this option should be used if the configured neighbor IP address does not match with any local network subnets. Such IP address have to be reachable through system routing table. The alternative is the direct option. For multihop BGP it is recommended to explicitly configure the source address to have it stable. Optional number argument can be used to specify the number of hops (used for TTL). Note that the number of networks (edges) in a path is counted; i.e., if two BGP speakers are separated by one router, the number of hops is 2. Default: enabled for iBGP. The reason why direct isn't working is also clear from the docs: direct Specify that the neighbor is directly connected. The IP address of the neighbor must be from a directly reachable IP range (i.e. associated with one of your router's interfaces), >>>otherwise the BGP session wouldn't start but it would wait for such interface to appear<<<. The alternative is the multihop option. Default: enabled for eBGP. Hope that helps, --Daniel
