ネットワーク【3分】シンキング – デバッグを効果的に活用しよう(BGP編)!

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

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

本日のお題 :

現在、R2<>R3の区間でBGPが接続できない問題が発生しています。R3は外接ルータ(キャリア管理)のため、コンフィグやルータのステータスを見ることができません。そのため、R2へデバッグコマンドを投入して障害を切り分けたところ、R3側に問題があることを突き止めました。(R3のWAN I/Fが一時的にシャットダウンされていた!) デバックコマンドとして【有効ではない/間違っている】解答を1つ答えなさい。

  • A : debug ip bgp neighbor
  • B : debug ip packet
  • C : debug ip tcp transactions
  • D : debug ip bgp

R1 コンフィグ
hostname R1
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0
!

!
!
!
line con 0
line aux 0
line vty 0 4

!
!
!
!
!
!
!
!
!
!
!

!
!
!
!
!
!
!
!
end

R2 コンフィグ
hostname R2
!
interface Loopback1
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
### LAN OSPF ###
ip address 192.168.1.2 255.255.255.0
!
interface FastEthernet1/0
### WAN BGP ###
ip address 10.0.0.2 255.255.255.0
!
router ospf 1
redistribute bgp 100 subnets route-map BGPToOSPF
network 2.2.2.2 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0
!
router bgp 100
no synchronization
redistribute ospf 1 route-map OSPFToBGP
neighbor 10.0.0.3 remote-as 200
no auto-summary
!
ip prefix-list BGP seq 5 permit 3.3.3.3/32
ip prefix-list OSPF seq 5 permit 1.1.1.1/32
!
route-map OSPFToBGP permit 10
match ip address prefix-list OSPF
!
route-map BGPToOSPF permit 10
match ip address prefix-list BGP
!
end

本日の回答 :

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

回答のポイントは「Ciscoデバイスでサポートされる Debugコマンド(BGP/IP Packet) のベストプラクティス」を正しく理解する必要があります。今回のケースでは、R2<>R3の区間で流れるトラフィックを可視化して障害切り分けを行いたいため、BGP(TCP Transaction)やIP Packetのシーケンスに特化したDebugコマンドを活用しつつ、Cisco IOSではサポートされないコマンド(debug ip bgp neighbor)の選択がベストアンサーとなります。

通信障害が発生している際には「show ip bgp xxx」コマンドだけでは切り分けに限界があります。また、今回のケースのように対向機器が自分たちの管轄外でステータスの確認が全くできない状況もよくあることです。このような場合に役立つコマンドが「debug」です。一般的に本番環境で稼働している機器にdebugコマンドを投入するとシステム負荷が高くなってしまうため、「タブー」とされるケースが多いですが、必要最低限の機能に絞ったdebug コマンド(絶対にdebug allなどの高負荷なコマンド実行はダメ!)にて障害を切り分けることは最終手段として実施されています。

最適なdebugコマンドの選択はとても難しく、可能な限り、本番環境では実施したくないイベントとなりますが、debugログをsyslogのみに飛ばして、システム負荷を最小限、かつ、短期間での切り分けであれば、大きな問題にならないケースも多いです。また、有益なdebugコマンドの見つけ方は「Cisco Configuration Guide」を参考にラボ検証->本番適応で望んでいただくことが望ましいです。(ラボ検証にて想定されない動作=バグを疑う前にまずは debug で切り分けを行うは定番中の定番です!また、今回のケースのようにTCPシーケンスやIP Packetの動作を診断するためには「パケットキャプチャ」に関する知識も必須となりますので合わせてスキルアップしたいですね!)

おすすめの書籍 :

Cisco人気ブログのご紹介 :

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

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

コメント