Virtualized Host Connectivity

このページのゴール

仮想化ホストの各アップリンクが運ぶVLAN数とNICバンドル要件からアクセス・トランクおよびLACPを選択・構成できるようにする。

このページで学ぶこと

• 仮想化ホストのアップリンク単位
• 単一VLANのハイパーバイザ・アクセス接続
• 複数VLANのハイパーバイザ・トランク接続
• ハイパーバイザのVLANタグ付け要件
• 仮想化ホストバンドル要件
• ホスト側のLACP対応可否
• ホストEtherChannelの同一論理ピア条件
• 仮想化ホストLACP設定
• 仮想化ホストのトランクPort-Channel
• 仮想化ホスト・エッジ確認

仮想化ホストはホスト全体ではなくアップリンク単位で判断する

仮想化ホストには複数の物理NICが搭載され、複数の仮想マシン（VM）や複数VLANを扱うことがあります。

しかし、

仮想化ホストで複数VLANを使う
↓
すべての物理NICをトランクにする

とは限りません。

スイッチポートを設計するときに確認するのは、

仮想化ホスト全体で何VLAN使うか

だけではなく、

各物理アップリンク
または
各論理Port-Channel

が実際に何VLANを運ぶか

です。

基本的な判断順は、

アップリンクを特定
↓
そのアップリンクで運ぶVLAN数を確認
↓
1 VLANならアクセスが成立し得る
↓
複数VLANならトランク
↓
複数NICをバンドルする要件があるか確認
↓
ホスト側LACP対応可否を確認
↓
スイッチ側Port-Channelを構成
↓
トランク状態とバンドル状態を確認

です。

物理ホストと仮想ネットワークを分けて考える

仮想化ホストでは、物理NICの内側に仮想スイッチなどの仮想ネットワーク機能が存在する構成があります。

概念的には、

VM-A ─┐
      ├─ 仮想スイッチ ─ 物理NIC ─ スイッチ
VM-B ─┘

となります。

複数VLANを扱う場合は、

VM・仮想ポート
↓
仮想スイッチ
↓
物理NIC
↓
物理スイッチポート

の各区間でVLANの扱いが整合している必要があります。

仮想化ホストのアップリンク単位

アクセス・トランクを判断する単位は、ホスト全体ではありません。

たとえばホストに2本のNICがあり、

NIC1
→ VLAN 10のみ

NIC2
→ VLAN 20のみ

という設計なら、ホスト全体としては2 VLANを使用しています。

しかし各アップリンクは、

NIC1
→ 1 VLAN

NIC2
→ 1 VLAN

です。

したがって、それぞれを独立したアクセスポートとして構成する設計が成立します。

ホスト全体のVLAN数だけでトランクにしない

次の構成を考えます。

仮想化ホスト

NIC1
→ 管理ネットワーク
→ VLAN 10

NIC2
→ サーバネットワーク
→ VLAN 20

スイッチ側：

Gi1/0/10
→ NIC1

Gi1/0/11
→ NIC2

各リンクが1 VLANだけを運ぶなら、

Gi1/0/10
→ アクセスVLAN 10

Gi1/0/11
→ アクセスVLAN 20

という構成が可能です。

ホスト全体でVLAN 10と20を使用するからといって、

Gi1/0/10
Gi1/0/11
→ 両方トランク

にする必要はありません。

単一VLANのハイパーバイザ・アクセス接続

1本の物理アップリンクが1つのVLANだけを運ぶ設計では、スイッチ側アクセスポートが成立し得ます。

要件：

ハイパーバイザNIC1
→ 管理ネットワーク

管理ネットワーク
→ VLAN 10

代表的なスイッチ設定：

interface GigabitEthernet1/0/10
 switchport
 switchport mode access
 switchport access vlan 10

この場合、スイッチはタグなしトラフィックをアクセスVLAN 10として扱います。

アクセスポート側ではホストが複数VLANをタグ付けする必要はない

スイッチポートが単一VLANのアクセスポートとして設計されている場合、その物理リンクで複数VLANを802.1Qタグ付けして運ぶ設計ではありません。

概念的には、

ハイパーバイザ
 |
 | 単一ネットワーク
 | タグなし
 v
