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

ネットワークマネージメントについて (Ask the Expert)

シスコの技術サポートエンジニアへ質問して疑問を解決できる「エキスパートに質問」へようこそ!
ここでは、シスコのエキスパートからのアドバイスや最新の情報が得られる場として気軽にご質問ください。

担当エキスパート: 和田 恭典(Yasunori Wada)
Cisco Japan TAC のカスタマーサポートエンジニアとして、ルータ(ISRシリーズ、ASR1000シリーズなど)やL3スイッチ(Catalyst6500、Catalyst3750など)でのルーティング、WANテクノロジのサポートを経て、現在はネットワークマネージメント製品のサポートを行っています。

開催期間: 12月8日(月)~12月21日(日)

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

も し1つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。
ディスカッション期間を過ぎてからの投稿にはエキスパートは回答できません。事務局より、通常コミュニティへの再投稿をご案内いたしますことをご了承ください。

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

11件の返信11

aiwamura
Level 1
Level 1

ルーターでの性能情報収集について質問します。

-各拠点ごとにブランチルータとしてISRルーターが2台。
-200箇所の拠点があり、約400台のISRルーターをWANを介してデータセンターに接続しています。
-WANは広域イーサネットです。(各拠点2回線、2ルーター)
-センター側は帯域制御装置と暗号化用ルータ4台を配置し、分散させて各拠点200箇所を接続しています。

これまで性能情報収集は、帯域制御装置の機能を使って、帯域制御各クラス毎に数分ごとの平均値と
ピーク値(IN/OUT=上り下り)をファイル化して、ネットワーク監視サーバーに送信する事で、実現していました。

今回ルーターを更改する事を検討しているのですが、その際に、暗号化と帯域制御の機能をASRに集約し
データセンター側はASR4台だけで、帯域制御装置は無くした構成にする予定です。

そこで、性能情報収集について困っています。

これまでは、帯域制御クラスごとのピーク値(収集期間での最大値)と収集間隔ごとの平均値を得てきましたので、
帯域制御装置を無くした後も、同等の性能情報レポートを作成したいと思います。

新たな性能情報収集の方法として、QoS_MIBの利用を考えています。
QoS_MIBであれば、帯域制御クラス毎のOUTPUT BYTES、OUTPUT PACKET COUNTが得られますので、
定期的にMIB値を収集する事で対応できるのではないかと想定しています。

しかしながら、QoS_MIBではOutputの値しか得る事ができません。これまでは回線のIN/OUT(上り下り)を
帯域制御装置が記録していましたが、MIBで上り下りの性能情報を収集するとなると、センタールータだけでは無く、
400台のブランチルータ側のWANのOutputで、MIBを定期的に収集する必要があります。

WAN越えで定期的に400台、かつ全クラス(10クラス程度)分のMIBを収集する、となると、ブランチルーターの
負荷だけではなく、WAN上を流れる性能情報データもそれなりの大きさとなる点と、
収集周期内に全てを収集できるかどうか、などの考慮点が増えてしまいます。

質問は、センタールーター側だけで上り下りの性能情報データを収集する方法が無いか?、という点についてです。

例えば、センタールーターのWANインターフェースのOutput側(下り)に定義してあるCLASS-MAPの定義を、
センタールーターのLANインターフェースのOUTPUT側にも定義して、そこで回線ごとに設定してあるクラスごとの
MIB値を、上りの数値として収集する方法が考えられると思うのですが、その有効性や、
その他の方法などで実現できるアイデアがあれば、アドバイスを頂けないでしょうか?

また、ピーク値について、何らかの取得方法があれば、アドバイス頂けると助かります。

トポロジとしては、簡単に書くと以下のイメージです。よろしくお願い致します。

データセンター側LAN -----+ ASR +------(広域イーサ)-----+ ISR(200拠点)+---- 拠点LAN

 

こんにちは。ご質問ありがとうございます。
policy-map を両方向に適用することで一応可能かとは思いますが、実際にそのような運用をされている例はほとんど見ないですね。
通常このような要件の場合は、NetFlow を採用することが多いです。
ASR1K では Flexible NetFlow や AVC にも対応していますので、流量測定だけでなく、具体的にどのようなアプリケーショントラフィックが帯域を圧迫しているのか等も確認できます。

Flexible NetFlow の概要
http://www.cisco.com/cisco/web/support/JP/docs/RT/WANAggregationInternetEdgeRT/ASR1000AggregationServsRT/CG/010/fnf-xe-3s-asr1000-book-1_chapter_00.html?bid=0900e4b18329443b

Cisco Application Visibility and Control(AVC)
http://www.cisco.com/web/JP/product/hs/routers/application_visibility_control.html


ASR1K に NetFlow を処理させることによる負荷上昇が気になるようでしたら、NGA という機器を使う方法もあります。
Cisco NetFlow Generation Appliance:データセンターにおけるネットワーク可視化の再定義
http://www.cisco.com/web/JP/product/hs/netmgt/nga/prodlit/white_paper_c11-708294.html

また、NetFlow コレクタが準備できないような場合は、NAM という機器を使う方法もあります。
Cisco Prime NAM 2300 シリーズ アプライアンス
http://www.cisco.com/web/JP/product/hs/netmgt/nam2200ap/prodlit/data_sheet_c78-715146.html


ネットワークトラフィックの「見える化」が注目を浴びてきており、選択肢もたくさん出てきています。
既存機器の投資保護をしながら段階的に導入することもできますので、いちど弊社営業まで相談頂くことをお勧めします。

