Network Appliance Connectivity

このページのゴール

ネットワークアプライアンスの各インターフェースが運ぶVLAN数、802.1Qタグ付け要件、リンク集約要件、LACP対応可否を読み取り、スイッチ側でアクセスポート、トランク、Port-Channel、LACPを適切に選択・構成・確認できるようにします。

このページで扱うのは、ファイアウォール、ロードバランサなどをスイッチへ接続するときのスイッチ側Layer 2接続設計です。

ファイアウォールポリシー、NAT、ロードバランシング方式、アプライアンス固有のHAプロトコル、ベンダー固有のNIC Teamingは扱いません。

このページで学ぶこと

• ネットワークアプライアンス名ではなくインターフェース要件からポート属性を決める
• 1本のリンクが単一VLANだけをタグなしで運ぶ場合のアクセスポート
• 1本のリンクが複数VLANを運ぶ場合の802.1Qトランク
• アプライアンス側Subinterfaceとスイッチ側VLAN設定の整合
• 許可VLANとネイティブVLANの役割
• 複数物理リンクとPort-Channel要件の関係
• アプライアンス側LACP対応可否
• LACPのactiveとpassive
• EtherChannelメンバーの同一論理ピア条件
• 複数VLANをPort-Channelで運ぶ場合のトランク設定
• showコマンドによるスイッチ側確認
• 要件と実状態を切り分ける試験問題の判断手順

ネットワークアプライアンスでも判断基準はインターフェース要件

「接続先がファイアウォールだからトランク」「ロードバランサだからPort-Channel」のように、装置の種類だけでスイッチポート属性を決めてはいけません。

確認するのは、その接続インターフェースが何を運ぶかです。

基本的な判断順は次のとおりです。

対象インターフェースを特定
↓
そのリンクが運ぶVLAN数を確認
↓
1 VLANをタグなしで運ぶ
→ アクセスポートを検討
↓
複数VLANを同じリンクで運ぶ
→ 802.1Qトランクを検討
↓
複数物理リンクを1つの論理リンクとして使う要件があるか確認
↓
アプライアンス側がLACPを使用できるか確認
↓
Port-Channelを構成
↓
スイッチポート、トランク、EtherChannel、LACPの実状態を確認

最初から「トランク」「LACP」と決めるのではなく、要件を順番に分解します。

物理インターフェースと論理インターフェースを分けて考える

ネットワークアプライアンスでは、1本の物理インターフェースの上に複数のSubinterfaceを作成し、それぞれ異なるVLANを割り当てる構成があります。

概念的には次のようになります。

VLAN 100
  ↓
Subinterface 100 ─┐
                  ├─ 物理インターフェース ─ スイッチ
Subinterface 200 ─┘
  ↑
VLAN 200

この場合、物理リンクでは複数VLANを区別して運ぶ必要があるため、スイッチ側はトランクとして設計します。

一方、物理インターフェースが1 VLANだけをタグなしで扱うなら、アクセスポートとして設計できます。

重要なのは、アプライアンス全体で何VLAN使うかではなく、対象の物理リンクまたは論理Port-Channelが何VLANを運ぶかです。

アプライアンス全体のVLAN数だけで判断しない

ファイアウォール全体では複数VLANを使用していても、それぞれを別の物理インターフェースへ分ける設計があります。

たとえば次の構成です。

Firewall

Ethernet1
→ VLAN 100
→ タグなし

Ethernet2
→ VLAN 200
→ タグなし

スイッチ側では次のような設計が成立します。

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

Gi1/0/11
→ Ethernet2
→ アクセスVLAN 200

アプライアンス全体ではVLAN 100とVLAN 200を使用していますが、各リンクが1 VLANだけを運ぶなら、各スイッチポートを別々のアクセスポートにできます。

単一VLANをタグなしで運ぶ場合はアクセスポートを検討する

アプライアンスの1本の物理インターフェースが、1つのVLANだけをタグなしで扱う要件なら、スイッチ側アクセスポートが成立し得ます。

要件を次のようにします。

Firewall Ethernet1
→ VLAN 100
→ タグなし

代表的なスイッチ設定は次のとおりです。

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

このとき、アプライアンスからタグなしで到着したフレームは、スイッチ側でアクセスVLAN 100として扱われます。

アクセスポートでは1本のリンクで複数VLANを識別しない

