Skip to content

unnumbered inspect fix + future gateway support - #1588

Draft
edipascale wants to merge 2 commits into
masterfrom
ema/bgp-unnumbered-gateway
Draft

unnumbered inspect fix + future gateway support#1588
edipascale wants to merge 2 commits into
masterfrom
ema/bgp-unnumbered-gateway

Conversation

@edipascale

Copy link
Copy Markdown
Contributor

No description provided.

@coderabbitai

coderabbitai Bot commented Aug 26, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

Comment @coderabbitai help to get the list of available commands.

edipascale and others added 2 commits August 28, 2026 09:53
An unnumbered session has no peer IP to be keyed by, so the device reports
it under the NOS interface it runs over: Ethernet3, Ethernet0.1001 for a
hostBGP subinterface, Vlan3123 for the TH5 workaround SVI. Those names must
not reach the API, so the agent now translates them to the port names we
use everywhere else - E1/1, E1/1.1001, E1/5.3123 - and apiutil keys the
expected neighbors the same way.

This replaces the "unnum" placeholder, which matched nothing the agent
reports: every unnumbered session showed up in `hhfctl inspect bgp` twice,
once as an unexpected neighbor and once as a phantom that never
established, so `--strict` could not pass on an unnumbered fabric. It also
collapsed every unnumbered link on a switch onto one key.

BFD sessions get the same treatment, keyed by their interface rather than
by the IPv6 link-local address they run over, which is of no use to anyone
and never joined the BGP neighbor it belongs to. Numbered sessions keep
their IP keys, so nothing else moves.

Since the port is now what identifies the peer, `hhfctl inspect bgp` and
`hhfctl inspect bfd` would otherwise show the same thing in their port and
neighbor/peer columns, so those rows are rendered as "E1/1 IPv6 LL". That
is display only: the key, and with it the JSON output, stays the plain port
name that the agent reports and that --strict matches on. An `unnumbered`
flag on the status carries it to the renderer.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Emanuele Di Pascale <emanuele@githedgehog.com>
A gateway link with no IP on either side now runs BGP unnumbered, the same
way fabric and mesh links already do: IPv6 is enabled on the link, the
neighbor is keyed by the interface rather than the peer IP, and
extended-nexthop lets the gateway's VTEP and protocol IPs resolve over the
link-local next hop. On TH5 the peering runs over the workaround SVI. BFD,
the L2VPN EVPN AF and the l2vpn-neighbors import policy are unchanged, and
RemoteAS still comes from GatewayASN so a miscabled port cannot bring the
session up.

Validation now rejects a gateway link with an IP on only one side instead
of requiring both, and the unnum golden group covers a gateway link on both
a leaf and a spine.

The gateway side has to be configured to match, which the Gateway API
cannot express yet; the fabric half is ready for it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Emanuele Di Pascale <emanuele@githedgehog.com>
@edipascale
edipascale force-pushed the ema/bgp-unnumbered-gateway branch from b8fa955 to 6700fb9 Compare August 28, 2026 08:01
@github-actions

Copy link
Copy Markdown

🚀 Temp artifacts published: v0-6700fb953 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant