拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

SoftEther VPN に関するご質問はこのフォーラムにお気軽にご投稿ください。
Post Reply
tokohito
Posts: 13
Joined: Sat Oct 04, 2014 1:06 pm

拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by tokohito » Thu Dec 15, 2016 2:06 pm

お世話になっております、よろしくお願いします。

2拠点間をServer-Bridge形式でL2延伸し利用しています。
DHCP/RAプロトコルのみSoftetherVPNのセキュリティポリシーで各拠点間を越えないようフィルタし、
それ以外の通信についてはマルチキャスト/ブロードキャスト共に制限しないという設計方針で
構築したのですが、なぜかVRRPのHelloパケットの一部が拠点を越えられないシーンが発生し困っています。
CIFSなど、その他日常的に使っているプロトコルで問題が発生したことはありません。
主だった設定項目は以下の通りです。

■セキュリティポリシー
・DHCPパケットをフィルタリング(IPv4):有効
・ブロードキャスト数を制限しない:有効
・ルータ要請/広告パケットをフィルタリング(IPv6):有効
・ルータ広告パケットをフィルタリング(IPv6):有効
・DHCPパケットをフィルタリング(IPv6):有効

■仮想HUB管理オプション
全て0に設定

■ログ保存設定
・パケットログ
全て「ヘッダ情報のみ」を選択

■ホストOS上の設定
・iptables/ufw無効化
・SELinux:Disabled

■SoftetherVPNバージョン
Softether VPN 4.0(Ver 4.21, Build 9613)

SoftetherVPNおよびホストのLinux OSのログを確認しましたが、
VRRPのパケットを落としているようなログは出力されていませんでした。

また懸案のVRRPパケットも2拠点間で一切転送されていないわけではなく、
拠点A→拠点Bへの転送のみ成功しているケースと、拠点B→拠点Aへの
転送のみ成功しているケースとがあります(ただし双方向は一度も成功例無し)。
転送方向が切り替わるタイミングは各拠点のVRRPルータを再起動した
タイミング等で発生しますが、正確なところはつかめていません。
各拠点のローカルセグメントにいるホストで個々にパケットダンプを取得する限りでは
各VRRPルータのアドバタイズメント(Hello送出)はちゃんと動作しているようです。

SoftetherVPNでServer-Bridge双方向にVRRPを転送させる方法、もしくは上記
トラブルの切り分け方法について何か思い当たることがあればお教えください。

以上、よろしくお願いします。

cedar
Site Admin
Posts: 845
Joined: Sat Mar 09, 2013 5:37 am

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by cedar » Fri Dec 16, 2016 9:15 am

使用されている OS は何でしょうか。
また、VM は使用されているでしょうか。
また、VRRPを使用するルーターは、SoftEther VPN の動作する Linux とは別のホストでしょうか。

tokohito
Posts: 13
Joined: Sat Oct 04, 2014 1:06 pm

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by tokohito » Fri Dec 16, 2016 3:08 pm

お世話になっております。

>使用されている OS は何でしょうか。
CentOS 6.8(Server), Ubuntu Server16.04(Bridge)です。

>また、VM は使用されているでしょうか。
使用しておりません。

>また、VRRPを使用するルーターは、SoftEther VPN の動作する Linux とは別のホストでしょうか。
拠点A、拠点B共に別のホストです。

以上、よろしくお願いします。

cedar
Site Admin
Posts: 845
Joined: Sat Mar 09, 2013 5:37 am

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by cedar » Sat Dec 17, 2016 3:12 am

構成自体には特に問題はないように思われます。
アドバタイズメントがローカル側ではキャプチャされているということですが、対向側のホストではキャプチャされていないでしょうか。

tokohito
Posts: 13
Joined: Sat Oct 04, 2014 1:06 pm

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by tokohito » Sat Dec 17, 2016 3:29 am

お世話になっております。