アクセスポートは、そのリンク上で1つのアクセスVLANへ所属させる設計です。

概念的には次のとおりです。

Firewall
  |
  | タグなし
  v
Access Port
  |
  v
VLAN 100

アプライアンス側が同じ物理リンクへVLAN 100とVLAN 200の802.1Qタグを付けて送る要件なのに、スイッチ側をアクセスポートへ固定すると、設計が一致しません。

したがって、1本のリンクで複数VLANを識別する必要があるかを最初に確認します。

複数の物理インターフェースを別々のアクセスVLANへ接続できる

次のような構成を考えます。

Firewall

Ethernet1
→ Inside
→ VLAN 100
→ タグなし

Ethernet2
→ DMZ
→ VLAN 200
→ タグなし

Ethernet3
→ Management
→ VLAN 300
→ タグなし

各インターフェースが独立して1 VLANだけを運ぶなら、スイッチ側を次のようにできます。

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

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

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

物理ポートが複数あること自体は、Port-Channelを意味しません。

それぞれのリンクを独立したLayer 2接続として使用する要件なら、個別ポートとして扱います。

1本の物理インターフェースで複数VLANを扱う場合はトランク

アプライアンスの1本の物理インターフェースに複数のSubinterfaceがあり、それぞれ異なるVLANを扱う場合は、同じ物理リンクで複数VLANを運ぶ必要があります。

たとえば次の要件です。

Firewall Ethernet1

Subinterface 100
→ VLAN 100

Subinterface 200
→ VLAN 200

この場合、スイッチ側では802.1Qトランクを使用します。

interface GigabitEthernet1/0/10
 switchport
 switchport mode trunk
 switchport trunk allowed vlan 100,200

この設計では、VLAN 100とVLAN 200を802.1Qタグで区別して同じリンク上へ流します。

トランク設定はアプライアンス側のVLANタグ付けと対になる

スイッチ側をトランクにしただけでは、接続が正しいとは限りません。

アプライアンス側で、

Subinterface 100
→ VLAN tag 100

Subinterface 200
→ VLAN tag 200

と設定しているなら、スイッチ側でも同じVLANをトランクで扱う必要があります。

switchport mode trunk
switchport trunk allowed vlan 100,200

スイッチ側がVLAN 100と200を許可していても、アプライアンス側がVLAN 100と300をタグ付けしていれば、要件は一致していません。

VLAN番号の不一致を見落とさない

次の組み合わせを考えます。

Appliance側
VLAN 100
VLAN 200

Switch側
Allowed VLAN
100,300

この場合、VLAN 100は一致していますが、VLAN 200はスイッチ側で許可されず、VLAN 300はアプライアンス側の想定と一致しません。

必要なのは「トランクになっているか」だけではありません。

Trunk Mode
+
Allowed VLAN
+
Appliance VLAN Tag

これらを同じVLAN単位で照合します。

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

switchport mode trunkが設定されていても、必要なVLANが許可VLANに含まれていなければ、そのVLANを期待どおりに転送できません。

たとえば次の状態です。

Appliance
VLAN 100
VLAN 200

Switch
switchport mode trunk
switchport trunk allowed vlan 100

この場合、トランクというポート種別自体は正しくても、VLAN 200の許可が不足しています。

確認では、

show interfaces trunk

を使用し、必要なVLANがトランク上で許可されているか確認します。

ネイティブVLANとタグなし通信の扱いを一致させる

トランクでは、ネイティブVLANの扱いもアプライアンス側のタグ付け要件と一致させる必要があります。

たとえば、アプライアンスがVLAN 100をタグなしで送信する設計なのに、スイッチ側ネイティブVLANがVLAN 200なら、タグなしフレームの所属VLANが一致しません。

スイッチ側でネイティブVLANを指定する代表例は次のとおりです。

interface GigabitEthernet1/0/10
 switchport mode trunk
 switchport trunk native vlan 100
 switchport trunk allowed vlan 100,200

ここで重要なのは、ネイティブVLANを「必ず設定する項目」と暗記することではありません。

アプライアンス側がどの通信をタグ付き、どの通信をタグなしとして扱う設計なのかを読み、その要件とスイッチ側を一致させます。

スイッチ側だけトランクでも通信要件は成立しない

次の状態を考えます。

Switch
→ Trunk
→ VLAN 100,200 Allowed

Appliance
→ VLAN tagを付けない
→ 1つの通常インターフェースとして使用

