EtherChannel Troubleshooting

このページで学ぶこと

• EtherChannel Troubleshooting Sequence
• EtherChannel Physical Member State
• EtherChannel L2/L3 Role Mismatch
• LACP Mode Verification
• LACP passive-passive 根本原因
• EtherChannel Member Parameter Mismatch
• EtherChannel Trunk Parameter Mismatch
• Local channel-group Binding
• Remote channel-group Number Independence
• EtherChannel 修正 修正後確認

1. EtherChannelトラブルシューティングの目的

EtherChannelトラブルシューティングでは、

Port-Channelができない
メンバーがバンドルされない
期待するトラフィックが通らない

という症状に対して、設定を無作為に変更するのではなく、原因候補を段階的に確認します。

中心となる確認対象は、

• 物理メンバー状態
• レイヤ2・レイヤ3の役割
• LACPモード
• メンバーパラメータ
• トランクパラメータ
• ローカルchannel-groupの関連付け
• 論理Port-Channelの状態

です。

2. トラブルシューティングの順序

基本的な確認順序は次のように整理できます。

1. 物理メンバー状態
        ↓
2. レイヤ2・レイヤ3の役割
        ↓
3. ローカルchannel-groupの関連付け
        ↓
4. LACPモード
        ↓
5. メンバーパラメータ
        ↓
6. レイヤ2ならトランクパラメータ
        ↓
7. Port-Channel・メンバー実状態
        ↓
8. 修正
        ↓
9. 修正後確認

3. 最初から原因を決めつけない

EtherChannelが形成されない場合に、

LACPが原因

と最初から断定しません。

物理インターフェースがdownしている場合もあれば、メンバー役割やパラメータが不一致の場合もあります。

4. 設定と動作状態を分ける

次の設定が存在するとします。

channel-group 1 mode active

これはLACP EtherChannelへ参加させる設定です。

しかし、

設定がある
=
メンバーが正常にバンドルされている

ではありません。

動作結果も確認します。

5. show etherchannel summaryを中心に使う

EtherChannelトラブルシューティングで重要なコマンドが、

show etherchannel summary

です。

論理Port-Channelと物理メンバーの状態をまとめて確認できます。

6. 正常なレイヤ2 EtherChannel例

代表的な出力例を考えます。

Group  Port-channel  Protocol  Ports
1      Po1(SU)       LACP      Gi1/0/1(P) Gi1/0/2(P)

一般的には、

S
→ レイヤ2

U
→ 使用中

P
→ Port-Channelへバンドル済み

と読みます。

7. 正常なレイヤ3 EtherChannel例

レイヤ3EtherChannelなら、代表的に、

10     Po10(RU)      LACP      Gi1/0/1(P) Gi1/0/2(P)

のような表示があります。

一般的には、

R
→ レイヤ3

U
→ 使用中

P
→ バンドル済み

です。

8. メンバーが(P)かを見る

2本のメンバーを期待している場合、

Gi1/0/1(P)
Gi1/0/2(P)

のように、両方がバンドルへ参加しているかを確認します。

9. メンバー間で状態が違う場合

次のような出力を考えます。

Gi1/0/1(P)
Gi1/0/2(...)

一方だけ期待するバンドル済み状態でないなら、Gi1/0/2側の条件を詳しく確認します。

10. サマリーは調査開始点

show etherchannel summaryは非常に有用ですが、

サマリーだけで
すべての原因が分かる

とは限りません。

出力から異常なメンバーを特定し、必要な情報を追加確認します。

11. 物理状態を最初に確認する理由

EtherChannelへ参加するには、物理インターフェース自体が利用可能である必要があります。

そのため最初に、

インターフェースが物理的にupか
shutdownされていないか
Link障害がないか

を確認します。

12. 物理リンクがdownなら上位設定だけ見ない

ケーブルやトランシーバ、対向ポートなどの問題で物理リンクがdownなら、

LACPモードだけ変更する

ことで解決するとは限りません。

物理状態を先に確認します。

13. 物理状態確認コマンド

環境によって、

show interfaces status

や、

show interfaces <interface>

などを利用して物理・動作状態を確認できます。

14. administratively downを区別する

インターフェースが、

administratively down

