SD-WANゾーンベースファイアウォール(ZBFW)とルート漏出の設定

はじめに

このドキュメントでは、バーチャルプライベートネットワーク(VPN)間のルート漏出を使用したゾーンベースファイアウォール(ZBFW)の設定、確認、およびトラブルシューティングの方法について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Cisco SD-WANオーバーレイによる初期設定
• vManageユーザインターフェイス(UI)からのZBFW設定
• vManage UIからのルート漏出コントロールポリシーの設定

使用するコンポーネント 

デモンストレーションの目的で、次のソフトウェアが使用されました。

• Cisco SD-WAN vSmartコントローラ（ソフトウェアリリース20.6.2）
• Cisco SD-WAN vManageコントローラ（ソフトウェアリリース20.6.2）
• コントローラモードで稼働する、ソフトウェアリリース17.6.2が稼働するCisco IOS® XE Catalyst 8000V仮想エッジプラットフォームルータ2台
• Autonomousモードで動作する、ソフトウェアリリース17.6.2を備えたCisco IOS XE Catalyst 8000V仮想エッジプラットフォームルータ3台

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

このドキュメントでは、ルータがSD-WANオーバーレイの宛先VPNマッピングを決定する方法と、VPN間のルート漏出の検証およびトラブルシューティングの方法について説明します。また、同じサブネットが別のVPNからアドバタイズされる場合のパス選択の特異性と、この問題によって発生する可能性のある問題の種類についても説明します。

設定

ネットワーク図

両方のSD-WANルータには、SD-WANコントローラとのコントロール接続と、コントローラ間のデータプレーン接続を確立するための基本パラメータが設定されています。この設定の詳細は、このドキュメントの目的の範囲外です。次の表に、VPN、サイトID、およびゾーンの割り当てをまとめます。

サービス側のルータでは、各Virtual Routing and Forwarding(VRF)に、対応するSD-WANルータを指すスタティックデフォルトルートが設定されています。同様に、SD-WANエッジルータには、対応するサブネットを指すスタティックルートが設定されています。ルート漏出とZBFWに関する潜在的な問題を示すために、cE2のサービス側の背後にあるルータは同じサブネット192.168.12.0/24を持つことに注意してください。cE2の背後にある両方のルータには、同じIPアドレス192.168.12.12を持つホストをエミュレートするように設定されたループバックインターフェイスがあります。

Cisco IOS-XEルータR10、R20、およびR30は、SD-WANエッジルートのサービス側でAutonomousモードで実行されることに注意してください。これらのルートは、主にこのデモンストレーションでエンドホストのエミュレートに使用されます。SD-WANエッジルート上のループバックインターフェイスは、サービス側ルータなどの実際のホストの代わりにこの目的で使用することはできません。これは、SD-WANエッジルータのVRFのインターフェイスから発信されたトラフィックは、対応するZBFWゾーンから発信されたトラフィックではなく、エッジルータの特別なセルフゾーンに属しているためです。そのため、ZBFWゾーンはVRFと同じとは見なされません。セルフゾーンの詳細な説明は、この記事の範囲外です。

ルート漏出の設定

主要な制御ポリシー設定の目的は、VPN 10および20からVPN 30へのすべてのルートの漏洩を許可することです。VRF 30はルータcE1にのみ存在し、VRF 10および20はルータcE2にのみ設定されています。これを実現するために、2つのトポロジ（カスタムコントロール）ポリシーを設定しました。VPN 10および20からのすべてのルートをVPN 30にエクスポートするトポロジを次に示します。

TLOCアドバタイズメントのブロックや通常のVPN内ルートアドバタイズメントの偶発的な到着を回避するために、デフォルトアクションが許可に設定されていることに注意してください。

同様に、トポロジポリシーは、VPN 30からVPN 10および20へのルーティング情報の逆アドバタイズメントを許可するように設定されました。

次に、両方のトポロジポリシーが、対応するサイトリストに入力（着信）方向で割り当てられます。VPN 30からのルートは、cE1（サイトID 11）から受信されると、vSmartコントローラによってVPN 10および20のOverlay Management Protocol(OMP)テーブルにエクスポートされます。

