シスコずヒュヌレットパッカヌドの゚ンタヌプラむズスむッチ仮想化テクノロゞヌ





今日は、耇数のスむッチを1぀の論理スむッチに結合できる、かなり類䌌した2぀のスむッチ仮想化テクノロゞヌに぀いおお話ししたいず思いたす。 Cisco Virtual Switching SystemVSSおよびHPE Intelligent Resilient FrameworkIRFテクノロゞヌに぀いお説明したす。 この蚘事のフレヌムワヌクでは、VSSテクノロゞヌがどのように機胜するかを詳现に調べ、その埌でIRFテクノロゞヌに぀いお説明したす。



䞡方のテクノロゞヌVSSおよびIRFにより、埓来のむヌサネットポヌトを䜿甚しおスむッチを組み合わせるこずができたす。 䞀般に、これらのテクノロゞヌはスタックテクノロゞヌに起因したす。 しかし、䞡方のベンダヌは䟝然ずしお仮想化技術ず呌がうずしおいたす。 シスコは通垞、VSSに関するワヌドスタックを避けおいたす。



シスコvss



VSSテクノロゞヌを䜿甚するず、2぀の物理スむッチを1぀の論理スむッチに結合できたす。 しかし、より叀兞的なスタッキングテクノロゞヌStackWise、FlexStackずは異なり、むヌサネットポヌトはスむッチを盞互に接続するためではなく、特殊なケヌブルを䜿甚するために䜿甚されたす。 したがっお、スむッチは互いに比范的倧きな距離に配眮できたす。



結合埌、スむッチは単䞀の論理スむッチずしお機胜し始めたす図1。 䞡方のスむッチがアクティブであり、パケット䌝送を提䟛したす。 この堎合、䞡方のスむッチの管理はいずれかのデバむスによっお実行されたす。 ぀たり、デヌタプレヌンは䞡方のデバむスでアクティブです。 ただし、コントロヌルプレヌンは1぀だけです。 コントロヌルプレヌン埌で倖郚名で䜿甚するこずを提案したすがスむッチのロゞックを担圓するこずを思い出しおくださいすべおのネットワヌクプロトコルL2 / L3の凊理、ルヌティングテヌブルの䜜成、CEF、ACL、QoSなどの入力









VSSテクノロゞヌは、次のCiscoスむッチでサポヌトされおいたす。





ただし、これらのデバむスのいずれか2぀を取り、VSSテクノロゞヌを䜿甚しおそれらを結合するこずはできたせん。 たず、VSSテクノロゞヌは、すべおのラむンカヌドではなく、すべおのスヌパヌバむザではサポヌトされおいたせん。たた、すべおのサヌビスモゞュヌルでもサポヌトされおいたせん。 たずえば、6500Eでは、Sup720-10GEおよびSup2TスヌパヌバむザヌでVSSテクノロゞヌがサポヌトされおいたす。 次に、VSSテクノロゞヌは同じプラットフォヌム間でのみ機胜したす。たずえば、2぀の4500Xたたは2぀の6500E + Sup2Tの間です。 デバむスレむアりトラむンカヌドおよびサヌビスモゞュヌルは異なる堎合がありたす。 4500Eず6500Eのシャヌシサむズも異なる堎合がありたす。 埮劙な違いがあるため、ベンダヌのWebサむトでハヌドりェア、゜フトりェアのバヌゞョン、ラむセンスの珟圚の芁件を確認するこずを匷くお勧めしたす。



2぀のスむッチを組み合わせた埌、システム党䜓のパフォヌマンスは2倍になりたす。 これは、䞡方のスむッチがパケット凊理を担圓しおいるためです。 したがっお、次のようになりたす。





VSSアヌキテクチャを図2に瀺したす。スむッチの1぀がプラむマリずしお遞択され、2番目のスむッチがバックアップずしお遞択されたす。 メむンスむッチではコントロヌルプレヌンがアクティブアクティブになり、スタンバむスむッチではホットスタンバむ状態になりたす。









アクティブなコントロヌルプレヌンは、䞡方のスむッチの動䜜を制埡したす。 たた、このプロセスでは、フォヌルトトレランスを確保するために、メむンスむッチのアクティブなコントロヌルプレヌンずバックアップスむッチのコントロヌルプレヌンの間で状態が垞に同期されたす。 管理ず同期は、特別なチャネル仮想スむッチリンクVSLを介しお実行されたす。



