次世代サービスのための集約されたマルチサービスインターフェイスの理解

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

Junos OSでは、複数のサービスインターフェイスを組み合わせて、単一のインターフェイスとして機能できるサービスインターフェイスのバンドルを作成できます。このようなインターフェイスのバンドルは、 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ごとです。例えば、session-limit は、集約レベルではなく、メンバーごとに適用されます。

手記：

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

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

手記：

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

手記：

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

AMSインターフェイスのメンバーインターフェイスを介したトラフィック分散は、ラウンドロビン方式またはハッシュベースのいずれかで発生します。次のハッシュ キー値を設定して、トラフィック分散を調整できます。 source-ip、 destination-ip 、および protocol。トラフィックの対称性を必要とするサービスでは、対称ハッシュを構成する必要があります。対称ハッシュ構成により、順方向と逆方向の両方のトラフィックが同じメンバー インターフェイスを介してルーティングされます。

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

ネクストホップ サービスでは、フォワード トラフィックでは、内部インターフェイスのイングレス キーがトラフィックのロード バランシングを行い、リバース トラフィックでは、外部インターフェイスのイングレス キーがトラフィックのロード バランシングを行うか、メンバーごとのネクストホップがリバース トラフィックをステアリングします。インターフェイススタイルのサービスでは、イングレスキーがトラフィックのロードバランシングを行い、エグレスキーがトラフィックのロードバランシング、またはメンバーごとのネクストホップがリバーストラフィックをステアリングします。順方向トラフィックはサービス セットの内側から入るトラフィックで、リバース トラフィックはサービス セットの外側から入るトラフィックです。フォワードキーは、トラフィックのフォワード方向に使用されるハッシュキーであり、リバースキーは、トラフィックの逆方向に使用されるハッシュキーです(インターフェイスサービスまたはネクストホップサービススタイルのどちらに関連するかによって異なります)。

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

• FOR-KEY:SIP、REV-KEY:ディップ

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

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

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

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

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

静的 NAT を基本 NAT44 または宛先 NAT44 として構成し、ステートフル ファイアウォールが構成されているかどうかにかかわらず、トラフィックの順方向で NAT 処理を行う必要がある場合は、ハッシュ キーを次のように構成します。

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

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

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

• FOR-KEY:SIP、REV-KEY:ディップ

• FOR-KEY: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 inet と family inet6 が設定されている場合、インターフェイス スタイルではサービス セット レベルで、ネクストホップ スタイルでは IFL レベルでhash-keysが設定されます。

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

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

理想的な環境で分散されるフローの数は、N 番目のメンバーがアップまたはダウンしたときの最良のシナリオでは 1/N にすることができます。しかし、この前提では、ハッシュ鍵が実際のトラフィックまたは動的なトラフィックのロードバランシングを行うことが考慮されています。たとえば、メンバー A が 1 つのフローのみを提供し、メンバー B が 10 個のフローを提供する実際の展開について考えてみます。メンバー B がダウンした場合、中断されるフローの数は 10/11 です。NAT プール分割動作は、リハッシュ最小化機能の利点を活用するように設計されています。NAT プールの分割は、動的 NAT シナリオ(動的 NAT、NAT64、NAPT44)で実行されます。

元のフローと再配布されたフローが次のように定義されているとします。

• Member-original-flows—すべてのメンバーがアップしているときにメンバーにマッピングされたトラフィック。

• Member-redistributed-flows—他のメンバーに障害が発生した場合に、メンバーにマッピングされる追加のトラフィック。これらのトラフィックフローは、メンバーインターフェイスが立ち上がったり下がったりしたときに、バランスを取り戻す必要があるかもしれません。

メンバー インターフェイスの元および再配布されたフローの前述の定義では、次の観察が適用されます。

• メンバーの member-original-flows は、そのメンバーが稼働している限りそのまま残ります。このようなフローは、他のメンバーがアップ状態とダウン状態の間を移動しても影響を受けません。

• メンバーのメンバー再配布フローは、他のメンバーがアップまたはダウンすると変化する可能性があります。このフローの変更は、これらの追加フローをすべてのアクティブ メンバー間で再バランスする必要があるために発生します。そのため、member-redistributed-flow は、他のメンバーのダウンまたはアップによって大きく変化します。メンバーがダウンすると、アクティブメンバーのフローは維持され、メンバーがアップすると、アクティブメンバーのフローは効果的に維持されないように見えるかもしれませんが、この動作は、アクティブメンバー間のトラフィックの静的またはハッシュベースのリバランスによるものにすぎません。

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

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

複数のサービスインターフェイスが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)では、1つのバックアップインターフェイスがグループ内の他のすべてのメンバーインターフェイスをサポートします。メンバーインターフェイスのいずれかに障害が発生した場合、バックアップインターフェイスが引き継ぎます。このステートレス設定では、バックアップ インターフェースと他のメンバー インターフェース間でデータが同期されません。

AMSに member-failure-options と high-availability-options の両方が設定されている場合、 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 ステートメントを使用します。 load-balancing-options ステートメントは、ウォームスタンバイ AMS インターフェイスでは使用できません。

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

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