スイッチのアクセスポート
 |
 v
VLAN 10

です。

仮想化ホスト内部では仮想マシン（VM）や仮想ポートの構成が存在しますが、物理アップリンク側が単一アクセスVLANなら、そのリンクのスイッチ側VLAN処理はアクセスポートとして判断します。

複数アップリンクを別々のアクセスVLANへ接続できる

次のホストを考えます。

NIC1
→ 管理
→ VLAN 10

NIC2
→ ストレージ
→ VLAN 20

NIC3
→ バックアップ
→ VLAN 30

各NICが独立し、各リンクが1 VLANだけを運ぶなら、

interface GigabitEthernet1/0/10
 switchport mode access
 switchport access vlan 10

interface GigabitEthernet1/0/11
 switchport mode access
 switchport access vlan 20

interface GigabitEthernet1/0/12
 switchport mode access
 switchport access vlan 30

のような設計が成立します。

重要なのは、

ホスト全体
→ 3 VLAN

ではなく、

各アップリンク
→ 1 VLAN

という点です。

複数VLANのハイパーバイザ・トランク接続

1本の物理アップリンクで複数VLANを運ぶ場合は、802.1Qトランクが必要になります。

要件：

ハイパーバイザNIC1

VLAN 10
VLAN 20
VLAN 30

を同じアップリンクで運ぶ

スイッチ側の代表例：

interface GigabitEthernet1/0/10
 switchport
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30

この場合、

VLAN 10
VLAN 20
VLAN 30

を同一物理リンク上で識別して運ぶため、802.1Qタグ付けを使用します。

スイッチ側だけトランクにしても十分ではない

スイッチ側を、

switchport mode trunk

にしただけでは、ハイパーバイザ側まで正しく複数VLANを扱えるとは限りません。

ハイパーバイザまたは仮想スイッチ側でも、

VLAN 10
VLAN 20
VLAN 30

をどの仮想ネットワークへマッピングし、どのトラフィックをタグ付けして物理アップリンクへ送るかという設計が必要です。

つまり、

スイッチ側
→ トランク

ホスト側
→ VLANタグ付け・マッピング

の両方を整合させます。

ハイパーバイザのVLANタグ付け

複数VLANを1つの物理アップリンクで運ぶ場合、ハイパーバイザ側でも802.1Q VLANを識別できる構成が必要です。

概念的には、

VM-A
→ VLAN 10

VM-B
→ VLAN 20

VM-C
→ VLAN 30

が、

仮想スイッチ
↓
802.1Q
↓
物理NIC
↓
スイッチのトランク

を通ります。

スイッチ側許可VLANが、

10,20,30

でも、ハイパーバイザ側でVLANマッピングが誤っていれば、期待するネットワークへトラフィックを送れません。

ハイパーバイザ側とスイッチ側のVLAN番号を一致させる

次の構成を考えます。

ハイパーバイザ側：

サーバA
→ VLAN 10

サーバB
→ VLAN 20

サーバC
→ VLAN 30

スイッチ側：

switchport trunk allowed vlan 10,20,40

この場合、

VLAN 10
→ 一致

VLAN 20
→ 一致

VLAN 30
→ スイッチ側で許可されていない

という不一致があります。

したがって、

ハイパーバイザVLANマッピング
↔
スイッチの許可VLAN

を対応させて確認します。

トランクモードと許可VLANは別に確認する

次の出力があったとします。

Operational Mode: trunk

これだけでは、

必要なVLAN 10、20、30を
すべて通せる

とは断定できません。

たとえば許可VLANが、

10,20

ならVLAN 30は許可されていません。

したがって、

Portがトランクか

と、

必要VLANが許可されているか

を別々に確認します。

複数NICがあるだけではPort-Channelにしない

仮想化ホストでは複数NICを持つことが一般的ですが、

NICが複数ある
↓
LACP Port-Channelを構成する

とは限りません。

まず確認するのは、

複数NICを
1つの論理リンクとして
バンドルする要件があるか

です。

複数NICが、

NIC1
→ 管理

NIC2
→ ストレージ

のように独立した役割を持つなら、同じPort-Channelへバンドルする設計ではない可能性があります。

