Образ linux для eve ng

Образы для EVE

Содержание

Введение

EVE-NG не содержит готовых образы узлов для эмуляции. Это обусловлено лицензионными соглашениями вендоров.

Для использования образов узлов в лабораториях они предварительно должны быть загружены и подготовлены. Лучший способ загрузить образы — использовать утилиту WinSCP для Windows или FileZilla для MAC OSX и Linux.

Для доступа к серверу EVE используйте SSH (22 порт).

Место хранения образов

Поддерживаемые EVE образы хранятся в трех местах:

• IOL (IOS on Linux), /opt/unetlab/addons/iol/bin/
• Dynamips образы, /opt/unetlab/addons/dynamips
• Qemu образы, /opt/unetlab/addons/qemu

Таблица имён для Qemu образов

EVE очень чувствителен к именам каталогов, используемых для образов QEMU. Они должны соответствовать таблице ниже, чтобы работать.

Убедитесь, что имя каталога образа начинается в соответствии с таблицей. После «-» вы можете добавить все, что захотите, чтобы пометить образ. Мы рекомендуем использовать версию вашего образа.

Примеры имен каталогов:

Образ внутри каталога должен быть правильно назван: Пример: hda.qcow2 или virtioa.qcow2

Полный путь для примера: opt/unetlab/addons/qemu/acs-5.8.1.4/hda.qcow2

Имя каталога Qemu	Производитель	Имя образа Qemu .qcow2
a10-	A10-vthunder	hda
acs-	ACS	hda
asa-	ASA ported	hda
asav-	ASAv	virtioa
ampcloud-	Ampcloud Private	hda, hdb, hdc
barracuda-	Barracuda FW	hda
bigip-	F5	hda, hdb
brocadevadx-	Brocade	hda
cda-	Cisco CDA	hda
cips-	Cisco IPS	hda, hdb
clearpass-	Aruba ClearPass	hda, hdb
aruba-	Aruba Virtual Mobility Controller	hda, hdb
coeus-	Cisco WSA coeus	virtioa
phoebe-	Cisco ESA	virtioa
cpsg-	Checkpoint	hda
csr1000v-	Cisco CSR v1000	virtioa
csr1000vng-	Cisco CSR v1000 Denali & Everest	virtioa
prime-	Cisco Prime Infra	virtioa
cucm-	Cisco CUCM	virtioa
cumulus-	Cumulus	hda
extremexos-	ExtremeOS	hda
firepower-	Cisco FirePower 5.4 NGIPS	scsia
firepower-	Cisco FirePower 5.4 FMC	scsia
firepower6-	Cisco FirePower 6.x NGIPS	scsia
firepower6-	Cisco FirePower 6.x FMC	hda
firepower6-	Cisco FirePower 6.x FTD	hda
fortinet-	Fortinet FW	virtioa
fortinet-	Fortinet SGT	virtioa
fortinet-	Fortinet mail	virtioa, virtiob
fortinet-	Fortinet manager	virtioa
hpvsr-	HP virt router	hda
huaweiusg6kv-	Huawei USG6000v	hda
ise-	ISE 1.x cisco	hda
ise-	ISE 2.x cisco	virtioa
jspace-	Junos Space	hda
junipervrr	Juniper vRR	virtioa
linux-	any linux	hda
mikrotik-	Mikrotik router	hda
nsvpx-	Citrix Netscaler	virtioa
nxosv9k-	NX9K Cisco Nexus ( SATA best perf)	sataa
olive-	Juniper	hda
ostinato-	Ostinato traffic generator	hda
osx-	Apple OSX	hda
paloalto-	PaloAlto FW	virtioa
pfsense-	pFsense FW	hda
riverbed-	vRiverbed	virtioa, virtiob
sonicwall-	DELL FW Sonicwall	hda
sourcefire-	Sourcefire NGIPS	scsia
sterra-	S-terra VPN	hda
sterra-	S-terra Gate	virtioa
timos-	Alcatel Lucent Timos	hda
titanium-	NXOS Titanium Cisco	virtioa
vcenter-	VMWare vCenter	sataa ( 12G )
veos-	Arista SW	hda, cdrom.iso
vios-	L3 vIOS Cisco Router	virtioa
viosl2-	L2 vIOS Cisco SW	virtioa
vmx-	Juniper vMX router	hda
vmxvcp-	Juniper vMX-VCP	hda, hdb, hdc
vmxvfp-	Juniper vMX-VFP	hda
vnam-	Cisco VNAM	hda
vqfxpfe-	Juniper vQFX-PFE	hda
vqfxre-	Juniper vQFX-RE	hda
vsrx-	vSRX 12.1 Juniper FW/router	virtioa
vsrxng-	vSRX v15.x Juniper FW/router	virtioa
vwaas-	Cisco WAAS	virtioa,virtiob,virtioc
vwlc-	vWLC Cisco WiFi controller	megasasa
vyos-	VYOS	virtioa
win-	Windows Hosts (Not Server Editions)	hda or virtioa(using driver)
winserver-	Windows Server Editions	hda or virtioa(using driver)
xrv-	XRv Cisco router	hda
xrv9k-	XRv 9000 Cisco router	virtioa

