Junos Node Slicingの設定
外部サーバーモデルを使用している場合は、Junos Node Slicingのセットアップタスクを実行する前に、「 Junos Node Slicingのセットアップの準備」の章で説明されている手順を完了している必要があります。
BSYSモードで動作するようにMXシリーズルーターを設定する(外部サーバーモデル)
サーバーとルーターの接続で説明されているように、MXシリーズルーターがx86サーバーに接続されていることを確認します。
Junos Node Slicingには、ベースシステム(BSYS)として機能するMXシリーズルーターが必要です。
以下のステップで、MXシリーズルーターをBSYSモードで動作するように設定します。
BSYSモードのルーターは、Junos Node Slicingの基本的な管理機能を実行するために必要な機能以外の機能を実行することはありません。例えば、BSYSは、システムにインストールされているラインカードに関連付けられたインターフェイス設定を持つことを想定していません。代わりに、ゲストネットワーク機能(GNF)には本格的なルーター設定が適用されます。
RHEL (外部サーバーモデル) を実行している x86 サーバーへの JDM RPM パッケージのインストール
x86サーバー用のJDM RPMパッケージをインストールする前に、 JDM用追加パッケージのインストールの説明に従って、追加パッケージがインストールされていることを確認します。
以下のように、RHEL を実行している x86 サーバー用の JDM RPM パッケージをダウンロードしてインストールします。
RHEL を実行している x86 サーバーにパッケージをインストールするには、各サーバーで以下の手順を実行します。
2 番目のサーバーについても、これらの手順を繰り返します。
Ubuntu 24.04(外部サーバーモデル)を実行しているx86サーバーへのJDM Ubuntuパッケージのインストール
x86サーバー用のJDM Ubuntuパッケージをインストールする前に、追加パッケージがインストールされていることを確認してください。詳細は、 JDM用の追加パッケージのインストールを参照してください。
Ubuntu 24.04を実行しているx86サーバー用のJDM Ubuntuパッケージを次のようにダウンロードしてインストールします。
Ubuntu 24.04を実行しているx86サーバーにJDMパッケージをインストールするには、各サーバーで次の手順を実行します。
2 番目のサーバーについても、これらの手順を繰り返します。
x86サーバーでのJDMの設定(外部サーバーモデル)
次の手順を使用して、各x86サーバーでJDMを設定します。
JDMでの非ルートユーザーの設定(Junos Node Slicing)
外部サーバーモデルでは、Junos OSリリース18.3R1以降、Junos Node Slicing用のジュニパーデバイスマネージャー(JDM)で非ルートユーザーを作成できます。非 root ユーザーを作成するには、root アカウントが必要です。非ルートユーザーは、JDMコンソールまたはSSHを使用してJDMにログインできます。非ルートユーザーにはユーザー名が付与され、事前定義されたログインクラスが割り当てられます。
非ルートユーザーは、以下の機能を実行できます。
JDMと対話します。
ゲストネットワーク機能(GNF)をオーケストレーションおよび管理します。
JDM CLIコマンドを使用して、JDM、ホストサーバーおよびGNFの状態を監視します。
非rootユーザーアカウントは、JDM内でのみ機能し、ホストサーバー上では機能しません。
JDMで非ルート・ユーザーを作成するには:
表1 に、JDMがルート以外のユーザー向けにサポートする定義済みのログインクラスを示します。
ログインクラス |
権限 |
|---|---|
スーパーユーザー |
|
運用担当者 |
|
読み取り専用 |
運用担当者クラスと似ていますが、ユーザーがJDM内でデーモンを再起動できない点が異なります。 |
無許可 |
pingおよびtraceroute操作。 |
JDMインターフェイスの設定(外部サーバーモデル)
JDMに設定されているサーバーインターフェイスを変更する場合は、以下の手順を実行します。
JDMで、以下を設定する必要があります。
MXシリーズルーターに接続されている2つの10Gbpsサーバーポート。
JDM管理ポートとして使用するサーバーポート。
GNF管理ポートとして使用するサーバーポート。
そのため、ポートの設定を開始する前に、各サーバーで次の点を確認する必要があります。
CB0に接続され、MXシリーズルーター上でCB1するサーバーインターフェイス(p3p1やp3p2など)。JDM管理とGNF管理に使用するサーバーインターフェイス(
em2やem3など)。
詳細については、「 サーバーとルーターの接続」の図を参照してください。
この情報は、
server0とserver1の両方に必要です。これらのインターフェイスは、Linux ホスト上でのみ表示されます。
JDMでx86サーバーインターフェイスを設定するには、両方のサーバーで次の手順を実行します。
JDM 設定例については、「 Junos Node Slicing のサンプル設定例」を参照してください。
JDMで設定されたサーバーインターフェイスを変更する場合は、GNFを削除し(設定されている場合)、上記のようにインターフェイスを設定し、シェルからJDMを再起動し、GNFを再設定してアクティブ化し、変更をコミットする必要があります。
Junos OSリリース19.2R1以降、Junos Node Slicingは、GNFに対してグローバルに一意のMACアドレス範囲(ジュニパーネットワークスから提供)の割り当てをサポートしています。 .
インシャーシモードで動作するようにMXシリーズルーターを設定する
シャーシ内 Junos Node Slicing を設定するには、MXシリーズ ルーターに次のいずれかのタイプのルーティング エンジンがインストールされている必要があります。
-
RE-S-X6-128G(MX480およびMX960ルーターで使用)
-
REMX2K-X8-128G(MX2010およびMX2020ルーターで使用)
-
REMX2008-X8-128G(MX2008ルーターで使用)
-
シャーシ内モデルでは、ベースシステム(BSYS)、ジュニパーデバイスマネージャー(JDM)、およびすべてのゲストネットワーク機能(GNF)が、MXシリーズルーターのルーティングエンジン内で実行されます。BSYSとGNFは、仮想マシン(VM)としてホスト上で実行されます。最初に、次のようにスタンドアロンMXシリーズルーターのリソースフットプリントを減らす必要があります。
ログ ファイル(/var/log)やコア ファイル(/var/crash)を含む、/var/ の場所にあるすべてのファイルは、set vmhost resize vjunos compact ステートメントを設定した後に VM ホストを再起動すると削除されます。現在 /var/log または /var/crash にあるファイルを、参照用に使用する場合は、VM ホストのサイズ変更設定に進む前に保存する必要があります。
シャーシ内モデルのJDMのインストールと設定
このトピックに記載されている手順は、シャーシ内の Junos Node Slicing 設定にのみ適用されます。
MXシリーズルーター(シャーシ内モデル)へのJDM RPMパッケージのインストール
MXシリーズルーターにジュニパーデバイスマネージャー(JDM)RPMパッケージをインストールする前に、シャーシ内BSYSモードで動作するようにMXシリーズルーターを設定する必要があります。詳細については、「 シャーシ内モードで動作するためのMXシリーズルーターの設定」を参照してください。
RPMパッケージ jns-jdm-vmhost はシャーシ内Junos Node Slicing導入を目的としており、RPMパッケージ jns-jdm は外部サーバーベースのJunos Node Slicing導入に使用されます。
JDM(シャーシ内モデル)の設定
以下の手順を使用して、MXシリーズルーターの両方のルーティングエンジンにJDMを設定します。
シャーシ内Junos Node Slicingでは、同じルーティングエンジンの管理インターフェイス間で(例えば、GNF1のルーティングエンジン0からGNF2のルーティングエンジン0へ、またはGNF1のルーティングエンジン0からJDMへ)トラフィックをpingまたは送信することはできません。
シャーシ内モードでは、BSYSとJDM管理インターフェイス間で
scp操作を実行することはできません。ステップ8を試みる前に、ステップ7で説明したようにssh鍵交換を行っておく必要があります。ステップ 7 を完了せずにステップ 8 を試みた場合、システムは以下の例に示すようにエラーメッセージを表示します。
Failed to fetch JDM software version from server1. If authentication of peer server is not done yet, try running request server authenticate-peer-server.
Junos OSリリース19.2R1以降、Junos Node Slicingは、GNFに対してグローバルに一意のMACアドレス範囲(ジュニパーネットワークスから提供)の割り当てをサポートしています。 .
GNFへのMACアドレスの割り当て
Junos OSリリース19.2R1以降、Junos Node Slicingは、GNFにグローバルに一意のMACアドレス範囲(ジュニパーネットワークスから提供)の割り当てをサポートしています。
GNFのグローバルに一意のMACアドレス範囲を受け取るには、ジュニパーネットワークスの担当者に連絡し、GNFライセンスの購入時に電子的に発送されるGNFライセンスSSRN(ソフトウェアサポート参照番号)をお知らせください。GNFライセンスでSSRNを見つけるには、ジュニパーネットワークスのナレッジベースの記事 KB11364を参照してください。
GNFライセンスごとに、「拡張SSRN」が提供されます。これには、ジュニパーネットワークスがそのGNFライセンスに割り当てたグローバルに一意のMACアドレス範囲が含まれます。次に、JDM CLIでこの拡張SSRNを次のように設定する必要があります。
root@jdm#set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-stringroot@jdm#commit
拡張SSRNは、1つのGNF IDにのみ使用する必要があります。JDMでは、GNF VMは仮想ネットワーク機能(VNF)と呼ばれます。GNF IDはその属性の1つです。VNF の属性については、以降の「 ゲスト ネットワーク機能の設定」で詳しく説明しています。
デフォルトでは、拡張SSRNが検証されます。この検証をスキップする必要がある場合は、次のようにCLIでno-validate属性を使用できます。 例:
set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-string [no-validate]。
GNF IDの拡張SSRNは、GNFが動作しておらず、まだプロビジョニングされていない場合にのみ設定できます。GNFを設定する前に、まずGNF ID用に拡張SSRNを設定する必要があります。GNF ID がすでにプロビジョニングされている場合は、拡張 SSRN を設定する前に、まず両方のサーバー(外部サーバー モデルの場合)または両方のルーティング エンジン(シャーシ内 Junos Node Slicing モデルの場合)でその GNF ID の GNF を削除する必要があります。
同様に、GNF IDの拡張SSRNを削除する前に、まず両方のサーバー(外部サーバーモデルの場合)または両方のルーティングエンジン(in-chassis Junos Node Slicingモデルの場合)で特定のGNF IDのGNFを削除する必要があります。
拡張SSRNは、Junos OS 19.1R1以前に基づくGNFに適用できません。
GNF に割り当てられたMACアドレス範囲が適用されたことを確認するには、GNF が動作可能になったら、Junos CLI コマンドを使用します
show chassis mac-addresses- 出力は拡張された SSRN の部分文字列と一致します。
ゲストネットワーク機能の設定
ゲストネットワーク機能(GNF)の設定は、BSYS で実行するタスクと JDM で実行するタスクの 2 つのタスクで構成されます。
- GNFの作成を試みる前に、JDMインスタンスによって生成されたランダムMACプレフィックスが同期されているように、JDM設定の一部としてコミット同期が設定されていることを確認する必要があります。ランダムなMACプレフィックスが同期されているかどうかを確認するには、JDMで
show server connectionsまたはshow system random-mac-prefixCLIコマンドを使用します。ランダムな MAC プレフィックスが同期されていない場合、ソフトウェアは次のメジャー アラームを発生させます。Mismatched MAC address pool between GNF RE0 and GNF RE1。アラームを表示するには、show system alarmsコマンドを使用します。 -
GNFの作成を試みる前に、サーバー(またはシャーシ内モデルの場合はルーティングエンジン)に、そのGNFのための十分なリソース(CPU、メモリ、ストレージ)があることを確認する必要があります。
-
各GNFにIDを割り当てる必要があります。このIDは、BSYSとJDMで同じである必要があります。
BSYSで、次の例に示すように、設定を適用してIDとラインカードのセットを割り当ててGNFを指定します。
ユーザー@ルーター# set chassis network-slices guest-network-functions gnf 1 fpcs 4
ユーザー@ルーター# commit
JDMでは、GNF VMは仮想ネットワーク機能(VNF)と呼ばれます。VNFには以下の属性があります。
VNF名。
GNF ID。この ID は、BSYS で使用される GNF ID と同じである必要があります。
MXシリーズプラットフォームタイプ。
-
GNFに使用するJunos OSイメージは、ジュニパー のダウンロード ページからダウンロードできます。
ダウンロードページから、すべての製品>Junosノードスライシング - ゲストネットワーク機能を選択し、GNFのJunosイメージをダウンロードします。
VNFサーバーリソーステンプレート。
JDMでVNFを設定するには、以下の手順を実行します。
JDMシェル・コマンド
scpを使用して、GNFのJunos OS Node Slicingイメージを取得し、JDMローカル・ディレクトリ/ var/jdm-usr/gnf-images に配置します(GNF構成ファイルを取得するには、このステップを繰り返します)。root@jdm:~#
scp source-location-of-the-gnf-image /var/jdm-usr/gnf-imagesroot@jdm:~#scp source-location-of-the-gnf-configuration-file /var/jdm-usr/gnf-config次の例に示すように、JDM CLIコマンドを使用して、このイメージをGNFに割り当てます。
root@test-jdm-server0>
request virtual-network-functions test-gnf add-image /var/jdm-usr/gnf-images/junos-install-ns-mx-x86-64-17.4R1.10.tgz all-serversServer0: Added image: /vm-primary/test-gnf/test-gnf.img Server1: Added image: /vm-primary/test-gnf/test-gnf.img-
次の例に示すように、設定ステートメントを適用してVNFを設定します。
root@test-jdm-server0#
set virtual-network-functionstest-gnfid1root@test-jdm-server0#
set virtual-network-functionstest-gnfchassis-type mx2020root@test-jdm-server0#
set virtual-network-functionstest-gnfresource-template2core-16groot@test-jdm-server0#
set system vnf-license-supplement vnf-id 1 license-supplement-string RTU00023003204-01-AABBCCDDEE00-1100-01-411Cシャーシ内モデルの場合、プラットフォームタイプ(
set virtual-network-functionstest-gnfchassis-type mx2020)を設定しないでください。自動的に検知されます。Junos OSリリース19.2R1以降、Junos Node Slicingは、GNFにグローバルに一意のMACアドレス範囲(ジュニパーネットワークスから提供)の割り当てをサポートしています。
GNF のベースライン設定または初期Junos OS設定も指定するには、外部サーバーモデルの場合はサーバー(server0 および server1)の両方、およびシャーシ内モデルの場合は両方のルーティングエンジン(re0 および re1)で GNF 設定ファイル(例: /var/jdm-usr/gnf-config/test-gnf.conf)を準備し、以下に示すように、
base-configステートメントのパラメーターとしてファイル名を指定します。root@test-jdm-server0#
set virtual-network-functions test-gnf base-config /var/jdm-usr/gnf-config/test-gnf.confroot@test-jdm-server0#
commit synchronize注:以下を確認します。
-
BSYSで前に指定したものと同じGNF IDを使用します。
-
ベースライン設定ファイル名(パス付き)は、両方のサーバー/ルーティングエンジンで同じです。
-
ベースラインファイルの内容の構文は、Junos OS設定形式です。
-
ここで使用するGNF名は、ステップ2でGNFのJunos OSイメージに割り当てられたものと同じです。
-
VNFが作成されていることを確認するには、次のJDM CLIコマンドを実行します。
root@test-jdm-server0>
show virtual-network-functions test-gnf以下のJDM CLIコマンドを発行して、VNFのコンソールにログインします。
root@test-jdm-server0>
request virtual-network-functions test-gnf console注:設定タスクを完了した後は、必ずVNFコンソールからログアウトしてください。コマンド
set system login idle-timeout minutesを使用してアイドルタイムアウトを設定することをお勧めします。そうしないと、ユーザーがVNFコンソールセッションからログアウトするのを忘れた場合、別のユーザーがアクセス資格情報を提供せずにログインできます。詳細については、 システムログイン(Junos Node Slicing)を参照してください。VNFは、MXシリーズルーティングエンジンの設定と同じ方法で設定します。
シャーシ内モデルのCLIプロンプトは
root@jdm#です。設定例については、「 Junos Node Slicingのサンプル設定」を参照してください。
外部サーバーモデルの場合、以前に物理x86 CBインターフェイスまたはGNF管理インターフェイスをLinuxシェルから(コマンド
ifconfig interface-name downを使用して)ダウンさせていた場合、GNFが起動すると自動的に起動されます。
GNF ペア間の抽象化されたファブリック インターフェイスの設定
2つのゲストネットワーク機能(GNF)間で抽象化ファブリック(af)インターフェイスを作成するには、ベースシステム(BSYS)とGNFの両方での設定が必要になります。抽象化されたファブリックインターフェイスは、BSYS設定に基づいてGNF上に作成され、それがそれらのGNFに送信されます。
-
GNFのペア間で設定できる
afインターフェイスは1つだけです。 - 各GNFに単一のFPCが割り当てられているJunos Node Slicingの設定では、リモートGNFに割り当てられたFPCのパケット転送エンジンがファブリック上で到達できなくなると、関連する抽象化ファブリックインターフェイスがダウンします。この動作を引き起こす可能性のあるエラーの例には、PFEファブリック到達可能性エラーや、アクションを引き起こすCMERRORイベント
pfe disableがあります(詳細についてはshow chassis fpc errorsコマンドを参照してください)。GNFに複数のFPCが割り当てられている場合、すべてのピアパケット転送エンジンがダウンしていることを報告するローカルFPCは、抽象化されたファブリックインターフェイスの状態の判断から削除されます。
一対のGNF間で af インターフェイスを設定するには:
-
BSYSで、次の例に示すように設定を適用します。
user@router#
set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf id 4user@router#set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf af2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf id 2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf af4この例では、
af2が抽象化されたファブリックインターフェイスインスタンス2で、af4が抽象化されたファブリックインターフェイスインスタンス4です。注:許可される
afインターフェイス値は、af0からaf9の範囲です。GNF
afインターフェイスが表示され、アップします。afインターフェイスは、他のインターフェイスと同じように設定できます。 GNFで、次の例に示すように設定を適用します。
user@router-gnf-b#
set interfaces af4 unit 0 family inet address 10.10.10.1/24user@router-gnf-d#set interfaces af2 unit 0 family inet address 10.10.10.2/24
afインターフェイスにMPLSファミリ設定を適用したい場合は、afインターフェイスが設定されている両方のGNFにコマンドset interfaces af-name unit logical-unit-number family mplsを適用できます。af設定例については、「Junos Node Slicingのサンプル設定」を参照してください。
抽象化されたファブリックインターフェイスのサービスクラス
サービス クラス(CoS)パケット分類は、パケットの転送クラスに基づいて、受信パケットを出力キューに割り当てます。詳細については、 『CoS 設定ガイド 』を参照してください。
以下のセクションでは、転送クラスからキューへのマッピング、および抽象化ファブリック(af)インターフェイスでサポートされるBA(動作集約)分類子と書き換えについて説明します。
クラスからキューへのマッピングの転送
afインターフェイスは、リモートパケット転送エンジンに指定されたトラフィックが2つのファブリックキュー(低/高優先度のもの)を通過する必要があることを除いて、他のインターフェイスのほとんどの機能を備えたシミュレートされたWANインターフェイスです。
現在、 af インターフェイスは2キューモードのみで動作します。そのため、スケジューリング、ポリシング、シェーピングなどのすべてのキューベースの機能を af インターフェイスで使用できるわけではありません。
afインターフェイス上のパケットは、パケットが属する転送クラスに設定されたファブリック優先度によって決定されるファブリックキューを継承します。例えば、以下の転送クラスからキューへのマップ設定を参照してください。
[編集]
user@router# show class-of-service forwarding-classes
class Economy queue-num 0 priority low; /* Low fabric priority */
class Stream queue-num 1;
class Business queue-num 2;
class Voice queue-num 3;
class NetControl queue-num 3;
class Business2 queue-num 4;
class Business3 queue-num 5;
class VoiceSig queue-num 6 priority high; /* High fabric priority */
class VoiceRTP queue-num 7;
前の例に示したように、パケットが転送クラス VoiceSigに分類されると、転送パスのコードがその転送クラスのファブリック優先度を調べ、このパケットにどのファブリックキューを選択するかを決定します。この場合、優先度の高いファブリックキューが選択されます。
BAの分類と書き換え
BA(動作集約)分類子は、サービスクラス(CoS)値を転送クラスと損失の優先度にマッピングします。転送クラスと損失優先度の組み合わせによって、ルーター内のパケットに与えられる CoS 処理が決まります。以下のBA分類子と書き換えがサポートされています。
Inet-Precedence の分類子と書き換え
DSCPの分類子と書き換え
MPLS EXPの分類子と書き換え
また、MPLS トンネルに入る IP パケットに書き換えを適用し、EXP と IPv4 の両方のサービス タイプ(ToS)ビットの書き換えを実行することもできます。このアプローチは、他の通常のインターフェイスの場合と同様に機能します。
IP v6トラフィック用のDSCP v6分類子と書き換え
以下はサポートされていません。
IEEE 802.1の分類と書き換え
IEEE 802.1AD(QinQ)分類と書き換え
BA CoS分類子の詳細については、 CoS設定ガイド を参照してください。
抽象化されたファブリックインターフェイス用のファブリックパスの最適化
ファブリックパス最適化モードを設定することで、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 を使用して、最適/非最適パスで現在流れているパケット数を表示できます。
関連項目
SNMPトラップのサポート: NMSサーバーの設定(外部サーバーモデル)
ジュニパーデバイスマネージャー(JDM)は、以下のSNMPトラップをサポートします。
JDM インターフェイス用の LinkUp および linkDown トラップ
標準のlinkUp/linkDown SNMPトラップが生成されます。デフォルトのコミュニティ文字列
jdmが使用されます。ホスト インターフェイス用の LinkUp/linkDown トラップ
標準
linkUp/linkDownSNMPトラップが生成されます。デフォルトのコミュニティ文字列hostが使用されます。JDM から JDM への接続損失/回復トラップ
JDMからJDMへの接続損失/再獲得トラップは、汎用syslogトラップ(jnxSyslogTrap)を使用してホスト管理インターフェイスを介して送信されます。
JDM接続ダウントラップ
JDM_JDM_LINK_DOWNは、JDMがcb0リンクまたはcb1リンクを介して別のサーバー上のピアJDMと通信できない場合に送信されます。次の例を参照してください。{ SNMPv2c C=host { V2Trap(296) R=1299287309 .1.3.6.1.2.1.1.3.0=42761992 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_DOWN" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Lost" .1.3.6.1.6.3.1.1.4.3.0.0=”” } }JDMからJDMへの接続トラップ
JDM_JDM_LINK_UPは、cb0リンクまたはcb1リンクのいずれかが立ち上がったときに送信され、両方のサーバー上のJDMが再び通信できるようになります。次の例を参照してください。{ SNMPv2c C=host { V2Trap(292) R=998879760 .1.3.6.1.2.1.1.3.0=42762230 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_UP" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Up" .1.3.6.1.6.3.1.1.4.3.0.0="" } }VM(GNF)アップ/ダウン—
libvirtGuestNotif通知。GNF 開始/シャットダウン イベントの場合、標準
libvirtGuestNotif通知が生成されます。libvirtMIB通知の詳細については、この Webページを参照してください。また、次の例も参照してください。HOST [UDP: [127.0.0.1]:53568->[127.0.0.1]]: Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (636682) 1:46:06.82, SNMPv2-MIB::snmpTrapOID.0 = OID: LIBVIRT-MIB::libvirtGuestNotif, LIBVIRT-MIB::libvirtGuestName.0 = STRING: "gnf1", LIBVIRT-MIB::libvirtGuestUUID.1 = STRING: 7ad4bc2a-16db-d8c0-1f5a-6cb777e17cd8, LIBVIRT-MIB::libvirtGuestState.2 = INTEGER: running(1), LIBVIRT-MIB::libvirtGuestRowStatus.3 = INTEGER: active(1)
SNMP トラップがターゲット NMS サーバーに送信されます。JDMでターゲットNMSサーバーの詳細を設定するには、次の例を参照してください。
[編集]
root@jdm#show snmp | display setroot@jdm#set snmp name nameroot@jdm#set snmp description descriptionroot@jdm#set snmp location locationroot@jdm#set snmp contact user's emailroot@jdm#set snmp trap-group tg-1 targets target ip address1root@jdm#set snmp trap-group tg-1 targets target ip address2
JDMは、ホストのsnmp設定ファイル(/etc/snmp/snmpd.conf)に設定を書き込みません。したがって、JDMのインストールとその後の設定は、ホストSNMPに影響を与えません。JDMのSNMP設定CLIコマンドは、コンテナ内に存在するJDMのsnmpd.confファイルを設定するためにのみ使用されます。linkUp/Downトラップを生成するには、以下の例に示すように、ホストサーバーのsnmpd.confファイル(/etc/snmp/snmpd.conf)に設定を手動で含める必要があります。
createUser trapUser iquerySecName trapUser rouser trapUser defaultMonitors yes notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus ifDescr notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus ifDescr monitor -r 10 -e linkUpTrap "Generate linkUp" ifOperStatus != 2 monitor -r 10 -e linkDownTrap "Generate linkDown" ifOperStatus == 2 trap2sink <NMS-IP> host
上記の例では、<NMS-IP>をNetwork Management Station(NMS)のIPアドレスに置き換えています。
BSYSおよびGNFでのシャーシ設定階層
Junos Node Slicingでは、BSYSがラインカードやファブリックを含むルーターのすべての物理コンポーネントを所有し、GNFはそれぞれのラインカードの転送状態を維持します。この責任の分割に沿って、 chassis 階層(存在する場合)の下Junos CLI設定は、BSYSまたはGNFで次のように適用する必要があります。
chassis設定階層の下の物理レベルのパラメータは、BSYSで適用する必要があります。例えば、FPCでの物理エラーを処理するための設定は物理レベルのパラメーターであるため、BSYSで適用する必要があります。At BSYS Junos CLI: [edit] user@router#
set chassis fpc fpc slot error major threshold threshold value action alarmchassis設定階層の論理パラメータまたは機能レベルのパラメータは、FPCに関連付けられたGNFで適用する必要があります。例えば、ラインカードあたりのmax-queuesの設定は論理レベルのパラメータであるため、GNFで適用する必要があります。At GNF Junos CLI: [edit] user@router#
set chassis fpc fpc slot max-queues value例外として、
chassis設定階層の以下の2つのパラメータは、BSYSとGNFの両方に適用する必要があります。At both BSYS and GNF CLI: [edit] user@router#
set chassis network-services network services modeuser@router#set chassis fpc fpc slot flexible-queueing-mode
サブラインカードの設定とGNFへの割り当て
サブラインカードの概要については、 サブラインカードの概要を参照してください。
-
この機能は、外部サーバーベースのJunos Node Slicing設定で使用されるMX2010ルーターおよびMX2020ルーター上のMPC11Eラインカード(モデル番号:MX2K-MPC11E)に適用できます。
-
すべてのGNFの各ルーティングエンジンとBSYSが、Junos OSリリース21.2R1以降のバージョンを実行していることを確認します。
MPC11EをさらにSLC(サブラインカード)にスライスするには、BSYSのset chassis network-slices guest-network-functions gnf階層にあるfpc-sliceCLIオプションを使用する必要があります。
設定をコミットする前に、ラインカードでサポートされているすべてのSLCを設定し、コア、DRAM、パケット転送エンジンなど、必要なすべてのリソースをSLCに割り当てる必要があります。MPC11E ライン カードは 2 つの SLC をサポートしています。
GNFは、フルラインカードとSLCの以下の組み合わせをサポートします。
-
MPC11E SLCを備えたGNF
-
MPC11E SLCおよびMPC9を使用したGNF
-
MPC11E SLCおよびMPC11Eを使用したGNF
-
MPC11E SLC、MPC9、MPC11E を使用した GNF
SLCを設定し、GNFに割り当てるには、以下の手順を使用します。
-
すべてのSLCに対して、以下のすべてのCLIステートメントを一度に設定する必要があります(以下の手順で示すように)。後でこの設定を変更すると、ラインカード全体が再起動します。
- 間違った値(サポートされていないパケット転送エンジンの範囲、CPUコア、DRAM値など)を設定した場合、設定コミットは失敗し、エラーを示す適切なメッセージが表示されます。
関連項目
Junos Node Slicing の設定例
このセクションでは、Junos Node Slicingの設定例を提供します。
- JDM構成例(外部サーバー・モデル)
- JDM設定例(シャーシ内モデル)
- 抽象化されたファブリック インターフェイスを使用したサンプル BSYS 設定
- サービスクラスによるGNFでの抽象化されたファブリック設定のサンプル
- GNFでの抽象化されたファブリックインターフェイス状態の出力例
JDM構成例(外部サーバー・モデル)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
chassis-type mx2020;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
JDM設定例(シャーシ内モデル)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
抽象化されたファブリック インターフェイスを使用したサンプル BSYS 設定
user@router> show configuration chassis
network-slices {
guest-network-functions {
gnf 1 {
af2 {
peer-gnf id 2 af1;
}
af4 {
peer-gnf id 4 af1;
}
description gnf-a;
fpcs [ 0 19];
}
gnf 2 {
af1 {
peer-gnf id 1 af2;
}
af4 {
peer-gnf id 4 af2;
}
description gnf-b;
fpcs [ 1 6 ];
}
gnf 4 {
af1 {
peer-gnf id 1 af4;
}
af2 {
peer-gnf id 2 af4;
}
description gnf-d;
fpcs [ 3 4 ];
}
}
}
サービスクラスによるGNFでの抽象化されたファブリック設定のサンプル
GNF1とGNF2の間に抽象化ファブリック(af)インターフェイスがあるとします。次の設定例は、トラフィックが GNF1 から GNF2 に送信されるシナリオで、GNF1 の af インターフェイスに書き換えを適用し、GNF2 の af インターフェイスに分類子を適用する方法を示しています。
GNF1 Configuration
interfaces {
xe-4/0/0 {
unit 0 {
family inet {
address 22.1.2.2/24;
}
}
}
af2 {
unit 0 {
family inet {
address 32.1.2.1/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-points [ 001001 000000 ];
}
}
}
interfaces {
xe-4/0/0 {
unit 0 {
classifiers {
dscp testdscp;
}
}
classifiers {
dscp testdscp;
}
}
af1 {
unit 0 {
rewrite-rules {
dscp testdscp; /*Rewrite rule applied on egress AF interface on GNF1.*/
}
}
}
}
rewrite-rules {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-point 001001;
}
}
}
}
GNF2 Configuration
interfaces {
xe-3/0/0:0 {
unit 0 {
family inet {
address 42.1.2.1/24;
}
}
}
af1 {
unit 0 {
family inet {
address 32.1.2.2/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class network-control {
loss-priority low code-points 001001;
}
}
}
interfaces {
af1 {
unit 0 {
classifiers {
dscp testdscp; /*Classifier applied on AF at ingress of GNF2*/
}
}
}
}
}
GNFでの抽象化されたファブリックインターフェイス状態の出力例
user@router-gnf-b> show interfaces af9
Physical interface: af9, Enabled, Physical link is Up
Interface index: 209, SNMP ifIndex: 527
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 370000mbps
Device flags : Present Running
Interface flags: Internal: 0x4000
Link type : Full-Duplex
Link flags : None
Current address: 00:90:69:2b:00:4c, Hardware address: 00:90:69:2b:00:4c
Last flapped : 2018-09-12 01:44:01 PDT (00:01:02 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Bandwidth : 370 Gbps
Peer GNF id : 9
Peer GNF Forwarding element(FE) view :
FPC slot:FE num FE Bandwidth(Gbps) Status Transmit Packets Transmit Bytes
6:0 130 Up 0 0
12:0 120 Up 0 0
12:1 120 Up 0 0
Residual Transmit Statistics :
Packets : 0 Bytes : 0
Fabric Queue Statistics :
FPC slot:FE num High priority(pkts) Low priority(pkts)
6:0 0 0
12:0 0 0
12:1 0 0
FPC slot:FE num High priority(bytes) Low priority(bytes)
6:0 0 0
12:0 0 0
12:1 0 0
Residual Queue Statistics :
High priority(pkts) Low priority(pkts)
0 0
High priority(bytes) Low priority(bytes)
0 0
Logical interface af9.0 (Index 332) (SNMP ifIndex 528)
Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
Input packets : 0
Output packets: 13
Protocol inet, MTU: 1500
サブラインカードの設定例
このセクションでは、サブラインカード(SLC)の設定例を提供します。
対称サブラインカードプロファイルの設定例
対称プロファイルでは、リソースの組み合わせは1つだけです。
以下は、対称サブラインカードプロファイルでFPC 1(MPC11E)をスライスするための設定例です。
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-3set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 13set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 4-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 13
この設定は次のようになります。
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-3;
cores 4;
dram 13;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 4-7;
cores 4;
dram 13;
}
}
}
}
非対称サブラインカードプロファイルの設定例
非対称プロファイルでは、PFEまたはパケット転送エンジン[0-7]が2つのSLC間でどのように分割されているかに応じて、2つの設定が可能です。ある設定例では、最初の 2 つのパケット転送エンジン [0-1] が 1 つの SLC に割り当てられ、残りのパケット転送エンジン [2-7] がもう一方の SLC に割り当てられています。他の構成例では、最後の 2 つのパケット転送エンジン [6-7] が 1 つの SLC に割り当てられ、残りのパケット転送エンジン [0-5] がもう一方の SLC に割り当てられています。
以下の構成例は、[0-1 2-7]分割の例です。
以下の例では、SLCのCPUコアとDRAMの割り当てが、サブラインカードの概要ページのMPC11EでサポートされているSLCプロファイルの表に示されているように、「非対称プロファイル」リソースの組み合わせの下の列のいずれかに一致します。
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-1set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 17set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 2-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 9
この設定は以下のようになります。
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-1;
cores 4;
dram 17;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 2-7;
cores 4;
dram 9;
}
}
}
}