PBR と HSRP・VRRP の組み合わせ｜ブラックホール化の回避

はじめに

「特定のセグメントからの通信だけプロキシ経由にしたい」「監査対象の通信をセキュリティ機器へ強制的に流したい」という要件では、宛先ベースの経路制御では対応できません。この場面で使われるのが PBR（Policy-Based Routing）です。

一方で、ゲートウェイの冗長化には HSRP や VRRP を構成しているのが一般的です。この 2 つを組み合わせた構成には、設計段階で把握しておきたい落とし穴があります。PBR は経路表とは別の仕組みで動作するため、冗長化の効果が及ばない範囲が生じます。

本記事は Cisco IOS / IOS XE を前提としています。set ip next-hop verify-availabilityは Cisco 固有のコマンドであり、FortiGate や YAMAHA のポリシールーティングは実装体系が異なるため対象外です。

結論から述べます。PBR は経路表より先に評価され、指定した next-hop が停止していてもフォールバックしません。結果としてパケットが破棄され続ける状態になります。next-hop に FHRP の仮想 IP アドレスを指定すると機器障害には対応できますが、それだけでは不十分です。オブジェクトトラッキングと組み合わせて、代替 next-hop と経路表へのフォールバックまで設計しておくことをおすすめします。

本記事の設定例は、次の構成を前提にしています。

PBR と FHRP の組み合わせで生じるブラックホール化

まず、両者を組み合わせる必要が生じる要件と、そこで生じる課題を整理します。

PBR が必要になる要件

通常のルーティングは宛先 IP アドレスのみで転送先を決定します。PBR は、それ以外の条件で経路を制御する仕組みです。

参考: IP Routing: Protocol-Independent Configuration Guide, Cisco IOS XE Release 3E / Policy-Based Routing
“the device puts packets through a route map before routing them”
（デバイスは、パケットをルーティングする前にルートマップを通過させます）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/xe-3e/iri-xe-3e-book/iri-pbr.html

実務で PBR が採用される要件は、次のようなものです。

いずれも「宛先だけでは判断できない」という点が共通しています。

冗長化との両立が課題になる理由

PBR と FHRP は、それぞれ異なるレイヤーで動作します。

• FHRP: 配下ホストから見たゲートウェイの冗長化。ホストの通信先（仮想 IP アドレス）を維持する
• PBR: ルーターに到達したパケットの転送先の制御。next-hop を明示的に指定する

FHRP が守るのは「ホストからルーターまで」の区間です。ルーターから先の転送先が停止していても、FHRP は関知しません。PBR で指定した next-hop の障害は、FHRP の対象外になります。

ここに、以降で扱う課題が生じます。PBR の最大の注意点は、指定した next-hop が到達不能になった場合の挙動です。

経路表を参照しない PBR の動作

PBR は、パケットがルーターに到達した時点で、通常のルーティング処理より先に評価されます。

処理の流れは次のようになります。

1. インターフェースにパケットが到着します
2. ip policy route-mapが設定されていれば、ルートマップの match 条件を評価します
3. 条件に一致すれば、set 句で指定された next-hop へ転送します
4. 条件に一致しなければ、通常の経路表に従って転送します

3 番目で処理が完結する点が要点です。ルートマップの条件に一致したパケットは、経路表を参照することなく指定された next-hop へ送られます。

公式ドキュメントでは、set コマンドの評価順序について「使用可能な next hop はインターフェースを意味する」「ローカルデバイスが next hop と使用可能なインターフェースを見つけると、パケットをルーティングする」と説明されています。逆に言えば、next-hop が到達可能かどうかの判定は、既定では行われません。

next-hop 障害時に起きること

指定した next-hop の機器が停止すると、次の状態になります。

この現象が、Cisco の公式ドキュメントでも「トラフィックブラックホール」として説明されています。リダイレクト先の機器に障害が発生すると、その宛先へのパケットがすべて破棄される状態です。

運用上、この障害は発見が遅れやすいという特性があります。理由は 2 点あります。

1 つは、影響範囲が限定的である点です。PBR の match 条件に一致する通信だけが停止するため、監視対象の疎通確認（多くは PBR 対象外の経路を通る）では検知されません。

