今回は、インターネットと接続しているWANインタフェースに障害が発生した際のローカルブレイクアウト通信の救済方法を説明します。
概要
ローカルブレイクアウト通信の救済
拠点間をインターネットと閉域網経由で接続している状況で、Slackのトラフィックをローカルブレイクアウトで直接インターネットに転送していると仮定します。
このような構成において、インターネットと接続しているvEdgeのWANインタフェースがダウンした際に、vEdgeがSlackのトラフィックに対して、ローカルブレイクアウトを継続すると、Slackが利用できなくなってしまいます。
このような状況では、vEdgeはSlackのトラフィックをローカルブレイクアウトさせず、閉域網経由でハブ拠点に転送することで、Slackを継続して利用できます。
今回は、vEdgeのインターネットと接続しているWANインタフェースがダウンした際に、ローカルブレイクアウト対象の通信を閉域網経由でハブ拠点に転送し、サービスを継続させる方法を説明します。
検証環境、内容
検証内容
R2からSV1に対して、Telnetを実施します。
正常時は、Teletのパケットはインターネット回線からローカルブレイクアウトされていることを確認します。
vEdge2のge0/0の障害時は、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.1.254 255.255.255.0
!
interface GigabitEthernet3
ip address 172.16.2.254 255.255.255.0
!
interface GigabitEthernet4
ip address 172.16.10.254 255.255.255.0
設定、正常時の状態確認
vEdge2の設定の確認
vEdge2では通常のローカルブレイクアウトの設定と同様に、ローカルブレイクアウトに使用するインタフェースにnatコマンドを設定するのみです。
vpn 0
interface ge0/0
nat
VPN Listの確認
VPN Listで、Traffic Data Policyの適用先のVPNのIDを指定します。
Site Listの確認
Site Listで、Traffic Data Policyの適用先のSiteのIDを指定します。
Traffic Data Policyの確認
ローカルブレイクアウトで使用するWANインタフェースがダウンした際に、ローカルブレイクアウト対象の通信をオーバレイ経由で転送するために、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
疎通確認
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 38401 23 tcp
application telnet
family Terminal
active-since 2020-04-25T12:52:37+00:00
packets 67
octets 3004
SV1のTelnetのアクセスログを見ると、vEdge2のWANインタフェースのアドレスが確認できます。
[root@localhost ~]# cat /var/log/messages | grep Telnet
Apr 25 13:43:17 localhost systemd: Started Telnet Server (172.16.2.2:38401).
Apr 25 13:43:17 localhost systemd: Starting Telnet Server (172.16.2.2:38401)...
インターネット回線障害時の状態確認
vEdge2のインターネット向けのWANインタフェース障害
vEdge2のインターネット向けのWANインタフェースであるge0/0をシャットダウンします。
vpn 0
interface ge0/0
shutdown
vEdge2でshow interfaceコマンドを実行すると、ge0/0がダウンしていることが確認できます。
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 Down Down NA null transport 1500 00:0c:29:35:f9:91 - - 1416 - 40556 38164
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:00:00:16 19739 18331
0 system ipv4 2.2.2.2/32 Up Up NA null loopback 1500 00:00:00:00:00:00 0 full 1416 0:01:34:44 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:01:32:24 556 296
512 eth0 ipv4 192.168.1.212/24 Up Up NA null service 1500 00:0c:29:35:f9:87 0 full 0 0:01:34:38 9846 2460
障害発生後の疎通確認
R2からR1に対して、Telnetを実施します。
vEdge2でshow app dpi flowsコマンドを実行すると、vEdge2はTelnetのパケットを閉域網経由でvEdge1に転送していることが確認できます。
vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 172.16.1.100 30209 23 tcp
application telnet
family Terminal
active-since 2020-04-25T12:55:30+00:00
packets 91
octets 3996
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 47
octets 1983
start-time 2020-04-25T12:55:30+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 44
octets 2013
start-time 2020-04-25T12:55:30+00:00
SV1のTelnetのアクセスログを見ると、R1のWANインタフェースのアドレスが確認できます。
[root@localhost ~]# cat /var/log/messages | grep Telnet
Apr 25 13:46:11 localhost systemd: Started Telnet Server (172.16.1.11:5063).
Apr 25 13:46:11 localhost systemd: Starting Telnet Server (172.16.1.11:5063)...
コメント