なら、物理故障ではなく管理上のshutdownが原因候補になります。

設定を確認します。

15. no shutdownが必要なシナリオ

設計上インターフェースを利用する必要があり、

shutdown

されていることが原因なら、

no shutdown

による修正を検討します。

修正後はインターフェース状態を再確認します。

16. 物理状態正常なら次へ進む

メンバーインターフェースが利用可能なら、

物理は正常
→ EtherChannelも正常

とは判断しません。

次にレイヤ2・レイヤ3の役割を確認します。

17. レイヤ2・レイヤ3の役割不一致

同じEtherChannelへ参加するメンバーで、

Gi1/0/1 → レイヤ2
Gi1/0/2 → レイヤ3

のような役割不一致がある場合、正常な同一バンドルとして扱えません。

18. レイヤ2メンバーの確認

レイヤ2EtherChannelではメンバーをスイッチポートとして扱います。

必要に応じて、

show interfaces <interface> switchport

やrunning-configから役割を確認します。

19. レイヤ3メンバーの確認

レイヤ3EtherChannelではメンバーをルーテッドポートとして扱います。

代表的な設定では、

no ip address
no switchport
channel-group 10 mode active

のような構造を確認します。

20. レイヤ2・レイヤ3をPort-Channel側でも確認する

show etherchannel summaryのPort-Channelフラグも判断材料になります。

代表的には、

Po1(SU)
→ レイヤ2

Po10(RU)
→ レイヤ3

です。

21. メンバー役割と論理役割を比較する

確認したい関係は、

物理メンバー役割
        ↕
論理Port-Channelの役割

です。

レイヤ2Port-Channelならメンバーもレイヤ2として整合させます。

22. シナリオ：レイヤ2メンバーの中にレイヤ3ポート

Gi1/0/1
switchport
channel-group 1 mode active

Gi1/0/2
no switchport
channel-group 1 mode active

なら、レイヤ2・レイヤ3の役割不一致を疑います。

23. 役割不一致の修正

意図した設計がレイヤ2EtherChannelなら、メンバーをレイヤ2役割へ整合させます。

レイヤ3設計ならレイヤ3役割へ揃えます。

どちらが正しいかは設計に基づいて判断します。

24. 次にローカルchannel-groupの関連付けを見る

メンバーの物理状態と役割が適切なら、

同一デバイス内で
意図したメンバーが
同じローカルチャネルグループへ入っているか

を確認します。

25. ローカルchannel-groupの関連付けとは何か

次の設定を考えます。

Gi1/0/1
 channel-group 1 mode active

Gi1/0/2
 channel-group 1 mode active

両方のメンバーはローカルチャネルグループ1へ関連付けられています。

26. ローカルグループが異なる場合

次の状態では、

Gi1/0/1
 channel-group 1 mode active

Gi1/0/2
 channel-group 2 mode active

同じローカル論理Port-Channelへ参加する設定ではありません。

27. ローカルの関連付けとPort-Channel番号

一般にローカルチャネルグループ番号は論理Port-Channel番号に対応します。

channel-group 1
→ Port-channel1

channel-group 2
→ Port-channel2

として読みます。

28. 意図したメンバーが同じグループか確認する

トポロジ上は2本を1バンドルにする設計なのに、

メンバー A → グループ 1
メンバー B → グループ 2

ならローカルの関連付けを確認します。

29. 対向グループ番号は別の話

ローカルグループ番号が重要だからといって、

SW1 group 1
SW2も必ずgroup 1

である必要があるとは限りません。

対向デバイスのチャネルグループ番号はローカル識別子として扱います。

30. 対向channel-group番号の独立性

たとえば、

SW1
Gi1/0/1-2
channel-group 1 mode active

対向SW2が、

SW2
Gi1/0/1-2
channel-group 20 mode active

でも、グループ番号が異なるという事実だけをLACP形成失敗の原因とはしません。

31. 対向側では別のPort-Channel番号になり得る

前の例では、

SW1
Port-channel1

と、

SW2
Port-channel20

というローカル論理インターフェース名になり得ます。

両端で同じ数字である必要性とは別問題です。

32. 対向グループ番号だけで不一致判定しない

次の判断は避けます。

SW1 = channel-group 1
SW2 = channel-group 20