もう 1 つは、ルーターとしては正常に動作している点です。インターフェースはアップしており、経路表も正常で、FHRP も Active を維持しています。ルーター側のログにも異常は記録されません。

FHRP では解決できない理由

「ゲートウェイを冗長化しているのだから、片方が落ちても大丈夫では」という認識は、この構成では成立しません。

FHRP が対応するのは、PBR を実行するルーター自身の障害です。R1 が停止すれば R2 が Active になり、R2 側でも同じ PBR 設定が動作します。ここまでは問題ありません。

しかし、PBR の転送先である迂回先機器（プロキシなど）が停止した場合、R1 も R2 も正常に動作しているため、FHRP のフェイルオーバーは発生しません。両系とも同じ停止した next-hop へパケットを送り続けます。

2 行目と 3 行目が、本記事で対処する課題です。FHRP と PBR は守備範囲が異なるため、それぞれに冗長化の仕組みを用意する必要があります。

対処の方向性は 2 つあります。1 つは next-hop に FHRP の仮想 IP アドレスを指定して迂回先側も冗長化する方法、もう 1 つは PBR 自身に到達性の確認機能を持たせる方法です。次のセクションから順に扱います。

なお、HSRP と VRRP のどちらを使うかという選定については、関連記事『HSRP と VRRP の違い｜FHRP の選定基準と判断の順序』で整理しています。本記事の設計論は両プロトコルに共通して適用できます。

next-hop に FHRP 仮想 IP を指定する設計

前のセクションで整理したとおり、PBR の転送先が単一機器のままでは、その機器の障害がそのまま通信断につながります。最初の対処は、迂回先も冗長化し、その仮想 IP アドレスを next-hop に指定する構成です。

基本の設定

迂回先のプロキシやセキュリティ機器の手前に、HSRP または VRRP を構成したルーターのペアを配置します。PBR の next-hop には、その仮想 IP アドレスを指定します。

! 迂回対象を定義（192.168.100.0/24 からの HTTP 通信）
ip access-list extended TO-PROXY
 permit tcp 192.168.100.0 0.0.0.255 any eq 80
!
! ルートマップの定義
route-map PBR-PROXY permit 10
 match ip address TO-PROXY
 set ip next-hop 192.168.200.254
!
! インターフェースへの適用
interface GigabitEthernet0/1
 ip address 192.168.100.251 255.255.255.0
 standby version 2
 standby 1 ip 192.168.100.254
 standby 1 priority 110
 standby 1 preempt
 ip policy route-map PBR-PROXY

set ip next-hop 192.168.200.254が迂回先の仮想 IP アドレスです。R1 と R2 の双方に同じ PBR 設定を投入します。どちらが Active になっても同じポリシーが適用される必要があるためです。

なお、ip policy route-mapはインターフェース単位で適用します。指定したインターフェースに到着したパケットが対象で、ルーター自身が生成したパケットは対象外です。ルーターからの ping やルーティングプロトコルのパケットは PBR を通りません。ルーター発のパケットにもポリシーを適用したい場合はip local policy route-mapを使います。

参考: IP Routing Configuration Guide / Policy-Based Routing
“Packets that are generated by the device are not normally policy-routed”
（デバイスが生成したパケットは、通常はポリシールーティングの対象になりません）
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-routing/b-ip-routing/m_iri-pbr.html

疎通確認をルーターの CLI から行った場合、PBR を経由しない経路が使われます。動作確認は配下のクライアントから実施することをおすすめします。

この構成で対応できる範囲

仮想 IP アドレスを next-hop に指定すると、迂回先ルーターの機器障害には対応できます。

4 行目と 5 行目が残る課題です。仮想 IP アドレス宛の到達性そのものが失われた場合、PBR は依然としてパケットを送り続け、ブラックホール化します。

仮想 IP を next-hop にする際の注意

もう 1 点、実装上の注意があります。VRRP では、仮想 IP アドレス宛の通信に応答しない実装があります。

VRRP の Accept_Mode は RFC 5798 で既定が False と規定されており、IP アドレス所有者が存在しない構成では、Master であっても仮想 IP アドレス宛の ICMP に応答しません。この動作自体は PBR の転送には影響しませんが、到達性確認の手段として仮想 IP アドレス宛の ping を使う設計では問題になります。

