Viptela 非直接接続リンク障害時のローカルブレイクアウト通信の救済

今回は、非直接接続のネットワークで障害が発生し、インターネットに出れなくなった際のローカルブレイクアウト通信の救済方法を説明します。

概要

ローカルブレイクアウト通信の救済

前回の記事で紹介した方法では、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コマンドを設定します。

vEdge2

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

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

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

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 STATUSUPであることが確認できます。

 

補足として、下記は、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

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インタフェースのアドレスが確認できます。

SV1

[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をシャットダウンします。

R3

interface GigabitEthernet3
 shutdown
            

 

R3でshow ip interface briefコマンドを実行すると、g3がダウンしていることが確認できます。

R3

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

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 STATUSDOWNに変化したことが確認できます。

 

 

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インタフェースのアドレスが確認できます。

SV1

[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)...
            

コメント

タイトルとURLをコピーしました