極端なLACP

悪魔は細部に宿る-私は何か新しいことに対処するときはいつもそれについて考える。 新しいソフトウェアや新しいハードウェアは、技術的にも経済的にもクールなものになり得ますが、そのような些細なことは当然のことと思われますが、大量の血を飲むのはクレイジーです。 ここで私は猫の下で伝えたいネットワーク機器エクストリームネットワークスのそのような飽くことのないささいなことについて。







前菜



モスクワのネットワークでは、 Extreme Summit X670V-48xスイッチが集約スイッチとして使用されています。 信頼性のため、VIM4-40G4Xモジュールを介してスタックされます(これらは40Gイーサネット上の4つのポートです)。 現在、各スタックには2つのシャーシがありますが、3つ目のシャーシを追加するためのチケットが既にあります。







したがって、すべてのリンクは2つのシャーシに均等に(つまり半分に)分散され、LACPを使用して集約されます。 1つのシャーシに何かが発生すると、レーンで劣化が発生しますが、メンテナンスは続行されます。



最初に



最初に埋め込んだのは、負荷をExtremeに転送することでした。 プロバイダーを切り替えます-物理は上昇しましたが、LACPは集まりませんでした。 それは大丈夫ですが、意味がありません。 別のプロバイダーの指示とまったく同じ設定-すべてがそこで機能します。 そして、ここで-少なくともあなたの足で蹴ります...解体のためのサポートで多くの時間を失う可能性がありますが、AS8359の同僚が助けてくれました:AndreiとPavel。 すぐに推奨される行:



configure sharing 1 lacp system-priority 1
      
      





助けた。 この問題で最も奇妙なことは、問題がすべてのパートナーで発生するわけではないということです。 私たちのtsiskaで-問題はありませんが、ASR9000の反対側にある場合-おそらく問題があるでしょう。 しかし、常にではありません。 一般的に、怠を理解する。 覚えて、マントラとして繰り返します。



第二



10ギガビットスイッチがあり、トラフィックはさらに多くなります。 したがって、多くの集約リンク(LAG)があります。 さて、LAG内ではバランスを取る必要があり、片足で休むのは非常に不快なので、すべての足ができるだけ均等に関与するようにします。 そのため、1つのLAGに8本の脚がありましたが、すべてが正常でしたが、突然1つのラムダが一gして落ちました。 全車線には常に予備があり、1ダースの損失は問題ではありません。 しかし、奇妙な方法で、均等に満たされた脚は層化されました。 いくつかは(予想どおり)高くなりましたが、他のものは落ちました。 おっと!



彼らは初めてそれを理解する時間を持っていませんでした-彼らは被害者を修理し、すべてが正常に戻りました。 しかし、堆積物は残った。 次回この問題に戻ったとき、さらに2つのラムダを追加しました。 私たちは見て-再びバンドル。 「余分な」2つの部分をオフにします-すべてがスムーズです。 電源を入れる-ガード! LAGのアクティブな脚の数が2のべき乗でない場合、層間剥離が発生することが実験的に検証されました。



考えて、サポートと話した。 そして彼らは言う:カスタムを使用します。 率直に言って、ドキュメントを信じているなら、デフォルト設定のカスタムはL3_L4と完全に等しいため、私はそれを信じていませんでした。 私はすでにこの問題を拷問していたMSK-IXの同僚に納得しました。



カスタムメソッドを使用するようにLAGを再構成したところ、LAGのアクティブなレッグの数に依存しない均一なバランスが得られました。 ただし、これを行うには、バランス設定アルゴリズムがLAGの作成時にのみ設定されるため、古い設定を削除してLAGを再度作成する必要がありました。 しかし、いつそれが私たちを怖がらせたのですか?



 enable sharing 1:1 grouping 1:1-5, 2:1-5 algorithm address-based custom lacp
      
      





デザート



デザートについては、私のお気に入りは残っています:)ポートチャネル。 tsiskaでポート集約はどのように行われますか? 特別なポートが作成されます-ポートチャネル、構成され、オンになります。 次に、物理ポートが追加されます(構成は完全ではありませんが、今では重要ではありません)。 追加する必要がありました-追加! 余分なものが現れた-削除。 どれでも。 気楽に



XOSでは、ストーリーは異なります。LAG構成は、物理ポートの1つにバインドされます(構成マスターになります)。 このようなポートはLAGのメンバーである必要があります。 構成マスターが移動しない限り、ポートを好きなだけ追加および削除できます。 ただし、最後の(マスター)ポートを移動する必要がある場合は、これですべてです。 唯一のオプションは、1つの共有を削除して、新しい共有を作成することです。 おっと...