後述するverify-availabilityの track オブジェクトで IP SLA の ping を使う場合、監視先を仮想 IP アドレスにすると常に到達不能と判定される可能性があります。監視先は迂回先機器の実 IP アドレスや、その先の到達確認できるアドレスを指定する設計を推奨します。

Accept_Mode の実装差については、関連記事『VRRP とは｜Master 選出と priority 設計の落とし穴』で整理しています。

verify-availability による到達性の確認

next-hop の到達性を PBR 自身に確認させる仕組みがset ip next-hop verify-availabilityです。このコマンドには 2 つの記法があり、動作が大きく異なります。

2 つの記法

引数の有無で仕組みがまったく異なります。混同すると、設定したつもりの監視が動作しません。

CDP を利用する方式

引数なしで設定すると、CDP のネイバーテーブルを参照して next-hop の存在を確認します。

route-map PBR-PROXY permit 10
 match ip address TO-PROXY
 set ip next-hop 192.168.200.254
 set ip next-hop verify-availability

動作の流れは次のとおりです。

1. PBR が CDP ネイバーテーブルを確認し、next-hop の IP アドレスが存在するかを判定します
2. 存在すれば、そのアドレスへ ARP 要求を送信して転送します
3. 存在しなければ、PBR は適用されず経路表に従った転送になります

設定が 1 行で済む手軽さはありますが、実務で採用する際には 3 つの制約があります。

制約 1: 検知が速くない

CDP はホールドタイムに依存して動作します。既定のホールドタイムは 180 秒で、設定可能な範囲は 10〜255 秒です。next-hop の停止から数分間、パケットが破棄され続ける可能性があります。

制約 2: すべてのプラットフォームで使えるわけではない

CDP をフェイルオーバー機構として利用できるかは、機器によって異なります。導入前に対象プラットフォームのドキュメントで確認することをおすすめします。

制約 3: 対向が Cisco 機器に限られる

CDP は Cisco 独自プロトコルです。迂回先がプロキシアプライアンスやサードパーティ製のセキュリティ機器の場合、CDP に対応していなければ判定できません。

FHRP の仮想 IP アドレスを next-hop にしている場合、この方式は適しません。CDP のネイバーテーブルに登録されるのは各機器の実 IP アドレスであり、仮想 IP アドレスは通常含まれないためです。

方式の選択

以上から、実務での選択は次のようになります。

CDP 方式が選択肢になるのは、対向が Cisco 機器で、かつ検知時間に余裕がある構成に限られます。新規構築では track オブジェクト方式を推奨します。

オブジェクトトラッキングとの連携

track オブジェクト方式では、IP SLA による疎通監視の結果を track オブジェクトに紐づけ、その状態を PBR が参照します。監視の仕組みと PBR が分離されているため、監視方法を柔軟に選べます。

IP SLA と track オブジェクトの定義

まず、監視を行う IP SLA オペレーションを定義します。

! 迂回先機器への疎通監視
ip sla 1
 icmp-echo 192.168.200.11 source-interface GigabitEthernet0/2
 frequency 5
ip sla schedule 1 life forever start-time now
!
! 代替経路の監視
ip sla 2
 icmp-echo 192.168.200.12 source-interface GigabitEthernet0/2
 frequency 5
ip sla schedule 2 life forever start-time now

ip sla scheduleの投入を忘れると、オペレーションが定義されただけで実行されません。この 1 行の漏れが、監視が動作しない原因として多く見られます。

監視先には迂回先機器の実 IP アドレスを指定しています。前のセクションで触れたとおり、VRRP の仮想 IP アドレスは実装によって ICMP に応答しないため、監視先には適さない場合があります。

次に、IP SLA の結果を track オブジェクトに紐づけます。

track 1 ip sla 1 reachability
track 2 ip sla 2 reachability

reachabilityは到達性の有無を返します。より詳細な条件で判定したい場合はstateを使う方法もありますが、PBR との連携ではreachabilityが扱いやすい選択です。

track オブジェクトの仕組みは HSRP のトラッキングと共通です。構文の詳細は関連記事『HSRP の設定手順｜priority と preempt の設計ポイント』でも扱っています。