VSLチャネルは、2぀のスむッチ間の盎接接続です䞭間デバむスは蚱可されたせん。 VSLチャネルを提䟛するには、通垞のむヌサネットポヌトを介しおスむッチを盞互に接続したす。 しかし、私が通垞のポヌトに぀いお話すずき、私は少しずるいです。 ご想像のずおり、これらのポヌトには特定の芁件もあり、これらの芁件はスむッチプラットフォヌムによっお異なりたす。 VSLチャネルを介しお送信されるすべおのパケットには、専甚のヘッダヌが远加されたす-仮想スむッチヘッダヌ長さは32バむト









VSLは耇数の物理チャネルで構成できたす実際に掚奚されたす。 これは、必芁な垯域幅を取埗するだけでなく、システムのフォヌルトトレランスにも必芁です。 集玄は、PAgPたたはLACPプロトコルを䜿甚しお実行されたす。 ぀たり 可胜な限り、8぀のアクティブチャネルを1぀の論理VSLに結合できたす。 たずえば、10 Gb / sのポヌトを䜿甚する堎合、そのようなチャネルを8぀集玄するず最倧80 Gb / sになりたす。



倚くの人が、VSLチャンネルがスタックバスに類䌌しおいるこずに気付いたず思いたす。 したがっお、送信されるトラフィックを芋るのは非垞に興味深いです。





ディスカッションプロセスでは、いずれにせよ、各タむプのトラフィックに぀いお詳しく説明したす。

そのため、スむッチが開始された埌、初期のVSS初期化を提䟛するプロトコルが戊いたす





LMPは、VSLリンクがアップしおおり、デバむスが盞互に認識しおいるこずを確認したす。 RRPプロトコルは、デバむスのハヌドりェアず゜フトりェアの互換性をチェックし、誰がメむンスむッチになり、誰がバックアップになるかを決定したす。



メむンスむッチのコントロヌルプレヌンは、2぀の機胜を実行したす。 最初のものは、スむッチのロゞックを提䟛したす。構成に基づいおスむッチをプログラミングし、すべおのネットワヌクプロトコルL2 / L3を凊理し、ルヌティングテヌブル、CEFテヌブル、ポヌト管理などを䜜成したす。 2番目の機胜は、䞡方のスむッチのすべおのハヌドりェアテヌブルFIB、隣接、ACL、QoSなどを蚭定しお、ナヌザヌトラフィックの凊理をハヌドりェアレベルで行うこずです。 スタンバむスむッチのコントロヌルプレヌンはホットスタンバむ状態です。 この堎合、アクティブなコントロヌルプレヌンの状態は垞にバックアップず同期されたす。 これは、メむンの物理スむッチに障害が発生した堎合に仮想スむッチの䞭断のない動䜜を保蚌するために必芁です。



次の情報が同期されたす。デバむスブヌトパラメヌタ、それらの構成、ネットワヌクプロトコルのステヌタスずさたざたなテヌブルアクティブなコントロヌルプレヌンで実行、デバむスステヌタスラむンカヌド、​​ポヌト。



プラむマリスむッチずバックアップスむッチ間の制埡デヌタの転送ず状態の同期は、専甚のプロトコルを䜿甚しお実行されたす。





これらのプロトコルはすべお、システムの制埡トラフィックに関連しおおり、VSLチャネルを介しおスむッチ間で送信され、論理制埡チャネルシャヌシ間むヌサネットアりトバンドチャネル-EOBCを圢成したす。



ステヌトフルスむッチオヌバヌSSOは、スむッチ間の状態同期を担圓したす。 このメカニズムはずっず前に登堎した。 たずえば、単䞀の6500スむッチ内でスヌパヌバむザを予玄するために䜿甚されたすが、VSSテクノロゞヌでも䜿甚されたす新しいものは思い぀きたせんでした。 しかし、芚えおいるように、SSOはルヌティングプロトコルの状態の同期を蚱可したせん。 ぀たり、バックアップスむッチに切り替えるず、動的ルヌティングプロトコルがれロから起動されたす。 これにより、リモヌトデバむスずのすべおのL3接続が自動的に終了したす。 ぀たり 倖郚ずの接続が䞀時的に倱われたす。 この問題を解決するために、SSOテクノロゞヌはNon-Stop ForwardingNSFテクノロゞヌず連携しお機胜したす。 このテクノロゞヌは次のタスクを実行したすスむッチング時のL3パケットの送信を保蚌したす実際、すべおのルヌトの叀いレコヌドをフリヌズしたす、切断する必芁がないこずをリモヌトルヌタヌに通知し、新しいルヌティングテヌブルを構築するために必芁なすべおの情報を芁求したす。 もちろん、この堎合のリモヌトデバむスはNSFテクノロゞヌもサポヌトする必芁がありたすいわば、NSFに察応しおいる必芁がありたす。



ずころで、参考たでに、スタンバむスむッチが動的ルヌティングプロセスを完党に再起動するのに最倧13秒かかりたす。 したがっお、NSFテクノロゞヌがなければ、たったく悲しくなりたす。



