Особенности применения контейнеров XRd в сетевом симуляторе GNS3 / Хабр

Лет 30 назад словосочетание «виртуальный контейнер» вызывало бы ровно одну ассоциацию – SONET/SDH. В то время это были основные технологии построения опорных и глобальных сетей, грамотно и, что важно, интересно описанные Uyless N. Black в монографии «Emerging Communications Technologies».

С тех пор утекло очень много воды, и если посмотреть на перечень технологий из этой монографии (FDDI, Frame Relay, ISDN, X.25, ATM и т.п.) – все они, за очень редким исключением в виде 100BASE-T и IPv6, уже благополучно позабыты. В частности, если сегодня и вспоминают про SONET/SDH – то только в части ставшего «золотым стандартом» времени переключения на резервный маршрут (50 мс). А «виртуальный контейнер» теперь ассоциируется с виртуализацией на уровне операционной системы и средствами управления ей (например, Docker, Kubernetes и т.п.)

Вообще, контейнеры (а дальше под этим словом будем понимать исключительно «виртуальные контейнеры» в контексте виртуализации на уровне операционной системы) оказались весьма удачным подходом для развертывания и управления микросервисами. А сегодня контейнеры начинают массово замещать или дополнять «стандартную» виртуализацию даже в сетевых симуляторах – дополнительно подталкивая сетевиков к изучению новых технологий.

Краткое содержание предыдущей серии

В предыдущей статье я описал нечасто используемую, но очень полезную возможность симулятора GNS3 – «горизональное масштабирование», позволяющую для симуляции использовать ресурсы не одной-единственной (как в EVE-NG/PNETLAB) виртуалки, а сразу нескольких (распределяя между всеми ними узлы из топологии). Однако, возможность использовать множество ресурсов не освобождает от платы за использование этих ресурсов. И чем больше ресурсов используется – тем выше эта плата. Плюс, даже относительно мощного подручного сервера не всегда может хватить на симуляцию всей требуемой топологии.

В моем конкретном кейсе все усугублялось тем, что в среде используемого сетевого симулятора GNS3, узлы IOS XRv 7.x в сколько-нибудь требуемом количестве работали крайне нестабильно. Могли поработать и уйти в перезагрузку с сообщением об ошибке, могли просто зависнуть при инициализации. Вероятно, причина была в том, что и сам IOS XRv состоит из 3 виртуалок: admin, RP и LC [1]. Поэтому в моем случае (по ряду соображений, не использовал ESXi) получался достаточно большой уровень вложенной виртуализации (Windows + VmWare WS + GNS3 VM, плюс еще виртуалки из состава IOS XRv). И при запуске единичных узлов IOS XRv (до 4 суммарно) все стабильно работало часами, но при дальнейшем увеличении их числа стабильность пропадала. Вообще, стандартным решением ресурсных проблем является использование более легковесных образов. Например, вместо CSR1000v можно использовать IOL/IOL-XE. Эти образы требуют в разы меньше CPU и RAM, стартуют на порядок быстрее, но могут не поддерживать весь требуемый функционал (чудес не бывает). Так что, обычно используются сразу оба типа образов – функциональные и «ресурсосберегающие» – если, конечно, симулятор поддерживает их одновременную работу.

Для IOS XRv таким «ресурсосберегающим» аналогом оказался XRd – потребляющий кратно меньше ресурсов и работающий (по ощущениям) быстрее и намного стабильнее – во всяком случае, если все правильно подготовить и настроить.

Не все контейнеры одинаково полезны (как и йогурты)

Приятной неожиданностью работы с контейнерами оказалась их доступность: на hub.docker.com разными участниками и официальными разработчиками представлены тысячи контейнеров на любой вкус, нужно лишь ввести правильный запрос в строке поиска по сайту.

Но на практике далеко не все контейнеры с хаба Docker запускались и радовали своей работой в среде GNS3. Дело в том, что именно контейнеры сетевых узлов в основном создавались для работы в среде другого популярного симулятора - containerlab.dev. А в основе контейнера для containerlab.dev находится стандартный образ .qcow2, требующий QEMU для своего исполнения. И, поскольку в GNS3 не смешиваются QEMU и Docker, при запуске такого контейнера в GNS3 будет появляться сообщение о недоступности QEMU. Иными словами, контейнер контейнеру – рознь.

