キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
3975
閲覧回数
30
いいね!
4
返信

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

j.takahashi
Level 1
Level 1

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

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

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

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

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

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

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

思います。

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

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

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

に見えています)

また、実はその中に監視専用のルータが存在していてCsico1812のEtherポート(サブ

インターフェース)で、契約回線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のクエリー処理を行うのが現実的に無理なので

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

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

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

1 件の受理された解決策

受理された解決策

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

ご指摘のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

元の投稿で解決策を見る

4件の返信4

t-yamashita
Level 7
Level 7

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


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

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

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

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

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

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

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

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

(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側)にはネイバーいないにも関わらず、リトライアウトするまで応答でき

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

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

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

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

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

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

ご指摘のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

計画してみます。

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

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

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

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

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

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします