リリース21.4R1の変更点

SVLBNH 情報の表示のサポート:コマンドを使用して指定された ESI およびルーティング インスタンスのVXLANトンネルエンドポイント情報を表示するときに、共有 VXLAN ロードバランシング ネクスト ホップ(SVLBNH)情報を表示 show ethernet-switching vxlan-tunnel-end-point esi esi-identifier esi-identifier instance instance svlbnh できるようになりました。

EVPN タイプ 8 ルートでの最大応答時間のサポート—Junos OS では、EVPN タイプ 8 ルート メッセージの最大応答時間(MRT)属性フィールドがサポートされるようになりました。この属性は、EVPN向けIGMPおよびMLDプロキシーのバージョン13のIETFドラフトで定義されています。MRT は、IGMP メッセージに応答するまでの待機時間を同期するために使用されます。MRT をサポートしていない以前のバージョンの Junos OS を実行しているデバイスとの互換性を維持するには、 set protocols evpn leave-sync-route-oldstyle .

[evpn.] を参照してください。

show Ethernet switching flood extensiveの出力—show ethernet-switching flood extensiveの出力に、EVPN-VXLANネットワーク内の仮想イーサネットおよびWANメッシュグループの正しいネクストホップタイプがユニリストとして表示されるようになりました。以前は、show ethernet-switching flood extensiveの出力で、ネクストホップタイプがコンポジットと誤って識別されていました。

EVPN タイプ 6 と EVPN タイプ 7 のルートでイーサネット タグ ID を 0 に設定—VLAN バンドルと VLAN ベースのサービスでは、Junos OS は RFC 7432 に従って、EVPN タイプ 6 と EVPN タイプ 7 のルートでイーサネット タグ ID(VLAN ID)をゼロに自動設定するようになりました。以前のリリースでは、Junos OS はイーサネット タグ ID として VNI(VXLAN ネットワーク識別子)を使用していました。

VNIをイーサネットタグIDとして使用するデバイスと相互運用するため、 set routing-instances routing-instance-name protocols evpn smet-etag-carry-vid.

ジュニパーアジャイルライセンシング(EX2300-VC、EX3400-VC、EX4300-VC、EX4400-24MP、EX4400-48MP、PTX10003、PTX10016、QFX5130-32CD、QFX5110-32Q、QFX5110-48S、QFX5120-48T、QFX5210-64C、QFX5200、QFX5220)—このリリース以降、Juniper Agile License Managerは非推奨となります。ジュニパーアジャイルライセンシングポータルを使用して、デバイスのライセンスをアクティブ化、インストール、管理および監視できます。

[ 『ジュニパーアジャイルライセンシングガイド』を参照]

show chassis pic コマンドの機能強化(Junos|Evo)— show chassis pic コマンドの実行時に、光学に関する追加情報を表示できるようになりました。出力に、次の追加フィールドが表示されます。 MSA バージョン: 指定された光インターフェイスが準拠しているマルチソース契約(MSA)バージョン。サポートされる値は、SFP+/SFP28 — SFF-8472 (バージョン 9.3 - 12.3)、QSFP+/QSFP28 — SFF 8363 (バージョン 1.3 - 2.10)、および QSFP-DD — CMIS 3.0、4.0、5.0 です。以前は、show chassis pic コマンドでは、この追加フィールドは表示されませんでした。

[show chassis pic.]を参照してください。

veriexec-check オプションの名前変更 - request system malware-scan コマンドの veriexec-check オプションを integrity-check に変更しました。このアップデートには、機能的な変更は含まれていません。integrity-checkオプションを使用して、Juniper Malware Removal Toolで整合性メカニズムが有効になっているかどうかを確認できます。

「 request system malware-scan」を参照してください。

ジュニパーアジャイルライセンシング(EX2300-VC、EX3400-VC、EX4300-VC、EX4400-24MP、EX4400-48MP、PTX10003、PTX10016、QFX5130-32CD、QFX5110-32Q、QFX5110-48S、QFX5120-48T、QFX5210-64C、QFX5200、QFX5220)—このリリース以降、Juniper Agile License Managerは非推奨となります。ジュニパーアジャイルライセンシングポータルを使用して、デバイスのライセンスをアクティブ化、インストール、管理および監視できます。

[ 『ジュニパーアジャイルライセンシングガイド』を参照]

複数の FTI(フレキシブル トンネル インターフェイス)トンネルを設定する場合、送信元と宛先アドレスのペアは、同じトンネル カプセル化タイプの FTI トンネル間でのみ一意である必要があります。この PR 以前は、送信元アドレスと宛先アドレスのペアは、トンネルのカプセル化タイプに関係なく、すべての FTI トンネルで一意である必要がありました。