仮想化ホストのバンドル要件

Port-Channelを選択する前に、

複数物理NICを
1つの論理アップリンクとして利用する

という要件があるかを確認します。

たとえば、

NIC1
NIC2

を1つの論理アップリンクとして利用し、
冗長性と帯域利用を行う

という設計なら、リンクアグリゲーションを検討します。

一方で、

NIC1
→ ネットワークA

NIC2
→ ネットワークB

という独立リンクなら、バンドルする必要はありません。

LACPを使用するにはホスト側対応可否も必要

スイッチ側だけで、

channel-group 10 mode active

を設定しても、ピア側がLACPに対応していない、またはLACPを使用する設定になっていなければ、期待するLACPバンドルは形成されません。

確認するのは、

ホストのNICチーム・仮想スイッチが
LACPをサポートしているか

その設計でLACPを使用する設定か

です。

したがって、

複数NIC
と
スイッチ側LACP

だけで成立条件を満たしたとは判断しません。

静的チーミングとLACPを混同しない

ホスト側には製品や実装によって複数のNICチーミング方式があります。

このページで確認するのは、

LACPを使用する要件

がある場合のスイッチ側判断です。

ホスト側が別のチーミング方式を使用する設計なのに、

スイッチ側をLACP activeにすればよい

とは判断しません。

LACPを使用するなら、両端がLACPを使う設計として整合している必要があります。

LACPのactiveとpassive

Ciscoスイッチでは、LACPを使用するPort-Channelメンバを代表的に、

channel-group 10 mode active

または、

channel-group 10 mode passive

として構成できます。

activeはLACPネゴシエーションを能動的に開始します。

passiveはLACPパケットを受信したときに応答します。

そのため、

active ↔ active

または、

active ↔ passive

ではLACP形成が可能です。

一方、

passive ↔ passive

では、両端ともネゴシエーションを開始しないため通常LACPは形成されません。

スイッチ側LACP設定

2本の物理インターフェースをLACPバンドルへ参加させる例を考えます。

interface range GigabitEthernet1/0/10-11
 channel-group 10 mode active

これにより、

Port-channel10

という論理インターフェースが形成される構成になります。

重要なのは、

物理メンバ

と、

論理Port-Channel

を分けて考えることです。

EtherChannelメンバは同じ論理ピアへ接続する

通常のEtherChannel・LACPバンドルでは、メンバリンクは同じ論理ピアとの間で1つの論理リンクを形成します。

正しいイメージ：

ハイパーバイザ
 NIC1 ─────┐
           ├── スイッチ論理ピア
 NIC2 ─────┘

一方、

NIC1
→ 独立したSW1

NIC2
→ 独立したSW2

というトポロジを見て、単に両スイッチで同じchannel-group番号を設定しても、通常の1つのLACP Port-Channelにはなりません。

物理スイッチが2台でも論理ピアとして動作する技術は別途存在する

ネットワークには、複数物理スイッチを1つの論理ピアのように扱える技術もあります。

しかし、

2台のスイッチへ1本ずつ接続した

という事実だけでは、

同じLACPバンドルを形成できる

とは判断できません。

確認するのは、

ホストから見て
LACPピアが同一論理システムとして成立しているか

です。

複数スイッチを論理ピアとして扱うベンダー固有技術の詳細は、ここでは扱いません。

channel-group番号が同じでも論理ピア条件にはならない

次の構成を考えます。

SW1：

interface GigabitEthernet1/0/10
 channel-group 10 mode active

SW2：

interface GigabitEthernet1/0/10
 channel-group 10 mode active

両方で、

channel-group 10

を使用しているからといって、SW1とSW2が自動的に同じ論理ピアになるわけではありません。

channel-group番号は各スイッチ上のローカル設定です。

トポロジと論理ピア関係を別途確認します。

トランクとLACPは別の属性

次の2つを混同しないことが重要です。

トランク

は、

複数VLANをリンク上で運ぶ

ためのレイヤ2ポート属性です。

一方、

LACP

は、

複数物理リンクを
1つの論理リンクとして束ねる

ためのリンクアグリゲーションプロトコルです。

したがって、

複数VLANだからLACP