同様に、VPN 10および20からのルートは、cE2(site-id 12)からVPN 10および20ルートを受信すると、vSmartによってVPN 30ルーティングテーブルにエクスポートされます。

また、参照用の完全な制御ポリシー設定プレビューも示します。

viptela-policy:policy
 control-policy LEAK_VPN10_20_to_30
    sequence 1
     match route
      vpn-list VPN_10_20
      prefix-list _AnyIpv4PrefixList
     !
     action accept
      export-to vpn-list VPN_30
     !
    !
  default-action accept
 !
 control-policy LEAK_VPN30_to_10_20
    sequence 1
     match route
      vpn-list VPN_30
      prefix-list _AnyIpv4PrefixList
     !
     action accept
      export-to vpn-list VPN_10_20
     !
    !
  default-action accept
 !
 lists
  site-list SITE_11
   site-id 11 
  !
  site-list SITE_12
   site-id 12 
  !
  vpn-list VPN_10_20
   vpn 10 
   vpn 20 
  !
  vpn-list VPN_30
   vpn 30 
  !
  prefix-list _AnyIpv4PrefixList
   ip-prefix 0.0.0.0/0 le 32 
  !
 !
!
apply-policy
 site-list SITE_12
  control-policy LEAK_VPN10_20_to_30 in
 !
 site-list SITE_11
  control-policy LEAK_VPN30_to_10_20 in
 !
!

vSmartコントローラでポリシーを有効にするには、vManageコントローラのConfiguration > Policiesセクションで、ポリシーをアクティブにする必要があります。

ZBFW設定

この記事のデモンストレーションの目的で要件をフィルタリングするZBFWの要約を次の表に示します。

主な目的は、ルータcE1 VPN 30のサービス側から発信され、VPN 10を宛先とするがVPN 20を宛先としないすべてのInternet Control Message Protocol(ICMP)トラフィックを許可することです。リターントラフィックは自動的に許可される必要があります。

また、ルータcE2のサービス側のVPN 20からのすべてのICMPトラフィックが、VPN 10からではなく、cE1のVPN 30サービス側に通過できるようにする必要があります。VPN 30からVPN 20へのリターントラフィックは自動的に許可される必要があります。

ここでは、参照用のZBFWポリシープレビューを確認できます。

policy
 zone-based-policy VPN_20_to_30
    sequence 1
     seq-name Rule_1
     match
      source-ip 192.168.20.0/24
      destination-ip 192.168.30.0/24
      protocol 1
     !
     action inspect
     !
    !
    sequence 11
     seq-name Rule_2
     match
      source-ip 192.168.12.0/24
      destination-ip 192.168.30.0/24
      protocol 1
     !
     action inspect
     !
    !
  default-action drop
 !
 zone-based-policy VPN_30_to_10
    sequence 1
     seq-name Rule_1
     match
      source-ip 192.168.30.0/24
      destination-ip 192.168.10.0/24
      protocol 1
     !
     action inspect
     !
    !
    sequence 11
     seq-name Rule_2
     match
      protocol 1
      source-ip 192.168.30.0/24
      destination-ip 192.168.12.0/24
     !
     action inspect
     !
    !
  default-action drop
 !
  zone VPN_10
   vpn 10 
  !
  zone VPN_20
   vpn 20 
  !
  zone VPN_30
   vpn 30 
  !
  zone-pair ZP_VPN_20_VPN_30_VPN_20_to_30
   source-zone VPN_20
   destination-zone VPN_30
   zone-policy VPN_20_to_30
  !
  zone-pair ZP_VPN_30_VPN_10_VPN_30_to_10
   source-zone VPN_30
   destination-zone VPN_10
   zone-policy VPN_30_to_10
  !
 zone-to-nozone-internet deny
!

セキュリティポリシーを適用するには、デバイステンプレートのAdditional TemplatesセクションにあるSecurity Policyドロップダウンメニューのセクションで、セキュリティポリシーを割り当てる必要があります。

デバイステンプレートが更新されると、セキュリティポリシーが適用されたデバイスでセキュリティポリシーがアクティブになります。このドキュメントのデモでは、cE1ルータでのみセキュリティポリシーを有効にするだけで十分でした。

確認

