Cisco IOSのNAT・ACL・routing処理順は、inside-to-outsideかoutside-to-insideか、input ACLかoutput ACLか、NVI/VRF/platform機能を使うかで見方が変わります。暗記表だけでruleを設計せず、対象versionのpacket processing資料とdebug以外の状態情報で確認します。
⭕️インフラエンジニアが
設計で理解しておきたいことNAT
ACL
Routing
の処理順L3機器に
インターフェイスACL
NAT
Routing
を設定しているとする。では、Gi0/1にパケットが着信した瞬間、
そのパケットは何から処理されるのか。ここを理解していないと、
設計や障害切り分けでハマる。… pic.twitter.com/YPQH7f8FhI— けんと＠設計構築チャンネル (@yeiquer12) 2026年6月21日
Cisco IOSのinside→outside通信でinput ACL、Routing、NAT、output ACLの順を整理したポスト。
Cisco IOSのNAT・ACL・Routingはどの順で処理される？
先に答えると、Cisco IOSのNAT・ACL・routing処理順は、inside-to-outsideかoutside-to-insideか、input ACLかoutput ACLか、NVI/VRF/platform機能を使うかで見方が変わります。暗記表だけでruleを設計せず、対象versionのpacket processing資料とdebug以外の状態情報で確認します。
insideからoutsideでは何を見る？
仕組みを構成上の位置と観測点に分けると、用語だけでなく実際のpacket・stateを説明できます。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| input ACL | ingressで評価 | その時点のheaderを対象versionで確認 |
| routing lookup | egressを決定 | NAT処理で再評価される構成も確認 |
| NAT | source/destinationを書き換え | inside local/global等 |
| output ACL | egress側で評価 | 変換済み/未変換を実機で検証 |
inside host → ingress ACL → route/NAT processing → egress ACL → outside
outside host → ingress ACL → NAT/route processing → egress ACL → inside
※簡略図。NVI・ZBF・VRF・platformで追加処理ありoutsideからinsideでは何を見る？
outsideからinsideでは何を見る？では、対象と期待値を固定し、状態取得、実通信、変更後確認の順に進めます。commandは例であり、本番投入前に対象OSの公式資料と現行設定を確認してください。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 通信方向と4 addressをpacket flowへ記入 | inside/outsideを固定 |
| 2 | interfaceのip nat inside/outsideとACL方向を取得 | 設定点を確定 |
| 3 | route・NAT translation・ACL counterをbefore取得 | 現在状態 |
| 4 | 1 sessionだけ生成しcounter/log変化を照合 | 実装順を裏付け |
show running-config interface GigabitEthernet0/0
show running-config interface GigabitEthernet0/1
show ip route <destination>
show ip nat translations verbose
show ip nat statistics
show ip access-listsInside local: 10.0.0.20:51500
Inside global: 203.0.113.20:51500
ACL-IN matches: +1
ACL-OUT matches: +1
Route: 0.0.0.0/0 via 203.0.113.1input・output ACLはどのaddressを参照する？
一つの表示だけで原因を決めず、症状ごとに次の観測点を選びます。正常時の同条件出力が比較基準です。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 図とcounterが不一致 | 別rule/route/context | matched sequenceとVRF |
| translationなし | NAT ACL不一致・inside/outside誤り | statisticsとconfig |
| translationあり通信なし | return route・outside policy | reverse direction |
| debugで高負荷 | 無条件debug | counter/log/captureを先に使う |
設計と実機をどう照合する？
Ciscoのdebug ip packetやdebug ip natは本番負荷と大量出力を招く可能性があります。maintenance条件とfilterを設計し、まずshow command、ACL counter、flow record、packet captureで絞ります。
- 対象機器・interface・VRF/VLAN
- 取得日時・timezone・software version
- 変更前後の同一command出力
- 期待値・実測値・判定者
- 異常時の停止条件とrollback結果
関連する仕組みを次に確認する
定義だけで終わらせず、隣接する仕組みと障害切り分けへ進みます。
まとめ：暗記した順序ではなく、対象方向のcounterとtranslationで検証する
暗記した順序ではなく、対象方向のcounterとtranslationで検証することが結論です。構成図、設定・command、正常時と異常時の結果を同じ条件で保存し、第三者が判断を再現できる状態にしてください。
