今回は、非直接接続のネットワークで障害が発生し、インターネットに出れなくなった際のローカルブレイクアウト通信の救済方法を説明します。
概要
ローカルブレイクアウト通信の救済
前回の記事で紹介した方法では、vEdgeのインターネット向けのWANインタフェースを収容しているルータの先で障害が発生した際は、ローカルブレイクアウト対象の通信をオーバレイ経由でハブ拠点に転送することは不可能になります。
その結果、vEdgeはローカルブレイクアウトを継続してしまい、サービスが利用できなくなってしまいます。
上記のような障害が発生した際に、ローカルブレイクアウト対象の通信をオーバレイ経由でハブ拠点に転送するには、Trackerと呼ばれる機能を使用する必要があります。
Trackerは特定のアドレスに対してHTTPリクエストを送信して、応答があるかを確認する機能になります。
vEdgeはTrackerを使用して、特定のインターネット上のサービスに対して、定期的にHTTPリクエストを送信します。
応答がある場合、vEdgeはインターネットまでの途中のネットワークで障害は発生していないと判断し、ローカルブレイクアウトを実施します。
応答がない場合、vEdgeはインターネットまでの途中のネットワークで障害が発生したと判断し、ローカルブレイクアウトを中止し、閉域網経由でハブ拠点にトラフィックを転送します。
検証環境、内容
検証内容
R4でHTTPサーバを動作させます。
vEdge2でTrackerを設定し、定期的にR4に対してHTTPリクエストを送信して、死活を監視します。
R2からSV1に対して、Telnetを実施します。
正常時は、Teletのパケットはインターネット回線からローカルブレイクアウトされていることを確認します。
R3とR4間のネットワーク障害時は、Telnetのパケットは閉域網経由でvEdge1に転送されていることを確認します。
物理/論理構成
オーバレイネットワーク構成
初期設定
system
system-ip 10.1.10.11
site-id 10
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
interface eth0
ip address 172.16.10.11/24
tunnel-interface
no shutdown
!
ip route 0.0.0.0/0 172.16.10.254
system
host-name vBond
system-ip 10.1.10.21
site-id 10
organization-name "Criterio1 - 19101"
vbond 172.16.10.21 local vbond-only
!
vpn 0
interface ge0/0
ip address 172.16.10.21/24
tunnel-interface
encapsulation ipsec
!
no shutdown
!
ip route 0.0.0.0/0 172.16.10.254
system
host-name vSmart
system-ip 10.1.10.31
site-id 10
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
interface eth0
ip address 172.16.10.31/24
tunnel-interface
no shutdown
!
ip route 0.0.0.0/0 172.16.10.254
system
host-name vEdge1
system-ip 1.1.1.1
site-id 1
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
interface ge0/0
ip address 172.16.1.1/24
tunnel-interface
encapsulation ipsec
color biz-internet restrict
!
no shutdown
!
interface ge0/1
ip address 172.20.1.1/24
tunnel-interface
encapsulation ipsec
color metro-ethernet restrict
max-control-connections 0
!
no shutdown
!
ip route 0.0.0.0/0 172.16.1.254
!
vpn 10
interface ge0/2
ip address 10.1.1.1/24
no shutdown
!
ip route 0.0.0.0/0 10.1.1.11
system
host-name vEdge2
system-ip 2.2.2.2
site-id 2
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
interface ge0/0
ip address 172.16.2.2/24
nat
!
tunnel-interface
encapsulation ipsec
color biz-internet restrict
!
no shutdown
!
interface ge0/1
ip address 172.20.1.2/24
tunnel-interface
encapsulation ipsec
color metro-ethernet restrict
max-control-connections 0
!
no shutdown
!
ip route 0.0.0.0/0 172.16.2.254
!
vpn 10
interface ge0/2
ip address 20.1.1.2/24
no shutdown
!
policy
app-visibility
interface GigabitEthernet2
ip address 10.1.1.11 255.255.255.0
ip nat inside
!
interface GigabitEthernet3
ip address 172.16.1.11 255.255.255.0
ip nat outside
!
ip nat inside source list 1 interface GigabitEthernet3 overload
ip route 0.0.0.0 0.0.0.0 172.16.1.254
ip route 20.1.1.0 255.255.255.0 10.1.1.1
!
access-list 1 permit any
interface GigabitEthernet2
ip address 20.1.1.12 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 20.1.1.2
interface GigabitEthernet2
ip address 172.16.2.254 255.255.255.0
!
interface GigabitEthernet3
ip address 172.16.3.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.3.4
interface GigabitEthernet2
ip address 172.16.1.254 255.255.255.0
!
interface GigabitEthernet3
ip address 172.16.3.4 255.255.255.0
!
interface GigabitEthernet4
ip address 172.16.10.254 255.255.255.0
!
ip http server
!
ip route 0.0.0.0 0.0.0.0 172.16.3.3
設定、正常時の状態確認
vEdge2の設定の確認
vEdge2ではsystem配下でtracker <Trackerの名前>コマンドを使用して、Trackerを定義します。
endpoint-ipコマンドでHTTPリクエストの送信先のアドレス、interval <秒>コマンドでHTTPリクエストの送信間隔を指定します。
そして、Trackerでダウンを検出した際にローカルブレイクアウトを無効にするインタフェースに対して、tracker <Trackerの名前>コマンドを設定します。
また、今までと同様に、ローカルブレイクアウトに使用するインタフェースにはnatコマンドを設定します。
system
tracker test_tracker
endpoint-ip 172.16.3.4
interval 10
!
vpn 0
interface ge0/0
nat
tracker test_tracker
VPN Listの確認
VPN Listで、Traffic Data Policyの適用先のVPNのIDを指定します。
Site Listの確認
Site Listで、Traffic Data Policyの適用先のSiteのIDを指定します。
Traffic Data Policyの確認
Trackerで障害を検出した際に、ローカルブレイクアウト対象の通信をオーバレイ経由で転送するために、NAT VPNアクションのFallbackオプションを有効にします。
他の通信はハブ拠点に転送させるために、Default ActionにはAcceptを設定します。
Centralized Control Policyの確認
Traffic Rules > Traffic DataからCentralized Control Policyにローカルブレイクアウト用のTraffic Data Policyをインポートしておきます。
Policy Application > Traffic DataからインポートしたTraffic Data Policyの適用先のSiteとVPNを指定します。
vSmartのCentralized Control Policyの設定確認
vSmartでshow runコマンドを実行し、Centralized Control Policy用のコマンドを確認します。
vSmart# show run
.
<一部省略>
.
policy
data-policy _VPN_10_Traffic_Data_Policy
vpn-list VPN_10
sequence 1
match
source-ip 0.0.0.0/0
destination-port 23
protocol 6
!
action accept
nat use-vpn 0
nat fallback
!
!
default-action accept
!
!
lists
vpn-list VPN_10
vpn 10
!
site-list Site_2
site-id 2
!
!
!
apply-policy
site-list Site_2
data-policy _VPN_10_Traffic_Data_Policy from-service
vEdge2のCentralized Control Policyの情報確認
vEdge2でshow policy from-vsmartコマンドを実行し、Centralized Control Policyの情報を確認します。
vEdge2# show policy from-vsmart
from-vsmart data-policy _VPN_10_Traffic_Data_Policy
direction from-service
vpn-list VPN_10
sequence 1
match
source-ip 0.0.0.0/0
destination-port 23
protocol 6
action accept
nat use-vpn 0
nat fallback
default-action accept
from-vsmart lists vpn-list VPN_10
vpn 10
疎通確認
vEdge2でshow interfaceコマンドを実行します。
vEdge2# show interface
IF IF IF TCP
AF ADMIN OPER TRACKER ENCAP SPEED MSS RX TX
VPN INTERFACE TYPE IP ADDRESS STATUS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 ipv4 172.16.2.2/24 Up Up Up null transport 1500 00:0c:29:35:f9:91 1000 full 1416 0:01:40:14 95019 91590
0 ge0/1 ipv4 172.20.1.2/24 Up Up NA null transport 1500 00:0c:29:35:f9:9b 1000 full 1416 0:04:12:12 30940 30909
0 system ipv4 2.2.2.2/32 Up Up NA null loopback 1500 00:00:00:00:00:00 0 full 1416 0:04:17:13 0 0
10 ge0/2 ipv4 20.1.1.2/24 Up Up NA null service 1500 00:0c:29:35:f9:a5 1000 full 1416 0:04:12:12 1676 925
512 eth0 ipv4 192.168.1.212/24 Up Up NA null service 1500 00:0c:29:35:f9:87 0 full 0 0:04:17:06 29857 7389
現在、vEdge2はR4からHTTPレスポンスを受信できているため、TRACKER STATUSがUPであることが確認できます。
補足として、下記は、vEdge2がR4に送信したHTTPリクエストになります。
そして、下記は、R4がvEdge2に返信したHTTPレスポンスになります。
Status Codeは401のエラーを示していますが、Trackerとしては、何かしらのHTTPレスポンスさえ受信できれば、疎通可能と判断します。
それでは、R2からSV1に対して、Telnetを実施します。
vEdge2のshow app dpi flows detailsコマンドの出力にTLOCの情報が含まれていないため、vEdge2はTelnetのパケットを、オーバレイ経由でvEdge1に転送せずに、ローカルブレイクアウトしていることが確認できます。
vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 172.16.1.100 15361 23 tcp
application telnet
family Terminal
active-since 2020-04-25T14:37:07+00:00
packets 66
octets 2970
SV1のTelnetのアクセスログを見ると、vEdge2のWANインタフェースのアドレスが確認できます。
[root@localhost ~]# cat /var/log/messages | grep Telnet
Apr 25 15:27:48 localhost systemd: Started Telnet Server (172.16.2.2:15361).
Apr 25 15:27:48 localhost systemd: Starting Telnet Server (172.16.2.2:15361)...
非直接接続ネットワーク障害時の状態確認
R3のインターネット向けのインタフェース障害
R3のg3をシャットダウンします。
interface GigabitEthernet3
shutdown
R3でshow ip interface briefコマンドを実行すると、g3がダウンしていることが確認できます。
R3#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1 192.168.1.223 YES manual up up
GigabitEthernet2 172.16.2.254 YES manual up up
GigabitEthernet3 172.16.3.3 YES unset administratively down down
障害発生後の疎通確認
vEdge2でshow interfaceコマンドを実行します。
vEdge2# show interface
IF IF IF TCP
AF ADMIN OPER TRACKER ENCAP SPEED MSS RX TX
VPN INTERFACE TYPE IP ADDRESS STATUS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 ipv4 172.16.2.2/24 Up Up Down null transport 1500 00:0c:29:35:f9:91 1000 full 1416 0:01:42:49 96036 92744
0 ge0/1 ipv4 172.20.1.2/24 Up Up NA null transport 1500 00:0c:29:35:f9:9b 1000 full 1416 0:04:14:46 31248 31217
0 system ipv4 2.2.2.2/32 Up Up NA null loopback 1500 00:00:00:00:00:00 0 full 1416 0:04:19:47 0 0
10 ge0/2 ipv4 20.1.1.2/24 Up Up NA null service 1500 00:0c:29:35:f9:a5 1000 full 1416 0:04:14:46 1717 964
512 eth0 ipv4 192.168.1.212/24 Up Up NA null service 1500 00:0c:29:35:f9:87 0 full 0 0:04:19:40 30184 7486
現在、vEdge2はR4からHTTPレスポンスを受信できないため、TRACKER STATUSがDOWNに変化したことが確認できます。
R2からSV1に対して、Telnetを実施します。
vEdge2でshow app dpi flows detailsコマンドを実行すると、vEdge2はTelnetのパケットを閉域網経由でvEdge1に転送していることが確認できます。
vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 172.16.1.100 44545 23 tcp
application telnet
family Terminal
active-since 2020-04-25T14:39:22+00:00
packets 66
octets 2969
tunnels-in 1
local-tloc TLOC IP 2.2.2.2
local-tloc color metro-ethernet
local-tloc encap ipsec
remote-tloc TLOC IP 1.1.1.1
remote-tloc color metro-ethernet
remote-tloc encap ipsec
packets 34
octets 1452
start-time 2020-04-25T14:39:22+00:00
tunnels-out 1
local-tloc ip 2.2.2.2
local-tloc color metro-ethernet
local-tloc encap ipsec
remote-tloc TLOC IP 1.1.1.1
remote-tloc color metro-ethernet
remote-tloc encap ipsec
packets 32
octets 1517
start-time 2020-04-25T14:39:22+00:00
SV1のTelnetのアクセスログを見ると、R1のWANインタフェースのアドレスが確認できます。
[root@localhost ~]# cat /var/log/messages | grep Telnet
Apr 25 15:30:04 localhost systemd: Started Telnet Server (172.16.1.11:5062).
Apr 25 15:30:04 localhost systemd: Starting Telnet Server (172.16.1.11:5062)...
コメント