コマンドライン引数が Python アクション スクリプトに渡される方法の変更(ACXシリーズ、EXシリーズ、MXシリーズ、PTXシリーズ、QFXシリーズ、SRXシリーズ、vMX、vSRX)— カスタム YANG RPC が Python アクション スクリプトを呼び出し、コマンドライン引数をスクリプトに渡すと、デバイスは 1 文字の引数名にハイフン(-)をプレフィックスとして付け、複数文字の引数名に 2 つのハイフンをプレフィックスとして付けます。プレフィックスを使用すると、標準のコマンドライン解析ライブラリを使用して引数を処理できます。以前のリリースでは、デバイスは変更されていない引数名をスクリプトに渡します。「Junos OS および を実行するデバイス上での YANG RPC のアクション スクリプトの作成 」を参照してください。

DHCP のリンク選択サポート—DHCP リレーがオプション 82 にサブオプション 5 を追加できるようにする、edit forwarding-options dhcp-relay relay-option-82 階層レベルで link-selection ステートメントを導入しました。サブオプション 5 では、DHCP プロキシ クライアントとリレー エージェントが、特定の IP アドレス範囲とスコープから特定のサブネットの IP アドレスを要求できます。このリリースより前は、DHCPリレーが更新DHCPプロセス中にパケットをドロップし、DHCPサーバーがDHCP更新メッセージを確認する宛先としてリーフのアドレスを使用していました。

[ relay-option-82.] を参照してください。

この設定は、YANG データ モデル(ACXシリーズ、EXシリーズ、MXシリーズ、PTXシリーズ、QFXシリーズ、SRXシリーズ、vMX、vSRX)の identityref タイプのノードに対して定義されたアイデンティティ値のみを受け入れます。対応する YANG データ モデルに identityref タイプのステートメントを設定すると、デバイスは定義されたアイデンティティ値(アイデンティティ ステートメントで定義)のみを有効な入力として受け入れます。以前のリリースでは、デバイスは、定義されていない ID 値も受け入れます。

snmp mib walk コマンドの機能拡張(PTXシリーズ、QFXシリーズ、EXシリーズ、MXシリーズ、SRXシリーズ)— ipv6IfOperStatus フィールドには、インターフェイスの現在の動作状態が表示されます。noIfIdentifier(3)状態は有効なインターフェイス識別子がインターフェイスに割り当てられていないことを示します。通常、この状態は、リンクローカル インターフェイス アドレスが重複アドレスの検出に失敗したことを示します。インターフェイスで「Duplicate Address Detected」エラーフラグを指定すると、新しい値(noIfIdentifier(3))が表示されます。以前は、snmp mib walk コマンドは新しい値(noIfIdIdentifier(3))を表示しませんでした。

SNMPv3 インフォームの contextEngineID の変更 (PTXシリーズ、QFXシリーズ、ACXシリーズ、EXシリーズ、MXシリーズ、SRXシリーズ— これで、SNMPv3 INFORMS の contextEngineID が Junos デバイスのローカル エンジン ID に設定されるようになりました。以前のリリースでは、SNMPv3 INFORMS の contextEngineID は remote engine-id に設定されていました。

「 Junos OSでサポートされているSNMP MIBとトラップ」を参照してください。

この設定は、YANG データ モデル(ACXシリーズ、EXシリーズ、MXシリーズ、PTXシリーズ、QFXシリーズ、SRXシリーズ、vMX、vSRX)の identityref タイプのノードに対して定義されたアイデンティティ値のみを受け入れます。対応する YANG データ モデルに identityref タイプのステートメントを設定すると、デバイスは定義されたアイデンティティ値(アイデンティティ ステートメントで定義)のみを有効な入力として受け入れます。以前のリリースでは、デバイスは、定義されていない ID 値も受け入れます。

RPD_OSPF_LDP_SYNCメッセージがログに記録されませんか?すべての Junos OS および Junos OS Evolved デバイスでは、LDP セッションがダウンすると、LDP と OSPF 間の同期が失われます。同期が失われた後、インターフェイスが 3 分以上ホールドダウン状態になると、警告レベルのシステム ログ メッセージが送信されます。このメッセージは、メッセージ・ファイルとトレース・ファイルの両方に表示されます。ただし、edit protocols ospf area area id interface interface name階層レベルでldp-synchronizationhold-timeを3分未満で明示的に設定した場合、システムログメッセージは記録されません。メッセージは 3 分後に印刷されます。

リソース パス間で一貫性を持たせるために、リソース パス /mpls/signalling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-countersip-addr='address'/state/countersname='name'/out-pkts/ を /mpls/signaling-protocols/segment-routing/aggregate-sid-counters/aggregate-sid-countersip-addr='address'/state/countersname='name'/ に変更します。リーフ「out-pkts」はパスの終尾から削除され、「signalling」は「signaling」に変更されます(「l」が1つ)。