数字が違う
→ LACP形成不可

グループ番号のローカルでの意味を考えます。

33. ローカル側メンバー同士ではグループを確認する

一方で同じデバイス上で、

Gi1/0/1 → グループ 1
Gi1/0/2 → グループ 20

なら、2本を同じPort-Channelへバンドルする設計と一致しているか確認が必要です。

34. ローカルと対向を混同しない

整理すると、

同一デバイス内
→ メンバーが意図した同じローカルグループか確認

対向デバイス間
→ グループ番号そのものの一致は必須条件と決めつけない

です。

35. 次にLACPモードを確認する

ローカルの関連付けが適切なら、両端のLACPモードを確認します。

代表的には、

active
passive

です。

36. LACPモード確認

両端の設定で、

channel-group <id> mode active

または、

channel-group <id> mode passive

を確認します。

37. active-active

SW1 = active
SW2 = active

はLACPモードとして形成可能です。

38. active-passive

SW1 = active
SW2 = passive

も形成可能です。

active側がネゴシエーションを開始できます。

39. passive-active

SW1 = passive
SW2 = active

も形成可能です。

対向active側が開始できます。

40. passive-passive

SW1 = passive
SW2 = passive

では双方がネゴシエーションを開始しません。

LACP形成に必要な開始側が存在しないため、根本原因になります。

41. passive-passiveの見分け方

両端設定を比較して、

ローカル  = passive
対向 = passive

なら、メンバーパラメータ以前にLACPモードの組み合わせへ問題があります。

42. passive-passive修正例

設計上LACPを使用するなら、少なくとも一方をactiveへ変更します。

例：

SW1
channel-group 1 mode active

SW2
channel-group 20 mode passive

43. active-activeへ変更してもよい

両端を、

activeとactive

とする構成も可能です。

どちらを採用するかは設計に従います。

44. モード修正だけで完了しない

passive-passiveを修正しても、

だから必ずバンドル完成

とは判断しません。

他のメンバーパラメータも正常である必要があります。

45. show lacp neighborを利用する

LACPピアを認識しているか確認する代表的なコマンドが、

show lacp neighbor

です。

46. ネイバーが見える意味

期待するLACPネイバー情報が確認できれば、

対向とLACP情報を交換できている

ことを判断する材料になります。

47. ネイバーが見えない場合

期待するネイバーが表示されない場合は、

• 物理状態
• LACPモード
• 対向設定
• ローカルの関連付け

などを確認します。

原因を1つだけに決めつけません。

48. LACPモードとメンバーパラメータは別

active-activeであっても、

速度不一致
トランク不一致
レイヤ2・レイヤ3 不一致

などが存在すれば期待するバンドルにならない場合があります。

49. メンバーパラメータ不一致

EtherChannelへ参加するメンバーには互換性が必要です。

代表的な確認対象には、

• 速度
• デュプレックス
• レイヤ2・レイヤ3の役割
• スイッチポート役割
• VLAN関連パラメータ

などがあります。

50. 速度不一致

同一EtherChannelメンバー候補で、

メンバー A → 速度 X
メンバー B → 速度 Y

となっている場合、互換性を確認します。

51. 速度確認

必要に応じて、

show interfaces status

やインターフェース設定などから速度を確認します。

52. デュプレックス不一致

デュプレックスパラメータもメンバー互換性の確認対象です。

メンバー A
フルデュプレックス

メンバー B
異なる条件

のような差が問題文で提示された場合は確認します。

53. パラメータが全部文字列一致とは限らない

トラブルシューティングでは、

すべてのインターフェース設定が
完全に同じ文字列でなければならない

と単純化しません。

バンドル形成に関係するパラメータの互換性を確認します。

54. レイヤ2EtherChannelならスイッチポート属性を見る

レイヤ2 EtherChannelでは、

アクセス・トランク
アクセスVLAN
ネイティブVLAN
許可VLAN

などのレイヤ2パラメータも確認対象になります。

55. アクセス・トランク不一致

次のようなメンバーは、

Gi1/0/1 → トランク
Gi1/0/2 → アクセス

同一レイヤ2バンドルのメンバーとしての役割が一致していません。

56. アクセスEtherChannelならVLANを確認する