まともなオフィスのように、私たちは自分自身のために改造するのが大好きです。 さまざまな理由で、しかし十分なハウスキーピングがあります。 したがって、このレーキにはすでに数回適用されています。 私はチームの他のメンバーの代弁はしませんが、個人的には好きではありませんでした。



自分で判断する:ポートにVLANを設定する必要があります(ちなみに、EXTREMEのイデオロギーvlanはポートでハングせず、vlanのポートです。したがって、ポートのvlanのリスト全体を1行でハングアップすることはできません)、STP(紳士役員、静かにしてください! )およびその他の不名誉。 このような大量の設定でミスを犯すのは間違っていることは明らかです-数バイトの送信方法。 それでは、私のお気に入りのシスコスタイルのポートチャネルはどこですか? しかし、すべてがそれほど悪いわけではありません。 構成マスターポートがダウンした場合、LAG自体は存続します(そうでなければ、完全にx ... badになります)。 構成マスターが配置されているシャーシを無効にしても、すべてが機能し続けました。 まあ、それでも...



絶望から、昨年、機能リクエストFR4-4584728621を発見しました。 ご存知のとおり、実装されていません。 そして、メーカーがこれについてまったく考えていたという確実性はありません。



dr死者の救助は、dr死者自身の仕事です。 私はかつて、tsiska one portchennelを見ました:



 #sh int po1 eth Port-channel1 (Primary aggregator) Age of the Port-channel = 174d:06h:35m:37s Logical slot/port = 2/1 Number of ports = 4 HotStandBy port = null Port state = Port-channel Ag-Inuse Protocol = LACP Port security = Disabled
      
      





そして、論理スロット/ポートの美しいラインに気付きました。 「ああ」と私は言った。 2番目のスロットは、このスタック不可能な拡張不可能なtsiskのどこから来たのですか?! これが論理スロットであることに気付いたとき、私は計画を持っていました!



しかし、構成マスターポートとして決して使用されないポートを使用するとどうなりますか? いいえ、購入したポートは申し訳ありませんが、すべて使用されます。 存在しないポートはどうですか? (スタック内の)スロット上にあり、そこにはありません。 その場合、特定のLAGにどのポートが含まれるかは気にしません。 この仮想スロットですべての設定を行います。 必要に応じてポートを追加および削除します。 はい、1つのスタック内のシャーシの数を減らしますが、8つのシャーシから非常に多くのスタックを見ましたか? 3を超える厚さは見ていません。



その後、すべてがシンプルになります。 仮想スロットを宣言し、可能な限り多くのポートを取得します(そのポートですべてのLAGを宣言します)。



 configure slot 8 module X670V-48x enable sharing 8:1 grouping 8:1, 1:1-5, 2:1-5 algorithm address-based custom lacp
      
      





新しいポートを追加するには:



 configure sharing 8:1 add ports 1:48, 2:48 enable ports 1:48, 2:48
      
      





これで、新しいポートに安全に切り替えることができます。 LACPは常にアクティブになります。 次に、古いポートをクリーンアップして、スレッドの下で使用できるようにします。



 disable ports 1:1, 2:1 configure sharing 8:1 delete ports 1:1, 2:1
      
      





ラボでの簡単なテストでは、アイデアの活力が示されました。 しかし、すぐに警告します。これまでのところ、戦闘でこれを利用していませんが、実装のチケットはすでにあります。



開発者に連絡しようとして、 Extremeフォーラムでトピックを作りました。 自分で答えを読むことができます。



LAGを便利に操作できるコマンドラインインターフェイスを作成することは、組み込みのメカニズムがあるため、比較的簡単なはずです。 私は、すべてのネットワーク担当者が素晴らしい隔離でこの問題に苦しんでいると思うので、この問題の程度を上げることを提案します。 Extremeユーザーの場合は、サポートに連絡してください。 表示されたFRを参照し、ビールが落ち着いた後にフォームの補充を要求します。 フォーラムスレッドに、メーカーについて考えたことをすべて書いてください。 そのようなネットワークフラッシュモブにしましょう。







以前の出版物:

» 安全なVPNプロトコル 実装します

» さらに安全なVPNプロトコル 実装します

» 追加の要素、またはサーバー間のバランス調整方法

» ガードiviのフグ

» 非パーソナライズガイドライン:関連付け方法

» 都市別および重量別、またはCDNノード間のバランス調整方法

» 私はGrootです。 イベントの分析を行います

» すべて1つまたはCDNの構築方法



All Articles