黒本の前にガイドを読んで再整理です。
以前、「ルータとはデバイス同士の接続を切断する装置である」と書いたことがあるが、それはL2スイッチにも言える事である。
L2スイッチは、コリジョンドメインが各ポートごとに存在する。そのポートにデバイスが接続されていれば、そのデバイスはそれぞれ別のコリジョンドメインに所属する。
たとえば10個のポートを持つL2スイッチのすべてのポートに1台ずつPCを接続した場合、コリジョンドメインは10個に分離されることとなる。
そういう意味で「L2スイッチも接続を切断する」と言えるが、その切断のしかたはルータとは異なる。
ルータはブロードキャストドメインを切断するので、適切なルーティングをおこなわないとノード間で通信ができない、という意味での切断である。
L2スイッチの場合は、受信する必要のないフレームを受信しなくてすむ、という消極的な切断である。だから、ハブで接続していたのをスイッチに置き換えたからといって、各ノード間で通信ができなくなることはない。
ハブとL2スイッチの違いを示す具体的な例をあげると、
たとえばオフィスのある島で10人がひとつのハブ（バカハブ）に接続してメールの送受信をしていたとすると、ある人のpopアクセスのやりとりを別の人が自分のPCのNICをキャプチャすることで覗き見ることができる。
実際に私はそのような状況で、他人のパスワードを盗み見たことがある（メールは読んでない）。
ハブをL2スイッチに置き換えることの利点は、主に不要なフラッディングをなくして、ネットワークの利用効率を上げることである。
つまり、「遅くならない」ようにする。ハブのときと比べると「速くなった」と感じるかもしれない。
「L2スイッチの方が高性能だから転送が速い」ということではなく、余計なフレームの送受信が減ったために相対的に速くなったように感じるのみである。
たとえば10個のポートを持つL2スイッチのすべてのポートに1台ずつPCを接続した場合、コリジョンドメインは10個に分離されることとなる。
そういう意味で「L2スイッチも接続を切断する」と言えるが、その切断のしかたはルータとは異なる。
ルータはブロードキャストドメインを切断するので、適切なルーティングをおこなわないとノード間で通信ができない、という意味での切断である。
L2スイッチの場合は、受信する必要のないフレームを受信しなくてすむ、という消極的な切断である。だから、ハブで接続していたのをスイッチに置き換えたからといって、各ノード間で通信ができなくなることはない。
ハブとL2スイッチの違いを示す具体的な例をあげると、
たとえばオフィスのある島で10人がひとつのハブ（バカハブ）に接続してメールの送受信をしていたとすると、ある人のpopアクセスのやりとりを別の人が自分のPCのNICをキャプチャすることで覗き見ることができる。
実際に私はそのような状況で、他人のパスワードを盗み見たことがある（メールは読んでない）。
ハブをL2スイッチに置き換えることの利点は、主に不要なフラッディングをなくして、ネットワークの利用効率を上げることである。
つまり、「遅くならない」ようにする。ハブのときと比べると「速くなった」と感じるかもしれない。
「L2スイッチの方が高性能だから転送が速い」ということではなく、余計なフレームの送受信が減ったために相対的に速くなったように感じるのみである。
「トランスペアレントブリッジ」って何だ？
「ルートキャッシング」、「トポロジベース」について
「ルートキャッシング」というのは、一度転送をおこなったらそれをキャッシュに残しておき次回はそれを参照する、というもののようだ。
「トポロジベース」というのは、個々のフローに応じて転送を行うのではなく、ネットワークトポロジを格納しておりそれを参照して転送をおこなうもの。そのトポロジとは、つまりルータのルーティングテーブルのようなものであろう。しかし、どうしてルーティングテーブルと呼ばないのか？ルーティングじゃないから、か。では「ルーティング」と「L3転送」の違いは？
これについて納得いく説明はできないし聞いたこともない。
スパニングツリー・・・。
トラウマになっていると言っていいくらい、苦手である。
実際に使ったこともないし。
実際に使ったこともないし。
VTPにしても、etherchannelのネゴにしても、STPにしても、あまり必要性を感じない。
どれもしっかり設計・管理すれば不要な機能である。
むしろ、ネットワークの変化に動的に対応すると予想しない動作をしてよくないのではないだろうか？
きっとそういうポリシーの人もいるだろう。
むしろ、ネットワークの変化に動的に対応すると予想しない動作をしてよくないのではないだろうか？
きっとそういうポリシーの人もいるだろう。
etherchannelの silent modeというのは、前回BCMSNを受験したときにはなかったトピックである。
最近追加された機能なのだろうか？
このモードはデフォルトで有効であり、この場合相手からネゴシエーションをされなくてもetherchannelが有効になるとのことである。
となると、デフォルトではもしかして、on/auto/desirableのどの組み合わせでも有効になるのではないか？
このモードはデフォルトで有効であり、この場合相手からネゴシエーションをされなくてもetherchannelが有効になるとのことである。
となると、デフォルトではもしかして、on/auto/desirableのどの組み合わせでも有効になるのではないか？
この辺は実機で確認せねばなるまい。
catalyst2950を3台オークションで買った。1万円もしない。
前回、もう3年くらい前は、たしか1台1万くらいじゃなかったかな？
前回、もう3年くらい前は、たしか1台1万くらいじゃなかったかな？
ブリッジングループの発生メカニズムについては、前回の試験でもよく読んだし、自分でも納得済みのことであるが、大事な原則なので、あらためて確認しておく。
switch A, BがともにPC1, PC2からのフレームを未受信でアドレス学習をおこなっていない状態であるとする。
このときPC1はPC2のMACアドレスを知っているとする。
2台のSwitchがフレーム未受信で、PC1がPC2のMACアドレスを知っている状態というのは、
PC1がarpによりPC2のMACを学習した後、PC1とPC2の間の通信がなくSwitchA,Bのアドレス学習のみエージアウトし、しかしPC1のarpテーブルはエージアウトしていないような場合が考えられる。
あるいは、あまりないがPC1でスタティックにarpテーブルを設定した場合。
このときPC1はPC2のMACアドレスを知っているとする。
2台のSwitchがフレーム未受信で、PC1がPC2のMACアドレスを知っている状態というのは、
PC1がarpによりPC2のMACを学習した後、PC1とPC2の間の通信がなくSwitchA,Bのアドレス学習のみエージアウトし、しかしPC1のarpテーブルはエージアウトしていないような場合が考えられる。
あるいは、あまりないがPC1でスタティックにarpテーブルを設定した場合。
その状態でPC1からPC2あてに「フレーム」が送信されたときの話。
「フレーム」というのは、送信されるデータをLayer2で捉えたときの呼び方である。それはpingのecho requestであるかもしれない。それは普通「パケット」と言う。イーサヘッダが先にあって、その後にIPヘッダがつく。フレームとして考えるとIPヘッダは「フレームのデータの一部」ということになる。
pingしたときにパケットキャプチャすると、イーサヘッダも見える。実際にノードやスイッチが送受信しているものはイーサヘッダまで含んだ「フレーム」である。
「パケット」という時は、イーサヘッダ以降の部分、つまり、フレームの一部を指す。
イーサネットフレームの最大長は1518オクテット（VLANタグも含めると1522）、
IPパケット（ヘッダ＋データ部）の最大長は65536バイトである。
「バイト」と「オクテット」であるが、これは両方8ビットなので同じことなのだが、L2では「オクテット」と呼ぶことになっている。
これはなぜかというと、昔は1バイトが8ビットではない場合があったためだそうだ。
これはなぜかというと、昔は1バイトが8ビットではない場合があったためだそうだ。
というわけで、IPパケットはフレームの一部分なのであるが、IPパケットの方が最大長が大きいため、フレームに収まらない場合がある。そのときは分割して送信する。
ちょっと話がそれて基本的なことの確認になってしまったが久しぶりなので許して欲しい。
さて、PC1からPC2にフレームが送信される、ということであった。
どのようなフレームであるかはどうでもいいのだが、なるべく具体的なイメージがつかめるように、
pingのecho requestのIPパケット（を含むフレーム）であったとしよう。
pingはサイズ指定できるがそれをせずに64バイトの普通のpingだったとしよう。つまり、フレームも1個であった。
アドレス解決は済んでいたので、arp requestも送信されず、いきなりecho requestが飛んだ。
MACアドレスは PC1が 0001.0001.0001, PC2が0002.0002.0002だったとする。
送信されるフレームヘッダにはSRC:0001.0001.0001, DST:0002.0002.0002 と書かれている。
Switch Aが、port1でこのフレームを受信した。
ヘッダを見る。まずport1とPC1のMACアドレス 0001.0001.0001を記憶する。
ヘッダを見る。まずport1とPC1のMACアドレス 0001.0001.0001を記憶する。
次に、あて先を見る。0002.0002.0002は初見あるいはかつて学習したがエージアウトして今は宛先（どのポートから送信するか）が不明なアドレスである。
このときSwitchは受信したポート以外のすべてのポートからフレームを送信する。これをフラッディングという。
送信するフレームは受信したフレームとまったく同じものである。
SwitchBは、port2とport3でまったく同じフレームを受信する。
このときはどうなるのかな・・・同時に送られるのだがSwitchがアドレス学習をするのはひとつずつだろうから、後から受信したフレームで学習したアドレスを記憶するのだろうか（不明）。
この場合は「port3がPC1へ送信するポートである」と学習したとする。
SwitchBもPC2のMACアドレスを知らないため、フラッディングする。フラッディングされるポートはどこか？port1のみか？
このときSwitchは受信したポート以外のすべてのポートからフレームを送信する。これをフラッディングという。
送信するフレームは受信したフレームとまったく同じものである。
SwitchBは、port2とport3でまったく同じフレームを受信する。
このときはどうなるのかな・・・同時に送られるのだがSwitchがアドレス学習をするのはひとつずつだろうから、後から受信したフレームで学習したアドレスを記憶するのだろうか（不明）。
この場合は「port3がPC1へ送信するポートである」と学習したとする。
SwitchBもPC2のMACアドレスを知らないため、フラッディングする。フラッディングされるポートはどこか？port1のみか？
これはちょっとややこしい。
SwitchBがport2でフレームを受信した瞬間に、宛先へのフラッディングをおこなう。このときはport1,3から送信される。
だがほぼ同時にport3でも同じフレームを受信している。
このときのSwitchの動作はどういう順序でおこなうのか？
port2でのフレーム受信→port1とport3からのフラッディング→port3でのフレーム受信→port2とport1からのフラッディング
だろうか？
あるいはフラッディングの前に後からのフレーム受信処理が割り込むことがあるだろうか？
port2でのフレーム受信→port3でのフレーム受信
→por2とport1からのフラッディング
フラッディングしているフレームはPC1からPC2宛てに送信されたものであった。
SwitchAは、macアドレスとポートの対応表を更新することになる。
PC1はport2に接続しているということになってしまうのである。
・・・「だからループが発生してしまうのでSTPが必要なんですね？」
と考えるのは、これからSTPを学ぶということになっているからであるが、
「L2スイッチのアドレス学習に問題があるんじゃないですか？」
と言う人がいてもおかしくないだろう。
ブリッジングループが発生しないようなアドレス学習方法はないだろうか？
STPはアドレス学習方法そのものは変更せずにループを防ぐ方法であるが、
アドレス学習方法そのものを改良できないだろうか？
SwitchAは、macアドレスとポートの対応表を更新することになる。
PC1はport2に接続しているということになってしまうのである。
・・・「だからループが発生してしまうのでSTPが必要なんですね？」
と考えるのは、これからSTPを学ぶということになっているからであるが、
「L2スイッチのアドレス学習に問題があるんじゃないですか？」
と言う人がいてもおかしくないだろう。
ブリッジングループが発生しないようなアドレス学習方法はないだろうか？
STPはアドレス学習方法そのものは変更せずにループを防ぐ方法であるが、
アドレス学習方法そのものを改良できないだろうか？
これはCCNP試験の範囲から逸脱するどころの脱線ではないがちょっとだけ考えてみよう、せっかくだから。
まず思いつくのは、フレームを異なるポートから受信したからといって即そのポートに接続先が変わったとみなすのをやめてはどうか、という事だ。
でもそれをしないと接続ポート変更にどうやって対応するのか、ということになる。
たとえば1回受信しただけでは更新しないとか、直後（一定の時間内）なら更新しないとか・・・
フラッディングするフレームには印をつけるとか・・・。
たとえ学習済みのsrc macアドレスのフレームであってもフラッディングされたものであったら更新しない。
いちいちフラッディングされたかを確認しなければならないということを除けばうまくいきそうに思えるが・・・
ループ発生の根本的な原因はフラッディングにある。
フラッディングとは要するにフレームの複製である。本物のフレーム以外のニセモノが複数作成されてしまうのだ。これが実際に接続していないポートに接続していると誤認してしまう原因だ。
では、このフラッディングをやめてはどうか？
つまり、送信先のアドレス学習をしないのである。
これはダメか・・・。
同じスイッチの二つのポートに通信をおこなう装置が接続されていれば双方が何か送信すれば通信がおこなえるが、スイッチ同士を接続したらその間の通信がいつまでたってもできなくなる。
ルーティングのように、macアドレスを広告しなければならなくなる。では、このフラッディングをやめてはどうか？
つまり、送信先のアドレス学習をしないのである。
これはダメか・・・。
同じスイッチの二つのポートに通信をおこなう装置が接続されていれば双方が何か送信すれば通信がおこなえるが、スイッチ同士を接続したらその間の通信がいつまでたってもできなくなる。
今更だが「ハブとスイッチの違い」を調べた。
ハブというのは、全部フラッディングする装置である。
スイッチは、アドレス解決のためにフラッディングをする、というよりは、
受信フレームのsrc MACとポートを記憶しておくことにより、余計なフラッディングをしないようにしたのだ。
通信というのはあたかもケーブルの中を小包のようなものが流れていくようなイメージがあり実際にそのように説明されることが多いが、あれは全部コピーなのだ。あるパソコンからパケットは、スイッチに到達するとそこでコピーして違うポートから送信される。それがルータに到達したら今度はルーティングなどの処理をおこなってまた別のインタフェースからコピーして送信される。
通信とは複製なのであった。
今更過ぎるか・・・・
スイッチは、アドレス解決のためにフラッディングをする、というよりは、
受信フレームのsrc MACとポートを記憶しておくことにより、余計なフラッディングをしないようにしたのだ。
通信というのはあたかもケーブルの中を小包のようなものが流れていくようなイメージがあり実際にそのように説明されることが多いが、あれは全部コピーなのだ。あるパソコンからパケットは、スイッチに到達するとそこでコピーして違うポートから送信される。それがルータに到達したら今度はルーティングなどの処理をおこなってまた別のインタフェースからコピーして送信される。
通信とは複製なのであった。
今更過ぎるか・・・・
「ハブ」「ブリッジ」「スイッチ（スイッチングハブ）」の違い。
ごく少数の装置を「つなげる」だけであれば、この３つは区別がつかないだろう。
もっとも、今ではハブやブリッジを入手することは困難である。
（もう製造されていないか？）
ハブとスイッチの違いは比較的わかりやすいが、ブリッジとスイッチは難しい。私は今説明できない。
昔、後輩に聞かれたことがあるがちゃんと答えられなかった記憶がある。
今もネットを探すと「同じと考えて差し支えない」みたいな人も多い。
今もネットを探すと「同じと考えて差し支えない」みたいな人も多い。
簡単に言ってしまうと「スイッチ」とは「高性能なブリッジ」ということになる。
ブリッジという装置が登場したときは、2ポートしかなかったそうだ。
各ポートにハブをつないで使っていたのか。
やがて2つじゃ少ないというので、「マルチポートブリッジ」が登場した。
しかしこれはただブリッジをくっつけただけで、動作原理はブリッジとまったく同じだった。
それが「スイッチ（スイッチングハブ）」と呼ばれるようになったのは、どのような革新があったからなのか。
初期の2ポートのブリッジは、10Base2とか10Base5とかのバス方式で使われていた。
バス方式というのはもう見かけないが、一本のケーブルに複数のノードがぶら下がる方式だ。
バス方式では全二重通信ができない。
これは同軸ケーブルを使っていたためである。
バス方式では全二重通信ができない。
これは同軸ケーブルを使っていたためである。
それは置いといて、ブリッジとスイッチの一番本質的な違いは何か？
名前からして、ブリッジは架け橋、接続するものであり、スイッチは単なる接続ではなく、切り替えつまり選択する機能を持つ。となるとやはり「マルチポートである」ということだろうか？
HW処理とSW処理というのは確かに大きな違いで転送速度などにも大きく影響するだろうが、動作原理の違いという観点からすると本質的な違いではない。
HW処理とSW処理というのは確かに大きな違いで転送速度などにも大きく影響するだろうが、動作原理の違いという観点からすると本質的な違いではない。
転送方式の違いつまり全部読み込む前に転送を開始する、というのも革新的なことではあっただろうが、やはり機能改善にすぎず本質的な違いではないように思う。
ちょっと深入りしすぎたかな・・・
これくらいにしておくか・・・
やっぱりマルチポートであることですかね。
３つ以上になるということは、右から左へ受け流すだけではなく、受け取ったフレームを残る２つ（またはそれより多く）のポートのどこから送出するかを判断する必要がある。
わかった！！！
わかった！！！
初期のブリッジは2ポートであった、これが重要である。
そして、ブリッジもＬ２スイッチと同様のフラッディングによるアドレス学習をおこなうのであるが、
そもそも2ポートしかないのだから、出口は一個しかなくて選択の余地がないから全部そこへ送ってしまえばよさそうなものである。
でも、それではハブと変わらない。
ブリッジがアドレスを学習するのは、出力ポートの選択が目的ではないのである。
目的は、不要なフラッディングをしないようにすることである。
そもそも2ポートしかないのだから、出口は一個しかなくて選択の余地がないから全部そこへ送ってしまえばよさそうなものである。
でも、それではハブと変わらない。
ブリッジがアドレスを学習するのは、出力ポートの選択が目的ではないのである。
目的は、不要なフラッディングをしないようにすることである。
アドレス学習の原理はブリッジとスイッチで変わりなく、その目的も不要なフラッディングの防止ということで同じである。
しかし、マルチポートになったことによって、本来は単なる不要なフラッディングの防止のためでしかなかったアドレス学習に、出力ポートの選択という新たな目的が加わったのである。
そうなると、マルチポートブリッジの機能は複数のコリジョンドメインを接続（本当は分離なのだが）するというよりも、複数のコリジョンドメイン間でフレームの出力先を判定して振り分ける機能が主要になった。それによって、「ブリッジ」という呼び名が「スイッチ」となったのである。
私はまずスイッチからその動作原理を学習し始め、そのときに「アドレス学習は出力ポート選択のため」と認識していたのだが、実はこれは副次的な目的であって、主目的はやはり「不要なフラッディングの抑制」なのだった。
やはり、通信機器というのは、その機能するレイヤーが上位に行くほど、通信が抑制される。
基本は全コピー。なんでもかんでもコピーしてばらまく。そうすればとりあえず届く。
でもそうすると余計な送受信が発生するので、それを減らすような装置が必要となり、スイッチやルータが登場した。
これで整理がついた。
こんなのは当たり前なのかもしれないが、ちゃんと説明できる人はすごく少ないと思う。
少なくとも私は納得のいく説明を聞いたことがない。
以前、「スイッチはネットワークを拡大する装置だ」なんてことを書いた記憶があるのだが、それは大きな間違いであった。
スイッチの目的はコリジョンドメインの分離であった。