先週私たちが遭遇し、多くのトラブルを引き起こした問題とその突然の解決策を共有します。
したがって、状況はかなり標準的なものであり、会社の中央オフィスは通信チャネルによってリモートユニットに接続されています。 通信(インターネットとVPN)は2人のオペレーターによって提供されます。 1つのチャネルがオフィスに落ちたときのリモートユニットのダウンタイムを最小限に抑えるために、ユニットごとに2つのトンネルDMVPNが構築されました。 動的なネットワーク内ルーティング、eigrp。 セントラルオフィスでは、それぞれ2台のCiscoルーターが使用されています。
リモートユニットの数はそれぞれ約70です。各ルーターは同じ数のトンネルを構築します。 チャネルの平均負荷は、オペレーターが保証する帯域幅の40〜60%です。
DMVPNセットアップは、入門書で説明されているように、かなり標準的に使用されていました。
ハブ:
インターフェースTunnel201
説明-= DMVPN_201 =-
IPアドレス10.10.201.1 255.255.255.0
IPリダイレクトなし
ip mtu 1416
ip hold-time eigrp 1 25
no ip next-hop-self eigrp 1
ip nhrp認証11111
ip nhrp map multicast dynamic
ip nhrp network-id 201
no ip split-horizon eigrp 1
遅延1000
cdp enable
トンネルソースGigabitEthernet0 / 0.2
トンネルモードgreマルチポイント
トンネルキー11111
!
終わり
ルーターEIGRP 1
ネットワーク10.10.201.0 0.0.0.255
ネットワーク192.168.0.0 0.0.1.255
一般に、数か月連続で正常に機能する古典的なスキーム。
www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008014bcd7.shtmlはCiscoの同様の例です。
ある日まで、eigrpのすべての内部ルートが30〜90秒ごとに落ち始めるという問題は発生しませんでした。 同時に、トンネルは完全に立ち、トンネルインターフェイスは完全にpingされました。 次のようなエラー:
* 2013年4月23日15:19:47.759 GMT + 11:%DUAL-5-NBRCHANGE:EIGRP-IPv4 1:Neighbor 10.10.202.9(Tunnel202)is down:hold time expired
* 2013年4月23日15:19:52.707 GMT + 11:%DUAL-5-NBRCHANGE:EIGRP-IPv4 1:ネイバー10.10.202.9(Tunnel202)がアップ:新しい隣接
* 2013年4月23日15:23:56.298 GMT + 11:%DUAL-5-NBRCHANGE:EIGRP-IPv4 1:Neighbor 10.10.202.57(Tunnel202)is up:new adjacency
* 2013年4月23日15:24:43.070 GMT + 11:%DUAL-5-NBRCHANGE:EIGRP-IPv4 1:ネイバー10.10.202.9(Tunnel202)がダウンしています:保持時間が切れています
さらに、両方のルーターで問題が突然発生しました。 タンバリンとダンスを始め、cisco.comを喫煙します。
各ルーターを個別にオーバーロードしても問題は解決しませんでした。
両方のルーターの過負荷は、最後の手段として、かなり長い(最大15〜20分)間隔でブランチを通信せずに放置しましたが、問題に対処するのに役立ちました。 息を吐き、冷静に理由を探し始めることができました。これは、以前のように、さらに数か月間はすべてうまくいくことを望んでいました。
しかし、3日後にはまったく同じように問題が繰り返され、早く幸せになりました。 トンネルと物理インターフェイスのmtuの変更に関するcisco.comからのすべての推奨事項、およびその他のシャーマニスティックキャンペーンは、結果をもたらしませんでした。 かなり長い期間の後、非常に小さなフォーラムの1つで、同様の問題を持つトピックを見つけました。最後のメッセージでは、次のように書かれています。
「ありがとうございます。問題は修正されました。 方法と理由はわかりませんが、ip bandwidth-percent eigrpを含めると役に立ちました。」
とにかく何もすることがなかったので、成功への大きな信頼なしに、トンネルのプロパティで指定されたコマンドを処方し、チャネルを使用するためのパラメーターとして100を示します(とにかく失うものは何もありません)、そして-MIRACLE、それは時計のように働きました。
しかし、多数のフォーラムを調べた後、他の同僚が抱えていたこの問題に繰り返し遭遇しましたが、解決策は説明されませんでした。
当然、将来的には割合の数値を減らしました。
別の自転車を発明したかもしれませんが、この情報は他のどこにも見つかりませんでした。 たぶん他の誰かがそれを必要とするでしょう。 使ってください。