[PATCH] OSPF: on PtP ospf_iface with physical PtP links, skip next-hop resolving
Signed-off-by: Soha Jin <soha@jin.sh> Co-developed-by: Wende Tan <twd2.me@gmail.com> --- proto/ospf/rt.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c index 471bb586..02b2f214 100644 --- a/proto/ospf/rt.c +++ b/proto/ospf/rt.c @@ -1796,7 +1796,12 @@ calc_next_hop(struct ospf_area *oa, struct top_hash_entry *en, if (ifa->type == OSPF_IT_VLINK) return new_nexthop(p, IPA_NONE, NULL, 0); - /* FIXME: On physical PtP links we may skip next-hop altogether */ + /* + * The type of the ospf_iface is PtP and the iface has a physical PtP link, + * so we can simply use the iface, and skip further resolving. + */ + if (ifa->type == OSPF_IT_PTP && !(ifa->iface->flags & IF_MULTIACCESS)) + return new_nexthop(p, IPA_NONE, ifa->iface, ifa->ecmp_weight); if (ospf_is_v2(p) || ospf_is_ip6(p)) { -- 2.39.2
Hi Thanks, merged. I hope it does not break some multipoint tunnels like Wireguard, they often have bad flags reported by kernel, but they should be configured as PtMP anyways. I wonder what use case is fixed by this patch, as the iface still needs an IP address just to be considered in ospf_ifa_notifyX(). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi Ondrej, To reproduce the use case, connect a Juniper and a BIRD by a GRE tunnel, and use OSPFv3 to advertise IPv4 networks. Here are the simplified configurations: # Juniper side: set interfaces gr-0/0/0.233 tunnel source <redacted> set interfaces gr-0/0/0.233 tunnel destination <redacted> set interfaces gr-0/0/0.233 tunnel ttl 255 set interfaces gr-0/0/0.233 family inet set interfaces gr-0/0/0.233 family inet6 set protocols ospf3 realm ipv4-unicast area 0.0.0.0 area-range 192.0.2.0/24 set protocols ospf3 realm ipv4-unicast area 0.0.0.0 interface gr-0/0/0.233 # BIRD side: protocol ospf v3 { ipv4 { import all; export none; }; area 0 { stubnet 198.51.100.0/24; interface "gre-test" { type pointopoint; }; }; } # with commands: ip link add gre-test type ip6gre local <redacted> remote <redacted> ttl 255 encaplimit none ip link set gre-test up Juniper works fine (some output omitted):
show route 198.51.100.0 198.51.100.0/24 *[OSPF3/10] 00:25:37, metric 60 > via gr-0/0/0.233
But the BIRD thinks Juniper is unreachable (some output omitted):
show ospf state all router 192.0.2.1 unreachable router 198.51.100.1 metric 1 stubnet 192.0.2.0/24 metric 1
After investigating Link-LSAs sent by each other with Wende, we found that Juniper sends a zero link-local address for PtP links. BIRD tries to resolve next-hop for IPv4 AF and sees a zero, so it marks the Juniper as unreachable. However, in fact, the other side (i.e., the Juniper) can be reached by routing the packets directly to the PtP interface without next-hop IP address, while RFC did not specify for this condition (link-local address for PtP with AFs other than IPv6). Thus, I compose this patch. As a workaround for now, I forced the GRE's interface type to be PtMP in the Juniper's OSPF configuration, which makes it put its link-local address in Link-LSA. About the ifa_notify, the IPv6 link-local address seems enough for it. I did not see any problem on an interface with only an fe80 address. Regards, Soha
-----Original Message----- From: Ondrej Zajicek <santiago@crfreenet.org> Sent: Thursday, November 9, 2023 9:41 PM To: Soha Jin <soha@jin.sh> Cc: bird-users@network.cz; Wende Tan <twd2.me@gmail.com> Subject: Re: [PATCH] OSPF: on PtP ospf_iface with physical PtP links, skip next-hop resolving
Hi
Thanks, merged.
I hope it does not break some multipoint tunnels like Wireguard, they often have bad flags reported by kernel, but they should be configured as PtMP anyways.
I wonder what use case is fixed by this patch, as the iface still needs an IP address just to be considered in ospf_ifa_notifyX().
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi, Anno domini 2023 Ondrej Zajicek scripsit: [...]
I hope it does not break some multipoint tunnels like Wireguard, they often have bad flags reported by kernel, but they should be configured as PtMP anyways.
I disagree on the PtMP part. I've deliberately set up a bunch of Wireguard tunnels, which by design are PTP, as in, there are only ever two peers. I know that Wireguard *can* handles PTMP, however having to enforce this in bird config would be weird to me. Cheers, Max -- "Does it bother me, that people hurt others, because they are to weak to face the truth? Yeah. Sorry 'bout that." -- Thirteen, House M.D.
On Fri, Nov 10, 2023 at 01:43:02PM +0100, Maximilian Wilhelm wrote:
Hi,
Anno domini 2023 Ondrej Zajicek scripsit:
[...]
I hope it does not break some multipoint tunnels like Wireguard, they often have bad flags reported by kernel, but they should be configured as PtMP anyways.
I disagree on the PtMP part.
I've deliberately set up a bunch of Wireguard tunnels, which by design are PTP, as in, there are only ever two peers. I know that Wireguard *can* handles PTMP, however having to enforce this in bird config would be weird to me.
Hi I see that my comment was ambiguous, it should be 'those Wireguard tunnels that are multipoint should be configured as OSPF PtMP anyways.' PTP Wireguard tunnels should work with OSPF PTP, of course. My point was that even those Wireguard tunnels that are PtMP have flags saying they are PtP: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi, Anno domini 2023 Ondrej Zajicek scripsit:
On Fri, Nov 10, 2023 at 01:43:02PM +0100, Maximilian Wilhelm wrote:
Anno domini 2023 Ondrej Zajicek scripsit: [...]
I hope it does not break some multipoint tunnels like Wireguard, they often have bad flags reported by kernel, but they should be configured as PtMP anyways.
I disagree on the PtMP part.
I've deliberately set up a bunch of Wireguard tunnels, which by design are PTP, as in, there are only ever two peers. I know that Wireguard *can* handles PTMP, however having to enforce this in bird config would be weird to me.
I see that my comment was ambiguous, it should be 'those Wireguard tunnels that are multipoint should be configured as OSPF PtMP anyways.'
PTP Wireguard tunnels should work with OSPF PTP, of course.
My point was that even those Wireguard tunnels that are PtMP have flags saying they are PtP:
wg0: <POINTOPOINT,NOARP,UP,LOWER_UP>
Oh, I see, that makes sense :-) Thanks for the clarification! Cheers, Max
participants (3)
-
Maximilian Wilhelm -
Ondrej Zajicek -
Soha Jin