Webcast 「第3版 Cisco LAN スイッチ教科書 （番外編）」フォローアップ エキスパートに質問

[CiscoJapanModerator]

このエキスパートに質問は2014/9/9に開催した Webcast のスピーカーが担当します。Webcast の内容に関することや Catalyst、Nexus スイッチに関することでしたらできる限り回答いたしますので、どうぞご利用ください。

資料はこちらからダウンロードいただけます。

スピーカー: 山下 薫 (Kaoru Yamashita)
シニア コンサルティング システムズエンジニア

＊　Webcast 前に LAN スイッチ教科書第3版についての質問箱として利用していたディスカッションの場をそのまま継続利用しています。Webcast 後の質問は、遠慮なくこのスレッドへご投稿ください。

[Jiro Takarada]

こんにちは。

シスコさんがこの本の第3版を出版された意図は、どの様なものなのでしょうか。

お教え頂ける範囲で構いませんので、コメント頂けるとうれしいです。

宜しくお願い致します。

[Kaoru Yamashita]

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

「第3版」を出版した最大の理由は、2004年の「改訂新版」が、10年近く販売されていたからです。第3版の出版が決まるまでは、改訂新版は絶版になっていませんでした。シスコのスイッチ製品に例えれば、EoL(End-of-Life)なのにEoS(End-of-Sales)では *ない* ような、通常はあり得ない状態になっていたとお考えください。

2番目の理由は、シスコのLANスイッチのラインナップ拡充(Nexusなど)と世代交代、高信頼化(HA)の進化です。特に、第3版を執筆していた2013年はスイッチの「当たり年」で、多数の新製品が発売されました。その情報は4章と、8章の一部に反映しています。また、改訂新版の時点ではごく一部しかサポートされていなかった、さまざまな高信頼化技術が利用できるようになり、第3版では5,6,7章のほぼ100ページを高信頼化の解説に割いています。

3番目の理由は、膨大な技術情報や製品情報を「ざっと把握」できる手段を提供することです。第3版では400個強の用語を取り上げていて、ほぼすべてのページに図版かリストが入っています。これにより、読者のみなさんがより詳細な情報を調べるための足掛かりになることを目指しました。

以上です。お答えになれば幸いです。

[Jiro Takarada]

Yamashita 様

丁寧にご説明いただき、ありがとうございました。

第2版は持っているので、第3版の購入はどうしようかなと考えていたのですが、購入させていただこうと思います。

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

[mousho1522]

早速購入させていただきました。

Nexus シリーズの FabricPath 機能ですが、同等の機能が Catalyst 6500/ 6800 シリーズでもサポートされる予定などはありますでしょうか。

[Kaoru Yamashita]

ご購入いただきありがとうございます。FabricPathに関する記述は、最も力を入れて書いた部分のひとつです。いかがでしたか?

しかし残念ながら、現時点ではCatalyst 6500 / 6800でのFabricPathサポートの予定はないとのことです。ですが、BU(事業部)はニーズがあることを理解していますので、同等の機能が将来サポートされる可能性はあります。

直近のご要望に沿えず申し訳ありませんが、弊社からのアップデートをお待ちください。よろしくお願いいたします。

[Jiro Takarada]

山下様

こんにちは。

ACLがTCAMにプログラムできない場合、もともと該当ACLが適用されるべきパケットに対しては、どのような処理が機器内部で行われるのでしょうか。

宜しくお願い致します。

[Kaoru Yamashita]

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

機種やACLの種類によって挙動が異なる可能性がありますので、調査にお時間をいただき、9月9日(火)に予定しておりますTAC Webcastで結果をお知らせいたします。

お待たせすることになり申し訳ありませんが、よろしくお願いいたします。

[Jiro Takarada]

山下様

こんにちは。

ご返信いただきありがとうございました。

それでは当日を楽しみに待ちたいと思います。

宜しくお願い致します。

[Kaoru Yamashita]

回答のほう、大変お待たせしました。本日の資料のP.5 - 11をご覧ください。
 

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

[Takainu1989]

担当者様

拝読させていただきました。

p.77にあったHSRPアクティブ側の再起動時の問題について質問があります。

preempt機能が有効でプライオリティの高い方のスイッチが再起動した際、ルーティングテーブルが安定状態になる前にそのスイッチがHSRPアクティブになってしまい、受け取ったパケットをルーティングできずに廃棄することがあると記載されております。

