Cisco Nexus 9000 vPC 設定のベストプラクティスと VSS との違い

  • URLをコピーしました!
目次

はじめに

データセンター向けスイッチである Cisco Nexus シリーズにおいて、冗長構成の標準的な技術として広く採用されているのが vPC(Virtual Port Channel) です。

本記事では、2026 年時点で Cisco が推奨する現役プラットフォームである Nexus 9000 シリーズを題材に、vPC の仕組み・VSS との違い・具体的な設定手順・ベストプラクティスコマンド・トラブルシューティングまでを実務目線で解説します。

参考: Cisco 公式「Recommended Cisco NX-OS Releases for Cisco Nexus 9000 Series Switches」
2026 年 1 月時点で Cisco が推奨する Nexus 9000 向け NX-OS バージョンは 10.4(3)F 以降とされています。
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/recommended_release/b_Minimum_and_Recommended_Cisco_NX-OS_Releases_for_Cisco_Nexus_9000_Series_Switches.html

なお、本記事のコマンド体系は Nexus 9000 シリーズ基準ですが、Nexus 7000 や 5000 シリーズでも大部分はそのまま適用可能です。旧機種を利用している場合は、Nexus 9000 への移行計画と合わせて参照することを推奨します。

この記事でわかること
  • 基礎: vPC の仕組みと VSS との違い
  • 構成要素: Peer-Keepalive と Peer-Link の役割、Orphan ポートの概念
  • 設定: Nexus 9000 における構築手順と、運用推奨のベストプラクティスコマンド
  • 制約事項: vPC の設計上の制約と注意点
  • トラブルシューティング: 整合性チェックや切り分けの実践

vPC(Virtual Port Channel)とは

vPC とは、物理的に異なる 2 台の Nexus スイッチを、接続される対向機器(サーバーや下位スイッチ)からは「論理的に 1 台のスイッチ」として見せる技術です。業界標準用語では MC-LAG(Multi-Chassis Link Aggregation) と呼ばれる技術の一種にあたります。

vPC を導入するメリット

従来の STP(Spanning Tree Protocol)を使った冗長構成では、ループを防ぐために片方のリンクが「ブロッキング(待機)」状態になり、物理的に接続した帯域の半分が活用できない状態となっていました。vPC を導入することで、以下のメリットが得られます。

① STP ブロックの排除
ループフリーな構成となるため、STP によるブロッキングが発生せず、すべてのリンクをデータ転送に利用できます。

② 帯域の最大活用
2 本のリンクを Active/Active で利用できるため、物理帯域をフルに活用できます。

③ 高可用性
片方のスイッチがダウンしても、もう片方で通信を継続できます。HSRP/VRRP と組み合わせた場合の切替時間は一般的にサブ秒(数百 ms 程度)で収束します。

vPC と VSS の違い

vPC(Nexus)と VSS(Catalyst)は、どちらも「2 台のスイッチをまたいでリンクアグリゲーション(PortChannel)を組む」という目的を達成する技術ですが、内部アーキテクチャは大きく異なります。

最大の違いは、コントロールプレーンが統合されるか独立しているかという点です。

VSS(Catalyst): 統合アーキテクチャ

VSS は、2 台のスイッチが「1 台の論理スイッチ」として統合動作します。

  • コントロールプレーン: 単一(Active 機が全体を制御)
  • 設定: running-config は自動的に同期される
  • 管理 IP: 1 つ(VSS 全体で共有)

vPC(Nexus): 独立協調アーキテクチャ

vPC は、独立した 2 台のスイッチが協調動作することで、対向機器から 1 台に見せるアプローチです。

  • コントロールプレーン: 2 つ(それぞれが独立して動作)
  • 設定: 自動同期されない。左右のスイッチそれぞれに同じ設定(VLAN、インターフェース設定等)が必要
  • 管理 IP: 2 つ(各筐体に必要)

比較表