でも、

複数NICだからトランク

でもありません。

アクセス・トランクとバンドルの判断を分ける

仮想化ホスト接続では、2つの判断軸があります。

VLAN数
↓
アクセス・トランク

と、

物理リンク数とバンドル要件
↓
単独リンク・Port-Channel

です。

たとえば、

2本のNIC
と
各NICが1 VLAN
と
バンドルしない

なら個別アクセスポートが成立します。

一方、

2本のNIC
と
1つのLACPバンドル
と
VLAN 10、20、30を運ぶ

なら、

トランクPort-Channel

という構成になります。

仮想化ホストのLACP設定

要件：

NIC1とNIC2
→ LACPバンドル

論理アップリンク
→ VLAN 10,20,30

スイッチ側では、代表的に物理メンバへLACPを設定します。

interface range GigabitEthernet1/0/10-11
 channel-group 10 mode active

そして論理Port-Channelへ必要なレイヤ2属性を設定します。

interface Port-channel10
 switchport
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30

概念的には、

Gi1/0/10 ─┐
           ├─ Port-channel10 ─ ハイパーバイザ論理アップリンク
Gi1/0/11 ─┘

です。

トランクPort-Channelでは論理インターフェースを確認する

LACPが正常に形成されても、

Port-channel

が正しいVLANを運べるとは限りません。

要件：

VLAN 10
VLAN 20
VLAN 30

に対して、

Port-channel10
許可VLAN
→ 10,20

ならVLAN 30が不足しています。

したがって、

バンドル状態

と、

トランクVLAN状態

を別々に確認します。

メンバインターフェースの設定整合性

同じEtherChannelへ参加する物理メンバは、Port-Channelとして成立するために互換性のあるレイヤ2設定を持つ必要があります。

たとえばメンバごとに、

片方はアクセス

片方はトランク

のように意図が異なる状態は、1つの正常な論理Port-Channelとして扱う設計と整合しません。

運用上は論理Port-Channelインターフェースを中心にレイヤ2属性を確認し、メンバインターフェースも同じバンドルとして整合しているか確認します。

Port-Channelへトランク属性を設定する

複数VLANをLACPバンドルで運ぶ場合は、

interface Port-channel10
 switchport mode trunk

のように論理Port-Channelをトランクとして構成します。

さらに、

switchport trunk allowed vlan 10,20,30

など、要件に応じたVLAN属性を設定します。

重要なのは、

LACPが形成された

ことと、

必要VLANを運べるトランクである

ことは別条件だという点です。

ホスト側も論理バンドルとVLANタグ付けを整合させる

スイッチ側で、

Port-channel10
→ トランクVLAN 10,20,30

を構成していても、ホスト側が、

NIC1
NIC2
→ 独立NICとして使用

しているなら、スイッチ側が期待するLACP論理リンクとは一致しません。

同様にホスト側LACPバンドルが形成されていても、仮想スイッチ側がVLAN 30を扱わないなら、VLAN 30の接続性は成立しません。

したがって、

ホスト側バンドル
と
ホスト側VLANタグ付け
と
スイッチLACP
と
スイッチのトランク

を対応させます。

show etherchannel summary

EtherChannelのバンドル状態を確認する代表的なコマンドは、

show etherchannel summary

です。

代表的な出力では、

Group
Port-channel
Protocol
Ports

などを確認できます。

例：

Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
10     Po10(SU)        LACP      Gi1/0/10(P) Gi1/0/11(P)

プラットフォーム・ソフトウェアによって表示形式やフラグ表記には違いがありますが、

Port-channelが存在するか

ProtocolがLACPか

期待する物理メンバがバンドルへ参加しているか

を確認します。

メンバが存在するだけでバンドルされたとは判断しない

show etherchannel summaryにインターフェース名が表示されていても、そのメンバが期待どおりバンドルされた状態に入っているかを確認します。

たとえば、

Gi1/0/10
Gi1/0/11

が設定上channel-groupへ所属していても、互換性やネゴシエーションに問題があれば、期待した状態でバンドルされていない可能性があります。

したがって、

メンバインターフェース名がある

だけではなく、

動作時のバンドル状態

を確認します。

show lacp neighbor

