Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#440 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, grpc
領域
networking

調査の方向性

api/core/v1alpha1/bgp_peer_types.go と api/cisco/nx/v1alpha1/bgpconfig_types.go から開始し、BGPPeer のリコンシリエーションを cisco-nxos-gnmi provider まで追跡します。既存の peer mapping を NX-OS PeerIf-list の例および Interface の動作と比較します。完了条件には、外部 AS の処理を伴うインターフェースベースの peer、address との相互排他、および provider の検証を含める必要があります。RA 設定はオプションの拡張です。

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
Go
スター
12
フォーク
9
平均マージ
3日 15時間
マージ済み PR（30日）
46

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ironcore-dev/network-operator のほかの issue

ironcore-dev/network-operator の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。