В тази статия ще ви покажа как да настроите OpenDaylight за работа с мрежово оборудване, а също така ще демонстрирам как чрез Postman и прости RESTCONF запитвания можем да управляваме това оборудване. Няма да работим с хардуер, а вместо това ще разширим малки виртуални лаборатории с един-единствен рутер с помощта на Vrnetlab повърхността Ubuntu 20.04 LTS.
Подробната настройка ще покажа първо на примера на рутера Juniper vMX 20.1R1.11, след което ще я сравним с настройката на Cisco xRV9000 7.0.2.
Съдържание
- Необходими знания
- Част 1: накратко обсъждаме OpenDaylight (по-нататък в текста ODL), Postman и Vrnetlab и защо ще ни бъдат нужни
- Част 2: описание на виртуалната лаборатория
- Част 3: настройваме OpenDaylight
- Част 4: настройваме Vrnetlab
- Част 5: с помощта на Postman свързваме виртуалния рутер (Juniper vMX) към ODL
- Част 6: получаваме и променяме конфигурацията на рутера с помощта на Postman и ODL
- Част 7: добавяме Cisco xRV9000
- Заключение
- P.S.
- Списък с литература
Необходими знания
За да не се превърне статията в дълга тетрадка, някои технически подробности оставих (с линкове към литература, където може да се прочетат).
В тази връзка, предлагам ви теми, които е добре да знаете (но почти не е задължително) преди прочитане:
- ,
- /
Част 1: малко теория
- Отворена SDN платформа за управление и автоматизация на всевъзможни мрежи, поддържана от Linux Foundation
- Java в основата
- Създаден на базата на Model-Driven Service Abstraction Level (MD-SAL)
- Използва YANG модели за автоматично генериране на RESTCONF API за мрежови устройства
Основен модул за управление на мрежата. Именно чрез него ще комуникираме с свързаните устройства. Управлява се чрез собственото си API.
По-подробно за OpenDaylight можете да прочетете .
- Инструмент за тестване на API
- Прост и удобен за използване интерфейс
В нашия случай той е интересен като средство за изпращане на REST запитвания към API на OpenDaylight. Разбира се, можете и ръчно да изпращате запитвания, но в Postman всичко изглежда много ясно и за нашите цели е подходящо както не може по-добре.
За желаещите да се задълбочат: написани са много обучителни материали за него ().
- Инструмент за разгръщане на виртуални рутери в Docker
- Поддържа: Cisco XRv, Juniper vMX, Arista vEOS, Nokia VSR и др.
- Отворен код
Много интересен, но малко известен инструмент. В нашия случай с него ще стартираме Juniper vMX и Cisco xRV9000 на обикновен Ubuntu 20.04 LTS.
Подробности за него можете да прочетете на .
Част 2: лабораторна работа
В рамките на този туториал ще настроим следната система:
Как работи това
- Juniper vMX създава се в Docker контейнер (средствата Vrnetlab) и функционира като обикновен виртуален рутер.
- ODL свързан с рутера и позволява управлението му.
- Postman стартиран на отделна машина и чрез него изпращаме команди ODL: за свързване/отстраняване на рутера, промяна на конфигурацията и т.н.
Коментар към устройството на системата
Juniper vMX и ODL изискват доста много ресурси за стабилната си работа. Само vMX иска 6 Gb оперативна памет и 4 ядра. Затова беше взето решение да се преместят всички "тежки" натоварвания на отделна машина (Heulett Packard Enterprise MicroServer ProLiant Gen8, Ubuntu 20.04 LTS). Рутерът, разбира се, не "лети", но за малки експерименти производителността е достатъчна.
Част 3: настройваме OpenDaylight
Актуалната версия ODL по време на написването на статията — Magnesium SR1
1) Инсталираме Java OpenJDK 11 (за по-подробна инсталация )
ubuntu:~$ sudo apt install default-jdk2) Намираме и изтегляме свежа версия ODL
3) Разархивираме изтегления архив
4) Преминаваме в получената директория
5) Стартираме ./bin/karaf
На този етап ODL трябва да се стартира и ще се озовем в конзолата (За достъп от вън е необходим порт 8181, който ще използваме по-късно).
След това инсталираме ODL Features, предназначени за работа с протоколи NETCONF и RESTCONF. За целта в конзолата ODL изпълняваме:
opendaylight-user@root> feature:install odl-netconf-topology odl-restconf-allНа този етап най-простата настройка ODL е завършена. (По-подробна информация може да се прочете ).
Част 4: настройваме Vrnetlab
Подготовка на системата
Преди инсталацията Vrnetlab е необходимо да инсталирате необходимите пакети за работа. Например, , , :
ubuntu:~$ sudo apt update
ubuntu:~$ sudo apt -y install python3-bs4 sshpass make
ubuntu:~$ sudo apt -y install git
ubuntu:~$ sudo apt install -y
apt-transport-https ca-certificates
curl gnupg-agent software-properties-common
ubuntu:~$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
ubutu:~$ sudo add-apt-repository
"deb [arch=amd64] https://download.docker.com/linux/ubuntu
$(lsb_release -cs)
stable"
ubuntu:~$ sudo apt update
ubuntu:~$ sudo apt install -y docker-ce docker-ce-cli containerd.ioИнсталация на Vrnetlab
За инсталация Vrnetlab клонираме съответния репозиторий от github:
ubuntu:~$ cd ~
ubutu:~$ git clone https://github.com/plajjan/vrnetlab.gitПреминаваме в директорията vrnetlab:
ubuntu:~$ cd ~/vrnetlabТук можете да видите всички скриптове, необходими за стартиране. Обърнете внимание, че за всеки тип рутер е създадена съответна директория:
ubuntu:~\/vrnetlab$ ls
CODE_OF_CONDUCT.md config-engine-lite openwrt vr-bgp
CONTRIBUTING.md csr routeros vr-xcon
LICENSE git-lfs-repo.sh sros vrnetlab.sh
Makefile makefile-install.include topology-machine vrp
README.md makefile-sanity.include veos vsr1000
ci-builder-image makefile.include vmx xrv
common nxos vqfx xrv9kСъздаваме изображение на маршрутизатора
Всеки маршрутизатор, който се поддържа Vrnetlab, има уникална процедура за настройка. В случая Juniper vMX ни е достатъчно да копираме .tgz архива с маршрутизатора (може да го свалим от ) в директорията vmx и да изпълним командата , затова потребителите на Windows трябва да инсталират Cygwin или да се справят сами с Visual Studio и библиотеките.:
ubuntu:~$ cd ~\/vrnetlab\/vmx
ubuntu:~$ # Копираме в тази директория .tgz архива с маршрутизатора
ubuntu:~$ sudo makeСъздаване на образ vMX ще отнеме около 10-20 минути. Самото време да отидете да си направите кафе!
Защо толкова дълго, ще попитате вие?
Превод на автора на този въпрос:
"Това е свързано с факта, че при първото стартиране VCP (Control Plane) прочита конфигурационния файл, който определя дали ще работи като VRR VCP в vMX. По-рано това стартиране се извършваше по време на стартиране на Docker, но това означаваше, че VCP винаги се рестартираше веднъж, преди виртуалният маршрутизатор да стане достъпен, което водеше до дълго време за зареждане (около 5 минути). Сега първото стартиране на VCP се извършва по време на изграждането на Docker изображението, и тъй като изграждането на Docker не може да бъде стартирано с параметъра —privileged, това означава, че qemu работи без хардуерно ускорение KVM и поради това, изграждането отнема значително повече време. По време на този процес се извеждат много логове, така че поне ще можете да видите какво се случва. Мисля, че дългото изграждане не е толкова страшно, защото изображението създаваме веднъж, а стартираме множество."
След това ще можем да видим изображението на нашия маршрутизатор в Docker:
ubuntu:~$ sudo docker image list
REPOSITORY TAG IMAGE ID CREATED SIZE
vrnetlab\/vr-vmx 20.1R1.11 b1b2369b453c 3 weeks ago 4.43GB
debian stretch 614bb74b620e 7 weeks ago 101MBСтартираме контейнера vr-vmx
Стартира се с командата:
ubuntu:~$ sudo docker run -d --privileged --name jun01 b1b2369b453cСлед това можем да видим информация за активните контейнери:
ubuntu:~$ sudo docker container list
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
120f882c8712 b1b2369b453c "\/launch.py" 2 minutes ago Up 2 minutes (unhealthy) 22\/tcp, 830\/tcp, 5000\/tcp, 10000-10099\/tcp, 161\/udp jun01Свързваме се с маршрутизатора
IP адресът на мрежовия интерфейс на маршрутизатора може да бъде получен следната команда:
ubuntu:~$ sudo docker inspect --format '{{.NetworkSettings.IPAddress}}' jun01
172.17.0.2По подразбиране, Vrnetlab създава на маршрутизатора на потребителя vrnetlab/VR-netlab9.
Свързваме се с помощта на ssh:
ubuntu:~$ ssh vrnetlab@172.17.0.2
Аутентичността на хоста '172.17.0.2 (172.17.0.2)' не може да бъде установена.
ECDSA ключовият отпечатък е SHA256:g9Sfg/k5qGBTOX96WiCWyoJJO9FxjzXYspRoDPv+C0Y.
Сигурни ли сте, че искате да продължите с връзката (да/не/[отпечатък])? да
Внимание: Постоянно добавен '172.17.0.2' (ECDSA) в списъка с известни хостове.
Парола:
--- JUNOS 20.1R1.11 Ядро 64-битово JNPR-11.0-20200219.fb120e7_buil
vrnetlab> show version
Модел: vmx
Junos: 20.1R1.11С това настройката на маршрутизатора е приключила.
Препоръките за инсталация за маршрутизатори от различни производители могат да бъдат намерени на в съответните директории.
Част 5: Postman — свързване на маршрутизатора с OpenDaylight
Инсталиране на Postman
За инсталация е достатъчно да изтеглите приложението .
Свързване на маршрутизатора с ODL
Нека създадем PUT заявка:
- Строка със заявка:
PUT http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01 - Тяло на заявката (вкладка Body):
jun01 172.17.0.2 22 vrnetlab VR-netlab9 false jun01_cache - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияи име/парола: admin/admin. Това е необходимо за достъп до ODL:
- На вкладката Headers е нужно да добавите два заглавия:
- Accept application/xml
- Content-Type application/xml
Нашата заявка е формирана. Изпращаме. Ако всичко е настроено правилно, трябва да получим статус "201 Created":
Какво прави тази заявка?
Създаваме node в рамките на ODL с параметри на истинския маршрутизатор, до който искаме да получим достъп.
xmlns="urn:TBD:params:xml:ns:yang:network-topology"
xmlns="urn:opendaylight:netconf-node-topology"Това са вътрешни пространства на имената XML (XML пространство на име) съгласно които той създава node. ODL Следователно, името на маршрутизатора — това е
node-id , адреса на маршрутизатора —и т.н. host Най-интересният ред — последният.
Schema-cache-directory създава директория, в която се изтеглят всички файлове YANG Schema на свързания маршрутизатор. Можете да ги намерите в $ODL_ROOT/cache/jun01_cache Проверяваме връзката на маршрутизатора.
GET http://10.132.1.202:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/
Нека създадем ИЗИСКВАНЕ заявка:
- Строка със заявка:
и име/парола: admin/admin. - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства.
Изпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства. на свързания маршрутизатор. Можете да ги намерите в:
Коментар: За да видите последното, в моя случай трябваше да изчакам около 10 минути след изпълнението PUT, докато всичко YANG схема се експортира на ODL. До този момент при изпълнение на тази ИЗИСКВАНЕ заявка ще бъде изведено следното:
Изтриваме рутера
Нека създадем DELETE заявка:
- Строка със заявка:
DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01 - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства.
Част 6: Променяме конфигурацията на рутера
Получаваме конфигурация
Нека създадем ИЗИСКВАНЕ заявка:
- Строка със заявка:
GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/ - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства.
Изпращаме. Трябва да получим статус "200 OK" и конфигурацията на рутера:
Създаваме конфигурация
Като пример ще създадем следната конфигурация и ще я променим:
protocols {
bgp {
disable;
shutdown;
}
}Нека създадем POST заявка:
- Строка със заявка:
POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols - Тяло на заявката (вкладка Body):
- На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства. - На вкладката Headers е нужно да добавите два заглавия:
- Accept application/xml
- Content-Type application/xml
След изпращането трябва да получим статус "204 No Content"
За да проверим, че конфигурацията е променена, можем да използваме предишната заявка. Но за примера ще създадем още една, която ще изведе информация само за конфигурираните на рутера протоколи.
Нека създадем ИЗИСКВАНЕ заявка:
- Строка със заявка:
GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства.
След изпълнението на заявката ще видим следното:
Променяме конфигурацията
Ще променим информацията за протокола BGP. След нашите действия тя ще изглежда по следния начин:
protocols {
bgp {
disable;
}
}Нека създадем PUT заявка:
- Строка със заявка:
PUT http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols - Тяло на заявката (вкладка Body):
- На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства. - На вкладката Headers е нужно да добавите два заглавия:
- Accept application/xml
- Content-Type application/xml
Използвайки предишната ИЗИСКВАНЕ заявка, виждаме промените:
Изтриваме конфигурацията
Нека създадем DELETE заявка:
- Строка със заявка:
DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства.
При повикване на ИЗИСКВАНЕ при заявката с информация за протоколите ще видим следното:
Допълнение:
За да променим конфигурацията, не е необходимо да изпращаме тялото на заявката във формат XML. Това може да се направи и в формат JSON.
Например, в заявката PUT за промяна на конфигурацията ще заменим тялото на заявката с:
{
"junos-conf-protocols:protocols": {
"bgp": {
"description" : "Changed in postman"
}
}
}Не забравяйте да промените заглавките на вкладката Headers на:
- Accept application/json
- Content-Type application/json
След изпращането ще получим следния резултат (Отговорът гледаме, използвайки ИЗИСКВАНЕ запрос):
Част 7: добавяме Cisco xRV9000
Какво знаем за Juniper, да поговорим за Cisco!
Намерих xRV9000 версия 7.0.2 (страшилище, на което му трябват 8GB RAM и 4 ядра. Не е наличен публично, затова се обърнете към ) — и ще го стартираме.
Стартиране на контейнера
Процесът на създаване на Docker контейнер не се различава особено от Juniper. Подобно, качваме .qcow2 файл с маршрутизатора в директорията, съответстваща на неговото име, (в този случай xrv9k) и изпълняваме командата make docker-image.
След няколко минути виждаме, че образът е създаден:
ubuntu:~$ sudo docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
vrnetlab/vr-xrv9k 7.0.2 54debc7973fc 4 hours ago 1.7GB
vrnetlab/vr-vmx 20.1R1.11 b1b2369b453c 4 weeks ago 4.43GB
debian stretch 614bb74b620e 7 weeks ago 101MBСтартираме контейнера:
ubuntu:~$ sudo docker run -d --privileged --name xrv01 54debc7973fcСлед известно време виждаме, че контейнерът е стартирал:
ubuntu:~$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
058c5ecddae3 54debc7973fc "/launch.py" 4 hours ago Up 4 hours (healthy) 22/tcp, 830/tcp, 5000-5003/tcp, 10000-10099/tcp, 161/udp xrv01Свързваме се по ssh:
ubuntu@ubuntu:~$ ssh vrnetlab@172.17.0.2
Парола:
RP/0/RP0/CPU0:ios#show version
Mon Jul 6 12:19:28.036 UTC
Cisco IOS XR Software, Version 7.0.2
Copyright (c) 2013-2020 by Cisco Systems, Inc.
Информация за изграждане:
Създадено от : ahoang
Създаден на : Fri Mar 13 22:27:54 PDT 2020
Създаден хост : iox-ucs-029
Работно пространство : /auto/srcarchive15/prod/7.0.2/xrv9k/ws
Версия : 7.0.2
Местоположение : /opt/cisco/XR/packages/
Марка : 7.0.2
cisco IOS-XRv 9000 () процесор
Системно време на работа е 3 часа 22 минутиСвързваме маршрутизатора с OpenDaylight
Добавянето става точно както с образа vMX. Просто трябва да сменим имената.
PUT заявка:
След известно време извикваме ИЗИСКВАНЕ запрос, за да проверим, че всичко е свързано:
Променяме конфигурацията
Настройваме следната конфигурация:
!
маршрутизатор ospf LAB
mpls ldp auto-config
!Нека създадем POST заявка:
- Строка със заявка:
POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf - Тяло на заявката (вкладка Body):
{ "processes": { "process": [ { "process-name": "LAB", "default-vrf": { "process-scope": { "ldp-auto-config": [ null ] } } } ] } } - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства. - На вкладката Headers е нужно да добавите два заглавия:
- Accept application/json
- Content-Type application/json
След неговото изпълнение трябва да получим статус "204 No Content".
Нека проверим какво сме получили.
За целта ще създадем ИЗИСКВАНЕ заявка:
- Строка със заявка:
GET http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства.
След изпълнението трябва да видим следното:
За да изтрием конфигурацията, използваме DELETE:
- Строка със заявка:
DELETE http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/xrv01/yang-ext:mount/Cisco-IOS-XR-ipv4-ospf-cfg:ospf - На вкладката Authorization е необходимо да зададете параметъра
Основна аутентификацияИзпращаме. Трябва да получим статус "200 OK" и списък на всички поддържани устройства.
Заключение
Както можете да видите, процедурите за свързване на Cisco и Juniper с OpenDaylight не се различават — това открива доста широка възможност за творчество. Започвайки от управлението на конфигурациите на всички компоненти на мрежата и стигайки до създаването на собствени мрежови политики.
В този туториал представих най-простите примери за взаимодействие с мрежово оборудване с помощта на OpenDaylight. Несъмнено, заявките от посочените примери могат да бъдат значително усложнени и да се конфигурират цели услуги с един клик на мишката — всичко е ограничено само от вашето въображение.
Продължение следва…
P.S.
Ако вече знаете всичко това или, обратно, преминахте и ви плени ODL, то ви препоръчвам да погледнете в посока разработка на приложения на контролера ODL. Можете да започнете. .
Успешни експерименти!
Списък на литературата
- / Brian Linkletter
- OpenDaylight Cookbook / Mathieu Lemay, Alexis de Talhouet и др.
- Network Programmability with YANG / Benoît Claise, Loe Clarke, Jan Lindblad
- Learning XML, Second Edition / Erik T. Ray
- Effective DevOps / Jennifer Davis, Ryn Daniels
Източник: habr.com