>アドバタイズメントがローカル側ではキャプチャされているということですが、対向側のホストではキャプチャされていないでしょうか。
はい。

もう少し補足すると、「拠点A側で拠点AとB両方のルータからのアドバタイズがキャプチャできてるが、
拠点B側では拠点Bのルータからのアドバタイズしかキャプチャできない」ケースと、逆に「拠点B側で
拠点AとB両方のルータからのアドバタイズがキャプチャできてるが、拠点A側では拠点Aのルータからの
アドバタイズしかキャプチャできない」ケースがあります。
その他情報については最初のポストをご覧ください。

以上、よろしくお願いします。

cedar
Site Admin
Posts: 845
Joined: Sat Mar 09, 2013 5:37 am

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by cedar » Sat Dec 17, 2016 4:15 am

VPN セッション自体も、その VRRP ルータを介して行われているでしょうか。
そうすると、状態が変わるきっかけは VPN セッションの切断という可能性も考えられます。

tokohito
Posts: 13
Joined: Sat Oct 04, 2014 1:06 pm

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by tokohito » Sat Dec 17, 2016 2:44 pm

お世話になっております。

>VPN セッション自体も、その VRRP ルータを介して行われているでしょうか。
はい、何れの拠点もVRRPルータの配下にSoftetherVPNの終端ホストがぶら下がっています。

>そうすると、状態が変わるきっかけは VPN セッションの切断という可能性も考えられます。
SoftetherVPNのトンネルセッションが確立している状態で、ルータの
VRRP設定を削除/再有効化することでどのような変化があるか確かめてみました。
結果、最初にVRRPを有効化したルータのアドバタイズはほどなく両拠点で
パケットがキャプチャされるようになるのが確認できましたが、後からVRRPを
有効化したルータ側のアドバタイズはSoftetherVPNのトンネルを挟んだ
反対側の拠点ではキャプチャできませんでした。
これは拠点Aルータ→拠点Bルータの順でVRRPを有効化した場合でも、
その逆の順序で有効化した場合でも同じで、再現性がありました。

不可解な挙動ですが、何か思いつくことがあればお教えください。

以上、よろしくお願いします。

cedar
Site Admin
Posts: 845
Joined: Sat Mar 09, 2013 5:37 am

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by cedar » Sun Dec 18, 2016 8:32 am

一方にしかパケットが流れないという挙動から考えて、仮想 HUB のスイッチングハブとしての
動作で、MAC アドレスの学習に関係する問題ではないかという気がします。

それぞれのルータの発するアドバタイズパケットの送信元と送信先のMACアドレスは何になっているでしょうか。

tokohito
Posts: 13
Joined: Sat Oct 04, 2014 1:06 pm

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by tokohito » Sun Dec 18, 2016 1:15 pm

お世話になっております。

> 一方にしかパケットが流れないという挙動から考えて、仮想 HUB のスイッチングハブとしての
> 動作で、MAC アドレスの学習に関係する問題ではないかという気がします。
ドンピシャでした!

> それぞれのルータの発するアドバタイズパケットの送信元と送信先のMACアドレスは何になっているでしょうか。
何れのVRRPルータもソースMACが(00:00:5e:00:01:01)、ディストが(01:00:5e:00:00:12)で
送出されていました。よく考えてみれば、これってVRRPの規定動作ですね(RFC3768)。
ちなみにソースの末尾2桁は設定したVRRP ID(今回は1)で、ディストはVRRPが使用する
予約されたのMACアドレスのようです。

原因はわかりましたが、SoftetherVPNのHUB設定でこれを回避する手立てはあるのでしょうか?
以上、よろしくお願いします。

cedar
Site Admin
Posts: 845
Joined: Sat Mar 09, 2013 5:37 am

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by cedar » Mon Dec 19, 2016 1:39 pm

