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 <santi...@crfreenet.org>
> Sent: Thursday, November 9, 2023 9:41 PM
> To: Soha Jin <s...@jin.sh>
> Cc: bird-users@network.cz; Wende Tan <twd2...@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: santi...@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."