たた、最初のスむッチに障害が発生した堎合、2番目のスむッチぞの切り替えはどのくらいの速さで行われたすか これに関するベンダヌは、200ミリ秒の平均倀を提䟛したす。 6500Eでは明らかに6800でも、堎合によっおは400ミリ秒いわば、分散アヌキテクチャのオヌバヌヘッドに達する可胜性がありたす。



コントロヌルプレヌンに関しおは、別の点に泚目する䟡倀がありたす。 アクティブなコントロヌルプレヌンはスむッチの1぀のみにあるため、すべおのネットワヌクプロトコルトラフィックはそれによっお凊理されたす。 たずえば、動的ルヌティングプロトコルOSPF、EIGRPなどからのトラフィックは、最終的にアクティブなコントロヌルプレヌンで終わる必芁がありたす。 したがっお、最初にバックアップスむッチに到達した堎合、このトラフィックはVSLチャネルを介しおメむンスむッチに送信されたす。 この堎合、応答パケットはメむンスむッチから盎接送信でき優先オプション、バックアップを通じお送信できたす。 ネットワヌクプロトコルの皮類ず、メむンスむッチからレシヌバヌぞの盎接チャネルの可甚性など、いく぀かのこずに䟝存したす。



4500E / 6500E / 6800スむッチを扱っおいる堎合、それぞれに2぀のスヌパヌバむザをむンストヌルできたす぀たり、耇補を耇補したす。 VSSはこの構成もサポヌトしおいたすQuad-Supervisorず呌ばれたす。 これは、スヌパヌバむザの1぀に障害が発生した堎合に、システム党䜓のパフォヌマンスを倱いたくない堎合に必芁です。 Sup2Tを陀くすべおのオプションでは、シャヌシの2番目のスヌパヌバむザはコヌルドスタンバむルヌトプロセッサの冗長性で実行されたす。 これは、シャヌシ党䜓がリブヌトされた埌にのみ、2番目のスヌパヌバむザが動䜜モヌドに入るVSSのコンテキストでバックアップになるこずを意味したす。 Sup2Tの堎合、同じシャヌシ内の2番目のスヌパヌバむザはSSOモヌドで動䜜し、再起動は䞍芁です。



次に、VSS仮想スむッチを介したナヌザヌトラフィックの転送に぀いお説明したす。 それでも、これは圌の䞻な仕事です。 VSSを䜿甚する䞻な理由の1぀は、異なるスむッチに到達する耇数のチャネルを集玄する機胜ですCisco-マルチシャヌシEtherChannelMECの芳点から。 倖郚デバむスたずえば、他のスむッチを仮想スむッチに接続するこずに぀いお話しおいる。









VSS内で耇数のチャネルを1぀の論理チャネルに集玄する堎合、動的集玄プロトコルPAgPたたはLACPたたは静的EtherChannelONモヌドのいずれかを䜿甚できたす。 ハッシュ関数に基づくメカニズムは、論理チャネル内のトラフィックの分散を担圓したす。 ハッシュ関数は、送信されたトラフィックのヘッダヌの特定のフィヌルドに適甚されたす。 たずえば、ハッシュ関数を送信者のIPアドレス倀に適甚できたす。 この堎合、2぀のチャネルを集玄するず、トラフィックフロヌは最初のチャネルで送信され、送信者のIPアドレスは偶数で、2番目のチャネルでは奇数のものが送信されたす。 これにより、1぀のむヌサチャネルに結合された異なるチャネル間でトラフィックフロヌを分散できたす。 より耇雑な堎合、いく぀かのパラメヌタヌたずえば、送信元IP + Dst IP +送信元ポヌト+ Dstポヌトがチャネルの遞択の決定に圱響を䞎える可胜性がありたす。



VSSの堎合、次のルヌルが垞に機胜したす。たず、ロヌカル通信チャネルを䜿甚しおMEC内でトラフィックを転送したす図5。 これは、VSLチャネルをロヌドしないようにするためです。 6500E / 6800のこのステヌトメントは、MECケヌスずEqual Cost Multipathケヌスの䞡方に圓おはたるこずに泚意しおください仮想スむッチず隣接デバむス間の接続が個別のL3チ​​ャネルを経由する堎合。









たた、各スむッチの総チャネル容量は関係ありたせん。 この䟋では、SW2ずSW3の間に二重接続がある堎合でも、SW1で受信され、SW3の受信者宛おのパケットは垞に単䞀のロヌカルポヌトを通過したす。 ただし、この接続が切断された堎合たたは最初はSW3スむッチがSW2にのみ接続されおいた堎合、すべおのトラフィックはVSLチャネルを通過したす図6。









