キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
566
閲覧回数
0
いいね!
0
コメント

  資料ダウンロード

フォローアップエキスパートに質問は開催期間を終了いたしました。
------------------------------------------------------------------------------------------------------------------------
Q1. High CPU や packet drop が発生した際に取得する debug があれば教えてください。
A1.  debug は CPU に負荷をかけるので、ある程度原因を特定出来た段階で特定のものにしぼって依頼させて頂いています。
事象の詳細がわからない状態にとりあえずこれを取得してください、というような debug はないです。

Q2. Fragment Packet を受信している場合 の DF bit 付きの ping の例を紹介してください。
A2.  IOS 機器であれば、
Router#ping 192.168.1.1 df-bit
のようにすればよいです。

windows であれば、-f オプションを付ければよいです。
> ping -f -l 1460 192.168.1.1
のようにすれば良いです。(-l は size を指定するオプションです。)

Q3. "show interface" で、"drops" と "Total output drops" の違いは何ですか。
A3.  drops は input queue(ルータ宛てのパケット) の drop です。
Total output drops はその interface から出力される際に drop されたパケットの数です。

Q4. SPD の部分の "ip spd mode aggressive" はどんな時に設定するべきでしょうか。
A4.  あまりないかもしれませんが、ルータ宛てに IP header に問題があるようなパケットを多く受信するような環境であれば設定した方がよいかも知れません。

Q5. SPD で Drop してしまう Packet はどのような packet が多いのでしょうか。
A5.  Process Switching されるパケットです。どのようなパケットが drop するかは流れている traffic 次第ですが、headroom や extended-headroom に入ることが出来るパケットは drop しづらくなっていますので、normal queue に入るパケットが drop しやすくなります。

Q6. 割込み処理とプロセス処理でだいぶパケット転送の処理方法が違うように見えますが、これはなぜそうなっているんでしょうか。
A6.  CEF(割込み処理)ではプロセス処理の場合にたどる処理をショートカットし大幅に処理時間を減らしています。
一方、プロセス処理の場合は様々なテーブルを参照して必要な転送情報を作成するので時間を要します。
CEFでショートカットが出来るのは以前に同じ転送処理結果になるパケットを処理したことがあり、その情報がキャッシュされているため、処理結果が予め分かっているためです。

Q7. 割込みとプロセスは結局のところいずれもCPUが処理を行うようですが、どう違うのでしょうか。
A7.  一番大きな違いは処理にかかる時間です。プロセス処理は msec のオーダーで行われますが、割込み処理はusec のオーダで処理が行われます。

Q8. SSPD のヘッドルームは 75 個のキュー要素に加えて100個のキュー要素が加わるんでしょうか。それとも既にある75個と併せて100個ということでしょうか。
A8.  75 個の要素とは別に100個あります。

Q9. Public buffer が枯渇する、とありましたが、public buffer には既定の決められたサイズがあるということでしょうか。
A9.  必要に応じてI/Oメモリ領域から取り出すことができるので、予め決まったサイズの中でやりくりするということではありません。

Q10. Fragment パケットの場合はいつもプロセス処理されるのでしょうか。
A10.  転送するパケットの場合は通常CEFで処理されます。ここで述べたのは fragment パケットがルータ宛の場合です。

Q11. Static route の書き方で next hop を書かない場合はいつも ARP 解決を行うということでしょうか。
A11.  これは next hop に interface だけ書いた場合ということでいいでしょうか。
宛先に対するARP解決が済んでいればARPを送信することはありません。
ただ、interface だけを指定した場合は実際に送る next hop がひとつのエントリだとしても宛先が異なっていればその都度ARP解決を行いますので、
本来は必要ない ARP 処理が増えるとか、ARP テーブルが大きくなるとかいった状況になって high cpu 状態を引き起こしやすいという問題があります。

Q12. no buffer や ignored がカウントされている のところでバッファが不足すると no buffer や ignored がカウントされるとありますが具体的にはどういった状況でバッファが不足しますか。
A12.  パケットが大量に来てバッファが足りなくなってしまった場合や、fragment パケットを受信して huge buffer がたくさん使用された場合や、あとはバッファリークなどの不具合が発生した場合です。

Q13. CRC は Software の不具合でカウントされることはないのでしょうか。
A13.  可能性としてはゼロではないですが、Software の不具合で CRC がカウントされるということは可能性としては限りなくゼロに近いと思います。
新製品などでリリースされたばかりであれば、Software不具合で CRC がカウントされることもあるかもしれません。

Q14. SPD の headroom や extended-headroom を default から変更する場合どういったことに気をつければ良いでしょうか。
A14.  SPD の headroom や extended-headroom を 大きくした場合、それだけ重要なパケットが CPU に到達しやすくなりますが、
大きくした場合は CPU に重要なパケットが多く到達するようになる可能性があるので、結果として High CPU の状況が起こりやすくなる可能性があります。
しかし小さすぎても重要なパケットを drop してしまうので一長一短です。
検証して判断して頂ければと思います。
input queue size を変更する hold-queue <size> in についても同様です。

Q15. IPv6 でも SPD はサポートされていますか。またどの version からサポートされていますか。
A15.  IPv6 でも SPD はサポートされています。
IPv6 の SPD のサポート version は以下のドキュメントに記載されていますのでご参照ください。
https://supportforums.cisco.com/ja/document/122306

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします