クライアントHyper-V上とvyOSでネットワーク検証する その5 OSPFで障害テスト

前回までに作ってみOSPF経由の接続でわざとvyOSを落として経路交換やらダウンタイムを見てみましょうかね。

• 測定用の簡易PowerShell
• クライアント側ゲートウェイ（プライマリがダウンした場合）
• クライアント側ゲートウェイ（プライマリが復旧した場合）
• DC側の対向ゲートウェイ（プライマリがダウンした場合）
• DC側の対抗ゲートウェイ（プライマリが復旧した場合）

測定用の簡易PowerShell

①ダウンタイム測定の簡易PowerShell

for($i = 0; $i -le 10000; $i++){
curl -Uri http://192.168.20.100 -TimeoutSec 1
    $date = date
    $date.DateTime
    sleep 1  
 }

②経路確認の簡易PowerShell

for($i = 0 ; $i -le 10000 ; $i++){
 tracert -d -w 2 192.168.20.100 
}

クライアント側ゲートウェイ（プライマリがダウンした場合）

2018年8月16日 23:46:34頃にダウン

2018年8月16日 23:47:03頃に回復

ダウンタイムは約３０秒ですね～。

経路も確認

クライアント側ゲートウェイ（プライマリが復旧した場合）

2018年8月17日 0:05:01頃に再度ダウン

2018年8月17日 0:05:14頃に疎通

１５秒くらいですね～。

経路も確認

DC側の対向ゲートウェイ（プライマリがダウンした場合）

2018年8月17日 0:18:23頃にダウン

2018年8月17日 0:18:57頃に復旧

35秒くらいでしょうかね

経路も確認

DC側の対抗ゲートウェイ（プライマリが復旧した場合）

2018年8月17日 0:31:39に再度ダウン

2018年8月17日 0:31:43に復旧

5秒以内ですか！なるほど。

経路も確認

無事にネットワークの自動復旧は確認できたわけですが、

こんなネットワークを組むことはないかもしれませんが、
LAN側のプライマリゲートウェイの復旧時に発生するダウンタイムより
DC対向側のゲートウェイが復旧した際のダウンタイムのほうが短いという気づきがありました。

ちゃんと確認してませんが、vyOSの復旧起動後にVRRPのほうがOSPFより早く復旧し、ゲートウェイに昇格するが、OSPFのルーティング情報の復旧までは引き続きダウンするためかと思います。

と、するとOSPFのルート情報が切り替わる直前でVRRPも復旧するようにチューニングすればダウンタイムを減らせるかもしれません。

うーん奥が深い。

今度は少し構成に手を入れて、ECMPか、vyOSのアウトバウンドの回線負荷分散機能を利用し、待機系ネットワークの有効利用を検証したいです。