高尾 竜太 （Ryota Takao）
Cisco Integrated Services Router (ISR)G1/G2
トラブル シューティング ～High CPU & Packet Drop～
シスコサポートコミュニティ
Live Expert Webcast
テクニカルアシスタンスセンター, テクニカルサービス 2015年4月21日
ご参加ありがとうございます
本日の資料はこちらからダウンロードいただけます
http://supportforums.cisco.com/ja/community/5356/webcast
直接ダウンロードする場合はこちら
オーディオ ブロードキャストについて
[Audio Broadcast（オーディオ ブロードキャスト）] ウィン ドウが自動的に表示され、コンピュータのスピーカーか ら音声が流れます [Audio Broadcast（オーディオ ブロードキャスト）] ウィン ドウが表示されない場合は、[Communicate（コミュニ ケート）] メニューから [Audio Broadcast（オーディオ ブ ロードキャスト）] を選択します イベントが開始されると自動的に音声が流れ始めます 音声接続に関する詳細はこちらをご参照ください。解決 しない場合は、QA ウィンドウよりお知らせください。 https://supportforums.cisco.com/ja/document/82876ご質問方法
Webcast 中のご質問は全て
画面右側のQAウィンドウより
’All Panelist’ 宛に
Expert Speaker
高尾 竜太 (Ryota Takao)
テクニカルアシスタンスセンター, テクニカルサービス
カスタマー サポート エンジニア
Cisco Integrated Services Router (ISR)
G1/G2 トラブル シューティング
アジェンダ
•
Packet Forwarding
•
Process Level と Interrupt Level
•
SPD(Selective Packet Discard)
•
High CPU について
•
High CPU の Troubleshooting に使用するコマンドの紹介
•
High CPU : Case Study
•
High CPU : ログの取得方法
•
Packet Drop について
•
Packet Drop のTroubleshooting に使用するコマンド
•
Packet Drop : Case Study
Packet Forwarding
現在の転送方式は以下の2つです。
•
CEF(Cisco Express Forwarding)
•
Process Switching
以前は Fast Switching というものもありましたが、12.4(20)T から
CEF の実装変更(CSSR)に伴い Fast Switching は廃止されています。
Cisco Express Forwarding Enhancements: Removal of IP Fast
Switching and Introduction of CLI Changes
次のページ以降で上記２つの転送方式について解説します。
＊ASIC/TCAM を使った転送ではない点に注意してください。
この説明は以前
「Cisco IOS Router のMemory/Buffer に関するTroubleshooting 方法の紹介」 でも行っているので 説明は簡略化させて頂きます。
資料ダウンロード : https://supportforums.cisco.com/docs/DOC-37376
© 2012 Cisco and/or its affiliates. All rights reserved. 10
Packet Forwarding : CEF
256 children 255 0 256 children 255 0 256 children 255 0 256 children 255 0 172 16 1 root
Lookup: 172.16.1.1
CEF ではあらかじめFIB(Forwarding Information Base)を作成し、
転送先の情報（送信InterfaceやL2 header）をあらかじめ cache しておきます。 1
Rx Interface CPU I/O Memory Tx Interface Rx Ring Tx Ring FIB(Forwarding Information Base) 1 2 3 4 5 6 7 In Out
Packet Forwarding : CEF
Particle
Packet Forwarding :CEF
1. Rx Interface にパケットが到着すると Rx Ring に示されている番地にデータを格
納します。(Rx Ring が持つのはデータの番地です。) パケットが格納される先は Particle です。
2. Rx Interface が Rx Interrupt で CPU に Packet の到着を通知する。 3. CPU が Packet の Header 部分を読む。
4. FIB を確認し CEF で転送可能なエントリであれば、FIB の情報を元に、次の宛先
と出力先の Interface を決定する。
5. 4. で得た情報を元に CPU が Packet の L2 部分の Header(MAC等) を書きかえ
る。
6. CPU が出力先の Tx Ring に Particle の番地を登録する。
7. Tx Ring に パケットデータの番地 が登録されると Interface が Particle からデー
タを読み込み転送をおこなう。
Rx Interface CPU I/O Memory Tx Interface Rx Ring Tx Ring 4 5 6 10 In Out
Packet Forwarding : Process Switching
Public Buffer IP Input Queue 途中までは処理はCEFと同じなので, 1～3 は図から割愛しています。 ip_input 7 RIB ARP cache 8 9 11 12 FIB(Forwarding Information Base) Particle (Interface Buffer)
Packet Forwarding : Process Switching
1.
Rx Interface にパケットが到着すると Rx Ring に示されている番地に
データを格納します。(Rx Ring が持つのはデータの番地です。) パケット
が格納される先は Particle です。
2.
Rx Interface が Rx Interrupt で CPU に Packet の到着を通知する。
3.
CPU が Packet の Header 部分を読む。
4.
FIB を確認したが CEF で転送が出来ない。
• CEF で転送が出来ないパケット→具体的には show ip cef で receive や punt と表示さ
れるもの（そのルータ宛のパケットやCEFでの転送がサポートされていない）。もしくは、 CEFのエントリがない。
5.
Particle から Public Buffer へパケットがコピーされる。Process
Switching Path へと処理が移る。
6.
パケットデータの 番地 が適切なプロセスの input queue へと渡される。
Packet Forwarding : Process Switching
7. 宛先IPアドレスへの経路がRIBにあるかどうか確認します。あればネクスト
ホップのアドレスをRIBから得る。
8. ARP cache を参照してネクストホップへのMAC Addressを得る。
9. 8で得た情報を元に Packet の L2 部分の Header(MAC等) を書きかえる。
10. Tx Ring にパケットデータの番地が渡される。
11. Tx Ring にパケットデータの番地が登録されると Interface が Public Buffer
からデータを読み込み転送をおこなう。
Packet Forwarding : まとめ
■基本的にパケットは CEF で転送処理される。
■CEF で処理出来ないパケットは show ip cef で receive や punt と表示されるものや CEF のエントリがないもの。
具体的には...
・そのルータ宛のパケット
・CEFでの転送がサポートされていないパケット ・CEFのエントリがないもの
Process LevelとInterrupt Level
• IOSが実行する処理は、その起動の形態からProcess LevelとInterrupt Level に分けることができる。 • Process Levelの処理は、機能毎にそれを担当するProcessというものが存在し、 優先順位やEventの有無などに従って、Schedulerにより順次呼び出される。 • Process Levelは、比較的、緊急度の低い処理を担当する。また、比較的、長時 間の処理を行うこともある。 • Interrupt Levelの処理は、割り込みというEventの種類毎にそれを実行する Interrupt Handlerというものが存在し、割り込みが発生する都度、Dispatcherに より呼び出される。 • Interrupt Levelは、緊急度の高い処理を担当する。また、その処理は、短時間 で終了する必要がある。
Process Level
• show processesでRouter上に存在する Process Levelの処理がprocessとして表示される。
Router# show processes
CPU utilization for five seconds: 11%/8%; one minute: 9%; five minutes: 10% PID QTy PC Runtime (ms) Invoked uSecs Stacks TTY Process
1 Cwe 32C386C4 0 14 0 5160/6000 0 Chunk Manager 2 Csp 30DEC798 764 157324 4 2404/3000 0 Load Meter 3 Mwe 302377A8 4 1 400023024/24000 0 LICENSE AGENT 4 Mwe 34FECC7C 0 1 023316/24000 0 EDDRI_MAIN 5 Mwe 32C9B804 0 1 0 5756/6000 0 RO Notify Timers 6 Lst 30016B40 835740 132934 6286 5196/6000 0 Check heaps 7 Cwe 32C532C8 2772 13548 204 5232/6000 0 Pool Manager 8 Mwe 32C53238 0 1 0 5656/6000 0 DiscardQ Backgro 9 Mst 3180A4D4 0 2 0 5272/6000 0 Timers 10 Mwe 3186D438 0 30 0 2716/3000 0 WATCH_AFS 11 Mwe 3020BE78 0 1 0 5652/6000 0 License Client N --- snip ---
Interrupt Level
Router#show stacks --- snip ---
Interrupt level stacks:
Level Called Unused/Size Name
1 0 9000/9000 i2c console redirect host Interrupt 4 140270 8256/9000 Host/PCI Bridge Interrupt
5 1961421 8908/9000 PQII PRO Timer
6 2360 8880/9000 16552 Con/Aux Interrupt 7 491651 8872/9000 M8300_TIMER_INTERRUPT
Process と Interrupt の CPU 使用率の確認
Process と Interrupt の CPU 使用率は以下のコマンド等で確認可能です。 -show processes
-show processes cpu
-show processes cpu sorted
Router#show processes cpu sorted
CPU utilization for five seconds: 7%/1%; one minute: 2%; five minutes: 2% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
168 44908 420747 106 4.00% 0.57% 0.17% 0 IP Input 6 92064 14351 6415 1.03% 0.15% 0.11% 0 Check heaps
7%/1% Total(Process + Interrupt) の CPU 使用率 :
/ の左側(この例では7%)
Interrupt の合計の CPU 使用率 : / の右側(この例では1%)
Process の合計の CPU 使用率:
SPD(Selective Packet Discard)
IOS ではルータ宛ての重要なパケットを保護するために SPD(Selective Packet Discard) という機能が default で有効になっていて ISR ルータの default の入力 queue は 75 です が、重要なパケットのために headroom(default 100) と extended headroom(default 75) が用意されています。
＜SPD の動作＞
ルータ宛てのパケットを受信すると IP Precedence の値によって、パケットは normal queue(IP Precedence 0 - 5) または priority queue(IP Precedence 6 or 7) に格納され、 normal queue に格納された場合は SPD check が行われます。まとめると以下のように なります。
IP Precedence queue SPD check
0 - 5 normal queue 有り
SPD(Selective Packet Discard)
SPD には minimum threshold, maximum threshold があり、SPD check が行われた際 の normal queue size と minimum threshold, maximum threshold の関係によって動作 が異なります。
なお、minimum threshold, maximum threshold は以下のコマンドで設定を行います。
ISR ルータは default では以下のコマンドが設定されています。show run all で確認可。
normal queue size と min, max の関係 mode 動作
normal queue size <= minimum NORMAL DROP なし
minimum <= normal queue size <= maximum RANDOM DROP パケットをランダムに DROP maximum <= normal queue size FULL DROP 全てのパケットを DROP
ip spd queue threshold minimum <min> maximum <max>
SPD(Selective Packet Discard)
priority queue に格納されたパケットは interface queue が一杯の場合は headroom を 使用可能です。headroom が一杯の場合にも一部のパケットは extended headroom を 使用可能です。まとめると以下のようになります。
queue packet の種類
head room BGP, IGP, IP Precedence 6 or 7 など extended head room IGP など
spd headroom <size>
spd extended-headroom <size>
headroom の size の設定は以下のコマンドで行います。
SPD(Selective Packet Discard)
aggressive mode:
ip spd mode aggressive
以下を設定すると aggressive mode となり、RANDOM DROP 時の動作が変わります。
aggressive mode では RANDOM DROP の際に不正なパケットを全て DROP する ようになります。ここでの不正なパケットとは IP header の version, IHL, Total Length, Header Checksum のフィールドに問題があるパケットを指します。
SPD(Selective Packet Discard)
show コマンド
Router#show ip spd Current mode: normal.
Queue min/max thresholds: 73/74, Headroom: 100, Extended Headroom: 75 IP normal queue: 41, priority queue: 35.
SPD special drop mode: none
Current mode: 現在の mode
Queue min/max thresholds: min/max threshold の値 Headroom: Headroom の queue
Extended Headroom: Extended Headroom の queue
SPD(Selective Packet Discard)
IP Precedence
SPD check
NORMAL RANDOM
DROP FULL DROP
normal queue priority queue Receive Packet
IP Precedence = 6, 7 IP Precedence = 0 ～ 5
normal queue size <= minmum
minimum <= normal queue size <= maximum
投票質問
質問 : これまで説明したセクションで理解
が不足していた感じた部分はありますか？
複数あれば一番理解が不足していると感
じたものを選んでください。
A) Packet Forwarding
B) Process Level と Interrupt Level
C) SPD(Selective Packet Discard)
D) 特になし
•
Traffic 量が多い
•
ルータ宛てのパケットを大量に受信している。
•
何らかの理由で CPU リソースを使うような処理が大
量に発生している。
•
IOS の不具合
High CPU について
High CPU は以下のようなことが原因で発生しますが、TAC に問い合わせがある事象の 多くは IOS の不具合が原因ではないです。
IOS の不具合を疑う前に、まずはそれ以外の原因で High CPU になっていないか確認を してください。
High CPU の Troubleshooting に使用する
コマンドの紹介と解説
High CPU の Troubleshooting に使用する
コマンドの紹介
High CPU の Troubleshooting は主に以下のコマンド等を複数回取得するなどして Troubleshooting を行います。
show processes cpu sorted show stacks
show stacks <PID> show interfaces
show interfaces switching show controllers
show ip traffic
show ip traffic interface <Interface> show ip spd
show platform
show platform interrupt * ISR G2 のみ show tech
show log
show processes cpu sorted
Router#show processes cpu sorted
CPU utilization for five seconds: 6%/1%; one minute: 2%; five minutes: 1% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
168 45952 429240 107 4.00% 0.36% 0.12% 0 IP Input 118 693096 434041 1596 0.95% 0.83% 0.83% 0 COLLECT STAT COU 131 4 11138680 0 0.15% 0.12% 0.13% 0 Ethernet Msec Ti 302 12 1353621 0 0.07% 0.02% 0.02% 0 MMA DB TIMER 244 88 86684 1 0.07% 0.00% 0.00% 0 ADJ background 35 138856 1191753 116 0.07% 0.12% 0.13% 0 ARP Input
CPU utilization for five seconds :
最後の 5 秒間の CPU 使用率。1 番目の数字はTotal CPU 使用率を示し、 2 番目の数字は、割り込みレベルで使われた CPU 使用率を示します。 one minute : 最後の 1 分間の CPU 使用率
five minutes : 最後の 5 分間の CPU 使用率 PID : プロセスID Runtime（ms） : プロセスが使用した CPU 時間（m秒） Invoked : プロセスが呼び出された回数 uSecs : 各プロセスの起動時間（マイクロ秒） 5Sec : 最後の 5 秒間のタスクによる CPU 使用率 1Min : 最後の 1 分間のタスクによる CPU 使用率 5Min : 最後の 5 分間のタスクによる CPU 使用率 TTY : プロセスを制御している端末 Process : プロセスの名前
show stacks
Router#show stacks --- snip ---
Interrupt level stacks:
Level Called Unused/Size Name
1 0 9000/9000 i2c console redirect host Interrupt 4 7867626 8200/9000 Host/PCI Bridge Interrupt
5 95953452 8908/9000 PQII PRO Timer
6 7101 8832/9000 16552 Con/Aux Interrupt 7 24012781 8872/9000 M8300_TIMER_INTERRUPT
Level : Interrupt の Level (高い方が優先) Called : 呼ばれた回数
Unused/Size : 未使用のstack/stack の size Name : Interrupt の種類
show stacks <PID>
Router#show processes cpu sorted
CPU utilization for five seconds: 45%/6%; one minute: 43%; five minutes: 42% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 35 223136 1907823 116 35.15% 0.21% 0.19% 0 ARP Input --- snip --- Process : PID: プロセス名 FP : Frame Pointer RA : Return Address Router#show stacks 35
Load for five secs: 1%/0%; one minute: 2%; five minutes: 2%
Time source is hardware calendar, *04:01:35.238 UTC Mon Apr 13 2015 Process 35: ARP Input
Stack segment 0x8A19E1F4 - 0x8A19F964 FP: 0x8A19F920, RA: 0x8006D6FC FP: 0x8A19F950, RA: 0x821F13D0 FP: 0x8A19F958, RA: 0x81B22094 FP: 0x0, RA: 0x81B09350 RA をデコードすることでどういった処理が行われていたのかの処理の流れがわかります。 残念ながら外部の方がデコードを行うことは出来ません。
show interfaces
Router#show interfaces FastEthernet 8 FastEthernet8 is up, line protocol is up
Hardware is PQII_PRO_UEC, address is e05f.b990.998c (bia e05f.b990.998c) Internet address is 192.168.1.1/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:53, output 00:00:00, output hang never Last clearing of "show interface" counters never
Input queue: 0/75/18461/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 385001 packets input, 44431515 bytes
Received 2656 broadcasts (0 IP multicasts) 3055 runts, 0 giants, 8058 throttles
6334 input errors, 0 CRC, 0 frame, 6334 overrun, 0 ignored 0 watchdog
0 input packets with dribble condition detected 479341 packets output, 52212376 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 186 unknown protocol drops
0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier
show interfaces
Hardware is : Phy の種類 address is : MAC Address
Internet address is : IP Address MTU : MTU size
BW : Bandwidth
DLY : Delay(遅延の値) マイクロsec
reliability : インターフェスの信頼性。「255/255」が最も高く、「0/255」が最も低い。
txload/rxload : Interfaceの送受信の負荷。 。「255/255」が最も高く、「0/255」が最も低い。 Keepalive set : keep alive が有効かどうかとその間隔
Full-duplex : duplex が全二重であることを示す。 100Mb/s : speed が 100Mbps であることを示す。 100BaseTX/FX : Interface の規格
ARP type : ARP type を示す。
ARP Time : ARP のキャッシュ時間。この例では default の4時間が表示されている。 Last input : パケットを最後に受信してからの経過時間。
output : パケットを最後に送信してからの経過時間。
show interfaces
Input queue :
size : Input queue の格納されているパケットの数 max queue : の最大サイズ
drops : 破棄されたパケット数
flushes : SPD によって normal queue パケットが drop した場合 Total output drops : 送信出来なかったパケット数
Queueing strategy : QoS の方式
Output queue : Output queue に格納されている数/Qutput queue の最大サイズ 5 minute input/output : 5分間平均の送受信bps, 送受信 pps
packets input, bytes : 正常に受信したパケット数と合計のバイト数
Received broadcasts : 正常に受信したマルチキャスト/ブロードキャストの合計数 runts : 最小パケットサイズより小さいために破棄されたパケット数
giants : 最大パケットサイズより大きいために破棄されたパケット数 throttles : バッファやCPUのリソースが不足した際にカウントされる。 input errors : CRC, frame, overrun, ignored のエラーカウントの合計 CRC : CRC(Cyclic Redundancy Check) error が検出されたことを示す。
ケーブル不良、対向のポート不良、自身のポート不良など基本的には Hardware の 問題によってカウントされう。
show interfaces
frame : CRC error やオクテットの数に誤りがあるパケットを受信した場合にカウント。 overrun : ルータの処理能力を超え interface バッファにパケットを渡せない場合
ignored : 新しいパケットを受け入れる空きバッファがないときにカウント watchdog : 2048byteよりも大きなパケットを受信した場合にカウント
input packets with dribble condition detected : frame 長がわずかに長い場合にカウント される。破棄はしない。
packets output, byte :送信したパケット数と合計のバイト数
underruns : Packet を出力するために十分な速度で Packet がバッファから取得出来 なかった場合カウントされる
output errors : パケットを送信する際にエラーが発生した場合にカウント
collisions :パケットを送信する際にコリジョンが発生し、再送された場合にカウント interface resets : interface reset が起きた場合にカウント
unknown protocol drops :認識できないプロトコルのパケットを検出した場合にカウント late collision : late collision を検出した場合にカウント
deferred : media の負荷が高いなどの場合に、それがが解消されるのを待ってからフレー ムを送信した際にカウント
show interfaces
lost carrier : 送信中にキャリアが失われた場合にカウント。 no carrier : 送信中にキャリアが検知されない場合にカウント。
output buffer failures : インターフェースからパケットを送出する際のバッファ割り当てに失 敗した場合にカウント
output buffers swapped : インターフェースからパケットを送出する際のバッファ割り当てを スワップした時にカウント
show interfaces switching
Router#show interfaces switching--- snip --- FastEthernet8 --- snip ---
Protocol IP
Switching path Pkts In Chars In Pkts Out Chars Out Process 37787369 839489278 535881 54958238 Cache misses 0 - - - Fast 1110253396 1573716918 0 0 Auton/SSE 0 0 0 0 Protocol ARP
Switching path Pkts In Chars In Pkts Out Chars Out Process 20 1200 194 11640 Cache misses 0 - - - Fast 0 0 0 0 Auton/SSE 0 0 0 0 Protocol CDP
Switching path Pkts In Chars In Pkts Out Chars Out Process 2468 927968 2468 924528 Cache misses 0 - - - Fast 0 0 0 0 Auton/SSE 0 0 0 0 --- snip --- Process : Process Switching された パケット数 Cache misses: 現在はカウントされることはありま せん。 Fast: CEF で転送されたパケット数 Auton/SSE: Forwarding 用の ASIC をもつよう な Platform で CEF 転送された パケット数
show ip traffic
Router#show ip traffic IP statistics:
Rcvd: 1102811 total, 610336 local destination
0 format errors, 0 checksum errors, 441138 bad hop count 0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 73803 with options Opts: 0 end, 0 nop, 0 basic security, 0 loose source route 0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 73803 alert, 0 cipso, 0 ump 0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble 0 fragmented, 0 fragments, 0 couldn't fragment Bcast: 349391 received, 0 sent
Mcast: 0 received, 16452 sent
Sent: 476138 generated, 0 forwarded
Drop: 2 encapsulation failed, 0 unresolved, 0 no adjacency 0 no route, 0 unicast RPF, 0 forced drop
0 options denied
Drop: 0 packets with source IP address zero
Drop: 0 packets with internal loop back IP address 50495 physical broadcast
show ip traffic
ICMP statistics:
Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 664 unreachable 379373 echo, 8 echo reply, 0 mask requests, 0 mask replies, 0 quench 0 parameter, 0 timestamp, 0 timestamp replies, 0 info request, 0 other 0 irdp solicitations, 0 irdp advertisements
0 time exceeded, 0 info replies
Sent: 0 redirects, 0 unreachable, 39779 echo, 379373 echo reply
0 mask requests, 0 mask replies, 0 quench, 0 timestamp, 0 timestamp replies 0 info reply, 0 time exceeded, 0 parameter problem
0 irdp solicitations, 0 irdp advertisements UDP statistics:
Rcvd: 228006 total, 0 checksum errors, 228006 no port 0 finput Sent: 16452 total, 0 forwarded broadcasts
TCP statistics:
Rcvd: 2285 total, 0 checksum errors, 0 no port Sent: 40536 total
BGP statistics:
Rcvd: 0 total, 0 opens, 0 notifications, 0 updates 0 keepalives, 0 route-refresh, 0 unrecognized Sent: 0 total, 0 opens, 0 notifications, 0 updates 0 keepalives, 0 route-refresh
EIGRP-IPv4 statistics: Rcvd: 0 total
show ip traffic
PIMv2 statistics: Sent/Received
Total: 0/0, 0 checksum errors, 0 format errors
Registers: 0/0 (0 non-rp, 0 non-sm-group), Register Stops: 0/0, Hellos: 0/0 Join/Prunes: 0/0, Asserts: 0/0, grafts: 0/0
Bootstraps: 0/0, Candidate_RP_Advertisements: 0/0 Queue drops: 0
State-Refresh: 0/0
IGMP statistics: Sent/Received
Total: 0/0, Format errors: 0/0, Checksum errors: 0/0 Host Queries: 0/0, Host Reports: 0/0, Host Leaves: 0/0 DVMRP: 0/0, PIM: 0/0
Queue drops: 0
OSPF statistics:
Last clearing of OSPF traffic counters never Rcvd: 0 total, 0 checksum errors
0 hello, 0 database desc, 0 link state req 0 link state updates, 0 link state acks Sent: 0 total
0 hello, 0 database desc, 0 link state req 0 link state updates, 0 link state acks ARP statistics:
Rcvd: 1814611 requests, 308365 replies, 659 reverse, 0 other Sent: 1843 requests, 4758 replies (0 proxy), 0 reverse
CPU Profile
show processes cpu sorted や show stacks より process や interrupt の情報を 得られますが、詳細はわかりません。process や interrupt でどういった処理が行われ ているのかの詳細を確認するためにはCPU Profile を実施する必要があります。
＊CPU Profile を実施すると一時的に CPU 使用率が上昇します。 ご注意ください。
CPU Profile は以下の手順で実施してください。
1. show region で IOS がロードされたアドレス空間を確認します。 main:text が IOS がロードされたアドレス空間です。
main:text の Start と End の値を確認してください。
Router#show region
Load for five secs: 98%/48%; one minute: 98%; five minutes: 98% Time source is hardware calendar, *00:04:31.647 UTC Wed Apr 15 2015 Region Manager:
Start End Size(b) Class Media Name 0x1E700000 0x1FFFFFFF 26214400 Iomem R/W iomem 0x80000000 0x9E6FFFFF 510656512 Local R/W main
0x80020110 0x86136333 101802532 IText R/O main:text 0x86136334 0x8878576F 40170556 IData R/W main:data 0x88785770 0x89326A2F 12194496 IBss R/W main:bss 0x89326A30 0x9E6FFFFF 356357584 Local R/W main:heap
CPU Profile
2. CPU Profile の設定 1.で確認したアドレス情報を元に CPU Profile の設定を行います。 0x は不要です。 Router(config)#profile 80020110 86136333 4 3. CPU Profile の取得開始profile start で CPU Profile の取得を開始します。
隠しコマンドのためご注意ください。TABでの補完が効きません。
Router#profile start
4. 1分ほどたったら profile 取得終了
profile stop で CPU Profile の取得を終了します。
CPU Profile
5. 以下のコマンドを取得
Router#show processes cpu sorted Router#show profile terse
6. Log 取得後、情報をクリアします
Router#clear profile
7. 3 ～ 6 の step を複数回繰り返します。 8. 設定をクリアします。
CPU Profile
Router#show profile terse PROF 80020110 86136333 4 PROFSKIP 80024F30 0 0 26 0 16 111 0 36 0 16 0 48 0 20 18 17 14 18 18 41 40 0 0 0 0 19 89 17 18 0 22 25 26 19 20 0 0 0 0 0 PROFSKIP 80025810 0 0 0 10 4 0 22 11 8 7 9 18 18 14 0 0 PROFSKIP 8002F330 0 0 0 0 0 1 0 0 PROFSKIP 80033A70 0 0 1 0 0 0 0 0 PROFSKIP 8003ED30 0 0 0 0 0 1 0 0 --- snip ---
show profile terse では
main:text のどの領域が使用されたかの 統計を取っています。
decode をすることで、profile start から profile stop までの間にどのような処理が 多く発生していたかがわかります。
残念ながら外部の方は decode を実施する ことは出来ませんのでTACへの問い合わせ時 にログを送付頂ければと思います。
IP Input の CPU 使用率が高い場合
IP Input の CPU 使用率が高くなるのは CEF で転送出来ないパケットを受信した場合です。 CEFで転送出来ないパケットは以下のものです。 ・そのルータ宛てのパケット ・CEFでの転送がサポートされていない ・CEFのエントリがないもの 今日においては CEF での転送がサポートされていないようなパケットは殆どありません。 また、CEF で転送すべきパケットをプロセススイッチしてしまうような不具合も 殆どなくなりました。またCEFのエントリがないパケットについては一度転送を行えばエント リが作成されます。 そのため IP Input の CPU 使用率が上昇している殆どのケースはそのルータ宛てのパ ケットを受信することによって引き起こされます。
ルータ宛てのパケットを大量に受信している場合
Router#show processes cpu sorted
Load for five secs: 98%/48%; one minute: 59%; five minutes: 25% Time source is hardware calendar, *23:17:24.287 UTC Tue Apr 14 2015
CPU utilization for five seconds: 98%/48%; one minute: 59%; five minutes: 25% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
168 219484 929335 236 47.79% 26.51% 7.21% 0 IP Input 118 2370396 1483834 1597 0.63% 0.79% 0.76% 0 COLLECT STAT COU 13 163772 4940 33152 0.55% 0.07% 0.05% 0 Licensing Auto U 55 8092 132473 61 0.47% 0.29% 0.08% 0 Net Background --- snip ---
Router#show interfaces FastEthernet 8 FastEthernet8 is up, line protocol is up --- snip ---
Input queue: 0/75/18461/0 (size/max/drops/flushes); Total output drops: 0 --- snip ---
3055 runts, 0 giants, 8058 throttles
6334 input errors, 0 CRC, 0 frame, 6334 overrun, 0 ignored --- snip ---
ルータ宛のパケットを多く受信している場合、IP パケットであれば
IP Input の CPU 使用率が上昇し、drops, flushes, throttles, input errors, overrun などのカウンタが上昇します。（counter は IP パケットでない場合も上昇します。）
ルータ宛てのパケットを大量に受信している場合
事象発生中にパケットのキャプチャや以下のコマンドを複数回取得し、
どういったパケットを大量に受信しているのかを特定し troubleshooting を行ってく ださい。
show processes cpu sorted show buffer
show buffer all dump show ip traffic
show ip traffic interface <Interface> show ip spd
show interfaces
show interfaces switching
また可能であれば、前述した CPU Profile も取得してください。
解決策としては基本的にはルータ宛ての Traffic を減らしていただくしかありませ ん。もしくは CoPP 等で rate を制限するのも対応策になるかと思います。
Fragment Packet を受信していると show ip traffic の reassembled がカウントされます。 Fragment Packet を受信するとパケットを組み立てるため pacektは CEFではなく、IP Input によって process switch されます。
reassemble 処理は多くの CPU 時間を消費し、かつ、後続 fragmentを待つ packetが Huge buffer (18024 byte)に格納されるため多くの Public Buffer を消費します。
その結果、CPU 使用率が上昇し になったり Public Buffer が枯渇し Packet Drop が発生し ます
Router#show ip traffic --- snip ---
Frags: 32097 reassembled, 0 timeouts, 0 couldn't reassemble <対処方法>
DF bit 付きの Ping 等を使用して End-to-End で MTU を確認し MTU の調整を行ってくだ さい。＊そのルータだけでMTUを調整しても意味がありません。
reassembled が上昇している原因となるパケットを投げている機器は、対向もしくはその先 にいる機器です。reassembled の上昇している機器でできることは、正しい MTU が設定さ れているか確認し調整することと、事象発生時に show buffer pool huge dump を取得して どのようなパケットが fragment されているか確認することです。
Router#show buffers pool huge dump --- snip ---
source: 1.1.1.1, destination: 2.2.2.2, id: 0xE4E0, ttl: 251, prot: 115 06375588: AFACEFAD 00000000 00000000 00000000 /,o-... 06375598: 00000000 00000000 00000000 00000000 ... 063755A8: 00000000 00000000 00000000 00000000 ... 063755B8: 00000000 00000000 00000000 00000000 ... 063755C8: 00000000 00000000 00000000 00000000 ... 063755D8: 00000000 00000000 45000028 E4E00000 ...E..(d`.. 063755E8: FB73B468 01010101 02020202 FCE01E49 {s4h...|`.I 063755F8: 8843E160 EA5868EF BDD18390 08004500 *;L.".*;L...E. 06375608: 05DC7134 2000FF01 10EA0A00 00010A00 .¥q4 ....j... 06375618: 00020800 00284668 00000000 00000028 ...(Fh...(
show buffers pool <pool name> dump は Buffer に格納されたパケットの dump ですので、 出力を解析することでパケットの詳細がわかります。（IPSec等で暗号化されていなければ）
IP header(20byte)
45000028 E4E00000 FB73B468 01010101 02020202 -> Source 1.1.1.1 Destination 2.2.2.2
L2TPv3 header(この例だと4byte)
FCE01E49
EtherⅡ header(14byte) (FCS 4byte は除く)
8843E160 EA5868EF BDD18390 0800
IP header(20byte)
4500 05DC7134 2000FF01 10EA0A00 00010A00 0002 -> Source 10.0.0.1 Destination 10.0.0.2
＜デコードのコツ＞
45 という hex値がある場合、IP header の可能性を疑ってください。(version + header length) 0800 という hex値がある場合、EtherⅡheader の type である可能性を疑ってください。
080045 という hex値がある場合、EtherⅡheader の type + IP header の version と header length の可能性が高いです。
前のページの show buffer pool huge dump の以下の部分に注目してください。
063755D8: 00000000 00000000 45000028 E4E00000 ...E..(d`.. 063755E8: FB73B468 01010101 02020202 FCE01E49 {s4h...|`.I 063755F8: 8843E160 EA5868EF BDD18390 08004500 *;L.".*;L...E. 06375608: 05DC7134 2000FF01 10EA0A00 00010A00 .¥q4 ....j... 06375618: 00020800 00284668 00000000 00000028 ...(Fh...(
next-hop interface のみを記載した static route
を使用している場合
Router(config)#ip route 0.0.0.0 0.0.0.0 FastEthernet 8
以下のような next-hop に interface のみを記載した static route を記載することは 特別な理由が無い限り避けた方が良いです。
next-hop に interface のみを記載した static route を記載すると以下のように connected route と認識されるという特徴があります。
Router#show ip route --- snip ---
S* 0.0.0.0/0 is directly connected, FastEthernet8 --- snip ---
interface に設定されたアドレス・サブネットにかかわらず、通信が発生した際に レイヤ 2 アドレスの解決を試みるため、パケットの宛先アドレスに対する ARP を送信します。 Fa8(192.168.1.1/24) そのため、Router と同じサブネットではない宛先へのパケットでも、ARP を送信します。 その結果、ARP を大量に送信することになり、CPU 使用率が高騰する場合があります。 パケットの宛先が同じサブネットでない 100.100.100.100 などでも ARP を送信 ARP
next-hop interface のみを記載した static route
を使用している場合
Router(config)#ip route 0.0.0.0 0.0.0.0 FastEthernet 8 192.168.1.2 Router#show ip route
--- snip ---
S* 0.0.0.0/0 [1/0] via 192.168.1.2, FastEthernet8 --- snip ---
以下のように next-hop に interface と address を併記して頂ければ （もしくは next-hop に IP address のみを記載）
connected route として認識されませんのでルータと異なるサブネットに対し ARP を送信するような動作はしなくなります。
Static route の install 基準と使用上の注意
https://supportforums.cisco.com/ja/document/97156
next-hop interface のみを記載した static route
を使用している場合
static route の next-hop には interface と address を併記する癖をつけておくと 良いと思います。
以下の出力のように SNMP Engine の CPU 使用率が高い、という お問い合わせを度々頂きますが、 SNMP パケットを受け CPU時間を多く使用する ような処理が発生している場合や、ルータ宛てに多くの SNMP パケットを受信して いて発生していることが多く、IOS の不具合ではなくルータとしては期待された 動作をしていることが多々あります。
SNMP Engine のCPU使用率が高い
Router#show processes cpu sorted
CPU utilization for five seconds: 69%/28%; one minute: 46%; five minutes: 49% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
154 38964 40846 953 14.87% 6.32% 6.09% 0 IP SNMP 260 182248 20639 8830 11.67% 21.97% 31.39% 0 SNMP ENGINE
＜ SNMP パケットを受けCPU時間を多く使用するような処理が発生している場合＞ SNMP パケットを受けCPU時間を多く使用るような処理が発生し、CPU 使用率が 高騰する場合があります。 代表的な例としては例えばルーティングテーブルが大きい状態で、SNMP を使用して ルータからルーティング情報を取得するような場合です。 このような場合は GetRequest を大量に受信していなくても CPU 使用率が高騰する 場合があります。 何らかの大きなテーブルから情報を取得するような場合は同様の事象が発生する可能 性がありますのでご注意ください。
SNMP Engine のCPU使用率が高い
＜大量のGetRequest を受けている場合＞
例えば server で以下のように OID を指定しない snmpwalk を指定した場合、 大量の GetRequest を送信します。
このような snmpwalk を実施した場合はルータは大量の SNMP GetRequest を 受信することになりますのでルータの CPU 使用率が高い状態になります。
そのため、OID を指定しない形での snmpwalk は特別な理由がない限り、使用を 避けてください。以下のように OID を指定した形で snmpwalk を実施頂き OID には OID Tree の下層のものを指定頂く形にして頂ければと思います。
SNMP Engine のCPU使用率が高い
$ snmpwalk -v <version> -c <COMMUNITY> <IP_ADDRESS> もしくは
$ snmpwalk -v <version> -c <COMMUNITY> <IP_ADDRESS> .
SNMP Engine のCPU使用率が高い
攻撃を受けている可能性もゼロではないので場合によっては 以下のような対策を取る必要があるかと思います。 ■特定しにくい community 名を使用する 記号、大小のアルファベット、数字を混ぜた community 名を使用することで攻撃を回避出来る可能性が高まります。 ■ACLを使用する以下のような ACL option を使用することで特定の SNMP Server からのパケットのみを許可することが可能です。 ACL を設定することで攻撃パケットを drop させることが可能です。
■VIEW を使用し一部の OID へのアクセスのみ許可する
以下のような設定を行い一部の OID 以外へのアクセスを禁止します。
この例では ifHCInUcastPkts と ifHCOutUcastPkts 以外へのアクセスを禁止しています。 Router(config)#snmp-server community <COMMUNITY> <rw or ro> ?
<1-99> Std IP accesslist allowing access with this community string <1300-1999> Expanded IP accesslist allowing access with this community string
WORD Access-list name
ipv6 Specify IPv6 Named Access-List <cr>
snmp-server view <VIEW_NAME> ifHCInUcastPkts included snmp-server view <VIEW_NAME> ifHCOutUcastPkts included
High CPU : ログの取得方法
CPU 使用率が上昇するような事象は一時的に発生し、すぐにおさまってしまう場合が多く 場合によってはログを取得することが難しいことがあります。
以下のような EEM を設定頂くことで CPU 使用率が上昇した場合に、自動的にログを 取得し、取得したログを flash に保存することが可能です。
process cpu threshold type total rising 90 interval 5 event manager environment pid1 0
event manager environment pid2 0 event manager environment pid3 0 event manager applet HIGH_CPU
event syslog pattern "%SYS-1-CPURISINGTHRESHOLD:" action 101 cli command "enable"
action 102 regexp "Top 3 processes¥(Pid/Util¥): +([0-9]+)/[0-9]+%, +([0-9]+)/[0-9]+%, +([0-9]+)/[0-9]+%" "$_syslog_msg" line pid1 pid2 pid3
action 103 cli command "show process $pid1 | append flash:High_CPU.txt" action 104 cli command "show stack $pid1 | append flash:High_CPU.txt" action 105 cli command "show process $pid2 | append flash:High_CPU.txt" action 107 cli command "show stack $pid2 | append flash:High_CPU.txt" action 108 cli command "show process $pid3 | append flash:High_CPU.txt" action 109 cli command "show stack $pid3 | append flash:High_CPU.txt" action 110 cli command "show interfaces | append flash:High_CPU.txt"
action 111 cli command "show interfaces switching | append flash:High_CPU.txt" action 112 cli command "show controllers | append flash:High_CPU.txt"
action 113 cli command "show ip traffic | append flash:High_CPU.txt"
action 114 cli command "show process $pid1 | append flash:High_CPU.txt" action 115 cli command "show stack $pid1 | append flash:High_CPU.txt" action 116 cli command "show process $pid2 | append flash:High_CPU.txt" action 117 cli command "show stack $pid2 | append flash:High_CPU.txt" action 118 cli command "show process $pid3 | append flash:High_CPU.txt" action 119 cli command "show stack $pid3 | append flash:High_CPU.txt" action 120 cli command "show interfaces | append flash:High_CPU.txt"
action 121 cli command "show interfaces switching | append flash:High_CPU.txt" action 122 cli command "show controllers | append flash:High_CPU.txt"
action 123 cli command "show ip traffic | append flash:High_CPU.txt"
action 124 cli command "show process $pid1 | append flash:High_CPU.txt" action 125 cli command "show stack $pid1 | append flash:High_CPU.txt" action 126 cli command "show process $pid2 | append flash:High_CPU.txt" action 127 cli command "show stack $pid2 | append flash:High_CPU.txt" action 128 cli command "show process $pid3 | append flash:High_CPU.txt" action 129 cli command "show stack $pid3 | append flash:High_CPU.txt" action 130 cli command "show interfaces | append flash:High_CPU.txt"
action 131 cli command "show interfaces switching | append flash:High_CPU.txt" action 132 cli command "show controllers | append flash:High_CPU.txt"
process cpu threshold type total rising 90 interval 5
Total の CPU 使用率が5秒以上 90% を超えたら以下のようなログを出力する。 Total/Interrupt のCPU使用率と TOP 3 の PID と CPU 使用率を出力
%SYS-1-CPURISINGTHRESHOLD: Threshold: Total CPU
Utilization(Total/Intr): 94%/44%, Top 3 processes(Pid/Util): 116/48%, 111/0%, 125/0%
event manager environment pid1 0
変数 pid1 を定義し初期値を 0 に設定 event manager applet HIGH_CPU
HIGH_CPU という名前で EEM を定義
event syslog pattern "%SYS-1-CPURISINGTHRESHOLD:"
%SYS-1-CPURISINGTHRESHOLD: というパターンの syslog があったら EEM が作動 action 101 cli command "enable"
action 102 regexp "Top 3 processes¥(Pid/Util¥): +([0-9]+)/[0-9]+%, +([0-9]+)/[0-9]+%, +([0-9]+)/[0-9]+%" "$_syslog_msg" line pid1 pid2 pid3
action 103 cli command "show process $pid1 | append flash:High_CPU.txt" show process XX を実行し結果を flash の High_CPU.txt に追記。 High_CPU.txt がなければファイルを作成
Total CPU Utilization(Total/Intr): NN%/NN%, Top 3 processes(Pid/Util): XX/48%, YY/0%, ZZ/0%
の XX を 変数 pid1 に格納、YY を変数 pid2 に格納、ZZ を変数 pid3 に格納。
ここで紹介した EEM は動作することを確認しておりますが、使用する前に念のため 問題なく動作するかご確認頂ければと思います。
投票質問
質問 : 過去にルータで発生したSoftware
の問題で一番多く経験しているのはどの
ような問題でしょうか？
A) High CPU
B) Packet Drop
C) Memory/Buffer 関連
D) その他
•
High CPU
•
Buffer や CPU などのリソース不足
•
性能限界
•
IOS の不具合
Packet Drop について
Packet Drop は以下のような要因で発生します。 様々なことが原因で Packet Drop は発生するので、色んな観点から調査を進める 必要があります。Packet Drop の Troubleshooting に使用
するコマンドの紹介と解説
Packet Drop の Troubleshooting に使用する
コマンドの紹介
Packet Drop の Troubleshooting は主に以下のコマンド等を複数回取得するなどして Troubleshooting を行います。
show processes cpu sorted show arp
show interfaces
show interfaces switching show controllers
show ip traffic
show ip traffic interface <Interface> show ip spd
show platform mgf controller ＊ISR G2 のみのコマンド show platform mgf statistics cpu ＊ISR G2 のみのコマンド show pci controller ＊ISR G1のみのコマンド
show pci hardware ＊ISR G2のみのコマンド show tech
show log
drops や flushes がカウントされている
show interfaces の drops や flushes はルータ宛てのパケットが drop された場合に カウントされます。
また、CPU 使用率が高いような状況だと、これらのカウンタが上昇しやすくなります。 パケットのキャプチャや以下のコマンドなどを取得するなどして、どういったパケットを drop しているのか確認してください。
show interfaces
show interfaces switching show ip traffic
show ip traffic <interface> show ip spd
overrun や throttle がカウントされている
overrun や throttle は基本的にはルータ宛てのパケットを多く受信している場合に 上昇します。 また、CPU 使用率が高いような状況だと、これらのカウンタが上昇しやすくなります。 パケットのキャプチャや以下のコマンドなどを取得するなどして、どういったパケットを drop しているのか確認してください。 show interfacesshow interfaces switching show ip traffic
show ip traffic <interface> show ip spd
no buffer や ignored がカウントされている
show interfaces の no buffer や ignored はバッファが不足した場合にカウントされます。 show buffer の中の Puplic buffer の failures や no memory が上昇していないか、
Interface buffer(Particle buffer) の misses in cache が上昇していないか確認して ください。
Public buffer pools:
Small buffers, 104 bytes (total 50, permanent 50, peak 109 @ 18:55:01):
47 in free list (20 min, 150 max allowed)
27688537 hits, 347 misses, 100 trims, 100 created 3 failures (0 no memory)
--- snip ---
GigabitEthernet0/2 buffers, 1664 bytes (total 768, permanent 768):
0 in free list (0 min, 768 max allowed) 768 hits, 0 fallbacks
768 max cache size, 0 in cache
no buffer や ignored がカウントされている
failures, no memory, misses in cache などがカウントされている場合は以下のような コマンドを複数回取得してください。
可能であればパケットのキャプチャもご取得ください。 show interfaces
show interfaces switching show ip traffic
show ip traffic <interface> show ip spd
show buffets all header show buffets all packet show buffets all dump show buffers leak
show buffers leak resource user show buffers old
CRC がカウントされている
show interfaces の CRC がカウントされ続けるような場合、何らかの Hardware的な 問題が発生している可能性が非常に高いです。
ケーブル、該当のルータのポート、対向機器のポートなどの問題が考えられます。 Hardware の交換にて対応頂ければと思います。
コマンド取得の準備
この Training で紹介した show コマンドを取得頂く際には以降の設定を行ったうえで ご取得ください。
■以下を設定頂き show command に time stamp が付くようにしてください。
■以下を設定頂き time stamp を msec 表示にしてください。
Router(config)#line con 0
Router(config-line)# exec prompt timestamp Router(config-line)#exit
Router(config)#line vty 0 4
Router(config-line)# exec prompt timestamp Router(config-line)#exit
Router(config)#service timestamps debug datetime msec localtime Router(config)#service timestamps log datetime msec localtime
コマンド取得の準備
■以下を設定頂き show log に保存されるログの size を変更してください。
buffer size は show memory statistics で現在の Processor Memory の Free の値を 確認し、値を設定頂ければと思います。
出来るだけ大きな値を設定頂きたいのですが、Free の値の数パーセント程度の値であ れば、設定しても問題ないと思います。
Router#show memory statistics
Load for five secs: 98%/45%; one minute: 98%; five minutes: 96% Time source is hardware calendar, 23:16:03.813 UTC Thu Nov 21 2013
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 86CD8338 396524744 38217340 358307404 351700516 349826728 ^^^^^^^^^
I/O 1E700000 26214400 12790532 13423868 12877568 12874460 Router(config)#logging buffer <size>