アクセスEtherChannelでは、メンバーが異なるアクセスVLANへ所属していないか確認します。

メンバー A → VLAN 10
メンバー B → VLAN 20

なら論理アクセスバンドルとしての整合性を調べます。

57. トランクEtherChannelではトランクパラメータを確認する

レイヤ2トランクEtherChannelでは、

• トランク役割
• ネイティブVLAN
• 許可VLAN

などを確認します。

58. トランクパラメータ不一致

次のメンバーを考えます。

メンバー A
ネイティブVLAN 99

メンバー B
ネイティブVLAN 1

同じ論理トランクを構成するメンバーとして不整合を確認します。

59. 許可VLAN不一致

次の状態も確認対象です。

メンバー A
許可VLAN 10,20

メンバー B
許可VLAN 10,20,30

トランクパラメータが一致しているか確認します。

60. Port-Channel側の論理設定も見る

物理メンバーだけではなく、

interface Port-channel1

側のアクセス・トランク設定も確認します。

61. show interfaces switchport

レイヤ2 Portの詳細を確認する際は、

show interfaces <interface> switchport

を利用できます。

メンバーとPort-Channelの役割確認に役立ちます。

62. show interfaces trunk

トランクEtherChannelでは、

show interfaces trunk

で論理トランクやVLAN関連情報を確認できます。

63. サマリーとトランク出力を使い分ける

show etherchannel summary
→ バンドル・メンバー状態

show interfaces trunk
→ トランク・VLAN状態

と役割を分けます。

64. running-configも比較する

必要に応じて、

show running-config

やインターフェース単位の設定を確認し、メンバー間の差を調べます。

65. すべてのメンバーを比較する

4メンバー構成なら、

メンバー1
メンバー2
メンバー3
メンバー4

を必要に応じて比較します。

1本だけ異なる設定があればバンドル状態に差が出る可能性があります。

66. 「1本だけバンドルされない」シナリオ

サマリー：

Po1(SU) LACP
Gi1/0/1(P)
Gi1/0/2(P)
Gi1/0/3(...)

なら、Gi1/0/3固有の状態やパラメータを優先的に比較できます。

67. 「全部バンドルされない」シナリオ

全メンバーが期待どおり参加しない場合は、

両端LACPモード
レイヤ2・レイヤ3の役割
ローカルの関連付け
共通パラメータ

など、バンドル全体に影響する条件も疑います。

68. 症状の範囲を利用する

1 メンバーだけ異常

ならメンバー固有条件、

全メンバー異常

なら共通設定や対向設定、

というように調査方向を決める材料にできます。

ただし症状だけで確定はしません。

69. ローカルの関連付けシナリオ

SW1：

Gi1/0/1
 channel-group 1 mode active

Gi1/0/2
 channel-group 2 mode active

2本を1つのEtherChannelへバンドルする設計なら、ローカルの関連付けを確認します。

70. ローカルの関連付け修正例

設計上Port-channel1へまとめるなら、必要なメンバーを同じローカルチャネルグループへ揃えます。

例：

Gi1/0/1
 channel-group 1 mode active

Gi1/0/2
 channel-group 1 mode active

71. 対向グループ番号シナリオ

SW1：

channel-group 1 mode active

SW2：

channel-group 20 mode active

この数字の違いだけを根本原因とはしません。

72. 対向番号より重要な確認

対向側について重要なのは、

正しい対向物理リンクが
同じ対向側のローカルバンドルへ参加しているか

などです。

対向グループ番号がローカル側と同じかどうかだけを見るのではありません。

73. 対向側メンバーの関連付けは確認する

対向グループ番号の独立性は、

対向側では
メンバーを別々のグループへ入れてもよい

という意味ではありません。

対向デバイス内でも、同じバンドルにするメンバーは意図した同じローカルグループへ関連付けします。

74. 独立性の正しい意味

整理すると、

SW1内部
→ SW1メンバー同士のローカルの関連付けが重要

SW2内部
→ SW2メンバー同士のローカルの関連付けが重要

SW1グループ番号とSW2グループ番号
→ 数字の一致そのものは必須と決めつけない

です。

75. トラブルシューティングの中間フロー

ここまでをまとめます。

物理 Up?
   ↓
