WAN ルーティングについて (Ask the Expert)

CiscoJapanModerator · ‎2012-04-09

シスコの技術サポートエンジニアへ質問して疑問を解決できる「エキスパートに質問」へようこそ！

ここでは、シスコのエキスパートからのアドバイスや最新の情報が得られる場として気軽に質問してみてください。

担当エキスパート：笠掛　利彰（カサカケ　トシアキ）

ディスカッション開催期間：2012年4月9日～2012年4月22日

Cisco Japan TAC のカスタマーサポートエンジニアとして、CISCO ルータシリーズ、Catalyst シリーズのサポートを行ってきました。

現在は、ルータ系 (Cisco12000、Cisco7200、ISR)やL3スイッチ(Catalyst6500、Cisco7600)でのルーティング、

WAN テクノロジのサポートを行っています。

Routing & Switching トラックのCCIE (CCIE#27227)資格を保有。

[質問の回答方法]

サポートコミュニティへCisco.comIDでログインすると、この説明の右下に「返信」ボタンが表示されます。クリックすると投稿欄が表示されますので、質問をご記入ください。最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。

もし１つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。
この「エキスパートに質問」のディスカッションスレッドに届いた質問は担当のTACエキスパートが回答しますがすべての質問に返信できないかもしれません。
返信が得られずに開催期間が終了して残ってしまった質問については、サポートコミュニティ事務局が今回の技術カテゴリの通常のディスカッションフォーラムへ再掲載し、有用な情報の展開へとつなげていきます。

エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエキスパートへぜひ伝えてください。

あなたからの質問だけでなく、他コミュニティのメンバーから寄せられた質問がどう発展したかをのぞきに、ぜひこのフォーラムへ再度訪問されることをお待ちしております！

[エキスパートからの回答について]

質問の投稿から原則数日以内に回答できるよう努めます。内容によっては、検証や確認に時間がかかる場合もありますのでご了承ください。質問の内容によっては、エキスパートの担当範囲外の場合もございます。その際はサポートコミュニティ事務局、もしくは適切な担当から回答いたします。

ディスカッション期間を過ぎてからの投稿は、事務局より通常コミュニティへ投稿いただくようお願いさせていただくようになりますことも合わせてご理解ください。

paserinokawari · ‎2012-04-12

Catalyst3750X(IPbase) IOS Version 12.2(53.r)SE2において、
ギガインタフェースにおけるパケットロス対策を検討しております。

環境は、Catalyst3750XのG1/0/1をLAN側に接続しております。また,G1/0/16にてWAN側を接続しております。
G1/0/1については1000Base-T（全二重）、G1/0/16は、100Baset-TX（全二重）にて接続しております。
LAN→WAN向きのトラヒックにおいて、インタフェースの速度差が原因（おそらく）で、G1/0/16のoutputにおいて、パケットロスが発生しております。（show int の、Output dropsにて確認）

一つの対策としてG1/0/16において、Outputキューの拡張を検討しました。
Outputキューデフォルトのキューサイズは、最大４０パケットですが、
hold-queueコマンドにより、最大4096パケットまで、拡張可能です。

しかし、実際、hold-queue 4096 outの設定を、G1/0/16にしましたが、
一向にパケットロスの改善が見られません。
また、show int において、現状のOutputキューに入っているパケット数が確認できるのですが、
一向に、数値が、0から変更しておりません。

以下、ご質問です。
・なぜ,パケットロスが発生しているにも関わらず、Outputキューのカウンタ値が、0のままで、増加しないのでしょうか？（パケットロスが発生しているなら、Outputキューも満杯になっているはず）
・このような環境で、パケットロスの発生を防ぐ術があれば教えてください。

■以下、補足情報です。
・Catalystでは、mls qosを動作させています。

よろしくお願いいたします。

Yasuhiro Nakajima · ‎2012-04-12

Yoshimoto様

お問い合わせ頂きました内容は、笠掛の専門外の分野に関するご質問ですので、私の方で回答させて頂きます。

尚、今回のAsk the Expertは、WAN及びルーティングに関する回となりますので、WAN及びルーティングに関するご質問をご投稿頂きます様、宜しくお願い申し上げます。

以下、お問い合わせに頂いた内容に関する回答となります。

hold-queueの設定では、パケットのH/W転送に使用しているバッファサイズを変更する事はできません。

従って、このコマンドを使用したとしても、output dropの対策とはなりません。

また、今回お問い合わせ頂いているoutput dropの原因は、入力ポートと送信ポートの速度差ですので、この状態が続く限り、

output dropは原則発生し続けてしまいます。

"mls qos"の設定を外してみて下さい。

上記を行ってもoutput dropが発生し続ける様であれば、速度差を解消するしか対応策はないと思います。

宜しくお願い致します。

paserinokawari · ‎2012-04-12

Nakajima様

お世話になります。Yoshimotoです。

早急にご回答いただきまして、ありがとうございます。

また、問合せ先を勘違いしておりました、申し訳ありません。

恐縮ですが、追加でご質問させてください。

＞"mls qos"の設定を外してみて下さい。

⇒設定を外してみることで、どのような、効果が期待できるのでしょうか？

>hold-queueの設定では、パケットのH/W転送に使用しているバッファサイズを変更する事はできません。

⇒Catalystで、hold-queueの設定が可能な理由がスッキリしないのですが、

　プロセススイッチングなどの、ソフトウェア処理のスイッチング方式に変更した場合にに有効であるということでしょうか？

　（そもそも、C3750Xがプロセススイッチングができるかも、曖昧ですが。。。。知識不足で申し訳ありません）

最初の投稿において以下ご質問をさせていただきました。ご回答いただいた中に、答えがあるのかもしれませんが、

お手数おかえしますが、再度ご確認いただけますでしょうか？

・なぜ,パケットロスが発生しているにも関わらず、Outputキューのカウンタ値が、0のままで、増加しないのでしょうか？（パケットロスが発生しているなら、Outputキューも満杯になっているはず）

お手数おかけして、大変申し訳ございませんが

何卒よろしくお願いいたします。

Yasuhiro Nakajima · ‎2012-04-12

Yoshimoto様

以下、お問い合わせ頂きました件に関しまして回答させて頂きます。

>⇒設定を外してみることで、どのような、効果が期待できるのでしょうか？

mls qosが設定されている方がoutput dropは発生しやすいので、mls qosの設定を外した方が、output dropが緩和するケースが多いです。

要件にもよりますが、特定のトラフィックのみ救えればよいという事であれば別ですが、output drop全般を減らしたいという事であれば、mls qosは外した方がいいと思います。

>⇒Catalystで、hold-queueの設定が可能な理由がスッキリしないのですが、プロセススイッチングなどの、ソフトウェア処理

>のスイッチング方式に変更した場合にに有効であるということでしょうか？

仮想インターフェース上でS/W転送されているトラフィックで、queue dropが発生している様な状況でのみ意味があります。

今回の様に物理インターフェースの送信バッファでdropが発生しているような状況では意味がありません。

>・なぜ,パケットロスが発生しているにも関わらず、Outputキューのカウンタ値が、0のままで、増加しないのでしょうか？（パ

>ケットロスが発生しているなら、Outputキューも満杯になっているはず）

物理インターフェースの送信バッファでdropが発生しており、このqueueでdropは発生していないからです。

今回のAsk the Expertは、WAN及びルーティングに関する回となっておりますので、是非WAN及びルーティングに関するご質問をご投稿頂きます様、宜しくお願い申し上げます。

tkqatech1 · ‎2012-04-17

質問させていただきます。

BGP で以下のように aggregate-address summary-only を指定して片方の
ルートを suppress しようとしているのですが、suppress されずに両方の
ルートが広報されてしまいます。

設定
aggregate-address 200.0.0.0 255.255.255.128 summary-only

対向ルータ

B 200.0.0.0/25 [200/0] via 172.17.19.1, 00:00:20
B 200.0.0.0/24 [200/0] via 172.17.19.1, 00:00:20 <<<<< 広報されてしまう

原因と対策をご教授ください。

よろしくお願い致します。

Toshiaki Kasakake · ‎2012-04-17

Konishi さん

こんにちは。ご質問に回答します。

aggregate-address 200.0.0.0 255.255.255.128 summary-only

上記設定では、200.0.0.0/25 に含まれる経路を summarize し、summary した経路だけを送る、という設定になるため、200.0.0.0/25 に含まれない 200.0.0.0/24 の suppress は行えません。

200.0.0.0/24 を suppress したい場合は、例えば該当の Router で neighbor への Route-map を outbound 方向に設定することで広報する経路を filter する方法などが考えられます。Mask長を考慮するならば prefix-list を使う方法なども考えられます。下は Access-list + Route-map の一例です。

設定例：

router bgp 1

neighbor x.x.x.x route-map Filter out

route-map Filter permit 10

match ip address 1

access-list 1 permit 200.0.0.0 0.0.0.127

上記を踏まえてさらに疑問点ありましたら、BGPでの200.0.0.0/24経路の学習状況をお聞かせいただければ、もう少しコメントできると思います。

宜しくお願いします。

tkqatech1 · ‎2012-04-18

仕様通りということで了解しました、ご教授いただいた案を

検討したいと思います。

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

Kentaro Yokokura · ‎2012-04-20

892JでBRIポートを利用してISDN接続しております。

■事象

NTT側のISDNスイッチとネゴシエーションが失敗し、Layer2がリンクダウンし通信が行えない状態になります。

■現状

ISDNのデバックログを取得し、NTTの故障受付とログ情報を確認し問題切り分けを行なっております。

そこで、ISDNのリンクアップには定期的なキープアライブがルータと ISDN スイッチとの間で交換されます。

これらのメッセージは、Receiver Ready（RRf および RRp）の形式なのですが、一部ルータから送信されるメッセージで

RRfとRRpが逆に送られていることでLayer2の通信がダウンしているようです。

今後は、別のルータを利用したりして、通信が正常になるかを切り分ける予定でございます。

また、DSUに異常がないかなども確認予定でございます。

■質問

実はISDNの接続は初めてのルータでして、config上で確認すべき点などがあれば指摘していただきたく、

また、NTT側で同型機で同じ現象が発生したらしく、バグ情報などあれば情報を頂きたく思います。

以上です。よろしくお願いします。

■バージョン情報

Cisco IOS Software, C890 Software (C890-UNIVERSALK9-M), Version 15.0(1)M5, RELEASE SOFTWARE (fc2)

ROM: System Bootstrap, Version 12.4(22r)YB3, RELEASE SOFTWARE (fc1)

Toshiaki Kasakake · ‎2012-04-20

Yokokura さん

こんにちは。ご質問ありがとうございます。

現状こちらで不具合情報等をお知らせすることができませんが、より新しい IOS Version (15.1(4)M4 や 15.2(3)T) も Release されておりますので、まずはそちらに upgrade していただき事象改善が見られるかをご確認いただければと思います。

それでも直らない場合、頂いた状況よりTAC での障害解析が必要な状況かと思います。申し訳ございませんが、TAC への Case Open をお願いできますでしょうか。Case open 頂く際は、以下のログ等を取得の上お送りください。

以下は事象発生中、前後で取得ください。

show isdn status

show controllers bri

show tech-support

以下は事象発生タイミングで取得ください。

debug bri-interface

debug isdn q921

debug isdn event

どうぞ宜しくお願いします。

Kentaro Yokokura · ‎2012-04-20

Kasakake様

ご教示いただいた通りに、IOSのVerUP後に事象確認したいと思います。

また、改善されない場合はTACへのCase Openを依頼したいと思います。

ご回答いただきありがとうございました。