В свою очередь, XRd – нативная контейнерная версия от «того самого» вендора, не требующая какой-то дополнительной или специфичной функциональности (кроме, разве что, настроек – описанию которых посвящен цикл из 6 описаний «xrd-tutorial-series» [2] от «того самого» вендора).

Кроме того, есть 2 версии XRd – XRd Control-Plane и XRd vRouter, отличающиеся:

Используемыми ресурсами и функционалом (версия XRd Control-Plane менее требовательна к ресурсам, но и менее функциональна)
Требованиями по настройкам операционной системы. К сожаление, несмотря на достаточно подробные описания настроек в [2], на момент построения стенда лично мне не удалось окончательно победить и запу��тить XRd vRouter. Возможно, это было связано с версией найденного контейнера (25.х вместо 7.х, под который был «заточен» цикл [2]). Также с тех пор обновился комплект скриптов и настроек, о котором пойдет речь ниже.

Не нравится XRd? Вы просто неправильно их готовите

Все описанные здесь настройки и примеры относятся только к XRd Control-Plane версии 7.9.2.

Почему именно эта версия? Она соответствует актуальному треку SP 5.1 «того самого» вендора. И данная статья может помочь прямо сейчас тем, кто по этому треку готовится. Или просто без претензий хочет сократить потребление ресурсов стенда.

Подготовка к использованию XRd в среде GNS3 включает:

Установку скриптов для последующей диагностики ОС на совместимость с XRd
Донастройку операционной системы на виртуалках GNS3 согласно туториалам
Диагностику ОС на совместимость с нужной версией XRd после донастройки
Загрузку на виртуальную машину GNS3 нужного контейнера
Настройку каждого экземпляра в части сохранения файла конфигурации

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

Для проверки всех нижеописанных процедур на стенд была добавлена еще одна, «чистая», виртуалка GNS3 с названием “TEST”. Ей было выделено 16 vCPU и 64 GB RAM.

Установка диагностических скриптов для последующей диагностики ОС

Описана в туториале «Helper Tools to get started with XRd» цикла [2]. Здесь и далее я не привожу прямые ссылки на эти статьи по той причине, что при непосредственном переходе по ссылке появляется сообщение об ошибке 404. Возможно, некорректно работает защита от DDos- атак. Однако, со странички цикла описаний [2] все описания открываются корректно.

Сами скрипты входят в состав большого комплекта документации, скриптов и примеров топологий, размещенных «тем самым» вендором на GITHUB. Судя по временным меткам, этот проект не заброшен и регулярно обновляется и дополняется.

Виртуальные машины GNS3 версии 2.2.46 построены на базе Ubuntu 20.04.06 LTS, что соответствует требованиям со стороны XRd Control-Plane и диагностического скрипта.

Предполагается, что при выполнении команд пользователь находится в домашнем каталоге.

1. Для установки необходимо выполнить следующую команду:

git clone https://github.com/ios-xr/xrd-tools.git

По факту, в домашний каталог пользователя будет добавлена следующая совокупность подкаталогов и файлов:

xrd-tools/
├── CHANGELOG.md
├── commit-check
├── CONTRIBUTING.md
├── Dockerfile.host-check
├── docs
│   └── version-compatibility.md
├── LICENSE
├── mypy.ini
├── profiles
│   └── xrd-unconfined
├── pylintrc
├── pyproject.toml
├── README.md
├── requirements.txt
├── samples
│   └── xr_compose_topos
│       ├── bgp-ospf-triangle
│       │   ├── docker-compose.xr.yml
│       │   ├── topo-diagram.png
│       │   ├── xrd1_xrconf.cfg
│       │   ├── xrd2_xrconf.cfg
│       │   └── xrd3_xrconf.cfg
│       ├── segment-routing
│       │   ├── docker-compose.xr.yml
│       │   ├── xrd-1-startup.cfg
│       │   ├── xrd-2-startup.cfg
│       │   ├── xrd-3-startup.cfg
│       │   ├── xrd-4-startup.cfg
│       │   ├── xrd-5-startup.cfg
│       │   ├── xrd-6-startup.cfg
│       │   ├── xrd-7-startup.cfg
│       │   └── xrd-8-startup.cfg
│       └── simple-bgp
│           ├── docker-compose.xr.yml
│           ├── xrd-1_xrconf.cfg
│           └── xrd-2_xrconf.cfg
├── scripts
│   ├── apply-bugfixes
│   ├── host-check
│   ├── launch-xrd
│   └── xr-compose
├── templates
│   ├── docker-compose.template.xr.yml
│   └── launch-xrd-macvlan.template
└── tests
    ├── __init__.py
    ├── test_host_check.py
    ├── test_launch_xrd.py
    └── utils.py