レイヤ2・レイヤ3の役割一致?
   ↓
ローカルの関連付け正しい?
   ↓
LACPモード成立?
   ↓
メンバーパラメータ互換?
   ↓
レイヤ2トランクならトランクパラメータ整合?

76. その後動作状態を再確認する

設定を確認した後は、

show etherchannel summary

へ戻り、メンバーが期待どおりバンドルされたか確認します。

77. 修正は原因に対応させる

トラブルシューティングでは、

とりあえず全部削除して再設定

よりも、特定した原因に対応する最小修正を行います。

78. 管理上のshutdown修正例

原因が管理上のshutdownなら、

interface GigabitEthernet1/0/1
 no shutdown

などを検討します。

79. レイヤ2・レイヤ3の役割修正例

レイヤ3EtherChannelメンバーなのにスイッチポートになっている場合は、設計に従い、

no ip address
no switchport

などで役割を整合させます。

80. LACP passive-passive修正例

passiveとpassive

が原因なら、少なくとも一方を、

mode active

へ変更します。

81. ローカルの関連付け修正例

メンバーが異なるローカルグループへ割り当てられている場合は、意図した論理Port-Channelへ関連付けを揃えます。

82. トランクパラメータ修正例

ネイティブVLAN不一致なら、設計値へ統一します。

例：

interface Port-channel1
 switchport trunk native vlan 99

実際の修正場所はプラットフォームと既存設定を確認して決めます。

83. 許可VLAN修正例

必要なVLANが不足している場合は、設計に従って論理トランクの許可VLANを修正します。

例：

switchport trunk allowed vlan add 30

84. 速度・デュプレックス修正

パラメータ不一致が原因なら、意図したインターフェース仕様と対向条件に合わせて整合させます。

無関係な設定まで同時変更しません。

85. 修正後にサマリーを再確認する

修正後は、

show etherchannel summary

を再実行します。

期待するメンバーが、

(P)

などのバンドル済み状態になったか確認します。

86. LACPネイバーも再確認する

LACP関連を修正した場合は、

show lacp neighbor

で対向LACP情報を再確認できます。

87. レイヤ2ならトランク状態も確認する

レイヤ2トランクEtherChannelなら、

show interfaces trunk

などでトランク・VLAN状態も確認します。

88. レイヤ3ならIP状態も確認する

レイヤ3 EtherChannelなら、

show ip interface brief

などでPort-ChannelのIP・動作状態を確認します。

89. 修正後疎通も確認する

バンドルが正常化しただけで終了せず、必要な通信が期待どおり成立するかも確認します。

90. 1つ修正したら結果を見る

複数の原因候補がある場合でも、

修正
→ 再確認

を繰り返すことで、どの変更が結果へ影響したかを明確にします。

91. シナリオ：物理メンバー down

サマリーでメンバーが期待状態でなく、インターフェース確認で物理downを確認した場合は、まず物理・管理状態を調べます。

LACPモードだけを変更するのは優先順位が違います。

92. シナリオ：レイヤ2・レイヤ3の役割不一致

2メンバーのうち、

メンバー A = switchport
メンバー B = no switchport

なら、役割不一致を原因候補として扱います。

93. シナリオ：active・passive

SW1 active
SW2 passive

ならLACPモードの組み合わせ自体は成立可能です。

他の原因を確認します。

94. シナリオ：passiveとpassive

SW1 passive
SW2 passive

ならネゴシエーション開始側がないことが根本原因です。

少なくとも片側をactiveへ変更します。

95. シナリオ：速度が1本だけ違う

3メンバー中1本だけ速度条件が異なり、そのメンバーだけバンドルされない場合はメンバーパラメータ不一致を疑います。

96. シナリオ：トランク役割が1本だけ違う

メンバー A = トランク
メンバー B = トランク
メンバー C = アクセス

なら、レイヤ2役割・トランクパラメータを確認します。

97. シナリオ：ネイティブVLANが異なる

トランクEtherChannelメンバー間で、

ネイティブVLAN 99
ネイティブVLAN 1

という差があれば、トランクパラメータ不一致として確認します。

98. シナリオ：許可VLANが異なる

メンバー間または論理トランク設定で期待する許可VLANが一致していない場合は、VLANパラメータの整合を確認します。

