次世代サービス向けの集約型マルチサービス インターフェイスについて

集合型マルチサービス インターフェイス

Junos OS では、複数のサービス インターフェイスを組み合わせて、1 つのインターフェイスとして機能するサービス インターフェイスのバンドルを作成できます。このようなインターフェイスのバンドルは、 aggregated multiservices interface (AMS)と呼ばれ、設定ではamsN と表され、 N AMSインターフェイス(例えばams0)を識別する一意の番号です。Junos OSリリース19.3R2以降、AMSインターフェイスは次世代サービスMX-SPC3サービスカードでサポートされています。

AMS 設定により、拡張性が向上し、パフォーマンスが向上し、フェイルオーバーとロードバランシングのオプションが向上します。

AMS設定では、AMSバンドルをサービスセットに関連付けることで、サービスセットが複数のサービスPICをサポートできます。次世代サービスの場合、MX-SPC3 サービス カードは最大 2 個の PIC をサポートし、シャーシには最大 8 枚の MX-SPC3 サービス カードを搭載できます。これにより、次世代サービスAMSバンドルをメンバーインターフェイスとして最大16個のサービスPICを使用でき、サービスをメンバーインターフェイス間で分散することができます。

メンバー インターフェイスは、構成内で mams として識別されます。AMS 設定をサポートするルーターのシャーシ型プロセスでは、ルーター上のすべてのマルチサービス インターフェイスに mams エントリが作成されます。

ams インターフェイス レベルでサービス オプションを設定する場合、オプションは ams インターフェイスのすべてのメンバー インターフェイス(mams)に適用されます。

オプションは、amsインターフェイスのメンバーインターフェイスに対応するサービスインターフェイスで設定されたサービスセットにも適用されます。すべての設定はPIC単位です。例えば、セッション制限は、集約レベルではなく、メンバーごとに適用されます。

メモ：

ams(集約)レベルとメンバーインターフェイスレベルの両方でサービスオプションを設定することはできません。サービスオプションが で設定されている場合、 上の vms-x/y/zサービスセットにも適用されます mams-x/y/z。

サービス オプション設定をすべてのメンバーに一貫して適用する場合は、ams インターフェイス レベルでサービス オプションを構成します。個々のメンバーに異なる設定が必要な場合は、メンバーインターフェイスレベルでサービスオプションを構成します。

メモ：

NAT64には、トラフィックのメンバー単位のドロップとメンバー単位のネクストホップ構成が必要です。NAPT44 では、このメンバー単位の指定により任意のハッシュ キーを使用でき、動的 NAT 操作を実行するためのより優れた負荷分散オプションが提供されます。NAT64、NAPT44、および動的 NAT44 では、どのメンバーが動的 NAT アドレスを割り当てるかを決定することはできません。リバース フロー パケットがフォワード フロー パケットと同じメンバーに到着するように、プールアドレスベースのルートを使用してリバース フロー パケットを誘導します。

メモ：

AMS インターフェイスに割り当てられたサービス セットによって使用されている NAT プールを変更する場合、NAT プールの変更を有効にする前に、サービス セットを無効化してアクティブ化する必要があります。

AMSインターフェイスのメンバーインターフェイス上のトラフィック分散は、ラウンドロビン方式またはハッシュベースのいずれかで発生する可能性があります。トラフィックの分散を調整するために、以下のハッシュキー値を設定することができます。 source-ipdestination-ip protocolトラフィックの対称性を必要とするサービスでは、対称ハッシュを設定する必要があります。対称ハッシュ設定により、フォワードトラフィックとリバーストラフィックの両方が同じメンバーインターフェイスを介してルーティングされます。

サービスセットがNAT内部インターフェイスとして機能するギガビットイーサネットまたは10ギガビットイーサネットインターフェイス(インターフェイススタイルのサービスセット)に適用される場合、負荷分散に使用されるハッシュキーが、イングレスキーが宛先IPアドレスとして設定され、エグレスキーが送信元IPアドレスとして設定されるように設定される場合があります。送信元 IP アドレスは NAT 処理を受けているため、逆方向のトラフィックをハッシュすることはできません。そのため、ロード バランシングは同じ IP アドレスで発生せず、フォワード トラフィックとリバース トラフィックは同じ PIC にマッピングされません。ハッシュキーが逆の場合、ロードバランシングが正しく行われます。

