Cet article a été publié en tant que jour 8 du calendrier de l'avent Cisco Systems Japan 2019 par des volontaires Cisco.
--Publiez un script Python qui automatise les tâches de routine dans la gestion du réseau à l'aide de commutateurs tact
0:16 Demo1: Interface Shut / No shut ... LED éteinte / allumée avec PoE fermé / non fermé 0:51 Demo2: Changement de Vlan ... Commutation entre Vlan99 et Vlan1 2:00 Demo3: Sauvegarde de la configuration ... Sauvegarde de la configuration du commutateur sur le serveur FTP 3:27 Démo4: Notification à SNS ... Publier des notifications de travail dans WebEx Teams
Raspberry Pi
Sept scripts Python sont disponibles sur Raspai. L'un (template_switch.py) sert à accepter l'entrée de chaque bouton et à exécuter l'un des six scripts. Le reste du script est dirigé vers l'API Cisco DNA Center, en fonction de son utilisation prévue (un seul poste directement dans WebEx Teams).
pi@raspberrypi:~/code $ uname -a
Linux raspberrypi 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux
pi@raspberrypi:~/code $ ls -la
36 au total
drwxr-xr-x 2 root root 4096 7 décembre 03:11 .
drwxr-xr-x 21 pi pi 4096 6 décembre 01:29 ..
-rwxr-xr-x 1 racine racine 845 6 décembre 01:30 teams.py
-rwxr-xr-x 1 racine racine 1285 5 décembre 23:08 templateConfigbackup.py
-rwxr-xr-x 1 racine racine 1246 4 décembre 04:42 templateNoShut.py
-rwxr-xr-x 1 racine racine 1243 4 décembre 04:41 templateShut.py
-rwxr-xr-x 1 racine racine 1369 6 décembre 00:45 templateVlan1.py
-rwxr-xr-x 1 racine racine 1370 6 décembre 00:46 templateVlan99.py
-rwxr-xr-x 1 racine racine 1894 6 décembre 06:22 template_switch.py
Connectez les six boutons (Tact Switch) entre les six GPIO (entrée / sortie à usage général) et GND, puis connectez les éléments suivants Permet à l'entrée d'être acceptée par le code dans. Pour le placement des broches, effectuez une recherche appropriée ou suivez le numéro de modèle de Raspeye. Référence: disposition des broches du Raspberry Pi 2/3 B (40 broches)
template_switch.py
# -*- coding: utf-8 -*-
import RPi.GPIO as GPIO
import time
import sys
import os
if __name__ == "__main__":
pin1 = 11
pin2 = 13
pin3 = 15
pin4 = 29
pin5 = 31
pin6 = 37
GPIO.setmode(GPIO.BOARD)
GPIO.setup(pin1, GPIO.IN, pull_up_down = GPIO.PUD_UP)
GPIO.setup(pin2, GPIO.IN, pull_up_down = GPIO.PUD_UP)
GPIO.setup(pin3, GPIO.IN, pull_up_down = GPIO.PUD_UP)
GPIO.setup(pin4, GPIO.IN, pull_up_down = GPIO.PUD_UP)
GPIO.setup(pin5, GPIO.IN, pull_up_down = GPIO.PUD_UP)
GPIO.setup(pin6, GPIO.IN, pull_up_down = GPIO.PUD_UP)
print("En attente du bouton...")
print("-- 6(noshut) - 5(shut) - 4(vlan1) - 3(vlan99) - 2(backup) - 1(message) --")
while True:
button1 = GPIO.input(pin1)
button2 = GPIO.input(pin2)
button3 = GPIO.input(pin3)
button4 = GPIO.input(pin4)
button5 = GPIO.input(pin5)
button6 = GPIO.input(pin6)
cmd = ""
if button1 == False:
print("Bottun1 - teams.py")
cmd = "python ./teams.py '##Je travaille dessus en ce moment##'"
elif button2 == False:
print("Button2 - templateConfigbackup.py")
cmd = "python ./templateConfigbackup.py"
elif button3 == False:
print("Button3 - templateVlan99.py")
cmd = "python ./templateVlan99.py"
elif button4 == False:
print("Button4 - templateVlan1.py")
cmd = "python ./templateVlan1.py"
elif button5 == False:
print("Button5 - templateShut.py")
cmd = "python ./templateShut.py"
elif button6 == False:
print("Button6 - templateNoShut.py")
cmd = "python ./templateNoShut.py"
if cmd != "":
ret = os.popen(cmd).readline().strip()
print(ret)
time.sleep(1)
time.sleep(0.1)
GPIO.cleanup()
Cisco DNA Center Le périphérique cible (deux Catalyst 9300 dans cet exemple) doit être pré-enregistré auprès du Cisco DNA Center. (Procédure omise)
archive
log config
logging enable
logging size 1000
notify syslog contenttype plaintext
hidekeys
path ftp://<ipaddress>/ConfigBackup/Cat9300_demo1
!
ip ftp username <ftpusername>
ip ftp password <ftppassword>
Parmi plusieurs, nous utiliserons l'API de "Deploy Template". Dans l'exemple de script ci-dessous, il est inclus dans un pour plus de clarté, comme l'acquisition de jetons et la génération de chemin. (Habituellement, je pense que les fichiers doivent être importés séparément pour plus d'efficacité et de maintenabilité.)
templateNoShut.py
import requests
import json
DNAC_URL = 'https://<dnac_ip_address>/api'
DNAC_USER = '<username>'
DNAC_PASSWORD = '<password>'
def get_token(url, user, password):
api_call = '/system/v1/auth/token'
url += api_call
response = requests.post(url=url, auth=(user, password), verify=False).json()
return response["Token"]
def deploy(token):
headers = {
'X-Auth-Token': token,
'content-type': 'application/json'
}
url = "https://<dnac_ip_address>/api/v1/template-programmer/template/deploy"
payload = {
"templateId": "<template_id>",
"forcePushTemplate": "true",
"targetInfo": [
{
#Puisqu'il n'y a qu'un seul port auquel le voyant est connecté, ce script spécifie un seul commutateur.
"id": "<device_ip>",
#La spécification des paramètres commute ici entre fermé et non fermé.
"params": {
"shutnoshut": "no shut"
},
"type": "MANAGED_DEVICE_IP"
}
],
}
response = requests.post(url=url, data=json.dumps(payload), headers=headers, verify=False)
print(response)
if __name__ == '__main__':
token = get_token(DNAC_URL, DNAC_USER, DNAC_PASSWORD)
deploy(token)
templateVlan99.py
import requests
import json
DNAC_URL = 'https://<dnac_ip_address>/api'
DNAC_USER = '<username>'
DNAC_PASSWORD = '<password>'
#Avec le réglage de plusieurs unités, dans cet exemple, nous exécutons pour deux unités
ips = ["<ip_address_1>", "<ip_address_2>"]
def get_token(url, user, password):
api_call = '/system/v1/auth/token'
url += api_call
response = requests.post(url=url, auth=(user, password), verify=False).json()
return response["Token"]
def deploy(token, ipaddr):
headers = {
'X-Auth-Token': token,
'content-type': 'application/json'
}
url = "https://<dnac_ip_address>/api/v1/template-programmer/template/deploy"
payload = {
"templateId": "<template_id>",
"forcePushTemplate": "true",
"targetInfo": [
{
"id": ipaddr,
#S'il existe plusieurs variables dans le modèle, spécifiez-les également ici.
#La valeur de Vlan et le nom de l'interface sont spécifiés.
"params": {
"vlan": "99",
"interface": "range GigabitEthernet 1/0/6-10"
},
"type": "MANAGED_DEVICE_IP"
}
],
}
response = requests.post(url=url, data=json.dumps(payload), headers=headers, verify=False)
print(response)
if __name__ == '__main__':
token = get_token(DNAC_URL, DNAC_USER, DNAC_PASSWORD)
for ip in ips:
deploy(token, ip)
templateConfigbackup.py
import requests
import json
DNAC_URL = 'https://<dnac_ip_address>/api'
DNAC_USER = '<username>'
DNAC_PASSWORD = '<password>'
#Avec le réglage de plusieurs unités, dans cet exemple, nous exécutons pour deux unités
ips = ["<ip_address_1>", "<ip_address_2>"]
def get_token(url, user, password):
api_call = '/system/v1/auth/token'
url += api_call
response = requests.post(url=url, auth=(user, password), verify=False).json()
return response["Token"]
def deploy(token, ipaddr):
headers = {
'X-Auth-Token': token,
'content-type': 'application/json'
}
url = "https://10.71.130.53/api/v1/template-programmer/template/deploy"
payload = {
#Il s'agit du modèle le plus simple du modèle qui ne gère pas les variables.
#Nous avons préparé deux types de méthodes de sauvegarde de configuration et nous les présentons.
#"templateId": "<template_id_1>",
"templateId": "<template_id_2>",
"forcePushTemplate": "true",
"targetInfo": [
{
"id": ipaddr,
"type": "MANAGED_DEVICE_IP"
}
],
}
response = requests.post(url=url, data=json.dumps(payload), headers=headers, verify=False)
print(response)
if __name__ == '__main__':
token = get_token(DNAC_URL, DNAC_USER, DNAC_PASSWORD)
for ip in ips:
deploy(token, ip)
Je suis épuisé, alors j'envoie juste un message fixe. Sur simple pression d'un bouton, quelqu'un effectuera de nombreux contrôles de communication, documentera les résultats et les affichera ...
teams.py
# -*- coding: utf-8 -*-
import requests
import sys
ACCESS_TOKEN = "<access_token>"
ROOM_ID = "<room_id>"
YOUR_MESSAGE = sys.argv[1]
#Création d'en-tête
def setHeaders():
accessToken_hdr = 'Bearer ' + ACCESS_TOKEN
spark_header = {'Authorization': accessToken_hdr, 'Content-Type': 'application/json; charset=utf-8'}
return spark_header
#Postez un message dans l'espace
def postMsg(the_header,roomId,message):
message = '{"roomId":"' + roomId + '","text":"' + message +'"}'
uri = 'https://api.ciscospark.com/v1/messages'
resp = requests.post(uri, data=message, headers=the_header)
print resp
header=setHeaders()
postMsg(header,ROOM_ID,YOUR_MESSAGE)
Simplicité ultime. Que diriez-vous d'une tâche commune en appuyant simplement sur un bouton?
Si vous vous connectez à Ansible à partir d'un commutateur tactile ou que vous accédez directement à l'appareil à l'aide de Netconf / Restconf, vous n'avez pas besoin de quelque chose comme Cisco DNA Center. Si vous disposez d'un petit nombre de périphériques ou si le contenu du modèle est fortement personnalisé pour les opérations locales, vous ne souhaiterez peut-être pas avoir de contrôleur.
En revanche, les personnes qui ne sont pas en charge des réseaux en premier lieu, comme un grand nombre de commutateurs (des centaines), ne veulent pas absorber la différence de fonctionnement de chaque appareil avec un script, ne veulent pas garantir l'évolutivité et la disponibilité avec un serveur d'exécution de script, etc. Si vous souhaitez lier des opérations réseau avec des applications, ou dans de tels cas, il est préférable d'avoir un contrôleur.
Pour une large gamme de zones nivelées (tout le LAN, tout le DC, etc.) via le contrôleur, et pour les zones avec de nombreuses opérations locales et personnalisées (telles que la connexion HQ WAN), directement sans passer par le contrôleur. Il est bon de l'utiliser correctement. Vous serez libéré des soucis liés à la maintenance et au fonctionnement du playbook.
Saviez-vous grâce à l'exemple de script que la gestion des périphériques réseau est masquée? Il a été confirmé que ce qui était dit à la page 15 de la diapositive ci-dessous était réalisé dans une certaine mesure même avec des opérations très familières (fermeture / non fermeture, changement de vlan, etc.).
[Interop Tokyo 2016] Introduction du contrôleur SDN APIC-EM pour LAN / WAN
Bien sûr, la fonctionnalité elle-même a évolué pour être davantage basée sur l'intention, et en termes de Cisco DNA Center, des API telles que Assurance, SD-Access et Application Policy vous donneront une idée de l'avenir.
Cisco DNA Center est une plate-forme de gestion de réseau qui se positionne en tant que contrôleur de stratégie basé sur l'intention + plate-forme de données, mais elle peut également être utilisée comme contrôleur de macro qui transforme la configuration (CLI) qui est utilisée en continu comme l'éditeur de modèle. À partir d'un script de niveau supérieur ou d'une autre application, il semble que les tâches courantes peuvent être automatisées en se liant au modèle CLI et en accédant à l'API.
Bien que vous puissiez tout faire avec des logiciels, de nombreux magasins en réseau adorent le matériel ~~. Il doit y avoir eu un moment où tout le monde était enthousiasmé par le câblage du rack. D'autre part, il est devenu une mission importante de connecter le réseau et le système supérieur à l'aide de l'API de l'infrastructure réseau complètement ouverte, et de connecter l'automatisation liée à un autre système à l'aide de l'API. .. Les ingénieurs réseau capables de connecter du matériel, des logiciels et des applications métier devraient avoir un bel avenir.
Donc, c'était une bonne pause pour jouer avec la planche à pain et le cavalier de temps en temps.
Il existe plusieurs possibilités!
Les opinions exprimées sur ce site et les commentaires correspondants sont les opinions personnelles de l'affiche et non les opinions de Cisco. Le contenu de ce site est fourni à titre informatif uniquement et n'est pas destiné à être approuvé ou exprimé par Cisco ou toute autre partie. En publiant sur ce site Web, chaque utilisateur est seul responsable du contenu de toutes les informations publiées, liées ou autrement téléchargées, et décline Cisco de toute responsabilité relative à l'utilisation de ce site Web. Je suis d'accord.