PBR（ポリシー Based ルーティング）は、宛先prefixだけでなく送信元、プロトコル、ACL等の条件でネクストホップや出力インターフェースを選ぶ機能です。通常ルーティングを置き換える万能機能ではなく、ポリシー不一致・ネクストホップ障害・local-generated トラフィック・VRF差を設計します。
⭕️ネットワークエンジニアが
少し深掘りして理解したいこと✅️PBR
PBRは、
Policy Based Routing日本語でいうと、
ポリシーベースルーティング。普通のルーティングは、
宛先IPアドレスを見て
ルーティングテーブルから
次の転送先を決める。つまり基本は、
宛先がどこか
で経路が決まる。… pic.twitter.com/QSNMvn6uJK— けんと＠設計構築チャンネル (@yeiquer12) 2026年6月23日
PBRはACL条件に一致する特定通信だけを通常とは別のNext Hopへ流すと解説したポスト。
(出典：https://x.com/yeiquer12/status/2069371140938846546（X：PBRはACL条件に一致する特定通信だけを通常とは別のネクストホップへ流すと解説したポスト。）)
PBRとは？
先に答えると、PBR（ポリシー Based ルーティング）は、宛先prefixだけでなく送信元、プロトコル、ACL等の条件でネクストホップや出力インターフェースを選ぶ機能です。通常ルーティングを置き換える万能機能ではなく、ポリシー不一致・ネクストホップ障害・local-generated トラフィック・VRF差を設計します。
通常のルーティングと何が違う？
通常ルーティングは「宛先 prefixで選択」を担い、実務では「ルーティングテーブル/FIB」を確認します。続く表で各要素の役割と判断点を比べます。
| 項目 | 仕組み・役割 | 実務での判断 |
|---|---|---|
| 通常ルーティング | 宛先 prefixで選択 | ルーティングテーブル/FIB |
| PBR | 経路-map条件でoverride | 主にingress インターフェースへ適用 |
| match | ACL等でパケットを分類 | 拒否の意味はPBR非対象 |
| set | ネクストホップ/インターフェースを指定 | 到達性trackが必要な場合 |
| fallback | ポリシー非一致/適用不能 | 通常ルーティングへ進む挙動を検証 |
Client-A 10.0.10.0/24 --PBR--> ISP-A next-hop 192.0.2.1
Client-B 10.0.20.0/24 --normal route--> ISP-B 198.51.100.1Ciscoで送信元別経路をどう設定する？
最初に「対象送信元/宛先と期待pathを表にする」を行い、最後に「送信元指定ping/tracerouteとカウンターで試験」を確認します。合格条件は「実path」です。
| STEP | 実施内容 | 確認する結果 |
|---|---|---|
| 1 | 対象送信元/宛先と期待pathを表にする | ポリシー範囲 |
| 2 | ACL・経路-map sequence・インターフェース適用をレビュー | match順 |
| 3 | ネクストホップ到達性と通常経路を確認 | fallback |
| 4 | 送信元指定ping/tracerouteとカウンターで試験 | 実path |
ip access-list extended PBR-SOURCE
permit ip 10.0.10.0 0.0.0.255 any
route-map PBR-WAN permit 10
match ip address PBR-SOURCE
set ip next-hop 192.0.2.1
interface GigabitEthernet0/0
ip policy route-map PBR-WAN
show route-map PBR-WAN
show ip policy
show ip route 192.0.2.1Policy routing matches: 245 packets, 19600 bytes
Interface Gi0/0: route-map PBR-WAN
Next-hop 192.0.2.1 reachable via Gi0/1ネクストホップ障害時はどう動く？
「カウンター 0」の場合は「ACL不一致・インターフェース適用違い」を原因候補にし、次に「actual 送信元/宛先」を確認します。正常時との差を症状ごとに追います。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| カウンター 0 | ACL不一致・インターフェース適用違い | actual 送信元/宛先 |
| ルーター自身のトラフィックだけ別経路 | local PBR未設定 | ip local ポリシーの要否 |
| ネクストホップ障害でblackhole | reachability検知不足 | track/verify-可用性 |
| 戻り トラフィックが別path | asymmetry・ステートフル FW | reverse 経路 |
PBRが効かないとき何を確認する？
PBRを追加すると、ルーティングテーブルだけでは実際のpathを説明できなくなります。構成図、経路-map、対象トラフィック、fallback、監視を一組にし、運用手順に『PBR適用有無を先に確認』と記載します。
- 対象機器・インターフェース・VRF/VLAN
- 取得日時・タイムゾーン・software バージョン
- 変更前後の同一コマンド出力
- 期待値・実測値・判定者
- 異常時の停止条件と切り戻し結果
関連する仕組みを次に確認する
次の記事では、今回の確認を隣接するレイヤーや別の観測点へ広げます。
まとめ：通常経路とポリシー 経路の二つの選択条件を可視化する
要点は、通常経路とポリシー 経路の二つの選択条件を可視化することです。構成図、設定、確認コマンド、正常時と異常時の結果を同じ条件で保存すると、第三者も判断を再現できます。
