ZabbixやPRTGでCiscoスイッチの監視を組むとき、まず詰まるのが「v2cとv3どっちで作る？」「trapはどこまで送らせる？」だったりする。最初の現場でv2cのコミュニティ名をそのままpublicのまま放置してたら、別チームのセキュリティ監査で速攻ひっかかった経験があり、ここは正直慎重にやりたい。
この記事では、Catalyst 9300とISR4321で実機検証したSNMPv2c / v3の設定コマンド、trap送信、show snmp系の確認手順までまとめる。社内専用ならv2cで十分なケースもあるけど、結論から言うとv3でいけるなら最初からv3で組んだ方が後々ラク。理由も含めて書いていく。
v2c はシンプル、v3 は安全。選び方の軸
v2cはコミュニティ文字列だけで認証する。設定コマンドが少ないし、Zabbixのテンプレートもデフォルトv2c前提のものが多い。ただ、コミュニティ文字列が平文でネットワークを流れる。WANをまたぐ監視や、共通基盤で複数組織が混ざる環境では、まあ正直v2cはやめた方がいい。
v3はuser/group/viewで権限を細かく切れて、authPrivモードならSHA認証＋AES暗号化が効く。設定の手数は増えるけど、これは慣れれば30分で終わる。下に比較表とプログレスバーを載せた。
| 項目 | SNMPv2c | SNMPv3 |
|---|---|---|
| 認証 | コミュニティ文字列のみ（平文） | user単位でMD5/SHA |
| 暗号化 | なし | DES / 3DES / AES128/192/256 |
| 設定の手数 | 2〜3行で済む | group / user / view で7〜10行 |
| 推奨用途 | 閉じた検証環境のみ | 本番運用すべて |
| Cisco IOSサポート | 12.0以降 | 12.0(3)T以降 |
図1: セキュリティ・運用の観点から見た総合評価
92%
25%
88%
55%
以前、共用データセンタの監視を引き継いだとき、v2cでpublicのまま放置されてた装置が30台くらい見つかった。脆弱性スキャナで一発で拾われる状態。慌てて週末作業でv3に巻き直したけど、最初からv3で組んでくれてれば3時間の残業はなかった。新規構築でv3が選べるなら、面倒でもv3でいくのがほんと無難。
v2c は ACL とセットで運用するのが鉄則
v2cはとにかく短い。コミュニティ文字列と、そのコミュニティに紐づくACL（送信元IP制限）だけ書けば動く。逆に言うとACLを書かないと、そのコミュニティ名さえ知ってればどこからでもwalkできてしまう。下記が最小構成。
Switch(config)# ip access-list standard SNMP_NMS_RO Switch(config-std-nacl)# permit host 10.0.0.10 Switch(config-std-nacl)# deny any log Switch(config-std-nacl)# exit
Switch(config)# snmp-server community NmsR0_2026 RO SNMP_NMS_RO Switch(config)# snmp-server location DC-Tokyo-Rack5 Switch(config)# snmp-server contact netops@example.co.jp
コミュニティ名はpublic / privateを絶対に使わないこと。スキャナの辞書攻撃で一番最初に試される。NmsR0_2026みたいに英数字混在＋年号で識別性を持たせるのが個人的に好き。
snmp-server community xxx ROだけ書いて、ACLを付け忘れるパターン。これだとコミュニティ名さえ漏れたら全世界から読み放題になる。show snmp communityで末尾にACL名がついてるか必ず確認する。
view → group → user の順に作る
v3はちょっとだけクセがある。「どのMIBツリーを見せるか（view）」を作って、「そのviewにアクセスできるグループ（group）」を定義し、「そのグループに所属するユーザ（user）」を作る。順番を間違えると参照エラーで蹴られるので、下から組み上げていくのが分かりやすい。
| パラメータ | 設定値（例） | 備考 |
|---|---|---|
| 認証プロトコル | SHA | MD5は使わない（廃止予定） |
| 暗号化 | AES 128 以上 | DESはNG。最低AES128 |
| セキュリティモデル | priv（authPriv） | noAuthNoPrivは検証用のみ |
| view | v_iso（iso配下のみ） | configは見せない |
Switch(config)# snmp-server view v_iso iso included Switch(config)# snmp-server view v_iso internet.6.3.15 excluded ! ↑ usmStatsの一部は隠す（パスワード試行回数などが見えるのを防ぐ）
Switch(config)# snmp-server group GRP_NMS v3 priv read v_iso access SNMP_NMS_RO
Switch(config)# snmp-server user nms_user GRP_NMS v3 auth sha N3tOpsAuth!2026 priv aes 128 N3tOpsPriv!2026
snmp-server userはrunning-configでshow running-configしても暗号化されて表示される。バックアップから戻すと別ホスト扱いになって動かないことがある。EngineIDを固定する（snmp-server engineID local 80000009030000...）か、リストア後に必ずuserを作り直すこと。これ、ハマると本気で原因が分からなくて1時間溶ける。
enable traps と host 指定はセットで
trapはイベント駆動でNMSに通知する仕組み。リンクダウンや認証失敗、設定変更などをUDP/162で投げる。snmp-server enable trapsで何を送るかを決め、snmp-server hostで送信先を指定。両方書かないと飛ばない。
Switch(config)# snmp-server enable traps snmp linkdown linkup coldstart warmstart Switch(config)# snmp-server enable traps config Switch(config)# snmp-server enable traps syslog Switch(config)# snmp-server enable traps cpu threshold Switch(config)# snmp-server host 10.0.0.10 version 3 priv nms_user
ちなみにenable trapsを全部入りにすると、たまにポートがバタつくたびに5,000件くらいtrapが飛んできてNMS側のキューが詰まる。最初は最低限のlinkdown linkupとconfigだけにして、必要に応じて追加する運用が現実的。
trapは「投げっぱなし」で再送しないので、UDPで落ちると消える。重要なイベントはsnmp-server enable traps ...とSyslog（TCP送信できる）の二系統で取るのが安心。
show snmp と Linux からの snmpwalk
Switch# show snmp
Chassis: FOC2345A1B2
Contact: netops@example.co.jp
Location: DC-Tokyo-Rack5
0 SNMP packets input
0 Bad SNMP version errors
...
SNMP global trap: enabled
Switch# show snmp user
User name: nms_user
Engine ID: 80000009030012ABCDEF34
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: GRP_NMS
Switch# show snmp group
groupname: GRP_NMS security model: v3 priv
readview : v_iso writeview: <no writeview specified>
notifyview: <no notifyview specified>
row status: active access-list: SNMP_NMS_RO
$ snmpwalk -v 3 -l authPriv -u nms_user \ -a SHA -A 'N3tOpsAuth!2026' \ -x AES -X 'N3tOpsPriv!2026' \ 10.0.0.1 sysDescr SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, Catalyst L3 Switch...
よく使うOIDを覚えておくと現場で便利。下記は監視で必須レベル。
| 用途 | OID / MIB名 | 補足 |
|---|---|---|
| 機種・IOS識別 | sysDescr (1.3.6.1.2.1.1.1) | 最初の疎通確認に使う |
| CPU使用率 | cpmCPUTotal5min | 過去5分平均 |
| メモリ使用 | ciscoMemoryPoolUsed | プール別に取得可 |
| IF状態 | ifOperStatus | 1=up, 2=down |
| トラフィック量 | ifHCInOctets / ifHCOutOctets | 64bitカウンタ。1Gbps超ならこっち |
| 温度 | ciscoEnvMonTempStatusValue | 機種依存。9300は対応 |
よくあるエラーと対処パターン
| 症状 | 原因 | 対処 |
|---|---|---|
| Timeout: No Response | ACL拒否 / FW遮断 | show ip access-listsでhitcount確認 |
| Authentication failure | v3パスワード不一致 | user削除→再作成（変更不可） |
| Unknown user name | EngineID不一致 | remote engineIDを明示するか再作成 |
| trap が NMS 側に届かない | enable traps漏れ / hostへのview | debug snmp packetsで出力確認 |
| 特定OIDだけ取れない | view から excluded | show snmp viewで確認 |
余談だけど、Cisco公式のSNMP Object Navigator（snmp.cloudapps.cisco.com）でOIDをキーワード検索できるので、MIBコンパイルが面倒なときは重宝する。社外接続できる端末から1つ叩く感じで運用してた時期もある。
SNMPv2cはACL必須、コミュニティ名はpublic禁止。新規構築なら最初からv3を選んで、SHA + AES128以上のauthPrivで組むのが結論。trapは最低限linkdown/linkupとconfigから始めて、運用しながら追加するくらいでちょうどいい。
よくある質問（FAQ）
Q. v2cからv3への移行はリブート必要？
不要。v3のuser/group/viewを追加してNMSを切り替え、v2cのsnmp-server communityを消すだけでOK。並行運用しながら切り替えるのが現実的。
Q. SNMPv3 のパスワードは何文字以上にすべき？
最低8文字。Ciscoの仕様で最短8文字、推奨は16文字以上。auth用とpriv用は別々に設定する（同じにしないこと）。
Q. trap の宛先は何台まで指定できる？
snmp-server hostを複数行書けば複数のNMSに送れる。冗長化したNMSがある場合は2台ぶん書くのが一般的。台数の上限はIOS依存だけど、実用上10台くらいまで指定しても問題なかった。
Q. SNMP のポーリング間隔は何秒にすべき？
NMS側で60秒〜300秒が一般的。1秒間隔とかにすると装置のCPUを軽く食う（特に古いL3スイッチ）。show processes cpu sortedでSNMP Engineプロセスが上位に来てたら間隔を伸ばす。