このこずから、掚奚されるVSS操䜜スキヌムは、デバむスを䞡方のVSSスむッチに同時に接続するこずであるず結論付けたした図7。 この堎合、トラフィックは䞡方のVSSスむッチ間で分散され、1぀のスむッチに比べおシステム党䜓のパフォヌマンスがほが2倍に向䞊したす。 それ以倖の堎合、VSLチャネルをロヌドし、システム党䜓のパフォヌマンスを䜎䞋させたす単䞀のトラフィックフロヌで䞡方のスむッチの凊理胜力を消費したす。









VSSテクノロゞヌのMECチャネル内のトラフィックバランシングメカニズムの䜜業を改善するために、次の機胜が远加されたした。





ナヌザヌトラフィックを終了するために、もう1぀泚意点がありたす。 VSLチャネルは、VLAN内のすべおのデバむスに送信されるトラフィックも送信したす。 このようなトラフィックには、ブロヌドキャストトラフィック、受信者のMACアドレスにデヌタがないトラフィック䞍明なナニキャスト、およびマルチキャストトラフィックが含たれたす。



そのため、䞡方のスむッチがトラフィックを凊理し、すべおの管理がどちらか䞀方に集䞭しおいるこずがわかりたした。 VSLチャネルは、少なくずも制埡および同期情報が送信される共通の接続バスずしお䜿甚されたす。 同じチャネルを介しお、バックアップスむッチはプラむマリスむッチが停止しおいるこずを孊習したす。 しかし、䞡方のスむッチが動䜜しおいる間にこのチャネルが壊れるずどうなりたすか 答えは簡単です。メむンスむッチはアクティブのたたですが、スタンバむスむッチは同僚が倱敗したず芋なし、それに応じおアクティブになりたすコントロヌルプレヌンに぀いお話しおいるすべおの堎所。 たた、これらのスむッチの構成は同じであるため、ネットワヌク䞊でたったく同じアドレス指定を持぀2぀のたったく同じデバむスを取埗したす。 これがどこに぀ながるかを蚀う䟡倀はないず思いたす。 この状況を回避するには、少なくずもVSLチャネルを壊さないでください。 しかし、これは垞に私たちに䟝存しおいるわけではありたせん。したがっお、VSLチャネルを壊した結果を最小限に抑えるこずができるメカニズムがありたす。 このメカニズムは、誀動䜜状態を怜出するために3぀の方法のいずれかを䜿甚したす。





VSLチャネルブレヌクにより䞡方のスむッチがアクティブになったこずが確認された埌、次のアクションが実行されたす。



  1. VSLチャネルが壊れる前にアクティブだったスむッチは、VSLおよびむンタヌフェむスを陀くすべおのむンタヌフェむスを無効にしたす。VSLずむンタヌフェむスの堎合、手動モヌドでは無効にする必芁がないこずが瀺されたす。 この動䜜により、ネットワヌクは、単䞀のスむッチ䞊でありながら衝突するこずなく、さらに機胜し続けるこずができたす。
  2. VSLチャネルが埩元されるずすぐに、最初にアクティブだったスむッチが再起動したす。 再起動埌、バックアップになりたす。


したがっお、2぀のアクティブスむッチがある状況では、元々冗長であったスむッチが最終的にアクティブのたたになりたす。 サりンド付きの各メ゜ッドがどのように機胜するかを芋おみたしょう。



拡匵PAgP玄PAgP-独自のプロトコルの堎合、倖郚デバむスは「リトマステスト」ずしお䜿甚されたす。 各VSSスむッチは、倖郚スむッチが接続されおいる同じMEC論理チャネル内のロヌカルポヌトを介しお特別なPAgPメッセヌゞを送信したす図9。 このメッセヌゞには、アクティブなVSSスむッチの識別子が含たれおいたす。 ePAgPパケットを受信するず、リモヌトデバむスはそれを反察方向に送信したす。 問題がなければ、䞡方のスむッチがアクティブなVSSスむッチの同じ識別子を送信したす。 䞡方のスむッチがアクティブになるず、それぞれが独自の識別子を持぀メッセヌゞを送信したす図10。 たた、リモヌトデバむスはこれらのメッセヌゞを送り返すため、䞡方のスむッチは障害が発生したこずを理解したす。









そしお、この堎合、誀動䜜状態がどのくらい早く怜出されたすか 元々冗長であったスむッチがアクティブになるずすぐに、ePAgPメッセヌゞずその識別子がすぐに送信されたす。 したがっお、誀動䜜を怜出する時間はほんの数秒です。 リモヌトデバむスもePAgPをサポヌトする必芁がありたす。 このようなサポヌトは、2960、3750スむッチスタックではなくなどで利甚できたす。



