WAN回線障害時に備える(自動バックアップ機能)
インデックス
症状：バックアップ回線での通信ができない
ここでは、RTX1200の基本的な設定が終了し、バックアップ回線での通信ができないケースでのトラブルシューティングを提供します。
状態確認方法
この項目ではコマンドによる状態確認方法を紹介します。表示例は正常動作時のものです。
トラブル発生時の状態と比較することで、問題解決の助けとなります。
1-1 バックアップの状態を確認する。
RTX1200の"show status backup"コマンドを実行し、バックアップの状態を確認します。
[正常時]メイン回線からバックアップ回線への切り替わりの際に以下のように変化します。
|
(1) |
|
[解説] |
1-2 NATディスクリプタの状態を確認する。
RTX1200の"show nat descriptor address"コマンドを実行し、内容を確認します。
[正常時]メイン回線からバックアップ回線への切り替わりの際に以下のように変化します。
|
(1) (2) (3) |
||||
| No. | 内側アドレス | 使用中のポート数 | 制限数 | 種別 |
|---|---|---|---|---|
|
1 |
192.168.0.1 |
3 |
20000 |
dynamic |
| 有効なNATディスクリプタテーブルが2個ありました | ||||
| [解説] (1)メイン回線接続時の状態です。 PP[01]側ではIPアドレス192.168.100.200を取得しています。 バックアップ回線は接続していませんので、PP[02]側ではIPアドレスは取得していません。 (2)障害によりメイン回線が切断された時の状態です。バックアップ回線は接続されていません。 PP[01]、PP[02]側共にIPアドレスを取得していません。 (3)メイン回線が切断され、バックアップ回線を接続した時の状態です。 PP[01]側ではIPアドレスを取得していません。PP[02]側ではIPアドレス172.16.0.100を取得しています。 |
||||
1-3 経路情報を確認する。
RTX1200の"show ip route"コマンドを実行し、経路情報を確認します。
[正常時]
| (1) # show ip route |
||||
| 宛先ネットワーク | ゲートウェイ | インタフェース | 種別 | 付加情報 |
|---|---|---|---|---|
|
default |
- |
PP[01] |
static |
|
|
192.168.100.1/32 |
- |
PP[01] |
temporary |
|
| (2) # show ip route |
||||
| 宛先ネットワーク | ゲートウェイ | インタフェース | 種別 | 付加情報 |
|
default |
- |
PP[01] |
static |
|
| (3) # show ip route |
||||
| 宛先ネットワーク | ゲートウェイ | インタフェース | 種別 | 付加情報 |
|
default |
- |
PP[01] |
static |
|
|
172.16.0.1/32 |
- |
PP[02] |
temporary |
|
| [解説] (1)メイン回線接続時の状態です。 プロバイダ側機器のIPアドレス192.168.100.1が表示されています。 (2)メイン回線が切断された時の状態です。バックアップ回線は接続されていません。 コマンドで設定されたデフォルト経路のみが表示されています。 (3)メイン回線が切断され、バックアップ回線を接続した時の状態です。 プロバイダ側機器のIPアドレス172.16.0.1が表示されています。 |
||||
1-4 デバッグログを確認する。
[バックアップ切り替わり成功時ログの例]
|
# show log |
|
[解説] |
トラブル原因と対処方法
この項目では各トラブル発生時の状態と、原因及びその解決方法を紹介します。
正常時の状態と比較することで、問題解決の助けとなります。
2-1 バックアップコマンド未設定による、バックアップ失敗
このケースは、バックアップコマンド未設定による、バックアップ失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。
ログの確認
※ログ採取の前にRTX1200に"syslog notice on"を設定しておきます。
|
(1) (2) |
|
[解説] |
対処方法
以下のバックアップコマンドを設定してください。
|
pp select 1 |
2-2 NATディスクリプタの設定不足による、バックアップ失敗
このケースは、NATディスクリプタの設定不足による、バックアップ失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。
ケース1
|
# show nat descriptor address |
|
[解説] |
対処方法
PP2に対してNATディスクリプタを適用してください。
|
pp select 2 |
2-3 バックアップ回線に切り替わっているが、通信ができない。
このケースは、バックアップ回線側IPアドレスの取得失敗によるバックアップ接続失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。
| (1) 2010/04/02 17:46:54: PP[01]: switched to backup 2010/04/02 17:46:56: PPPOE[01] Disconnecting, cause [PPP: LCP Keepalive failure] 2010/04/02 17:46:56: PPPOE[01] SEND PADT 2010/04/02 17:46:56: 11 a7 0e 58 00 00 2010/04/02 17:46:56: PPPOE[01] Cannot send packet (LAN2 link down) 2010/04/02 17:46:57: PPPOE[01] Disconnected, cause [PPP: LCP Keepalive failure] 2010/04/02 17:46:57: PPPOE[01] Connecting to PPPoE server 2010/04/02 17:46:57: PPPOE[01] SEND PADI 2010/04/02 17:46:57: 11 09 00 00 00 0e 01 01 00 00 01 03 00 06 59 e1 2010/04/02 17:46:57: 93 76 fd 4a 2010/04/02 17:46:57: PPPOE[01] Cannot send packet (LAN2 link down) 2010/04/02 17:47:00: PPPOE[01] SEND PADI 2010/04/02 17:47:00: 11 09 00 00 00 0e 01 01 00 00 01 03 00 06 59 e1 2010/04/02 17:47:00: 93 76 fd 4a 2010/04/02 17:47:00: PPPOE[01] Cannot send packet (LAN2 link down) 2010/04/02 17:47:06: PPPOE[01] SEND PADI 2010/04/02 17:47:06: 11 09 00 00 00 0e 01 01 00 00 01 03 00 06 59 e1 2010/04/02 17:47:06: 93 76 fd 4a 2010/04/02 17:47:06: PPPOE[01] Cannot send packet (LAN2 link down) 2010/04/02 17:47:18: PPPOE[01] SEND PADI 2010/04/02 17:47:18: 11 09 00 00 00 0e 01 01 00 00 01 03 00 06 59 e1 2010/04/02 17:47:18: 93 76 fd 4a 2010/04/02 17:47:18: PPPOE[01] Cannot send packet (LAN2 link down) 2010/04/02 17:47:30: PPPOE[01] SEND PADI 2010/04/02 17:47:30: 11 09 00 00 00 0e 01 01 00 00 01 03 00 06 59 e1 2010/04/02 17:47:30: 93 76 fd 4a 2010/04/02 17:47:30: PPPOE[01] Cannot send packet (LAN2 link down) 2010/04/02 17:47:42: PPPOE[01] SEND PADI 2010/04/02 17:47:42: 11 09 00 00 00 0e 01 01 00 00 01 03 00 06 59 e1 2010/04/02 17:47:42: 93 76 fd 4a 2010/04/02 17:47:42: PPPOE[01] Cannot send packet (LAN2 link down) 2010/04/02 17:47:54: PPPOE[01] Disconnected, cause [PPPoE: PADI Timeout] 2010/04/02 17:48:29: PP[02] IP Commencing: 2010/04/02 17:48:29: PP[02] IP Commencing: UDP 192.168.0.1:10538 > 172.16.0.1 2010/04/02 17:48:29: 45 00 00 3d 00 04 00 00 ff 11 91 96 c0 a8 00 01 2010/04/02 17:48:29: dd 71 8b fa 29 2a 00 35 00 29 7c 0f 00 02 01 00 2010/04/02 17:48:29: 00 01 00 00 00 00 00 00 03 77 77 77 05 79 61 68 2010/04/02 17:48:29: 6f 6f 02 63 6f 02 6a 70 00 00 01 00 01 2010/04/02 17:48:29: PP[02] Calling 1492 with 1B mode 2010/04/02 17:48:29: BRI[1] SEND [SETUP] 2010/04/02 17:48:29: 08 01 01 05 04 02 88 90 18 01 83 6c 02 00 80 70 2010/04/02 17:48:29: 05 80 31 34 39 32 7c 02 88 90 2010/04/02 17:48:30: BRI[1] RECV [CALL PROC] 2010/04/02 17:48:30: 08 01 81 02 18 01 89 2010/04/02 17:48:30: BRI[1] RECV [ALERT] 2010/04/02 17:48:30: 08 01 81 01 2010/04/02 17:48:30: BRI[1] RECV [CONN] 2010/04/02 17:48:30: 08 01 81 07 2010/04/02 17:48:30: PP[02] HDLC Opening, ch = A 2010/04/02 17:48:30: PP[02] ISDN connect, going PPP phase 2010/04/02 17:48:30: PP[02] SEND LCP ConfReq in STARTING 2010/04/02 17:48:30: ff 03 c0 21 01 01 00 0e 01 04 07 00 05 06 34 ae 2010/04/02 17:48:30: a1 4b 2010/04/02 17:48:33: PP[02] SEND LCP ConfReq in REQSENT 2010/04/02 17:48:33: ff 03 c0 21 01 01 00 0e 01 04 07 00 05 06 34 ae 2010/04/02 17:48:33: a1 4b 2010/04/02 17:48:33: PP[02] RECV LCP ConfReq in REQSENT 2010/04/02 17:48:33: ff 03 c0 21 01 01 00 16 01 04 05 f4 03 05 c2 23 2010/04/02 17:48:33: 05 13 09 03 00 d0 52 03 44 e8 2010/04/02 17:48:33: PP[02] SEND LCP ConfRej in REQSENT 2010/04/02 17:48:33: ff 03 c0 21 04 01 00 0d 13 09 03 00 d0 52 03 44 2010/04/02 17:48:33: e8 2010/04/02 17:48:33: PP[02] RECV LCP ConfAck in REQSENT 2010/04/02 17:48:33: ff 03 c0 21 02 01 00 0e 01 04 07 00 05 06 34 ae 2010/04/02 17:48:33: a1 4b 2010/04/02 17:48:33: PP[02] RECV LCP ConfReq in ACKRCVD 2010/04/02 17:48:33: ff 03 c0 21 01 02 00 0d 01 04 05 f4 03 05 c2 23 2010/04/02 17:48:33: 05 2010/04/02 17:48:33: PP[02] SEND LCP ConfAck in ACKRCVD 2010/04/02 17:48:33: ff 03 c0 21 02 02 00 0d 01 04 05 f4 03 05 c2 23 2010/04/02 17:48:33: 05 2010/04/02 17:48:33: PP[02] RECV CHAP Challenge in CS_LISTEN/SS_CLOSED 2010/04/02 17:48:33: ff 03 c2 23 01 01 00 1f 10 72 6d 90 67 07 66 1f 2010/04/02 17:48:33: ff 9d 9f 7f 58 78 d2 09 65 6c 61 63 30 31 6d 6a 2010/04/02 17:48:33: 30 30 30 2010/04/02 17:48:33: PP[02] SEND CHAP Response in CS_LISTEN/SS_CLOSED 2010/04/02 17:48:33: ff 03 c2 23 02 01 00 2d 10 f0 7a 99 3a 56 74 57 2010/04/02 17:48:33: 78 6c 0a 86 43 75 1a 8a 62 72 38 33 69 72 65 30 2010/04/02 17:48:33: 68 40 69 70 63 6f 6e 2e 6f 63 6e 2e 6e 65 2e 6a 2010/04/02 17:48:33: 70 2010/04/02 17:48:33: PP[02] RECV CHAP Success in CS_OPEN/SS_CLOSED 2010/04/02 17:48:33: ff 03 c2 23 03 01 00 04 2010/04/02 17:48:33: PP[02] SEND CCP ConfReq in STARTING 2010/04/02 17:48:33: ff 03 80 fd 01 01 00 09 11 05 00 01 03 2010/04/02 17:48:33: PP[02] SEND IPCP ConfReq in STARTING 2010/04/02 17:48:33: ff 03 80 21 01 01 00 10 81 06 00 00 00 00 83 06 2010/04/02 17:48:33: 00 00 00 00 2010/04/02 17:48:33: PP[02] SEND IPV6CP ConfReq in STARTING 2010/04/02 17:48:33: ff 03 80 57 01 01 00 0e 01 0a 02 a0 de ff fe 37 2010/04/02 17:48:33: b5 0a 2010/04/02 17:48:33: PP[02] RECV IPCP ConfReq in REQSENT 2010/04/02 17:48:33: ff 03 80 21 01 01 00 0a 03 06 db a0 03 09 2010/04/02 17:48:33: PP[02] SEND IPCP ConfAck in REQSENT 2010/04/02 17:48:33: ff 03 80 21 02 01 00 0a 03 06 db a0 03 09 2010/04/02 17:48:33: PP[02] RECV LCP ProtRej in OPENED 2010/04/02 17:48:33: ff 03 c0 21 08 01 00 0f 80 fd 01 01 00 09 11 05 2010/04/02 17:48:33: 00 01 03 2010/04/02 17:48:33: PP[02] RECV IPCP ConfNak in ACKSENT 2010/04/02 17:48:33: ff 03 80 21 03 01 00 10 81 06 dd b8 19 01 83 06 2010/04/02 17:48:33: de 92 23 01 2010/04/02 17:48:33: PP[02] SEND IPCP ConfReq in ACKSENT 2010/04/02 17:48:33: ff 03 80 21 01 02 00 10 81 06 dd b8 19 01 83 06 2010/04/02 17:48:33: de 92 23 01 2010/04/02 17:48:33: PP[02] RECV LCP ProtRej in OPENED 2010/04/02 17:48:33: ff 03 c0 21 08 02 00 14 80 57 01 01 00 0e 01 0a 2010/04/02 17:48:33: 02 a0 de ff fe 37 b5 0a 2010/04/02 17:48:33: PP[02] RECV IPCP ConfAck in ACKSENT 2010/04/02 17:48:33: ff 03 80 21 02 02 00 10 81 06 dd b8 19 01 83 06 2010/04/02 17:48:33: de 92 23 01 2010/04/02 17:48:33: PP[02] PPP/IPCP up (Local: None, Remote: 172.16.0.1) 2010/04/02 17:48:33: PP[02] Local PP IP address 0.0.0.0 2010/04/02 17:48:33: PP[02] Remote PP IP address 172.16.0.1 |
||||
| (2) # show nat descriptor address 参照NATディスクリプタ : 1, 適用インタフェース : PP[01](1) Masqueradeテーブル 外側アドレス: ipcp ポート範囲: 60000-64095, 49152-59999, 44096-49151 |
||||
| 参照NATディスクリプタ : 1, 適用インタフェース : PP[02](1) Masqueradeテーブル 外側アドレス: ipcp ポート範囲: 60000-64095, 49152-59999, 44096-49151 1個使用中 |
||||
| No. | 内側アドレス | 使用中のポート | 制限数 | 種別 |
|---|---|---|---|---|
|
1 |
192.168.0.1 |
1 |
20000 |
dynamic |
| 有効なNATディスクリプタテーブルが2個ありました | ||||
| [解説] (1)ログには"PP[02] PPP/IPCP up"が表示され、バックアップ回線が接続していることを確認できますが、"PP[02] Local PP IP address 0.0.0.0"の表示からWAN側のIPアドレスを取得していないことが分かります。 (2)"show nat descriptor address"コマンドでNATディスクリプタの状態を確認すると、PP[02}では外側アドレスが表示されていません。 参考：正常時のNATディスクリプタの状態、正常時のログ |
||||
対処方法
フィルタを正しく設定してください。
|
pp select 2 |
技術情報(RTpro)