LACPピアとのネゴシエーション確認には、

show lacp neighbor

を利用できます。

このコマンドでは、LACPピアに関する情報を確認できます。

仮想化ホストとの接続では、

期待するインターフェースで
LACPピアが見えているか

を確認する材料になります。

show interfaces trunk

トランクとして必要VLANを運べているかは、

show interfaces trunk

で確認できます。

代表的に、

Port        Mode             Encapsulation  Status        Native vlan
Po10        on               802.1q         trunking      1

Port        Vlans allowed on trunk
Po10        10,20,30

Port        Vlans allowed and active in management domain
Po10        10,20,30

Port        Vlans in spanning tree forwarding state and not pruned
Po10        10,20,30

などを確認できます。

Port-Channelがトランクなら、

Po10

などの論理インターフェースがトランクとして表示され、必要な許可VLANを運べるか確認します。

show interfaces port-channel ... switchport

Port-Channelのスイッチポート属性を確認するときは、プラットフォームで利用可能な形式に応じて、

show interfaces Port-channel10 switchport

などを使用できます。

確認したいのは、

Administrativeモード

動作時モード

アクセス・トランク属性

VLAN情報

です。

バンドル状態とトランク状態の両方を見る

仮想化ホストのトランクPort-Channelを確認するときは、

show etherchannel summary

だけでは不十分な場合があります。

これは主に、

物理リンクが論理バンドルへ
正常に参加しているか

を確認するためです。

一方、

show interfaces trunk

では、

論理リンクがトランクとして動作し
必要なVLANを運べるか

を確認します。

したがって、

EtherChannel・LACP状態

と

トランク・VLAN状態

の両方を照合します。

シナリオ 1：ホスト全体では2 VLANだが各NICは1 VLAN

要件：

NIC1
→ VLAN 10

NIC2
→ VLAN 20

NIC1とNIC2は独立アップリンク

このホストは全体としてVLAN 10と20を使用しています。

しかし、

NIC1
→ 1 VLAN

NIC2
→ 1 VLAN

なので、それぞれアクセスポートとして構成できます。

interface GigabitEthernet1/0/10
 switchport mode access
 switchport access vlan 10

interface GigabitEthernet1/0/11
 switchport mode access
 switchport access vlan 20

です。

シナリオ 2：1本のアップリンクで3 VLAN

要件：

NIC1
→ VLAN 10
→ VLAN 20
→ VLAN 30

同じ物理アップリンクで3 VLANを運ぶため、

802.1Qトランク

が必要です。

スイッチ側：

interface GigabitEthernet1/0/10
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30

ホスト側も、対応するVLANタグ付け・マッピングを構成します。

シナリオ 3：スイッチだけトランクでホストはタグなし

スイッチ：

switchport mode trunk
switchport trunk allowed vlan 10,20,30

ハイパーバイザ：

すべてのトラフィックを
同一タグなしネットワークとして扱う

という状態なら、スイッチとホストの複数VLAN設計が整合していません。

複数VLANを同一アップリンクで使用するには、

スイッチ側トランク
と
ホスト側VLANタグ付け

を対応させます。

シナリオ 4：NICが4本ある

ホストに、

NIC1
NIC2
NIC3
NIC4

が存在しています。

しかし、この情報だけでは、

4 Port LACPバンドル

を選択できません。

まず、

NICを1つの論理リンクとして束ねる要件があるか

を確認します。

さらにLACPを使用するなら、

ホスト側がLACPをサポートし
LACPを利用する設定になっているか

を確認します。

シナリオ 5：通常LACPで異なる独立スイッチへ接続

要件：

NIC1
→ SW1

NIC2
→ SW2

NIC1とNIC2
→ 1つの通常LACPバンドル

SW1とSW2が独立した論理ピアなら、このまま通常の1つのLACP Port-Channelを形成する条件を満たしません。

判断：

トポロジを確認
↓
同一論理ピア条件を満たすか確認
↓
満たさなければ設計を見直す

です。

シナリオ 6：LACP active・passive

スイッチ側：

channel-group 10 mode passive

ホスト側も：

LACP passive

なら、双方がネゴシエーション開始を待つため、通常LACPは形成されません。

