シスコサポートコミュニティ
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

6/19 Webcast 「ルーティングプロトコルのネイバーダウンに 関するトラブルシューティング」 Q&A

 

スピーカー紹介

東村 誉(ヒガシムラ タカシ)

シスコテクニカルサポート、RP/WAN/IBM/OPTIC Team

2007年入社。カスタマーサポートエンジニアとしてシスコ テクニカルサポート部門、ルーティングプロトコルチームへ配属。

以降、RP, WAN, IBM や OPTIC などのテクノロジに関するサポートを担当。現在は、Routing Protocol を最も専門とし活躍している。

保有資格: CCIE 27598 in Routing and Switching

 

セミナーの録画ビデオはこちらでご覧いただけます。

7月1日(日)まで「エキスパートに質問」で質問を受け付けています。

 

質問

Q1. SPDにおいて、各キューのサイズを設定で変更することはできますか?また、変更する必要がある時はどのような場合ですか?

A1. はい。SPDのキューサイズを変更することは可能です。下記ページを参照ください。

http://www.cisco.com/web/JP/product/hs/ios/tec/spd.html

変更する必要があるケースとしましては、複数のルーティングプロトコルを稼働している場合や、ネイバーが多数ある場合などが挙げられます。

 

Q2. debugによるシステムへの負荷はどの程度でしょうか?

A2. こちらは一概に申し上げることができません。資料の中で案内させていただいた show/debug ログ取得の際の推奨設定を実施していただき、負荷を軽減して取得していただくしかございません。

そのため、debug 取得時に懸念がある場合には事前に検証環境等で実環境での影響を確認してもらうことを提案させていただいております。

 

Q3. SPD はどのルーティングプロトコルでも、適用されますか?

A3. はい。基本的なものは SPD で保護されます。例えば、BGP, EIGRP, OSPF です。その他 HSRP 等も保護の対象となりますが、詳細は下記ページに記載されている情報を参照ください。

http://www.cisco.com/web/JP/product/hs/ios/tec/spd.html

 

Q4. OSPFにおいて、Dead timer expiredでNeighbor Downすることはよく耳にするのですが、それ以外ではどのような原因が多いのでしょうか?

 

A4. OSPF neighbor を確立した後という場合では、ネイバーを確立している interface down に起因するものが多いですが、最も多いのは dead timer expired です。

 

Q5.  OSPF の RFC についてはいくつか versionがありますが、Cisco IOS についてはどの RFC を読めばよいですか?

A5. OSPFの基本的な部分としては資料でも出てきました RFC2328 になります。拡張機能などは個別に RFC が出ていますので、必要に応じて確認するという形になります。弊社 IOS で準拠している RFC 一覧が下記ページにあります。こちらを見たり、キーワードで検索することでどのようなRFCがあるかも確認することができると思います。

http://www.cisco.com/en/US/partner/prod/collateral/iosswrel/ps8802/ps6968/ps6350/prod_bulletin0900aecd802eaa4f.html

 

Q6. OSPFのデモで、ACLを設定してHelloを落としていたと思いますが、downした後にすぐにOSPF がUpした理由を教えていただけますでしょうか。

A6. OSPFネイバー確立後は 224.0.0.5 で Hello を定期的に送出しますが、新規にネイバーを確立する際には、ネイバーの確立を早くするため、224.0.0.5 の Hello を受信した側は相手にユニキャストですぐに Hello を返す動作を行います。そのため、デモの際は 224.0.0.5 は deny していましたが、ユニキャストは deny していなかったためとなります。

 

Q7. debコマンド時にACLを設定することを推奨されていますが、実際の運用中にはほとんど不可能と思われます。運用中にはどのようにしぼりこめばいいのでしょうか?

A7. ACL で絞った形での debug も難しい場合には、代替としてはパケットキャプチャを取るしかない場合がほとんどです。しかしながら、キャプチャからの解析は時間もかかり非常に難しいため、実環境で debug が取得できない場合は、検証環境等で事象を再現し、その環境で debug を取得して解析を進めるという方向にしていく必要があります。

 

Q8. MTUサイズの不一致に拠る隣接ダウンを解説して頂きましたが,分割されたパケットを受け取る様にする設定も可能なものでしょうか?

A8. 基本的に MTU を超過する場合には、MTU に合わせて分割されて送信されますので、分割されたパケットを受信することになります。特に設定はございません。ただし、前提としてネイバー間での MTU は同じでなければ解説したような問題が発生することになります。

 

Q9. 送った方が良い他のコマンド結果を教えて欲しいです。

A9. こちらはケースバイケースとなるため、一概に案内することは困難となります。

弊社 Cisco.com や Cisco Support Community にあるような情報を参考に、事象に合わせて必要と考えられるようなものを取得していただくしかございません。

 

 

Q10. デフォルトのMTUサイズは製品毎に異なるのですか?一般的にはどのような理由でMTUサイズの不一致が発生するのですか?

A10. 通信事業者等のサービスにより、L3スイッチ等でQinQを行ったりすることでヘッダが増加するため、MTU を大きくしたりするケースがあります。

 

Q11. 以下の2つはどのような違いがあるのですか?

・対向ルータが OSPF Hello を drop した(トラフィック過多)

・ルータ間の L2 区間で OSPF Hello が drop された(トラフィック過多)

A11. 前者は SPD のキューでドロップされた場合、後者は L2区間が 100M->10M などの帯域が変更となるデザインの場合などには帯域差による破棄などがあります。

 

Q12. EIGRPはRFC化されないんですか?

A12. 申し訳ございませんが、その予定はありません。

 

Q13. 自社で使用しているルータでは log-adjacency-changeが show run に表示されているんですがバグですか?

A13. log-adjacency-change は default で有効な設定となっておりますが、バージョンによっては sh run で表示されるものがあります。しかしながら、動作に支障があるものではございませんので、特に気にしていただく必要はございません。

993
閲覧回数
0
いいね!
0
コメント