次に、必要なセキュリティポリシー(ZBFW)目標が達成されたことを確認する必要があります。

pingを使用したテストでは、ゾーンVPN 10からVPN 30へのトラフィックに対してゾーンペアが設定されていないため、ゾーンVPN 10からVPN 30へのトラフィックが期待どおりに拒否されていることが確認されます。

R10#ping 192.168.30.30 source 192.168.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.30.30, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.10
.....
Success rate is 0 percent (0/5)
R10#ping 192.168.30.30 source 192.168.12.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.30.30, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.12
.....
Success rate is 0 percent (0/5)

同様に、VPN 20からのトラフィックは、セキュリティポリシーの設定で想定されているとおり、VPN 30への接続を許可されます。

R20#ping 192.168.30.30 source 192.168.20.20
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.30.30, timeout is 2 seconds:
Packet sent with a source address of 192.168.20.20
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R20#ping 192.168.30.30 source 192.168.12.12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.30.30, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.12
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

VPN 30からゾーンVPN 10のサブネット192.168.10.0/24へのトラフィックは、ポリシー設定で想定されているとおりに許可されます。

R30#ping 192.168.10.10 source 192.168.30.30
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.30
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

VPN 30からゾーンVPN 20のサブネット192.168.20.0/24へのトラフィックは、このトラフィック用に設定されたゾーンペアがないため拒否されます。これは予想どおりの動作です。

R30#ping 192.168.20.20 source 192.168.30.30
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.20, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.30
.....
Success rate is 0 percent (0/5)

IPアドレス192.168.12.12にpingを実行すると、ゾーンVPN 10またはVPN 20に含まれる可能性があり、SD-WANエッジルータcE1のサービス側にあるルータR30の観点から宛先VPNを判別できないため、さらに興味深い結果が得られる場合があります。

R30#ping 192.168.12.12 source 192.168.30.30
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.30
.....
Success rate is 0 percent (0/5)

結果は、VRF 30のすべての送信元で同じです。これは、等コストマルチパス(ECMP)ハッシュ関数の結果に依存しないことを確認します。

R30#ping 192.168.12.12 source 192.168.30.31
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.31
.....
Success rate is 0 percent (0/5)
R30#ping 192.168.12.12 source 192.168.30.32
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.12, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.32
.....
Success rate is 0 percent (0/5)

宛先IP 192.168.12.12のテスト結果から判断すると、ICMPエコー要求に応答せず、（必要に応じて）VPN 30からVPN 20へのトラフィックを許可するゾーンペアが設定されていないため、ブロックされている可能性が高いため、VPN 20内に存在することだけが推測できます。 同じIPアドレス192.168.12.12を持つ宛先がVPN 10にあり、ICMPエコー要求に応答すると想定される場合、VPN 30からVPN 20へのICMPトラフィックに対するZBFWセキュリティポリシーに従って、トラフィックを許可する必要があります。宛先VPNを確認する必要があります。

トラブルシュート

方式 1.OMPテーブルから宛先VPNを検索するには

cE1のルーティングテーブルを簡単にチェックしただけでは、実際の宛先VPNを理解することはできません。出力から得られる最も有用な情報は、宛先(169.254.206.12)のシステムIPであり、発生するECMPはありません。

cE1# show ip route vrf 30 192.168.12.0 255.255.255.0

Routing Table: 30
Routing entry for 192.168.12.0/24
  Known via "omp", distance 251, metric 0, type omp
  Last update from 169.254.206.12 on Sdwan-system-intf, 01:34:24 ago
  Routing Descriptor Blocks:
  * 169.254.206.12 (default), from 169.254.206.12, 01:34:24 ago, via Sdwan-system-intf
      Route metric is 0, traffic share count is 1

宛先VPNを見つけるには、まず、対象のプレフィックスについて、cE1上のOMPテーブルからサービスラベルを見つける必要があります。

cE1#show sdwan omp routes vpn 30 192.168.12.0/24
Generating output, this might take time, please wait ...
Code:
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved
                 PATH                      ATTRIBUTE
FROM PEER        ID     LABEL    STATUS    TYPE       TLOC IP          COLOR            ENCAP  PREFERENCE
-----------------------------------------------------------------------------------------------------------
169.254.206.4    12     1007     C,I,R     installed  169.254.206.12   private2         ipsec  -