少なくとも一方が、

active

としてネゴシエーションを開始する必要があります。

シナリオ 7：LACPは正常だがVLAN 30だけ通信できない

確認：

show etherchannel summary

結果：

Po10
→ LACP
→ メンバ正常

しかしVLAN 30だけ通信できません。

次に、

show interfaces trunk

を確認すると、

Port        Vlans allowed on trunk
Po10        10,20

だったとします。

この場合、

LACPバンドル
→ 正常

VLAN 30
→ 許可されていない

という切り分けができます。

シナリオ 8：トランクは正しいがLACPバンドルにならない

Port-Channel設定：

switchport mode trunk
switchport trunk allowed vlan 10,20,30

は要件と一致しています。

しかし、

show etherchannel summary

でメンバが期待するバンドルされた状態になっていません。

この場合、

許可VLANを変更する

前に、

LACPモード

ホスト側LACP設定

メンバ整合性

論理ピアのトポロジ

などバンドル成立条件を確認します。

シナリオ 9：メンバの接続先が想定と異なる

ホスト側では、

NIC1
NIC2
→ 同一LACPバンドル

として構成されています。

しかしケーブル接続を確認すると、

NIC1
→ スイッチA

NIC2
→ 独立したスイッチB

となっていました。

この場合、スイッチ側のchannel-group番号や許可VLANだけを見るのではなく、

両リンクが同じ論理ピアへ
終端しているか

を確認します。

シナリオ 10：トランクPort-Channel

要件：

NIC1とNIC2
→ LACP

VLAN
→ 10,20,30

スイッチ側の代表的な構成：

interface range GigabitEthernet1/0/10-11
 channel-group 10 mode active

interface Port-channel10
 switchport
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30

確認：

show etherchannel summary
show lacp neighbor
show interfaces trunk

です。

これにより、

LACPピア

バンドル状態

トランク状態

許可VLAN

を分けて確認できます。

よくある誤り

仮想化ホストが複数VLANを使うから全NICをトランクにする

アクセス・トランクは各アップリンクまたはPort-Channel単位で判断します。

各アップリンクが1 VLANだけなら、個別アクセスポートが成立し得ます。

NICが複数あるからLACPを設定する

NIC本数だけではバンドル要件を意味しません。

複数NICを1つの論理リンクとして使用する要件を確認します。

スイッチ側でLACPを設定すれば成立すると考える

ホスト側NICチーム・仮想スイッチがLACPをサポートし、その方式を使用する必要があります。

activeとpassiveを両端ともpassiveにする

passive同士では双方がネゴシエーション開始を待つため、通常LACPは形成されません。

異なる独立スイッチでも同じchannel-group番号ならバンドルできると考える

channel-group番号はローカル設定です。

通常のLACPバンドルでは同じ論理ピアへ終端する必要があります。

LACPがアップならVLANも正しいと考える

バンドル状態とトランクVLAN状態は別です。

show etherchannel summaryとshow interfaces trunkなどを使い分けます。

トランクがアップならLACPも正常と考える

トランク属性が正しくても、物理メンバが期待するPort-Channelへバンドルされているとは限りません。

EtherChannel・LACP状態も確認します。

スイッチ側だけVLANタグ付けを考える

ハイパーバイザ側でもVLANマッピング・タグ付けがスイッチ側トランクと整合している必要があります。

問題での判断パターン

パターン 1：アップリンク単位

条件：

ホスト全体
→ VLAN 10と20

NIC1
→ VLAN 10のみ

NIC2
→ VLAN 20のみ

判断：

ホスト全体ではなく
各アップリンク単位で判断

です。

パターン 2：単一VLANのアクセス接続

条件：

1 アップリンク
→ 1 VLAN

判断：

アクセスポートが成立し得る

です。

パターン 3：複数VLANのトランク接続

条件：

1 アップリンク
→ VLAN 10、20、30

判断：

802.1Qトランク

です。

パターン 4：ハイパーバイザのVLANタグ付け

条件：

スイッチ
→ トランクVLAN 10、20、30

判断：

ハイパーバイザ側も
対応するVLANタグ付け・マッピングが必要

です。

パターン 5：バンドル要件

