Dies ist der 20. Tag nach NetOpsCoding AdventCalender. Es tut mir leid, dass ich zu spät war.
Ich habe diesen Artikel vor zwei Wochen geschrieben. Versuchen Sie, mit SSH (Exscript) von Software zu Router zu wechseln
Eine der Herausforderungen bei der automatischen Konfiguration eines Routers besteht darin, dass der Syntaxanalyseprozess für die Router-CLI sehr schwierig ist. Da das Ausgabeergebnis des Befehls status check in der Router-CLI unter der Annahme erstellt wird, dass es von einer Person visuell überprüft wird, ist es subtil, wenn versucht wird, Informationen mithilfe des in der Programmiersprache bereitgestellten SSH- oder Telnel-Pakets automatisch zu extrahieren. Dies ist sehr schwierig, da Zeilenumbrüche, Leerzeichen, Sonderzeichen, Fehleranzeige usw. flexibel behandelt werden müssen.
Die Geschichte hier wird auch in @ yuyarins Blog vorgestellt. Bitte beziehen Sie sich darauf. Was wird von Netzwerkgeräten für die Betriebsautomatisierung benötigt
Um die Probleme bei der Verarbeitung von CLI-Analysen / Ausnahmen durch SSH- und Telnet-Pakete zu beseitigen, möchte ich diesmal Software mit NETCONF erstellen, die in der Automatisierung Aufmerksamkeit erregt. Um ehrlich zu sein, variiert der Implementierungsstatus je nach Hersteller, daher bin ich mir nicht sicher, ob es sofort bei der Arbeit verwendet werden kann, aber dieses Mal werde ich es als Studie versuchen.
NETCONF ist ein standardisiertes Protokoll zum Einstellen von Netzwerkgeräten und zum Erfassen von Informationen. NETCONF hat sich als Alternative zu SNMP herausgestellt, wird jedoch voraussichtlich in Netzwerkgeräten mehrerer Anbieter verwendet und hat in Kombination mit der jüngsten Automatisierung und dem SDN-Boom Aufmerksamkeit erregt.
Alle Konfigurationseinstellungen und Statusausgaben in NETCONF werden im XML-RPC-Format definiert, und die oben erwähnte Syntaxanalyse kann mit dem erforderlichen Minimum durchgeführt werden.
Als ich es vor ungefähr einem Jahr überprüfte, schien es, dass NETCONF fast in dem neuesten Betriebssystem der großen Hersteller implementiert war. Der Implementierungsstatus und die unterstützten Funktionen unterscheiden sich jedoch stark je nach Betriebssystemversion. Es wird daher empfohlen, zu überprüfen, ob NETCONF von Ihrer Version unterstützt wird.
| Manufactor | OS | Supported API |
|---|---|---|
| Cisco | IOS or IOS XE | OnePK, NETCONF |
| IOS XR | OnePK, NETCONF | |
| NX OS | OnePK, NX-API, NETCONF | |
| Juniper | JUNOS | JUNOS XML Protocol, REST API, NETCONF |
| Brocade | NetIron | REST API, NETCONF |
| Network OS | REST API, NETCONF | |
| Arista | EOS | eAPI (REST API) |
Um einen Überblick über NETCONF zu erhalten, enthält @codeout eine ausführliche Erläuterung, sodass Sie auf diesen Artikel verweisen können.
NETCONF, das ich nicht kenne Versuchen wir es mit NETCONF
Die Hintergrund- und Standardisierungstrends des Erscheinungsbilds von NETCONF- und YANG-Modellen werden in den folgenden Präsentationsmaterialien vorgestellt. JANOG36 NETCONF/YANG
Wenn Sie weitere Details erfahren möchten, lesen Sie bitte RFC. RFC6241 Network Configuration Protocol (NETCONF) RFC6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
Verwenden Sie jetzt NETCONF, um den Router einzurichten. Anfragen und Antworten werden zwischen dem NETCONF-Client und dem Router über XML-RPC ausgetauscht.
Der Implementierungsablauf war wie folgt.
--Router OS - JUNOS --Programmiersprache
Installieren Sie ncclient auf dem Server, auf dem Sie das Python-Programm schreiben.
sudo pip install ncclient
Geben Sie die Einstellungen ein, um netconf im Voraus im JUNOS-Router zuzulassen.
set system services netconf ssh
Das XML-RPC-Format des Routers wird auf der Support-Seite jedes Anbieters veröffentlicht.
NETCONF XML Management Protocol Developer Guide
In JUNOS ist es sehr praktisch, "| display xml rpc" am Ende des Befehls in der Router-CLI hinzuzufügen, da der Befehl config content und show im RPC-Anforderungsformat ausgegeben werden kann.
Verwenden Sie den von \
user1@router> show interfaces xe-0/0/0 terse | display xml rpc
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/xxxxx/junos">
<rpc>
<get-interface-information>
<terse/>
<interface-name>xe-0/0/0</interface-name>
</get-interface-information>
</rpc>
<cli>
<banner></banner>
</cli>
</rpc-reply>
Mithilfe der Befehlsfunktion in ncclient können Sie die Informationen mithilfe des Befehls show in der Router-CLI abrufen, ohne das XML-RPC-Schema zu verwenden. Führen Sie hier den Befehl aus, um den Status der Schnittstelle xe-0 / 0/0 abzurufen.
show_junos.py
#! /usr/bin/env python
# -*- coding: utf-8 -*-
from ncclient import manager
username = 'user1'
password = 'pass1'
ipv4 = '192.168.0.1'
port = 22
connection = manager.connect(host = ipv4, port = port, username = username, password = password, timeout = 20, device_params={'name':'junos'}, hostkey_verify=False )
print '1. run show command'
print '='*40
print connection.command('show interfaces xe-0/0/0 terse')
Hier ist das Ausführungsergebnis. Obwohl der Speicherplatz geringfügig abweicht, können Sie den Schnittstellenstatus mit \
Ausführungsergebnis
$ python show_junos.py
1. run show command
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<interface-information style="terse">
<physical-interface>
<name>
xe-0/0/0
</name>
<admin-status>
down
</admin-status>
<oper-status>
down
</oper-status>
</physical-interface>
</interface-information>
</rpc-reply>
Wenn die angegebene Schnittstelle nicht vorhanden ist, wird ein Fehler mit dem Tag \
Ausführungsergebnis
[t-tsuchiya@dev set_router_netconf]$ python show_junos.py
1. run show command
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<interface-information style="terse">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<source-daemon>
ifinfo
</source-daemon>
<error-message>
device xe-0/0/0 not found
</error-message>
</rpc-error>
</interface-information>
</rpc-reply>
Mit ncclient ist es übrigens auch möglich, optional ein für den Menschen leicht erkennbares Textformat auszugeben (= ähnlich dem CLI-Ergebnis auf dem Router).
show_junos.py
(Kürzung)
# print connection.command('show interfaces terse xe-0/0/0')
print connection.command('show interfaces terse xe-0/0/0', format='text')
Ausführungsergebnis
$ python show_junos.py
1. run show command
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<output>
Interface Admin Link Proto Local Remote
xe-0/0/0 down down
</output>
</rpc-reply>
Es ist besser, das XML-RPC-Format für die Verarbeitung durch eine Automatisierungssoftware und das Textformat für die visuelle Bestätigung durch den Bediener zu verwenden.
In ncclient können Sie die im aktuellen Router festgelegten Konfigurationsinformationen mit der Funktion get_config und der Funktion get abrufen. Im folgenden Beispiel werden alle im Router festgelegten Konfigurationsinformationen erfasst.
show_junos.py
#! /usr/bin/env python
# -*- coding: utf-8 -*-
from ncclient import manager
username = 'user1'
password = 'pass1'
ipv4 = '192.168.0.1'
port = 22
connection = manager.connect(host = ipv4, port = port, username = username, password = password, timeout = 20, device_params={'name':'junos'}, hostkey_verify=False )
print connection.get_config(source='running')
Ausführungsergebnis
$ python show_junos.py
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<data>
<configuration changed-seconds="1450593048" changed-localtime="2015-12-20 15:30:48 JST">
<version>xx.xx.xx</version>
<system>
<host-name>router</host-name>
<time-zone>Asia/Tokyo</time-zone>
(Unten weggelassen)
Wenn Sie die Konfiguration teilweise abrufen möchten, z. B. wenn Sie die Einstellungen der Schnittstelle anzeigen möchten, können Sie sie abrufen, indem Sie der Funktion get_config die Filteroption hinzufügen. Da zu diesem Zeitpunkt jedoch XML-RPC-Strukturinformationen erforderlich sind, muss das XML-RPC-Schema im Voraus mit dem Befehl show configration interaface xe-0 / 0/0 | display xml 'usw. auf dem Router überprüft werden. ..
show_junos.py
(Kürzung)
request_config_interface = """
<configuration>
<interfaces>
<interface>
<name>xe-0/0/0</name>
</interface>
</interfaces>
</configuration>"""
# print connection.get_config(source='running')
print connection.get_config(source='running', filter=('subtree', request_config_interface) )
Ausführungsergebnis
$ python show_junos.py
1. run show command
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<data>
<configuration commit-seconds="1450593048" commit-localtime="2015-12-20 15:30:48 JST" commit-user="user1">
<interfaces>
<interface>
<name>xe-0/0/0</name>
<disable/>
</interface>
</interfaces>
</configuration>
</data>
</rpc-reply>
Zu diesem Zeitpunkt enthält xe-0 / 0/0 nur die Einstellung "Deaktivierbar".
CLI-Bestätigungsergebnis auf dem Router
user1@router> show configuration interfaces xe-0/0/0
disable;
Jetzt erstellen wir ein Programm, das Einstellungen in die Schnittstelle eingibt. Der Zweck hier ist, die unten gezeigte IP-Adresse einzustellen und die Schnittstelle zu aktivieren.
Einstellungen, die Sie ausführen möchten
delete interfaces xe-0/0/0 disable
set interfaces xe-0/0/0 unit 0 family inet address 10.0.0.1/30
Verwenden Sie zum Festlegen der Routerkonfiguration die Funktion edit_config von ncclient. Nachdem Sie die obigen Einstellungen in das XML-RPC-Schema eingefügt haben, geben Sie sie im Argument edit_config an und führen Sie sie aus.
Beschreiben Sie das erstellte Programm. Der Programmablauf ist wie folgt. --Schritt 1. Überprüfen Sie vorab die Routerkonfiguration des Schnittstellenteils --Schritt 2. Legen Sie die Routerkonfiguration mit der Funktion edit_config als Kandidatenkonfiguration fest. --Schritt 3. Überprüfen Sie die Normalität der Kandidatenkonfiguration --Schritt 4. Anzeige der Kandidatenkonfiguration --Schritt 5. Implementierung von Commit (Menschen treffen hier Entscheidungen) --Schritt 6. Überprüfen Sie die Routerkonfiguration des Schnittstellenteils nach
set_junos.py
#! /usr/bin/env python
# -*- coding: utf-8 -*-
from ncclient import manager
username = 'user1'
password = 'pass1'
ipv4 = '192.168.0.1'
port = 22
connection = manager.connect(host = ipv4, port = port, username = username, password = password, timeout = 20, device_params={'name':'junos'}, hostkey_verify=False )
print '='*40
print 'Step 1. show running-config before commit'
print '='*40
request_config_interface = """
<configuration>
<interfaces>
<interface>
<name>xe-0/0/0</name>
</interface>
</interfaces>
</configuration>"""
print connection.get_config(source='running', filter=('subtree', request_config_interface) )
print '='*40
print 'Step 2. set config on candidate-config'
print '='*40
request_set_config_interface = """
<config>
<configuration>
<interfaces>
<interface>
<name>xe-0/0/0</name>
<enable/>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>10.0.0.1/30</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
</config>
"""
print connection.edit_config(target='candidate', config=request_set_config_interface)
print '='*40
print 'Step 3. validate candidate-config'
print '='*40
print connection.validate(source='candidate')
print '='*40
print 'Step 4. show config on candicate-config'
print '='*40
print connection.get_config(source='candidate', filter=('subtree', request_config_interface) )
print '='*40
print 'Step 5. commit'
print '='*40
print 'Do you commit? y/n'
choice = raw_input().lower()
if choice == 'y':
connection.commit()
else:
connection.discard_changes()
print '='*40
print 'Step 6. show running-config after commit'
print '='*40
print connection.get_config(source='running', filter=('subtree', request_config_interface) )
if connection:
connection.close_session()
Bei der Ausführung funktioniert es wie folgt.
Ausführungsergebnis
$ python set_junos.py
========================================
Step 1. show running-config before commit
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<data>
<configuration commit-seconds="1450688416" commit-localtime="2015-12-21 18:00:16 JST" commit-user="user1">
<interfaces>
<interface>
<name>xe-0/0/0</name>
<disable/>
</interface>
</interfaces>
</configuration>
</data>
</rpc-reply>
========================================
Step 2. set config on candidate-config
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<ok/>
</rpc-reply>
========================================
Step 3. validate candidate-config
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<commit-results>
</commit-results>
<ok/>
</rpc-reply>
========================================
Step 4. show config on candicate-config
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<data>
<configuration changed-seconds="1450688512" changed-localtime="2015-12-21 18:01:52 JST">
<interfaces>
<interface>
<name>xe-0/0/0</name>
<undocumented>
<enable/>
</undocumented>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>10.0.0.1/30</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
</data>
</rpc-reply>
========================================
Step 5. commit
========================================
Do you commit? y/n
y
========================================
Step 6. show running-config after commit
========================================
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<data>
<configuration commit-seconds="1450688535" commit-localtime="2015-12-21 18:02:15 JST" commit-user="user1">
<interfaces>
<interface>
<name>xe-0/0/0</name>
<undocumented>
<enable/>
</undocumented>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>10.0.0.1/30</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
</data>
</rpc-reply>
Ich konnte bestätigen, dass die Einstellungen auch mit der Router-CLI korrekt waren.
CLI-Bestätigungsergebnis auf dem Router
user1@router> show configuration interfaces xe-0/0/0
enable;
unit 0 {
family inet {
address 10.0.0.1/30;
}
}
Konfigurationseinstellungen werden mit der Funktion edit_config durchgeführt. Bei Erfolg wird das Ergebnis wie folgt ausgegeben.
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<ok/>
</rpc-reply>
Wenn die Konfigurationseinstellung fehlschlägt, werden die Fehlerdetails ausgegeben. (Das folgende Beispiel zeigt, wenn Sie versuchen, eine Einstellung neu zu schreiben, die nicht geändert werden kann.)
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-message>
could not set enab_disab
</error-message>
</rpc-error>
<ok/>
</rpc-reply>
Dies ist sehr hilfreich bei der Entwicklung automatisierter Programme. Wenn die Software die Router-CLI verwendet, ist es umständlich zu sagen: "Fehlermeldung erkennen-> Befehl show ausführen, um Problemteil zu finden, Syntaxanalyse-> Einen anderen Befehl show ausführen, Syntaxanalyse-> ..." Es war notwendig, die Software zu implementieren, aber es ist möglich, zum nächsten Prozess überzugehen, indem die Fehlermeldung extrahiert wird, indem nur der erforderliche Teil mit dem XML-Tag angegeben wird, und die Anzahl der Programme kann erheblich reduziert werden. können.
Es fiel mir schwer, den Befehl delete beim Erstellen des obigen Programms zu implementieren.
delete interfaces xe-0/0/0 disable;
Ursprünglich wird im XML-RPC-Schema disable wie folgt gespeichert.
<interfaces>
<interface>
<name>xe-0/0/0</name>
<disable/>
</interface>
</interfaces>
Es war mühsam, dieses \
set_junos.py
(Kürzung)
request_delete_config_interface = """
<delete-config>
<interfaces>
<interface>
<name>xe-0/0/0</name>
<disable/>
</interface>
</interfaces>
</delete-config>
"""
print connection.edit_config(target='candidate', config=request_delete_config_interface)
Ausführungsergebnis
Traceback (most recent call last):
File "set_junos.py", line 62, in <module>
print connection.edit_config(target='candidate', config=request_delete_config_interface)
File "/usr/lib/python2.7/site-packages/ncclient/manager.py", line 157, in wrapper
return self.execute(op_cls, *args, **kwds)
File "/usr/lib/python2.7/site-packages/ncclient/manager.py", line 227, in execute
raise_mode=self._raise_mode).request(*args, **kwds)
File "/usr/lib/python2.7/site-packages/ncclient/operations/edit.py", line 62, in request
node.append(validated_element(config, ("config", qualify("config"))))
File "/usr/lib/python2.7/site-packages/ncclient/xml_.py", line 117, in validated_element
raise XMLError("Element [%s] does not meet requirement" % ele.tag)
ncclient.xml_.XMLError: Element [delete-config] does not meet requirement
Lesen Sie als Nächstes ncclient-Beispielcode und verweisen Sie auf "delete =" delete = "delete". Ich habe auch die Beschreibung "" ausprobiert, aber obwohl dies funktioniert, scheint es besser zu sein, sie zu vermeiden, da sie eine RPC-Fehlerantwort zurückgibt.
set_junos.py
(Kürzung)
request_delete_config_interface = """
<config>
<configuration>
<interfaces>
<interface delete="delete">
<name>xe-1/3/0</name>
<disable/>
</interface>
</interfaces>
</configuration>
</config>
"""
print connection.edit_config(target='candidate', config=request_delete_config_interface)
Ausführungsergebnis
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-message>
could not set enab_disab
</error-message>
</rpc-error>
<ok/>
</rpc-reply>
Schließlich habe ich diesmal (?) Durch Setzen von "set enable;" anstelle von "delete disable;" vermieden. Ich denke nicht, dass es eine grundlegende Lösung ist, aber vorerst kann ich sie jetzt ohne Fehler einstellen.
#### **`set_junos.py`**
```py
(Kürzung)
request_delete_config_interface = """
<config>
<configuration>
<interfaces>
<interface>
<name>xe-1/3/0</name>
<enable/>
</interface>
</interfaces>
</configuration>
</config>
"""
print connection.edit_config(target='candidate', config=request_delete_config_interface)
Ausführungsergebnis
<rpc-reply message-id="urn:uuid:xxxxxx-xxxxxx">
<ok/>
</rpc-reply>
XML mit "enable" gesetzt-Mit Blick auf den RPC "<undocumented>..<undocumented>Details sind unbekannt, da es vom Tag umgeben ist, aber XML-Dies kann eine Einstellung sein, die in RPC nicht definiert ist.
<interfaces>
<interface>
<name>xe-1/3/0</name>
<undocumented>
<enable/>
</undocumented>
</interface>
</interfaces>
Ich habe es nicht selbst überprüft, aber im Moment scheint es einige Dinge zu geben, die selbst mit NETCONF nicht eingestellt werden können. Daher ist es besser, im Voraus zu prüfen, ob die zu automatisierende Netzwerkfunktion mit NETCONF eingestellt werden kann. ..
##XML nach Hersteller-Das RPC-Schema ist anders und schwer zu finden Ursprünglich wollte ich in diesem Blog ein Programm für JUNOS und IOS XR schreiben, aber ich gab auf, weil es zu lange dauerte, jedes XML-Schema zu untersuchen.
JANOG36 NETCONF/YANG PräsentationsmaterialSoweit ich sehen kann, scheint es in IOS XR wie folgt zu schreiben.
IOSXR_XML-RPC
<Configuration>
<InterfaceConfigurationTable>
<InterfaceConfiguration>
<Naming>
<Active>act</Active>
<InterfaceName Match="Loopback0"/>
</Naming>
<InterfaceVirtual>true</InterfaceVirtual>
<IPV4Network>
<Addresses>
<Primary>
<Address>172.16.255.1</Address>
<Netmask>255.255.255.255</Netmask>
</Primary>
</Addresses>
</IPV4Network>
</InterfaceConfiguration>
</InterfaceConfigurationTable>
</Configuration>
Selbst wenn Sie es mit dem diesmal verwendeten JUNOS-XML-Schema vergleichen, können Sie feststellen, dass es ganz anders ist.
JUNOS_XML-RPC
<configuration>
<interfaces>
<interface>
<name>xe-0/0/0</name>
<undocumented>
<enable/>
</undocumented>
<unit>
<name>0</name>
<family>
<inet>
<address>
<name>10.0.0.1/30</name>
</address>
</inet>
</family>
</unit>
</interface>
</interfaces>
</configuration>
Im Fall von JUNOS ist dies recht einfach, da es die Option "xml rpc anzeigen" gibt. Es ist jedoch etwas schmerzhaft, da sie beim Betrachten des Dokuments implementiert wird, um die XML-Struktur anderer Hersteller zu untersuchen.
Ich bin froh, dass das Industriestandardprotokoll namens NETCONF herausgekommen ist, aber derzeit ist es immer noch notwendig, ein dediziertes Programm für jedes Router-Betriebssystem zu schreiben. Das Datenmodell YANG wird derzeit auf der IETF aktiv diskutiert und implementiert, und die Datenstruktur von Routern könnte in naher Zukunft vereinheitlicht werden.
#Zusammenfassung der Verwendung von NETCONF Ich habe die Vor- und Nachteile der Verwendung von NETCONF im Moment zusammengefasst. ##Vorteil -Statusprüfungsergebnisse und Fehlerergebnisse sind XML-Da es von RPC strukturiert wird, kann die Menge an Code für die Syntaxanalyse und die Ausnahmebehandlung beim Erstellen automatisierter Software erheblich reduziert werden.
##Nachteil -Die XML-Struktur unterscheidet sich je nach Hersteller des Netzwerkgeräts. Für jedes Router-Betriebssystem ist für eine Weile ein spezielles Programm erforderlich. -XML für jeden Hersteller-Es ist schwer, RPC zu überprüfen -Gibt es Funktionen, die derzeit nicht in NETCONF eingestellt werden können? -Ich habe es selbst nicht gefunden, aber ich habe gehört, dass LACP und andere Einstellungen nicht festgelegt werden konnten.
#Schließlich Es war eine sehr gute Studie für mich, diesen Artikel zu schreiben. Beim Schreiben eines NETCONF-Programms wird mehr als beim Schreiben eines Programms XML vom Hersteller veröffentlicht-Sie müssen viele RPC-Schemainformationen und Dokumentationen der von Ihnen verwendeten Bibliotheken lesen. Im Moment gibt es nur wenige Beispielcodes, daher kann es schwierig sein.
Nutzer(=Netzbetreiber, Softwareentwickler)XML für jeden Hersteller-RPCスキーマを意識させないNutzerフレンドリなラッパーAPIが登場すると実装の敷居がかなり下がるので、ネットワーク運用自動化が一気に進むように思います。 Ich habe es schon einmal in meinem Blog vorgestelltNAPALMWenn in Zukunft eine API-Bibliothek angezeigt wird, mit der Geräte mehrerer Anbieter mit derselben Funktion eingerichtet werden können, z. B., wird die Implementierung von Software einfacher.
Letzter Artikel: Ich habe versucht, die Router-Steuerungs-API-Bibliothek NAPALM zu berühren (Übrigens ist in NAPALM nur JUNOS NETCONF und der Rest ist SSH, Hersteller-API, und es scheint, dass verschiedene Implementierungen verwendet werden.)
Das ist alles für diesen Artikel. Wir hoffen, dass es nützlich ist, wenn Sie NETCONF starten. Vielen Dank für Ihre Beziehung.
Recommended Posts