このページの目次
Junos Node Slicingの設定
外部サーバ モデルを使用している場合は、Junos ノード スライシング設定タスクの実行に進む前に、 『Junos Node Slicing セットアップの準備』の章で説明されている手順を完了している必要があります。
BSYS モードで動作するための MX シリーズ ルーターの設定(外部サーバ モデル)
サーバーとルーターの接続の説明に従って、MX シリーズ ルーターが x86 サーバーに接続されていることを確認します。
Junosノードスライシングを実行するには、MXシリーズルーターがベースシステム(BSYS)として機能する必要があります。
MX シリーズ ルーターが BSYS モードで動作するよう設定するには、次の手順を実行します。
BSYSモードのルーターが、Junosノードスライシングの基本的な管理機能を実行するために必要な機能以外の機能を実行することは想定されていません。たとえば、BSYS は、システムにインストールされたライン カードに関連付けられたインターフェイス設定を持つことは想定されていません。代わりに、ゲストネットワーク機能(GNF)は本格的なルーター構成になります。
RHEL を実行する x86 サーバーへの JDM RPM パッケージのインストール(外部サーバーモデル)
x86 サーバー用の JDM RPM パッケージをインストールする前に、 JDM 用の追加パッケージのインストールの説明に従って、追加パッケージがインストールされていることを確認してください。
次のように、RHEL を実行している x86 サーバー用の JDM RPM パッケージをダウンロードしてインストールします。
RHEL を実行している x86 サーバーにパッケージをインストールするには、各サーバーで次の手順を実行します。
2 番目のサーバーに対して手順を繰り返します。
Ubuntu 20.04(外部サーバモデル)を実行しているx86サーバへのJDM Ubuntuパッケージのインストール
x86 サーバー用の JDM Ubuntu パッケージをインストールする前に、追加のパッケージがインストールされていることを確認してください。詳細については、「 JDM の追加パッケージのインストール」を参照してください。
次のように、Ubuntu86を実行しているx20.04サーバー用のJDM Ubuntuパッケージをダウンロードしてインストールします。
Ubuntu 20.04を実行しているx86サーバーにJDMパッケージをインストールするには、各サーバーで次の手順を実行します。
2 番目のサーバーに対して手順を繰り返します。
x86 サーバーでの JDM の設定 (外部サーバーモデル)
以下のステップを使用して、各 x86 サーバーで JDM を構成します。
JDM(Junos Node Slicing)での非ルートユーザーの設定
外部サーバーモデルでは、Junos OSリリース18.3R1以降、Junosノードスライス用のJuniper Device Manager(JDM)で非ルートユーザーを作成できます。非 root ユーザーを作成するには、root アカウントが必要です。非ルートユーザーは、JDM コンソールまたは SSH を使用して JDM にログインできます。非ルートユーザーには、それぞれユーザー名が提供され、事前定義されたログインクラスが割り当てられます。
非 root ユーザーは、以下の機能を実行できます。
JDM と対話します。
ゲストネットワーク機能(GNF)のオーケストレーションと管理を行います。
JDM CLI コマンドを使用して、JDM、ホストサーバー、および GNF の状態を監視します。
非 root ユーザー・アカウントは、ホスト・サーバーではなく、JDM 内でのみ機能します。
JDM で非ルートユーザーを作成するには、次のようにします。
表 1 に、JDM が非 root ユーザーに対してサポートする事前定義ログイン・クラスを示します。
ログインクラス |
権限 |
---|---|
スーパーユーザ |
|
演算子 |
|
読み取り専用 |
演算子クラスに似ていますが、ユーザーが JDM 内でデーモンを再起動できない点が異なります。 |
不正 |
ping および traceroute 操作。 |
JDM インターフェースの設定 (外部サーバー・モデル)
JDM で構成されているサーバー・インターフェースを変更する場合は、以下のステップを実行します。
JDM では、以下を構成する必要があります。
MX シリーズ ルーターに接続された 2 つの 10 Gbps サーバー ポート。
JDM 管理ポートとして使用するサーバー・ポート。
GNF 管理ポートとして使用するサーバー ポート。
したがって、ポートの構成を開始する前に、各サーバーで次のことを確認する必要があります。
MX シリーズ ルーターの
CB0
および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ノードスライシングは、GNFに対してグローバルに一意のMACアドレス範囲(ジュニパーネットワークス提供)の割り当てをサポートしています。 です。
MXシリーズルーターをインシャーシモードで動作するよう設定する
シャーシ内Junosノードスライシングを設定するには、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ホストを再起動すると削除されます。参照用として使用する場合は、VM ホストのサイズ変更の構成に進む前に、現在 /var/log または /var/crash にあるファイルを保存する必要があります。
シャーシ内モデル用のJDMのインストールと設定
このトピックに記載されている手順は、シャーシ内のJunosノードスライシング設定にのみ適用されます。
MXシリーズルーターへのJDM RPMパッケージのインストール(シャーシ内モデル)
MXシリーズルーターにJuniperデバイスマネージャー(JDM)RPMパッケージをインストールする前に、MXシリーズルーターがシャーシ内BSYSモードで動作するように設定する必要があります。詳細については、 MXシリーズルーターをシャーシ内モードで動作するよう設定するを参照してください。
RPMパッケージ jns-jdm-vmhost
は、シャーシ内のJunosノードスライシング導入用であり、RPMパッケージ jns-jdm
は、外部サーバーベースのJunosノードスライシング導入に使用されます。
JDM(インシャーシモデル)の設定
MX シリーズルーターの両方のルーティングエンジンで JDM を設定するには、次の手順に従います。
シャーシ内Junosノードスライシングでは、同じルーティングエンジンの管理インターフェイス間でpingを実行したり、トラフィックを送信したりすることはできません(たとえば、GNF1のルーティングエンジン0からGNF2のルーティングエンジン0へ、またはGNF1のルーティングエンジン0からJDMへ)。
シャーシ内モードでは、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ノードスライシングは、GNFに対してグローバルに一意のMACアドレス範囲(ジュニパーネットワークス提供)の割り当てをサポートしています。 です。
GNF への MAC アドレスの割り当て
Junos OSリリース19.2R1以降、Junosノードスライシングは、GNFに対してグローバルに一意のMACアドレス範囲(ジュニパーネットワークス提供)の割り当てをサポートしています。
GNFのグローバルで一意のMACアドレス範囲を受け取るには、ジュニパーネットワークスの担当者に連絡し、GNFライセンスの購入時に電子的に出荷されるGNFライセンスSSRN(ソフトウェアサポート参照番号)を提供してください。GNFライセンスでSSRNを確認するには、ジュニパーネットワークスのナレッジベース記事 KB11364を参照してください。
各GNFライセンスに対して、ジュニパーネットワークスがそのGNFライセンスに割り当てたグローバルに一意のMACアドレス範囲を含む「拡張SSRN」が提供されます。次に、JDM CLI でこの拡張 SSRN を次のように構成する必要があります。
root@jdm#set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-string
root@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ノードスライシングモデルの場合)で、そのGNF IDのGNFを削除する必要があります。
同様に、GNF IDの拡張SSRNを削除する前に、まず両方のサーバー(外部サーバーモデルの場合)または両方のルーティングエンジン(シャーシ内Junosノードスライシングモデルの場合)で、特定のGNF IDのGNFを削除する必要があります。
Junos OS 19.1R1以前に基づくGNFに拡張SSRNを適用することはできません。
GNFが動作可能になったときに、GNFに割り当てられたMACアドレス範囲が適用されたことを確認するには、Junos CLIコマンド
show chassis mac-addresses
を使用します。出力は拡張SSRNの部分文字列と一致します。
ゲストネットワーク機能の設定
ゲストネットワーク機能(GNF)の設定は、BSYSで実行するタスクとJDMで実行するタスクの2つのタスクで構成されます。
- GNF を作成する前に、JDM インスタンスによって生成されるランダムな MAC プレフィックスが同期するように、JDM 設定の一部としてコミット同期が設定されていることを確認する必要があります。ランダムなMACプレフィックスが同期しているかどうかを確認するには、JDMでCLIコマンド
show server connections
またはshow system random-mac-prefix
を使用します。ランダムな 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を指定します。
user@router# set chassis network-slices guest-network-functions gnf 1 fpcs 4
user@router# commit
JDM では、GNF VM を仮想ネットワーク機能 (VNF) と呼びます。VNFには以下の属性があります。
VNF 名。
GNF ID。この ID は、BSYS で使用される GNF ID と同じである必要があります。
MX シリーズ プラットフォーム タイプ。
-
GNFに使用するJunos OSイメージ。ジュニパーのダウンロード ページ からダウンロードできます。
ダウンロードページで、すべての製品 > Junos Node Slicing - ゲストネットワーク機能 を選択し、GNF 用の Junos イメージをダウンロードします。
VNF サーバーリソーステンプレート。
JDM で VNF を設定するには、次の手順を実行します。
scp
JDMシェルコマンドを使用して、GNF用のJunos OSノードスライシングイメージを取得し、JDMローカルディレクトリ/var/jdm-usr/gnf-imagesに配置します(GNF構成ファイルを取得するには、この手順を繰り返します)。root@jdm:~#
scp source-location-of-the-gnf-image /var/jdm-usr/gnf-images
root@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-servers
Server0: 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-functions
test-gnf
id
1
root@test-jdm-server0#
set virtual-network-functions
test-gnf
chassis-type mx2020
root@test-jdm-server0#
set virtual-network-functions
test-gnf
resource-template
2core-16g
root@test-jdm-server0#
set system vnf-license-supplement vnf-id 1 license-supplement-string RTU00023003204-01-AABBCCDDEE00-1100-01-411C
シャーシ内モデルの場合、プラットフォーム タイプ(
set virtual-network-functions
test-gnf
chassis-type mx2020
)を設定しないでください。自動的に検出されます。Junos OSリリース19.2R1以降、Junosノードスライシングは、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.conf
root@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)を参照してください。MX シリーズルーティングエンジンを設定するのと同じ方法で VNF を設定します。
シャーシ内モデルの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に1つのFPCを割り当てるJunosノードスライシング設定では、リモートGNFに割り当てられたFPCのパケット転送エンジンがファブリック上で到達不能になると、関連する抽象化されたファブリックインターフェイスがダウンします。この動作を引き起こす可能性のあるエラーの例には、PFEファブリック到達可能性エラーや、
pfe disable
アクションを引き起こすcmerrorイベントがあります(詳細については、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 4
user@router#set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf af2
user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf id 2
user@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/24
user@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 classifier and rewrite
DSCP分類子と書き換え
MPLS EXPの分類と書き換え
また、MPLS トンネルに入る IP パケットに書き換えを適用し、EXP ビットと IPv4 タイプのサービス(ToS)ビットの両方を書き換えることもできます。このアプローチは、他の通常のインターフェイスと同様に機能します。
IP v6トラフィックのDSCP v6分類子と書き換え
以下はサポートされません。
IEEE 802.1の分類と書き換え
IEEE 802.1AD(QinQ)の分類と書き換え
CoS BA分類子の詳細については、 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 インターフェイス用のリンクアップおよびリンクダウントラップ。
標準のリンクアップ/リンクダウン SNMP トラップが生成されます。デフォルトのコミュニティ文字列
jdm
が使用されます。ホスト インターフェイスのリンクアップ/リンクダウン トラップ。
標準
linkUp/linkDown
SNMPトラップが生成されます。デフォルトのコミュニティ文字列host
が使用されます。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 set
root@jdm#set snmp name name
root@jdm#set snmp description description
root@jdm#set snmp location location
root@jdm#set snmp contact user's email
root@jdm#set snmp trap-group tg-1 targets target ip address1
root@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 ファイルを設定するためにのみ使用されます。リンクアップ/ダウントラップを生成するには、次の例に示すような設定をホストサーバーの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> をネットワーク管理ステーション(NMS)の IP アドレスに置き換えます。
BSYSおよびGNFでのシャーシ構成階層
Junosノードスライシングでは、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 alarm
chassis
構成階層の下にある論理レベルまたは機能レベルのパラメーターは、FPCに関連付けられたGNFで適用する必要があります。例えば、ラインカードあたりの最大キュー数の設定は論理レベルのパラメータであるため、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 mode
user@router#set chassis fpc fpc slot flexible-queueing-mode
サブラインカードの設定とGNFへの割り当て
サブ ライン カードの概要については、 サブ ライン カードの概要を参照してください。
-
この機能は、外部サーバーベースのJunosノードスライシングセットアップで使用されるMX2010およびMX2020ルーターのMPC11Eラインカード(モデル番号:MX2K-MPC11E)に適用されます。
-
すべてのGNFの各ルーティングエンジンとBSYSが、Junos OSリリース21.2R1以降のバージョンを実行していることを確認します。
MPC11Eをさらにサブラインカード(SLC)にスライスするには、BSYSのset chassis network-slices guest-network-functions gnf
階層の下にあるfpc-slice
CLIオプションを使用する必要があります。
設定をコミットする前に、ラインカードでサポートされているすべての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 ノード スライシングの設定例を示します。
- サンプル 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-3
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 13
set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 4-7
set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4
set 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 つの構成が可能です。1つの設定例では、最初の2つのパケット転送エンジン[0-1]が1つのSLCに割り当てられ、残りのパケット転送エンジン[2-7]が他のSLCに割り当てられています。もう一方の設定例では、最後の 2 つのパケット転送エンジン [6-7] が 1 つの SLC に割り当てられ、残りのパケット転送エンジン [0-5] が他の SLC に割り当てられています。
以下の構成例は、[0-1 2-7]分割の例です。
次の例では、サブラインカードの概要ページの表MPC11EでサポートされているSLCプロファイルに示されているように、SLCのCPUコアとDRAMの割り当てが「非対称プロファイル」リソースの組み合わせの列の1つと一致しています。
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-1
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 17
set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 2-7
set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4
set 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;
}
}
}
}