11 directories, 39 files

Примечание: пару лет назад всего было 9 каталогов и 35 файлов.

Однако, исходно на виртуалке GNS3 нет утилиты «tree». Ее можно добавить, а можно просто просмотреть содержимое каталогов. По факту, далее будут использоваться скрипт «host-check» и профиль «xrd-unconfined».

2. Для проверки правильности клонирования, можно выполнить команды:

cd ~/xrd-tools/scripts 
sudo ./host-check --platform xrd-control-plane

Ожидаемый результат:

gns3@gns3vm:~/xrd-tools/scripts$ sudo ./host-check --platform xrd-control-plane
==============================
Platform checks - xrd-control-plane
==============================
 PASS -- CPU architecture (x86_64)
 PASS -- CPU cores (16)
 PASS -- Kernel version (5.15)
 PASS -- Base kernel modules
         Installed module(s): dummy, nf_tables
 PASS -- Cgroups (v1)
 FAIL -- Inotify max user instances
         The kernel parameter fs.inotify.max_user_instances is set to 128 but
         should be at least 4000 (sufficient for a single instance) - the
         recommended value is 64000.
         This can be addressed by adding 'fs.inotify.max_user_instances=64000'
         to /etc/sysctl.conf or in a dedicated conf file under /etc/sysctl.d/.
         For a temporary fix, run:
           sysctl -w fs.inotify.max_user_instances=64000
 PASS -- Inotify max user watches
         500784 - this is expected to be sufficient for 125 XRd instance(s).
 WARN -- Socket kernel parameters
         The kernel socket parameters are insufficient for running XRd in a
         production deployment. They may be used in a lab deployment, but must
         be increased to the required minimums for production deployment.
         Lower values may result in XR IPC loss and unpredictable behavior,
         particularly at higher scale.

         The required minimum settings are:
             net.core.netdev_max_backlog=300000
             net.core.optmem_max=67108864
             net.core.rmem_default=67108864
             net.core.rmem_max=67108864
             net.core.wmem_default=67108864
             net.core.wmem_max=67108864

         The current host settings are:
             net.core.netdev_max_backlog=1000
             net.core.optmem_max=20480
             net.core.rmem_default=212992
             net.core.rmem_max=212992
             net.core.wmem_default=212992
             net.core.wmem_max=212992

         Values can be changed by adding e.g.
         'net.core.rmem_default=67108864' to /etc/sysctl.conf or
         in a dedicated conf file under /etc/sysctl.d/.
         Or for a temporary fix, running e.g.:
           sysctl -w net.core.rmem_default=67108864
 WARN -- UDP kernel parameters
         The kernel UDP parameters are insufficient for running XRd in a
         production deployment. They may be used in a lab deployment, but must
         be increased to the required minimums for production deployment.
         Lower values may result in XR IPC loss and unpredictable behavior,
         particularly at higher scale.

         The required minimum settings are:
             net.ipv4.udp_mem=1124736 10000000 67108864
         The current host settings are:
             net.ipv4.udp_mem=1535838 2047785 3071676
         Values can be changed by adding
         'net.ipv4.udp_mem=1124736 10000000 67108864' to /etc/sysctl.conf or
         in a dedicated conf file under /etc/sysctl.d/.
         Or for a temporary fix, running:
           sysctl -w net.ipv4.udp_mem='1124736 10000000 67108864'
 INFO -- Core pattern (core files managed by XR)
 PASS -- ASLR (full randomization)
 FAIL -- Linux Security Modules
         AppArmor is running on this system but the `xrd-unconfined` profile is
         not installed / loaded. XRd is unable to run as expected without this
         profile in place, so please follow the steps from the README.md file
         at https://github.com/ios-xr/xrd-tools to install and enable the profile.
 PASS -- Kernel module parameters
         Kernel modules loaded with expected parameters.
 PASS -- RAM
         Available RAM is 61.6 GiB.
         This is estimated to be sufficient for 30 XRd instance(s), although memory
         usage depends on the running configuration.
         Note that any swap that may be available is not included.

