You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
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).
Map the interface-peer to the NX-OS DME peerif-items/PeerIf-list[id=<intf>] (asnType: external) in the cisco-nxos-gnmi provider.
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
Summary
Note
With some guidance I am happy to open a PR.
BGPPeercan only express a numbered IPv4 neighbor (spec.addressis+requiredwith+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-gnmiprovider. CLI:The session establishes over the peer's IPv6 link-local
(
fe80::…%Ethernet1/1). In the NX-OS DME model it appears under:Important
NX-OS suppresses Router Advertisements by default, so the unnumbered peers cannot discover each other's link-local until
no 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
BGPPeerto reference an interface instead of an address, e.g. aspec.interfaceRef(mutually exclusive withspec.address), and permitasNumberto beexternal(dynamic /remote-as external).peerif-items/PeerIf-list[id=<intf>](asnType: external) in thecisco-nxos-gnmiprovider.ipv6 nd suppress-ra(andip forward/use-link-local-only) on theInterfacetype so an unnumbered link can be fully declared.Environment
cisco-nxos-gnmi