VRRPでは、マスタルータが決定した後は、アドバタイズメントを送信するのはマスタールータのみとなるようです。
なので、一方向にしかアドバタイズメントが流れないのは、正常な動作なのではないでしょうか。
http://www.itbook.info/network/vrrp2.html

tokohito
Posts: 13
Joined: Sat Oct 04, 2014 1:06 pm

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by tokohito » Mon Dec 19, 2016 4:21 pm

お世話になっております。

> VRRPでは、マスタルータが決定した後は、アドバタイズメントを送信するのはマスタールータのみとなるようです。
> なので、一方向にしかアドバタイズメントが流れないのは、正常な動作なのではないでしょうか。
VRRPのメンバー設定をされた各ルータ同士がアドバタイズを交換し、
それに伴ってマスタールータが決定した後ならおっしゃる通りかと思います。

ただ現在の状況はSoftetherVPNを挟んだ拠点A-B間でアドバタイズが
到達しないため、各VRRPルータは自身がマスターであると主張し続け
どちらもアドバタイズを発信し続けているということだと理解していますが
いかがでしょうか?
(各VRRPルータに設定されたpriorityやpreemptによって挙動は
当然異なりますが、典型例として上記を挙げさせていただきました)

以上、よろしくお願いします。

cedar
Site Admin
Posts: 845
Joined: Sat Mar 09, 2013 5:37 am

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by cedar » Thu Dec 22, 2016 8:44 am

双方の仮想 HUB の仮想 HUB 拡張オプションの「DisableCheckMacOnLocalBridge」を1に設定してみてください。
これで、他のポートに学習されているMACアドレスが、ローカルブリッジから届いた時に無視しなくなります。

LAN カードドライバ(またはハードウェア)が、送信したパケットの複製を送り返してくるケースがあるため、その対策としてデフォルトでは。ローカルブリッジは他のポートに学習されているMACアドレスのパケットを無視する仕様になっています。

tokohito
Posts: 13
Joined: Sat Oct 04, 2014 1:06 pm

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by tokohito » Fri Dec 23, 2016 11:12 pm

お世話になっております。

> 双方の仮想 HUB の仮想 HUB 拡張オプションの「DisableCheckMacOnLocalBridge」を1に設定してみてください。
> これで、他のポートに学習されているMACアドレスが、ローカルブリッジから届いた時に無視しなくなります。
設定してみたところ、正常にVRRPが機能するようになりました。ありがとうございます!

> LAN カードドライバ(またはハードウェア)が、送信したパケットの複製を送り返してくるケースがあるため、その対策として
> デフォルトでは。ローカルブリッジは他のポートに学習されているMACアドレスのパケットを無視する仕様になっています。
この件について、SoftetherVPN特有の問題を引き起こす可能性はありますか?
複製パケットを送り返してくるだけなら物理HUBであっても状況に大差ないように
思えますが、SoftetherVPNが既知のMACからのパケットを無視するのは
どちらかというとトラフィック削減を目的にしているのでしょうか?

以上、よろしくお願いします。

cedar
Site Admin
Posts: 845
Joined: Sat Mar 09, 2013 5:37 am

Re: 拠点間L2延伸環境におけるマルチキャスト/ブロードキャストの制限について

Post by cedar » Sat Dec 24, 2016 9:05 am

既知の MAC アドレスからのパケットを無視するのは、前述の通り、ローカルブリッジから送信したパケットをそのまま受信したかのように見せてしまうポートへの対策です。
このようなパケットの反射が起きると、MAC アドレスの学習が正常に行われず、通信が行えなくなるケースがあります。
また、セグメント内に複数の反射を起こすポートがあると、ブロードキャストパケットが反射し続けてブロードキャストストームを起こす可能性があります。

理屈で言えば、送信したパケットをすべて覚えていて、それと同じパケットが戻ってきたときだけ無視すればよいのですが、必要な処理能力が高くなりすぎるため、他のポートで学習されているパケットを無視するという実装になっています。

Post Reply