Всем привет!

Начну с себя — я студент направления ИБ. На момент написания статьи заканчиваю третий курс. Не по секрету вам скажу, в моём учебном процессе немало внимания уделяется устройству компьютерных сетей — от базового понимания до вполне прикладных задач.

В случае нашего университета знакомство с компьютерными сетями начинается с Cisco Packet Tracer — наглядного, простого, но довольно ограниченного инструмента, предназначенного для освоения базы. У нас был целый семестр вместе с Cisco.

Но потом у нас появился новый преподаватель, который предложил проявить инициативу, и заняться чем то интересным. Я решил подойти и узнать у него по подробнее. Задание было переписать методическое пособие по Моделированию компьютерных сетей и адаптировать всё содержимое под PNETLab. Он подметил, что документации на русском языке по этой теме очень мало, и если я возьмусь за это, то буду одним из первооткрывателей. Я согласился на эту авантюру.

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

Спустя семестр, когда надо было отчитаться о проделанной работе, я сделал для себя вывод, что даже у PNETLAB есть свои минусы. И не всё так радужно, как я думал.

К тому моменту нам дали курсовую работу по проектированию сети. Из инструментов проектирования были только Packet Tracer и PNETLab.

Во время работы над курсовой, само собой, возникало много вопросов, приходилось гуглить — искал ответы на вопросы по настройке, примеры, советы. В какой-то момент, совершенно случайно, наткнулся на упоминание Containerlab. Само название сначала ничего особенного не сказало. Так получилось, что я открыл эту ссылку — и тут я понял, что это то, что мне надо!

Всё основано на контейнерах. Топология описывается обычным YAML-файлом, а настройка — через пару CLI-команд. Никаких долгих загрузок, никаких виртуалок, минимум движений.

На фоне этого PNETLab начал казаться громоздким и неудобным, а Packet Tracer — и вовсе учебной игрушкой. Добавлю, что у каждого инструмента есть своё место, каждый хорош в своём, лишних нет: Packet Tracer отлично подходит для первых шагов, PNETLab — если хочется ближе к реальности, но всё ещё с GUI. А вот Containerlab — это на голову выше. Он даёт не только знания, но и практику, максимально приближенную к тому, как это делается в реальных инфраструктурах. А если вы еще и хотите освоить контейнеры, то это прекрасная практика для начинающих «сетевиков».

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

Дальше — сравнение трёх инструментов, плюсы и минусы каждого, и почему Containerlab — не просто альтернатива, а настоящий шаг вперёд.

Cisco Packet Tracer

Cisco Packet Tracer — единственный на сегодня проект в данной статье, для которого нужно покупать лицензию. Несомненно, является одним из самых популярных инструментов в мире для сетей. Сам я тоже начинал с него — и тогда казалось самой крутой реализацией программы: можно соединить компьютеры, свитчи, роутеры и наглядно увидеть как это работает.

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

Со временем, когда углубляешься в реальные технологии и сценарии, осознаешь, что это не настоящий Cisco IOS. Тут нет полноценной операционной системы, часть команд либо отсутствует, либо просто ведёт себя «странно». Многие привычные вещи из CLI просто недоступны. Плюс к этому, нулевая поддержка других вендоров. Только Cisco.

Кооперативная работа в Packet Tracer также невозможна. Это чисто оффлайновый инструмент, рассчитанный на одного пользователя. О контейнерах можно полностью забыть. Нет возможности автоматизировать развертывание конфигураций, использовать Ansible, Git, CI/CD или другие DevOps‑подходы. Ни о какой инфраструктуре, как код речи не идёт.

Если вы только начинаете, или вам нужно быстро «накидать» идею, проверить базовую связность — Packet Tracer справиться. Но когда вы выходите за рамки «настроить VLAN и пропинговать», и хотите работать с настоящими образами, более сложными протоколами, автоматизацией и DevOps‑инструментами — этот этап нужно пройти и двигаться дальше.

PNETLab

Сам «пнет», по существу, как инструмент проектирования сетей, очень хорош.

1. Можно использовать реальные образы Cisco IOSv, IOS‑XRv, ASA, Juniper vSRX, Fortinet FortiGate, VyOS, Arista, и других.

2. Возможность использовать Dynamips, QEMU, IOL, Docker и Wireshark. Можно эмулировать реальные протоколы, взаимодействие на уровне L2/L3, более точно моделировать отказоустойчивость, маршрутизацию, firewall, NAT и т. д.

3. Он хорош тем, что его просто развернуть на сервере и дать доступ нескольким студентам — у каждого будет своя учётка и свой набор лабораторий.

Сайт с полной документацией по PNETLab.

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

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

За всё время работы с «пнетом», я пробовал разные методы действий, который позволяет не потерять конфигурации. Для этого вам нужно разобраться с Startup Configs, но по себе скажу, это не гарантирует какой то стабильности в работе. Я считаю, что такие вещи, как автосохранение конфигурации устройств, должны работать на автоматизме. Без всяких костылей.