ネクストホップサービスでは、転送トラフィックでは、内部インターフェイスのイングレスキーがトラフィックの負荷分散を行い、リバーストラフィックの場合は、外部インターフェイスのイングレスキーがトラフィックの負荷分散またはメンバー単位のネクストホップによってトラフィックを逆誘導します。インターフェイススタイルのサービスでは、イングレスキーが転送トラフィックの負荷分散を行い、エグレスキーは転送トラフィックまたはメンバー単位のネクストホップでトラフィックを負荷分散し、トラフィックを逆に誘導します。転送トラフィックとは、サービス セットの内側から入るトラフィックであり、リバース トラフィックはサービス セットの外側から入るトラフィックです。フォワードキーはトラフィックの前方方向に使用されるハッシュキーであり、リバースキーはトラフィックの逆方向に使用されるハッシュキーです(インターフェイスサービスまたはネクストホップサービススタイルに関連するかどうかによって異なります)。

ステートフルファイアウォールでは、ロードバランシングのために、以下のフォワードキーとリバースキーの組み合わせを設定できます。ハッシュキーに対して提示される以下の組み合わせでは、FOR-KEYはフォワードキーを指し、REV-KEYはリバースキーを示し、SIPは送信元IPアドレスを示し、DIPは宛先IPアドレスを示し、PROTOはIPなどのプロトコルを指します。

• 鍵用:SIP、REV-KEY:DIP

• 鍵用:SIP、PROTO REV-KEY:DIP、PROTO

• 鍵用:DIP、REV-KEY:SIP

• 鍵用:DIP、PROTO REV-KEY:SIP、PROTO

• 鍵用:SIP、DIP REV-KEY:SIP、DIP

• FOR-KEY:SIP、DIP、PROTO REV-KEY:SIP、DIP、PROTO

静的NATを基本的なNAT44またはディスティネーションNAT44として設定し、ステートフルファイアウォールを設定するかどうかを設定した場合、トラフィックの転送方向にNAT処理が必要な場合、ハッシュキーを次のように設定します。

• 鍵用:DIP、REV-KEY:SIP

• 鍵用:DIP、PROTO REV-KEY:SIP、PROTO

トラフィックの逆方向が NAT 処理を受ける必要がある場合は、次のようにハッシュ キーを設定します。

• 鍵用:SIP、REV-KEY:DIP

• 鍵用:SIP、PROTO REV-KEY:DIP、PROTO

動的NATが設定され、ステートフルファイアウォールが設定されているかどうかに関係なく、転送方向のトラフィックのみがNATを受けることができます。転送ハッシュキーは、SIP、DIP、プロトコルの任意の組み合わせが可能で、リバースハッシュキーは無視されます。

メモ：

Junos OS AMS設定は、IPv4およびIPv6トラフィックをサポートしています。

AMS インターフェイス上の IPv6 トラフィックの概要

IPv6 トラフィックに AMS インターフェイスを使用できます。AMSインターフェイスに対するIPv6サポートを設定するには、 階層レベルで ステートメントを[edit interfaces ams-interface-name unit 1]含family inet6めます。AMSインターフェイスサブユニットに と family inet6 が設定されている場合family inet、 hash-keys はインターフェイススタイルのサービスセットレベルで、ネクストホップスタイルのIFLレベルで設定されます。

