このページの目次
Junos Node Slicingについて
Junos Node Slicingの概要
Junos Node Slicingを使用すると、サービスプロバイダや大企業は、複数のルーティング機能を1つの物理デバイスに統合したネットワークインフラストラクチャを作成できます。これは、単一の物理インフラストラクチャで複数のサービスをホストし、それに伴う運用の複雑さを回避するのに役立ちます。また、デバイスでホストされている機能の運用上、機能上、および管理上の分離も維持します。
Junosノードスライシングを使用すると、1台の物理MXシリーズルーターに複数のパーティションを作成できます。これらのパーティションは、ゲストネットワーク機能 (GNF) と呼ばれます。各GNFは、専用のコントロールプレーン、データプレーン、管理プレーンを備えた独立したルーターとして動作します。これにより、1台の統合型MXシリーズルーターで複数のサービスを実行し、それらの間の運用の分離を維持できます。同じ物理デバイスを利用して、コントロールプレーンや転送プレーンを共有せず、同じシャーシ、スペース、電力のみを共有するパラレルパーティションを作成できます。
また、ファーストクラスのイーサネットインターフェイスとして動作する疑似インターフェイスである抽象化ファブリック(af)インターフェイスを使用することで、スイッチファブリックを介してGNF間でトラフィックを送信することもできます。抽象化されたファブリックインターフェイスにより、GNF間の制御、データ、および管理トラフィックのルーティングが容易になります。
Junosノードスライシングには、外部サーバーモデルとインシャーシモデルの2つのモデルがあります。外部サーバ モデルでは、GNF は業界標準の x86 サーバのペアでホストされます。シャーシ内モデルの場合、GNFはMXシリーズルーター自体のルーティングエンジンでホストされます。
Junosノードスライシングは、マルチバージョンのソフトウェア互換性をサポートしているため、GNFを個別にアップグレードできます。
Junos Node Slicingのメリット
Converged network—Junosノードスライシングにより、サービスプロバイダは、映像エッジと音声エッジなど、複数のネットワークサービスを1台の物理ルーターに統合し、それらの運用を分離しておくことができます。水平方向と垂直方向の両方の収束を実現できます。水平統合では同じレイヤーのルーター機能を1台のルーターに統合します。垂直統合では異なるレイヤーのルーター機能を1台のルーターに集約します。
Improved scalability:物理デバイスから仮想ルーティングパーティションに軸足を移すことで、ネットワークのプログラマビリティと拡張性が向上します。サービスプロバイダや企業は、追加のハードウェアを購入することなくインフラストラクチャの要件に対応できます。
Easy risk management- 複数のネットワーク機能を単一シャーシ上で統合することによって、すべての機能が独立して動作し、運用、機能、管理の分離によるメリットを享受できます。ブロードバンドネットワークゲートウェイ(BNG)のような物理システムをパーティション化して複数の独立した論理インスタンスにすると、障害は確実に分離されます。パーティションはコントロールプレーンや転送プレーンを共有せず、共有するのはシャーシ、スペース、電力のみです。つまり、1つのパーティションで障害が発生してもサービス停止にまでは被害が拡大しません。
Reduced network costs- Junosノードスライシングは、内部のスイッチファブリックを介してGNFの相互接続を可能にします。このインターフェイスでは、優れたイーサネットインターフェイスの動作を示す疑似インターフェイスである
af(抽象化ファブリック)インターフェイスを活用します。afインターフェイスを導入すると、企業はGNFの接続に物理インターフェイスを使用する必要がなくなり、大幅な削減が実現します。Reduced time-to-market for new services and capabilities- 各GNFは、異なるJunosソフトウェアバージョンで動作します。この利点により、企業は各GNFを独自のペースで進化させることができます。新しいサービスまたは機能を特定のGNFに展開する必要があり、新しいソフトウェアリリースが必要な場合、関連するGNFのみが更新を必要とします。Junos Node Slicingにより、俊敏性の向上により、サービスプロバイダと企業は柔軟性の高いEverything-as-a-Serviceビジネスモデルを導入し、絶えず変化する市場の状況に迅速に対応できるようになりました。
Junos Node Slicingのコンポーネント
Junosノードスライシングを使用すると、1台のMXシリーズルーターをパーティション分割して、複数の独立したルーターとして見せることができます。各パーティションには、仮想マシン(VM)として動作する独自のJunos OSコントロールプレーンと、専用のラインカードセットがあります。各パーティションは、ゲストネットワーク機能(GNF)と呼ばれます。
MXシリーズルーターは、ベースシステム(BSYS)として機能します。BSYS は、ライン カードやスイッチング ファブリックなど、ルーターのすべての物理コンポーネントを所有しています。BSYS はライン カードを GNF に割り当てます。
ジュニパーデバイスマネージャー(JDM)ソフトウェアがGNF VMをオーケストレーションします。JDM では、GNF VM は仮想ネットワーク機能(VNF)と呼ばれます。したがって、GNFはVNFとラインカードのセットで構成されます。
BSYSでの設定を通じて、シャーシのラインカードを異なるGNFに割り当てることができます。さらに、ラインカードのタイプによっては、ラインカード内のPFEのセットを異なるGNFに割り当てることもできます。詳細については、 サブラインカードの概要 を参照してください。
Junos Node Slicingは、2つのモデルをサポートしています。
外部サーバ モデル
シャーシ内モデル
外部サーバーモデルでは、JDM と VNF は外部の業界標準 x86 サーバーのペアでホストされます。
図 1 は、3 つの GNF と専用ライン カードが外部サーバーで実行されていることを示しています。
上のGNF
MX シリーズ ルーターを外部 x86 サーバーのペアに接続する方法については、 サーバーとルーター の接続を参照してください。
インシャーシモデルでは、すべてのコンポーネント(JDM、BSYS、およびGNF)は、MXシリーズルーターのルーティングエンジン内で実行されます。 図2を参照してください。
ベースシステム(BSYS)
Junosノードスライシングでは、MXシリーズルーターはベースシステム(BSYS)として機能します。BSYSは、すべてのラインカードとファブリックを含む、ルーターのすべての物理コンポーネントを所有しています。BSYSでのJunos OS設定を通じて、ラインカードをGNFに割り当て、GNF間の抽象化ファブリック(af)インターフェイスを定義できます。BSYSソフトウェアは、MXシリーズルーターの冗長ルーティングエンジンのペアで動作します。
ゲストネットワーク機能(GNF)
ゲストネットワーク機能(GNF)は、ベースシステム(BSYS)によって割り当てられたラインカードを論理的に所有し、ラインカードの転送状態を維持します。MX シリーズ ルーターには、複数の GNF を設定できます( ゲスト ネットワーク機能の設定を参照)。各GNFのJunos OSコントロールプレーンは、仮想マシン(VM)として動作します。ジュニパーデバイスマネージャー(JDM)ソフトウェアがGNF VMをオーケストレーションします。JDM のコンテキストでは、GNF は仮想ネットワーク機能(VNF)と呼ばれます。
GNFは、スタンドアロンルーターに相当します。GNFは独立して設定および管理され、運用上互いに分離されています。
GNF を作成するには、BSYS と JDM の 2 つの構成セットが必要です。
GNF は ID によって定義されます。この ID は、BSYS と JDM で同じである必要があります。
GNF設定のBSYS部分は、IDとラインカードのセットを与えることで構成されています。
GNF 構成の JDM 部分は、以下の属性の指定で構成されます。
VNF 名。
GNF ID。この ID は、BSYS で使用される GNF ID と同じである必要があります。
MX シリーズ プラットフォーム タイプ(外部サーバー モデルの場合)。
VNFに使用されるJunos OSイメージ。
VNF サーバーリソーステンプレート。
サーバーリソーステンプレートは、専用(物理)CPUコアの数と、GNFに割り当てるDRAMのサイズを定義します。GNF で使用できる定義済みのサーバー リソース テンプレートの一覧については、 Junos Node Slicing の最小ハードウェアおよびソフトウェア要件のサーバー ハードウェア リソース要件(GNF あたり)セクションを参照してください。
GNF を設定したら、GNF の仮想コンソール ポートに接続してアクセスできます。GNFでJunos OS CLIを使用して、ホスト名や管理IPアドレスなどのGNFシステムプロパティを設定し、管理ポートを介してアクセスすることができます。
ジュニパーデバイスマネージャー(JDM)
仮想化LinuxコンテナであるJuniper Device Manager(JDM)を使用することで、GNF VMのプロビジョニングと管理が可能になります。
JDMは、Junos OSライクなCLI、設定と管理のためのNETCONF、監視のためのSNMPをサポートしています。
シャーシ内モデルでは、JDM は SNMP をサポートしません。
JDM インスタンスは、外部サーバーモデルの各 x86 サーバーと、シャーシ内モデルの各ルーティングエンジンでホストされます。JDM インスタンスは通常、GNF 構成を同期するピアとして構成されます。一方のサーバーで GNF VM が作成されると、もう一方のサーバーまたはルーティング エンジンでバックアップ VM が自動的に作成されます。
JDM で IP アドレスと管理者アカウントを設定する必要があります。これらを設定したら、JDM に直接ログインできます。
関連項目
抽象化されたファブリック インターフェイス
抽象化されたファブリック(af)インターフェイスは、ファーストクラスのイーサネットインターフェイスの動作を表す疑似インターフェイスです。 af インターフェイスは、スイッチファブリックを介したゲストネットワーク機能(GNF)間のトラフィックのルーティング、制御、および管理を容易にします。2つのGNFが相互に接続されているように設定されている場合、ピアGNFと通信するためにGNF上に af インターフェイスが作成されます。抽象化されたファブリック インターフェイスは、BSYS で作成する必要があります。 af インターフェイスの帯域幅は、リモートラインカード/MPCの挿入または到達可能性に基づいて動的に変化します。ファブリックはGNF間の通信媒体であるため、 af インターフェイスは同等のWANインターフェイスとみなされます。 図3を参照してください。
抽象化されたファブリック インターフェイス帯域幅の理解
抽象化ファブリック(af)インターフェイスは、ファブリックを介して 2 つの GNF を接続し、2 つの GNF を接続するすべての PFE(パケット転送エンジン)を集約します。 af インターフェイスは、 af インターフェイスに属する各パケット転送エンジンの帯域幅の合計を活用することができます。
例えば、GNF1にMPC8が1つ(それぞれ240Gbpsの容量を持つパケット転送エンジンが4つある)があり、GNF1が af インターフェイス(af1とaf2)を使用してGNF2およびGNF3と接続されている場合、GNF1の最大 af インターフェイス容量は4x240Gbps = 960Gbpsになります。
GNF1—af1——GNF2
GNF1—af2——GNF3
ここでは、af1 と af2 は 960 Gbps の容量を共有しています。
各 MPC でサポートされる帯域幅については、 表 1 を参照してください。
抽象化されたファブリック インターフェイスでサポートされる機能
抽象化されたファブリック インターフェイスは、次の機能をサポートしています。
統合型稼動中ソフトウェア アップグレード(ISSU)
BSYSレベルでのハイパーモード設定(Junos OSリリース19.3R2以降)。この機能は、MPC6E、MPC8E、MPC9E、MPC11E ライン カードでサポートされています。
手記：個々のGNFはBSYSから設定を継承しているため、ハイパーモードの設定を変えることはできません。
SFB3を搭載したMX2020およびMX2010ルーターは、デフォルトでハイパーモードで起動します。ハイパー モードを任意の GNF で無効にする必要がある場合は、BSYS で設定する必要があり、ハイパー モードはそのシャーシのすべての GNF に適用されます。
存在するリモート GNF ラインカードに基づくロードバランシング
サービスクラス(CoS)のサポート:
Inet-precedence classifier and rewrite
DSCP分類子と書き換え
MPLS EXPの分類と書き換え
IP v6トラフィックのDSCP v6分類子と書き換え
OSPF、IS-IS、BGP、OSPFv3 プロトコル、L3VPN のサポート
手記：非
afインターフェイスは、Junos OSで動作するすべてのプロトコルをサポートしています。-
Junos OSリリース24.2R1以降から始まるBGP、IS-IS、OSPF向けBFD。
マルチキャスト転送
グレースフル ルーティング エンジン スイッチオーバー(GRES)
afインターフェイスがコアインターフェイスとして機能するMPLSアプリケーション(L3VPN、VPLS、L2VPN、L2CKT、EVPN、およびIP over MPLS)次のプロトコルファミリーがサポートされています。
IPv4 転送
IPv6 転送
ティッカー
磯
CCC
JTI(Junos Telemetry Interface)センサーのサポート
Junos OS リリース 19.1R1 以降、ゲスト ネットワーク機能(GNF)は、VXLAN(仮想拡張 LAN)プロトコル(VXLAN)カプセル化により、EVPN(イーサネット VPN)をサポートします。このサポートは、非
af(つまり物理)インターフェイスと、コアフェーシングインターフェイスとしてのafインターフェイスで利用できます。このサポートは、MPC11Eラインカードでは使用できません。afインターフェイス構成では、GNFはaf対応MPCをサポートします。表1は、af対応MPC、MPCごとにサポートされているPFEの数、MPCごとにサポートされている帯域幅を示しています。表 1: サポートされる抽象化されたファブリック対応 MPC ティッカー
初期リリース
PFEの数
総帯域幅
MPC7E-MRATE
17.4R1
2
480G (240*2)
MPC7E-10G
17.4R1
2
480G (240*2)
MX2K-MPC8E
17.4R1
4
960G (240*4)
MX2K-MPC9E
17.4R1
4
1.6T(400※4)
MPC2E
19.1R1
2
80 (40*2)
MPC2E NG
17.4R1
1
80G
MPC2E NG Q
17.4R1
1
80G
MPC3E
19.1R1
1
130G
MPC3E NG
17.4R1
1
130G
MPC3E NG Q
17.4R1
1
130G
32 x 10GE MPC4E
19.1R1
2
260G (130*2)
2x100GE + 8x10GE MPC4E
19.1R1
2
260G (130*2)
MPC5E-40G10G
18.3R1
2
240G(120*2)
MPC5EQ-40G10G
18.3R1
2
240G(120*2)
MPC5E-40G100G
18.3R1
2
240G(120*2)
MPC5EQ-40G100G
18.3R1
2
240G(120*2)
MX2K-MPC6E
18.3R1
4
520G (130*4)
マルチサービスMPC(MS-MPC)
19.1R1
1
120G
16 x 10 GE MPC
19.1R1
4
160G (40*4)
MX2K-MPC11E
19.3R2
8
4T(500G*8)
afインターフェイスのMTU設定は、XE/GEインターフェイスの最大許容値に合わせることを推奨します。これにより、af インターフェイス上のパケットのフラグメント化を最小限に抑えるか、まったく発生させないことができます。
抽象化されたファブリック インターフェイスの制限
抽象化されたファブリック インターフェイスの現在の制限を次に示します。
単一のエンドポイント
afインターフェイス、afインターフェイスから GNF へのマッピングの不一致、または同じリモート GNF への複数のafインターフェイスのマッピングなどの設定は、BSYS でのコミット中にチェックされません。構成が正しいことを確認します。帯域幅の割り当ては、MPC タイプに基づいて静的に行われます。
リモート GNF でホストされている MPC のオフライン/再起動時のトラフィック損失(トランジットとホストの両方)を最小限に抑えることができます。
af対応MPCとaf非対応MPCの相互運用性はサポートされていません。
関連項目
抽象化されたファブリックインターフェイスのためのファブリックパスの最適化
ファブリックパス最適化モードを設定することで、2つのゲストネットワーク機能(GNF)間の抽象化されたファブリック(af)インターフェイス上のトラフィックを最適化できます。この機能は、パケットが最終的に宛先パケット転送エンジンに到達する前に、ファブリックホップ(あるパケット転送エンジンから別のパケット転送エンジンへのトラフィックフローのスイッチング)を防ぐことにより、ファブリックの帯域幅消費を削減します。ファブリックパスの最適化は、MPC9EおよびMX2K-MPC11Eを搭載したMX2008、MX2010、MX2020でサポートされており、抽象化されたファブリックインターフェイスのロードバランシングから生じるトラフィックホップの追加が1つだけになるのを防ぎます。
次のいずれかのファブリックパス最適化モードを設定できます。
monitor—このモードを設定すると、ピアGNFはトラフィックフローを監視し、トラフィックが現在転送されているパケット転送エンジンと、最適化されたトラフィックパスを提供できる目的のパケット転送エンジンに関する情報を送信元GNFに送信します。このモードでは、送信元GNFは目的のパケット転送エンジンにトラフィックを転送しません。optimize—このモードを設定すると、ピアGNFはトラフィックフローを監視し、トラフィックが現在転送されているパケット転送エンジンと、最適化されたトラフィックパスを提供できる目的のパケット転送エンジンに関する情報を送信元GNFに送信します。次に、送信元GNFは、目的のパケット転送エンジンに向けてトラフィックを転送します。
ファブリック パス最適化モードを設定するには、BSYS で次の CLI コマンドを使用します。
user@router#set chassis network-slices guest-network-functions gnf id af-name collapsed-forward (monitor | optimize)user@router#commit
ファブリックパスの最適化を設定した後、GNFのコマンド show interfaces af-interface-name を使用して、現在最適/非最適パスで流れているパケットの数を表示できます。
関連項目
外部サーバ モデルとシャーシ内モデルの選択
外部サーバ モデルでは、GNF の要件を満たすのに十分な容量のサーバを選択できるため、より高いスケールでより多くの GNF インスタンスを設定できます。シャーシ内モデルでは、設定可能なGNFの数は、構成要素GNFの規模要件とルーティングエンジンの全体的な容量の関数です。
Junosノードスライシングの外部サーバーとシャーシ内モデルは相互に排他的です。MXシリーズルーターは、これらのモデルのうち1つのみで同時に動作するように設定できます。
BSYS と GNF のプライマリ ロールの動作
次のセクションでは、ルーティング エンジンの冗長性の観点からの BSYS と GNF の主要なロール動作について説明します。
図4 は、ルーティングエンジンの冗長性を使用したGNFとBSYSのプライマリロールの動作を示しています。
のプライマリ ロールの動作
BSYS プライマリ ロール
BSYS ルーティング エンジンのプライマリ ロール アービトレーションの動作は、MX シリーズ ルーターのルーティング エンジンの動作と同じです。
GNF の主な役割
GNF VM のプライマリロールのアービトレーション動作は、MX シリーズのルーティングエンジンの動作と似ています。各 GNF は、VM のプライマリ/バックアップ ペアとして動作します。 server0 (またはシャーシ内の場合は re0 )で動作するGNF VMは、MXシリーズルーターのルーティングエンジンスロット0に相当し、 server1 (またはシャーシ内の場合は re1 )で動作するGNF VMは、MXシリーズルーターのルーティングエンジンスロット1に相当します。
GNF のプライマリ ロールは、BSYS のプライマリ ロールや他の GNF のプライマリ ロールから独立しています。GNF プライマリ ロールのアービトレーションは、Junos OS を介して行われます。接続障害状態では、GNF の主要な役割は控えめに処理されます。
GNF プライマリ ロール モデルは、外部サーバー モデルとシャーシ内モデルの両方で同じです。
MXシリーズルーティングエンジンと同様に、各GNFでグレースフルルーティングエンジンスイッチオーバー(GRES)を設定する必要があります。これは、プライマリ GNF VM に障害が発生したり再起動されたりしたときに、バックアップ GNF VM がプライマリ ロールを自動的に引き継ぐための前提条件です。
Junos Node Slicing 管理者ロール
次の管理者ロールを使用すると、ノード スライシング タスクを実行できます。
BSYS 管理者 - 物理シャーシと GNF プロビジョニング(ライン カードの GNF への割り当て)を担当します。これらのタスクでは、Junos OS CLI コマンドを使用できます。
GNF 管理者 - GNF で Junos OS の設定、運用、管理を担当します。GNF 管理者は、これらのタスクのために、通常の Junos OS CLI コマンドをすべて使用できます。
JDM 管理者 - JDM サーバーのポート構成(外部サーバーモデルの場合)、および GNF VM(VNF)のプロビジョニングとライフサイクル管理を担当します。これらのタスクでは、JDM CLI コマンドを使用できます。
サブラインカードの概要
Junosノードスライシングでは、各GNFはラインカード(FPC)で構成されています。デフォルトでは、GNF が提供する最も細かい粒度はラインカードレベルになります。各 GNF にはラインカード全体(つまり、各ラインカードのパケット転送エンジンの完全なセット)が割り当てられるためです。サブラインカード(SLC)機能では、1つのラインカード内のパケット転送エンジンのサブセットを異なるGNFに割り当てることで、より細かい区分を定義できます。
このようにラインカード内のパケット転送エンジンのユーザー定義のサブセットを、サブラインカード(SLC)と呼びます。運用上、SLCは独立したラインカードのように機能します。
ラインカードをスライスする場合、そのラインカードのすべてのSLCを異なるGNFに割り当てる必要があります。
複数のラインカードから同じGNFにSLCを割り当てることができます。
SLC機能を備えたJunosノードスライシング設定では、GNFはラインカード全体だけでなく、ラインカードのスライス(SLC)のセットでも構成できるため、高いレベルの柔軟性が得られます。
ライン カードがスライスされると、1 つの BLC(ベース ライン カード)インスタンスと複数の SLC インスタンス(そのライン カードのスライス数)の 2 種類のソフトウェア インスタンスがそのライン カードで実行されます。現在、SLC機能は、2つのSLCをサポートするMPC11Eでのみ使用できます。BLCインスタンスは、そのラインカードのすべてのSLCに共通のハードウェアを管理し、各SLCインスタンスは、自分に排他的に割り当てられたパケット転送エンジンのセットを管理します。BLC インスタンスは BSYS の Junos ソフトウェアを実行し、各 SLC インスタンスは関連する GNF の Junos ソフトウェアを実行します。
SLCは、 抽象化されたファブリックインターフェイス と集約型転送をサポートします( 抽象化されたファブリックインターフェイスのファブリックパスの最適化を参照)。 show interface af-interface-name コマンドを使用して、リモート FPC スライス固有のパケット転送エンジンの負荷分散統計を表示できます。詳細については、 show interfaces(抽象化されたファブリック) を参照してください。
SLC機能はMPC11E(型番:MX2K-MPC11E)でのみ利用可能です。
SLC のラインカードリソース
SLC またはラインカードのスライスは、一緒に動作する必要がある(そのラインカードの)パケット転送エンジンのセットを定義します。ラインカード内のパケット転送エンジンは、数字のIDで識別されます。ラインカードに「n」個のパケット転送エンジンがある場合、個々のパケット転送エンジンには0から(n-1)までの番号が付けられます。さらに、ラインカードのコントロールボード上のCPUコアとDRAMも分割してスライスに割り当てる必要があります。SLCを定義するには、そのSLC専用となる次のラインカードリソースを定義します。
-
パケット転送エンジンの範囲
-
ラインカードのコントロールボード上のCPUコアの数
-
ラインカードのコントロールボード上のDRAMのサイズ(GB)
一定量のDRAMは、そのラインカードのBLCインスタンス用に自動的に予約され、残りはSLCインスタンスに使用できます。
すべての SLC は、ユーザーによって割り当てられた数値 ID によって識別されます。
ラインカードをスライスする場合、そのラインカード上のすべてのスライスのリソースパーティションを完全に定義する必要があります。
SLC 向け MPC11E ライン カードのリソース
MPC11Eラインカードには次のものがあります。
-
8 パケット転送エンジン
-
コントロールボード上に8個のCPUコア
-
コントロールボード上の32GBのDRAM
5 GB の DRAM は自動的に BLC 用に予約され、1 GB の DRAM がラインカード ホストに割り当てられ、残りの 26 GB は SLC スライスに使用できます。
MPC11E は 2 つの SLC をサポートすることができます。
表 2 は、MPC11E が 2 つの SLC (ここでは SLC1 および SLC2 と呼ぶ) に対してサポートする 2 つのタイプのリソース割り振りプロファイルを定義しています。
対称プロファイルでは、パケット転送エンジンとその他のラインカードリソースがスライス間で均等に分散されます。非対称プロファイルでは、 表 2 に示す指定されたラインカードリソースの組み合わせのみがサポートされています。
パケット転送エンジン[0-7]が2つのSLC間でどのように分割されるかに基づいて、次のSLCプロファイルを設定できます。
-
パケット転送エンジン 一方の SLC の場合は 0-3、もう一方の SLC の場合は 4-7(対称プロファイル)
-
パケット転送エンジン 一方の SLC では 0-1、もう一方の SLC では 2-7(非対称プロファイル)
-
パケット転送エンジン 一方のSLCでは0-5、他方のSLCでは6-7(非対称プロファイル)
非対称プロファイルでは、9 GB または 17 GB の DRAM を SLC に割り当てることができます。すべてのラインカードリソースを完全に割り当てる必要があり、SLCで使用可能なDRAMの合計は26GBであるため、9GBのDRAMをSLCに割り当てるには、残りの17GBを他のSLCに割り当てる必要があります。
| 対称プロファイル |
非対称プロファイル |
|||
|---|---|---|---|---|
| リソースの種類 |
SLC1 |
SLC2 |
SLC1 |
SLC2 |
| パケット転送エンジン |
4 |
4 |
2 |
6 |
| ドラム |
13GB |
13GB |
17GB/9GB |
9 GB/17 GB |
| CPU: |
4 |
4 |
4 |
4 |
サブラインカードの設定と GNF への割り当て、およびサブラインカードの管理も参照してください。
マルチバージョンソフトウェアの相互運用性の概要
Junos OSリリース17.4R1以降、Junosノードスライシングはマルチバージョンソフトウェアの互換性をサポートし、BSYSのソフトウェアバージョンよりも新しいバージョンのJunos OSを実行するゲストネットワーク機能(GNF)との相互運用を可能にします。この機能は、GNFとBSYSの間で最大2つのバージョンの範囲をサポートします。つまり、GNF ソフトウェアは BSYS ソフトウェアより 2 つ高いバージョンにすることができます。BSYSとGNFの両方が、Junos OSリリース17.4R1の最小バージョン要件を満たしている必要があります。
マルチバージョンサポートの制限は、統合 ISSU アップグレードプロセスにも適用されます。
JDM ソフトウェアのバージョン管理には、GNF または BSYS ソフトウェアのバージョンに関して同様の制限はありませんが、JDM ソフトウェアを定期的に更新することをお勧めします。JDM のアップグレードは、実行中の GNF には影響しません。
Junosノードスライシングでの次世代サービス
Junosノードスライシングは、MXプラットフォーム上で次世代サービスを実行するための追加の処理能力を提供するセキュリティサービスカードである MX-SPC3サービスカードをサポートしています。GNF で CLI request system enable unified-services を使用して、ゲスト ネットワーク機能 (GNF) で次世代サービスを有効にすることができます。MX-SPC3をサポートするには、GNFにラインカードが関連付けられている必要があります。
Junosノードスライシング設定では、MX-SPC3とMS-MPCの両方を同じシャーシ上で異なるGNFルーティングエンジンで使用できます。GNFで次世代サービスを有効にしている場合、 request system enable unified-servicesを使用することで、MX-SPC3がオンラインになります。次世代サービスを有効にしていない場合は、MS-MPCがオンラインになります。
MX-SPC3カードのソフトウェアインストールまたはアップグレードは、関連するGNFルーティングエンジンをインストールまたはアップグレードするときに行われます。
MX-SPC3 は、抽象化されたファブリック インターフェイスをサポートしていません。そのため、MX-SPC3 カードがリンクされている GNF には、ラインカードも関連付けられている必要があります。
Junos Node Slicing と論理システムの比較
Junosノードスライシングは、Junosの論理システムの下位レイヤーです。どちらのテクノロジにも重複する機能がいくつかありますが、他の側面が異なります。Junosノードスライシングでは、完全なラインカード、つまり物理インターフェイスがGNFに割り当てられますが、論理システムでは、物理インターフェイス上で定義された複数の論理インターフェイスをすべて別々の論理システムに割り当てることができるため、単一の物理インターフェイス自体を異なる論理システムで共有できます。つまり、論理システムでは、Junosのノードスライシングよりも細かい共有が可能です。しかし、すべての論理システムは単一のJunosカーネルを共有するため、ルーティングエンジンとCPU、メモリ、ストレージなどのラインカードの物理リソースを共有する必要があることに加えて、必然的に同じJunosバージョンが実行されます。Junosノードスライシングでは、各GNFはルーティングエンジンのペアに相当する独自のものを取得し、そのGNF専用のラインカードも取得します。そのため、GNFはほとんどの物理リソースを共有せず、シャーシとスイッチファブリックのみを共有します。GNFは、論理システムとは異なり、MXスタンドアロンルーターと同様に、独立してアップグレードおよび管理できます。
Junosノードスライシングは、GNF自体が内部に複数の論理システムを持つことができるため、論理システムを補完し、さらには拡張するテクノロジーです。物理的な隔離、リソースの保証、管理上の完全な隔離が最も重要な場合は、Junosノードスライシングが適しています。そして、論理インターフェイスレベルに至るまで、共有の細かい粒度が最も重要である場合は、論理システムの方が適しています。
Junos Node Slicing のライセンス
Junosノードスライシングを運用するには、GNFおよび抽象化されたファブリックインターフェイスのライセンスをBSYSにインストールする必要があります。BSYS にライセンスをインストールせずに GNF を実行すると、以下の syslog メッセージとマイナー アラームが発生します。
CHASSISD_LICENSE_EVENT: License Network-Slices: Failed to get valid license('216') 'gnf-creation'
Minor alarm set, 1 Guest network functions creation for JUNOS requires a license.
Junosノードスライシングライセンスに関するご質問がございましたら、ジュニパーネットワークスまでお問い合わせください。