その他のMC-LAG構成
MXシリーズルーターのマルチシャーシリンクアグリゲーションにおけるIRB上のアクティブ-アクティブブリッジングおよびVRRPの設定
ここでは、MC-LAG(マルチシャーシ リンク アグリゲーション)におけるアクティブ/アクティブ ブリッジングと IRB 上の VRRP の設定について説明します。
MC-LAG の設定
MC-LAGは、LAG(ロジカルリンクアグリゲーショングループ)で構成され、次のように[ editinterfaces aeX] 階層の下に設定されます。
[edit] interfaces { ae0 { encapsulation ethernet-bridge; multi-chassis-protection { peer 10.10.10.10 { interface ge-0/0/0; } } aggregated-ether-options { mc-ae { mode active-active; # see note below } } } }
mode active-active ステートメントは、カプセル化が ethernet-bridge または extended-vlan-bridge の場合にのみ有効です。
mode ステートメントを使用して、MC-LAG がアクティブ/スタンバイかアクティブ/アクティブかを指定します。ICCP接続がUPでICLが起動した場合、スタンバイに設定されたルーターが、ピアと共有されるマルチシャーシの集合型イーサネットインターフェイスを起動します。
物理インターフェイス レベルで マルチシャーシ保護 を使用することは、論理インターフェイス レベルでの設定を削減する方法です。
ae0の下にn+1個の論理インターフェイスがある場合、ae0.0からae0.nまで、ge-0/0/0の下にもn+1個の論理インターフェイスがあり、ge-0/0/0.0からge-0/0/0.nまで、各ge-0/0/0論理インターフェイスはae0論理インターフェイスの保護リンクになります。
ブリッジドメインに、異なる冗長性グループに属するマルチシャーシ集約型イーサネット論理インターフェイスを含めることはできません。
シャーシ間リンク保護リンクの設定
ICL-PL(シャーシ間リンク保護リンク)は、アクティブリンクの 1 つでリンク障害(MC-LAG トランク障害など)が発生した場合に冗長性を提供します。ICL-PLは集合型イーサネットインターフェイスです。2 つのピア間では ICL-PL を 1 つだけ設定できますが、ピア間で複数の MC-LAG を設定できます。
ICL-PL は、MC-LAG-1 のインターフェイス ae0.0 を保護するためにインターフェイス ge-0/0/0.0 が使用されることを前提としています。
[edit] interfaces { ae0 { .... unit 0 { multi-chassis-protection { peer 10.10.10.10 { interface ge-0/0/0.0; } .... } ... } } }
保護インターフェイスは、geやxeなどのイーサネットタイプのインターフェイス、または集合型イーサネット(ae)インターフェイスのいずれかです。
複数シャーシの設定
トップレベル階層は、次のように、マルチシャーシ関連の設定を指定するために使用されます。
[edit] multi-chassis { multi-chassis-protection { peer 10.10.10.10 { interface ge-0/0/0; } } }
この例では、ピアの一部でもあるすべてのマルチシャーシ集合型イーサネットインターフェイスのマルチシャーシ保護インターフェイスとして、インターフェイスge-0/0/0を指定しています。これは、物理インターフェイス レベルと論理インターフェイス レベルで保護を指定することで上書きできます。
サービス ID の設定
サービスを提供する PE ルーターのセット内のサービスに対して、ネットワーク全体で同じ固有の設定を設定する必要があります。次の例に示す階層のレベルでサービスIDを設定できます。
グローバル設定(デフォルトの論理システム)
switch-options { service-id 10; } bridge-domains { bd0 { service-id 2; } } routing-instances { r1 { switch-options { service-id 10; } bridge-domains { bd0 { service-id 2; } } } }
論理システム
ls1 { switch-options { service-id 10; } routing-instances { r1 { switch-options { service-id 10; } } } }
ブリッジ ドメインごとのサービス名の使用はサポートされていません。
ブリッジレベルのサービス ID は、ピア間で関連するブリッジ ドメインをリンクするために必要であり、同じ値で設定する必要があります。 service-id 値は、すべてのブリッジング インスタンスとルーティング インスタンス、およびピア間で名前空間を共有します。したがって、サービス ID の値が重複することは、これらのエンティティ間で許可されません。
ブリッジ ドメイン レベルのサービス ID は、タイプが単一でない VLAN ブリッジ ドメインには必須です。サービスIDは、VLAN識別子(VID)が定義されたブリッジドメインではオプションです。後者でサービス ID が定義されていない場合は、そのルーティング インスタンスのサービス ID 設定から取得されます。
マルチシャーシ集合型イーサネットインターフェイスを含むブリッジドメインを含むこのデフォルトルーティング インスタンス(またはその他のルーティング インスタンス)が設定されている場合、含まれているブリッジドメインに特定のサービスIDが設定されているかどうかに関係なく、グローバルレベルの switch-optionsサービスID numberを設定する必要があります。
図 1 のサンプル図では、ネットワーク ルーティング インスタンス N1 と N2 は、どちらも同じサービス ID 用であり、N1 と N2 の両方で同じサービス ID を使用して構成されています。数字の代わりに名前文字列を使用することはサポートされていません。
次の設定制限が適用されます。
サービスIDは、マルチシャーシ集約型イーサネットインターフェイスが設定されていて、マルチシャーシ集約型イーサネット論理インターフェイスがブリッジドメインの一部である場合に設定する必要があります。この要件は強制されます。
単一のブリッジ ドメインを 2 つの冗長グループ ID に対応することはできません。
図2では、2つのマルチシャーシ集約型イーサネットインターフェイスからの論理インターフェイスで構成されるブリッジドメインを設定し、それらを別の冗長グループIDにマッピングすることができますが、これはサポートされていません。サービスは、サービスを提供する冗長性グループと1対1でマッピングする必要があります。この要件は強制されます。
図2:2つのマルチシャーシ集合型イーサネットインターフェイスからの論理インターフェイスを持つブリッジドメイン
マルチシャーシの集合型イーサネット設定を表示するには、 show interfaces mc-ae コマンドを使用します。詳細については、 CLIエクスプローラーを参照してください。
アクティブ-アクティブ MC-LAG の IGMP スヌーピングの設定
マルチキャストソリューションを機能させるには、以下を設定する必要があります。
マルチシャーシ保護リンクは、ルーターに面したインターフェイスとして設定する必要があります。
[edit bridge-domain bd-name] protocols { igmp-snooping { interface ge-0/0/0.0 { multicast-router-interface; } } }
この例では、ge-0/0/0.0 は ICL インターフェイスです。
multichassis-lag-replicate-state
ステートメントオプションは、そのブリッジ ドメインのmulticast-snooping-options
ステートメントの下で設定する必要があります。
アクティブ/アクティブ MC-LAG によるスヌーピングは、非プロキシ モードでのみサポートされます。
MC-LAGアクティブ-アクティブモードでのIGMPスヌーピングの設定
bridge-domain
ステートメントのservice-id
オプションを使用して、MX240ルーター、MX480ルーター、MX960ルーター、QFXシリーズスイッチでマルチシャーシ集合型イーサネット構成を指定できます。
service-id
ステートメントは、非単一 VLAN タイプのブリッジ ドメイン(none、all、または vlan-id-tags:dual)には必須です。このステートメントは、VID が定義されたブリッジ ドメインではオプションです。
ブリッジレベルの
service-id
は、ピア間で関連するブリッジ ドメインをリンクするために必要であり、同じ値で設定する必要があります。service-id
値は、すべてのブリッジングおよびルーティング インスタンス、およびピア間で名前空間を共有します。したがって、これらのエンティティ間で重複するservice-id
値は許可されません。ブリッジ サービス ID の変更は致命的と見なされ、ブリッジ ドメインが変更されます。
この手順では、レプリケーション機能を有効または無効にすることができます。
MC-LAGアクティブ-アクティブモードでIGMPスヌーピングを設定するには:
MXシリーズルーターでのMC-LAGインターフェイスの手動および自動リンクスイッチオーバーの設定
アクティブ/スタンバイモードのマルチシャーシリンクアグリゲーション(MC-LAG)トポロジーでは、リンクスイッチオーバーはアクティブノードがダウンした場合にのみ発生します。アクティブ/スタンバイ モードで MC-LAG インターフェイスを設定し、自動的に優先ノードに戻るようにすることで、このデフォルト動作を上書きできます。この設定では、アクティブノードが使用可能な場合でも、優先ノードへのリンクスイッチオーバーをトリガーできます。例えば、PE1 と PE2 という 2 つのノードがあるとします。PE1 はアクティブ モードで設定され、優先ノードになり、PE2 はアクティブ/スタンバイ モードに設定されます。PE1で障害が発生した場合、PE2がアクティブノードになります。ただし、PE1 が再び利用可能になるとすぐに、自動リンク スイッチオーバーがトリガーされ、PE2 がアクティブであっても制御が PE1 に戻されます。
リンク スイッチオーバーは、リバーティブと非リバーティブの 2 つのモードで設定できます。リバーティブ モードでは、 request interface mc-ae switchover
動作モード コマンドを使用して、リンクのスイッチオーバーが自動的にトリガーされます。非リバーティブ モードでは、リンクの切り替えはユーザーが手動でトリガーする必要があります。また、指定したタイマーが期限切れになったときに自動または手動のスイッチオーバーをトリガーする復帰時間を設定することもできます。
ICCP(Inter-Chassis Control Protocol)および非リバーティブ スイッチカバー モードを使用してアクティブ/スタンバイ設定で設定された 2 つの MC-LAG デバイスが、両方の MC-LAG の集合型イーサネット インターフェイスで設定され、両方の MC-AE インターフェイスがレイヤ 2 回線ローカル スイッチング設定でリンクされている場合、
request interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)
を入力してスイッチオーバーを実行することをお勧めします。MC-LAGデバイスの集合型イーサネットインターフェイスの1つだけ上の動作モードコマンド。このコマンドは、アクティブ ノードとして設定されているMC-LAGデバイスでのみ発行できます([edit interfaces aeX aggregated-ether-options mc-ae]
階層レベルでstatus-control active
ステートメントを使用)。非リバーティブ スイッチオーバー モードでは、MC-LAG メンバー リンク障害が原因で MC-LAG インターフェイスがスタンバイ ステートに遷移するときに使用する保持時間を選択します 他の MC-LAG インターフェイスがアクティブ ステートに移行した場合、スタンバイ ステートの MC-LAG は、アクティブ ステートの MC-LAG に障害が発生してアクティブ ステートに戻るまで、その状態のままになります。
MC-LAGの両方の集合型イーサネットインターフェイスでスイッチオーバーを実行すると、レイヤー2回線のローカルスイッチング設定により、一方の集約イーサネットインターフェイスでスイッチオーバーが発生すると、もう一方の集約イーサネットインターフェイスでもスイッチオーバーがトリガーされます。このようなシナリオでは、両方の集合型イーサネットインターフェイスがスタンバイ状態に移行し、その後アクティブ状態に戻ります。そのため、MC-LAG内の両方の集合型イーサネットインターフェイスで同時にスイッチオーバーを実行することはできません。
MC-LAGインターフェイスをリバーティブスイッチオーバーモードに設定した場合、レイヤー2回線設定とVPLS機能はサポートされません。リバーティブまたは非リバーティブ スイッチオーバー機能を設定できます(2 つの MC-LAG デバイスがアクティブ/スタンバイ セットアップで設定されている(1 つのデバイスは
status-control standby
ステートメントを使用してアクティブ ノードとして設定され、もう 1 つのデバイスは 階層レベルで ステートメントを使用してstatus-control active
スタンバイ ノードとして設定[edit interfaces aeX aggregated-ether-options mc-ae]
。アクティブノードとして設定されたMC-LAGデバイスでのみ、request interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)
操作モードコマンドを入力してスイッチオーバーを実行できます。
MC-LAGインターフェイスでリンクスイッチオーバーメカニズムを設定するには、次の手順に従います。
show interfaces mc-ae revertive-info
コマンドを使用して、スイッチオーバー設定情報を表示できます。
LACP機能が制限されたMC-LAGリンクまたはインターフェイスを強制的に起動させる
MC-LAGネットワークでは、リンクアクセス制御プロトコル(LACP)が設定されていないMC-LAGクライアントリンクはダウンしたままになり、MC-LAGスイッチからアクセスできません。
LACP機能が制限されたクライアントデバイスがMC-LAGネットワーク上で稼働し、アクセス可能になっていることを確認するには、デバイスの適切な階層レベルで force-up
ステートメントを使用して、MC-LAGスイッチ上の集合型イーサネットリンクまたはインターフェイスの1つを稼働するように設定します。
[edit interfaces interface-name aggregated-ether-options lacp
]
MC-LAG スイッチの フォースアップ 機能は、アクティブ モードまたはスタンバイ モードのいずれかで設定できます。ただし、重複トラフィックとパケットのドロップを防ぐために、MC-LAGスイッチの1つの集約されたイーサネットリンクでのみフォースアップ機能を設定します。フォースアップ機能が設定されたMC-LAGスイッチ上で複数の集合型イーサネットリンクがアップしている場合、デバイスはLACPポートIDとポート優先度に基づいてリンクを選択します。プライオリティが最も低いポートが優先されます。プライオリティが同じポートが2つある場合は、ポートIDが最も低いポートが優先されます。
force-up
オプションは、QFX10002スイッチではサポートされていません。
QFX5100 スイッチでは、Junos OS リリース 14.1X53-D10 以降の MC-LAG スイッチの LACP(リンク アグリゲーション制御プロトコル)でフォースアップ機能を設定できます。
LACP が MC-LAG ネットワークで部分的に起動する場合(つまり、MC-LAG スイッチの 1 つで起動し、他の MC-LAG スイッチで起動しない場合)、フォースアップ機能は無効になります。
拡張MC-LAGおよびレイヤー3 VXLANトポロジー向けARPおよびネットワーク検出プロトコルエントリーの増加
- ARP および Network Discovery Protocol(NDP)エントリの増加の必要性を理解する
- IPv4トランスポートを使用した拡張MC-LAG向けARPおよびネットワーク検出プロトコルエントリの増加
- IPv6トランスポートを使用した拡張MC-LAGのARPおよびネットワーク検出プロトコルエントリの増加
- IPv4テナントトラフィック用のエッジルーティングブリッジ(ERB)または中央ルーティングブリッジ(CRB)のスパインのボーダーリーフ用のEVPN-VXLANゲートウェイのARPの増加
- IPv6テナントトラフィック用のエッジルーティングブリッジ(ERB)または中央ルーティングブリッジ(CRB)のスパインのボーダーリーフ用のEVPN-VXLANゲートウェイのARPおよびネットワーク検出プロトコルエントリーの増加
ARP および Network Discovery Protocol(NDP)エントリの増加の必要性を理解する
拡張MC-LAGおよびレイヤー3 VXLANシナリオを改善するために、ARPおよびNDPエントリー数が256,000に増加しました。
次に、ARP と NDP エントリの増加が必要となる拡張 MC-LAG およびレイヤー 3 VXLAN のシナリオを示します。
シャーシごとに多数のメンバーを含む多数の MC-AE インターフェイスを持つ拡張 MC-LAG トポロジー。
折り畳みのないスパインリーフ トポロジーでは、リーフ デバイスはレイヤー 2 ゲートウェイとして動作して VXLAN 内のトラフィックを処理し、スパイン デバイスはレイヤー 3 ゲートウェイとして動作し、IRB インターフェイスを使用して VXLAN 間のトラフィックを処理します。
このシナリオでは、スパインレベルでARPおよびNDPエントリーの増加が必要です。
レイヤー 2 とレイヤー 3 の両方のゲートウェイとして動作するリーフ デバイス。
このシナリオでは、トランジット スパイン デバイスはレイヤー 3 ルーティング機能のみを提供し、ARP および NDP エントリーの増加はリーフ レベルでのみ必要とされます。
IPv4トランスポートを使用した拡張MC-LAG向けARPおよびネットワーク検出プロトコルエントリの増加
IPv4 トランスポートを使用して ARP および NDP エントリーの数を増やすには、以下の手順に従います。最適なパフォーマンスを得るには、この手順で提供された値を使用することをお勧めします。
IPv6トランスポートを使用した拡張MC-LAGのARPおよびネットワーク検出プロトコルエントリの増加
IPv6 トランスポートを使用して ARP および Network Discovery Protocol エントリの数を増やすには、次の手順に従います。最適なパフォーマンスを得るには、この手順で提供された値を使用することをお勧めします。
IPv4テナントトラフィック用のエッジルーティングブリッジ(ERB)または中央ルーティングブリッジ(CRB)のスパインのボーダーリーフ用のEVPN-VXLANゲートウェイのARPの増加
IPv4 テナント トラフィックを使用して ARP エントリー数を増やすには、次の手順を実行します。最適なパフォーマンスを得るには、この手順で提供された値を使用することをお勧めします。
IPv6テナントトラフィック用のエッジルーティングブリッジ(ERB)または中央ルーティングブリッジ(CRB)のスパインのボーダーリーフ用のEVPN-VXLANゲートウェイのARPおよびネットワーク検出プロトコルエントリーの増加
IPv4 および IPv6 テナント トラフィックを使用して ARP および Network Discovery Protocol エントリの数を増やすには、次の手順を実行します。最適なパフォーマンスを得るには、この手順で提供された値を使用することをお勧めします。
設定の同期とコミット
あるデバイス(Junos Fusion Provider Edge、Junos Fusion Enterprise、EXシリーズ スイッチ、MXシリーズ ルーター)から別のデバイスに設定変更を伝達、同期、およびコミットするには、以下のタスクを実行します。
- 設定を同期させるためのデバイスの設定
- グローバル設定グループの作成
- ローカル設定グループの作成
- リモート設定グループの作成
- ローカル、リモート、およびグローバル設定の適用グループの作成
- 設定の同期とコミット
- リモートデバイス接続のトラブルシューティング
設定を同期させるためのデバイスの設定
設定を同期するデバイスのホスト名または IP アドレスと、設定の同期を管理するユーザーのユーザー名と認証の詳細を設定します。さらに、デバイスが設定を同期できるように、NETCONF接続を有効にします。SCP(セキュア コピー プロトコル)は、デバイス間で設定を安全にコピーします。
たとえば、スイッチAという名前のローカルデバイスがあり、スイッチB、スイッチC、およびスイッチDという名前のリモートデバイスと設定を同期させる場合、スイッチAでスイッチB、スイッチC、およびスイッチDの詳細を構成する必要があります。
構成の詳細を指定するには:
グローバル設定グループの作成
グローバル コンフィギュレーション グループ、ローカルおよびリモート デバイスを作成します。
グローバル設定グループを作成するには、次の手順に従います。
設定の出力は次のとおりです。
groups { global { when { peers [ Switch A Switch B Switch C Switch D ]; } interfaces { ge-0/0/0 { unit 0 { family inet { address 10.1.1.1/8; } } } ge-0/0/1 { ether-options { 802.3ad ae0; } } ge-0/0/2 { ether-options { 802.3ad ae1; } } ae0 { aggregated-ether-options { lacp { active; } } unit 0 { family ethernet-switching { interface-mode trunk; vlan { members v1; } } } } ae1 { aggregated-ether-options { lacp { active; system-id 00:01:02:03:04:05; admin-key 3; } mc-ae { mc-ae-id 1; redundancy-group 1; mode active-active; } } unit 0 { family ethernet-switching { interface-mode access; vlan { members v1; } } } } } switch-options { service-id 1; } vlans { v1 { vlan-id 100; l3-interface irb.100; } } } }
ローカル設定グループの作成
ローカルデバイスのローカル設定グループを作成します。
ローカル設定グループを作成するには:
設定の出力は次のとおりです。
groups { local { when { peers Switch A; } interfaces { ae1 { aggregated-ether-options { mc-ae { chassis-id 0; status-control active; events { iccp-peer-down { prefer-status-control-active; } } } } } irb { unit 100 { family inet { address 10.10.10.3/8 { arp 10.10.10.2 l2-interface ae0.0 mac 00:00:5E:00:53:00; } } } } } multi-chassis { multi-chassis-protection 10.1.1.1 { interface ae0; } } } }
リモート設定グループの作成
リモートデバイス用のリモート設定グループを作成します。
リモート設定グループを作成するには:
設定の出力は次のとおりです。
groups { remote { when { peers Switch B Switch C Switch D } interfaces { ae1 { aggregated-ether-options { mc-ae { chassis-id 1; status-control standby; events { iccp-peer-down { prefer-status-control-active; } } } } } irb { unit 100 { family inet { address 10.10.10.3/8 { arp 10.10.10.2 l2-interface ae0.0 mac 00:00:5E:00:53:00; } } } } } multi-chassis { multi-chassis-protection 10.1.1.1 { interface ae0; } } } }
ローカル、リモート、およびグローバル設定の適用グループの作成
設定の変更がローカル、リモート、グローバル設定グループに継承されるように、適用グループを作成します。最初の設定グループの設定データが後続の設定グループのデータよりも優先される継承順に、設定グループを一覧表示します。
設定グループを適用して commit peers-synchronize
コマンドを発行すると、ローカルとリモートの両方のデバイスで変更がコミットされます。いずれかのデバイスにエラーが発生した場合、エラーメッセージが発行され、コミットは終了します。
設定グループを適用するには:
[edit] user@switch# set apply-groups [<name of global configuration group> <name of local configuration group> <name of remote configuration group>]
例えば:
[edit] user@switch# set apply-groups [ global local remote ]
設定の出力は次のとおりです。
apply-groups [ global local remote ];
設定の同期とコミット
コンフィギュレーションの同期実行時に commit at <"string">
コマンドはサポートされません。
ローカル(または要求側)デバイスで peers-synchronize
ステートメントを有効にすると、デフォルトでその設定がリモート(または応答側)デバイスにコピーされ、ロードされます。または、 commit peers-synchronize
コマンドを発行することもできます。
デバイス間で
peers-synchronize
アクションを自動的に実行するには、ローカル(または要求)でcommit
コマンドを設定します。[edit] user@switch# set system commit peers-synchronize
設定の出力は次のとおりです。
system { commit { peers-synchronize; } }
ローカル(または要求側)デバイスで
commit peers-synchronize
コマンドを発行します。[edit] user@switch# commit peers-synchronize
リモートデバイス接続のトラブルシューティング
問題
形容
commit
コマンドを発行すると、次のエラー メッセージが発行されます。
root@Switch A# commit
error: netconf: could not read hello error: did not receive hello packet from server error: Setting up sessions for peer: 'Switch B' failed warning: Cannot connect to remote peers, ignoring it
このエラーメッセージは、ローカルデバイスとリモートデバイス間にNETCONF接続の問題があることを示しています。
解決
解決
リモートデバイス(スイッチB)へのSSH接続が機能していることを確認します。
root@Switch A# ssh root@Switch B
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is 21:e8:5a:58:bb:29:8b:96:a4:eb:cc:8a:32:95:53:c0. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:1 ECDSA host key for Switch A has changed and you have requested strict checking. Host key verification failed.
エラーメッセージは、SSH接続が機能していないことを示しています。
/root/.ssh/known_hosts:1 ディレクトリのキー エントリを削除し、スイッチ B への接続を再試行します。
root@Switch A# ssh root@Switch B
The authenticity of host 'Switch B (10.92.76.235)' can't be established. ECDSA key fingerprint is 21:e8:5a:58:bb:29:8b:96:a4:eb:cc:8a:32:95:53:c0. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'Switch A,10.92.76.235' (ECDSA) to the list of known hosts. Password: Last login: Wed Apr 13 15:29:58 2016 from 192.168.61.129 - JUNOS 15.1I20160412_0929_dc-builder Kernel 64-bit FLEX JNPR-10.1-20160217.114153_fbsd-builder_stable_10 At least one package installed on this device has limited support. Run 'file show /etc/notices/unsupported.txt' for details.
スイッチ B への接続に成功しました。
スイッチ B からログアウトします。
root@Switch B# exit
logout Connection to Switch B closed.
SSH 経由の NETCONF が動作していることを確認します。
root@Switch A# ssh root@Switch B -s netconf
logout Connection to st-72q-01 closed.
Password:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
ログメッセージは、SSH経由のNETCONFが成功したことを示しています。
エラーメッセージにSSH経由のNETCONFが成功しなかったことが示された場合は、
set system services netconf ssh
コマンドを発行してSSH経由のNETCONFを有効にします。同期する設定グループを作成します(まだ作成していない場合)。
show | compare
コマンドを発行すると、設定グループが作成されているかどうかを確認できます。root@Switch A# show | compare
commit
コマンドを発行します。root@Switch A# commit
[edit chassis] configuration check succeeds commit complete {master:0}[edit]
ログメッセージには、コミットが成功したことが示されています。