I dropped a PR for this change, here: https://github.com/vyos/vyos-1x/pull/5392

Three changes came out of review and testing on PR #5392. Two of them narrow or widen what verify() accepts relative to the original description above, so the rules listed there are superseded by the list at the end of this comment.

1. A keyless tunnel no longer collides with a keyed one

alexk37 on GitHub found a real regression while testing the branch: a keyless tunnel and a keyed tunnel sharing one source-address both committed and both came up, but every later commit that re-ran the keyless tunnel's script was rejected, and after a reboot that tunnel was silently gone from both the Kernel and the running config.

set interfaces tunnel tun10 encapsulation gre
set interfaces tunnel tun10 source-address 192.0.2.1

set interfaces tunnel tun20 encapsulation gre
set interfaces tunnel tun20 source-address 192.0.2.1
set interfaces tunnel tun20 remote 0.0.0.0
set interfaces tunnel tun20 parameters ip key 10

The keyless branch never looked at the neighbour's key, and the 0.0.0.0 normalisation introduced here is what made that path reachable for a config current rolling accepts. The Kernel only ever matches a keyless tunnel against another keyless tunnel — see ip_tunnel_key_match() in include/net/ip_tunnels.h — so a genuinely keyed neighbour is now skipped outright.

2. A zero key does not count as a key

parameters ip key 0 is CLI-valid, but it does not buy a tunnel any uniqueness on receive: the IPv4 lookup ends in a flag-blind compare in ip_tunnel_lookup(), and ip6gre_tunnel_locate() compares i_key with no flag gate at all. So keyless and key 0 stay ambiguous inbound, and a zero-keyed neighbour stays in scope for the keyless check. This restores what rolling did before change 1 above.

3. Keyless tunnels on different source-interfaces are now accepted

This reverses the rule in the description that keyless tunnels sharing a local and remote address should still be rejected when their source-interfaces differ.

That rule was wrong. source-interface reaches the Kernel as dev, so it lands in the tunnel's link index, which ip_tunnel_find() compares alongside local address, remote address, tunnel type and key. Two such tunnels are genuinely distinct devices, and the inbound demultiplexing concern that motivated the original rule does not apply — the link index discriminates.

Measured on kernel 6.12 / iproute2 6.15 in a network namespace:

• two keyless gre tunnels, same local and remote, bound to different dummy interfaces → both create;
• the same pair bound to one interface → second add fails with add tunnel "gre0" failed: File exists.

Resulting rules

For two tunnels in the GRE family sharing a normalised remote address, where 0.0.0.0 and :: both normalise to unset:

• rejected — both keyless, same local address and same source-interface;
• rejected — both keyed, same local address, same source-interface and the same key (mGRE tunnels sharing a key on one source-interface);
• rejected — one keyless and one carrying key 0, same local address and same source-interface;
• accepted — differing remote addresses, whether keyed or not;
• accepted — same key, differing local addresses or differing source-interfaces;
• accepted — keyless alongside a tunnel carrying a non-zero key.

Unchanged from the original description: gre and gretap are still compared against each other even though the Kernel keeps them in separate tunnel tables, and ip6gre/ip6gretap are still not validated. Both remain deliberate follow-ups for their own tasks rather than scope for this one.

Each case above is covered by a smoketest in smoketest/scripts/cli/test_interfaces_tunnel.py; the suite passes in CI at 42 tests.

Correction - change 2 above was too broad, and rule 3 in the resulting list with it.

alexk37 tested the branch again and showed that the reasoning behind "a zero key
does not count as a key" does not hold in general. Both citations in that
paragraph were wrong for the rule they supported:

• The flag-blind compare in ip_tunnel_lookup() is only its last loop, and that loop is reached only by tunnels with saddr == 0 && daddr == 0. A tunnel carrying a local or a remote address is matched in one of the three loops above it, through ip_tunnel_key_match(), which tests the flag saying that a key is set before it compares the value - so there a zero key and an unset key are two different tunnels.
• ip6gre_tunnel_locate() is the create path of a protocol this check never reaches: the pairwise check runs for gre and gretap only. It stays relevant for the deferred ip6gre task, not for this one.

Measured on kernel 6.12 / iproute2 6.15 in a network namespace, sending GRE
packets in from a veth peer and counting per-tunnel rx:

t1 keyless, t2 key 0, both local 10.0.0.1
  packet with no key -> t1 +3   t2 +0
  packet with key 0  -> t1 +0   t2 +3

t1 keyless, t2 key 0, neither a local nor a remote
  packet with no key -> t1 +0   t2 +3
  packet with key 0  -> t1 +0   t2 +3

So parameters ip key 0 does make a tunnel unique wherever an endpoint is set,
and only fails to where neither tunnel carries one - the single shape that
reaches that last loop.

Amended rule. Replace the third entry of the resulting-rules list with these
two:

• rejected - one keyless and one carrying key 0, same source-interface, where neither tunnel carries a local or a remote address;
• accepted - one keyless and one carrying key 0, where either of them carries a local or a remote address.

The other five entries are unchanged and still hold. Change 1 above reads a
little more precisely now as well: the neighbour skipped outright by the keyless
check is one carrying a key which identifies it, and a zero key does that only
where an endpoint is set.

A further change, in the single-tunnel check. The rule that a gre tunnel
with source-address 0.0.0.0 needs a key read the configured value directly, so
key 0 satisfied it while the pairwise check treated the same value as no key at
all - the file gave two answers to one question. It now uses the same
classification: with no remote either, such a tunnel needs a non-zero key,
because with key 0 it is the same catch-all a keyless tunnel would be, which is
what that check has always refused. A tunnel which does carry a remote is unique
without its key, so key 0 remains acceptable there.

This is the only place the series narrows rather than widens what commits, so it
is kept as its own commit and can be lifted out if it is better handled under a
separate task.

Coverage. The suite is 43 tests with the one added here, rather than the 42
stated above - test_multiple_gre_tunnel_zero_key_with_endpoints covers the
newly accepted pairs, test_multiple_gre_tunnel_zero_key still covers the pair
which stays rejected, and test_tunnel_src_any_gre_key covers the single-tunnel
rule. The last completed CI run reported 42 on the previous head; the run for
this push is still queued behind the approval gate that fork pull requests hit.