Was hat sich geändert?

Veraltetes SHA-1-Kennwortformat (ACX-Serie, EX-Serie, MX-Serie, PTX-Serie, QFX-Serie, SRX-Serie, vMX und vSRX): Wir haben die Option auf Hierarchieebene entfernt, da SHA-1 für die sha1 [edit system login password format] Nur-Text-Kennwortverschlüsselung nicht mehr unterstützt wird.

Das <request-system-zeroize/> Die RPC-Antwort gibt an, wenn das Gerät den angeforderten Vorgang erfolgreich initiiert (ACX-Serie, EX-Serie, MX-Serie, PTX-Serie, QFX-Serie, SRX-Serie, vMX und vSRX)—Wenn der <request-system-zeroize/> RPC den Nullstellungsvorgang erfolgreich initiiert, gibt das Gerät das <system-zeroize-status>zeroizing re0</system-zeroize-status> Antwort-Tag aus, um anzuzeigen, dass der Prozess gestartet wurde. Wenn das Gerät den Nullstellungsvorgang nicht initiieren kann, gibt das Gerät das <system-zeroize-status> Antwort-Tag nicht aus.

In der offenen Konfiguration (ACX-Serie, EX-Serie, MX-Serie, QFX-Serie, SRX-Serie, vMX und vSRX) ist eine Änderung des Instance-Typs von default zu L3VRF nicht zulässig – DEFAULT_INSTANCE ist die primäre Instance, die ausgeführt wird, wenn in der Route set routing-optionskein bestimmter Instance-Typ konfiguriert ist. Jede Instanz, die Sie explizit konfigurieren, wird in set routing-instance r1 routing-optionsübersetzt. Das Problem tritt in der Übersetzung auf, wenn Sie den Instance-Typ DEFAULT_INSTANCE (beliebige Instance zu DEFAULT_INSTANCE) in L3VRF oder L3VRF in DEFAULT_INSTANCE ändern. Daher sind solche Änderungen nicht zulässig. Darüber hinaus kann DEFAULT_INSTANCE nur DEFAULT genannt werden, und DEFAULT ist für DEFAULT_INSTANCE reserviert, sodass solche Änderungen nicht zulässig sind.

DES-Ablaufwarnung für SNMPv3: Das Datenschutzprotokoll des Data Encryption Standard (DES) für SNMPv3 ist aufgrund schwacher Sicherheit und Anfälligkeit für kryptografische Angriffe veraltet. Konfigurieren Sie für erhöhte Sicherheit den dreifachen Datenverschlüsselungsstandard (3DES) oder den erweiterten Verschlüsselungsstandard (CFB128-AES-128 Privacy Protocol) als Verschlüsselungsalgorithmus für SNMPv3-Benutzer.

[Siehe privacy-3des und privacy-aes128.]

Änderungen beim Deaktivieren oder Löschen von Instanzen der flüchtigen Konfigurationsdatenbank (ACX-Serie, EX-Serie, MX-Serie, PTX-Serie, QFX-Serie, SRX-Serie, vMX und vSRX): Die folgenden Änderungen gelten, wenn Sie flüchtige Datenbankinstanzen in der statischen Konfigurationsdatenbank deaktivieren oder löschen:

• Wenn Sie die gesamte [edit system configuration-database ephemeral] Hierarchieebene deaktivieren, löscht das Gerät die Dateien und die zugehörigen Konfigurationsdaten für alle benutzerdefinierten kurzlebigen Instanzen. In früheren Versionen werden die Dateien und Konfigurationsdaten beibehalten. Die Konfigurationsdaten werden jedoch nicht mit der statischen Konfigurationsdatenbank zusammengeführt.

• Wenn Sie eine kurzlebige Instanz in der statischen Konfigurationsdatenbank löschen, werden auch die Konfigurationsdateien der Instanz gelöscht. In früheren Versionen wurden die Konfigurationsdateien beibehalten.

• Sie können die Dateien und die entsprechenden Konfigurationsdaten für die flüchtige Standarddatenbankinstanz löschen, indem Sie die delete-ephemeral-default Anweisung in Verbindung mit der ignore-ephemeral-default Anweisung auf der [edit system configuration-database ephemeral Hierarchieebene konfigurieren.

  [Siehe Aktivieren und Konfigurieren von Instanzen der flüchtigen Konfigurationsdatenbank.]

Änderungen an der NETCONF <edit-config> RPC-Antwort (ACX-Serie, EX-Serie, MX-Serie, PTX-Serie, QFX-Serie, SRX-Serie, vMX und vSRX): Wenn der <edit-config> Vorgang einen Fehler zurückgibt, gibt der NETCONF-Server kein <load-error-count> Element in der RPC-Antwort aus. In früheren Versionen enthält die <edit-config> RPC-Antwort das <load-error-count> Element, wenn der Vorgang fehlschlägt.

Laden von JSON-Konfigurationsdaten mit ungeordneten Listeneinträgen (ACX-Serie, EX-Serie, MX-Serie, PTX-Serie, QFX-Serie, SRX-Serie, vMX und vSRX): Das Junos-Schema erfordert, dass Listenschlüssel allen anderen gleichgeordneten Elementen innerhalb eines Listeneintrags vorangestellt und in der durch das Schema angegebenen Reihenfolge angezeigt werden. Junos-Geräte bieten zwei Optionen zum Laden von JSON-Konfigurationsdaten, die ungeordnete Listeneinträge enthalten:

• Verwenden Sie den request system convert-json-configuration Befehl Betriebsmodus, um JSON-Konfigurationsdaten mit geordneten Listeneinträgen zu erzeugen, bevor die Daten auf das Gerät geladen werden.

• Konfigurieren Sie die reorder-list-keys Anweisung auf Hierarchieebene [edit system configuration input format json] . Nachdem Sie die Anweisung konfiguriert haben, können Sie JSON-Konfigurationsdaten mit ungeordneten Listeneinträgen laden, und das Gerät ordnet die Listenschlüssel während des Ladevorgangs gemäß den Anforderungen des Junos-Schemas neu an.

• Wenn Sie die reorder-list-keys Anweisung konfigurieren, kann das Analysieren der Konfiguration durch den Ladevorgang je nach Größe der Konfiguration und Anzahl der Listen erheblich länger dauern. Daher empfehlen wir bei großen Konfigurationen oder Konfigurationen mit vielen Listen die Verwendung des request system convert-json-configuration Befehls anstelle der reorder-list-keys Anweisung.

  [Siehe json und request system convert-json-configuration]

• Veraltete Perl-Module des Junos-XML-Protokolls (ACX-Serie, EX-Serie, MX-Serie, PTX-Serie, QFX-Serie, SRX-Serie, vMX und vSRX): Der Perl-Client für das XML-Protokoll Junos steht nicht mehr zum Download zur Verfügung. Um Perl zum Verwalten von Junos-Geräten zu verwenden, verwenden Sie stattdessen die NETCONF-Perl-Bibliothek.

  [Siehe Grundlegendes zum NETCONF-Perl-Client und zu Beispielskripten.]