Cisco NX-OS: support unnumbered / interface-based eBGP peering (IPv6 link-local, `remote-as external`)
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
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.Addressis+required,Format=ipv4, andASNumberis+required. No interface field; no way to expressremote-as external(dynamic AS).LocalAddress.InterfaceRefonly sets the source interface (e.g. a loopback), not an unnumbered neighbor.api/cisco/nx/v1alpha1/bgpconfig_types.go: the provider-specificBGPConfigonly 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 untilno ipv6 nd suppress-rais set on the peering interface. (FRR enables RAs automatically for unnumbered BGP interfaces; NX-OS does not.) Without it the neighbor stays atremote AS 0and never establishes. It would be ideal for the operator to manage this automatically for interface-based peers.
Proposed change
- Allow
BGPPeerto reference an interface instead of an address, e.g. aspec.interfaceRef(mutually exclusive withspec.address), and permitasNumberto beexternal(dynamic /remote-as external). - Map the interface-peer to the NX-OS DME
peerif-items/PeerIf-list[id=<intf>](asnType: external) in thecisco-nxos-gnmiprovider. - Optionally model
ipv6 nd suppress-ra(andip forward/use-link-local-only) on theInterfacetype 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
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ironcore-dev/network-operator
-
area/switch-automation firmware-bug vendor/cisco
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
ironcore-dev/network-operator#282 · 7 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Introduce a generic reconciler abstraction to reduce controller boilerplateForse di nuovo libera @felix-kaestner l’ha presa 208 giorni fa e non c’è nessuna pull request aperta. Apertaarea/switch-automation enhancement
ironcore-dev/network-operator#257 · 3 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
area/switch-automation firmware-bug plattform/iosxr vendor/cisco
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
ironcore-dev/network-operator#178 · 3 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
area/switch-automation firmware-bug platform/nx vendor/cisco
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
ironcore-dev/network-operator#171 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Cisco NX-OS: Round-trip delays for GNMI calls due to authentication/authorization/accounting (AAA)Apertaarea/switch-automation firmware-bug platform/nx vendor/cisco
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
ironcore-dev/network-operator#164 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di ironcore-dev/network-operator
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
apache/rocketmq-dashboard#7243 ·
I maintainer di solito rispondono entro 3 giorni
-
Missing example coverage: getClockForse già presa @camunda-sdk-automation l’ha presa oggi. Apertanew-operations
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
camunda/orchestration-cluster-api-go#75 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
[schema-coverage] elasticstack_kibana_security_entity_store_statusForse già presa @github-actions l’ha presa oggi. Apertaacceptance-tests phase-coding schema-coverage testing triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
elastic/terraform-provider-elasticstack#5396 ·
I maintainer di solito rispondono entro 1 giorno
-
Go device SDK: Whisper transcriber keeps buffering and transcribing audio appended after Stop()Forse già presa @apoorvdarshan l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
BasedHardware/omi#22770 ·
I maintainer di solito rispondono entro 1 giorno
-
Bug v3
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno