EIGRPのコンバージェンスについて

[j.takahashi]

EIGRPのコンバージェンスについてどなたか教えて頂けないでしょうか。

あるキャリアL2網に約30台のEIGRPルータが接続されており、その内の数拠点(3拠点)は

別のL2網で二重化されている状態です。

一重化拠点から見るとeigrpネイバーは29台

二重化拠点から見るとeigepネイバーは31台(自分除く一重化29+二重化2拠点)

として見えているかと思いますが、その内二重化拠点の片系のキャリア向け回線

が断となった場合に、他拠点から見るとhold timeoutでネイバーダウンとなるかと

思います。

その際には各拠点のルータはダウンしていないネイバー全て(28台～30台)にクエリ

ーを投げてリプライを待つと考えて良いでしょうか？

(通常は他のネイバーもダウンしたネイバー(サクセサ)も同一インターフェースの先

に見えています)

また、実はその中に監視専用のルータが存在していてＣｓｉｃｏ1812のＥｔｈｅｒポート(サブ

インターフェース)で、契約回線512Kbps(bandwidth 512を物理I/F、サブI/Fに指定済み)

で受けているのですが、どうやらそのルータが時々クエリーに対するリプライを返せない

で、他ルータがSIA状態となっているようです。

監視用なので、当然ネイバーダウン時等には各ルータからのTRAP/syslog等も同時に

飛んできます。

Cisco1812、回線512Kbpsと言ったリソースで30台程のネイバー、ルートは約500と言った

条件でサマライズはしていません。

上記条件で、網内のネイバーダウン時にクエリーへのリプライが返せなくなるのは想定さ

れる動作でしょうか？

※監視ルータ配下(LAN側)にはEIGRPネイバーは存在しません。

長文になってしまったので質問を要約すると

(1)約30台がL2網で接続された構成でネイバーダウンが発生すると、フルメッシュ的に

クエリーを投げ、それぞれが全てのリプライを待つのでしょうか？

(2)Cisco1812、回線512Kbpsと言ったリソースで30台程のネイバー、ルートは約500で

サマライズ無しと言った条件ではEIGRPのクエリー処理を行うのが現実的に無理なので

しょうか?(過去の経験論等でも構いません)

※ネイバーダウンと同時に監視パケットも飛んできます。

以上、ご意見と頂ければ幸いです。

[t-yamashita]

まず、(1) のご質問についてですが、マルチキャストにより全ネイバーにクエリがフラッディングされます。

そして、全ネイバーから Reply がないと、ACTIVE 状態となり、コンバージェンスに失敗します。

(2）については、経験上、ルータの処理能力よりも、ユーザーのトラフィック利用状況の影響が大きいと考えます。

例えば、ユーザートラフィックにより、帯域が圧迫され、遅延が発生し、その結果 Reply が到達できない可能性は十分にあります。

帯域に十分な余裕がある場合は、ハードウェア・ソフトウェアの不具合の可能性も考えられますので、

情報を収集し、TAC ケースオープンされることを推奨します。

対策についてですが、二重化を行っていないルータ（特に監視ルータ）については、eigrp stub の設定を行い、クエリを受け付けないようにしてはどうでしょうか？

あくまで応急処置になりますが、もしよければご検討ください。

[j.takahashi]

早速のご回答ありがとうございます。

(1)に関しましては理解致しました。ありがとうございます。

(2)に関しましては、おっしゃるように、監視ルータに関しては配下にネイバーいない事が確認

できましたのでstubで対応しようとはしておりますが、原因が判明していない事から仮にStub

対応できない拠点のルータが要因で同様の事象になった場合を危惧しております。

単に監視ルータだから「事象発生時にはTRAP/syslog + EIGRP クエリーが飛んでくる事が要因」

と理由が明確になればいいのですが、まだその結論には至っておりません。

ちなみにクエリーも再送されると思うのですが、再送間隔は可変(show ip eigrp neigborで確認できる

RTO(単位はmsでしょうか?))であり、再送回数は16回と理解してよろしいでしょうか？

ご参考までに、異常であったルータは以下のように見えており、RTO=5000 キューで待ちが発生して

いました。

H   Address                    Interface       Hold  Uptime   SRTT   RTO  Q  Seq

8   192.168.xxx.xxx         Fa0/0.599         11 6d17h    1292   5000  9  7163

監視ルータ配下(LAN側)にはネイバーいないにも関わらず、リトライアウトするまで応答でき

ない物か？といささか疑問に思っており、「回線」「機種」に依存する問題となると、他拠点で

気になる所があり、別途検討しなくてはいけないと思っております(今更ネイバー減らせませんし)。

再現試験はいずれ必要であると思っておりますが、まずは机上で分かる範囲で調べており

アドバイス等あればお願いします。

また、本コミュニティのスコープを逸脱していたら申し訳有りません。

[t-yamashita · Accepted solution]

>再送間隔は可変(show ip eigrp neigborで確認できる RTO(単位はmsでしょうか?))であり、再送回数は16回と理解してよろしいでしょうか？

ご指摘のとおりです。

>原因が判明していない事から仮に Stub 対応できない拠点のルータが要因で同様の事象になった場合を危惧しております

今回の事象（SIA）の【問題】は以下のいずれかにあると考えます。

①監視ルータに Query が到達していない。

②監視ルータに Query は到達しているが、処理ができない。

③監視ルータからの Reply が、発信元に到達していない。

④監視ルータからの Reply が、発信元に到達しているが、処理ができない。

問題を明確化するために、以下について調査が必要です。

①②監視ルータの当該インターフェースにおけるトラフィックの利用状況を確認する。

「回線が過負荷状態になる事がある」と、判明した場合は、帯域を圧迫しているトラフィックが何かを調査します。

仮に帯域を圧迫しているトラフィックが、過剰な監視パケット等、予期せぬトラフィックだった場合は、それを制御するか、

【Query 制限】で良いと思います。※監視パケットが原因だった場合は、他のルータでの懸念は解消されます。

帯域を圧迫しているトラフィックがユーザートラフィックだった場合は、対策は【帯域拡張】になると思います。

③④ルータの状態を確認する。

④はないと思うので、③が目的になると思いますが CPU 使用率や、インターフェースの状況等を確認します。

余談になりますが、以前、1812J のスイッチポートで、「NTP の Reply が返せない」という事象を経験したことがあります。

様々な切り分けの結果、当該スイッチポートの問題と判断し、再起動してみた結果、あっさり治りました。。

ユーザーへは、スイッチポートのハングということで了承を頂きましたが、原因は不明です。

こーいったケースもあるので、トラフィック利用状況や、ルータの状態等に問題がなければ TAC ケースオープンを推奨します。

以上、アドバイスになったかどうかわかりませんが、参考になれば幸いです。

[j.takahashi]

ご回答、アドバイス等、ご丁寧にありがとうございました。

やはりCPU負荷やトラフィックにフォーカスした調査が必要と思われますので

計画してみます。

他拠点に比べて小さなルータである事と、回線帯域が他に比べて狭い事から

差異はあるとは思うのですが、Queryの再送で一切救われない程か否かに

判断し兼ねている部分がありました。

調査方法については頂いたご解答を参考に検討したいと思います。

ありがとうございました。