ラベル値が1007であることがわかります。最後に、system-IP 169.254.206.12を持つルータから発信されるすべてのサービスがvSmartコントローラ上でチェックされる場合、宛先VPNを見つけることができます。

vsmart1# show omp services family ipv4 service VPN originator 169.254.206.12
C   -> chosen
I   -> installed
Red -> redistributed
Rej -> rejected
L   -> looped
R   -> resolved
S   -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA  -> On-demand inactive
U   -> TLOC unresolved

                                                 PATH
VPN    SERVICE  ORIGINATOR      FROM PEER        ID     LABEL    STATUS
---------------------------------------------------------------------------
1      VPN      169.254.206.12  169.254.206.12   82     1003     C,I,R
2      VPN      169.254.206.12  169.254.206.12   82     1004     C,I,R
10     VPN      169.254.206.12  169.254.206.12   82     1006     C,I,R
17     VPN      169.254.206.12  169.254.206.12   82     1005     C,I,R
20     VPN      169.254.206.12  169.254.206.12   82     1007     C,I,R

VPNラベル1007に基づいて、宛先VPNが20であることを確認できます。

方式 2.プラットフォームコマンドを使用して宛先VPNを検索するには

プラットフォームコマンドを使用して宛先VPNを見つけるには、まず、show ip vrf detail 30またはshow platform software ip f0 cef table * summaryコマンドを使用して、cE1ルータ上でVPN 30の内部VRF ID(VRF ID)を取得する必要があります。

cE1#show ip vrf detail 30 | i Id
VRF 30 (VRF Id = 1); default RD 1:30; default VPNID 
cE1#show platform software ip f0 cef table * summary | i VRF|^30
Name             VRF id  Table id    Protocol         Prefixes    State
30               1       1           IPv4             21          hw: 0x561b60f07a50 (created)

この例では、VRF ID 1は30という名前のVRFに割り当てられています。プラットフォームコマンドは、Cisco IOS-XEソフトウェアのパケットパスを決定する内部転送ロジックを表す、SD-WANソフトウェアのオブジェクトの出力チェーン要素(OCE)チェーンを明らかにします。

cE1#show platform software ip F0 cef table index 1 prefix 192.168.12.0/24 oce
=== Prefix OCE ===
Prefix/Len: 192.168.12.0/24
  Next Obj Type: OBJ_SDWAN_NH_SLA_CLASS
  Next Obj Handle: 0xf800045f, urpf: 0
  Prefix Flags: unknown
  aom id: 1717, HW handle: 0x561b60eeba20 (created)

対象のプレフィックスは、さらに検証可能なID 0xf800045fのサービスレベル契約(SLA)クラスタイプ(OBJ_SDWAN_NH_SLA_CLASS)のネクストホップオブジェクトを指します。

cE1#show platform software sdwan F0 next-hop sla id 0xf800045f
SDWAN Nexthop OCE

SLA: num_class 16, client_handle 0x561b610c3f10, ppe addr 0xdbce6c10
  SLA_0: num_nhops 1, Fallback_sla_flag TDL_FALSE, nhobj_type SDWAN_NH_INDIRECT
  ECMP: 0xf800044f 0xf800044f 0xf800044f 0xf800044f
        0xf800044f 0xf800044f 0xf800044f 0xf800044f
        0xf800044f 0xf800044f 0xf800044f 0xf800044f
        0xf800044f 0xf800044f 0xf800044f 0xf800044f
  SLA_1: num_nhops 0, Fallback_sla_flag TDL_FALSE, nhobj_type ADJ_DROP
  ECMP: 0xf800000f 0xf800000f 0xf800000f 0xf800000f
        0xf800000f 0xf800000f 0xf800000f 0xf800000f
        0xf800000f 0xf800000f 0xf800000f 0xf800000f
        0xf800000f 0xf800000f 0xf800000f 0xf800000f