スイッチ側がトランクでも、アプライアンス側が複数VLANを識別する設計になっていなければ、期待したVLAN分離は成立しません。

トランク接続では、

Switch側
802.1Q Trunk
Allowed VLAN
Native VLAN

Appliance側
Subinterface
VLAN Tag
Untagged要件

を対応させて判断します。

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

アプライアンスに2本や4本のEthernetポートが搭載されていても、それだけでPort-Channelを構成する理由にはなりません。

たとえば4本のポートが、

Port1
→ Inside

Port2
→ Outside

Port3
→ DMZ

Port4
→ Management

のように別用途なら、1つの論理リンクとして束ねる要件ではありません。

Port-Channelを検討するのは、複数の物理リンクを1つの論理リンクとして利用する要件がある場合です。

リンク集約要件を先に確認する

リンク集約を使用する場合は、アプライアンス側の設計に複数物理リンクを1つの論理インターフェースとして扱う要件があることを確認します。

概念的には次の構成です。

Appliance

Ethernet1 ─┐
           ├─ Logical Bundle
Ethernet2 ─┘

スイッチ側では対応する物理ポートをEtherChannelへ参加させます。

Gi1/0/10 ─┐
           ├─ Port-channel10
Gi1/0/11 ─┘

物理ポート数ではなく、論理バンドル要件があるかを判断します。

LACPを使うならアプライアンス側の対応可否を確認する

スイッチ側でLACPを設定しても、アプライアンス側がLACPを使用しない構成なら、期待するLACPバンドルは成立しません。

確認する項目は次のとおりです。

Appliance側
→ LACPをサポートしているか
→ LACPを使用する設定か
→ どの物理リンクを同じBundleへ入れるか

Switch側
→ 対応ポートを同じPort-Channelへ入れるか
→ LACP modeが成立する組み合わせか

「アプライアンスに複数ポートがある」と「LACPを使用する」は別の条件です。

静的リンク集約とLACPを混同しない

アプライアンス側が静的なリンク集約を使用している場合、スイッチ側だけをLACPactiveにしても、自動的にLACPネゴシエーションが成立するわけではありません。

LACPを使う設計なら、両端がLACPとして動作できる必要があります。

一方、静的EtherChannelを使用する設計はLACPとは別です。

試験では、

Appliance
→ Static Bundle

に対して、

Switch
→ LACP active

という組み合わせを見たら、「複数リンクだから問題ない」ではなく、集約方式が一致しているかを確認します。

LACPのactiveとpassive

LACPでは代表的にactiveとpassiveがあります。

active
→ LACPネゴシエーションを能動的に開始

passive
→ 相手からのLACPを待つ

成立し得る代表的な組み合わせは次のとおりです。

active － active
→ 成立可能

active － passive
→ 成立可能

passive － passive
→ 開始側がいないため成立しない

アプライアンス側がpassiveなら、スイッチ側をactiveにすることでLACP形成を開始できます。

スイッチ側のLACP設定

たとえばアプライアンスの2本のリンクをPort-Channel 10へ束ねる場合、スイッチ側の代表例は次のとおりです。

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

これにより、対象物理ポートをLACPでPort-Channel 10へ参加させます。

論理インターフェースは次のように表されます。

interface Port-channel10

ただし、設定コマンドを投入しただけで正常にバンドルされたとは判断しません。

実状態はshow etherchannel summaryなどで確認します。

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

通常のEtherChannelでは、同じPort-Channelへ参加させるメンバーリンクは、対向側でも同じ論理装置へ接続される必要があります。

正しい考え方は次のとおりです。

Appliance Bundle
  |       |
  |       |
Switch Logical Peer

一方、2本のリンクをそれぞれ完全に独立したスイッチへ接続しているのに、通常の1つのLACPを使用するPort-Channelとして扱えるとは限りません。

確認するのは物理筐体の台数だけではなく、対向側が1つの論理ピアとして動作するかです。

Stackは複数筐体でも1つの論理ピアになり得る

スイッチが2台に見えても、Stackとして1つの論理スイッチとして動作している場合があります。

概念的には次のとおりです。

Appliance
 |      |
 |      |
SW1    SW2
 \      /
  \    /
   Stack
1 Logical Switch

このような構成では、物理的に異なる筐体へリンクが接続されていても、同一論理ピア条件を満たし得ます。

