I believe the "options" of the neighbor object is only updated as a result of NEIGHBOR_EXSTART. If the authentication is enabled after unauthenticated neighbor adjacency, then this does not result in a new NEIGHBOR_EXSTART. Thus the options of the neighbor object is stuck 0x113, and not the updated to 0x513 (i.e. OPT_AT) resulting in that OSPF packets are becoming dropped in procedure ospf_pkt_checkauth3 since auth_present is zero. If I manually kick the FSM when authentication is changed by doing ISM_DOWN-> ISM_UP then this works as expected (see pseudo code below). I believe there is some logic missing when changing the autype? Can this be done in some more fine granular way? /* AUTHENTICATION */ if (ifa->autype != new->autype) { OSPF_TRACE(D_EVENTS, "Changing authentication type of %s", ifname); ifa->autype = new->autype; ... ospf_iface_sm(ifa, ISM_DOWN); ospf_iface_sm(ifa, ISM_UP); } Thanks, Kenth -----Original Message----- From: Bird-users <bird-users-bounces@network.cz> On Behalf Of Joakim Tjernlund Sent: den 11 mars 2021 16:50 To: santiago@crfreenet.org Cc: bird-users@network.cz Subject: Re: OSPFv3 auth problem CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, 2021-03-11 at 15:06 +0000, Joakim Tjernlund wrote:
On Thu, 2021-03-11 at 15:50 +0100, Ondrej Zajicek wrote:
On Thu, Mar 11, 2021 at 12:35:40PM +0000, Joakim Tjernlund wrote:
We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. However, removing OSPFv3 on ONE interface causes big problem in some cases, we loose auth in the whole ring and routing is then kaputt for all routers.
We have noted that some PDUs(like LS update) are sent without auth trailer so the receiving nodes complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)"
OSPFv3 Hello is OK though, it still has its auth trailer.
Hmm, that is strange. There is difference between Hello and LSUpd in OSPFv3 Auth receiver code, but not in sending code. That is essentially:
if (ifa->autype != OSPF_AUTH_CRYPT) return;
... attach auth trailer ...
Any ideas?
LSUpd packets do not contain explicit flag whether they use OSPFv3 auth trailer. Such information is stored in neighbor structure based on received DBDes packet. So 'missing authentication trailer' for LSUpd really means that such neighbor structure says 'no auth'. But that should not happen as that DBDes packet would be rejected.
One idea is that DBDes packets intended for one iface (non-authenticated) were sent to a different iface (authenticated) and they poisoned neighbor structure with 'no auth' info.
You say 'loose auth in the whole ring', i can imagine that it will break adjacent links, but it will really break even non-adjacent links?
Yes, it takes some time(about 30 min) though before the whole ring is gone. All nodes are seeing "missing authentication trailer" msg.
I should mention that a birdc restart/configure(on each node) will correct the problem.