============================================================================
!! Host NOT set up correctly for xrd-control-plane !!
============================================================================
gns3@gns3vm:~/xrd-tools/scripts$

Помимо подтверждения успешного клонирования, скрипт указывает на 2 проблемы, требующие решения. На самом деле, реальная проблема, без решения которой контейнер версии 7.х точно не запустится, всего одна - Inotify max user instances. В прошлых версиях скрипта статус сообщения «Linux Security Modules» был WARN.

Есть еще причина, по которой имеет смысл использовать скрипт: в случае каких-то ошибок в настройках операционной системы, контейнер очень быстро прекращает работу и мгновенно закрывает окно – так что диагностическое сообщение, даже если он напоследок и выдает, не всегда можно успеть прочесть.

Донастройка операционной системы на виртуалках GNS3

И так, скрипт показал 2 ошибки:

Linux Security Modules
Inotify max user instances

Первая ошибка устраняется следующей парой команд (если нужно – добавляем “sudo”):

cp ~/xrd-tools/profiles/xrd-unconfined /etc/apparmor.d/xrd-unconfined
apparmor_parser -r /etc/apparmor.d/xrd-unconfined

Ошибка «Inotify max user instances» исправляется добавлением следующей строки в файл /etc/sysctl.conf

fs.inotify.max_user_instances=64000

Если у вас выругается на «Inotify max user watches», то добавить еще одну строчку в тот же файл:

fs.inotify.max_user_watches=64000

Я добавлял такие строки через редактор nano.

Значение 64000 соответствует примерно 16 одновременно запущенным экземплярам XRd Control-Plane. Если предполагаются более «развесистые» топологии (например, до 32 экземпляров) – значение можно пропорционально увеличить (например, до 128000).

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

Проверка применения и достаточности настроек

Снова выполним скрипт «host-check»:

gns3@gns3vm:~/xrd-tools/scripts$ sudo ./host-check --platform xrd-control-plane
==============================
Platform checks - xrd-control-plane
==============================
 PASS -- CPU architecture (x86_64)
 PASS -- CPU cores (16)
 PASS -- Kernel version (5.15)
 PASS -- Base kernel modules
         Installed module(s): dummy, nf_tables
 PASS -- Cgroups (v1)
 PASS -- Inotify max user instances
         64000 - this is expected to be sufficient for 16 XRd instance(s).
 PASS -- Inotify max user watches
         500784 - this is expected to be sufficient for 125 XRd instance(s).
 WARN -- Socket kernel parameters
         The kernel socket parameters are insufficient for running XRd in a
         production deployment. They may be used in a lab deployment, but must
         be increased to the required minimums for production deployment.
         Lower values may result in XR IPC loss and unpredictable behavior,
         particularly at higher scale.

         The required minimum settings are:
             net.core.netdev_max_backlog=300000
             net.core.optmem_max=67108864
             net.core.rmem_default=67108864
             net.core.rmem_max=67108864
             net.core.wmem_default=67108864
             net.core.wmem_max=67108864

         The current host settings are:
             net.core.netdev_max_backlog=1000
             net.core.optmem_max=20480
             net.core.rmem_default=212992
             net.core.rmem_max=212992
             net.core.wmem_default=212992
             net.core.wmem_max=212992

         Values can be changed by adding e.g.
         'net.core.rmem_default=67108864' to /etc/sysctl.conf or
         in a dedicated conf file under /etc/sysctl.d/.
         Or for a temporary fix, running e.g.:
           sysctl -w net.core.rmem_default=67108864
 WARN -- UDP kernel parameters
         The kernel UDP parameters are insufficient for running XRd in a
         production deployment. They may be used in a lab deployment, but must
         be increased to the required minimums for production deployment.
         Lower values may result in XR IPC loss and unpredictable behavior,
         particularly at higher scale.

         The required minimum settings are:
             net.ipv4.udp_mem=1124736 10000000 67108864
         The current host settings are:
             net.ipv4.udp_mem=1535838 2047785 3071676
         Values can be changed by adding
         'net.ipv4.udp_mem=1124736 10000000 67108864' to /etc/sysctl.conf or
         in a dedicated conf file under /etc/sysctl.d/.
         Or for a temporary fix, running:
           sysctl -w net.ipv4.udp_mem='1124736 10000000 67108864'
 INFO -- Core pattern (core files managed by XR)
 PASS -- ASLR (full randomization)
 INFO -- Linux Security Modules
         AppArmor is running with the recommended `xrd-unconfined` profile.
         XRd is able to run under this profile by running with '--security-opt
         apparmor=xrd-unconfined', however this is not supported when launching
         the container in privileged mode.
 PASS -- Kernel module parameters
         Kernel modules loaded with expected parameters.
 PASS -- RAM
         Available RAM is 61.5 GiB.
         This is estimated to be sufficient for 30 XRd instance(s), although memory
         usage depends on the running configuration.
         Note that any swap that may be available is not included.