route-map への組み込み

定義した track オブジェクトを、PBR の next-hop 判定に組み込みます。

route-map PBR-PROXY permit 10
 match ip address TO-PROXY
 set ip next-hop verify-availability 192.168.200.254 10 track 1
 set ip next-hop verify-availability 192.168.200.244 20 track 2

各行の構成要素は次のとおりです。

シーケンス番号が評価順序を決めます。track 1 が up であれば 192.168.200.254 へ転送し、down であれば次のシーケンスへ進みます。

3 段構えのフォールバック

上の設定では、次の 3 段階で転送先が決まります。

第 3 段階が重要です。公式ドキュメントの設定例でも、優先 next-hop が到達不能なら代替へ、代替も到達不能ならポリシールーティングが失敗し、経路表に従って転送されるという設計が示されています。

参考: IP Routing: Protocol-Independent Configuration Guide / PBR Support for Multiple Tracking Options
“the policy routing fails and the packets are routed according to the routing table”
（ポリシールーティングが失敗し、パケットは経路表に従ってルーティングされます）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-sy/iri-15-sy-book/iri-pbr-mult-track.html

この動作が、ブラックホール化を回避する仕組みです。すべての next-hop が到達不能になると PBR の適用が見送られ、通常のルーティングにフォールバックします。

フォールバック先の妥当性を確認する

ただし、第 3 段階には設計上の判断が伴います。経路表にフォールバックするということは、迂回を回避して直接通信することを意味します。

セキュリティや監査を目的とした迂回では、フォールバックによって要件が満たされない状態が生じます。「通信を継続する」ことと「ポリシーを維持する」ことのどちらを優先するかを、設計時に決めておく必要があります。

ポリシーの維持を優先する場合は、set ip next-hopの代わりにset interface Null0を最終段に配置し、明示的に破棄する設計も選択肢になります。ただしこの場合、迂回先の障害がそのまま通信断になるため、監視体制とセットで検討することをおすすめします。

設定全体の例

ここまでを統合した設定です。

! 監視オペレーション
ip sla 1
 icmp-echo 192.168.200.11 source-interface GigabitEthernet0/2
 frequency 5
ip sla schedule 1 life forever start-time now
!
ip sla 2
 icmp-echo 192.168.200.12 source-interface GigabitEthernet0/2
 frequency 5
ip sla schedule 2 life forever start-time now
!
! トラッキングオブジェクト
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability
!
! 迂回対象の定義
ip access-list extended TO-PROXY
 permit tcp 192.168.100.0 0.0.0.255 any eq 80
!
! ルートマップ
route-map PBR-PROXY permit 10
 match ip address TO-PROXY
 set ip next-hop verify-availability 192.168.200.254 10 track 1
 set ip next-hop verify-availability 192.168.200.244 20 track 2
!
! インターフェースへの適用
interface GigabitEthernet0/1
 ip address 192.168.100.251 255.255.255.0
 standby version 2
 standby 1 ip 192.168.100.254
 standby 1 priority 110
 standby 1 preempt
 ip policy route-map PBR-PROXY

R2 側にも同じルートマップと IP SLA の設定を投入します。HSRP の priority と自身の IP アドレスのみが異なる形になります。

なお、公式ドキュメントには IOS 12.3(11)T や 12.2(25)S 以前を対象とした RTR による記法も掲載されています。現行バージョンでは上記のip sla構文を使用します。古い文献を参照する際は、対象バージョンの確認をおすすめします。

非対称ルーティングへの注意

PBR で往路を制御した構成には、もう 1 つ検討事項があります。

往路と復路が異なる経路を通る

PBR が制御するのは、指定したインターフェースに到着したパケットの転送先です。復路のパケットは PBR の対象外であり、通常のルーティングに従います。

復路が往路と同じ経路を通る保証はありません。迂回先機器がクライアント宛の経路を別のルーターへ向けていれば、復路はそちらを通ります。

ステートフル機器を経由する場合の影響

非対称になること自体は、必ずしも問題ではありません。影響が出るのは、経路上にステートフルな機器が存在する場合です。

