項目一覧
高度なMC-LAGの概念
設定の同期について
設定の同期は、QFXシリーズスイッチ、Junos Fusion Provider Edge、Junos Fusion Enterprise、EXシリーズスイッチ、MXシリーズルーターで動作します。
このトピックでは、以下について説明します。
- コンフィギュレーションの同期の利点
- 構成の同期の仕組み
- コンフィギュレーションの同期を有効にする方法
- 設定の同期のサポート方法
- ローカル、リモート、およびグローバル設定の設定グループ
- 特定のデバイスに対する条件付きグループの作成
- 設定グループの適用
- コンフィギュレーション同期のためのデバイス構成の詳細
- デバイス間での設定とコミットの同期方法
コンフィギュレーションの同期の利点
設定の同期により、あるデバイスから別のデバイスに設定を伝播、同期、およびコミットできます。これらのデバイスのいずれかにログインして、すべてのデバイスを管理できるため、単一の管理ポイントを持つことができます。
構成の同期の仕組み
設定グループを使用して、設定プロセスを簡素化します。例えば、ローカルデバイス用に1つの設定グループ、リモートデバイス用に1つ以上の設定グループ、そして基本的にすべてのデバイスに共通する設定であるグローバル設定用に1つの設定グループを作成することができます。
さらに、条件グループを作成して、設定を別のデバイスと同期するタイミングを指定できます。[edit system commit]
階層で peers-synchronize
ステートメントを有効にすると、デフォルトでデバイス間で設定とコミットを同期させることができます。SSH上のNETCONFはデバイス間の安全な接続を提供し、セキュアコピープロトコル(SCP)はデバイス間で設定を安全にコピーします。
コンフィギュレーションの同期を有効にする方法
設定の同期を有効にするには、次の手順を実行します。
ローカルデバイスをリモートデバイスに静的にマッピングします。
ローカル、リモート、グローバル設定用の設定グループを作成します。
条件グループを作成します。
適用グループを作成します。
SSH経由のNETCONFを有効にします。
構成を同期するためのデバイスの詳細とユーザー認証の詳細を構成します。
peers-synchronize
ステートメントを有効にするか、commit peers-synchronize
コマンドを発行して、ローカルとリモートデバイス間の設定を同期してコミットします。
設定の同期のサポート方法
MXシリーズルーターとJunos Fusionでは、Junos OS リリース14.2R6から設定同期のサポートが開始されました。QFXシリーズスイッチでは、Junos OS リリース15.1X53-D60から設定同期のサポートが開始されました。
ローカル、リモート、およびグローバル設定の設定グループ
ローカル、リモート、グローバル設定用の設定グループを作成できます。ローカル設定グループはローカル デバイスによって使用され、リモート設定グループはリモート デバイスによって使用され、グローバル設定グループはローカルとリモート デバイス間で共有されます。
例えば、ローカル デバイス(スイッチ A)が使用する設定を含むグループ A というローカル設定グループ、リモート デバイス(スイッチ B、スイッチ C、スイッチ D)が使用する設定を含むグループ B というリモート設定グループ、すべてのデバイスに共通する設定を含むグループ C というグローバル設定グループを作成できます。
[edit groups]
階層レベルで設定グループを作成します。
構成の同期では、ネストされたグループはサポートされません。
特定のデバイスに対する条件付きグループの作成
条件グループを作成して、特定の設定をデバイスに適用するタイミングを指定できます。たとえば、4 つのデバイスで構成されているすべてのデバイスにグローバル コンフィギュレーションを適用する場合は、[edit groups]
階層レベルで when peers [<name of local peer> <name of remote peer> <name of remote peer> <name of remote peer>]
ステートメントを有効にします。たとえば、グローバル設定(グループ C)をローカルおよびリモート デバイス(スイッチ A、スイッチ B、スイッチ C、およびスイッチ D)に適用する場合は、set groups Group C when peers [Switch A Switch B Switch C Switch D] コマンドを発行できます。
設定グループの適用
設定グループを適用するには、[edit]
階層レベルで apply-groups
ステートメントを有効にします。たとえば、ローカル設定グループ(グループAなど)、リモート設定グループ(グループBなど)、グローバル設定グループ(グループCなど)を適用するには、set apply-groups [ GroupA GroupB GroupC ]コマンドを発行します。
コンフィギュレーション同期のためのデバイス構成の詳細
デバイス間で設定を同期させるには、リモート デバイスのホスト名または IP アドレス、ユーザー名、パスワードを設定する必要があります。これを行うには、ローカルデバイスの[edit system commit]
階層で set peers <hostname-of-remote-peer> user <name-of-user> authentication <plain-text-password-string>
コマンドを発行します。
たとえば、スイッチ A からスイッチ B に設定を同期させるには、スイッチ A で set peers SwitchB user administrator authentication test123 コマンドを発行します。
また、ローカルデバイスをリモートデバイスに静的にマッピングする必要があります。これに対して、 set system commit peers
たとえば、スイッチAからスイッチB、スイッチC、およびスイッチDへの設定を同期させるには、スイッチAで次のように設定します。
スイッチA
[edit system commit] peers { switchB { user admin-swB; authentication "$ABC123"; } switchC { user admin-swC; authentication ""$ABC123"; } switchD { user admin-swD; authentication "$ABC123"; } } [edit system] static-host-mapping [ SwitchA{ inet [ 10.92.76.2 ]; } SwitchB{ inet [ 10.92.76.4 ]; } SwitchC{ inet [ 10.92.76.6 ]; } SwitchD{ inet [ 10.92.76.8 ]; } } }
スイッチAからスイッチB、スイッチC、およびスイッチDへの設定のみを同期する場合は、スイッチB、スイッチC、およびスイッチDで peers
ステートメントを設定する必要はありません。
peersステートメントの設定詳細は、デバイス間のSSH接続を介してNETCONFを確立するためにも使用されます。SSH経由のNETCONFを有効にするには、すべてのデバイスで set system services netconf ssh
コマンドを発行します。
デバイス間での設定とコミットの同期方法
peers-synchronize
ステートメントを有効にした、またはcommit peers-synchronize
コマンドを発行したローカル(または要求側)デバイスは、その設定をコピーして、リモート(または応答側)デバイスにロードします。次に、各デバイスは、コミットされる構成ファイルに対して構文チェックを実行します。エラーが見つからなければ、設定が有効になり、すべてのデバイスで現在動作している設定になります。コミットは、リモート手続き型呼び出し (RPC) を使用して伝達されます。
コンフィギュレーションの同期中に、以下のイベントが発生します。
ローカルデバイスは、sync-peers.confファイル(条件付きグループで指定されたデバイスと共有される設定)をリモートデバイスに送信します。
リモート デバイスは、設定をロードし、ロードの結果をローカル デバイスに送信し、その設定をローカル デバイスにエクスポートし、コミットが完了したことを返します。
ローカルデバイスは、リモートデバイスからの応答を読み取ります。
成功すると、設定がコミットされます。
a)リモートデバイスが利用できない場合、または b)リモートデバイスに到達可能であるが、以下の理由により障害が発生する場合、設定の同期は成功しません。
ユーザーと認証の問題により、SSH 接続が失敗します。
リモート データベースでロックを取得できないため、Junos OS RPC が失敗します。
構文上の問題により、設定の読み込みに失敗します。
コミットチェックに失敗します。
peers-synchronize
ステートメントは、peers
ステートメントで設定したデバイスのホスト名またはIPアドレス、ユーザー名、およびパスワードを使用します。peers-synchronize
ステートメントを有効にすると、commit
コマンドを発行するだけで、あるデバイスから別のデバイスに設定を同期させることができます。例えば、ローカルデバイスで peers
ステートメントを設定し、その設定をリモートデバイスと同期させたい場合、ローカルデバイスで commit
コマンドを発行するだけで済みます。ただし、ローカルデバイスで commit
コマンドを発行したときにリモートデバイスに到達できない場合は、リモートデバイスに到達できず、ローカルデバイスの設定のみがコミットされるという警告メッセージが表示されます。
警告メッセージの例を次に示します。
error: netconf: could not read hello error: did not receive hello packet from server error: Setting up sessions for peer: 'peer1' failed warning: Cannot connect to remote peers, ignoring it commit complete
リモートデバイス情報で peers
ステートメントが設定されていない場合に commit
コマンドを発行すると、ローカルデバイスでの設定のみがコミットされます。リモート デバイスに到達できず、他の障害がある場合、ローカル デバイスとリモート デバイスの両方でコミットは失敗します。
peers-synchronize
ステートメントを有効にして commit
コマンドを発行すると、コミットが通常のコミットよりも長くかかる場合があります。設定がデバイス間で同じで、同期が不要な場合でも、システムは設定の同期を試みます。
commit peers-synchronize
コマンドは、peers
ステートメントで設定されたデバイスのホスト名またはIPアドレス、ユーザー名、およびパスワードも使用します。ローカルデバイスで commit peers-synchronize
コマンドを発行してリモートデバイスと設定を同期し、リモートデバイスに到達可能であっても、他の障害が発生した場合、ローカルデバイスとリモートデバイスの両方でコミットに失敗します。
マルチシャーシ リンク アグリゲーション グループ設定の整合性チェックについて
マルチシャーシリンクアグリゲーショングループ(MC-LAG)の不整合がある場合、通知され、それを解決するためのアクションを取ることができます。不一致の例としては、両方のピアで一意のシャーシ ID を設定するのではなく、両方のピアで同一のシャーシ ID を設定することが挙げられます。コミットされたMC-LAGパラメータのみの整合性がチェックされます。
- MC-LAG整合性チェックを使用するメリット
- MC-LAG整合性チェックの仕組み
- 構成の一貫性に関する要件
- リモートピアに到達できない場合
- MC-LAG 設定整合性チェックの有効化
- 設定整合性チェックのステータスの学習
- MC-LAG 設定整合性チェックのサポート
MC-LAG整合性チェックを使用するメリット
この機能は、マルチシャーシリンクアグリゲーショングループ(MC-LAG)ピア間の設定パラメータの不一致を見つけるのに役立ちます。
MC-LAG整合性チェックの仕組み
ローカル MC-LAG ピアでコミットを発行した後の設定整合性チェック中に、次のイベントが発生します。
ローカル MC-LAG ピアで MC-LAG 設定をコミットします。
ICCP は MC-LAG の設定を解析し、リモートの MC-LAG ピアに設定を送信します。
リモート MC-LAG ピアは、ローカル MC-LAG ピアから MC-LAG 設定を受け取り、それを自身の MC-LAG 設定と比較します。
2つのMC-LAG設定間に重大な不一致がある場合、MC-LAGインターフェイスがダウンし、syslogメッセージが発行されます。
2 つの設定に適度な不一致がある場合は、syslog メッセージが発行されます。
リモート MC-LAG ピアでコミットを発行した後の設定整合性チェック中に、次のイベントが発生します。
リモート MC-LAG ピアで MC-LAG 設定をコミットします。
ICCPはMC-LAG設定を解析し、ローカルMC-LAGピアに設定を送信します。
ローカル MC-LAG ピアは、リモート MC-LAG ピアから設定を受信し、自身の設定と比較します。
2つの設定間に重大な不一致がある場合、MC-LAGインターフェイスがダウンし、syslogメッセージが発行されます。
2 つの設定に適度な不一致がある場合は、syslog メッセージが発行されます。
構成の一貫性に関する要件
MC-LAGパラメータに応じて、設定の一貫性に関する要件は異なります。整合性の要件は、同一または一意です。つまり、一部のパラメータは同一に設定する必要があり、一部はMC-LAGピア上で一意に設定する必要があります。例えば、シャーシ ID は両ピアで一意である必要がありますが、LACP モードは両ピアで同一である必要があります。
整合性要件の適用レベル (同一または一意) は、必須または望ましいものです。適用レベルが必須の場合に、MC-LAGパラメータの設定を誤ると、システムはインターフェイスをダウンさせ、syslogメッセージを発行します。
たとえば、次のような syslog メッセージを受信したとします “Some of the Multichassis Link Aggregation (MC-LAG) configuration parameters between the peer devices are not consistent. The concerned MC-LAG interfaces were explictly brought down to prevent unwanted behavior.”
不整合を修正し、コミットを正常に発行すると、システムはインターフェイスを起動します。適用が望まれる場合に、MC-LAGパラメータを誤って設定すると、次の内容のsyslogメッセージが表示されます "Some of the Multichassis Link Aggregation(MC-LAG) configuration parameters between the peer devices are not consistent. This may lead to sub-optimal performance of the feature."
。 syslogメッセージに記載されているように、この状況ではパフォーマンスは最適ではありません。 また、show interfaces mc-ae コマンドを発行して、マルチシャーシの集合型イーサネットインターフェイスの設定整合性チェックステータスを表示することもできます。
複数の不整合がある場合は、最初の不整合のみが表示されます。MC-LAGパラメータの適用レベルが必須であり、そのパラメータを正しく設定しなかった場合、コマンドはMC-LAGインターフェイスがダウンしていることを示します。
リモートピアに到達できない場合
ローカルピアでコミットを発行し、リモートピアに到達できない場合、設定整合性チェックに合格し、ローカルピアをスタンドアロンモードで起動できます。リモートピアが立ち上がると、ICCPはピア間で設定を交換します。整合性チェックに失敗した場合、MC-LAGインターフェイスがダウンし、不整合の原因となったパラメータがシステムから通知されます。不一致を修正し、コミットを正常に発行すると、システムはインターフェイスを起動します。
MC-LAG 設定整合性チェックの有効化
整合性チェックはデフォルトで有効になっています。 表 1 は、整合性チェックされるコミットされた MC-LAG パラメータのサンプル リストと、その整合性要件(同一または一意)、パラメータが設定されている階層、および整合性チェックの実施レベル(必須または望ましい)を示しています。
コンフィグレーションノブ |
階層 |
一貫性の要件 |
実施 |
---|---|---|---|
ピア間で ICCP(Inter-Chassis Control Protocol)接続を確立する時間を指定します。 |
|
|
|
インターフェイスに関連付けられるMACアドレスの最大数を指定します。 |
|
|
|
MC-AEインターフェイスに関連付けられるMACアドレスの最大数を指定します。 |
|
|
|
VLAN に関連付ける MAC アドレスの最大数を指定しますが、デフォルトは無制限であるため、ネットワークがフラッディングに対して脆弱なままになる可能性があります。 |
|
|
|
MACアドレスがイーサネットスイッチングテーブルに残る期間を指定します。 |
|
|
|
|
|
|
|
異なる RSTP ルーティング インスタンスに異なるブリッジ識別子を指定します。 |
|
|
|
異なる MSTP ルーティング インスタンスに異なるブリッジ識別子を指定します。 |
|
|
|
RSTP のルート ブリッジとして選択されるブリッジを決定します。2 つのブリッジのルート ブリッジへのパス コストが同じ場合、ブリッジのプライオリティによって、どちらのブリッジが LAN セグメントの指定ブリッジになるかが決まります。 |
|
|
|
MSTP のルート ブリッジとして選択されるブリッジを決定します。2 つのブリッジのルート ブリッジへのパス コストが同じ場合、ブリッジのプライオリティによって、どちらのブリッジが LAN セグメントの指定ブリッジになるかが決まります。 |
|
|
|
RSTP 用にスイッチのすべてのエッジ ポート上のブリッジ プロトコル データ ユニット(BPDU)保護を設定します。 |
|
|
|
VSTP 用にスイッチのすべてのエッジ ポートでブリッジ プロトコル データ ユニット(BPDU)保護を設定します。 |
|
|
|
MSTP 用にスイッチのすべてのエッジ ポートでブリッジ プロトコル データ ユニット(BPDU)保護を設定します。 |
|
|
|
リンクアグリゲーショングループ(LAG)に属する各マルチシャーシの集合型イーサネットインターフェイスのサービス識別子を指定します。 |
|
|
|
ローカル ルーティング デバイスが Hello パケットを送信し、BFD セッションを確立したネイバーからの応答を受信することを期待する最小間隔を設定します。 |
|
|
|
ローカル ルーティング デバイスが BFD セッションを確立したネイバーに Hello パケットを送信する最小間隔を指定します。 |
|
|
|
ローカルルーティングデバイスがBFDセッションを確立したネイバーから応答を受信する最小間隔を指定します。 |
|
|
|
ネイバーが受信しない hello パケットの数を設定すると、発信元インターフェイスがダウンと宣言されます。 |
|
|
|
シングル ホップの BFD セッションを設定します。 |
|
|
|
認証キーのパスワードを指定して、MC-LAG をホストしているピアから送信されたパケットの信頼性を確認します。 |
|
|
|
冗長グループ識別番号を指定します。ICCP(シャーシ間制御プロトコル)は、冗長グループIDを使用して、同様の冗長性機能を実行する複数のシャーシを関連付けます。 |
|
|
|
2 つの ICCP(Inter-Chassis Control Protocol)ピア間の管理リンク上でキープアライブ メッセージを交換して、ピアがアップしているかダウンしているかを判断します。 |
|
|
|
MC-LAGデバイスの識別番号を指定します。 |
|
|
|
ICCPが、同様の冗長機能を実行する複数のシャーシを関連付け、ピアリングシャーシ上のアプリケーションが相互にメッセージを送信できるように通信チャネルを確立するために使用されます。 |
|
|
|
MC-LAG の物理メンバーリンクのポート番号を計算するために LACP で使用されます。 |
|
|
|
MC-LAGがアクティブ/スタンバイモードかアクティブ/アクティブモードかを示します。 |
|
|
|
シャーシ間リンク障害が発生したときに、シャーシをアクティブにするか、スタンバイモードのままになるかを指定します。 |
|
|
|
ICCPピアがダウンした場合に、シャーシ間リンク論理インターフェイスがダウンすることを指定します。 |
|
|
|
このノードのピアがダウンした場合、 |
|
|
|
LACPをアクティブまたはパッシブに指定します。 |
|
|
|
LACPパケットの定期送信間隔を指定します。 |
|
|
|
LACPシステム識別子を集合型イーサネットインターフェイスレベルで定義します。 |
|
|
|
ルーターまたはスイッチの管理キーを指定します。 |
|
|
|
ポート上のタグなしパケットに対する混合タグなしパケットサポートを設定します。 |
|
|
|
MC-LAG に参加しているスイッチのレイヤー 3 インターフェイスの MAC アドレスを同期します。 |
|
|
|
ブリッジ ドメイン、VLAN、仮想スイッチ、またはブリッジ ドメインや VLAN のセットから学習できる MAC アドレスの数の制限を設定します。 |
|
|
|
レイヤー 3 インターフェイスを VLAN に関連づけます。 |
|
|
|
IGMP スヌーピングを有効にします。レイヤー 2 デバイスは、接続された各ホストからマルチキャスト ルーターに送信される IGMP Join および Leave メッセージを監視します。これにより、レイヤー2デバイスは、マルチキャストグループと関連づけられたメンバーポートを追跡できます。レイヤー 2 デバイスはこの情報を使用してインテリジェントな判断を行い、マルチキャスト トラフィックを目的の宛先ホストにのみ転送します。 |
|
|
|
論理インターフェイスで設定されたプロトコルファミリーを指定します。 |
|
|
|
IRB インターフェイスの IPv4 アドレスを指定します。 |
|
|
|
IRB インターフェイスの IPv6 アドレスを指定します。 |
|
|
|
VRRP グループ識別子を指定します。 |
|
|
|
イーサネット インターフェイスの場合のみ、ルーターまたはスイッチに ARP リクエスト ターゲット アドレスへのアクティブなルートがある限り、ARP リクエストに応答するようにルーターまたはスイッチを設定します。 |
|
|
|
プライマリデフォルトルーターになるためのVRRP(Virtual Router Redundancy Protocol)ルーター優先度を設定します。グループ内でプライオリティが最も高いルータがプライマリになります。 |
|
|
|
VRRP(Virtual Router Redundancy Protocol)IPv4 認証キーを設定します。また、authentication-type ステートメントを含めて、VRRP 認証スキームを指定する必要があります。 |
|
|
|
VRRP(Virtual Router Redundancy Protocol)IPv4認証を有効にし、VRRPグループの認証方式を指定します。 |
|
|
|
VRRP(Virtual Router Redundancy Protocol)IPv4 または IPv6 グループ内の仮想ルーターのアドレスを設定します。 |
|
|
|
論理リンク層カプセル化タイプを設定します。 |
|
|
|
同じイーサネットポート上の論理インターフェイス、および疑似回線論理インターフェイス上の802.1Q VLANシングルタグおよびデュアルタグフレームの同時送信をサポートします。 |
|
|
|
ファストイーサネットおよびギガビットイーサネットインターフェイス、VPLSに設定された集合型イーサネットインターフェイス、および疑似回線加入者インターフェイスでは、インターフェイス上で802.1Q VLANタグ付きフレームの送受信を有効にします。 |
|
|
|
メディアまたはプロトコルの最大送信単位(MTU)サイズを指定します。 |
|
|
|
論理インターフェイスがVLANタグに基づいてパケットを受け入れるか破棄するかを決定します。 |
|
|
|
インターフェイスに属する VLAN の名前を指定します。 |
|
|
|
設定整合性チェックのステータスの学習
次のコマンドは、設定整合性チェックのステータスに関する情報を提供します。
show multi-chassis mc-lag configuration-consistency list-of-parameters コマンドを発行して、不整合、整合性要件(同一または一意)、および適用レベル(必須または望ましい)についてチェックされたコミットされた MC-LAG パラメータのリストを表示します。
show multi-chassis mc-lag configuration-consistency コマンドを発行して、整合性のなさがチェックされたコミットされた MC-LAG パラメータのリスト、整合性要件(同一または一意)、適用レベル(必須または必須)、および設定整合性チェックの結果を表示します。結果は合格または不合格です。
show multi-chassis mc-lag configuration-consistency global-config コマンドを発行して、MC-LAG 機能に関連するすべてのグローバル設定の設定整合性チェック ステータス、整合性要件(同一または一意)、適用レベル(必須または必須)、および設定整合性チェックの結果を表示します。結果は合格または不合格です。
show multi-chassis mc-lag configuration-consistency icl-config コマンドを発行して、シャーシ間制御リンク、整合性要件(同一または一意)、適用レベル(必須または必須)、および設定整合性チェックの結果に関連するパラメータの設定整合性チェック ステータスを表示します。結果は合格または不合格です。
show multi-chassis mc-lag configuration-consistency mcae-configコマンドを発行して、マルチシャーシ集合型イーサネットインターフェイスに関連するパラメータの設定整合性チェックステータス、整合性要件(同一または一意)、実施レベル(必須または望ましい)、および設定整合性チェックの結果を表示します。結果は合格または不合格です。
コマンドを show multi-chassis mc-lag configuration-consistency vlan-config 発行して、VLAN 設定、整合性要件(同一または一意)、適用レベル(必須または望ましい)、および設定整合性チェックの結果に関連するパラメータの設定整合性チェック ステータスを表示します。結果は合格または不合格です。
コマンドを show multi-chassis mc-lag configuration-consistency vrrp-config 発行して、VRRP 設定に関連するパラメータの設定整合性チェック ステータス、整合性要件(同一または一意)、適用レベル(必須または必須)、および設定整合性チェックの結果を表示します。結果は合格または不合格です。
show interfaces mc-aeコマンドを発行して、マルチシャーシの集合型イーサネットインターフェイスの設定整合性チェックステータスを表示します。複数の不整合がある場合は、最初の不整合のみが表示されます。MC-LAGパラメータの適用レベルが必須であり、そのパラメータを正しく設定しなかった場合、コマンドはMC-LAGインターフェイスがダウンしていることを表示します。
MC-LAG 設定整合性チェックのサポート
EXシリーズスイッチとQFXシリーズスイッチはどちらも、MC-LAG設定整合性チェックをサポートしています。
QFX10000 スイッチの 15.1X53-D60 Junos OS リリース以降、設定整合性チェックでは、ICCP(シャーシ間制御プロトコル)を使用して MC-LAG 設定パラメータ(シャーシ ID、サービス ID など)を交換し、MC-LAG ピア間で設定の不一致がないかチェックします。
参照
不明なユニキャストおよび IGMP スヌーピング
-
MC-LAGピアの再起動中に、IGMPスヌーピング状態がピアと同期されるまで、既知のマルチキャストトラフィックがフラッディングされます。
-
フラッディングは、両方のピアに仮想LANメンバーシップがある場合、ピア全体のすべてのリンクで発生します。
一方のピアだけが、特定の MC-LAG リンク上でトラフィックを転送します。
-
ICLポートをマルチキャストルーターポートとして追加することで、既知および未知のマルチキャストパケットをピア間で転送します。
-
MC-LAGリンクで学習されたIGMPメンバーシップは、ピア間で伝搬されます。
MC-LAG環境で正しく動作するためには、IGMP(Internet Group Management Protocol)スヌーピングの
multichassis-lag-replicate-state
ステートメントを設定する必要があります。
レイヤー 3 ユニキャスト機能のサポート
レイヤー 3 ユニキャスト機能のサポートには以下が含まれます。
-
VRRP アクティブ/スタンバイのサポートにより、MC-AE インターフェイス上でレイヤー 3 ルーティングが可能になります。
-
RVI(Routed VLAN Interface)または IRB MAC アドレスの同期により、MC-LAG ピアは、MC-AE インターフェイスに到着したレイヤー 3 パケットを、それ自身の RVI または IRB MAC アドレス、あるいはピア RVI または IRB MAC アドレスのいずれかに転送できます。
-
アドレス解決プロトコル(ARP) 同期により、両方のMC-LAGピアでARP解決が可能になります。
-
オプション 82 の DHCP リレーは、MC-LAG ピアでオプション 82 を有効にします。オプション 82 は、DHCP クライアントのネットワーク上の場所に関する情報を提供します。DHCPサーバーは、この情報を使用して、IPアドレスやその他のパラメータをクライアントに実装します。
MACアドレスの管理
MC-LAG がアクティブ/アクティブに設定されている場合、アップストリームとダウンストリームのトラフィックは異なる MC-LAG ピア デバイスを経由する可能性があります。MAC アドレスは一方の MC-LAG ピアでのみ学習されるため、逆方向のトラフィックがもう一方の MC-LAG ピアを通過し、ネットワークに不必要にフラッディングする可能性があります。また、シングルホーム クライアントの MAC アドレスは、接続されている MC-LAG ピアでのみ学習されます。ピアMC-LAGネットワークデバイスに接続されたクライアントがそのシングルホームクライアントと通信する必要がある場合、トラフィックはピアMC-LAGネットワークデバイスにあふれます。不要なフラッディングを避けるため、MC-LAGピアの1つでMACアドレスが学習されるたびに、アドレスが他のMC-LAGピアに複製されます。MAC アドレスの複製を実行する場合、以下の条件が適用されます。
IRB または RVI インターフェイスの MAC アドレスが変更された場合、Gratuitous ARP 要求は送信されません。
-
一方の MC-LAG ピアの MC-LAG で学習した MAC アドレスは、もう一方の MC-LAG ピアの同じ MC-LAG で学習したものとして複製する必要があります。
-
一方の MC-LAG ピアのシングルホームの CE(カスタマー エッジ) クライアントで学習した MAC アドレスは、もう一方の MC-LAG ピアの ICL インターフェイスで学習したものとして複製する必要があります。
-
ICLでのMACアドレス学習は、データパスからは無効になっています。ICCPを介して複製されたMACアドレスをインストールするには、ソフトウェアが必要です。
IRB または RVI が設定されていない VLAN がある場合、MAC アドレス レプリケーションによって MAC アドレスが同期されます。
MAC エージング
Junos OS の MAC エージング サポートは、指定された MC-LAG 向けの集合型イーサネット ロジックを拡張します。ソフトウェアのMACアドレスは、すべてのパケット転送エンジンがMACアドレスを削除するまで削除されません。
アドレス解決プロトコル アクティブ-アクティブ MC-LAG のサポート方法
アドレス解決プロトコル(ARP)は、IPアドレスをMACアドレスにマッピングします。Junos OS は、ARP 応答パケット スヌーピングを使用してアクティブ/アクティブ MC-LAG をサポートするため、特定の状態を維持することなく簡単に同期できます。同期を行わない場合、一方の MC-LAG ピアが ARP 要求を送信し、他方の MC-LAG ピアが応答を受信した場合、ARP 解決は成功しません。同期では、MC-LAGピアは、ARP応答を受信するMC-LAGピアでパケットをスニッフィングし、これを他のMC-LAGピアに複製することで、ARP解決を同期します。これにより、MC-LAG ピアの ARP テーブルのエントリーの一貫性が確保されます。
MC-LAG ピアの 1 つが再起動すると、その MC-LAG ピアの ARP 宛先が同期されます。ARPの宛先はすでに解決されているため、そのMC-LAGピアは、マルチシャーシの集合型イーサネットインターフェイスからレイヤー3パケットを転送できます。
DHCPリレー(Option 82搭載)
オプション 82 の DHCP リレーは、DHCP クライアントのネットワーク上の場所に関する情報を提供します。DHCPサーバーは、この情報を使用して、IPアドレスやその他のパラメータをクライアントに実装します。DHCPリレーを有効にすると、DHCPリクエストパケットはMC-LAGピアのいずれかを経由してDHCPサーバーへのパスを取る可能性があります。MC-LAGピアはホスト名、シャーシMACアドレス、インターフェイス名が異なるため、オプション82でDHCPリレーを設定する場合は、次の要件に従う必要があります。
ご使用の環境が IPv6 のみをサポートしている場合、または他の理由で拡張 DHCP リレー エージェント(jdhcp)プロセスを使用する必要がある場合は、回避策として、IPv4 の場合は forwarding-options dhcp-relay forward-only
コマンド、IPv6 の場合は forwarding-options dhcpv6 forward-only
コマンドを使用して、前方転送専用サポートを設定できます。また、ネットワーク内の DHCP サーバーがオプション 82 をサポートしていることも確認する必要があります。
-
インターフェイス名ではなく、インターフェイスの説明を使用します。
-
ホスト名を回線 ID またはリモート ID 文字列の一部として使用しないでください。
-
シャーシのMACアドレスをリモートID文字列の一部として使用しないでください。
-
ベンダー ID を有効にしないでください。
-
ICLインターフェイスがDHCP要求パケットを受信すると、パケットは破棄され、ネットワーク内でパケットが重複するのを防ぎます。
show helper statistics
コマンドにDue to received on ICL interfaceと呼ばれるカウンタが追加されました。このカウンタは、ICLインターフェイスがドロップしたパケットを追跡します。CLI出力の例を以下に示します。
user@switch> show helper statistics BOOTP: Received packets: 6 Forwarded packets: 0 Dropped packets: 6 Due to no interface in DHCP Relay database: 0 Due to no matching routing instance: 0 Due to an error during packet read: 0 Due to an error during packet send: 0 Due to invalid server address: 0 Due to no valid local address: 0 Due to no route to server/client: 0 Due to received on ICL interface: 6
この出力は、ICL インターフェイスで受信した 6 つのパケットがドロップされたことを示しています。
サポートされるレイヤー 2 ユニキャスト機能
-
手記:
MAC 学習は ICL で自動的に無効になります。そのため、送信元MACアドレスをICLでローカルに学習することはできません。ただし、リモートMC-LAGノードからのMACアドレスは、ICLインターフェイスにインストールできます。たとえば、リモート MC-LAG ノード上のシングルホーム クライアントの MAC アドレスは、ローカル MC-LAG ノードの ICL インターフェイスにインストールできます。
レイヤー2ユニキャスト学習とエージングの仕組み:
-
学習されたMACアドレスは、ピア間で生成されたすべてのVLANに対して、MC-LAGピア間で伝搬されます。
-
MAC アドレスのエージングは、MAC アドレスが両方のピアで見られない場合に発生します。
-
シングルホーム リンクで学習された MAC アドレスは、メンバーとして MC-LAG リンクを持つすべての VLAN に伝播されます。
プロトコル独立マルチキャスト
PIM(プロトコル独立マルチキャスト) と IGMP(インターネットグループ管理プロトコル) は、レイヤー3マルチキャストをサポートしています。PIM 動作の標準モードに加えて、PIM デュアル指定ルータと呼ばれる特別なモードがあります。PIM デュアル指定ルーターにより、障害発生時のマルチキャスト トラフィックの損失を最小限に抑えます。
レイヤー3マルチキャストを使用している場合は、アクティブMC-LAGピアで、高いIPアドレスまたは高い指定ルーター優先度でIPアドレスを設定します。
PIMデュアル指定ルーターは、EX9200およびQFX10000スイッチではサポートされていません。
PIM の動作については、次のセクションで説明します。
通常モード指定ルーター選択での PIM 動作
指定されたルーターが選出される通常のモードでは、両方の MC-LAG ピアの IRB または RVI インターフェイスは PIM を有効にして設定されます。このモードでは、MC-LAG ピアの 1 つが、PIM の指定ルーター選択メカニズムによって指定ルーターになります。選出された指定ルーターは、ソースデバイスからデータを受信できるように、ランデブーポイントツリー(RPT )と最短パスツリー(SPT) を維持します。選出された指定ルーターは、ランデブー ポイントまたは送信元に向けて、定期的な PIM 参加およびプルーニング アクティビティに参加します。
これらの参加およびプルーニング アクティビティを開始するトリガーは、関心のある受信者から受信した IGMP メンバーシップ レポートです。マルチシャーシの集合型イーサネットインターフェイス(MC-LAGピアのいずれかでハッシュされる可能性がある)およびシングルホームリンクで受信したIGMPレポートは、ICCPを介してMC-LAGピアに同期されます。
両方のMC-LAGピアは、着信インターフェイス(IIF)でトラフィックを受信します。非指定ルーターは、マルチキャストルーター(mrouter)インターフェイスとして機能するICLインターフェイスを介してトラフィックを受信します。
指定ルーターに障害が発生した場合、指定されていないルーターは転送ツリー全体(RPT と SPT)を構築する必要があり、マルチキャスト トラフィック損失が発生する可能性があります。
デュアル指定ルータ モードでの PIM 動作
デュアル指定ルーター モードでは、両方のMC-LAGピアが指定ルーター(アクティブとスタンバイ)として機能し、ランデブー ポイントまたは送信元に向かってアップストリームに定期的な参加およびプルーニング メッセージを送信し、最終的に RPT または SPT に参加します。
スタンバイ MC-LAG ピアのプリファレンス メトリックが小さい場合でも、プライマリ MC-LAG ピアはマルチキャスト トラフィックを受信側に転送します。
スタンバイ MC-LAG ピアも転送ツリーに参加し、マルチキャスト データを受信します。スタンバイMC-LAGピアは、空の発信インターフェイスリスト(OIL)があるため、データをドロップします。スタンバイ MC-LAG ピアは、プライマリ MC-LAG ピアの障害を検出すると、レシーバー VLAN を OIL に追加し、マルチキャスト トラフィックの転送を開始します。
マルチキャスト デュアル指定ルーターを有効にするには、各 MC-LAG ピアの VLAN インターフェイスで set protocols pim interface interface-name dual-dr
コマンドを発行します。
障害処理
障害発生時のコンバージェンスを高速化するには、プライマリMC-LAGピアのIPアドレスに、より高いIPアドレスまたはより高い指定ルーター優先度を設定します。これにより、PIM ピアリングがダウンした場合、プライマリ MC-LAG ピアが指定されたルーター メンバーシップを維持できます。
MC-AE インターフェイスがダウンした場合にトラフィックが収束するように、ICL-PL インターフェイスは常に mrouter ポートとして追加されます。レイヤー 3 トラフィックは、ICL-PL インターフェイス上のデフォルト エントリまたはスヌーピング エントリを介してフラッディングされ、トラフィックは MC-LAG ピア上の MC-AE インターフェイスに転送されます。ICL-PL インターフェイスがダウンすると、PIM ネイバーシップもダウンします。この場合、両方のMC-LAGピアが指定ルーターになります。バックアップMC-LAGピアのリンクがダウンし、ルーティングピアリングが失われます。ICCP接続がダウンした場合、バックアップMC-LAGピアはLACPシステムIDを変更し、MC-AEインターフェイスを停止します。PIM ネイバーの状態は引き続き動作します。
IGMP レポートの同期
MC-AEインターフェイスおよびシングルホーム リンクを介して受信したIGMPレポートは、MC-LAGピアに同期されます。MC-LAGピア上のMCSNOOPDクライアントアプリケーションは、ICCP経由で同期パケットを受信し、ルーティングソケットPKT_INJECTメカニズムを使用してパケットのコピーをカーネルに送信します。カーネルはパケットを受信すると、パケットをルーティングプロトコルプロセス(rpd)に送信し、MC-LAG VLAN上に設定された RVI(Routed VLAN Interface) 上で、PIMやIGMPなどのレイヤー3マルチキャストプロトコルを有効にします。
MC-LAGアクティブ-アクティブモードでのIGMPスヌーピング
MC-LAGアクティブ/アクティブモードでのIGMPスヌーピングは、MX240ルーター、MX480ルーター、MX960ルーター、QFXシリーズスイッチでサポートされています。
以下のトピックについて説明します。
- MC-LAGのIGMPスヌーピング アクティブ/アクティブモード機能
- MC-LAGアクティブ/アクティブブリッジングによるIGMPスヌーピングで一般的にサポートされているネットワークトポロジー
- リモートシャーシで受信したパケットによって引き起こされるコントロールプレーンの状態の更新
- データ転送
- ルーティングとブリッジングを統合しない純粋なレイヤー2トポロジー
- 適格な学習
- 認定学習によるデータ転送
- シングルホームインターフェイスの静的グループ
- マルチシャーシリンクとしてのルーターに接続するインターフェイス
MC-LAGのIGMPスヌーピング アクティブ/アクティブモード機能
MC-LAG(Multi-Chassis Link Aggregation Group)アクティブ/アクティブモードと、アクティブ/スタンバイモードでのIGMPスヌーピングがサポートされています。MC-LAGでは、1台のデバイスで2台以上のネットワークデバイスと論理LAGインターフェイスを形成できます。MC-LAGは、ノードレベルの冗長性、マルチホーミング、およびスパニングツリープロトコル(STP)を実行しないループフリーのレイヤー2ネットワークなどの追加のメリットを提供します。次の機能がサポートされています。
レイヤー 2 インターフェイスのみを持つブリッジ ドメインにおける IGMP スヌーピングのピア間の状態同期
適格な学習
ルーターに接続するマルチシャーシリンク
アクティブ/アクティブブリッジングと、IRB(統合型ルーティングおよびブリッジング)上のVRRP(Virtual Router Redundancy Protocol)に対する以下の機能拡張がサポートされています。
ピュア レイヤー 2 スイッチでの IGMP スヌーピングの MC-LAG サポート
ブリッジ ドメインでの IGMP スヌーピングに対する MC-LAG のサポート 適格な学習を行う
ルーターに接続するインターフェイスである MC-Link のサポート
以下の機能 not サポートされています。
VPLS インスタンスの MC-LAG
MC-Links トランク ポート
アクティブ/アクティブのプロキシ モード
必要に応じて、発信インターフェイスにシャーシ間リンクを追加する
シャーシ間リンクは、ルーターに接続するインターフェイスとして発信インターフェイスリストに追加できます。
MC-LAGアクティブ/アクティブブリッジングによるIGMPスヌーピングで一般的にサポートされているネットワークトポロジー
図 1 は、MC-LAG アクティブ/アクティブ ブリッジングによる IGMP スヌーピングがサポートされている典型的なネットワーク トポロジーを示しています。