AMSバンドルのメンバーインターフェイスに障害が発生した場合、障害が発生したメンバーを宛先とするトラフィックは、残りのアクティブメンバーに再分配されます。既存のアクティブメンバーを通過するトラフィック(フローまたはセッション)には影響はありません。M メンバーが現在アクティブな場合、トラフィック量が障害メンバーからアクティブ メンバーのままに移動するため、予想される結果はトラフィック(フロー/セッション)の約 1/M 分の 1 に過ぎません。障害が発生したメンバー インターフェイスがオンラインに戻ると、トラフィックのごく一部のみが新しいメンバーに再配布されます。N メンバーが現在アクティブな場合、予想される結果は、その量のトラフィックが新しい復元されたメンバーに移動するため、影響を受けるトラフィック(フロー/セッション)の約 1/(N+1)程度です。パケットハッシュが負荷分散に使用され、トラフィックには通常、IPアドレス(または負荷分散キーとして使用されるその他のフィールド)の典型的なランダムな組み合わせが含まれているため、1/Mと1/(N+1)の値は、フローがメンバー間で一様に分散していることを前提としています。

IPv4 トラフィックと同様に、IPv6 パケットの場合、AMS バンドルには 1 つのサービス PIC タイプのみのメンバーを含める必要があります。

理想的な環境で分散したフローの数は、N 番目のメンバーが上昇またはダウンした場合に最適なシナリオで 1/N にすることができます。ただし、この仮定では、ハッシュキーが実際のトラフィックまたは動的トラフィックの負荷分散を行うとみなします。例えば、メンバー A が 1 つのフローのみを提供し、メンバー B が 10 個のフローを提供しているのに対して、実際の導入を考えてみましょう。メンバーBがダウンした場合、中断されたフローの数は10/11になります。NAT プール分割動作は、リハッシュ最小化機能のメリットを活用するように設計されています。NAT プールの分割は、動的 NAT シナリオ(動的 NAT、NAT64、NAPT44)に対して実行されます。

元のフローと再分配されたフローが次のように定義されている場合:

• メンバー・オリジナル・フロー — すべてのメンバーが立ち上がっている時にメンバーにマッピングされたトラフィック。

• メンバー再分配フロー —他のメンバーに障害が発生した場合にメンバーにマッピングされた追加のトラフィック。メンバーインターフェイスが立ち上がってダウンした場合、これらのトラフィックフローは再調整が必要になる場合があります。

前述のメンバー インターフェイスの元のフローと再分配されたフローの定義では、以下のオブザベーションが適用されます。

• メンバーの元のフローは、そのメンバーが立ち上がっている限り、そのまま維持されます。他のメンバーがアップとダウンの状態の間を移動しても、このようなフローは影響を受けません。

• メンバーの再分配フローは、他のメンバーが上がったり下がったりしたときに変更できます。このフローの変更は、アクティブなすべてのメンバー間でこれらの追加のフローを再調整する必要があるために発生します。そのため、メンバー再分配フローは、ダウンまたはアップする他のメンバーによって大きく異なります。メンバーがダウンすると、アクティブメンバー上のフローが保持され、メンバーが立ち上がるとアクティブメンバー上のフローが効果的に保存されないように見えるかもしれませんが、この動作はアクティブなメンバー間のトラフィックの静的またはハッシュベースの再バランスが原因です。

リハッシュを最小限に抑える機能は、メンバー・インタフェースの状態における運用上の変更のみを処理します(メンバーオフラインやメンバーJunos OSのリセットなど)。設定の変更は処理されません。例えば、 階層レベルの [edit interfaces amsN load-balancing-options member-interface mams-a/b/0] メンバー・インターフェースの追加または削除、またはアクティベーションと非アクティベーションでは、メンバーPICがバウンスされる必要があります。AMSインターフェイスのIPv4サポートと同様に、2回のNATまたはヘアピンはサポートされていません。

メンバー障害オプションと高可用性設定

AMSバンドルの一部として複数のサービスインターフェイスが設定されているため、AMS設定ではフェイルオーバーと高可用性のサポートも提供します。メンバーインターフェイスの1つを、他のメンバーインターフェイスのいずれかがダウンした場合にアクティブになるバックアップインターフェイスとして設定するか、メンバーインターフェイスの1つがダウンしたときにそのインターフェイスに割り当てられたトラフィックがアクティブなインターフェイスで共有されるようにAMSを設定することができます。