次のメカニズムはFast Helloです。 この堎合、远加の盎接L2チャネルがVSSスむッチ間に䜜成されたす䞭間デバむスなし。 このチャネル内で、スむッチはVSLP Fast Helloメッセヌゞを亀換したす。 たた、VSLチャネルがクラッシュしたが、VSLP Fast Helloパケットが匕き続き送信される堎合、悪い状況がありたす。 障害怜出時間は1秒未満ですVSLチャネルが萜ちたずきのVSLP Fast Helloメッセヌゞは、200ミリ秒の間隔で送信されたす。









最新の怜出メカニズムは、IP BFD双方向転送怜出です。 このメカニズムは、Fast Helloの操䜜に非垞に䌌おいたすが、䜎速です怜出時間は秒単䜍です。 ダむレクトチャネルL3を介しお機胜したす。 このメカニズムは速床が遅いためお勧めできたせん。 さらに、最新のiOSリリヌスでは欠萜しおいたす。



誀動䜜状況VSLチャネルブレヌクを同時に怜出するには、2぀のメカニズムを䜿甚するこずをお勧めしたす。

そのため、䞀般的に、Cisco VSSテクノロゞヌの䞻芁なポむントを怜蚎したした。 少し巊に觊れたす-VSSを䜿甚するための掚奚蚭蚈。 2぀のオプションを考えおみたしょう。











前者の堎合、チャネルブレヌクたたはアクティブなVSSスむッチは、動的ルヌティングプロトコルを䜿甚しお倱敗したす。 同時に、耇数の同等のルヌト各L3チャネルぞのルヌト䞊があるため、Equal Cost MultipathECMPにより総スルヌプットが集玄されたす。 実際、ECMPはVSSスむッチ党䜓のトラフィックの分散を担圓したす。 2番目の堎合、マルチシャヌシEtherChannelの動䜜により、チャネルのフェヌルオヌバヌたたはアクティブなVSSスむッチの障害がハヌドりェアによっお凊理されたす。 チャネル間でトラフィックのバランスをずる手段ハッシュ機胜のおかげで、MECはVSSスむッチ間でのトラフィックの分散も担圓したす。



ECMPず比范したMECの利点はすぐにわかりたす。 ネむバヌずの論理接続が少ない1぀の接続のみ、ルヌティングテヌブルが少ない1぀のネむバヌからルヌトのコピヌを1぀だけ取埗する、チャネルの1぀に障害が発生した堎合の負荷が少ない実際には存圚しないため、論理チャネルが1぀でも物理的に動䜜し続けたす。 さらに、この構成は理解しやすいです。



しかし、切り替え時間はどうでしょうか 䞡方の堎合のナニキャストトラフィックの堎合、この時間は同じです。 しかし、マルチキャストの堎合はありたせん。 マルチキャストトラフィックの堎合、ECMPのネットワヌク収束時間は倧幅に長くなりたす。



以䞊の結論から、1぀の論理接続MECで接続オプションを䜿甚するこずをお勧めしたす。



VSSテクノロゞヌを基盀ずする別の゜リュヌションに぀いお簡単に觊れたいず思いたす。 この゜リュヌションは、Cisco Catalyst Instant Accessです。 アむデアは、ネットワヌク内に1぀の倧きな仮想スむッチを取埗するこずです。









この堎合、Sup2Tスヌパヌバむザず特殊なラむンカヌドを備えた2぀の6500E / 6800スむッチがVSSテクノロゞヌを䜿甚しお結合され、ネットワヌクコアInstant Access芪にむンストヌルされたす。 アクセスレベルのスむッチむンスタントアクセスクラむアントスむッチずしお、Cisco 6800iaたたは3560CXが䜿甚されたす最倧42個。 IAクラむアントスむッチにはロヌカルスむッチング機胜がなく、すべおのパケットがカヌネルスむッチIA芪に送信されるこずに泚意しおください。 確かに、このようなスむッチの䟡栌は、私には思えたすが、それらの機胜にはたったく察応しおいたせん。 しかし、これは別の䌚話です。



VSSテクノロゞヌの実装䟋
VSSテクノロゞヌの構成は非垞に簡単です。 Cisco IOS XE 3.6.0EIOS 15.22E以降、簡易構成スキヌムであるEasy VSSを䜿甚しお、2぀のスむッチを1぀の仮想スむッチに結合できたす。 2぀のスむッチは盞互に接続されおおり、L3レベルで芋えるはずです。 次に、スむッチでVSSモヌドに倉換するコマンドを入力したす。これにはメむンがありたす。



SwitchAswitch倉換モヌドeasy-virtual-switch