インターフェイス I3 と I4 はシングルホーム インターフェイスです。マルチシャーシ リンク ae0.0 と ae0.1 は、両方のシャーシの同じブリッジ ドメインに属しています。インターフェイス I3、ae0.0、ae0.1 は、セカンダリ アクティブ(S-A)ルーターの同じブリッジ ドメインにあります。インターフェイス I4、ae0.0、ae0.1 は、プライマリ アクティブ(P-A)ルーターの同じブリッジ ドメインにあります。インターフェイス I3、I4、ae0.0、ae0.1 は、2 つのシャーシを接続するシャーシ間リンク(ICL)と同じ学習ドメインにあります。
プライマリアクティブルーターは、統合型ルーティングおよびブリッジングがPIM-DRになったシャーシです。セカンダリ アクティブ ルーターは、統合型ルーティングおよびブリッジングが PIM-DR ではないシャーシです。ルーターP-Aは、IPコアからトラフィックを引き出す役割を担うシャーシです。したがって、PIM-DR 選択は、データ トラフィックの重複を回避するために使用されます。
学習ドメインについては、「 適格な学習」で説明しています。
学習ドメインの IGMP スピーカー(ホストおよびルーター)の場合、P-A と S-A は、インターフェイス I4、I3、ae0.0、ae0.1 を備えた 1 つのデバイスとして表示されます。
マルチシャーシリンクでは、制御パケットを重複して送信しないように、つまり、制御パケットは1つのリンクのみで送信する必要があります。
リモートシャーシで受信したパケットによって引き起こされるコントロールプレーンの状態の更新
以下は、リモートシャーシで受信したパケットによってトリガーされるコントロールプレーンの状態の更新です。
レイヤー3マルチキャストルーティングのメンバーシップ状態は、マルチシャーシリンクのリモートレッグおよびリモートシャーシに接続されたSリンクで学習したレポートの結果として更新されます。
スヌーピングのメンバーシップ状態とルーティングエントリーは、マルチシャーシリンクのリモートレッグでレポートを受信すると更新されます。
リモートシャーシに接続されたSリンクでレポートを受信しても、スヌーピングのメンバーシップ状態またはルーティングエントリは更新されません。
PE ルーター間でマルチキャスト スヌーピング状態を同期する場合、グループ メンバーシップ タイムアウト タイマーなどのタイマーは同期されません。同期通知を受信すると、通知を受信するリモート PE ルーターが関連するタイマーを開始または再起動します。
状態が維持される<,g>のリストは、発信インターフェイスリストにマルチシャーシリンクのみが含まれる限り、スヌーピングされている両方のシャーシで同じです。
データ転送
この説明では、ルーター P-A の統合型ルーティングおよびブリッジングが PIM-DR であることを前提としています。コアのソースからトラフィックを引き出します。トラフィックは、ブリッジ ドメイン内のレイヤー 2 インターフェイスにも発生する可能性があります。P-A シャーシに直接接続されているホストの場合、データの配信方法に変更はありません。
I3のようなシングルホームリンクでS-A(非DR)に接続されたホストにトラフィックを配信する場合、シャーシ間リンクに依存します。P-A に到達したトラフィックは、ICL を介して S-A に送信され、s,g のインタレストを報告したリンクとルータに接続しているリンクに配信されます。
P-A の ae0 レッグがダウンすると、マルチシャーシ リンクに接続されているホストは ICL 経由でトラフィックを受信します。S-A では、ICL で受信されたトラフィックは、P-A の対応する ae がダウンしている発信インターフェイス リスト内のマルチシャーシ リンクに送信されます。
ルーティングとブリッジングを統合しない純粋なレイヤー2トポロジー
図 2 は、PIM-DR に接続しているシャーシがプライマリ アクティブ(P-A)ルーターで、もう一方がセカンダリ アクティブ(S-A)ルーターであることを示しています。