条件：

NICが4本存在

だけではLACPを決定しません。

確認：

複数NICを
1 論理リンクとして
利用する要件があるか

です。

パターン 6：ホスト側のLACP対応可否

LACPを使用するなら、

ホストのNICチーム・仮想スイッチ
→ LACP対応

かつ

LACPを使用する設定

であることを確認します。

パターン 7：同一論理ピア

通常LACPでは、

物理メンバリンク
↓
同じ論理ピア

へ終端する必要があります。

パターン 8：スイッチ側LACP

代表例：

interface range GigabitEthernet1/0/10-11
 channel-group 10 mode active

です。

active・passiveの組み合わせも確認します。

パターン 9：トランクPort-Channel

条件：

LACPバンドル
と
VLAN 10、20、30

なら、

Port-channel
→ トランク
→ 許可VLAN 10,20,30

を要件と整合させます。

パターン 10：確認

代表的には、

show interfaces trunk

でトランク状態を、

show etherchannel summary

でバンドル状態を、

show lacp neighbor

でLACPピア情報を確認します。

パターン 11：複数VLANでも個別アクセス

条件：

NIC1
→ VLAN 10だけ

NIC2
→ VLAN 20だけ

なら、ホスト全体が複数VLANでも各アップリンクを個別アクセスポートとして構成できます。

パターン 12：スイッチ・ホスト双方のタグ付け

条件：

1 アップリンク
→ VLAN 10、20、30

なら、

スイッチ
→ 802.1Qトランク

ハイパーバイザ
→ VLANタグ付け・マッピング

を両方整合させます。

パターン 13：LACP採用前の確認

NIC本数ではなく、

論理バンドル要件
と
ホスト側のLACP対応可否

を確認してからLACPを選択します。

パターン 14：異なるスイッチへのLACP

NIC1とNIC2が別々の独立した論理スイッチへ終端している場合、

同じchannel-group番号

同じ許可VLAN

両方`active`

だけでは、通常LACPの同一論理ピア条件を満たしません。

パターン 15：トランクとバンドルの両方を確認

トランクPort-Channelでは、

Port-channelが必要VLANを運べるか

と、

物理メンバが
LACPバンドルへ正常参加しているか

の両方を確認します。

仮想化ホスト・エッジの確認手順

仮想化ホスト接続では、次の順序で整理すると判断しやすくなります。

対象アップリンク・Port-Channelを特定
↓
その論理リンクで運ぶVLAN数を確認
↓
単一VLANならアクセスを検討
↓
複数VLANならトランク
↓
ハイパーバイザ側タグ付けを整合
↓
複数NICをバンドルする要件を確認
↓
ホスト側LACP対応可否を確認
↓
論理ピアのトポロジを確認
↓
スイッチ側LACPを設定
↓
Port-Channelのレイヤ2属性を設定
↓
バンドル状態を確認
↓
トランク・VLAN状態を確認

まとめ

仮想化ホスト接続では、

仮想化ホストだからトランク

または、

NICが複数あるからLACP

とは判断しません。

まず、

各アップリンクまたはPort-Channelが
何VLANを運ぶか

を確認します。

1つのアップリンクで1 VLANだけなら、

アクセスポート

が成立し得ます。

1つのアップリンクで複数VLANを運ぶなら、

802.1Qトランク

を使用し、ハイパーバイザ側のVLANタグ付け・マッピングもスイッチ側と整合させます。

複数NICについては、

バンドル要件

があるかを確認し、LACPを使用するなら、

ホスト側LACP対応可否

スイッチ側LACP設定

同一論理ピア

メンバ整合性

を確認します。

複数VLANをLACPバンドルで運ぶ場合は、

物理NIC
↓
LACP
↓
Port-Channel
↓
802.1Qトランク
↓
許可VLAN

という関係になります。

最後に、

show etherchannel summary

でバンドル状態を、

show lacp neighbor

でLACPピアを、

show interfaces trunk

でトランク・VLAN状態を確認します。

重要なのは、

VLAN数
→ アクセス・トランク

バンドル要件
→ Port-Channel・LACP

動作出力
→ 実際の成立状態

をそれぞれ分離して判断することです。