項目vPC(Nexus)VSS(Catalyst)
対象プラットフォームCisco Nexus シリーズCisco Catalyst 6500/4500-X など
コントロールプレーンセパレート(独立)
※2 つのコントロールプレーンが稼働
統合(単一)
※1 つのコントロールプレーンで制御
コンフィグ同期手動(同期しない)
※両機への設定投入が必要
自動(同期する)
※Active 機への設定だけで反映
管理 IP アドレス2 つ(各筐体に必要)1 つ(VSS 全体で共有)
MC-EtherChannel(MEC)◯(対応)◯(対応)

💡 注意点
vPC 環境では、「左のスイッチには VLAN 10 を作ったが、右のスイッチには作り忘れた」という設定不一致(Config Mismatch)が起きやすくなります。これを防ぐため、後述の show vpc consistency-parameters による整合性確認を推奨します。

vPC の構成要素

vPC を構成するには、2 台のスイッチ間に役割の異なる 2 種類のリンクと、実トラフィックを扱うメンバーポートが必要です。物理設計の段階でこれらを適切に配置することが、運用の安定性に直結します。

① vPC Peer-Keepalive Link(生存確認リンク)

2 台のスイッチが互いに生存確認(Heartbeat)を行うためのリンクです。

  • 役割: 相手の生存確認(Heartbeat)。L3 接続(IP 到達性)が必要
  • 流れるデータ: UDP の小さなパケットのみ。ユーザーデータは流れない
  • 物理構成: 帯域要件は低いため、通常はマネジメントポート(mgmt0)を直結、または管理用ネットワーク経由で接続
  • デフォルトタイマー: Hello interval 1 秒、Hold timer 3 秒、Timeout 5 秒

⚠️ Peer-Keepalive が切断された場合: 相手がダウンしたのか、単に通信が途絶しただけなのかの判別ができなくなり、障害時の挙動(スプリットブレイン)に影響します。

② vPC Peer-Link(制御・データ同期リンク)

2 台のスイッチを論理的に結合するための重要度の高いリンクです。

  • 役割:
  • 制御情報の同期: MAC アドレステーブルや IGMP 等の制御情報(CFS)を同期
  • データ転送: 通常時は流れないが、メンバーポート障害時やブロードキャストパケット等が通過する
  • 構成: PortChannel(LACP)での構成が前提。Trunk ポートとして設定する
  • 冗長化: 10G/40G/100G のリンクを 2 本以上束ねて冗長化することを推奨

③ vPC Member Port(メンバーポート)

サーバーや下位スイッチに接続するためのポートです。

  • 役割: 実際のユーザートラフィックを処理
  • 構成: 左右のスイッチで同じ vPC 番号(例:vpc 10)を設定することで、対向機器から 1 つの PortChannel として認識される

④ Orphan ポート(片側接続ポート)

実務で重要な概念として Orphan ポートがあります。

  • 定義: vPC を組まずに、vPC ドメインの片側のスイッチだけに接続されているポート
  • 例: シングル NIC で片方の Nexus にしか接続されていないサーバー、LACP をサポートしていない古い機器
  • 注意点: vPC のループ回避メカニズムにより、メンバーポートから Peer-Link 経由で対向 Nexus に流れたパケットは、対向側のメンバーポートからは出ることができないという制約があります。Orphan ポートまたは L3 ポート経由でしか出られないため、トラフィック設計時に考慮が必要です

後述の設定手順で、Orphan ポート向けの安全策である vpc orphan-port suspend コマンドについて解説します。

設計上の制約事項と注意点

vPC は運用が確立された技術ですが、設計段階で押さえておくべき根本的な制約があります。これらを把握せずに設計を進めると、後から修正が困難になるケースがあるため、事前の確認を推奨します。

制約
vPC ドメインは最大 2 台まで

vPC は 最大 2 台のスイッチで構成する技術です。3 台以上のスイッチでマルチシャーシ LAG を組むことはできません。3 台以上の冗長構成を組みたい場合は、後述する VXLAN EVPNIP CLOS 設計への移行を検討することを推奨します。

