- ライター：渡部 満幸
- 2004年4月1日、ネットワンシステムズ入社。
応用技術、製品主管部門、製品担当業務で技術者として15年以上勤務。
主としてCisco製ローエンド～ハイエンドルータ製品の技術担当として15年の経験があります。
Cisco製だけでなくJuniper製、Nokia製ハイエンドルータの技術担当としても兼務経験があります。
現在はCisco製ロー/ミドルレンジルータ、Catalystスイッチ製品群およびVMware SD-WAN (VeloCloud)の技術担当。
目次
みなさまこんにちは。
ネットワンシステムズの渡部です。
今回はVeloCloud EdgeとCiscoルータとでVirtual Router Redundancy Protocol (VRRP) を組んでみました。
その結果や発見についてご紹介します。
VeloCloud Edgeの冗長構成について
ここで簡単にVeloCloud Edge(以下、VCE)で冗長構成を組む方法についておさらいしておきましょう。
VeloCloudでは以下3種類の形態から1つを選択することが可能です。
1. VeloCloud独自のHigh Availability(HA)構成
2. VeloCloud独自のCluster構成
3. VeloCloudと他メーカ機器でVirtual Router Redundancy Protocol(VRRP)による冗長構成
1 のHA構成は2台の同じ機種を同期させ、仮想的に1台のVCEとして動作させることができます。
CiscoのCatalystでStack構成を組んでいる状態と言えばピンとくる方もいらっしゃるかもしれません。
このHA構成では "2台の"、"同じ機種のVCE” という制限がありますが、設定や接続は非常に簡単で主に営業店舗や支店等、拠点側の機器冗長を実現する際に利用します。
2 のCluster構成は複数のVCEをClusterとしてグループ化し、負荷分散処理を行います。
この構成では異なるVCEをグループ化することが可能で、理論上は何台でもグループに所属することができます。
主に本社やデータセンタ等、営業店や支店等からのVPNトンネルを集約し、トラフィックが集中する場所で利用します。
現時点ではVPNトンネルの収容数のスケールアウト機能に対する負荷分散処理をサポートしており、トラフィック(スループット)の負荷分散処理はサポートしていません。
ちょうど1年前のブログ VeloCloud High Availability = 機器冗長の 特徴と利点 で触れていますので、ご興味があればこちらも参照ください。
そして今回ご紹介する 3 のVRRPは、IETF RFC 3768で標準化されているプロトコルを使用したものです。
標準プロトコルのため、この機能を実装している他の機器との冗長構成を実現します。
検証構成
利用コンポーネント
・VeloCloud Virtual Edge Version 3.4.3
・VeloCloud Gateway Version 3.4.3
・VeloCloud Orchestrator Version 3.4.3
・Cisco CSR1000v Version 16.7.1
・PC Windows10 (LAN側接続端末として)
・Vyatta Version 17.1.0 (疑似Internet WAN回線として)
図1. 構成図
図中にVeloCloud Gateway(VCG)も描かれていますが、VeloCloudの主要コンポーネントとして記載しているだけです。
今回の記事においては特段の役割があるわけではありません。
VRRPの設定
それでは画面キャプチャをベースにVeloCloud Orchestrator(VCO)でVRRPを設定する手順を確認していきましょう。
1. VCO > Configure > Edges > Device > High Availability > [VRRP with Third-Party Router]
High Availabilityの設定項目から [VRRP with Third-Party Router] を選択しましょう。
2. VCO > Configure > Edges > Device > High Availability > VRRP Settings
VRRP Settingsに各種パラメータを入力可能になっていますので、以下の項目を埋めていきます。
・VRID: Virtual Router ID
・Interface: VRRPを有効化するInterfaceをプルダウンから選択
今回はVLAN 1
・Virtual IP: VRRPで公告するIPアドレス
・Advertise Interval: Helloタイマ間隔(設定可能な単位は秒)
今回は1秒
・Priority: VRRP Priority
今回は100
VeloCloudにおいては最低でも20以上の数値を設定することをお勧めします
・Preempt (Delay): Preempt ON or OFF (Delay 設定可能な単位は秒)
今回はON、10秒
必要に応じて右側の [＋] ボタンを押して行を追加(あるいは [Clone] ボタンで行を複製)します
3. LAN側のInterfaceを設定します
VCO > Configure > Edges > Device > Configure VLAN > [Edit]
VRRP Settingsで指定したVLANの設定を行います。
Edge LAN IP Address は適切なパラメータを指定してください。
ここでお伝えしたい重要な点は、「DHCPサーバ機能を利用している場合、必ずOptionでDNS Server(6)の値を正しいDNSサーバのIPアドレスで設定してください」ということです。
この例では某大手クラウドプラットフォーマーさんのDNSを指定していますが、大人の事情によりマスクしています。
VeloCloud Edgeの設定には Device > DNS Settings という項目があります。
しかし、この項目で設定したDNSサーバのIPアドレスは、VCEがDHCPサーバとして動作している場合にDHCPクライアントへ通知されません。
DHCPクライアントへ通知されるDNSサーバアドレスは、VCEの "Edge LAN IP Address" で設定した自身のIPアドレスです。
もし、ここでDHCPオプションを変更しなければ、以下のようにVCEが何らかの理由で通信不能になった際に名前解決が機能しなくなってしまいます。
しかし、このVRRPとDHCP OptionのDNS設定は少しややこしい問題を引き起こす場合があります。
VeloCloudではアプリケーション識別やURLフィルタリング等、複数の機能で「DNSパケットの中身を監視/記録してトラフィックの扱いを変える」処理を実行します。
裏を返せば、VeloCloudの主要な機能が正しく機能するためには、VCEがDNSパケットの中身を確認できる必要がある、つまりDNSパケットが全てVCEを通過するような経路設計が望ましいということになります。
しかし、これを忠実に守った設定だけを投入すると、上図のようなことが起こる可能性があります。
それならば、DHCPサーバOptionの設定でDNSサーバアドレスを2つ(例えば192.168.101.251 = VCE、X.8.8.8を)通知するよう設定したらどうか。
一応、これでDNSリクエストのブラックホール化(あて先が正しくない等の理由で通信が破棄される状態)は避けられます。
ただし、DHCPクライアント側のDNSリクエストタイムアウトを待たなければ切り替わらない等の不都合が生じます。
他にも様々な不都合が起こり得る可能性がありますが、この辺りのお話はまた別の機会にご紹介することにしようと思います。
とりあえずVCE側のVRRP設定は以上3ステップで完了です。
裏を返せば、これ以上設定できる部分はありません。
Cisco側の設定
今回の動作確認で設定したCiscoルータの設定内容もご紹介します。
基本的にはVCEと同じような内容です。
状態を確認する
VeloCloud側のVRRP状態確認は VCO > Monitor > Edges > HA から行います。
Ciscoルータでは以下のように見えます。
VCEがVR Priority 100でActive、CiscoルータがVR Priority 50でBackupとなっています。
DHCPクライアントのPCではDNSサーバアドレスも設定どおりのパラメータを取得しています。
障害試験
障害試験はLAN側Interface、WAN側Interface、筐体電源OFF等、想定されるすべての障害パターンを網羅するのが一般的です。
しかし、今回はWAN側Interface障害の結果だけを紹介します。
それ以外は動きます。
はい、それはもう(前述のDNS問題を除いて)普通に、期待どおりにVRRPが動きます。
面白くないので割愛します。
通信試験はDHCPクライアントのPCから疑似WANのVyattaへ連続Pingを実行して確認します。
PC-1からPingを連続して実行した状態で、VCEのWAN側Interface : GE3を抜線します。
ここでみなさん、VCEで設定した内容を思い出してください。
Ciscoルータなどで一般的に利用される ”Interface Trackingのような機能” は設定していません。
項目すらありませんでした。
しかし、WAN側Interface Downを検知するとVCEは自身のVR PriorityをDecrement(減少)させ、ちゃんとCiscoルータで言うところのInterface Trackingのような動作を行うことがわかりました。
下記はVCEがVR Priority 100でActiveの状態でWAN側Interface : GE3を抜線した際、Ciscoルータ側で取得したDebugログです。
"192.168.101.251" = VCE が "Priority 100" でVRRP Helloを送信していましたが、WANのDownを検知後に自身のPriorityを10に減少させます。
CiscoルータではPreempt設定が入っていますので、Preempt Delay経過後にActiveへ昇格します。
なお、VCEがWAN InterfaceのDownを検知した際に通知するVR Priorityは10で固定です。
そのためVRRPを設定する際のVR Priorityは少なくとも12より大きい数字を指定する必要があります。
余談ですが、VCEの設定でVR Priorityを10より小さい値、例えば9に設定した場合、VCEがWAN InterfaceのDownを検知するとVR Priorityは10に増えます。
もちろん、この後WAN側InterfaceをLink Upさせた際はVCEのVR Priorityは100に戻り、CiscoルータはBackupに戻りました。
まとめ
今回の記事では、VeloCloudとCiscoルータを組み合わせてVRRPが期待どおりに動作することを確認しました。
VeloCloudのVRRP設定では表示されませんが、CiscoルータのInterface Trackingに該当するような機能も動作することがわかりました。
しかし、途中でご紹介したようなDNSパケットの問題も明らかになりました。
このように、SD-WAN製品群に代表される近年のインテリジェントなネットワーク機器においては、従来のルータやスイッチ製品のように "IPさえ通ればOK" というわけにはいかない、さまざまな考慮が必要とされるようになっているということを認識しておく必要があります。
免責事項
ご紹介している内容は2020年09月15日現在、VeloCloud Version 3.4.3における動作です。
今後のアップデートにより動作が変更される可能性があります。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
