【Nexus】Part 5 – vPCについて
Cisco NexusシリーズのNXOSではvPC(virtual PortChannel)というMLAG機能を実装しています。
MLAGはマルチシャーシ・リンクアグリゲーションの略でCisco以外でも利用される一般的な機能名となり、他にもマルチシャーシ・ポートチャネルとも呼ばれることもあります(vPCはNXOSの機能名)。1台のスイッチで利用するポートチャネルを「マルチシャーシ(2台)で実現する機能」となります。
Nexusが登場した初期にはvPCは実装されていて、今や95%のNexusユーザが利用しているというNexusを利用する上で基本的かつ重要な機能となります。今回はこのvPCについて機能概要、用語をご紹介しながら、Nexus9000vを利用した基本的なvPCコンフィグレーションを確認していきたいと思います。
*Nexus9000vシリーズの記事のまとめはこちらから
*Nexus 9000vはversion 9.3(1)を元に動作確認を行っています。
vPCとは
vPCとはSTP(スパニングツリープロトコル)のような"ネットワーク冗長"と、Port Channelのような複数リンクを束ねる"パフォーマンス拡張"の両メリットを実現できるテクノロジです。
STP(スパニングツリープロトコル)は、L2ネットワークで冗長構成とした場合に発生するループ構成を、ブロッキングポートを設けてループとならないようにしてくれます。しかしSTPのブロッキングポイントを設ける=そのリンクを使えないということです。近年トラフィックが増大している中でブロックされたリンクは使えないというのはネットワーク全体のパフォーマンスにおいて大きなデメリットとなります。
複数リンクを活用できる技術としてPort Channelがありますが、基本的には単体機器同士の接続となるで、リンク障害には耐えられますが筐体障害時にはネットワークダウンしてしまいます。
このように冗長性とパフォーマンスの両者メリットをとることができなかったのですが、vPCの登場によりネットワークの冗長性を持ちながらリンクを全て利用できるようになりました。ではvPCがどのような構成になるかというと、下の図の右側のようにNexusを2台ペアとする構成となります。

2台ペアで一台のスイッチのように見せかけてリンクアグリゲーション(LACP or Static)を提供します。こうすることで、vPCに接続するサーバやネットワーク機器に対して冗長性とともにマルチパス(両リンクを使うこと)を提供します。
スタックと比較すると?
vPCは2台を1台に見せかける技術ということで、Cisco CatalystシリーズのスタックやVSSをイメージする方が多いと思います。しかしvPCとスタックでは様々な点で異なる技術となっています。
まずネットワーク機器をパケットをフォワードするデータプレーン、マネジメントやプロトコルを処理するコントロールプレーンに分けて考えた時に、それぞれ以下のような違いがあります。
vPC | 両デバイスでデータプレーンは統合されていて、コントロールプレーンは分離されている |
スタック | データプレーン、コントロールプレーンともに統合されている |
これらが運用面でどのような違いを生み出すのかというと、例えば管理・運用面だと
vPC | コントロールプレーンが別々のため個々の機器に設定が必要。またL3ゲートウェイで利用しようとすると機器毎の物理IPと両機器の仮想IP(HSRP/VRRP)を設定する必要がある。2台ペア構成のため2台以上の構成は不可 |
スタック | コントロールプレーンが一体化しているため、設定は代表スイッチへ投入するのみ。L3ゲートウェアで利用する場合もIPはひとつのみ。複数台での構成が可能(VSSは2台ペア構成) |
一見スタックに比べるとvPCはデメリットが多いようにも見えますが、安全性で見てみると
vPC | コントロールプレーンが何らかの問題でスタックしても影響は片側のみ。またアーキテクチャ上、メンテナンスなどで片側ノードの切り離しも容易 |
スタック | コントロールプレーンが統合されているので、何かSW上で問題があった場合には両機器とも影響を及ぼす可能性が高い |
このようにデータセンターネットワークというミッションクリティカルな環境において、より安全にネットワークシステムを利用できるメリットがあります。
vPCの基本構成要素
ここではvPCの基本構成と用語について説明します。

