Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#440 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, grpc
Área
networking

Línea de trabajo

Comienza con api/core/v1alpha1/bgp_peer_types.go y api/cisco/nx/v1alpha1/bgpconfig_types.go, y después sigue la reconciliación de BGPPeer hasta el provider cisco-nxos-gnmi. Compara el mapeo existente de peers con el ejemplo NX-OS PeerIf-list y el comportamiento de Interface. El trabajo terminado debe cubrir los peers basados en interfaces con el manejo de AS externa, la exclusión mutua con address y la verificación del provider; la configuración de RA es una extensión opcional.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Go
Estrellas
12
Forks
9
Merge medio
3 d 15 h
PR fusionados (30 d)
46

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ironcore-dev/network-operator

Todos los issues de ironcore-dev/network-operator

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.