Подготовка образов для EVE

Подробные инструкции доступны в каждой из статей:

Источник

Установка и использование виртуальной сетевой лаборатории EVE-NG совместно с Ansible. Первый опыт

В данной статье приведен опыт инженера-сетевика по развертыванию виртуальной лаборатории EVE-NG в домашних условиях, для целей подготовки к экспертным экзаменам Cisco.

Я постарался собрать все основные вехи настройки, разбросанные по статьям в интернете и попытался добавить в топологию, попутно изучая, ansible — систему управления конфигурациями. Черновик статьи появился случайно, поскольку мне стало жаль терять накопленный опыт и решил сохранять его в отдельный файл. Вот его я и представляю на ваш суд.

Все решения, приведенные в статье, не претендуют на оптимальность, но абсолютно точно работают.

Установка EVE-NG

Подготовка хоста

В качестве хостовой я использую следующую систему: Intel Xeon X3240, 32Gb RAM под управлением Gentoo. Настройка KVM на Gentoo дело достаточно тривиальное и, по правде сказать, я не помню с какими подводными камнями мне пришлось столкнуться при её развертывании. Дело было давно.

Основное, что катастрофически сказывается на производительности лабораторного стенда типа EVE-NG, — это параметр ядра, который запускает возможность использования nested virtualization (вложенную виртуальзацию).

Для процессоров Intel:

Подробнее можно прочесть по ссылке.

Подключение образов сетевых устройств

Образы сетевых устройств для подключения находятся в свободном доступе на самом cisco.com, для скачивания достаточно иметь учётную запись начального уровня. Нам понадобятся XRv и CSR.
Скачиваем по указанными ссылкам и следуем рекомендациям в how-to.

Проблема, с которой я столкнулся при добавлении образов — как называть директории, куда нужно складывать файлы hda.qcow2. Решение, как всегда, — реверс-инжиниринг. Список заголовков, обрабатываемых EVE-NG зашит в файле:

Приведу его здесь:

То есть, если нам необходимо добавить образ с любым Linux, как мы будем делать ниже, то достаточно создать директорию /opt/unetlab/addons/qemu/linux-что-то-там/ и положить в неё файл образа hda.qcow2.

Настройка окружения

Под окружением будем понимать всё, что делает нашу жизнь удобнее.

Доступ к консоли маршрутизаторов

Несмотря на то, что в EVE-NG разработчики внедрили возможность доступа к консолям сетевых устройств по web с использованием HTML5, доступ со сторонних клиентов удобнее и привычнее. Основное удобство, которое предоставляется putty в моём случае, — это возможность использования буфера обмена. Не работает copy/paste в web-консоли.

Итак, процесс выглядит следующим образом:

Установка putty на машине, откуда будет осуществляться доступ. Я работаю на ПК c ubuntu, поэтому:

Но этого мало, нужно еще рассказать браузеру, в моём случае это chrome, как реагировать на ссылки вида telnet://. Для этого необходимо создать файл

/.local/share/applications/telnet.desktop следующего содержания:

После этого консоли будут отлично открываться в putty. Задачу перехода на gnome-terminal с вкладками или его аналог оставлю на потом.

Запуск сниффера трафика

Wireshark — насущная необходимость при изучении сетевых технологий. Очень много написано про его использование. Не стану повторяться. Опишу процесс его настройки.

Установка на клиенте:

Но снова браузер не понимает как обработать ссылку capture://

Объяснять ему это придется в три этапа:

Этап 1:
Как и в случае с консолями, файл

Этап 2:
Обработчик в виде скрипта на bash на клиентской машине в любой директории из списка PATH:

Этап 3:
Ключевой ssh-доступ между клиентской машиной и EVE-NG.

На клиентской машине (вместо ip_eve поставить адрес EVE-NG):

После этого будет работать захват трафика в wireshark на стороне клиента. Что нам и требовалось.

На этом непритязательный пользователь может остановиться, но нет предела совершенству и мы продолжаем.

Настройка инстанса сервера ansible

Необходимость ansible для виртуальных лабораторных топологий в начале пути была для меня неочевидна. Но со временем, на втором десятке лабораторных часов, приходит мысль — а не автоматизировать ли загрузку стартовых топологий в устройства, не перегружая их, тем самым экономя время?

Итак, с чего начать? С ограничений ansible! Да, они действительно есть. Для меня, как достаточно далекого от программирования, слишком жестоким оказалось предложение на одном из форумов — дописать обработчик телнета самому. Телнет нужен был для решения в лоб — настроить ansible на виртуальной машине EVE-NG и телнетится на консольные порты виртуальных маршрутизаторов. Но не тут-то было — работает только ssh.

Но мы старые инженеры и не привыкли отступать! Если гора не идёт к Магомету, то двинем мы к ней — настроим отдельный инстанс с ububtu в самой топологии, благо для этого есть возможность.
Как разворачивать в KVM образ скаченный с ubuntu.com я приводить не буду. Делал я это на отдельной машине, настраивал и заливал в EVE-NG. После установки нам понадобятся пакеты с telnet-сервером и настройка статического IP-адреса.