============================================================================
!! One or more platform checks resulted in a warning, see warnings above !!
============================================================================
gns3@gns3vm:~/xrd-tools/scripts$

И так, все препятствия для запуска контейнера в тестовой среде устранены.

Загрузка на виртуальную машину GNS3 нужного контейнера

1. Процедура начинается с вызова экранной формы через меню GNS3: Edit->Preferences->Docker containers->New

2. Затем нужно выбрать виртуалку, на которую будет установлен контейнер. Выбираем TEST

3. Далее выбираем контейнер с сайта hub.docker.com в формате USER/CONTAINER:TAG

4. Определяем условное имя для последующего использования (позднее можно переименовать).

5. Далее нужно задать число адаптеров 9 (чтобы без изменений добавить переменные), стартовую строку команд оставить пустой, тип консоли без изменений (telnet).

6. И, наконец, добавляем переменные для сетевых адаптеров. Адаптеры с 0 до 7 будут передавать данные, а адаптер 8 будет выделенным интерфейсом управления.

Собственно, сами переменные (чтобы не вбивать руками с экрана):

XR_MGMT_INTERFACES=linux:eth8
XR_INTERFACES=linux:eth0;linux:eth1;linux:eth2;linux:eth3;linux:eth4;linux:eth5;linux:eth6;linux:eth7

Названия переменных не являются универсальными (контейнерам для containerlab.dev не подойдут). Сами переменные и их возможные значения описаны в статье «User Interface and Knobs for XRd» из цикла [2].

Предложенная последовательность обеспечивает интуитивно комфортное соответствие между внешними портами контейнера и обозначениями в командной строке:

Eth0 <=> GigabitEthernet0/0/0/0
…
Eth7 <=> GigabitEthernet0/0/0/7

Кстати, получается намного удобнее по сравнению с «полноценным» IOS XRv9k 7.x – там нужно пропустить первые 2 порта, что сбивает нумерацию на топологии.

7. Контейнер добавлен. Можно просмотреть сводку и нажать «ОК».

При необходимости, в этой же форме контейнер можно удалить. Он также будет удален с диска, что кажется удобным.

8. Придать каталогу /etc/xrd/ статус «постоянный» (peristent) через опцию «Configure Template».

В выборе каталога я тоже неоригинален – именно этот каталог используется для хранения файлов конфигураций в примерах описаний «XRd with docker: Control-Plane and vRouter» и «XRd with docker-compose: Control-Plane» из цикла [2].

На самом деле, изначально каталог /etc/xrd/ не существует – но перед придания ему статуса «постоянный» (peristent) происходит создание этого каталога (что логично и даже удобно).

Настройка каждого экземпляра в части сохранения файла конфигурации

В чем необходимость донастройки каждого экземпляра и почему все необходимые переменные нельзя было задать при скачивании контейнера (как с переменными сетевых адаптеров)?

Пойдем по шагам, но в обратную сторону:

-1. Чтобы устройство запустилось с конфигурацией – устройство должно знать, в каком файле хранится конфигурация. Полный путь к этому файлу задается через переменную XR_EVERY_BOOT_CONFIG. Но если в этой переменной содержатся неверные сведения (файл отсутствует или не содержит верные сведения) – устройство просто не запустится (проверено). Таким образом, значение переменной должно задаваться только после создания и наполнения файла конфигурации.

-2. Конфигурационный файл может использоваться только в том случае, если он находится в «постоянной» (persistent) области (каталоге), которая сохраняет содержимое даже при выключении контейнера или закрытии топологии (но не удалении контейнера из топологии). В противном случае, содержимое конфигурационного файла может быть утеряно и впоследствии устройство также не загрузится (тоже проверено). Таким образом, файл конфигурации может быть сохранен только после придания каталогу статуса «постоянный» (persistent).

