OSPFv2: PtP stub interface
hello, i'm using BIRD 3.2.0 on FreeBSD 15.0. i have a PPPoE interface with a point-to-point IPv4 address configured: ng0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=0 inet 81.187.73.117 --> 81.187.81.187/32 inet6 2001:8b0:aab5:1::1/128 inet6 fe80::227c:14ff:fef3:d8f7%ng0/64 scopeid 0x12 groups: arpa nd6 options=1<PERFORMNUD> i would like to advertise this in OSPF as a passive interface, so i configured the OSPF protocol: define OSPF_V6_EXPORT = [ ]; define OSPF_V4_EXPORT = [ 0.0.0.0/0 ]; filter ospf_export { if (net ~ OSPF_V6_EXPORT) then accept; if (net ~ OSPF_V4_EXPORT) then accept; reject; }; protocol ospf v2 core4 { ipv4 { export filter ospf_export; import all; }; area 0 { interface "ng0" { stub yes; }; [... other config elided ...] }; } however, BIRD does not advertise 81.187.73.117/32 in OSPF. it *does* advertise 81.187.81.187/32, which is the remote side of the interface. the interface looks fine in BIRD: bird> show ospf interface "ng0" core6: core4: Interface ng0 (peer 81.187.81.187) Type: ptp Area: 0.0.0.0 (0) State: PtP (stub) Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 the route: bird> show route for 81.187.73.117/32 Table master4: 0.0.0.0/0 unicast [kernel4 2026-07-04] ! (10) via 81.187.81.187 on ng0 81.187.73.117/32 unicast [kernel4 2026-07-04] ! (10) dev lo0 if i add 81.187.73.117/32 to OSPF_V4_EXPORT, then it is correctly advertised as an E2 route, which is fine as a workaround, but i would like to understand why the interface configuration doesn't work.
Good morning Lexi, I believe the issue might be this one: define OSPF_V4_EXPORT = [ 0.0.0.0/0 ]; 0.0.0.0/0 matches only the default route *exactly*, nothing shorter. What you probably meant is: 0.0.0.0/0+ (default route and everything shorter as well). Best regards, Nico <#secure method=pgpmime mode=sign> Lexi Winter <lexi@le-fay.org> writes:
hello,
i'm using BIRD 3.2.0 on FreeBSD 15.0. i have a PPPoE interface with a point-to-point IPv4 address configured:
ng0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=0 inet 81.187.73.117 --> 81.187.81.187/32 inet6 2001:8b0:aab5:1::1/128 inet6 fe80::227c:14ff:fef3:d8f7%ng0/64 scopeid 0x12 groups: arpa nd6 options=1<PERFORMNUD>
i would like to advertise this in OSPF as a passive interface, so i configured the OSPF protocol:
define OSPF_V6_EXPORT = [ ];
define OSPF_V4_EXPORT = [ 0.0.0.0/0 ];
filter ospf_export { if (net ~ OSPF_V6_EXPORT) then accept; if (net ~ OSPF_V4_EXPORT) then accept; reject; };
protocol ospf v2 core4 { ipv4 { export filter ospf_export; import all; };
area 0 { interface "ng0" { stub yes; }; [... other config elided ...] }; }
however, BIRD does not advertise 81.187.73.117/32 in OSPF. it *does* advertise 81.187.81.187/32, which is the remote side of the interface.
the interface looks fine in BIRD:
bird> show ospf interface "ng0" core6:
core4: Interface ng0 (peer 81.187.81.187) Type: ptp Area: 0.0.0.0 (0) State: PtP (stub) Priority: 1 Cost: 10 ECMP weight: 1 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5
the route:
bird> show route for 81.187.73.117/32 Table master4: 0.0.0.0/0 unicast [kernel4 2026-07-04] ! (10) via 81.187.81.187 on ng0 81.187.73.117/32 unicast [kernel4 2026-07-04] ! (10) dev lo0
if i add 81.187.73.117/32 to OSPF_V4_EXPORT, then it is correctly advertised as an E2 route, which is fine as a workaround, but i would like to understand why the interface configuration doesn't work.
-- Sustainable and modern Infrastructures by ungleich.ch
hi Nico, Nico Schottelius via Bird-users wrote in <87bjcjgv8n.fsf@ungleich.ch>:
I believe the issue might be this one:
define OSPF_V4_EXPORT = [ 0.0.0.0/0 ];
0.0.0.0/0 matches only the default route *exactly*, nothing shorter. What you probably meant is:
0.0.0.0/0+ (default route and everything shorter as well).
my understanding is that Type 1 LSAs for directly connected interfaces are originated inside OSPF and aren't subject to the route filter. for example, i have another interface with an identical configuration: interface "wg.vpn" { stub yes; }; and this interface also has an IPv4 address assigned: wg.vpn: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1280 options=80000<LINKSTATE> inet 198.18.66.1/24 and a Type 1 LSA for 198.18.66.0/24 is correctly originated, even though 198.18.66.0/24 isn't permitted in the filter. the reason 0.0.0.0/0 is listed in the filter is that this router injects a default route as a Type 5 (E1) LSA; that's not directly relevant to the problem, i just wanted to show all the relevant config. adding 81.187.73.117/32 to OSPF_V4_EXPORT does result in the address of ng0 being originated as a Type 5 LSA, but since this is an interface address, it seems more correct to originate it as a Type 1 LSA. (but it's quite possible this is not how OSPF is meant to work with point-to-point addresses, so i don't know if this is actually wrong; it was just surprising.)
On Mon, Jul 06, 2026 at 09:42:35PM +0100, Lexi Winter wrote:
hello,
i'm using BIRD 3.2.0 on FreeBSD 15.0. i have a PPPoE interface with a point-to-point IPv4 address configured:
ng0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=0 inet 81.187.73.117 --> 81.187.81.187/32 inet6 2001:8b0:aab5:1::1/128 inet6 fe80::227c:14ff:fef3:d8f7%ng0/64 scopeid 0x12 groups: arpa nd6 options=1<PERFORMNUD>
i would like to advertise this in OSPF as a passive interface, so i configured the OSPF protocol:
however, BIRD does not advertise 81.187.73.117/32 in OSPF. it *does* advertise 81.187.81.187/32, which is the remote side of the interface.
if i add 81.187.73.117/32 to OSPF_V4_EXPORT, then it is correctly advertised as an E2 route, which is fine as a workaround, but i would like to understand why the interface configuration doesn't work.
Hello This is somewhat idiosyncratic BIRD behavior. For point-to-point IPv4 addresses, BIRD do *not* announce the local one (while the remote one is announced only in case of stub interface). This works when one configures point-to-point addresses with existing/loopback address of the router. E.g.: eth0: 192.168.1.0/24 eth1: 192.168.1.0/32 --> 192.168.2.0/32 This is something that i always wanted to fix in some more generic/configurable way, but never got to that. The workaround is to set the same IP address as /32 on a dummy/loopback interface and announce it as a stub. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
hi Ondrej, Ondrej Zajicek via Bird-users wrote in <ak0CUJw9_GN1C0nu@feanor>:
On Mon, Jul 06, 2026 at 09:42:35PM +0100, Lexi Winter wrote:
i'm using BIRD 3.2.0 on FreeBSD 15.0. i have a PPPoE interface with a point-to-point IPv4 address configured: [...] however, BIRD does not advertise 81.187.73.117/32 in OSPF. it *does* advertise 81.187.81.187/32, which is the remote side of the interface.
This is somewhat idiosyncratic BIRD behavior. For point-to-point IPv4 addresses, BIRD do *not* announce the local one (while the remote one is announced only in case of stub interface). This works when one configures point-to-point addresses with existing/loopback address of the router. E.g.:
eth0: 192.168.1.0/24 eth1: 192.168.1.0/32 --> 192.168.2.0/32
This is something that i always wanted to fix in some more generic/configurable way, but never got to that.
The workaround is to set the same IP address as /32 on a dummy/loopback interface and announce it as a stub.
thanks, this explanation makes sense. unfortunately, FreeBSD does not seem to allow an address to be configured as a normal /32 on one interface and a PtP address on another interface: # ifconfig lo1 inet 81.187.73.117/32 alias ifconfig: ioctl (SIOCAIFADDR): File exists (this is different from the normal behaviour, where the same /32 address can be configured on multiple interfaces; it seems to be specific to PtP addresses.) also, since this address is assigned by PPPoE, it is theoretically possible that it could change -- although in practice it isn't an issue for me (because it's statically assigned and will never change) i could imagine this being an issue for some people. so, it would be nice if there was a configuration option to change this behaviour, but in the mean time, i'll continue to work around it by injecting the address as an E2 route.
i wrote in <ak1hA4UbFMfVeCF9@rose.le-fay.org>:
unfortunately, FreeBSD does not seem to allow an address to be configured as a normal /32 on one interface and a PtP address on another interface:
# ifconfig lo1 inet 81.187.73.117/32 alias ifconfig: ioctl (SIOCAIFADDR): File exists
to follow up on this (in case anyone else is following along at home), it turns out this behaviour depends on the order in which addresses are assigned to the interface. i have filed a FreeBSD PR for this issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296631 i will try updating the configuration on the BIRD router to assign addresses in the 'approved' order and see if this resolves the original problem. thanks again to everyone who replied to my original post.
participants (3)
-
Lexi Winter -
Nico Schottelius -
Ondrej Zajicek