2015/4/21 Webcast ’Cisco ISR G1/G2 トラブル シューティング ～High CPU & Packet Drop～ フォローアップ エキスパートに質問

[CiscoJapanModerator]

このエキスパートに質問は2015/4/21に開催した Webcast のスピーカーが担当します。Webcast トピック に関することでしたらできる限り回答いたしますので、どうぞご利用ください。

担当: 高尾　竜太 (Ryota Takao)

開催期間: 2015/4/22～5/3

  

[質問の投稿方法]

サポートコミュニティへ Cisco.com ID でログインすると、この説明の右下に「返信」ボタンが表示されます。クリックすると投稿欄が表示されますので、質問をご記入ください。最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。

もし１つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。

エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエキスパートへぜひ伝えてください。

[t-maeyama]

担当エキスパート: 高尾様

本日はトラブルシューティングの講演ありがとうございました。

High CPU に関して、質問させて頂きます。

High CPUの原因が「Traffic量が多い」である場合、基本的にTraffic を減らすしかないと

ご説明頂きましたが、Traffic を減らすにあたり指標となるTraffic 量のMax値などは

御座いますでしょうか。

製品毎にまとめられた情報や個別の検証情報など製品限界を確認できるものがあれば

ご教示願います。

以上、よろしくお願いします。

[Ryota Takao]

ご質問頂きありがとうございます。

Performance のデータとしては以下のような資料がございます。

Portable Product Sheets – Routing Performance
http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf

ただ、このデータが参考になるかというと、実環境ではあまり参考にならないと思います。
通常こういったデータは理想的な環境での値です。
例えば、CEFで転送可能な IPv4 の unicast パケットのみがあり、ルータ宛ての Traffic は存在しない、
また Interface ACL、QoS、IPSec なども使用していないといった環境です。

実環境では、CEF で転送可能なパケット以外にもルータ宛てのパケットもあると思います。
ルータ宛てのパケットの処理は多くの CPU 時間を消費します。
また、通常 Interface ACL、QoS、IPSec といった何らかの Feature を使用して運用されていると思います。
こういった Feature を使用するとその処理を行うために CPU時間 が消費されますので、
そのぶんパフォーマンスは劣化します。
ですので、上記のデータシートの値とかけ離れた値で CPU が 100% になることは十分考えられます。
そのため、基本的には検証によってご確認頂くしかないと思います。

どうぞよろしくお願いします。

[t-maeyama]

担当エキスパート: 高尾様

ご回答頂き、ありがとうございます。

HighCPUが発生したお客様より、当該機器だけでなく正常稼働中の機器についても

調査を依頼されており、指標があれば活用したかったのですが

やはり検証するしかないと分かりました。

以上、ありがとうございました。

[Kei Kondo]

担当エキスパート: 高尾様

トラブルシューティングの講演とても参考になりました。

以下、3点質問させてください。

SPD（headroomやextended headroom）により、ルーティングプロトコル等の
helloパケットが保護される機能があることがわかりました。

質問① IGP Helloパケット受信の場合

前提として、
・headroom/extended headroomが一杯にはならない環境
・データパケット=IP Precedence(0～5）

データパケットが大量にRXInterface入って来た場合でも、輻輳によりIGP Hello
が破棄されることはないのでしょうか？また遅延に関してはどうなのでしょうか？

質問② IGP Helloパケット送信の場合

前提として、
・headroom/extended headroomが一杯にはならない環境
・データパケット=IP Precedence(0～5）

IGP Helloパケット（自発）がTXInterfaceから出て行く場合でも
headroom/extended headroomは関係してくるのでしょうか。

質問③ Packet Forwarding : CEF

*********************資料抜粋*********************
priority queue に格納されたパケットは interface queue が一杯の場合は headroom
を使用可能です。headroom が一杯の場合にも一部のパケットは extended headroom を 使用可能です。まとめると以下のようになります。
**************************************************

「RX ring」「priority queue」「Particle（Interface  Buffer）」「interface queue」「TX ring」
の位置関係が把握ができずにいます。何かよい資料はございますでしょうか。
※特に（priority queue に格納されたパケットは interface queue・・）の部分

以上、宜しくお願い致します。

[t.higashimura]

Kondoさん

担当エキスパートではないですが、私の知っている範囲で返信させていただきます。
高尾様、間違いがあればご指摘ください。

>質問① IGP Helloパケット受信の場合
>前提として、
>・headroom/extended headroomが一杯にはならない環境
>・データパケット=IP Precedence(0～5）
>データパケットが大量にRXInterface入って来た場合でも、輻輳によりIGP Hello
>が破棄されることはないのでしょうか？また遅延に関してはどうなのでしょうか？

Input Queue に入ってくるパケットの種類によると思います。例えば、限りなく OSPF Hello に偽装されたパケットを大量に受けた場合、SPD でも保護しきれません。遅延については基本 Input queue 及び SPD で処理されるのは CPU 向けトラフィックなので、そこまで気にする必要はないのと queue の深さもそんなに深くないので気にするレベルではないかと思います。

>質問② IGP Helloパケット送信の場合

SPD は入力パケットに対する保護なので、送信は関係ないはずです。

>質問③ Packet Forwarding : CEF

>*********************資料抜粋*********************
>priority queue に格納されたパケットは interface queue が一杯の場合は headroom
>を使用可能です。headroom が一杯の場合にも一部のパケットは extended headroom を 使用可能です。まとめると以下のようになります。
>**************************************************

>「RX ring」「priority queue」「Particle（Interface  Buffer）」「interface queue」「TX ring」
>の位置関係が把握ができずにいます。何かよい資料はございますでしょうか。
>※特に（priority queue に格納されたパケットは interface queue・・）の部分

気にされている全てを網羅していない気もしますが、下記ドキュメントが分かりやすいかと思います。

• 選択的 パケット 廃棄（SPD）の理解と利用

ご参考になれば幸いです。

t.higashimura

[Ryota Takao]

東村さん、

代わりに回答頂きありがとうございました。問題ありません。

お手数をおかけしました。

高尾