ただし、StackであることだけでLACP形成まで保証されるわけではありません。

LACPモード、メンバー整合性、実際のリンク集約状態は別途確認します。

独立した2台のスイッチへ通常LACPを張るとは限らない

次のような構成を考えます。

Appliance
 |      |
 |      |
SW1    SW2

SW1とSW2は独立した論理装置

この状態で、2本を1つの通常LACP EtherChannelとして扱えるとは判断しません。

同一論理ピアとして動作する技術が別途存在する場合はありますが、このページではその技術の詳細には踏み込みません。

試験では「2台へ接続」という見た目だけではなく、同一論理ピアかを確認します。

channel-group番号が同じでも対向条件は満たされない

スイッチ側で2つのポートに同じchannel-group番号を設定しただけでは、対向側トポロジの条件まで自動的に満たされません。

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

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

この設定があっても、実際の対向接続やアプライアンス側リンク集約設定が誤っていれば正常なLACP形成にはなりません。

設定の存在と、リンク集約成立を分けて確認します。

トランクとLACPは別の属性

1本の論理Port-Channelについても、

Link Aggregation

と、

VLAN Transport

は別の判断です。

つまり、

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

Trunk
→ その論理リンクで複数VLANを運ぶ

という役割の違いがあります。

LACPが正常だからVLAN設定も正しいとは限らず、トランクが正常だからLACPも正常とは限りません。

AccessまたはTrunkの判断とリンク集約の判断を分ける

要件を次の2軸で分けると判断しやすくなります。

軸1
この論理リンクは何VLANを運ぶか

1 VLAN
→ Accessを検討

複数VLAN
→ Trunkを検討

軸2
何本の物理リンクを1つとして使うか

1本
→ 単独リンク

複数本を1つとして使う
→ Port-Channelを検討

したがって、次のような組み合わせが成立します。

単独Access

単独Trunk

Access Port-Channel

Trunk Port-Channel

ネットワークアプライアンスでは特に、複数VLANを複数リンクの集約上で運ぶTrunk Port-Channelが重要です。

複数VLANをリンク集約上で運ぶならトランクPort-Channel

次の要件を考えます。

Appliance

Ethernet1 ─┐
           ├─ LACP Bundle
Ethernet2 ─┘

Bundle上で
VLAN 100
VLAN 200
を運ぶ

この場合、スイッチ側では、

Gi1/0/10 ─┐
           ├─ Port-channel10
Gi1/0/11 ─┘

Port-channel10
→ Trunk
→ VLAN 100,200

という構成にします。

物理メンバーを束ねるLACPと、複数VLANを運ぶトランクの両方が必要です。

トランクPort-Channelの代表設定

代表的な設定例は次のとおりです。

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

論理Port-Channel側へトランク属性を設定します。

interface Port-channel10
 switchport
 switchport mode trunk
 switchport trunk allowed vlan 100,200

ネイティブVLAN要件がある場合は、その要件に合わせて追加します。

interface Port-channel10
 switchport trunk native vlan 100

設定位置はプラットフォームや既存構成との整合も考慮しますが、試験上は論理Port-ChannelのVLAN属性とアプライアンス側リンク集約のタグ付け要件が一致しているかを見ることが重要です。

メンバーインターフェースの設定整合性を確認する

EtherChannelメンバーでは、Port-Channel形成に必要な設定が互いに整合している必要があります。

たとえば、同じリンク集約へ入れる2ポートでLayer 2属性が矛盾していれば、正常なリンク集約形成を妨げる可能性があります。

確認時は、

Gi1/0/10
Gi1/0/11

を単に「両方upだから正常」と考えず、

同じPort-Channelへ参加しているか
LACP状態は正常か
論理Port-Channelが存在するか

を確認します。

アプライアンス側リンク集約とVLANタグ付けも同じ論理単位で考える

アプライアンス側で複数物理リンクを1つのリンク集約として扱い、そのリンク集約上にVLAN 100と200のSubinterfaceを作る場合を考えます。

Appliance

Ethernet1 ─┐
           ├─ Bundle10
Ethernet2 ─┘

Bundle10.100
→ VLAN 100

Bundle10.200
→ VLAN 200

スイッチ側も対応する論理Port-ChannelでVLAN 100と200を運びます。

Port-channel10
→ Trunk
→ Allowed VLAN 100,200

