その他の MC-LAG 構成
MX シリーズ ルーターのマルチシャーシ リンク アグリゲーションにおけるアクティブ/アクティブ ブリッジングと IRB 上の VRRP の設定
以下のセクションでは、マルチシャーシ リンク アグリゲーション(MC-LAG)におけるアクティブ/アクティブ ブリッジングと IRB 上の VRRP の設定について説明します。
MC-LAG の設定
MC-LAGはLAG(論理リンクアグリゲーショングループ)で構成され、[ edit interfaces 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
}
}
}
}
モードのアクティブ -アクティブ ・ステートメントは、カプセル化が イーサネット・ ブリッジまたは 拡張VLANブリッジである場合にのみ有効です。
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 つのピア間で複数の MC-LAG を設定できますが、2 つのピア間で設定できる ICL-PL は 1 つだけです。
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が設定されているかどうかに関係なく、グローバルレベルの スイッチオプションのservice-id numberを設定する必要があります。
図 1 に示すサンプル 図では、同じサービス ID のネットワーク ルーティング インスタンス N1 と N2 が、N1 と N2 の両方で同じサービス ID で構成されています。数値の代わりに名前文字列を使用することはサポートされていません。
次の構成制限が適用されます。
サービス ID は、マルチシャーシ集約型イーサネットインターフェイスが設定されており、マルチシャーシ集約型イーサネット論理インターフェイスがブリッジドメインの一部である場合に設定する必要があります。この要件は強制されます。
1 つのブリッジ ドメインが 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スヌーピングの設定
ステートメントのオプションservice-idを使用してbridge-domain、MX240ルーター、MX480ルーター、MX960ルーター、QFXシリーズスイッチ上のマルチシャーシ集約型イーサネット構成を指定できます。
この
service-idステートメントは、非単一VLANタイプのブリッジドメイン(なし、すべて、または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)および非復帰スイッチカバー モードを使用してアクティブ/スタンバイ セットアップで設定された 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台のデバイスは ステートメントを使用してアクティブノードとして設定され、もう1台のデバイスは 階層レベルで ステートメント
[edit interfaces aeX aggregated-ether-options mc-ae]を使用してstatus-control standbystatus-control activeスタンバイノードとして設定されます)。アクティブノードとして設定されたMC-LAGデバイスでのみ、request interface mc-ae switchover (immediate mcae-id mcae-id | mcae-id mcae-id)運用モードコマンドを入力してスイッチオーバーを実行できます。
MC-LAGインターフェイスでリンクスイッチオーバーメカニズムを設定するには:
コマンドを使用して、 show interfaces mc-ae revertive-info スイッチオーバーの設定情報を表示できます。
MC-LAGリンクまたはLACP機能が限定されたインターフェイスを強制的に立ち上げる
MC-LAG ネットワークでは、LACP(リンク アクセス コントロール プロトコル)が設定されていない MC-LAG クライアント リンクはダウンしたままになり、MC-LAG スイッチからアクセスできません。
LACP機能が限定されているクライアントデバイスがMC-LAGネットワーク上でアクセス可能であることを確認するには、デバイスの適切な階層レベルでステートメント force-up を使用して、MC-LAGスイッチ上の集約されたイーサネットリンクまたはインターフェイスの1つが稼働するように設定します。
[edit interfaces interface-name aggregated-ether-options lacp][edit interfaces interface-name ether-options 802.3ad lacp]
MC-LAG スイッチの フォースアップ 機能は、アクティブ モードまたはスタンバイ モードで設定できます。ただし、トラフィックの重複やパケット ドロップを防ぐため、強制アップ機能は MC-LAG スイッチの 1 つの集約されたイーサネット リンクでのみ設定します。フォースアップ機能が設定されたMC-LAGスイッチ上で複数の集約型イーサネットリンクが立ち上がっている場合、デバイスはLACPポートIDとポートプライオリティに基づいてリンクを選択します。プライオリティが最も低いポートが優先されます。プライオリティが同じ 2 つのポートの場合は、ポート ID が最も小さいポートが優先されます。
オプションは force-up 、QFX10002スイッチではサポートされていません。
QFX5100スイッチでは、Junos OSリリース14.1X53-D10以降、MC-LAGスイッチのリンクアグリゲーション制御プロトコル(LACP)でフォースアップ機能を設定できます。
MC-LAG ネットワークで LACP が部分的に起動する場合(つまり、MC-LAG スイッチの 1 つで起動し、他の MC-LAG スイッチでは起動しない場合)、フォースアップ機能は無効になります。
拡張 MC-LAG およびレイヤー 3 VXLAN トポロジーの ARP およびネットワーク検出プロトコル エントリーの増加
- ARP および NDP(ネットワーク検出プロトコル)エントリー数の増加の必要性を理解する
- IPv4トランスポートを使用した拡張MC-LAGのARPおよびネットワークディスカバリプロトコルエントリーの増加
- IPv6トランスポートを使用した拡張MC-LAGのARPおよびネットワークディスカバリプロトコルエントリーの増加
- エッジルーティングブリッジ(ERB)のボーダーリーフまたはIPv4テナントトラフィックの中央ルーティングブリッジ(CRB)のスパイン向けのEVPN-VXLANゲートウェイのARPの増加
- エッジルーティングブリッジ(ERB)のボーダーリーフまたはIPv6テナントトラフィックの中央ルーティングブリッジ(CRB)のスパイン用のEVPN-VXLANゲートウェイのARPおよびネットワーク検出プロトコルエントリの増加
ARP および NDP(ネットワーク検出プロトコル)エントリー数の増加の必要性を理解する
ARP および NDP エントリー数は 256,000 に増加し、拡張 MC-LAG およびレイヤー 3 VXLAN シナリオが改善されました。
以下に、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 およびネットワーク検出プロトコルのエントリの数を増やす。最適なパフォーマンスを得るには、この手順で提供される値を使用することをお勧めします。
エッジルーティングブリッジ(ERB)のボーダーリーフまたはIPv4テナントトラフィックの中央ルーティングブリッジ(CRB)のスパイン向けのEVPN-VXLANゲートウェイのARPの増加
IPv4 テナント トラフィックを使用して ARP エントリの数を増やすには、次の手順を実行します。最適なパフォーマンスを得るには、この手順で提供される値を使用することをお勧めします。
エッジルーティングブリッジ(ERB)のボーダーリーフまたはIPv6テナントトラフィックの中央ルーティングブリッジ(CRB)のスパイン用のEVPN-VXLANゲートウェイのARPおよびネットワーク検出プロトコルエントリの増加
IPv4 および IPv6 テナント トラフィックを使用して ARP およびネットワーク検出プロトコル エントリの数を増やすには、次の手順を実行します。最適なパフォーマンスを得るには、この手順で提供される値を使用することをお勧めします。
設定の同期とコミット
あるデバイス(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 コマンドを発行することもできます。
commitローカル(または要求側)で コマンドを設定して、デバイス間でアクションを自動的に実行しますpeers-synchronize。[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]ログ メッセージには、コミットが成功したことが示されます。