適格な学習
このトポロジーでは、インターフェイス I1、I2、I3、I4、I5、I6、I7、I8、I9、および I10 はシングルホーム インターフェイスです。マルチシャーシ リンク ae0.0 と ae0.1 は、両方のシャーシの同じブリッジ ドメインに属しています。インターフェイス I10、I1、I7、I3、I5、ae0.0、ae0.1 は同じブリッジ ドメイン(P-A の bd1)にあります。インターフェイス I9、I2、I8、I4、I6、ae0.0、ae0.1 は同じブリッジ ドメイン(S-A の bd1)にあります。
この説明では、次の設定を前提としています。
P-A と S-A では、bd1 で認定学習がオンになっています。
インターフェイス I1、I2、I3、ae0.0、I4 は、学習ドメイン ld1 の vlan1 に属しています。
インターフェイス I7、I8、I5、ae0.1、および I6 は、学習ドメイン ld2 の vlan2 に属しています。
インターフェイス I9 と I10 は、学習ドメイン ld3 の vlan3 に属しています。
同じ学習ドメイン ld1 内の IGMP スピーカー(ホストとルーター)では、リンクされた P-A と S-A は 1 つのスイッチのように見えます。
同じ学習ドメイン ld2 内の IGMP スピーカー(ホストとルーター)では、リンクされた P-A と S-A は 1 つのスイッチのように見えます。
学習ドメイン ld3 にはマルチシャーシ リンクがないため、学習ドメイン ld3 の IGMP スピーカー(ホストおよびルーター)では、P-A と S-A は 1 つのスイッチには見えません。
この説明では、シャーシ間リンク ICL1 が学習ドメイン ld1 に対応し、シャーシ間リンク ICL2 が学習ドメイン ld2 に対応すると仮定します。
IRB への情報の受け渡しを除き、制御パケットフローがサポートされています。
認定学習によるデータ転送
ここでは、1 つのラーニング ドメイン(LD)である ld1 を想定し、さらにルーター P-A のインターフェイス I1 がラーニング ドメインの PIM-DR に接続され、コアの送信元からトラフィックを取得することを前提としています。
I2、I4(ld1に所属)などのシングルホームリンクでルーターS-A(非DR)に接続されたホストにトラフィックを配信する場合、ICL1に依存します。インターフェイス I1 のルーター P-A に到達するトラフィックは、シャーシ間リンク ICL1 を介してルーター S-A に送信され、s,g への関心を報告したリンク、またはラーニング ドメイン ld1 のルーターに面したリンクに配信されます。
ルーター P-A のインターフェイス ae0 レッグがダウンすると、マルチシャーシ リンクに接続されたホストは、シャーシ間リンク ICL1 を使用してインターフェイス I1 からトラフィックを受信します。ルーターS-Aでは、シャーシ間リンクICL1で受信されたトラフィックは、ルーターP-Aの対応する集合型イーサネットがダウンしている発信インターフェイスリスト内のマルチシャーシリンクに送信されます。
さらに、ルーター S-A のインターフェイス I9 は、s,g に関心を持つ学習ドメイン ld3 に属し、ルーター P-A の学習ドメイン ld3 のインターフェイス I10 は s,g のトラフィックを受信していると仮定されます。インターフェイス I9 は、マルチシャーシ リンク(a-a モード)がないため、学習ドメイン ld3 にシャーシ間リンクがないため、このトポロジーではデータを受信しません。
シングルホームインターフェイスの静的グループ
マルチシャーシリンクの場合、静的グループ設定は両方のレッグに存在する必要があり、他のシャーシとの同期は必要ありません。
シャーシ間のシングルホーム インターフェイス上のスタティック グループの同期はサポートされていません。ただし、デフォルトの発信インターフェイスリストに論理インターフェイスを追加することで、静的設定内のインターフェイスへのトラフィック配信がサポートされます。
マルチシャーシリンクとしてのルーターに接続するインターフェイス
IGMPクエリーは、マルチシャーシリンクのどちらのレッグにも到達できますが、どちらのピアにおいても、マルチシャーシリンクはルーターに接続するものと見なす必要があります。
レポートは、マルチシャーシ リンクから 1 回だけ、つまり 1 つのレッグからのみ出力する必要があります。
IRB での IGMP スヌーピングに対して、以下の MC-LAG サポートが提供されます。
非プロキシ スヌーピング
論理インターフェイスは、デフォルトルートを含むすべてのルートの発信インターフェイスである必要があります
純粋なレイヤー2スイッチでのIGMPスヌーピング
適格な学習を行うブリッジ ドメインでの IGMP スヌーピング
ルーターに接続するインターフェイスMCリンク
次の機能 not サポートされています。
アクティブ/アクティブのプロキシ モード
VPLS インスタンスの MC-LAG サポート
マルチシャーシリンクとしてのトランクポート
必要に応じて、発信インターフェイスに論理インターフェイスを追加します。
ただし、論理インターフェイスは、常にルーターに接続するインターフェイスとして発信インターフェイスリストに追加されます。
参照
FCoE トランジット スイッチの MC-LAG について
MC-LAG を使用して、FCoE(FCoE チャネル経由)トラフィックの冗長アグリゲーション レイヤーを提供します。
このトピックでは、以下について説明します。
サポートされるMC-LAGトポロジ
MC-LAG 全体で FCoE トラフィックのロスレス転送をサポートするには、MC-LAG ポート メンバーがある両方のスイッチで適切な サービス クラス (CoS)を設定する必要があります。MC-LAGは転送クラスとIEEE 802.1pの優先順位情報を伝送しないため、CoSの設定は両方のMC-LAGスイッチで同じである必要があります。
FCoE ホストに直接接続されておらず、パススルー トランジット スイッチとして機能するスイッチは、 逆 U ネットワーク トポロジーの FCoE トラフィックの MC-LAG をサポートします。 図3 は、QFX3500スイッチを使用した逆Uトポロジーを示しています。

