スポンサーリンク

ネットワーク【3分】シンキング – パケロスが発生する

Cisco
カモフラ<br>(管理人)
カモフラ
(管理人)

ネットワーク(特にCisco)が大好きな皆様へCCNA/CCNP/CCIE試験で問われる【お題】をQuiz形式で出題致します。また、本ブログではCiscoさんが無償で提供する【Packet Tracer】や【GNS3】を利用しての簡単なシュミレーションと実際の業務で役立つワンポイントなども織り混ぜながら、皆さんが楽しめるコンテンツ(3分でサクッと読める内容)となります。

本日のお題 :

SW_1<>2にポートチャネルを実施し、LB : 1.1.1.1 <> 2.2.2.2 へ性能テストを実施したところ、たまにパケロスが発生する。I/Fステータスを調査したところ、Gi1/0/1にて”err-disabled”が発生しています。(解決策を答えなさい / 複数選択)

  • A : 該当I/Fに”shutdown/no shutdown”を実施する
  • B : SW1<>2に”port-channel”を再設定する
  • C : SW1<>2に”no spanning-tree vlan1″を設定する
  • D : SW1<>2に”errdisable recovery”を設定する

SW_1コンフィグ

hostname SW_1
!
port-channel load-balance src-dst-mac
spanning-tree mode pvst
!
interface Loopback1
ip address 1.1.1.1 255.255.255.0
!
interface Port-channel1
switchport mode trunk
!
interface GigabitEthernet1/0/1
switchport mode trunk
channel-group 1 mode active
!
interface GigabitEthernet1/0/2
switchport mode trunk
channel-group 1 mode active
!

interface GigabitEthernet1/0/3
switchport mode trunk
channel-group 1 mode active
!
interface Vlan1
ip address 192.168.1.1 255.255.255.0
!
ip route 2.2.2.0 255.255.255.0 192.168.1.2
!
line con 0
line aux 0
line vty 0 4
login
!
end

SW_2コンフィグ

hostname SW_2
!
port-channel load-balance src-dst-mac
spanning-tree mode pvst
!
interface Loopback1
ip address 2.2.2.2 255.255.255.0
!
interface Port-channel1
switchport mode trunk
!
interface GigabitEthernet1/0/1
switchport mode trunk
channel-group 1 mode active
!
interface GigabitEthernet1/0/2
switchport mode trunk
channel-group 1 mode active
!
interface GigabitEthernet1/0/3
switchport mode trunk
channel-group 1 mode active
!
interface Vlan1
ip address 192.168.1.2 255.255.255.0
!
ip route 1.1.1.0 255.255.255.0 192.168.1.1
!
line con 0
line aux 0!
line vty 0 4
login
!
end

本日の回答 :

正解は【AとD】になります。

コンフィグを確認する限り、特に問題は無いように見えるが、設定の投入順番や結線タイミングによってI/Fステータスがダウン(err-disabled状態)となってしまうことがあります。以下のCofiguration Guideを参考にポートチャネル設定後は「show etherchannel summary」、「show interfaces status」などでインターフェースUPやチャネル接続数をチェックする必要がございます。

インターフェイスが errdisable 状態になる理由」は様々ですが、「errdisable recovery causeコマンド」を過信しすぎるのは要注意です。機器障害でI/Fがフッラッピングしている状態が続いた場合、errdisable recoveryがエラーを自動検知して修復を行おうとして、ループ状態(障害<>修復)でログが多発するケースがよくあります。便利な機能ではありますが、物理障害をきちんと検知するためにはまだまだ人手での対応も必要です。(DNACなどはこの問題をAIが賢く解決してくれますが、それはまた違う機会で解説いたします)

おすすめの書籍 :

Cisco人気ブログのご紹介 :

皆様からのご質問について

本サイトでは皆様からご質問を受け付けております。ご質問には必ずご回答させていただきますので、まずは本ブログサイトの”お問い合わせ“より、ご連絡をお願い致します。

Cisco
スポンサーリンク
♡(ˊo̴̶̷̤ ᴗ o̴̶̷̤ˋ)***シェアをお願い致します***(ˊo̴̶̷̤ ᴗ o̴̶̷̤ˋ)♡