Hoster-JP

NetScreen FireWall L2モード冗長化の構成で、切り替わりが正常に行われたにも関わらず通信が暫くできないことはありませんか？その原因と対策について記載します。

試験環境

使用した機器は以下の通りです。

• NS1,NS2　－Netscreen50　Version:5.4.0r15
• L2SW1,L2SW2　－Cisco Catalyst 2960
• R1,R2　－Cisco 830 Router

試験の構成

図1試験構成

試験結果

Netscreen FW自体の切り替わりは正常に行われるが、 切り替わり後にスイッチのMACテーブルが直ぐには書き変わらないため、FW冗長化の設定及び障害の内容によって、しばらく通信できない場合があります。

意図した切り替えから回復する方法としては、同じブロードキャストドメインにある機器（スイッチやホスト）のMACテーブルをFWの切り替えと同時にクリアする。

機器障害からの回復には「同じブロードキャストドメインにある機器のMACテーブルのAgeタイムアウトを待つ」又は「同じブロードキャストドメインにある総ての関連する機器が一度パケットを投げるのを待つ」事になります。

正常時の通信

NS1はMaster、NS2はBackupで、R1とR2間のトラフィックはNS1を経由して通信がOKな状態です。

切り替え後の通信-ポート障害

ある障害（例：NS1のeth2がDown）が発生したら、FWの切り替わり自体は正常に行われるが、切り替わり後R2からR1へPING通信がN/Gになります。逆にR1からR2へPINGパケットが流れたら、両方通信が正常になります。

切り替え戻す通信1(Preemptしない)

NS1のeth2をLinkupしてNSRPをPreemptしない場合、切り替えが戻りませ ん。   NS2はMaster、NS1はBackupで、L2SW１とL2SW2を持っているMACアドレスがNS2側のため、通信両方OKです。

切り替え戻す通信2(Preemptする)

NS1のeth2をLinkup してNSRPをPreemptする場合、切り替えが戻ります。NS１はMaster、NS2はBackupで、L2SW１とL2SW2を持っているMACアドレスがNS2側のため、通信両方N/Gです。

切り替え後の通信-FW障害

NS1がDownしたら、FWが切り替えします。NS1はDown、NS2はMasterで、両方通信OKです。

各状態の詳細分析

NS1	Master	NS2	Backup
R1→R2通信	OK	R2→R1通信	OK

図2正常時の情報構成

ポートDown時

最初－正常の時
NS1	Master	NS2	Backup
NS1のeth2ポートをDownします
NS1	Backup	NS2	Master
①　先ずR2 → R1 PING  N/G
②　其後R1 → R2 PING  OK
③　其後R2 → R1 PING  OK

－　NS1のeth2がDownしましたら、FWはNS1からNS2へ正常に切り替えします。L2SW1にてFa0/1がDownしたため、Fa0/1元々BindしたMACアドレス「0015.629d.4f64」が無くなります。またNS2からGratuitous Arpが発生しないためL2SW1のFa0/5にてMACアドレスがありません。

－　其の時点でR2からR1へPING　Request 10.9.1.254。先ずR2は自分のARP表を調べて、10.9.1.254　行くMACアドレスは　　0014.6986.d091です。PacketがR2からL2SW2へ行きます。L2SW2にて、L2SW2 のMAC表より、0014.6986.d091行く場合Fa0/13ポートへ行きます。PacketがL2SW2からNS1へ行きます。NS1にて、NS1はBackupの状態になっているため、Packetを転送しません。よって、R2からR1へPING 10.9.1.254　通信がN/Gになります。

－　その後R1からR2へPING Request 10.9.1.254。先ずR1を自分のARP表を調べて、10.9.1.254へ行くMACアドレスは0015.629d.4f64です。PacketがR1からL2SW1へ行きます。PacketがL2SW1にて、L2SW1のMAC表をより、0015.629d.4f64 MACアドレス情報がないため、全ポートへPing Requestを出します。L2SW1のFe0/5を経由してPing　Requestが　NS2へ行きます、NS2はMaster状態のためPing RequestがL2SW2へ転送します。L2SW2にて、自分のMAC表を調べて、0015.629d.4f64行く場合のポートがFE0/16です。よって、Ping RequestがL2SW2からR2へ行きます。R1のArp Requestより、R2からArp Responseを回答します。

上記R1からR2までのPing Requestより、L2SW1にて0015.629d.4f64はFa0/5とBindします。またL2SW2のFa0/17は0014.6986.d091とBindします。よって、R1からR2へPING 10.9.1.254通信OK。R1からR2のPING Requestより、L2SW2のMAC Tableを再直したので、R2からR1へのPING通信もうOKです。

通信回復方法―片道障害が発生した場合、障害が発生した側から通信を行って、両方通信が回復します。

DownしたポートLinkupした時－Preemptしない場合

※NSRPのPreemptを設定しません場合、FW切り替え戻りません

最初－NS1のeth2ポートをDownしました
NS1	Backup	NS2	Master
NS1→NS2通信	OK	NS2→NS1通信	OK
NS1のeth2ポートをLinkupします
NS1	Backup	NS2	Master
NS1→NS2通信	OK	NS2→NS1通信	OK

図4 切り替え戻る構成図1-Preemptしません

DownしたポートLinkupした時－Preempt有り

※NSRPのPreemptを設定しません場合、FW切り替え戻ります。

最初－NS1のeth2ポートをDownしました
NS1	Backup	NS2	Master
NS1→NS2通信	OK	NS2→NS1通信	OK
NS1のeth2ポートをLinkupします
NS1	Master	NS2	Backup
NS1→NS2通信	N/G	NS2→NS1通信	N/G

NS1のeth2をLinkupしてNSRPのPreemptする場合、NS1はMaster、NS2はBackupです。但しSWが持っているMACアドレスがNS2側のため、通信両方N/Gです。

この時点の通信回復方法－片道のL2SW2のMAC Tableをクリアして、R2からR1へ通信を流れて、両方通信が回復します。

FW Down時

最初－正常の時
NS1	Master	NS2	Backup
FW NS1　Downする時
NS1	Down	NS2	Master
NS1→NS2通信	OK	NS2→NS1通信	OK

NS1がDowｎしましたら、ポートeth2とeth3両方がDownします。L2SW1にR2のMACアドレスがなくなります。L2SW2にR1のMACアドレスがなくなります。よって、R1（或はR2） からR2へのPING Requestを流れたら、L2SW1にてR2のMACアドレスがありませんため、全てのポートがPING Requestを出します。PING Request NS2経由でR2まで出して、R2からPING Replyを回答して通信OKになります。