VSLチャネルを圢成するポヌトが瀺されおいたすスむッチはこれらのポヌトを介しお既に盞互に接続されおいる必芁がありたす。



SwitchAeasy-vssVSL Te1 / 1/15 Te1 / 1/16



その埌、䞡方のスむッチが再起動しおVSS動䜜モヌドに入りたす。 これで、最小セットアップが完了したした。



VSSを埓来の方法で構成する堎合、実際には回路はそれほど耇雑ではありたせん。 䞡方のスむッチで、次を構成したす。



  • 仮想ドメむン仮想スむッチドメむンおよびその䞭のスむッチの番号



    SwitchAconfig仮想ドメむン2を切り替える

    SwitchAconfig-vs-domainスむッチ1



    SwitchBconfigスむッチ仮想ドメむン2

    SwitchBconfig-vs-domainスむッチ2



  • VSLポヌトチャネル



    SwitchAconfiginterface port-channel 1

    SwitchAconfigswitchport

    SwitchAconfig-if仮想リンク1を切り替える

    SwitchAconfig-ifシャットダりンなし



    SwitchBconfiginterface port-channel 2

    SwitchBconfigスむッチポヌト

    SwitchBconfig-if仮想リンク2を切り替える

    SwitchBconfig-ifシャットダりンなし



  • VSLチャネル甚に䜜成されたPortChannelに物理ポヌトを远加したす。



    SwitchAconfiginterface range tengigabitethernet 1 / 15-16

    SwitchAconfig-ifチャネルグルヌプ1モヌドオン



    SwitchBconfiginterface range tengigabitethernet 1 / 15-16

    SwitchBconfig-ifチャネルグルヌプ2モヌドオン



  • 䞡方のスむッチでVSSモヌドぞの倉換を開始したす。



    SwitchAスむッチ倉換モヌド仮想

    SwitchBスむッチ倉換モヌド仮想


スむッチがVSSモヌドになるず、VSLチャネルのQoS蚭定が自動的に構成に远加されたす。 さらにオプションでVSLチャネルが䞭断した堎合に、2぀のアクティブなコントロヌルプレヌンを䜿甚しお状況怜出機胜を構成できたす。 たた、仮想スむッチのMACアドレスも蚭定したすデフォルトでは、動的に蚭定されたす。



䟋ずしおCisco 4500Xを䜿甚しおスむッチを組み合わせた埌の結果を芋おみたしょう。









最初のスむッチはメむン/アクティブVSSアクティブ、id = 1になり、2番目のスむッチはバックアップVSSスタンバむ、id = 2になりたした。 ホットスタンバむモヌドで、最初のスむッチのコントロヌルプレヌンがアクティブになりコントロヌルプレヌン状態= ACTIVE、2番目のスむッチのコントロヌルプレヌンが冗長になりたしたコントロヌルプレヌン状態= STANDBY珟圚の゜フトりェア状態= STANDBY HOTスむッチオヌバヌタヌゲット。 フォヌルトトレランスを確保するために、SSOOperating Redundancy Mode = Stateful Switchoverメカニズムを䜿甚したす。 たた、䞡方のスむッチのデヌタプレヌンがアクティブ状態になっおいるこずがわかりたすファブリック状態= ACTIVE。



次の情報は、VSLチャネルに䜿甚するポヌトを瀺しおいたす。









ご芧のずおり、Te1 / 1/15およびTe1 / 1/16ポヌトがVSLチャネルで䜿甚されおいたす。 スむッチ間では、LMPプロトコルが実行されおいたす。 LMPプロトコルを䜿甚する䞡方のポヌトを通しお、2番目のスむッチHello bidirが衚瀺されたす。



このCisco VSSの説明を螏たえお、HPE IRF゜リュヌションを完成させ、次に進むこずを提案したす。


HP゚ンタヌプラむズIRF



HPE IRFは、Cisco VSSよりも詳现に説明できたせん。 これは、このテクノロゞヌに関する情報があたりないためであり、ほずんどの堎合、非垞に衚面的なものです。 これは最善の方法かもしれたせんが、詳现を把握するために脳を「殺す」必芁はありたせん。 䞀方、特定のブラックボックスで䜜業しおいるずいう感芚は消えたせん。



䞀般的に、2぀のHPEスむッチがスタックされおいるベンダヌがこの定矩を蚱可しおいる堎合、IRFずVSSの動䜜は非垞に䌌おいたす。 スむッチの1぀はマスタヌマスタヌによっお遞択され、2番目のスむッチはスレヌブスレヌブになりたす。 䞡方のスむッチがトラフィック凊理に関䞎しおいたす぀たり、デヌタプレヌンは䞡方のデバむスでアクティブです。 制埡はメむンスむッチによっお実行されコントロヌルプレヌンがアクティブになりたす、その状態はスレヌブず同期されたす。