99. シナリオ：ローカルグループが異なる

SW1 Gi1/0/1 → group 1
SW1 Gi1/0/2 → group 2

なら、同一ローカルPort-Channelへ関連付けする設計か確認します。

100. シナリオ：対向グループ番号だけ違う

SW1 group 1
SW2 group 20

で、他条件が正常なら、

番号が違う

という理由だけで障害と判断しません。

101. シナリオ：対向側もメンバーの関連付けを確認する

SW2がグループ 20を使用していること自体は問題でなくても、

SW2メンバー A → group 20
SW2メンバー B → group 30

なら、対向デバイス内のローカルの関連付けを確認します。

102. シナリオ：設定は正しいがバンドルされない

設定上、

active-active
同一グループ
役割一致

でもメンバーがバンドルされない場合は、物理状態やメンバーパラメータを確認します。

設定だけで正常判定しません。

103. シナリオ：サマリーで全メンバー(P)

Po1(SU) LACP
Gi1/0/1(P)
Gi1/0/2(P)

なら、基本的なバンドル状態は正常方向と判断できます。

必要ならトランクや疎通を追加確認します。

104. シナリオ：LACPネイバーがない

期待するLACPネイバーが見えない場合は、

物理状態
LACPモード
ローカル・対向設定

を確認する方向を考えます。

105. よくある誤り：最初からLACPだけ疑う

EtherChannel障害には物理、役割、パラメータなど複数の原因があります。

順番に確認します。

106. よくある誤り：active-passiveを障害と判断する

activeとpassive

はLACPモード上形成可能です。

passiveが存在するだけで障害とはしません。

107. よくある誤り：passive-passiveでも形成できると考える

両端passiveではネゴシエーション開始側がありません。

これはモード上の根本原因になります。

108. よくある誤り：対向グループ番号は必ず一致すると考える

チャネルグループ番号を対向デバイス間で同じにしなければならない、と一律に判断しません。

ローカルグループ関連付けと対向番号を分けます。

109. よくある誤り：対向グループ番号の独立性を誤解する

対向グループ番号が独立だからといって、対向デバイス内のメンバーを別々のグループへ自由に割り当ててよいわけではありません。

各デバイス内部ではローカルの関連付けを正しく構成します。

110. よくある誤り：サマリーだけでトランクVLANも正常

メンバーが(P)でも、

ネイティブVLAN
許可VLAN

まで自動的に正しいとは限りません。

トランク情報を別途確認します。

111. よくある誤り：トランクパラメータだけ見ればよい

物理リンクがdownしていれば、VLAN設定を修正しても根本原因は解消しません。

確認順序を保ちます。

112. よくある誤り：複数設定を一度に変更する

原因が不明なまま、

モード変更
VLAN変更
速度変更
グループ変更

を同時に行うと原因判定が難しくなります。

最小修正と再確認を行います。

113. よくある誤り：修正したら終了と考える

設定を変更した後は、

show etherchannel summary
show lacp neighbor

などで動作結果を確認します。

114. コマンド役割比較

115. トラブルシューティング判断表

116. 全体トラブルシューティングフロー

show etherchannel summary
        ↓
期待するメンバーを特定
        ↓
物理状態
        ↓
レイヤ2・レイヤ3の役割
        ↓
ローカルchannel-groupの関連付け
        ↓
LACP active・passive
        ↓
メンバーパラメータ
        ↓
レイヤ2トランクならVLANパラメータ
        ↓
原因を修正
        ↓
show etherchannel summary
        ↓
show lacp neighbor
        ↓
必要なレイヤ2・レイヤ3状態と疎通確認

117. 問題パターン1：EtherChannelトラブルシューティングの順序

EtherChannelがバンドルされない場合に、

物理
→ 役割
→ 関連付け
→ LACP
→ パラメータ
→ 動作状態

と段階的に確認する順序を判断します。

118. 問題パターン2：物理メンバー状態

物理インターフェースがdown、shutdown、または利用不能な状態なら、上位EtherChannel設定より先にメンバー状態を確認することを判断します。

119. 問題パターン3：レイヤ2・レイヤ3の役割不一致

同一バンドル候補のメンバーに、

switchport
no switchport