物理メンバー単位でVLAN 100と200を別々のアクセスポートへ分け、それを同じPort-Channelとして扱う設計とは異なります。

show interfaces switchportでポート属性を確認する

物理スイッチポートがアクセスかトランクか、アクセスVLANやネイティブVLANなどを確認するときは、次のようなコマンドを使用できます。

show interfaces GigabitEthernet1/0/10 switchport

確認したい観点は次のとおりです。

Administrative Mode
Operational Mode
Access Mode VLAN
Trunking Native Mode VLAN

要件が単一VLANのアクセスポートなら、動作モードやAccess Mode VLANが期待値と一致するか確認します。

トランク要件なら、動作モードがトランクとして動作しているかを確認します。

show interfaces trunkで許可VLANを確認する

トランクで必要なVLANが許可されているかは、次のコマンドで確認できます。

show interfaces trunk

たとえばアプライアンス側がVLAN 100と200をタグ付けしているなら、スイッチ側でも対象トランクにVLAN 100と200が含まれる必要があります。

Appliance
100,200

Switch
100,200
→ 整合

Appliance
100,200

Switch
100
→ VLAN 200が不整合

トランクという状態だけでなく、許可VLANまで確認します。

show etherchannel summaryでリンク集約成立を確認する

LACPを設定した後は、次のコマンドでEtherChannelの概要を確認します。

show etherchannel summary

見るべきなのは、「Port-Channel設定が存在するか」だけではありません。

Port-Channelが利用可能な状態か
Member Portが実際にBundleへ参加しているか
Protocolが期待どおりか

を確認します。

複数の物理インターフェースがupでも、Port-Channelへ正常参加していなければ「LACPによるリンク集約が正常」とは判断しません。

show lacp neighborでLACP隣接情報を確認する

LACPを使用する構成では、次のコマンドも確認に利用できます。

show lacp neighbor

このコマンドにより、LACPの対向情報を確認できます。

アプライアンス側がLACP passive、スイッチ側がactiveという設計なら、LACP隣接情報が期待どおり見えるかを確認材料にできます。

LACP隣接情報が確認できない場合は、モード、物理接続、対向設定、メンバー設定などを切り分けます。

Port-Channelのスイッチport状態を確認する

トランクPort-Channelでは、物理メンバーだけでなく論理Port-Channel側のVLAN属性を確認します。

show interfaces Port-channel10 switchport

確認する観点は、

Port-channel10
→ Trunkとして動作しているか
→ Native VLANが要件どおりか
→ Access属性と誤認していないか

です。

さらに許可VLANはshow interfaces trunkでも確認します。

リンク集約状態とTrunk状態を別々に確認する

トランクPort-Channelでは、最低でも次の2つを分けて確認します。

Bundle確認
show etherchannel summary
show lacp neighbor

Trunk確認
show interfaces trunk
show interfaces Port-channel10 switchport

たとえば、

LACP
→ 正常

Allowed VLAN 200
→ 欠落

なら、リンク集約は正常でもVLAN 200の通信要件は満たせません。

逆に、

Trunk設定
→ 正常

LACP
→ Bundle未成立

なら、VLAN属性だけ正しくても論理リンクとして期待どおりではありません。

ネットワークアプライアンス接続の確認順序

実機確認では、要件から順番に照合します。

1. 対象インターフェースを特定

2. 1 VLANか複数VLANか確認

3. AccessまたはTrunkを確認

4. Appliance側VLAN Tagと
   Allowed VLAN
   Native VLAN
   を照合

5. Bundle要件を確認

6. LACP対応可否とModeを確認

7. 同一論理ピア条件を確認

8. show etherchannel summary

9. show lacp neighbor

10. show interfaces trunk

11. show interfaces ... switchport

12. 要件と実状態を照合

この順序にすると、VLANの問題とLACPの問題を混同しにくくなります。

シナリオ1：ファイアウォールの1インターフェースがVLAN 100だけをタグなしで扱う

要件は次のとおりです。

Firewall Ethernet1
→ VLAN 100
→ タグなし
→ Bundleなし

スイッチ側ではアクセスポートが成立し得ます。

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

ここで「ファイアウォールだからTrunk」と判断するのは誤りです。

判断材料は装置名ではなく、そのインターフェースが運ぶVLAN数とタグ付け要件です。

シナリオ2：1インターフェースにVLAN 100と200のSubinterfaceがある