これは長い出力であるため、2 ～ 15のSLAクラスはスキップされました。フォールバックSLAクラスは設定されておらず、すべてのSLAクラスがSLA 1と同じ特別なDROP隣接関係を指しているためです。主な対象は、SLA 0からの間接タイプ(SDWAN_NH_INDIRECT)のネクストホップオブジェクトです。また、ECMPが存在せず、すべてのIDが同じであることも確認できます(0xf800044f)。 最終的な宛先VPNとサービスラベルを見つけるためにさらに検証できます。

cE1#show platform software sdwan F0 next-hop indirect id 0xf800044f
SDWAN Nexthop OCE

Indirect: client_handle 0x561b610f8140, ppe addr 0xd86b4cf0
  nhobj_type: SDWAN_NH_LOCAL_SLA_CLASS, nhobj_handle: 0xf808037f
  label: 1007, vpn: 20, sys-ip: 169.254.206.12, vrf_id: 1, sla_class: 1

方法 3.パケットトレースツールを使用して宛先VPNを検索するには

宛先VPNを見つけるもう1つの方法は、ルータを通過する実際のパケットをリアルタイムで分析できるパケットトレースツールです。デバッグ条件は、IPアドレス192.168.12.12との間のトラフィックのみに一致するように設定されています。

cE1#debug platform condition ipv4 192.168.12.12/32 both
cE1#debug platform packet-trace packet 10
 Please remember to turn on 'debug platform condition start' for packet-trace to work
cE1#debug platform condition start

次に、トラフィックがpingを利用してR30から開始された場合、cE1で一致するパケットを確認し、各パケットの詳細を確認できます。この例では、最初のパケット番号は0です。最も重要な行は<<<<の記号で強調表示されています。

cE1#show platform packet-trace summary
Pkt   Input                     Output                    State  Reason
0     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)
1     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)
2     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)
3     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)
4     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)
5     Gi6                       Tu3                       DROP   52  (FirewallL4Insp)


cE1#show platform packet-trace packet 0
Packet: 0           CBUG ID: 0
Summary
  Input     : GigabitEthernet6
  Output    : Tunnel3
  State     : DROP 52  (FirewallL4Insp) <<<<<<<<<<<<<<<<<<<<<<<<
  Timestamp
    Start   : 161062920614751 ns (03/24/2022 16:19:31.754050 UTC)
    Stop    : 161062920679374 ns (03/24/2022 16:19:31.754114 UTC)
Path Trace
  Feature: IPV4(Input)
    Input       : GigabitEthernet6
    Output      : 
    Source      : 192.168.30.30
    Destination : 192.168.12.12
    Protocol    : 1 (ICMP)
  Feature: SDWAN Forwarding
    SDWAN adj OCE:
    Output       : GigabitEthernet3
    Hash Value   : 0xda
    Encap        : ipsec
    SLA          : 0
    SDWAN VPN    : 20
    SDWAN Proto  : IPV4
    Out Label    : 1007 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Local Color  : private2
    Remote Color : private2
    FTM Tun ID   : 218
    SDWAN Session Info
      SRC IP       : 192.168.10.11
      SRC Port     : 12366
      DST IP       : 192.168.10.12
      DST Port     : 12346
      Remote System IP : 169.254.206.12
      Lookup Type : TUN_DEMUX
      Service Type : NONE
  Feature: ZBFW
    Action  : Drop
    Reason  : No Zone-pair found <<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Zone-pair name         : N/A <<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Class-map name         : N/A
    Policy    name         : N/A
    Input interface        : GigabitEthernet6
    Egress interface       : Tunnel3
    Input  VPN ID          : 30
    Output VPN ID          : 20 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Input  VRF ID:Name     : 1:30 
    Output VRF ID:Name     : 1:30
    AVC Classification ID  : 0
    AVC Classification name: N/A
    UTD Context ID         : 0 

パケットトレースは、pingによって送信された5つのICMPエコーパケットがすべてドロップコード52(FirewallL4Insp)でドロップされたことを示します。 セクション「Feature: SDWAN Forwarding」では、宛先VPNが20であり、cE2での宛先VPNの指定のために、トンネリングパケットの内部ヘッダーのサービスラベル1007が使用されることが示されています。セクション「Feature: ZBFW」では、入力VPN 20からVPN 30ゾーン宛てのトラフィックに対してゾーンペアが設定されていなかったためにパケットがドロップされたことをさらに確認します。