Настройка telnet-сервера

У меня не вышло заставить EVE-NG показать мне консоль сервера стандартным способом через клик по девайсу. Чтобы не закапываться глубоко, я пошел в обход — настроил telnet-сервер. SSH v2, конечно, тоже имеется и работает с CSR, но уж очень медленно для интерактивной работы, да и бесполезно — у нас лабораторный стенд, а не продакшн.

Потом необходимость в сервере отпала, но запись в шпаргалке осталась, поэтому приведу и её.

После автоматического запуска xinetd, конечно, ничего не произошло, как нам обещали в интернете.

Нужно добавить в /etc/xinetd.d файл telnet следующего содержания:

и перезапустить сервер xinetd:

Проверяем телнет локально:

Закачиваем полученный образ в виртуальную машину EVE-NG и пробуем собрать топологию.

Теперь мы можем, настроив на соседней цыске в топологии адрес из подсети сервера, до него достучаться по telnet. Всё работает быстро, не в пример SSH.

Сбор топологии

Здесь всё чрезвычайно просто. Моя топология выглядит следующим образом:

Развёртывание подсистемы аnsible

Настройка CSR для работы с ansible

Выделим на каждом маршрутизаторe отдельный порт для управления и подключим к общему хабу с сервером ansible портами Gi2. Выберем подсеть для управления, у меня это 192.168.0.0/24. И назначим IP-адреса на портах в соответствии с номером маршрутизатора.

Эту же информацию занесем в /etc/hosts сервера:

На каждом маршрутизаторе настроим SSH v2 согласно ссылки. Всё тривиально, скажу лишь то, что для запуска требумеого нам SSHv2 нужно генерировать ключ более 768 бит, я выбрал размер 2048.

Проверяем доступ с сервера до маршрутизаторов по SSH, заодно собирая в хранилище ключи.

Сохраняем конфигурацию на маршрутизаторе:

И экспортируем в EVE-NG конфигурацию для того, чтобы заново не настраивать при перезагрузках девайсы:

Эта фича в EVE-NG, как и Unetlab до неё, работает с переменным успехом. Но будем надеяться.

Создание первого воркбука

Как мы помним, структура ansible состоит из двух основных частей — описания девайсов (inventory), и воркбука, собственно с логикой работы системы.

В нашем случае inventory достаточно примитивен и файл его содержащий (/etc/ansible/hosts) принимает вид:

Что раскрывается списком хостнеймов от R1 до R10 (помним, что мы уже прописали /etc/hosts для разрешения имён).

А вот с ворбуком придется повозиться.

Первым этапом, для того, чтобы залить конфигурацию, представляющую для нас лабораторный интерес, на виртуальный маршрутизатор IOS, нам необходимо сделать откат на начальную нулевую, содержащую только IP управления и настройки VTY.

Для этого мы попытаемся использовать модуль ios_command.

Основой всей работы по смене конфигураций в устройствах IOS для нас будет служить функционал команды привилегированного режима маршрутизатора:

Нулевые конфигурации будем хранить на сервере в домашнем каталоге нового пользователя под именем router в директории /home/router/default_configs/. Забегая вперед, скажу, что файлы будут иметь имена такие же, как и в inventory, т.е. в нашем случае это R1, R2 и т.д.

Создадим в /opt/ansible файл rollback.yml вида:

Итак, по порядку:

Название используемого инвентори:

Количество параллельно конфигурируемых устройств из инвентори. Важная часть последующей оптимизации производительности.

Как я понял, это говорит о соединении с локальным обработчиком заданий. Могу ошибаться.

Отключение сбора информации о хостах:

Имя пользователя для соединения с устройствами:

Передача команды в устройство из инвентори:

Время ожидания отклика в секундах:

Ничего особо сложного, как мы видим, но есть одно но!

Гугл нам об этом не особо много расскажет, поэтому вооружаемся смекалкой и пытаемся найти кто же нам это заявил. И находим файл самого используемого нами модуля: /usr/local/lib/python2.7/dist-packages/ansible-2.3.0-py2.7.egg/ansible/modules/network/ios/ios_command.py, содержащий вот такой код:

Явно, что разработчики немного перегнули палку, отнеся все параметры configure к конфигурационному режиму, поэтому дописываем в соответсвующую строку:

Создание второго воркбука

Не стану описывать так же подробно, как на предыдущем этапе, просто приведу пример воркбука, который заливает тематическую начальную конфигурацию лабораторных работ одного известного бренда с тремя буквами в названии:

Файлы начальных конфигурации лежат в /opt/ansible/IOS-XE-initials/base.ipv4, соответственно. Основное отличие данного сценария — это использование функционала модуля ios_config и передача права ему интерпретировать те команды, которые необходимо выполнить на устройствах.

На этом всё, спасибо за внимание. Если статья достойна продолжения, то следующей темой станет настройка взаимодействия IOS XR и ansible.

Источник