要件は次のとおりです。

Firewall Ethernet1

Subinterface 100
→ VLAN 100

Subinterface 200
→ VLAN 200

同じ物理リンクで複数VLANを運ぶため、スイッチ側はトランクを使用します。

interface GigabitEthernet1/0/10
 switchport mode trunk
 switchport trunk allowed vlan 100,200

アプライアンス側VLAN Tagとスイッチ側許可VLANを対応させます。

シナリオ3：TrunkだがVLAN 200だけ通信できない

次の状態です。

Appliance
VLAN 100
VLAN 200

Switch
switchport mode trunk
switchport trunk allowed vlan 100

この場合、ポートがトランクであること自体は正しいですが、VLAN 200が許可VLANに含まれていません。

最初に確認する候補は次のとおりです。

show interfaces trunk

「トランクかどうか」と「必要VLANが許可されているか」を分けて確認します。

シナリオ4：ネイティブVLANが一致していない

アプライアンスがVLAN 100をタグなしで扱う設計とします。

Appliance
Untagged
→ VLAN 100

しかしスイッチ側は次の設定です。

switchport trunk native vlan 200

この場合、タグなし通信のVLAN解釈が一致しません。

確認すべきなのは、

Appliance側のUntagged要件
Switch側Native VLAN

の対応です。

シナリオ5：4 Portあるがリンク集約要件がない

アプライアンスに4本のEthernetポートがあるとします。

Ethernet1
Ethernet2
Ethernet3
Ethernet4

しかし、それぞれが別用途であり、1つの論理リンクとして束ねる要件がない場合、ポート数だけを理由にLACPを採用しません。

試験では、

複数Physical Port
≠
自動的にPort-Channel

と判断します。

シナリオ6：アプライアンス側が静的リンク集約、スイッチ側がLACP active

次の組み合わせです。

Appliance
→ Static Bundle

Switch
channel-group 10 mode active

スイッチ側activeはLACPを使用する設定です。

アプライアンス側がLACPではなく静的集約なら、両端の集約方式が一致していません。

「両方ともリンク集約だから同じ」と判断しないことが重要です。

シナリオ7：2本のリンクが同じスイッチStackへ接続される

要件は次のとおりです。

Appliance
 |       |
 |       |
Stack Member1
Stack Member2

Stack全体
→ 1 Logical Switch

この構成は同一論理ピア条件を満たし得ます。

ただし、ここで確認を止めません。

show etherchannel summary

を使用し、実際にメンバーがリンク集約へ参加しているか確認します。

シナリオ8：2本のリンクが独立したスイッチへ接続される

次の構成です。

Appliance
 |       |
 |       |
SW1     SW2

SW1とSW2
→ 独立した論理装置

通常の1つのLACPを使用するPort-Channelとして扱うには、同一論理ピア条件を満たしているか確認が必要です。

単に「冗長だから2台へ接続すればよい」とは判断しません。

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

確認結果が次のとおりだとします。

show etherchannel summary
→ Bundle正常

show lacp neighbor
→ Neighbor確認可能

しかし、

show interfaces trunk
→ VLAN 100のみAllowed

であり、アプライアンス側はVLAN 100と200を使用しています。

この場合、優先して疑うのはLACPではなく、VLAN 200のトランク許可です。

LACP正常
≠
VLAN設定正常

という切り分けが重要です。

シナリオ10：Trunkは正しいがLACPによるリンク集約にならない

次の状態を考えます。

Port-channel10
→ Trunk
→ VLAN 100,200

VLAN属性は要件どおりでも、

show etherchannel summary
→ MemberがBundleされていない

なら、LACP側の問題を確認します。

候補は次のとおりです。

Appliance側LACP対応可否
LACP Mode
Member設定
Physical Link
Same Logical Peer

トランク設定が正しいことを理由に、LACPまで正常とは判断しません。

シナリオ11：Port-Channel上でVLAN 10と20を運ぶ

要件は次のとおりです。

Appliance Bundle
→ VLAN 10
→ VLAN 20

スイッチ側は次のように考えます。

Physical Members
→ LACP
→ Port-channel10

Port-channel10
→ Trunk
→ Allowed VLAN 10,20

物理メンバーをVLAN 10と20の別々のアクセスポートとして分けるのではなく、論理Port-Channel上のトランクとしてVLANを運びます。

よくある誤り

装置名だけでTrunkと決める