vPCは各ノード(vPC peer)でActiveとStandbyというステータスをもっています。このステータスはプロトコルを動作させる際の挙動や、障害が発生した時の挙動に影響を与えます。ノード間ではPeer-Linkと呼ばれるノード間リンクで各種データ(ノードのAct/Sbyを決める上でのPriority情報や、各ノードで学習したMACアドレスの情報など)をCFSというプロトコルで情報連携しつつ、リンク障害ではデータの渡りとしても利用されます。10G x2本以上の接続として高帯域・冗長性をもたせます。
Keepalive Linkではお互いのノードの死活監視を行います。この死活監視によってPeer-Linkダウンの際にDual Acitve構成を防いでくれます。まずPeer-Linkがダウンするケースを考えると、基本的には片側ノード障害とPeer-Link障害があります。前者の場合だとKeepaliveの有無で動作は変わらないのですが、問題は後者の場合です。Peer-Link障害でPeer-Linkのみダウンした状態だと、StandbyだったノードがActiveに昇格して各ノードともActiveとなるDual Active構成となってしまいます。これはスタックのデュアルコントロールプレーンとほぼ同じ状況で、2台のノードが情報をシンクロできないで配下のスイッチとLAGを構成している状態なのでネットワークが混乱する恐れがあります。このようなケースでKeepaliveによる監視を行っていると、Peer-Linkがダウンして両ノードが動作していることを確認した場合には、Standby側のvPCポートをダウンさせるなどしてActive-Activeとならないように対処します。このようにKeepalive LinkはPeer−Linkダウンの際にネットワークを混乱させないようにするための非常に重要な役割を担っています。通常はマネジメントNW経由で接続しますが、機種によってはインバンドでの管理を推奨することもあるようです。
vPC接続するにはvPC member port設定をいれることで、配下のスイッチやサーバとマルチシャーシでリンクアグリゲーション接続することが可能です。もうひとつの用語として、Orphan Port(オーファンポート)とありますが、いわゆる片足接続となります。vPC構成とすると全てvPC接続となる必要があるわけではなく片足の接続もサポートされています。
以下に各用語と役割をまとめます。
vPC | vPC Peer デバイスとダウンストリーム デバイスの間の結合されたポートチャネル |
vPC Peer | vPC Peer Linkと呼ばれる特殊なポート チャネルで接続されている一対のデバイス。それぞれプライマリとセカンダリのロールを持つ |
vPC Peer-Link | vPC Peer デバイス間の状態を同期するために使用されるリンク。直接接続で10G以上利用 |
vPC Domain | このドメインにvPCの構成要素が含まれる |
vPC Peer Keepalive Link | vPC Peer デバイスを定期的なキープアライブで監視。利用推奨ポートはシリーズにより異なる(基本はmgmtポート) |
vPC Member Port | vPCに属するインターフェイス |
Orphan Port/Device | vPC Domain内の片側のデバイスにのみ属するポートとデバイス |
CFS(Cisco Fabric Services) | MACアドレス,STP、IGMPなど、vPC peer デバイス間で同期の際にCFSを使用 |
基本的なデータフロー
vPCのデータフローは以下のようになります。vPC配下のトラフィック分散は、それぞれのサーバやスイッチに依存しますが、vPCではそれらのトラフィックを適切に処理します。アップストリームのリンクに障害が発生した場合には、渡りのPeer-linkをたどって通信をするようになります。

L2 vPC 基本コンフィグレーション
それではここからvPC構成の基本コンフィグレーションの確認と動作確認を行いたいと思います。構成については通常のvPC接続の他に、少しひねってOrphan Port(オーファンポート)も組み込みたいと思います。
vPCでは2台ペアのNexusと配下の機器でLAGを構成すること、すなわちvPC接続が可能ですが、それ以外にも片側のNexusと片足接続(Orphan Port/Device)を構成することもできます。
以下のようなvPC配下に”vPC接続したL2スイッチx2台”と、”片足接続のデバイス(FWなどのアプライアンス見立て)x2台”をそれぞれVLAN100で接続。そしてL2スイッチ配下のデバイスと片足接続のデバイスの各機器間で疎通確認したいと思います。

NXOS1
hostname NXOS1
feature lacp
feature vpc
vlan 100
vpc domain 10
peer-keepalive destination 192.168.0.2
interface port-channel1
switchport mode trunk
switchport trunk allowed vlan 1,100
vpc 1
interface port-channel2
switchport mode trunk
switchport trunk allowed vlan 1,100
vpc 2
interface port-channel10
switchport mode trunk
switchport trunk allowed vlan 1,100
vpc peer-link
interface Ethernet1/1
switchport mode trunk
switchport trunk allowed vlan 1,100
channel-group 1 mode active
interface Ethernet1/2
switchport mode trunk
switchport trunk allowed vlan 1,100
channel-group 2 mode active
interface Ethernet1/3
switchport access vlan 100
interface Ethernet1/6
switchport mode trunk
switchport trunk allowed vlan 1,100
channel-group 10 mode active
interface Ethernet1/7
switchport mode trunk
switchport trunk allowed vlan 1,100
channel-group 10 mode active
interface mgmt0
ip address 192.168.0.1/24
NXOS2
hostname NXOS2
feature lacp
feature vpc
vlan 100
vpc domain 10
peer-keepalive destination 192.168.0.1
interface port-channel1
switchport mode trunk
switchport trunk allowed vlan 1,100
vpc 1
interface port-channel2
switchport mode trunk
switchport trunk allowed vlan 1,100
vpc 2
interface port-channel10
switchport mode trunk
switchport trunk allowed vlan 1,100
vpc peer-link
interface Ethernet1/1
switchport mode trunk
switchport trunk allowed vlan 1,100
channel-group 1 mode active
interface Ethernet1/2
switchport mode trunk
switchport trunk allowed vlan 1,100
channel-group 2 mode active
interface Ethernet1/3
switchport access vlan 100
interface Ethernet1/6
switchport mode trunk
switchport trunk allowed vlan 1,100
channel-group 10 mode active
interface Ethernet1/7
switchport mode trunk
switchport trunk allowed vlan 1,100
channel-group 10 mode active
interface mgmt0
ip address 192.168.0.2/24
動作確認結果
Orphan Portで接続したデバイスや、vPC接続したL2スイッチ配下のデバイス間でお互いでPing疎通の確認をしてみたところ問題なくPing疎通できるていることを確認しています。
次回はL3 vPC構成について
今回はL2 vPC構成についての機能概要、vPCの用語や基本コンフィグを確認しました。次回は一歩進んでL3ゲートウェイとして利用可能なL3 vPC構成や、vPCのベストプラクティス構成、その他様々なvPCの推奨オプションなどについて確認しみたいと思います。
参考ドキュメント
Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 9.3(x)
vPC Best Practices and Design on NXOS