フェールオーバーが原因で発生する可能性のある問題

ルート192.168.12.0/24がR20によって取り消されるか、VRF 20のcE2から到達不能になった場合はどうなりますか。VRF 30の観点からはサブネットは同じですが、ZBFWセキュリティポリシーはゾーンVPN 30からゾーンVPN 20および10へのトラフィックを異なる方法で処理するため、許可されたトラフィックのような望ましくない結果を招く可能性がありますが、許可されたトラフィックとは異なる結果になる可能性があります。

たとえば、cE2ルータとR20ルータ間のリンクの障害をシミュレートする場合などです。これにより、192.168.12.0/24ルートがvSmartコントローラのVPN 20ルーティングテーブルから取り消され、代わりにVPN 10ルートがVPN 30ルーティングテーブルにリークされます。VPN 30からVPN 10への接続は、cE1に適用されるセキュリティポリシーに従って許可されます（これはセキュリティポリシーの観点から予想されますが、両方のVPNに存在する特定のサブネットにとって望ましくありません）。

cE1#show platform packet-trace packet 0
Packet: 0           CBUG ID: 644
Summary
  Input     : GigabitEthernet6
  Output    : GigabitEthernet3
  State     : FWD
  Timestamp
    Start   : 160658983624344 ns (03/24/2022 16:12:47.817059 UTC)
    Stop    : 160658983677282 ns (03/24/2022 16:12:47.817112 UTC)
Path Trace
  Feature: IPV4(Input)
    Input       : GigabitEthernet6
    Output      : 
    Source      : 192.168.30.30
    Destination : 192.168.12.12
    Protocol    : 1 (ICMP)
  Feature: SDWAN Forwarding
    SDWAN adj OCE:
    Output       : GigabitEthernet3
    Hash Value   : 0xda
    Encap        : ipsec
    SLA          : 0
    SDWAN VPN    : 10
    SDWAN Proto  : IPV4
    Out Label    : 1006
    Local Color  : private2
    Remote Color : private2
    FTM Tun ID   : 188
    SDWAN Session Info
      SRC IP       : 192.168.10.11
      SRC Port     : 12366
      DST IP       : 192.168.10.12
      DST Port     : 12346
      Remote System IP : 169.254.206.12
      Lookup Type : TUN_DEMUX
      Service Type : NONE
  Feature: ZBFW
    Action  : Fwd
    Zone-pair name         : ZP_VPN_30_VPN_10_VPN_30_to_10
    Class-map name         : VPN_30_to_10-seq-11-cm_
    Policy    name         : VPN_30_to_10
    Input interface        : GigabitEthernet6
    Egress interface       : Tunnel3
    Input  VPN ID          : 30
    Output VPN ID          : 10
    Input  VRF ID:Name     : 1:30
    Output VRF ID:Name     : 1:30
    AVC Classification ID  : 0
    AVC Classification name: N/A
    UTD Context ID         : 0
  Feature: IPSec
    Result    : IPSEC_RESULT_SA
    Action    : ENCRYPT
    SA Handle : 74
    Peer Addr : 192.168.10.12
    Local Addr: 192.168.10.11

1007の代わりにラベル1006が使用され、現在の出力VPN IDは20ではなく10であることに注意してください。また、パケットはZBFWセキュリティポリシーに従って許可され、対応するゾーンペア、クラスマップ、およびポリシー名が指定されました。

最も古いルートがVPN 30のルーティングテーブルに保持されるという事実により、さらに大きな問題が発生する可能性があります。この場合、初期制御ポリシーアプリケーションVPN 20ルートがvSmart上のVPN 30 OMPテーブルにリークされた後のVPN 10ルートが原因です。元のアイデアがこの記事で説明したZBFWセキュリティポリシーロジックとまったく逆のシナリオを想像してみてください。たとえば、目的はVPN 30からVPN 20へのトラフィックを許可し、VPN 10へのトラフィックは許可しないことでした。初期ポリシー設定後に許可された場合は、障害または192.168.12.0/24ルートがVPN 20から離脱した後も、192.168.12.0/24ルートがVPN 10から引き続きリークするため、回復した後でも192.168.12.0/24サブネットへのトラフィックはブロックされたままになります。