この問題を回避するため、HSRPの起動を機器自体の起動よりも遅らせるような機能はないのでしょうか。

また、その他にこの問題の回避策はありますでしょうか。

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

[Kaoru Yamashita]

ご質問ありがとうございます。9月9日(火)午前に予定しておりますTAC Webcastで回答し、その内容をこの掲示板にも投稿いたします。

それに先立ち、HSRP Preemptを有効にしたい理由や背景について、可能な範囲でお教えいただけないでしょうか。

よろしくお願いします。

[Takainu1989]

ご返答ありがとうございます。

Webcast、楽しみにしております。

HSRP preemptですが、特に実運用環境で使用したいというわけではなく、今回拝読させていただいて純粋に疑問に思った部分を質問させていただきました。

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

[Kaoru Yamashita]

「HSRP Preempt」を用い、かつ再起動時のパケットロスを防ぎたいとのことで、"preempt delay reload <秒>" コマンドをご紹介しました。本日の資料のP.32をご覧ください。

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

[katsuyask2 · Accepted solution]

こんにちは。

山下さんの教科書を拝見し、QOS（教科書P40）について大変興味を持ちました。

現在、スマートフォンの急激な増加でトラフィックの増加が問題となっているからです。

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

QOSについてネットで調べていると、「優先制御」と「帯域制御」というワードを見つけました。

しかし、私自身ではこの二つの違いについてよく理解できませんでした。

また、山下さんの教科書にはこれらのワードが書かれていません。

なので、もしよろしければ、山下さんの「優先制御」と「帯域制御」についての

解説をお願いしたいです。

期限を過ぎてからの質問で大変恐縮ですがお願い致します。

当日はWeb Castを拝見できませんが、後日ビデオで拝見させていただきたいと思います。

今年の4月からNWの勉強を始めたので初歩的な質問ですが、ご回答して頂ければ幸いです。

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

[Kaoru Yamashita]

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

「優先制御」は、見出し用語にはなっていないのですが、第2章の「2.14 QoS (P.118 - 121)」で解説しています。

「帯域制御」については、「流量の制限」という表現を用いており、第3章の「3.4.5 QoS (P.148 - 151)」で解説しています。

スイッチのQoSは、ハードウェアに依存する割合が高いため、QoSそのものの紹介を第1章、比較的抽象度の高い機能を第2章、実装に依存する部分を第3章に分けています。一読していただいたあと、第1章の「1.11 QoS (Quality of Service, P.40 - 42)」、2.14、3.4.5をもう一度続けてお読みいただければ、スイッチによる優先制御と帯域制御の概要がご理解いただけると思います。

それでも疑問点がありましたら、この掲示板にてご質問ください。よろしくお願いします。

[shinhei.nagasako]

もしかしたら、聞いても仕方がないことなのかもしれませんが、可能であれば山下さんのお考えを教えてください。

Nexus スイッチでは、どうしてwriteコマンドを無くしたのでしょうか?

(PortChannel やHSRPの変更については、非常に良い変更だと思います)

writeと言うキーワードを他の何かに割り当てる狙い等があるのでしょうか?

copyコマンドに対して、一種の恐怖心を持ってる人も多いと思うんです(私とかは、何千回とやってると、いつか, copy startup-config running-configってしてしまいそうで怖いのです。write eraseも怖いですけど)。

勿論、エイリアスを付ければ、ほぼ問題ないわけですが、だったら最初からエイリアス付けてくれれば良いのにとも感じてしまうので。

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

[Kaoru Yamashita]

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

NX-OSでも「write erase」だけは残っているので、writeというキーワードを他に転用する意図はなかったようです。IOSにおいて「write memory」を「copy running-config start-config」に置き換える動きがあったので、それを先取りして「write memory」を無くしたのではないかと個人的には思います。

調べてみたところ、

CSCuh73905(A) Enhancement: Add "write memory", "write", and "write termin" to Nexus OS

という拡張リクエストが登録されていました。Bug Search Toolでもご覧いただけると思います。実装は早くて来年半ば、Nexus 7000/7000用のNX-OS 7.1になる見込みです。(Nexus 5500, 5600, 6000は未定)

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