member-failure-options 設定ステートメントを使用すると、メンバーインターフェイスに障害が発生した場合のトラフィック処理方法を設定できます。1つのオプションは、トラフィックを他のメンバーインターフェイス間で直ちに再分配することです。ただし、トラフィックの再分配はハッシュタグの再計算を伴い、すべてのメンバーインターフェイスのトラフィックに何らかの混乱を引き起こす可能性があります。

もう 1 つのオプションは、障害が発生したメンバー インターフェイスに割り当てられたすべてのトラフィックをドロップするように AMS を設定することです。これにより、AMSが障害が発生したインターフェイスがオンラインに戻るのを待ち、 rejoin-timeoutその後、AMSが他のメンバーインターフェイス間でトラフィックを再分配できる間隔を、オプションで設定することができます。構成された待機時間の前に障害が発生したメンバー インターフェイスがオンラインに戻った場合、オンラインに戻って操作を再開したインターフェイスを含むすべてのメンバー インターフェイスでトラフィックは影響を受けません。

また、オンラインに戻ったときに、障害が発生したインターフェイスの再参加を制御することもできます。設定に member-failure-options ステート メントをenable-rejoin含めなかった場合、障害が発生したインターフェイスはオンラインに戻ったときに AMS に再び参加できません。このような場合、運用モード コマンドを実行request interfaces revert interface-nameすることで、手動で AMS に再参加できます。

rejoin-timeoutおよび enable-rejoin ステートメントにより、メンバーインターフェイスがフラップする際のトラフィックの中断を最小限に抑えることができます。

メモ：

設定されていない場合 member-failure-options 、デフォルトの動作は、再参加タイムアウトが120秒のメンバートラフィックをドロップすることです。

この high-availability-options 設定により、メンバーインターフェイスの1つをバックアップインターフェイスとして指定できます。バックアップ インターフェイスがバックアップ インターフェイスである限り、バックアップ インターフェイスはルーティング操作に参加しません。メンバーインターフェイスに障害が発生した場合、バックアップインターフェイスは、障害が発生したインターフェイスに割り当てられたトラフィックを処理します。障害が発生したインターフェイスがオンラインに戻ると、それが新しいバックアップ インターフェイスになります。

多対 1 設定(N:1)では、単一のバックアップ インターフェイスがグループ内の他のすべてのメンバー インターフェイスをサポートします。メンバーインターフェイスのいずれかに障害が発生した場合、バックアップインターフェイスが引き継ぎます。このステートレス設定では、バックアップインターフェイスと他のメンバーインターフェイス間でデータは同期されません。

と のhigh-availability-options両方member-failure-optionsが AMS に設定されている場合、設定high-availability-optionsが設定よりもmember-failure-options優先されます。障害が発生したインターフェイスがオンラインに戻って新しいバックアップになる前に、2 つ目の障害が発生した場合、設定がmember-failure-options有効になります。

ウォーム スタンバイ冗長化

Junos OS リリース 19.3R2 以降、次世代サービスを実行している場合、MX-SPC3 では N:1 ウォーム スタンバイ オプションがサポートされています。各ウォーム スタンバイ AMS インターフェイスには、2 つのメンバーが含まれています。1つのメンバーは、プライマリインターフェイスと呼ばれる保護したいサービスインターフェイスであり、1つのメンバーはセカンダリ(バックアップ)インターフェイスです。プライマリインターフェイスはアクティブインターフェイスであり、プライマリインターフェイスに障害が発生しない限り、バックアップインターフェイスはトラフィックを処理しません。

AMS インターフェイスでウォーム スタンバイを設定するには、 ステートメントを redundancy-options 使用します。ウォーム スタンバイ AMS インターフェイスでは、 load-balancing-options ステートメントを使用できません。

プライマリ インターフェイスからセカンダリ インターフェイスに切り替えるには、 コマンドを request interface switchover amsN 発行します。

セカンダリ インターフェイスからプライマリ インターフェイスに戻すには、 コマンドを request interface revert amsN 発行します。