Firewall
→ 必ずTrunk

ではありません。

対象リンクが1 VLANをタグなし
→ Accessが成立し得る

対象リンクが複数VLAN
→ Trunk

と判断します。

ポート数だけでLACPと決める

4 Portある
→ 必ずLACP

ではありません。

論理リンク集約要件とアプライアンス側LACP対応を確認します。

Trunkなら許可VLANも正しいと思う

switchport mode trunk

だけでは不十分です。

必要なVLANが許可されているか確認します。

LACPが正常ならVLANも正しいと思う

LACPはリンク集約、TrunkはVLAN運搬の設定です。

別々に確認します。

同じchannel-group番号なら対向も正しいと思う

ローカル設定だけでは、対向側が同一論理ピアであることや、アプライアンス側リンク集約が正しいことまで証明できません。

問題での判断パターン

試験問題では、まず要件から判断軸を抽出します。

1 VLAN
+
Untagged
→ Access候補

複数VLAN
+
同一Interface
→ Trunk

Appliance Subinterface
+
VLAN Tag
→ Switch Allowed VLANと照合

複数Physical Links
+
1 Logical Linkとして利用
→ Port-Channel候補

ApplianceがLACP対応
+
LACPを使用
→ LACP Port-Channel候補

Member Links
→ Same Logical Peerを確認

Bundle上で複数VLAN
→ Trunk Port-Channel

最後に、

show interfaces ... switchport
show interfaces trunk
show etherchannel summary
show lacp neighbor

を要件に対応させます。

どのshowコマンドで何を見るか

ポート属性を確認します。

show interfaces GigabitEthernet1/0/10 switchport

主な確認対象は次のとおりです。

Administrative Mode
Operational Mode
Access Mode VLAN
Trunking Native Mode VLAN

トランクと許可VLANを確認します。

show interfaces trunk

EtherChannelの形成状態を確認します。

show etherchannel summary

LACP隣接情報を確認します。

show lacp neighbor

論理Port-ChannelのLayer 2属性を確認します。

show interfaces Port-channel10 switchport

1つのコマンドですべてを判断するのではなく、要件に対応する確認結果を組み合わせます。

ネットワークアプライアンス接続の最終確認

ネットワークアプライアンス接続の最終確認では、次の4層に分けて見ると整理しやすくなります。

第1層
Link
→ 対象物理Interfaceは正しいか

第2層
VLAN
→ AccessかTrunkか
→ Access VLANは正しいか
→ Allowed VLANは正しいか
→ Native VLANは要件と一致するか

第3層
Bundle
→ Port-Channel要件はあるか
→ Memberは正しいか
→ Same Logical Peerか

第4層
LACP
→ ApplianceはLACP対応か
→ Modeは成立するか
→ Neighborは確認できるか

最後にアプライアンス側要件とスイッチ側の実状態を対応させます。

Appliance Requirement
↓
Switch Configuration
↓
Operational State

この3つが一致して、初めてネットワークアプライアンスのエッジ接続が要件どおりと判断できます。

まとめ

ネットワークアプライアンスの接続では、ファイアウォールやロードバランサという装置名ではなく、対象インターフェースが運ぶVLAN数、タグ付け、リンク集約要件、LACP対応可否からスイッチ側ポート属性を決めます。

1 VLANをタグなしで運ぶならアクセスポートが成立し得ます。

1本のリンクで複数VLANを運ぶなら802.1Qトランクを使用し、アプライアンス側SubinterfaceのVLAN Tagと、スイッチ側許可VLAN、必要に応じてネイティブVLANを整合させます。

複数物理リンクを1つの論理リンクとして使う場合はPort-Channelを検討し、LACPを使用するならアプライアンス側対応可否とモードを確認します。

EtherChannelメンバーは同一論理ピアへ接続される必要があり、複数筐体でもStackなどで1つの論理スイッチとして動作する場合は条件を満たし得ます。

TrunkとLACPは別の属性なので、

show interfaces ... switchport
show interfaces trunk
show etherchannel summary
show lacp neighbor

を使い分け、VLAN状態とリンク集約状態の両方を確認します。

試験では、

VLAN数
↓
Tagging
↓
Bundle要件
↓
LACP対応
↓
Same Logical Peer
↓
Switch側Operational Verification

の順で要件を分解すると、ネットワークアプライアンス接続の判断を整理できます。