スタンドアロン スイッチは MC-LAG をサポートしています。QFabric システム ノード デバイスは MC-LAG をサポートしていません。バーチャルシャーシおよび混合モードのバーチャルシャーシファブリック(VCF)構成は、FCoEをサポートしていません。純粋な QFX5100 VCF(QFX5100 スイッチのみで構成)のみが FCoE をサポートします。
FCoE-FC ゲートウェイ設定(仮想 FCoE-FC ゲートウェイ ファブリック)の一部であるポートは、MC-LAG をサポートしていません。MC-LAG のメンバーであるポートは、パススルー トランジット スイッチ ポートとして機能します。
FCoE トラフィックに使用する MC-LAG には、以下のルールとガイドラインが適用されます。ルールとガイドラインは、FCoE トラフィックに必要な適切な処理とロスレス トランスポート特性を確保するためのものです。
MC-LAG を形成する 2 つのスイッチ(スイッチ S1 および S2)は、FCoE-FC ゲートウェイ ファブリックの一部であるポートを使用できません。MC-LAG スイッチ ポートは、パススルー トランジット スイッチ ポート(FCoE ホストに直接接続されていない中間トランジット スイッチの一部として使用)である必要があります。
MC-LAG スイッチ S1 および S2 を FCoE ホストに直接接続することはできません。
FCoE ホストのアクセス デバイスとして機能する 2 つのスイッチ(FCoE トランジット スイッチ TS1 および TS2)は、標準 LAG を使用して MC-LAG スイッチ S1 および S2 に接続します。FCoE トランジット スイッチ TS1 および TS2 は、スタンドアロン スイッチにすることも、QFabric システムのノード デバイスにすることもできます。
トランジット スイッチ TS1 および TS2 は、FCoE ホストと、MC-LAG スイッチ S1 および S2 への標準 LAG にトランジット スイッチ ポートを使用する必要があります。
トランジット スイッチ TS1 および TS2 の FCoE VLAN で FIP スヌーピングを有効にします。FCoE ホストが FC SAN 内のターゲットにアクセスする必要があるか(VN2VF_Port FIP スヌーピング)、イーサネット ネットワーク内のターゲットにアクセスする必要があるか(VN2VN_Port FIP スヌーピング)に応じて、VN_Port から VF_Port(VN2VF_Port)FIP スヌーピングまたはVN_PortからVN_Port(VN2VN_Port)FIP スヌーピングのいずれかを設定できます。
FIPスヌーピングはアクセスエッジで実行する必要があり、MC-LAGスイッチではサポートされていません。MC-LAG スイッチ S1 および S2 では FIP スヌーピングを有効にしないでください。(スイッチS1およびS2をスイッチTS1およびTS2に接続するMC-LAGポート、またはスイッチS1をS2に接続するLAGポートでは、FIPスヌーピングを有効にしないでください)。
手記:ジュニパーネットワークスQFX10000アグリゲーションスイッチはFIPスヌーピングをサポートしていないため、このトポロジーではFIPスヌーピングアクセススイッチ(トランジットスイッチTS1およびTS2)として使用できません。
CoS 設定は、MC-LAG スイッチで一貫している必要があります。MC-LAGは転送クラスや優先度情報を伝送しないため、ロスレストランスポートをサポートするには、各MC-LAGスイッチに同じCoS設定が必要です。(各MC-LAGスイッチでは、各転送クラスの名前、エグレスキュー、CoSプロビジョニングが同じで、優先度ベースのフロー制御(PFC)設定が同じである必要があります)。
トランジット スイッチ(サーバー アクセス)
FCoE トランジット スイッチ TS1 および TS2 の役割は、FCoE ホストをマルチホーム 方式で MC-LAG スイッチに接続することであり、トランジット スイッチ TS1 および TS2 は FCoE ホストのアクセス スイッチとして機能します。(FCoE ホストはトランジット スイッチ TS1 および TS2 に直接接続されます)。
トランジット スイッチの設定は、VN2VF_Port FIP スヌーピングと FIP スヌーピングVN2VN_Portどちらを実行するか、およびトランジット スイッチに FCoE-FC ゲートウェイ仮想ファブリックの一部としてポートが設定されているかどうかによって異なります。QFX3500 スイッチが FCoE-FC ゲートウェイ仮想ファブリックで使用するポートは、MC-LAG スイッチへのトランジット スイッチの LAG 接続に含めることはできません。(ポートは、トランジット スイッチと FCoE-FC ゲートウェイの両方に属することはできません。動作モードごとに異なるポートを使用する必要があります)。
MC-LAGスイッチ(FCoEアグリゲーション)
MC-LAG スイッチ S1 および S2 の役割は、FCoE トランジット スイッチ間に冗長化された負荷分散接続を提供することです。MC-LAGスイッチS1およびS2は、アグリゲーションスイッチとして機能します。FCoE ホストは MC-LAG スイッチに直接接続されません。
MC-LAG スイッチの構成は、FCoE トランジット スイッチ TS1 および TS2 が実行する FIP スヌーピングのタイプに関係なく同じです。
FIP スヌーピングと FCoE の信頼済みポート
セキュアなアクセスを維持するには、FCoE ホストに直接接続されているトランジット スイッチのアクセス ポートで、VN2VF_Port FIP スヌーピングまたは VN2VN_Port FIP スヌーピングを有効にします。不正アクセスを防止するために、ネットワークのアクセス エッジで FIP スヌーピングを実行する必要があります。たとえば、 図 3 では、FCoE ホストに接続されたアクセス ポートを含むトランジット スイッチ TS1 および TS2 上の FCoE VLAN で FIP スヌーピングを有効にします。
MC-LAG の作成に使用されるスイッチでは、FIP スヌーピングを有効にしないでください。たとえば、 図 3 では、スイッチ S1 および S2 の FCoE VLAN で FIP スヌーピングを有効にしません。
スイッチ間のリンクを FCoE の信頼できるポートとして設定すると、FIP スヌーピングのオーバーヘッドが削減され、システムがアクセス エッジでのみ FIP スヌーピングを実行するようになります。サンプル トポロジーでは、MC-LAG スイッチに接続されたトランジット スイッチ TS1 および TS2 の LAG ポートを FCoE の信頼済みポートとして設定し、スイッチ TS1 および TS2 に接続されたスイッチ S1 および S2 の MC-LAG ポートを FCoE の信頼済みポートとして設定し、スイッチ S1 から S2 に接続する LAG 内のポートを FCoE の信頼済みポートとして設定します。
CoS およびデータ センター ブリッジング(DCB)
MC-LAGリンクは、転送クラスや優先度情報を伝送しません。ロスレストランスポートをサポートするには、各MC-LAGスイッチまたは各MC-LAGインターフェイスで、以下のCoSプロパティの設定を同じにする必要があります。
FCoE 転送クラス名—たとえば、FCoE トラフィックの転送クラスは、両方の MC-LAG スイッチでデフォルトの
fcoe
転送クラスを使用できます。FCoE 出力キュー—たとえば、
fcoe
転送クラスを両方の MC-LAG スイッチのキュー 3 にマッピングできます(キュー 3 はfcoe
転送クラスのデフォルト マッピングです)。分類子:FCoE トラフィックの転送クラスは、両方の MC-LAG スイッチ上の MC-LAG の各メンバー インターフェイスで、同じ IEEE 802.1p コード ポイントにマッピングされる必要があります。たとえば、FCoE 転送クラス
fcoe
を IEEE 802.1p コード ポイント011
にマッピングできます(コード ポイント011
はfcoe
転送クラスのデフォルト マッピングです)。プライオリティベースのフロー制御 (PFC):PFC は、各 MC-LAG スイッチの FCoE コード ポイントで有効にし、輻輳通知プロファイルを使用して各 MC-LAG インターフェイスに適用する必要があります。
また、ロスレス トランスポートに十分なスケジューリング リソース(帯域幅、優先度)を提供するために、MC-LAG インターフェイスで拡張伝送選択(ETS)を設定する必要があります。ETS の設定は、予想される FCoE トラフィックのロスレス トランスポートをサポートするのに十分なリソースがスケジュールされている限り、MC-LAG スイッチごとに異なっていてもかまいません。
各MC-LAGメンバーインターフェイスでは、LLDP(Link Layer Discovery Protocol)およびDCBX(Data Center Bridging Capability Exchange Protocol)を有効にする必要があります(LLDPとDCBXは、すべてのインターフェイスでデフォルトで有効になっています)。
他のすべての FCoE 設定と同様に、FCoE トラフィックには FCoE トラフィックのみを伝送する専用 VLAN が必要であり、FCoE VLAN では IGMP スヌーピングを無効にする必要があります。
Junos Fusion EnterpriseおよびMC-LAGとのEVPN-MPLS相互作用について
Junos OS リリース 17.4R1 以降では、イーサネット VPN(EVPN)を使用して、Junos Fusion Enterprise またはマルチシャーシ リンク アグリゲーション グループ(MC-LAG)ネットワークを MPLS ネットワークからデータ センターまたはキャンパス ネットワークに拡張できます。この機能の導入により、分散したキャンパスやデータセンターのサイトを相互接続して、単一のレイヤー2仮想ブリッジを形成できるようになりました。
図4 は、サテライトデバイスがマルチホームされているアグリゲーションデバイス(PE2およびPE3)として機能する2台のEX9200スイッチを備えたJunos Fusion Enterpriseトポロジーを示しています。2台のアグリゲーションデバイスは、ICL(シャーシ間リンク)とMC-LAGのICCP(シャーシ間制御プロトコル)プロトコルを使用して、Junos Fusion Enterpriseトポロジーを接続および維持します。EVPN-MPLS環境のPE1は、MC-LAGを使用したJunos Fusion EnterpriseのPE2およびPE3と相互運用されます。

