Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Cisco NX-OS: support unnumbered / interface-based eBGP peering (IPv6 link-local, `remote-as external`)

Aperta
#440 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, grpc
Ambito
networking

Direzione di ricerca

Inizia con api/core/v1alpha1/bgp_peer_types.go e api/cisco/nx/v1alpha1/bgpconfig_types.go, quindi segui la riconciliazione di BGPPeer fino al provider cisco-nxos-gnmi. Confronta il mapping dei peer esistente con l’esempio NX-OS PeerIf-list e il comportamento di Interface. Il lavoro completato deve coprire i peer basati su interfaccia con la gestione dell’AS esterno, l’esclusione reciproca con address e la verifica del provider; le impostazioni RA sono un’estensione facoltativa.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area/switch-automation
Summary

[!NOTE]
With some guidance I am happy to open a PR.

BGPPeer can only express a numbered IPv4 neighbor (spec.address is +required with +kubebuilder:validation:Format=ipv4). There is no way to configure unnumbered / interface-based BGP peering (FRR/Cumulus style: neighbor <interface> ... remote-as external, next-hops resolved over IPv6 link-local + RAs). Please add first-class support for it.

Motivation

IPv6 leaf/spine fabrics commonly run unnumbered eBGP over IPv6 link-local so that transit links need no per-link addressing (no /31s or /127s to plan/manage); peers are discovered via IPv6 link-local + Router Advertisements, and IPv6 link-local next-hops are used for both address families. This is the idiom used by FRR and Cumulus, and it's the design we want to drive through network-operator on Cisco NX-OS.

Today this is impossible to model, forcing either numbered eBGP (the addressing overhead we're trying to avoid) or out-of-band configuration.

Current limitation
  • api/core/v1alpha1/bgp_peer_types.go: BGPPeerSpec.Address is +required, Format=ipv4, and ASNumber is +required. No interface field; no way to express remote-as external (dynamic AS). LocalAddress.InterfaceRef only sets the source interface (e.g. a loopback), not an unnumbered neighbor.
  • api/cisco/nx/v1alpha1/bgpconfig_types.go: the provider-specific BGPConfig only carries EVPN / address-family knobs (AdvertisePIP, ExportGatewayIP) => no peer-level interface/unnumbered field, so it isn't a usable escape hatch.
NX-OS support

Verified on Nexus 9300v (n9kv) 10.3(9) driven by the cisco-nxos-gnmi provider. CLI:

interface Ethernet1/1
  no switchport
  ipv6 address use-link-local-only
  ip forward
  no ipv6 nd suppress-ra          ! REQUIRED, see note below
router bgp 65010
  neighbor Ethernet1/1
    remote-as external
    address-family ipv4 unicast
    address-family ipv6 unicast

The session establishes over the peer's IPv6 link-local
(fe80::…%Ethernet1/1). In the NX-OS DME model it appears under:

System/bgp-items/inst-items/dom-items/Dom-list[name=default]/peerif-items/PeerIf-list[id=eth1/1]
  asnType: external

[!IMPORTANT]
NX-OS suppresses Router Advertisements by default, so the unnumbered peers cannot discover each other's link-local until no ipv6 nd suppress-ra is set on the peering interface. (FRR enables RAs automatically for unnumbered BGP interfaces; NX-OS does not.) Without it the neighbor stays at remote AS 0 and never establishes. It would be ideal for the operator to manage this automatically for interface-based peers.

Proposed change
  1. Allow BGPPeer to reference an interface instead of an address, e.g. a spec.interfaceRef (mutually exclusive with spec.address), and permit asNumber to be external (dynamic / remote-as external).
  2. Map the interface-peer to the NX-OS DME peerif-items/PeerIf-list[id=<intf>] (asnType: external) in the cisco-nxos-gnmi provider.
  3. Optionally model ipv6 nd suppress-ra (and ip forward / use-link-local-only) on the Interface type so an unnumbered link can be fully declared.
Environment
  • network-operator provider: cisco-nxos-gnmi
  • Device: Cisco Nexus 9300v (n9kv), NX-OS 10.3(9), gNMI/DME over gRPC/TLS
Lingua principale
Go
Stelle
14
Fork
10
Merge medio
1g 22h
PR unite (30g)
57

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ironcore-dev/network-operator

Tutte le issue di ironcore-dev/network-operator

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.