Еще одна проблема «пнета» — его производительность. На простых ноутбуках не очень удобно работать. В одной виртуальной машине запускаются другие виртуальные машины (через QEMU, Dynamips, IOL и т. д.).

Запуск 4–5 устройств одновременно легко загружает процессор на 70–100%, особенно если у вас не передовое устройство. Я работаю на 8 ядерном, 16 поточном ноутбуке, для виртуалки выделяю половину ресурсов процессора. Если конфигурация стенда становится хоть немного сложнее (10+ устройств), начинает тупить интерфейс, система "пнета" становиться непослушной. Это была моя "точка кипения". Я не мог спокойно продолжать работать с такой проблемой.

Почему Containerlab?

Когда я впервые ворвался в Linux Сommunity, мне было много чего не понятно. Интерес крутился вокруг могущества командной строки терминала. Так я стал привыкать работать исключительно в терминале, без графической оболочки GUI. В этом есть какой то шарм.

В какой то момент я пришел к Docker. Мне изначально понравилась концепция контейнеров, открывающие большие просторы возможностей быстро поднимать тестовые среды.

Так всё же, что такое Containerlab?

Containerlab (сокр. clab) — это инструмент от команды Nokia Srlinux, предназначенный для создания виртуальных сетей с использованием контейнеров. Если цитировать официальную документацию:

С ростом числа контейнеризированных сетевых операционных систем растет и потребность в их легком запуске в определяемых пользователем универсальных лабораторных топологиях.

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

Containerlab предоставляет CLI для оркестровки и управления сетевыми лабораториями на основе контейнеров. Он запускает контейнеры, создает виртуальную проводку между ними для создания топологий лабораторий по выбору пользователей и управляет жизненным циклом лабораторий.

Возможностьсоздания «виртуальных связей» между контейнерами — визитная карточка clab. Официальная страница проекта.

Установка производиться в одну команду (Для Debian и RHEL-like дистрибутивов):

bash -c "$(wget -qO - https://get.containerlab.dev)"

Топология задается через YAML-файл. Пример файла представлен ниже:

name: network

topology:
  nodes:
    isp1:
      kind: linux
      image: frrouting/frr:latest
      binds:
        - ./config/isp1/frr.conf:/etc/frr/frr.conf
        - ./config/isp1/vtysh.conf:/etc/frr/vtysh.conf
      exec:
        - /usr/lib/frr/frrinit.sh start

    m1:
      kind: linux
      image: frr-for-vrrp-config:0.1.0
      binds:
        - ./config/m1/frr.conf:/etc/frr/frr.conf
        - ./config/m1/vtysh.conf:/etc/frr/vtysh.conf
      env:
        IS_MASTER: "1"
      exec:
        - /usr/lib/frr/frrinit.sh start

    m2:
      kind: linux
      image: frr-for-vrrp-config:0.1.0
      binds:
        - ./config/m2/frr.conf:/etc/frr/frr.conf
        - ./config/m2/vtysh.conf:/etc/frr/vtysh.conf
      exec:
        - /usr/lib/frr/frrinit.sh start

    sw1:
      kind: linux
      image: v-switch:v1

  links:
    - endpoints: ["m1:eth1", "sw1:eth1"]
    - endpoints: ["m2:eth1", "sw1:eth2"]
    - endpoints: ["isp1:eth1", "sw1:eth3"]

У clab'a явное преимущество, на которое я обратил внимание — это возможность очень быстро и понятно взаимодействовать, управлять топологией.

mish@debian:~$ clab --help
deploy container based lab environments with a user-defined interconnections

Usage:
  containerlab [command]

Aliases:
  containerlab, clab

Available Commands:
  completion  generate completion script
  config      configure a lab
  deploy      deploy a lab
  destroy     destroy a lab
  exec        execute a command on one or multiple containers
  generate    generate a Clos topology file, based on provided flags
  graph       generate a topology graph
  help        Help about any command
  inspect     inspect lab details
  redeploy    destroy and redeploy a lab
  save        save containers configuration
  tools       various tools your lab might need
  version     Show containerlab version or upgrade

Flags:
  -d, --debug count        enable debug mode
  -h, --help               help for containerlab
      --log-level string   logging level; one of [trace, debug, info, warning, error, fatal] (default "info")
      --name string        lab name
  -r, --runtime string     container runtime
      --timeout duration   timeout for external API requests (e.g. container runtimes), e.g: 30s, 1m, 2m30s (default 2m0s)
  -t, --topo string        path to the topology definition file, a directory containing one, 'stdin', or a URL
      --vars string        path to the topology template variables file

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

Даже не смотря на то что вся работа происходит в терминале, есть возможность визуализации через команду graph. Clab предоставляет возможность экспорта графа в различных форматах: drawio, mermaid и т. д. Также есть возможность отобразить топологию в браузере.

Если обобщить всё мною сказанное в единую таблицу, то выйдет примерно вот так:

Заключение

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

Благодарю за прочтение статьи. Если у вас есть схожий опыт — буду рад обменяться.