図 5 は、カスタマー エッジ(CE)デバイス CE1 が PE2 および PE3 にマルチホームされている MC-LAG トポロジーを示しています。PE2 と PE3 は、ICL と MC-LAG の ICCP プロトコルを使用して、トポロジーを接続および維持します。EVPN-MPLS環境のPE1は、MC-LAG環境のPE2およびPE3と相互運用します。

このトピックでは、 図 4 と 図 5 を参考にして、さまざまなシナリオとポイントを示します。
図4と図5に示すユースケースでは、アクティブ/アクティブモードでのEVPNマルチホーミングと、PE2およびPE3でのMC-LAGの両方を設定する必要があります。マルチホーミング、アクティブ/アクティブ、および MC-LAG を備えた EVPN には、トラフィック、特にブロードキャスト、不明なユニキャスト、マルチキャスト(BUM)トラフィックを処理するための独自の転送ロジックがあります。マルチホーミング、アクティブ-アクティブ、および MC-LAG を使用する EVPN の転送ロジックが互いに矛盾し、問題を引き起こすことがあります。このトピックでは、問題と、EVPN-MPLS相互作用機能がこれらの問題を解決する方法について説明します。
このトピックで説明するEVPN-MPLSインターワーキング固有の実装を除き、EVPN-MPLS、Junos Fusion Enterprise、MC-LAGは、スタンドアロン機能と同じ機能と機能を提供します。
- Junos Fusion EnterpriseおよびMC-LAGでEVPN-MPLSを使用するメリット
- BUMトラフィック処理
- スプリット ホライズン
- MAC ラーニング
- Junos Fusion Enterprise でのカスケード ポートとアップリンク ポート間のダウン リンクの処理
- レイヤー 3 ゲートウェイのサポート
Junos Fusion EnterpriseおよびMC-LAGでEVPN-MPLSを使用するメリット
EVPN-MPLS と Junos Fusion Enterprise および MC-LAG を使用して、分散したキャンパスやデータ センター サイトを相互接続し、単一のレイヤー 2 仮想ブリッジを形成します。
BUMトラフィック処理
図 4 と 図 5 に示すユースケースでは、PE1、PE2、PE3 は EVPN ピアで、PE2 と PE3 は MC-LAG ピアです。両方のピア セットが制御情報を交換してトラフィックを相互に転送するため、問題が発生します。表2は、EVPN-MPLS相互作用機能を実装する際に発生する問題と、ジュニパーネットワークスが解決する方法の概要を示しています。
BUM トラフィック方向 |
Junos Fusion EnterpriseおよびMC-LAGロジックとのEVPNインターフェイス |
発行 |
ジュニパーネットワークスの実装アプローチ |
---|---|---|---|
ノースバウンド(PE2 は、ローカルに接続されたシングルホームまたはデュアルホーム インターフェイスから BUM パケットを受信します)。 |
PE2 は、BUM パケットを以下にフラッディングします。
|
PE2とPE3の間には、MC-LAG ICLとEVPN-MPLSパスの2つのBUM転送パスがあります。転送パスが複数あると、パケットが重複し、ループが発生します。 |
|
サウスバウンド(PE1 は BUM パケットを PE2 と PE3 に転送します)。 |
PE2 と PE3 はどちらも BUM パケットのコピーを受信し、ICL を含むすべてのローカル インターフェイスからパケットをフラッディングします。 |
PE2 と PE3 はどちらも BUM パケットを ICL から転送するため、パケットの重複とループが発生します。 |
スプリット ホライズン
図 4 と図 5 に示すユースケースでは、スプリット ホライズンにより、BUM パケットの複数のコピーが CE デバイス(サテライト デバイス)に転送されるのを防止できます。ただし、EVPN-MPLSとMC-LAGのスプリットホライズン実装は互いに矛盾しているため、問題が発生します。表3は、この問題と、ジュニパーネットワークスがEVPN-MPLSインターワーキング機能を実装する際にどのように解決するかを示しています。
BUM トラフィック方向 |
Junos Fusion EnterpriseおよびMC-LAGロジックとのEVPNインターフェイス |
発行 |
ジュニパーネットワークスの実装アプローチ |
---|---|---|---|
ノースバウンド(PE2 はローカルに接続されたデュアルホーム インターフェイスから BUM パケットを受信します)。 |
|
EVPN-MPLS と MC-LAG の転送ロジックは互いに矛盾しているため、BUM トラフィックが ES に転送されない可能性があります。 |
ローカル バイアスをサポートすることで、ローカルでスイッチングされたトラフィックのポートの DF および非 DF ステータスを無視します。 |
サウスバウンド(PE1 は BUM パケットを PE2 と PE3 に転送します)。 |
PE1 から受信したトラフィックは、マルチホーム ES の EVPN DF および非 DF 転送ルールに従います。 |
何一つ。 |
該当なし。 |
MAC ラーニング
EVPN と MC-LAG は、MAC アドレスの学習に同じ方法を使用します。つまり、PE デバイスはローカル インターフェイスから MAC アドレスを学習し、そのアドレスをピアに同期させます。ただし、EVPNとMC-LAGの両方がアドレスを同期していることを考えると、問題が発生します。
表4 では、この問題と、EVPN-MPLSインターワーキングの実装によってどのように問題を回避するかについて説明します。 図4 と 図5 に示すユースケースは、この問題を示しています。どちらのユースケースでも、PE1、PE2、およびPE3はEVPNピアであり、PE2およびPE3はMC-LAGピアです。
MAC同期ユースケース |
Junos Fusion EnterpriseおよびMC-LAGロジックとのEVPNインターフェイス |
発行 |
ジュニパーネットワークスの実装アプローチ |
---|---|---|---|
PE2およびPE3のシングルホームまたはデュアルホームインターフェイスでローカルに学習されたMACアドレス。 |
|
PE2とPE3は、EVPNピアとMC-LAGピアの両方として機能するため、これらのデバイスには複数のMAC同期パスがあります。 |
|
PE1のシングルホームまたはデュアルホームインターフェイスでローカルに学習されたMACアドレス。 |
EVPNピア間では、EVPN BGPコントロールプレーンを使用してMACアドレスを同期します。 |
何一つ。 |
該当なし。 |
Junos Fusion Enterprise でのカスケード ポートとアップリンク ポート間のダウン リンクの処理
このセクションは、Junos Fusion EnterpriseとのEVPN-MPLS相互作用にのみ適用されます。
図 4 に示す Junos Fusion Enterprise では、アグリゲーション デバイス PE2 が PE1 から BUM パケットを受信し、PE2 のカスケード ポートとサテライト デバイス SD1 の対応するアップリンク ポート間のリンクがダウンしていると仮定します。BUM パケットが MC-LAG と EVPN マルチホーミングのどちらで処理されても結果は同じで、パケットは ICL インターフェイスを介して PE3 に転送され、PE3 はデュアルホームの SD1 に転送されます。
マルチホーミング アクティブ-アクティブを備えた EVPN がデュアルホーム SD1 でこの状況を処理する方法をさらに説明するために、DF インターフェイスが PE2 に存在し、ダウン リンクに関連付けられており、非 DF インターフェイスが PE3 に存在すると仮定します。通常、マルチホーミング アクティブ-アクティブ転送ロジックを使用するEVPNでは、非DFインターフェイスがパケットを破棄します。ただし、DFインターフェイスに関連付けられたダウンリンクにより、PE2はICLを介してBUMパケットをPE3に転送し、PE3の非DFインターフェイスはパケットをSD1に転送します。
レイヤー 3 ゲートウェイのサポート
EVPN-MPLS相互作用機能は、拡張ブリッジドメインとVLANに対して、以下のレイヤー3ゲートウェイ機能をサポートします。
拡張ブリッジ ドメインまたは VLAN 間でトラフィックを転送するための IRB(統合型ルーティングおよびブリッジング)インターフェイス。
拡張ブリッジ ドメインまたは VLAN 内の物理(ベアメタル)サーバーから、別の拡張ブリッジ ドメインまたは VLAN 内の物理サーバーまたは仮想マシンにトラフィックを転送するためのデフォルト レイヤー 3 ゲートウェイ。
ループフリーMC-LAGネットワークの統計カウンタの増分値の理解
アクティブ/アクティブ ブリッジング ドメインの MC-LAG では、次のコマンドの出力に、MC-LAG カラー カウンターが継続的に増加していることが表示されます。MC-LAGのカラー属性またはカウンターがループ防止メカニズムとして機能するため、この統計数の増加は予期される動作です。
request pfe execute target fpc0 command "show jnh 0 exceptions" |grep color GOT: mc lag color DISC(88) 554712463 144488623417 request pfe execute target fpc0 command "show jnh 0 exceptions" |grep color GOT: mc lag color DISC(88) 554712747 144488664296
パケット転送エンジンに保存された例外テーブルには、次の出力例に示すように、カウンターのリストが含まれています。
request pfe execute target fpc0 command "show jnh 0 exceptions" SENT: Ukern command: show jnh 0 exceptions GOT: Reason Type Packets Bytes GOT: ================================================================== GOT: Ucode Internal GOT: ---------------------- GOT: mcast stack overflow DISC(33) 0 0 GOT: sample stack error DISC(35) 0 0 GOT: undefined nexthop opcode DISC(36) 0 0 GOT: internal ucode error DISC(37) 0 0 GOT: invalid fabric hdr version DISC(41) 0 0 GOT: GOT: PFE State Invalid GOT: ---------------------- GOT: sw error DISC(64) 803092438 59795128826 GOT: child ifl nonlocal to pfe DISC(85) 0 0 GOT: invalid fabric token DISC(75) 179 42346 GOT: unknown family DISC(73) 0 0 GOT: unknown vrf DISC(77) 0 0 GOT: iif down DISC(87) 0 0 GOT: unknown iif DISC( 1) GOT: invalid stream DISC(72) 0 0 GOT: egress pfe unspecified DISC(19) 10889 1536998 GOT: invalid L2 token DISC(86) 26 1224 GOT: mc lag color DISC(88) 554693648 144486028726<<<<<<<<<<<<<<<<<<<<<<<< GOT: dest interface non-local to pfe DISC(27) 10939253797 2078273071209 GOT: invalid inline-svcs state DISC(90) 0 0 GOT: nh id out of range DISC(93) 0 0 GOT: invalid encap DISC(96) 0 0 GOT: replication attempt on empty irb DISC(97) 0 0 GOT: invalid selector entry DISC(98) 0 0 GOT: GOT: GOT: Packet Exceptions GOT: ---------------------- GOT: bad ipv4 hdr checksum DISC( 2) GOT: non-IPv4 layer3 tunnel DISC( 4) 0 0 GOT: GRE unsupported flags DISC( 5) 0 0 GOT: tunnel pkt too short DISC( 6) 0 0 GOT: tunnel hdr too long DISC( 7) 0 0 GOT: bad IPv6 options pkt DISC( 9) 0 0 GOT: bad IP hdr DISC(11) 0 0 GOT: bad IP pkt len DISC(12) 0 0 GOT: L4 len too short DISC(13) GOT: invalid TCP fragment DISC(14) 0 0 GOT: mtu exceeded DISC(21) 0 0 GOT: frag needed but DF set DISC(22) 0 0 GOT: ttl expired PUNT( 1) 9 769 GOT: IP options PUNT( 2) 16 512 GOT: xlated l2pt PUNT(14) 0 0 GOT: control pkt punt via ucode PUNT( 4) 0 0 GOT: frame format error DISC( 0) GOT: tunnel hdr needs reassembly PUNT( 8) 0 0 GOT: GRE key mismatch DISC(76) 0 0 GOT: my-mac check failed DISC(28) GOT: frame relay type unsupported DISC(38) 0 0 GOT: IGMP snooping control packet PUNT(12) 0 0 GOT: bad CLNP hdr DISC(43) 0 0 GOT: bad CLNP hdr checksum DISC(44) 0 0 GOT: Tunnel keepalives PUNT(58) 0 0 GOT: GOT: GOT: Bridging GOT: ---------------------- GOT: lt unknown ucast DISC(84) 0 0 GOT: dmac miss DISC(15) 0 0 GOT: mac learn limit exceeded DISC(17) 0 0 GOT: static mac on unexpected iif DISC(18) 0 0 GOT: no local switching DISC(20) 0 0 GOT: bridge ucast split horizon DISC(26) 39458 13232394 GOT: mcast smac on bridged iif DISC(24) 1263 200152 GOT: bridge pkt punt PUNT( 7) 0 0 GOT: iif STP blocked DISC( 3) GOT: oif STP blocked DISC(31) GOT: vlan id out of oif's range DISC(32) GOT: mlp pkt PUNT(11) 15188054 440453569 GOT: input trunk vlan lookup failed DISC(91) 0 0 GOT: output trunk vlan lookup failed DISC(92) 0 0 GOT: LSI/VT vlan validation failed DISC(94) 0 0 GOT: GOT: GOT: Firewall GOT: ---------------------- GOT: mac firewall DISC(78) GOT: firewall discard DISC(67) 0 0 GOT: tcam miss DISC(16) 0 0 GOT: firewall reject PUNT(36) 155559 59137563 GOT: firewall send to host PUNT(54) 0 0 GOT: firewall send to host for NAT PUNT(59) 0 0 GOT: GOT: GOT: Routing GOT: ---------------------- GOT: discard route DISC(66) 1577352 82845749 GOT: dsc ifl discard route DISC(95) 0 0 GOT: hold route DISC(70) 21130 1073961 GOT: mcast rpf mismatch DISC( 8) 0 0 GOT: resolve route PUNT(33) 2858 154202 GOT: control pkt punt via nh PUNT(34) 51807272 5283911584 GOT: host route PUNT(32) 23473304 1370843994 GOT: ICMP redirect PUNT( 3) 0 0 GOT: mcast host copy PUNT( 6) 0 0 GOT: reject route PUNT(40) 1663 289278 GOT: link-layer-bcast-inet-check DISC(99) 0 0 GOT:
PE1とPE2の2台のプロバイダーエッジ(PE)ルーターが、それぞれ集合型イーサネットインターフェイス ae0
で接続されている導入例を考えてみましょう。MC-LAG(マルチシャーシ リンク アグリゲーション グループ)は、PE1 と PE2 の間で使用され、2 つのコントローラ間の論理 LAG インターフェイスを形成します。MC-LAG の PE1 と PE2 は、ICL-PL(シャーシ間制御リンク保護リンク)を使用して、ピア間で転送情報を複製します。
ICCP(Inter-Chassis Control Protocol)メッセージは、2台のPEデバイス間で送信されます。この例では、2 つのルータにまたがる MC-LAG を設定します。このMC-LAGは、2 つの集合型イーサネット インターフェイス、ICL-PL(シャーシ間制御リンク保護リンク)、ICL-PL のマルチシャーシ保護リンク、MC-LAG をホストするピアの ICCP で構成されます。
PE1ルーターは、別の集合型イーサネットインターフェイス ae3
を使用して、ホストH1とC1と呼ばれる別のMC-LAGホストに接続されています。MC-LAGは ae3
インターフェイスで有効になっています。
MC-LAG C1からPE1で受信したトラフィックは、ICL上でフラッディングしてPE2に到達することができます。パケットがPE2に到着すると、MC-LAG C1にフラッディングできます。シングルホーム ホストH1から送信されたトラフィックは、MC-LAG C1とPE1のICLにフラッディングできます。PE2 が ICL からこのようなトラフィックを受信すると、再び MC-LAG C1 にフラッディングできます。このようなループからMC-LAGトポロジーを保護するために、MC-LAGカラー機能が実装されています。この機能は、ICLリンクのイングレスに適用されます。したがって、PE2がPE1からパケットを受信すると、MC-LAGカラーをアクティブとして設定するか、オンにします。PE2がパケットをMC-LAGリンクに向けてフラッディングする必要がある場合、MC-LAGカラービットが設定されているか、またはオンとしてタグ付けされているかを確認します。カラーが設定されている場合、MC-LAG ae3
メンバーリンクインターフェイスのエグレスインターフェイスでパケットをドロップし、jnh例外の mc-lag color
カウンタがインクリメントされます。
このようなカウンタ値の増加動作は、アクティブ/アクティブ ブリッジング ドメインに設定された MC-LAG で、ARP ブロードキャストやマルチキャスト トラフィックなど、フラッディングが必要なあらゆる形式のトラフィックがネットワークを通過する場合に予想される状態です。
すべてのVLANは、ループを防ぐために一部のパケットをドロップすることがありますが、そのようなパケットのドロップはVLANに固有のものではない場合があります。
場合によっては、MXシリーズルーターの両方のMC LAGで、次のサンプル出力に示すように、カウンターがFPC0とFPC2で増加することに気付くかもしれませんが、FPC2では増加しません。
request pfe execute target fpc0 command "show jnh 0 exceptions" |grep color GOT: mc lag color DISC(88) 558477875 144977739683 request pfe execute target fpc1 command "show jnh 0 exceptions" |grep color GOT: mc lag color DISC(88) 0 0 request pfe execute target fpc2 command "show jnh 0 exceptions" |grep color GOT: mc lag color DISC(88) 518499257 119130527834
この動作は、16ポートの10ギガビットイーサネットMPC(16x10GE 3D MPC)を搭載したMXシリーズルーターでは、各MPCに対して4つのパケット転送エンジンがあるために発生します。FPC 0、1、2にある1つのパケット転送エンジンを調べると、FPC1のPFE1にはMC-LAGのメンバーであるインターフェイスがありません。MC-LAGに含まれない他の集合型イーサネットインターフェイスのインターフェイスが含まれている場合があります。したがって、正しいカウンター統計を取得するには、 request pfe execute target fpc0 command "show jnh X exceptions" |grep color
コマンド(X は 0、1、2、または 3)を入力して、他のパケット転送エンジンを調べる必要があります。
dest interface non-local to pfe
という名前のカウンターが増加している場合、集合型イーサネットインターフェイスが複数のFPCに分割されている場合、これは望ましい動作です。ae5
インターフェイスに以下のメンバーリンクが含まれる例を考えてみましょう。 xe-0/1/0
オン(FPC0)とxe-1/1/0
(FPC1) ハッシュアルゴリズムに基づいて、トラフィックはこれら2つのリンク間で分割される必要があります。ハッシュ アルゴリズムはイングレス FPC に適用され、FPC が転送される必要がある各パケット(FPC0 または FPC1)をマークする操作を実行します。その後、パケットがファブリックに送信されます。ファブリックから、すべてのトラフィックがFPC 0とFPC 1の両方に送信されます。FPC0 では、マイクロカーネルがパケットを分析し、パケットをローカル インターフェイスで転送する必要があるか(PFE にローカル)、またはこのパケットがすでに FPC1 を介して転送されているか(PFE にローカルではない)を判断します。パケットがすでに転送されている場合、パケットは破棄され、non-local to pfe
カウンターがインクリメントされます。
拡張コンバージェンス
MXシリーズルーターのJunos OS リリース14.2R3以降、拡張コンバージェンスにより、マルチシャーシ集約型イーサネット(MC-AE)リンクがダウンしたり、ブリッジドメインまたはVLANで起動した場合のレイヤー2およびレイヤー3コンバージェンス時間が改善されます。Junos OS リリース 18.1R1以降、vmembersの数は128kに増加し、 enhanced-convergence
ステートメントを有効にした場合のARPおよびNDエントリーの数は96kに増加しました。Junos OS リリース 19.1R1以降、 enhanced-convergence
および arp-enhanced-scale
ステートメントを有効にした場合のARPおよびNDエントリーの数は256,000に増加しました。拡張コンバージェンスにより、MC-AE(マルチシャーシ集合型イーサネット)リンク障害時や復旧時のレイヤー2およびレイヤー3コンバージェンス時間が改善します
拡張コンバージェンスが有効な場合、MC-AE インターフェイスを介して学習された MAC アドレス、ARP、または ND エントリーは、MC-AE リンクをプライマリ ネクストホップとして、ICL をバックアップ ネクストホップとして、転送テーブルでプログラムされます。この機能拡張により、MC-AE のリンク障害時または復元時に、転送テーブルのネクストホップ情報のみが更新され、MAC アドレス、ARP、または ND エントリのフラッシュと再学習がなくなります。このプロセスでは、MC-AE リンクの障害時や復旧時のトラフィック コンバージェンスが改善されます。これは、コンバージェンスでは転送プレーンでのネクストホップ修復のみが行われ、トラフィックが MC-AE リンクから ICL に高速に再ルーティングされるためです。
拡張コンバージェンスが有効になっている MC-AE インターフェイス上で IRB インターフェイスを設定した場合は、IRB インターフェイスでも拡張コンバージェンスを設定する必要があります。拡張コンバージェンスは、レイヤ 2 インターフェイスとレイヤ 3 インターフェイスの両方で有効にする必要があります。
IPv6近隣探索プロトコル
近隣検索プロトコル(NDP)は、同じリンク上のノードがネイバーにその存在をアドバタイズし、ネイバーの存在について学習できるようにする IPv6 プロトコルです。NDP は、ICMPv6(Internet Control Message Protocol version 6)の上に構築されています。これは、IPv4プロトコル(RDISC(ルーター検出)、ARP(アドレス解決プロトコル)、ICMPv4リダイレクトに代わるものです。
NDP は、スイッチ上のマルチシャーシ リンク アグリゲーション グループ(MC-LAG)のアクティブ/アクティブ構成で使用できます。
MC-LAG の NDP は、次のメッセージ タイプを使用します。
-
ネイバー要請(NS):アドレス解決およびネイバーの到達可能性のテストに使用されるメッセージ。
ホストは、新しいアドレス宛てにネイバー要請メッセージを送信することで、そのアドレスが一意であることを確認できます。ホストが応答でネイバーアドバタイズメントを受信した場合、アドレスは重複しています。
-
ネイバーアドバタイズメント(NA):アドレス解決とネイバーの到達可能性のテストに使用されるメッセージ。ネイバーアドバタイズは、ネイバー要請メッセージに応答して送信されます。
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer を使用します。
enhanced-convergence
および
arp-enhanced-scale
ステートメントを有効にした場合のARPおよびNDエントリーの数は256,000に増加しました。
enhanced-convergence
ステートメントを有効にした場合、vmembersの数は128kに増加し、ARPおよびNDエントリーの数は96kに増加しました。