「スタックバス」は埓来のむヌサネットポヌトを䜿甚するため。 䞀郚のモデルでは、1 Gbit / sのポヌトでさえこれに䜿甚できたすが、ほずんどの堎合、少なくずも10 Gbit / sのポヌトが必芁です。 IRFチャネルVSLチャネルのアナログがスむッチ間で䜜成されたす。 远加のヘッダヌIRFタグがすべおのパッケヌゞに远加されたす。









コントロヌルプレヌンの珟圚の状態はスタック内のスむッチ間で同期されるため、メむンスむッチの障害はトラフィックを停止したせん。 この動䜜はCisco SSOに䌌おいたす。 Cisco VSSずは異なり、同期にはルヌティングプロトコルの状態も含たれたす。 たた、切り替えにかかる時間はかなり短いためベンダヌによれば50ミリ秒、近隣のデバむスはいずれかのスむッチの障害を怜出しおL3接続を切断する時間がありたせん。 したがっお、Cisco NSFテクノロゞヌの類䌌物は必芁ありたせん。



VSSテクノロゞヌず同様に、IRFスタックは異なるスタックスむッチに接続されたチャネルの集玄をサポヌトしたす。 論理チャネルのパラメヌタヌの調敎を確実にするために、LACPプロトコルが䜿甚されたす。



タむミングむンゞケヌタヌに぀いおは、IRFテクノロゞヌで非垞によく芋えたす。 たずえば、䞊蚘の50ミリ秒は平均倀ではなく、最倧倀です。 倚くの文曞は、実際に切り替えがより速く行われるこずを瀺しおいたす。 同じこずが、集玄内の物理チャネルを1぀の論理チャネルに远加/削陀する堎合のトラフィックフロヌの切り替え時にも圓おはたりたす。 倀は-2ミリ秒です。 シスコでは、この倀は200ミリ秒です。 このような䞀時的なむンゞケヌタでは、適応ハッシュ関数は必芁ありたせん。



IRFチャネルが砎損し、䞡方のスむッチがアクティブになる必芁があるず刀断した堎合、IRSはCisco VSSず同様のアルゎリズムに埓っお動䜜したす。 スむッチの1぀はプラむマリロヌルを保持し、2番目のスむッチは回埩状態になりたす。 この状態では、IRFを陀くすべおのポヌトず、手動モヌドで無効にする必芁がないこずが瀺されおいるポヌトが無効になりたす。 IRFチャネルが埩元されるずすぐに、回埩状態にあったスむッチが再起動したす。 再起動埌、スレヌブになりたす。



マルチアクティブ怜出スキヌムも、Cisco VSSでレビュヌしたものず非垞に䌌おいたす。 HPE IRFは次のオプションをサポヌトしおいたす。





HPEはLACPたたはBFP MADを䜿甚するこずをお勧めしたす。これらは最速のメカニズムです。 ARPずND MADは䜎速であり、STPの䜿甚が必芁ですこれは少し予想倖です。 ずころで、メカニズムはメむンマスタヌのたたであるスむッチを遞択する異なるロゞックを䜿甚するため、HPEはそれらを䞀緒に䜿甚するこずをお勧めしたせん぀たり、LACPず残り。



次に、HPE IRFがCisco VSSずどのように異なるかを芋おみたしょう。



たず、IRFテクノロゞヌはより広範なスむッチでサポヌトされおいたす。 実際、これは比范的安䟡なA3100スむッチず高䟡なモゞュラヌ12900の䞡方で利甚可胜なスタッキングのメむンテクノロゞヌです。ただし、1぀のモデルレンゞスむッチのみをスタックに組み合わせるこずができたす。ただし、わずかな䟋倖がありたす



第二に、IRFテクノロゞヌでは、最倧9台のスむッチをスタックできたす倚くのモデルでは、この倀は4台に制限されおいたす。 IRF内でスむッチを接続するには、バスずリングの2぀のトポロゞが可胜です。









耐障害性が高いため、リング接続のオプションをお勧めしたす。 1぀の接続が切断された堎合、2぀のアクティブなIRFスむッチグルヌプの状況は発生したせん。



技術の説明から刀断するず、スむッチがIRFスタックに結合された埌、いく぀かのhelloパケットの亀換が開始され、共通のスタックトポロゞが構築されたす。 さらに、このトポロゞに基づいお、パケットはIRFスタック内で送信されたす。 残念ながら、より詳现な情報は芋぀かりたせんでした。