制約
Peer-Link 経由のパケットフロー制約

vPC のループ回避メカニズムとして、「メンバーポートから Peer-Link 経由で対向 Nexus に流れたパケットは、対向側のメンバーポートからは出ることができない」という制約があります。

この制約により、Peer-Link 経由で入ってきたパケットは以下のいずれかの経路でしか出られません。

  • 同じ vPC ドメイン内の L3 ポート(SVI や物理ルーテッドポート経由)
  • Orphan ポート(片側接続のポート)

この挙動を知らないと、「トラフィックが片方のスイッチに偏る」「特定の通信が通らない」といったトラブルの原因となります。特にサーバー側の NIC Teaming 設定が Active/Standby の場合、トラフィックが Peer-Link に集中するケースがあります。

制約
3 データセンター以上の接続には非推奨

vPC は最大 2 拠点間の DCI(Data Center Interconnect)接続までを前提として設計されています。3 拠点以上を相互接続する場合は、vPC ではなく VXLAN EVPNOTV(Overlay Transport Virtualization)IP CLOS などの採用が推奨されます。

制約
コントロールプレーンの独立性に伴う制約

vPC は 2 台が独立したコントロールプレーンで動作するため、以下の制約が生じます。

  • 設定の自動同期はされない: 左右両方に同じ設定を投入する必要がある(設定漏れによる Type-1 不一致が発生しやすい)
  • NX-OS バージョンの不一致リスク: 一時的な混在は可能だが、長期的な運用では揃えることが推奨される
  • ISSU(In-Service Software Upgrade)時の順序制約: 一度に 1 台ずつ vPC ピアデバイスで実施する必要がある

参考: Cisco 公式「ベストプラクティスを使用した Nexus 9000 vPC の概要と設定」
“vPC ドメインの NX-OS コードリリースを変更するには、ISSU(In-Service Software Upgrade)を使用してください。順番に、一度に 1 つの vPC ピアデバイスで操作を実行してください。”
https://www.cisco.com/c/ja_jp/support/docs/switches/nexus-9000-series-switches/218333-understand-and-configure-nexus-9000-vpc.html

制約
Peer-Link と Peer-Keepalive の同時障害への対応

Peer-Link と Peer-Keepalive が同時にダウンすると、スプリットブレイン(両スイッチがともに Primary として動作する状態)のリスクが生じます。以下の対策を組み合わせることを推奨します。

  • Peer-Link の冗長化: 最低 2 本以上の物理リンクで構成
  • Peer-Keepalive の経路独立化: Peer-Link とは別の物理経路を確保(mgmt0 直結が典型)
  • vpc orphan-port suspend の設定: Orphan ポート接続機器へのブラックホール化を回避
  • auto-recovery の有効化: Peer-Link 復旧後のサービス自動復旧

設定手順