Поскольку каталогу /etc/xrd/ уже придан статус «постоянный» (peristent), остается:

Применить и сохранить конфигурацию в файле из каталога /etc/xrd/
В переменной XR_EVERY_BOOT_CONFIG задать полный путь до файла конфигурации.

Рассмотрим это пошагово:

ШАГ 0. Добавляем контейнер в пустую (или ранее созданную) топологию и стартуем контейнер.

После первоначальной загрузки появится приглашение создать пользователя с привилегиями root. Это является индикатором первого запуска устройства и определяется исключительно алгоритмом работы IOS XRv, но не его контейнерной природой. Собственно, поэтому вынесено в подготовительный шаг 0.

На этом шаге вводим идентификатор и пароль этого пользователя. Первые 3 строки создают пользователя и его пароль, следующие 2 – выполнение входа под учеткой этого пользователя.

admin
User123
User123

admin
User123

В консоли это выглядит так (выполнялся копи-паст, поэтому пароль отобразился):

!!!!!!!!!!!!!!!!!!!! NO root-system username is configured. 
Need to configure root-system username. !!!!!!!!!!!!!!!!!!!!
Configuration lock is held by another agent.  Please wait. [.OK]


         --- Administrative User Dialog ---


  Enter root-system username: admin
User123
User123
  Enter secret:
  Enter secret again:
Use the 'configure' command to modify this configuration.
User Access Verification

Username: admin
Password:


RP/0/RP0/CPU0:ios#

И теперь можно выполнить настройку устройства или загрузить из файла ранее заготовленную конфигурацию.

ШАГ 1. Сохраняем файл конфигурации из текущей

Сперва выполняем следующие команды:

copy run /etc/xrd/work.cfg

Эти команды обеспечивают собственно сохранение исполняемой конфигурации в конфигурационный файл /etc/xrd/work.cfg. Вторая (пустая) строчка нужна для подтверждения имени создаваемого файла (имитация нажатия клавиши ENTER). В дальнейшем именно так придется сохранять конфигурацию контейнер��.

RP/0/RP0/CPU0:ios#copy run /etc/xrd/work.cfg
Wed Jan 21 17:29:31.596 UTC
Destination file name (control-c to cancel): [/etc/xrd/work.cfg]?
Building configuration.
44 lines built in 1 second
[OK]
RP/0/RP0/CPU0:ios#

Теперь проверяем правильность сохранения:

bash
cat /etc/xrd/work.cfg
ls /etc/xrd
exit

Здесь выполняется переход в режим bash, в котором командами Linux выполняются:

Просмотр содержимого файла /etc/xrd/work.cfg
Просмотр содержимого каталога /etc/xrd/

RP/0/RP0/CPU0:ios#bash
Wed Jan 21 17:32:30.682 UTC
cat /etc/xrd/work.cfg
ls /etc/xrd
exit
cat /etc/xrd/work.cfg
ls /etc/xrd
exit
[ios:~]$cat /etc/xrd/work.cfg
!! IOS XR Configuration 7.9.2
!! Last configuration change at Wed Jan 21 17:24:12 2026 by SYSTEM
!
username admin
 group root-lr
 group cisco-support
 secret 10 $6$II2WS03Vcb6u7S0.$AWrl0sN2SH1ePSGKWzcOnhWMX9w/ED8zo2wnuSedka1GVvtwb.VD4sHMNvh8yg2IC6DGsidWN1pmRM7eex4Hn1
!
call-home
 service active
 contact smart-licensing
 profile CiscoTAC-1
  active
  destination transport-method email disable
  destination transport-method http
 !
!
interface MgmtEth0/RP0/CPU0/0
 shutdown
!
interface GigabitEthernet0/0/0/0
 shutdown
!
interface GigabitEthernet0/0/0/1
 shutdown
!
interface GigabitEthernet0/0/0/2
 shutdown
!
interface GigabitEthernet0/0/0/3
 shutdown
!
interface GigabitEthernet0/0/0/4
 shutdown
!
interface GigabitEthernet0/0/0/5
 shutdown
!
interface GigabitEthernet0/0/0/6
 shutdown
!
interface GigabitEthernet0/0/0/7
 shutdown
!
end
[ios:~]$ls /etc/xrd
work.cfg
[ios:~]$exit
Logout
RP/0/RP0/CPU0:ios#