IRFのレビュヌを完了する前に、このテクノロゞヌEnhanced IRFeIRFの開発に぀いお説明する必芁がありたす。 eIRFを䜿甚するず、コアずアクセスレベルClosアヌキテクチャを䜿甚の2぀のレベルを含む、より階局的な構造を構築できたす。









カヌネルレベルClosアヌキテクチャのスパむンレベルにあるスむッチは、管理機胜を実行したすこのようなスむッチはControlling Bridges-CBず呌ばれたす。 実際、IRFスタックはそれらで実行されたす。 アクセスレベルClosアヌキテクチャのリヌフレベルにあるスむッチは、ポヌト拡匵機胜のみを実行し、トラフィック䌝送のみを提䟛したすこのようなスむッチはポヌト゚クステンダヌ-PEず呌ばれたす。 PEスむッチ䞀郚のドキュメントでは、このようなスむッチは頭字語PEXで指定されおいたすにはロヌカルスむッチング機胜がなく、すべおのパケットがカヌネルスむッチに送信されたす。 珟時点では、2぀のカヌネルスむッチず最倧30のアクセスレベルスむッチを䜿甚できたす。 これらのスむッチはすべお、1぀の倧きなデバむスのように芋えたす。 䜕にも䌌おいたせんか もちろん、シスコの同様の゜リュヌションはむンスタントアクセスです。



IRFテクノロゞヌの実装䟋
IRFテクノロゞヌのセットアップの䟋を芋おみたしょう。



メンバヌIDをスむッチに割り圓おたす。 デフォルトでは、デバむスのメンバヌIDは1なので、2番目のデバむスにのみメンバヌIDを蚭定したす。



[Sysname2] IRFメンバヌ1の番号を2に倉曎

メンバヌIDの番号を倉曎するず、構成が倉曎たたは倱われる可胜性がありたす。 続行したすか [Y / N]y

[Sysname2]終了

{Sysname2} reboot



, IRF ( ):



[Sysname1] interface range ten-gigabitethernet 1/0/7 to ten-gigabitethernet 1/0/8

[Sysname1-if-range] shutdown



[Sysname2] interface range ten-gigabitethernet 2/0/7 to ten-gigabitethernet 2/0/8

[Sysname2-if-range] shutdown



IRF :



[Sysname1] irf-port 1/1

[Sysname1-irf-port2/1] port group interface ten-gigabitethernet 1/0/7

[Sysname1-irf-port2/1] port group interface ten-gigabitethernet 1/0/8



[Sysname2] irf-port 2/1

[Sysname2-irf-port2/2] port group interface ten-gigabitethernet 2/0/7

[Sysname2-irf-port2/2] port group interface ten-gigabitethernet 2/0/8



, IRF :



[Sysname1] interface range ten-gigabitethernet 1/0/7 to ten-gigabitethernet 1/0/8

[Sysname1-if-range] undo shutdown

[Sysname1-if-range] quit

[Sysname1] save



[Sysname2] interface range ten-gigabitethernet 2/0/7 to ten-gigabitethernet 2/0/8

[Sysname2-if-range] undo shutdown

[Sysname2-if-range] quit

[Sysname2] save



IRF :



[Sysname1] irf-port-configuration active

[Sysname2] irf-port-configuration active



, , . IRF . MAD.



, . (MemberID=1) (Master), (MemberID=2) (Standby).









, IRF :









IRF:









, IRF-Port1 (MemberID=1) IRF-Port2 (MemberID=2).


, , , , IRF.



おわりに



, . , « ?» . -, . -, . , IRF . Cisco . VSS . ? などなど。 -, , , , , .

Cisco VSS HPE IRF
4500X, 4500E, 6500E, 6800 3100, 3600, 5120 ..
, 2 9
(SSO/NSF) はい
200-400 50
VSL , Ethernet- IRF , Ethernet-
ePAgP, Fast Hello, IP BFD LACP, BFD, ARP, ND
VSL/IRF
Instant Access eIRF
そしお最埌に。 , ( ) , .



参照資料



Cisco VSS



Campus 3.0 Virtual Switching System Design Guide

Release 15.1SY Supervisor Engine 2T Software Configuration Guide, Virtual Switching Systems (VSS)

Release 15.1SY Supervisor Engine 720 Software Configuration Guide, Virtual Switching Systems (VSS)

Catalyst 4500 Series Switch Software Configuration Guide, IOS XE 3.8.0E and IOS 15.2(4)E, Virtual Switching Systems (VSS)



HPE IRF



HP Intelligent Resilient Fabric (IRF) — Frequently Asked Questions

HP 5920 & 5900 Switch Series IRF Configuration Guide

HP FlexFabric 12900 Switch Series IRF Configuration Guide

H3C IRF Technology White Paper



All Articles