今回作成する構成イメージ

  • 対象機器: Nexus 9000 シリーズ 2 台(N9K-1N9K-2
  • Peer-Link: Ethernet 1/31Ethernet 1/32 を 2 本束ねて使用
  • Peer-Keepalive: mgmt0 ポートを使用(1.1.1.0/24 セグメント)
  • vPC ドメイン ID: 1
  • メンバーポート: Ethernet 1/1 を使用(サーバー接続用 vpc 10
STEP
事前準備(Feature 有効化・Mgmt 設定)

Nexus はデフォルトですべての機能が無効化されています。vPC と LACP を利用するために、機能(Feature)を有効化し、Peer-Keepalive 用の IP アドレスを設定します。

STEP
機能の有効化

両方のスイッチ(N9K-1N9K-2)で実行します。

N9K-1(config)# feature lacp
N9K-1(config)# feature vpc

これを忘れると、vPC 関連のコマンドが一切入力できません。

STEP
Keepalive 用 IP の設定(mgmt0)

マネジメントポートに IP アドレスを設定します。これが Peer-Keepalive の送受信に使われます。

! N9K-1(Primary 側)
N9K-1(config)# interface mgmt 0
N9K-1(config-if)# ip address 1.1.1.1/24
N9K-1(config-if)# no shutdown

! N9K-2(Secondary 側)
N9K-2(config)# interface mgmt 0
N9K-2(config-if)# ip address 1.1.1.2/24
N9K-2(config-if)# no shutdown
STEP
vPC ドメインと Peer-Link の作成

vPC 構築のポイントとなる部分です。ドメインを定義し、Peer-Keepalive と Peer-Link を構成します。ここで Cisco 公式推奨のベストプラクティスコマンドをあわせて設定することで、運用時のコンバージェンスや障害耐性が大きく向上します。

STEP
vPC ドメインの作成と Keepalive・ベストプラクティス設定

左右で同じドメイン ID(ここでは 1)を使用します。

! N9K-1(Primary 側)
N9K-1(config)# vpc domain 1
N9K-1(config-vpc-domain)# role priority 100
N9K-1(config-vpc-domain)# peer-keepalive destination 1.1.1.2 source 1.1.1.1 vrf management
N9K-1(config-vpc-domain)# peer-switch
N9K-1(config-vpc-domain)# peer-gateway
N9K-1(config-vpc-domain)# auto-recovery
N9K-1(config-vpc-domain)# ip arp synchronize
N9K-1(config-vpc-domain)# delay restore 150
N9K-1(config-vpc-domain)# exit

! N9K-2(Secondary 側)
N9K-2(config)# vpc domain 1
N9K-2(config-vpc-domain)# role priority 110   ! 値が大きい方が Secondary
N9K-2(config-vpc-domain)# peer-keepalive destination 1.1.1.1 source 1.1.1.2 vrf management
N9K-2(config-vpc-domain)# peer-switch
N9K-2(config-vpc-domain)# peer-gateway
N9K-2(config-vpc-domain)# auto-recovery
N9K-2(config-vpc-domain)# ip arp synchronize
N9K-2(config-vpc-domain)# delay restore 150
N9K-2(config-vpc-domain)# exit

各ベストプラクティスコマンドの役割

コマンド役割
peer-switch両 vPC ピアを STP Root として動作させ、STP コンバージェンス時間を短縮
peer-gateway対向ピア宛てのパケットを自分のものとして処理(HSRP/VRRP や NetApp 等での Active-Active 通信に有用)
auto-recoveryPeer-Link 復旧後、ピアが起動してこない場合に自動的に vPC サービスを復旧。デフォルト timeout は 240 秒
ip arp synchronizeピア間の ARP テーブルを同期。L3 トラフィックのコンバージェンス時間を改善
delay restore 150vPC ピア復旧時の遅延を 150 秒に設定(デフォルトは 30 秒)。リロード直後の不安定状態でメンバーポートを先に上げるのを避ける

参考: Cisco 公式「ベストプラクティスを使用した Nexus 9000 vPC の概要と設定」
https://www.cisco.com/c/ja_jp/support/docs/switches/nexus-9000-series-switches/218333-understand-and-configure-nexus-9000-vpc.html

💡 peer-gateway の補足
Nexus が対向スイッチ(Peer)宛てのパケットを受信した際、それを捨てずに自分のものとして処理する設定です。HSRP/VRRP を組む場合や、NetApp など一部ストレージ製品との接続時にパケットドロップを防ぐ効果があります。

STEP
vPC Peer-Link の設定

Ethernet 1/311/32 を束ねて Peer-Link を作成します。通常の LACP 設定に加え、vpc peer-link コマンドを入れることで Peer-Link として動作します。

! N9K-1 および N9K-2(両機に同じ設定を投入)
interface Ethernet1/31-32
  channel-group 1 mode active
  no shutdown
  exit

interface port-channel 1
  switchport mode trunk
  switchport trunk allowed vlan 1,10,20        ! 必要な VLAN を通す
  spanning-tree port type network              ! Bridge Assurance 用(自動設定されることが多い)
  vpc peer-link                                ! Peer-Link として指定する重要なコマンド
  no shutdown
STEP
メンバーポート(ダウンリンク)の設定

サーバーや下位スイッチを接続する メンバーポートを設定します。ここが VSS と一番異なる部分です。左右のスイッチに同じ vPC 番号を設定することで、対向機器からは 1 つの PortChannel として認識されます。

例として、Ethernet 1/1 を使ってサーバー接続用の vpc 10 を作成します。

! N9K-1(Primary 側)
interface Ethernet1/1
  channel-group 10 mode active
  no shutdown

interface port-channel 10
  switchport mode trunk
  vpc 10        ! 左右で同じ vPC 番号を設定

! N9K-2(Secondary 側)
interface Ethernet1/1
  channel-group 10 mode active
  no shutdown

interface port-channel 10
  switchport mode trunk
  vpc 10        ! 左右で同じ vPC 番号を設定

これにより、対向のサーバーからは「1 つの Port-Channel 10」として認識され、2 本のケーブルで帯域をフル活用できる状態となります。

STEP
Orphan ポート対策(推奨)

LACP をサポートしないサーバーや、片側 Nexus にしか接続されていないサーバー(Orphan ポート接続)がある場合、Peer-Link 障害時にトラフィックがブラックホール化するリスクがあります。これを防ぐため、vPC ドメインで vpc orphan-port suspend を設定することを推奨します。

! 対象の Orphan ポート側で設定(両スイッチで該当ポートに設定)
interface Ethernet1/5
  description Orphan-Port to Legacy-Server
  switchport mode access
  switchport access vlan 10
  vpc orphan-port suspend
  no shutdown

この設定により、Peer-Link 障害時に Secondary 側の Orphan ポートが自動的に shutdown され、サーバー側の NIC Teaming(Active/Standby)が Primary 側に切り替わる動作が期待できます。

ステータス確認

設定が完了したら、vPC が正常に動作しているかを確認します。「設定したのに通信が成立しない」というケースの多くは、左右スイッチのパラメータ不一致(Consistency Error)が原因です。

① 基本ステータスの確認(show vpc)

vPC の状態を一覧で確認できる基本コマンドです。

N9K-1# show vpc

正常時に確認すべきポイント

項目正常時の表示異常時のチェック箇所
vPC keep-alive statuspeer is aliveマネジメントポートの IP 設定、ケーブル、ルーティング
Peer statuspeer adjacency formed okPeer-Link の物理接続、LACP、vpc peer-link 設定
Configuration consistency statussuccess両機の設定差異(次項の consistency-parameters で詳細確認)
vPC status 表の Statusupメンバーポートの設定
vPC status 表の ConsistencysuccessType-1 パラメータの不一致

出力例(正常時)

Legend:
    (*) - local vPC is down, forwarding via vPC peer-link

vPC domain id                   : 1
Peer status                     : peer adjacency formed ok
vPC keep-alive status           : peer is alive
Configuration consistency status: success
Per-vlan consistency status     : success
Type-2 consistency status       : success
vPC role                        : primary
Number of vPCs configured       : 1
Peer Gateway                    : Enabled
Graceful Consistency Check      : Enabled
Auto-recovery status            : Enabled (timeout = 240 seconds)
Delay-restore status            : Timer is off.(timeout = 150s)
...

vPC status
----------------------------------------------------------------------------
id     Port        Status Consistency Reason                     Active vlans
------ ----------- ------ ----------- -------------------------- -----------
10     Po10        up     success     success                    10

② 設定整合性の確認(show vpc consistency-parameters)

vPC は左右のスイッチで設定が一致していることが動作条件となります。通信不良が発生する場合、このコマンドで設定不一致(ミスマッチ)の有無を確認することを推奨します。

N9K-1# show vpc consistency-parameters global

Type-1 と Type-2 の違い

種別挙動代表的なパラメータ
Type-1不一致だと vPC がダウン(Suspend)する重大な項目STP モード、STP リージョン設定、MTU、LACP Mode、Native VLAN、Allowed VLAN、Speed、Duplex
Type-2不一致でも警告が出るだけで通信は継続する項目QoS パラメータの一部、STP Priority、ポートのインターフェース設定の一部

出力結果で Local ValuePeer Value の値が食い違っている箇所がないかを確認することを推奨します。特に Type-1 不一致は vPC の Suspend に直結するため、優先的な確認対象となります。

💡 Graceful Consistency Check について
Nexus のデフォルトでは Graceful Consistency Check が有効になっており、稼働中の vPC で不一致が発生した場合、Secondary 側のリンクのみを一時停止することで、Primary 側の通信継続を保つ挙動となります。この機能は graceful consistency-check コマンドで制御できます(デフォルト有効)。

トラブルシューティング

vPC 構築時・運用中によく発生する問題と、その切り分けフローを整理します。

Case
vPC keep-alive status が Failed になる

症状: show vpcvPC keep-alive status: peer is alive が表示されない。

主な原因と切り分け

STEP
mgmt0 の IP 到達性: 相互に ping が通るか確認
N9K-1# ping 1.1.1.2 vrf management
STEP
VRF 指定の漏れ

peer-keepalive destination ... vrf management の VRF 指定を確認

STEP
mgmt0 のケーブル接続

物理接続(直結ケーブルの場合)、管理ネットワーク経由の場合はルーティングを確認

STEP
IP アドレスの重複

管理ネットワーク全体で IP が重複していないか確認

Case
Peer status が peer adjacency formed ok にならない

症状: Peer-Keepalive は OK だが、Peer-Link の adjacency が確立しない。

主な原因と切り分け

STEP
物理リンクの状態

show interface Ethernet 1/31-32up 状態を確認

STEP
LACP の状態

show port-channel summary で PortChannel が SU (Eth) になっているか確認

STEP
vpc peer-link コマンドの漏れ

Peer-Link 用の PortChannel に vpc peer-link が入っているか

STEP
VLAN 設定の不一致

switchport trunk allowed vlan の内容が両機で一致しているか

Case
メンバーポートの Consistency が failed になる

症状: show vpc の vPC status 表で Consistency: failed と表示され、メンバーポートが Suspend する。

切り分けコマンド

N9K-1# show vpc consistency-parameters interface port-channel 10

確認ポイント(Type-1 パラメータ)

  • STP ModeSTP Region Configuration
  • MTU
  • LACP Modeactive / passive / on の不一致)
  • Native VLANAllowed VLAN
  • SpeedDuplex

上記のいずれかで Local ValuePeer Value が異なっていれば、該当箇所を両機で統一します。

Case
HSRP/VRRP が正しく動作しない

症状: HSRP/VRRP を組んだが、Active-Active で転送できない、または特定の通信が通らない。

主な原因

peer-gateway コマンドの未設定

vPC ドメインで peer-gateway を設定していないと、対向ピア宛てのパケットが正しく処理されないケースがあります

peer-switch コマンドの未設定

STP のルート選定が意図通りにならず、コンバージェンスが遅延する可能性があります

Case
Orphan ポートに接続した機器の通信断

症状: Peer-Link 障害時に、Orphan ポート経由の機器への通信が一時的に途絶する。

原因: Peer-Link 障害で Secondary 側がメンバーポートを Suspend した際、Orphan ポート経由のトラフィックが行き場を失いブラックホール化する。

確認コマンド一覧(実運用向け)

対処: 該当 Orphan ポートに vpc orphan-port suspend を設定することで、Peer-Link 障害時に Secondary 側の Orphan ポートも強制的にダウンさせ、サーバー側の NIC Teaming による切り替えを促します。

! vPC 全体の状態確認
show vpc
show vpc brief
show vpc role

! 整合性チェック
show vpc consistency-parameters global
show vpc consistency-parameters interface port-channel <番号>

! Peer-Keepalive の統計
show vpc peer-keepalive

! PortChannel の状態
show port-channel summary
show interface port-channel <番号>

! STP の状態
show spanning-tree summary
show spanning-tree vlan <VLAN 番号>

参考: Cisco 公式「Cisco Nexus 9000 Series NX-OS Troubleshooting Guide」
Cisco 公式のトラブルシューティングガイドには、より詳細なチェックリスト・確認コマンド・想定される症状ごとの原因が整理されています。
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/troubleshooting/guide/b-cisco-nexus-9000-series-nx-os-troubleshooting-guide-101x.html

vPC と VXLAN EVPN の使い分け

Nexus 9000 シリーズでは、マルチシャーシ冗長化の選択肢として vPC だけでなく、VXLAN EVPN も広く利用されています。両者の位置づけを整理すると、設計判断が容易になります。

vPC が向いているケース

  • 2 台構成のデータセンタースイッチ冗長化(典型的な Collapsed Aggregation / Top-of-Rack 構成)
  • 小規模〜中規模の L2 冗長要件
  • 既存の STP ベース設計からの段階的な刷新
  • サーバーの NIC Teaming(LACP)を Active-Active で活用したい

VXLAN EVPN が向いているケース

  • 3 台以上のスイッチでマルチパスを組みたい(Leaf-Spine 構成)
  • データセンターをまたぐ L2 拡張(DCI)
  • 大規模な L2 セグメント拡張が必要(VLAN 4094 の上限を超える要件等)
  • マルチテナント要件や Tenant 分離
  • IP CLOS アーキテクチャに基づく最新のスケーラブル設計

比較表

項目vPCVXLAN EVPN
最大構成台数2 台数百台規模
マルチパス2 パス(Active-Active)ECMP による多パス
L2 拡張同一サブネット内VNI による仮想化で広域拡張可能
マルチテナント限定的(VLAN ベース)VRF + VNI で柔軟に対応
設計複雑度中〜高
推奨規模小〜中規模中〜大規模
運用ノウハウ成熟近年急速に拡大

組み合わせた利用も可能

実務では、Leaf スイッチのペアに vPC を組み、その Leaf ペア同士を VXLAN EVPN で接続するという構成(vPC + VXLAN EVPN)も一般的です。この構成は vPC Fabric Peering と呼ばれ、Nexus 9000 シリーズで公式にサポートされています。既存の vPC 設計を活かしつつ、VXLAN EVPN の拡張性を取り入れたい場合の選択肢となります。

まとめ

本記事では、Cisco Nexus 9000 シリーズにおける vPC の仕組み・設定手順・ベストプラクティス・トラブルシューティングまでを解説しました。

  • vPC は 2 台の Nexus スイッチを対向機器から 1 台に見せる技術で、STP ブロックを排除して帯域をフル活用できる。
  • VSS と異なり、vPC はコントロールプレーンが独立しているため、設定は左右両方に手動で投入する必要がある。
  • 運用時は peer-switchpeer-gatewayauto-recoveryip arp synchronizedelay restore などの Cisco 公式推奨ベストプラクティスコマンドの設定を推奨する。
  • Orphan ポートへの対策として vpc orphan-port suspend を設定することで、Peer-Link 障害時のブラックホール化を回避できる。
  • show vpc consistency-parametersType-1 / Type-2 パラメータの不一致を定期的に確認することを推奨する。
  • vPC は最大 2 台構成までの制約があるため、3 台以上の冗長や DC 間接続では VXLAN EVPN の採用を検討することを推奨する。

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

主にインフラを得意とするエンジニアです。日々の業務で得た実践的なノウハウや、最新の脆弱性ニュースなどを備忘録を兼ねて発信しています。
同じエンジニアの方々の課題解決のヒントになれば嬉しいです。

[ Certs ] CCIE Lifetime Emeritus / VCAP-DCA ✒️ [ Life ] 技術書・ビジネス書愛好家📖 / 小・中学校で卓球コーチ👟

目次