ご返答頂き、ありがとうございます。(ご返信が遅くなりました事をお詫びします)

>policy-map を両方向に適用することで一応可能かとは思いますが、実際にそのような運用をされている例はほとんど見ない

上記についてのご返答、ありがとうございました。

今回の質問は、ネットワーク全体の性能情報収集設計の中で、機器更改に伴い現状の方法で対応できなくなる部分への質問のため、「Netflowの採用」のような、全体の性能情報収集設計を見直すところまで考えてはおりませんでした。

収集の目的は、「拠点ごとの回線利用状況と設定した帯域制御クラスの利用状況を確認する事」ですので、Flow情報を使った場合には以下の考慮が必要になりますが、対応可能でしょうか?

 →暗号化ヘッダ・WANヘッダなどの附加バイトの考慮が必要である。

 →取得したデータを、拠点ごとに設定している帯域制御のクラスマップ単位でデータをまとめる必要がある。

 また、MIB収集ではピーク値の収集ができませんが、Netflowでは可能なのでしょうか?

 *ピーク値=1分などの単位時間内に記録された最大Output bps

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

追加のご質問ありがとうございます。

Netflow を受け取る Collector 側がどのように組み立て、解釈し、表示させるかにもよりますので、実際にそれが可能かどうかはルータ単体で判断するのは難しいと思います。

弊社営業に実案件の話としてご相談頂いたほうがより具体的な提案をさせて頂けると思いますので、ご検討下さい。

どうぞよろしくお願い致します。

 

了解しました。ご返答頂きありがとうございました。
 

kazuhide hirano
Level 1
Level 1

こんにちわ

脆弱性に関する問い合わせに対応するために、Cisco製品には、
どのようなサードパーティのオープンソース製品が実装されているかを
調べています。
OpenSSLが実装されている場合はこのように明示されますが

http://www.cisco.com/c/en/us/td/docs/ios/15_0/release/notes/150MDOCS.html#wp1022817

他のオープンソース製品(bind、apacheなど、)は記載が見当たりません。
実装していないのですかね?
詳しい方がいらっしゃいましたらご教授下さい。

こんにちは。ご質問ありがとうございます。
残念ながら、どのようなサードパーティのオープンソース製品が実装されているかを網羅的に確認頂く方法はございません。
実際に shell にログインして確認できるものもあれば、製品によっては非公開かつ実機確認もできないものもあります。
ただし、重大な脆弱性に関しては、Security Advisory として必要な情報が公開されますのでご安心下さい。

たとえば、OpenSSL に関する脆弱性の場合は以下のような形で公開されています。
Multiple Vulnerabilities in OpenSSL Affecting Cisco Products
http://www.cisco.com/cisco/web/support/JP/112/1122/1122700_cisco-sa-20140605-openssl-j.html

なお、情報が錯綜し混乱することを避けるためにも、脆弱性に関する全ての公開可能な情報は Security Advisory ページ上で一元的に公開されます。
逆に言えば、ここに記載されていない情報については、営業や TAC にお問い合わせ頂いても回答は得られません。

どうぞよろしくお願い致します。

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

ネットワークマネジメントに関する内容とは少し離れているかもしれませんが、ご回答頂けたら幸いです。

装置:Cat3560X
IOS:15.0(2)SE

上記環境において以下の設定を施しています。
logging source-interface Loopback0
snmp-server trap-source Loopback0

上記の状態からLoopback0をshutdownした後に何らかeventが発生すると、以下のようになります。

[SNMP-Trap]
up/downに関わらず常にLoopback0をsourceアドレスとして送信する
[Syslog]
Loopback0ではなく、upしている別のinterface(=出力先I/F)をsourceアドレスとして送信してしまう。
Loopback0をno shutすると、ともにLoopback0がsourceになります

運用者としてはsyslogもSNMP Trapと同じ挙動を期待していたのですが、上記の動作が「仕様」となりますでしょうか?それとも装置/IOS Ver固有の動作なのでしょうか?(それともバグ?)

当該スイッチ群とSNMP/syslogサーバとの間に他部門管理のFWが存在し、通過できるsourceアドレスが制限されるため、interfaceのup/downに関わらずsyslogもsourceアドレスを固定にできないか、スイッチ側でできる対処がありましたらご教授頂きたく存じます。

お手数をお掛けしますが、どうぞよろしくお願い致します。

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

ご指摘のコマンドは、指定した interface が up していることを前提としているので、admin down 状態でどのような挙動をとるかは「仕様」としては定義されておらず、各機器やバージョンそれぞれの「実装」によるものと思われます。

そのため、別の機器に変えたり、バージョンを変えたりすることで結果的に期待されている動作となる可能性もありますが、それを全て調べるのは現実的ではありません。

また、既に機器をお持ちのようですので、TAC の Service Request としてお問い合わせ頂き、正式に調べることもできますが、開発側との協議の結果 syslog の挙動のほうが好ましいと判断されれば snmp のほうの実装が変えられてしまう可能性もあります。

通常、物理 interface のように意図せず down しては困る場合に loopback interface を指定するものなので、shut せずに運用頂くのが現実的かと思います。

どうぞよろしくお願い致します。

 

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

いただいた内容について理解/了解しました。

Loopbackインターフェースをshutdownするのは移行過渡期の短期間だけなので実運用には支障はないものと思っております。

よってTAC の Service Request までは不要と考えています。

 

迅速かつ的確に対応いただきましてありがとうございました。