Видно, что конфигурация содержит дефолтные настройки интерфейсов (shutdown) и пользователя admin из шага 0. Собственно, большего там и не должно быть.

В каталоге /etc/xrd есть только файл work.cfg, что также является ожидаемым результатом.

Понятно, что проверки – опциональная часть. Хотя весьма полезная, когда что-то идет не так.

ШАГ 2. Добавляем переменную XR_EVERY_BOOT_CONFIG=/etc/xrd/work.cfg.

После нажатия ОК узел перезагрузится автоматически.

Теперь после перезагрузки узел не требует создать пользователя с привилегиями root, а сразу переходит к аутентификации.

RP/0/RP0/CPU0:Jan 21 17:45:11.650 UTC: pyztp2[297]: %INFRA-ZTP-4-EXITED : ZTP exited

User Access Verification

Username: admin
Password:


RP/0/RP0/CPU0:ios#sh run
Wed Jan 21 17:45:58.705 UTC
Building configuration...
!! IOS XR Configuration 7.9.2
!! No configuration change since last restart
!
username admin
 group root-lr
 group cisco-support
 secret 10 $6$II2WS03Vcb6u7S0.$AWrl0sN2SH1ePSGKWzcOnhWMX9w/ED8zo2wnuSedka1GVvtwb.VD4sHMNvh8yg2IC6DGsidWN1pmRM7eex4Hn1
!
call-home
 service active
 contact smart-licensing
 profile CiscoTAC-1
  active
  destination transport-method email disable
  destination transport-method http
 !
!
interface MgmtEth0/RP0/CPU0/0
 shutdown
!
interface GigabitEthernet0/0/0/0
 shutdown
!
interface GigabitEthernet0/0/0/1
 shutdown
!
interface GigabitEthernet0/0/0/2
 shutdown
!
interface GigabitEthernet0/0/0/3
 shutdown
!
interface GigabitEthernet0/0/0/4
 shutdown
!
interface GigabitEthernet0/0/0/5
 shutdown
!
interface GigabitEthernet0/0/0/6
 shutdown
!
interface GigabitEthernet0/0/0/7
 shutdown
!
end

RP/0/RP0/CPU0:ios#

Собственно, это минимально необходимые действия для последующего сколько-нибудь долговременного использования узла.

И где здесь подвох?

Во-первых, обычно экономия ресурсов достигается за счет экономии на функционале. В данном случае, функционале data-plane. В частности, даже после безошибочной настройки не будут работать: multicast, BFD, политики QoS (и, боюсь, это не исчерпывающий список).

С другой стороны, многие технологии (SR, SRv6, MPLS, протоколы маршрутизации) поддерживаются вполне корректно, что позволяет скорее рекомендовать использовать XRd, чем не использовать.

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

Я бы даже не назвал это неудобством – ибо для учебного стенда даже хорошо, что конфигурация сама возвращается к исходной (без снапшотов). Ну, а если нужно сохранить изменения – «copy run /etc/xrd/work.cfg» в помощь. Главное – сделать до выключения.

В-третьих, даже такие нетребовательные по ресурсам узлы не избавляют (при большом числе) от необходимости их поочередного запуска, В противном случае, устройства будут запускаться с очень большой задержкой.

Заключение

В данной статье: описано внедрение «ресурсосберегающей» версии IOS XRv9k – XRd – в среде симулятора сетей GNS3.

При этом описывалось применение версии xrd-control-plane версии 7.9.2, которая:

Требует меньше ресурсов и проще в установке по сравнению с версией vRouter;
Соответствует требованиям актуального трека SP 5.1 «того самого» вендора;
При этом имеет неполный функционал в части multicast, BFD, политик QoS

Были приведены:

Пояснения по настройкам
Пошаговые инструкции по применению настроек

Для дополнительного просмотра и изучения

1. Видеотуториал «Cisco IOS XRv 9000 Installation Basic Operations & vRR Configuration»

https://www.youtube.com/watch?v=EOFddGI_qvY

Если для вас наличие виртуальных машин внутри IOS XRv9K оказалось неожиданным – посмотрите данный видеотуториал. Там на слайде 25 (это начиная с 18:45) обсуждается архитектура, а также связанные с ней команды диагностики и состояния.

2. Цикл описаний «xrd-tutorial-series»

https://xrdocs.io/tags/xrd-tutorial-series

Особенности применения контейнеров XRd в сетевом симуляторе GNS3