が混在している場合、レイヤ2・レイヤ3の役割不一致を判断します。

120. 問題パターン4：LACPモード確認

両端の、

channel-group <id> mode active/passive

を比較し、LACPモードの組み合わせを判断します。

121. 問題パターン5：passive-passive根本原因

passiveとpassive

ではネゴシエーション開始側がないため、LACP形成不可の根本原因になることを判断します。

122. 問題パターン6：メンバーパラメータ不一致

速度、デュプレックス、役割など、バンドルへ参加するメンバーに必要なパラメータの不整合を判断します。

123. 問題パターン7：トランクパラメータ不一致

レイヤ2トランクEtherChannelで、

ネイティブVLAN
許可VLAN
トランク役割

などの不一致を原因候補として判断します。

124. 問題パターン8：ローカルchannel-groupの関連付け

同一デバイス上のメンバーが、意図した同じローカルチャネルグループへ関連付けされているか判断します。

125. 問題パターン9：対向channel-group番号の独立性

対向デバイスのローカルチャネルグループ番号が異なるという理由だけで、LACP形成障害と判断しないことを確認します。

126. 問題パターン10：修正後確認

原因に対応した修正後、

show etherchannel summary
show lacp neighbor

などでバンドル・ネイバー状態を再確認することを判断します。

127. 問題パターン11：順序と物理状態

EtherChannelが形成されないシナリオで、まずサマリーから対象メンバーを特定し、物理状態を確認する流れを判断します。

128. 問題パターン12：レイヤ2・レイヤ3の役割とLACPモード

メンバー役割の不一致とactive/passiveの組み合わせを別問題として切り分けます。

役割不一致

がある場合、LACPモードが正しくても正常バンドルとは判断しません。

129. 問題パターン13：passive-passiveとメンバーパラメータ

両端passiveという明確なモード障害と、速度などのメンバーパラメータ不一致を区別し、どちらが提示されているか判断します。

130. 問題パターン14：トランクパラメータとローカルの関連付け

レイヤ2EtherChannelで、

トランクパラメータは一致しているか
メンバーは同じローカルグループか

を別々に確認します。

131. 問題パターン15：対向グループ番号と修正・確認

SW1 group 1
SW2 group 20

という数字の違いだけを修正対象とせず、実際の障害原因を特定し、その原因だけを修正して再確認します。

132. 最終判断フロー

EtherChannelトラブルシューティングでは次の順序を基本にします。

症状確認
   ↓
show etherchannel summary
   ↓
物理メンバー状態
   ↓
レイヤ2・レイヤ3の役割
   ↓
ローカルの関連付け
   ↓
LACPモード
   ↓
メンバー互換性
   ↓
レイヤ2ならトランクパラメータ
   ↓
根本原因特定
   ↓
最小修正
   ↓
サマリー・ネイバー再確認
   ↓
必要な通信確認

133. まとめ

LACP EtherChannelが期待どおりバンドルされない場合は、LACPモードだけを見るのではなく、段階的に原因を切り分けます。

最初に、

show etherchannel summary

から論理Port-Channelと物理メンバーの状態を確認します。

次に、

物理状態
→ レイヤ2・レイヤ3の役割
→ ローカルchannel-groupの関連付け
→ LACPモード
→ メンバーパラメータ

という順序で確認します。

レイヤ2トランクEtherChannelなら、さらに、

ネイティブVLAN
許可VLAN
トランク役割

などのトランクパラメータも確認します。

LACPでは、

activeとactive
→ モード上形成可能

activeとpassive
→ モード上形成可能

passiveとactive
→ モード上形成可能

passiveとpassive
→ 形成不可

です。

また、

ローカルデバイス内のメンバーグループ

は正しく関連付けする必要がありますが、

ローカル側グループ 1
対向側グループ 20

のように対向デバイス間でグループ番号が異なるという事実だけをLACP障害の原因とはしません。

原因を特定したら、その原因へ対応する最小修正を行います。

修正後は、

show etherchannel summary

でメンバーのバンドル状態を確認し、LACP関連を修正した場合は、

show lacp neighbor

でピア情報も確認します。

EtherChannelトラブルシューティングの基本は、

確認
→ 原因特定
→ 最小修正
→ 動作状態を再確認

です。