7月を最後に、ぱったりとエントリーが止まっていた本ブログですが、今年からあらためて、再開したいと思います。当面は、週1ぐらいを目安に書いていけるといいな、と思っています。頑張るというか、アウトプットによって自分の頭の中を整理できればいいな、と。
で、毎回書くつもりはありませんがお約束をあらためて…。
本ブログは個人のブログ。所属する会社は無関係。エントリー内容に正確性の保証なし。
なお、本エントリーでは以下PDFより図などを拝借させて頂いていますm(_ _)m
http://www.cisco.com/web/JP/event/ciscoplus2011/pdf/2D-2.pdf
では、本題に。
もう一昨年のエントリーになってしまっていますが、2011/2/27に[http://d.hatena.ne.jp/takaochan/20110227/1298787766:title=「[Virtualization]TRILLはEthernetに何をもたらすのか？」]、2011/4/9に[http://d.hatena.ne.jp/takaochan/20110409/1302329951:title=「[Virtualization]TRILLあれこれ」]というエントリーを書いていますが、再開1発目は、TRILLを拡張するベンダー技術であるCiscoのFabricPathについて、書いてみたいと思います。
BrocadeがTRILLをベースとしながらもVDXにおけるルーティングプロトコルとしてFSPF(Fabric Shortest Path First)やeNS(Ethernet Name Service)などのFCで培った技術を使用して独自拡張を行っているのと同じように、CiscoのFabricPathもTRILLに独自拡張を加えた技術となっています。
L2スイッチングでFabricPath網との境までスイッチングされてきたEthernetフレームは、FabricPath網内ではスイッチからスイッチへのルーティングで転送が行われます(下図では、スイッチS11からスイッチS42へ)。
FabricPathの技術は、BrocadeのVCS(Virtual Cluster Switching)/TRILLによって実現されていることとよく似ています。TRILL標準で使用される見込のIS-ISを使用し、FabricPathを構成するスイッチにID(Switch ID)を割り当てることによりL2 Routingを行います。STPを用いないループ防止が実装されている点、等価マルチパスでのロードバランスが可能である点などもほぼ同様。どちらも、ネットワークを構成する全てのパスをActiveで使用し、ネットワークの拡張や変更などをシンプルに運用できるようにすることを目指した技術といえます。ネットワークトポロジーについても、Access/Coreな構成でもかまいませんし、メッシュな構成にすることもできます*1。
対してFabricPathならではの特徴は、FabricPathを使用しない既存L2との接続部分であったり、FCoEと組み合わせるための実装の部分*2、vPCの拡張などでしょうか。
FabricPathでは、FabricPath網内でL2 Routingを行うために、既存L2からEthernetフレームが入ってきた時点でFabricPathヘッダを付加し既存L2に戻っていく時点でFabricPathヘッダを除去しています。既存L2ネットワークとの接点となるスイッチでは、既存のEthernetポートとFabricPathポートの両方を構成することにより、両者の間で透過的に通信を接続することができます*3。
スイッチをまたいだPort Channelを構成するvPCについても、FabricPathと既存Ethernetの接点で使用することができるように拡張されました(vPC+)。これにより、FabricPathとの接点となっているスイッチ2台に対するvPCについても問題なく構成することができます*4。
FabricPath網内では元々のEthernetフレームはヘッダを含めてペイロード化されるため、宛先MACアドレス・送信元MACアドレスとも使用されず、FabricPathヘッダにあるSwitch IDをベースにしたRoutingによってEthernetフレームが運ばれていきます。ここでのポイントは、FabricPath網内では各スイッチにおいてMACアドレスの学習は行われないし必要ない、という点です。
既存のL2では、L2セグメントを拡張していくと特にコアスイッチにおいて非常に膨大なMACアドレステーブルが必要になってしまうことが隠れた問題として存在していましたが、FabricPathが導入されていれば、FabricPath網内のスイッチにおいてはFabricPathによるRouting経路として各スイッチが必要とする分だけをそれぞれが必要な範囲で必要な時に学習すれば良く、さらにはリモートのMACアドレスについては「最終的にどのスイッチに対して送れば良いのか」だけを把握しておけば良いため、各スイッチが必要とするMACアドレステーブルのサイズをL2ネットワークのままで必要最小限に抑えることができます。
では宛先のMACアドレスが分かっている通信はそれでよいとして、宛先がわからない通信(Unknown Unicast)や、Broadcast通信、Multicast通信などについてはFabricPath網ではどのように扱われるのでしょうか？FabricPathでは、これらの通信についてはMulti Destination Trafficとして別扱いでの処理が行われるようになっています。
Multi Destination Trafficは宛先MACアドレスを元に経路を定めることができないため、FabricPathではそうした通信のために事前に通信経路を定義しておく仕組みが用いられています。FabricPath網を構成しているスイッチ群においてrootとなるスイッチを定め、各スイッチはrootとなったスイッチからのツリーとなるパスのみを用いてこれらの通信を伝搬します。最低2組以上のパスが構成されるため、全てのパスを使用するのではなくこの複数構成されるツリー経路に沿ってMulti Destination Trafficのロードバランスが行われます。
宛先MACアドレスのあるEthernetフレームについては、IS-ISによる最短パスに基づくルーティングによる配送が行われます。宛先スイッチまでの経路に最短パスが複数ある場合は、それぞれのパスに対する各インターフェイスが宛先スイッチに対する送信経路としてテーブルにエントリーされるため、それらのパス全てを使ってロードバランスされます。
各ベンダーが独自拡張を行っているため互換性がない点は残念ではありますが、この辺りは様々な方向で拡張されていく可能性が残されていますので今後の展開が楽しみです。L2はシンプルなスイッチングということでこれまでサーバとネットワークの緩衝地帯？として機能してきましたが、L2が拡張されていくと、どのようにネットワークとサーバを統合的に管理していくのか、今後ますます両者の統合的な構成と管理が必要になっていくのではないでしょうか。