ファイアウォールや NAT を行う機器は、通信のセッション情報を保持しています。往路のパケットで作られたセッション情報と、復路のパケットが到達する機器が異なると、復路のパケットが未知のセッションとして破棄される可能性があります。

設計上の対処

対処の方向性は 3 つあります。

1. 復路にも PBR を設定する

迂回先機器側のインターフェースにも PBR を設定し、クライアント宛の通信を明示的に制御します。設定箇所が増えますが、経路を確実に固定できます。

2. 経路設計で往復を揃える

迂回先機器の経路表で、クライアントセグメント宛の next-hop を PBR 実行側の仮想 IP アドレスに向けます。静的経路 1 行で対応できるため、構成がシンプルになります。

3. FHRP の Active 機を揃える

複数の FHRP グループを構成している場合、往路と復路で Active になる機器が異なると非対称が生じます。グループ間で priority の設計を揃えるか、HSRP であればstandby groupによる連動、VRRP であればvrgrpによる連動を検討します。

多くの構成では 2 番目の方法が扱いやすい選択になります。設定量が少なく、PBR の設定箇所を増やさずに済むためです。

構成が確定した段階で、往路と復路の経路を実際にトレースして確認することをおすすめします。設計上は対称に見えても、機器側の経路表の状態によって想定と異なる経路を通る場合があります。

動作確認と切り分け

設定後は、PBR とトラッキングの双方が意図どおりに動作しているかを確認します。

ルートマップと track 状態の確認

もっとも基本的な確認コマンドです。

R1# show route-map PBR-PROXY
route-map PBR-PROXY, permit, sequence 10
  Match clauses:
    ip address (access-lists): TO-PROXY
  Set clauses:
    ip next-hop verify-availability 192.168.200.254 10 track 1 [up]
    ip next-hop verify-availability 192.168.200.244 20 track 2 [up]
  Policy routing matches: 1043 packets, 128291 bytes

確認したい箇所は 2 つです。

Policy routing matchesが 0 のまま増えない場合、次の点を確認します。

• アクセスリストの条件が実際の通信と一致しているか
• ip policy route-mapを適用したインターフェースが、通信の入口として正しいか
• 確認用の通信をルーター自身から発生させていないか

3 番目は見落としやすい部分です。ルーターの CLI から実行した ping は PBR の対象外になるため、配下のクライアントから確認します。

監視状況の確認

IP SLA の動作状況は、次のコマンドで確認します。

R1# show ip sla statistics
R1# show track

show ip sla statisticsでは、直近の実行結果と成功・失敗の回数を確認できます。Number of successesが増えていない場合、ip sla scheduleの投入漏れか、監視先が応答していない可能性があります。

show trackでは、track オブジェクトの状態と、状態が変化した回数と時刻が表示されます。フラッピングの調査では、状態変化の回数が判断材料になります。短時間に多数の変化が記録されていれば、監視先までの経路品質を疑う流れになります。

切り分けの順序

意図どおりに動作しない場合、次の順序で確認すると原因に到達しやすくなります。

1 番目でPolicy routing matchesが増えていれば PBR 自体は動作しています。増えていない場合は 2 番目へ、track が down であれば 3 番目以降へ進みます。

まとめ

PBR は経路表より先に評価されるため、指定した next-hop が停止していてもフォールバックせず、対象の通信だけが破棄される状態になります。FHRP による冗長化はルーター自身の障害を守るもので、PBR の転送先の障害には反応しません。両者の守備範囲が異なることを理解したうえで、トラッキングによる到達性確認とフォールバック先の設計まで含めて構成することをおすすめします。

• PBR は経路表を参照せず、next-hop 障害でもフォールバックしない
• FHRP が守るのはルーター自身の障害で、転送先の障害は対象外
• next-hop に仮想 IP を指定しても両系ダウンには対応できない
• CDP 方式は検知が遅く、仮想 IP を next-hop にする構成には不向き
• IP SLA と track による 3 段構えのフォールバックが基本の設計
• セキュリティ目的の迂回では経路表へのフォールバック可否を検討する
• 往路を固定するとステートフル機器で非対称ルーティングが問題になる

以上、最後までお読みいただきありがとうございました。