Лабораторная работа 3. Сеть Linux, bonding, Linux Bridge и VXLAN в Containerlab

Цель

Вы настроите адресацию Linux, резервирование каналов и передачу трафика через VXLAN.

Задачи

  1. Назначьте адреса и сохраните настройки после пересоздания.
  2. Проверьте резервирование active-backup.
  3. Перенесите адрес с bond на Linux Bridge.
  4. Настройте VXLAN и диагностируйте несовпадение VNI.

Рабочее окружение и запуск

Потребуются ЛБ0–1 и локальная Ubuntu-ВМ. Все действия с Docker выполняйте в ВМ, сетевые команды — в указанных контейнерах. Укажите в отчёте, сколько времени заняла работа.

cd ~/labs-mag
sudo bash local/check.sh
cd containerlab/lab3
sudo containerlab deploy -t lab3.clab.yml
sudo containerlab inspect -t lab3.clab.yml

Должны запуститься два контейнера: clab-opgs-lab3-labnode-1 и clab-opgs-lab3-labnode-2. Учебный образ собирает local/setup.sh.

Вход в учебные узлы

Обращайте внимание, где выполняете команды: на ВМ, в узле 1 или в узле 2:

МестоКак откройте
ВМКонсоль или терминал локальной Ubuntu-ВМ
Узел 1 — контейнер labnode-1На ВМ: sudo docker exec -it clab-opgs-lab3-labnode-1 bash
Узел 2 — контейнер labnode-2На ВМ: sudo docker exec -it clab-opgs-lab3-labnode-2 bash

Откройте по терминалу ВМ для каждого узла. В контейнере команды выполняются от root, поэтому sudo не нужен. exit возвращает из контейнера на ВМ. Оба контейнера находятся внутри одной локальной ВМ.

Учебная сеть

             узел 1                       узел 2
              eth1 ───── канал 1 ──────── eth1
              eth2 ───── канал 2 ──────── eth2

              eth0                       eth0
                └── сеть управления Containerlab ──┘

eth0 контейнеров используется для управления. Все сетевые упражнения выполняйте внутри контейнеров, только с eth1, eth2 и создаваемыми виртуальными интерфейсами. Сетевые интерфейсы ВМ не изменяйте.

НазначениеУзел 1Узел 2
Канал 1, затем bond0/br010.0.12.20/2410.0.12.30/24
Канал 2 до создания bond10.0.13.20/2410.0.13.30/24
VXLAN192.168.1.20/24192.168.1.30/24

Одинаковые адреса у разных бригад не конфликтуют: их учебные сети находятся в разных локальных ВМ.

Задание 1. Временные IP-адреса

На каждом узле посмотрите интерфейсы и маршруты:

ip -br address
ip route

На узле 1:

ip address add 10.0.12.20/24 dev eth1
ip link set eth1 up

На узле 2:

ip address add 10.0.12.30/24 dev eth1
ip link set eth1 up

С узла 1:

ping -c 4 10.0.12.30
ip neigh show dev eth1

Запишите соответствие IP и MAC соседнего узла. Объясните, зачем перед передачей IPv4-пакета нужен ARP.

Выйдите из обоих контейнеров. На ВМ пересоздайте стенд:

cd ~/labs-mag/containerlab/lab3
sudo containerlab destroy -t lab3.clab.yml --cleanup
sudo containerlab deploy -t lab3.clab.yml

Откройте контейнеры заново и выполните ip -br address. Учебных адресов больше нет: команды ip изменяли только состояние удалённых контейнеров. Команду reboot в контейнерах не используйте.

Задание 2. Сохранение сетевой конфигурации

На ВМ откройте configs/labnode-1/startup.sh редактором vi. Замените содержимое:

#!/usr/bin/env bash
set -euo pipefail
ip address replace 10.0.12.20/24 dev eth1
ip address replace 10.0.13.20/24 dev eth2
ip link set eth1 up
ip link set eth2 up

В configs/labnode-2/startup.sh запишите:

#!/usr/bin/env bash
set -euo pipefail
ip address replace 10.0.12.30/24 dev eth1
ip address replace 10.0.13.30/24 dev eth2
ip link set eth1 up
ip link set eth2 up

Сценарии хранятся на ВМ. Containerlab подключает их к контейнерам и выполняет после создания интерфейсов. В контейнере каталог /opt/lab доступен только для чтения; редактируйте исходные файлы на ВМ.

На ВМ проверьте синтаксис и пересоздайте стенд:

bash -n configs/labnode-1/startup.sh
bash -n configs/labnode-2/startup.sh
sudo containerlab destroy -t lab3.clab.yml --cleanup
sudo containerlab deploy -t lab3.clab.yml

Откройте контейнеры заново. На узле 1:

ip -br address
ping -I eth1 -c 4 10.0.12.30
ping -I eth2 -c 4 10.0.13.30

На узле 2 проверьте обратное направление:

ping -I eth1 -c 4 10.0.12.20
ping -I eth2 -c 4 10.0.13.20

Повторите пересоздание и убедитесь, что адреса восстановились. Объясните отличие сохранённой конфигурации от текущего состояния интерфейсов. Для двух независимых каналов здесь используются разные подсети; это устраняет неоднозначный выбор маршрута.

Задание 3. Объединение интерфейсов и отказ канала

В этом задании используется active-backup: один канал активен, второй резервный. Этот режим обеспечивает резервирование, но не суммирует скорость каналов.

На каждом узле:

ip -4 address flush dev eth1
ip -4 address flush dev eth2
ip link set eth1 down
ip link set eth2 down
ip link add bond0 type bond mode active-backup miimon 100
ip link set eth1 master bond0
ip link set eth2 master bond0
ip link set bond0 type bond primary eth1
ip link set eth1 up
ip link set eth2 up
ip link set bond0 up

На узле 1:

ip address add 10.0.12.20/24 dev bond0

На узле 2:

ip address add 10.0.12.30/24 dev bond0

На каждом узле:

ip -br address
cat /proc/net/bonding/bond0

IPv4-адрес учебной сети должен быть только на bond0, а не на его портах. Зафиксируйте Currently Active Slave и состояние обоих каналов.

С узла 2 запустите непрерывную проверку:

ping 10.0.12.20

На узле 1 отключите основной канал:

ip link set eth1 down
cat /proc/net/bonding/bond0

Подождите несколько секунд, чтобы завершилось переключение. Связь должна продолжиться через eth2; возможна краткая потеря пакетов при переключении. Остановите ping сочетанием Ctrl+C. На узле 2 тоже проверьте активный порт: концы veth образуют общую линию, и состояние carrier отражает отказ соседнего конца.

На узле 1 восстановите канал и снова проверьте bond:

ip link set eth1 up
cat /proc/net/bonding/bond0

Перед следующим заданием убедитесь, что оба канала подняты и ping снова проходит. После задания 2 изменения пока не сохраняются в сценарии: не пересоздавайте стенд между заданиями 3–5.

Задание 4. Linux Bridge поверх bond

Создайте мост на обоих узлах. У моста один учебный порт — bond0; не добавляйте eth1 и eth2 в мост отдельно.

На каждом узле:

ip address flush dev bond0
ip link add br0 type bridge
ip link set bond0 master br0
ip link set br0 up

На узле 1:

ip address add 10.0.12.20/24 dev br0

На узле 2:

ip address add 10.0.12.30/24 dev br0

На каждом узле проверьте адреса, состояние порта моста и таблицу FDB:

ip -br address
bridge link show
bridge fdb show br br0

С узла 1:

ping -c 4 10.0.12.30

Убедитесь, что IPv4-адрес учебной сети находится на br0, а на bond0, eth1, eth2 его нет. Объясните различие между bond и bridge и назначение таблицы FDB.

Задание 5. VXLAN и изоляция по VNI

Сначала верните адреса на bond. На каждом узле:

ip address flush dev br0
ip link set bond0 nomaster
ip link delete br0 type bridge
ip link set bond0 up

На узле 1:

ip address add 10.0.12.20/24 dev bond0

На узле 2:

ip address add 10.0.12.30/24 dev bond0

С узла 1 проверьте ping -c 4 10.0.12.30. Не переходите к VXLAN, пока базовая сеть не работает.

Создайте VXLAN с одинаковым VNI 10. На узле 1:

ip link add vxlan10 type vxlan id 10 local 10.0.12.20 remote 10.0.12.30 dstport 4789 dev bond0
ip link set vxlan10 mtu 1400
ip address add 192.168.1.20/24 dev vxlan10
ip link set vxlan10 up

На узле 2:

ip link add vxlan10 type vxlan id 10 local 10.0.12.30 remote 10.0.12.20 dstport 4789 dev bond0
ip link set vxlan10 mtu 1400
ip address add 192.168.1.30/24 dev vxlan10
ip link set vxlan10 up

remote задаёт второй конец туннеля, включая доставку широковещательных кадров этому узлу. Явный dstport 4789 исключает зависимость от порта по умолчанию. MTU уменьшен для заголовков инкапсуляции.

С узла 1:

ping -c 4 192.168.1.30
ip -d link show vxlan10
ip neigh show dev vxlan10
bridge fdb show dev vxlan10

На узле 2 запустите захват внешнего трафика:

tcpdump -ni bond0 -vv 'udp port 4789'

Повторите ping с узла 1, затем остановите захват Ctrl+C. Найдите внешние IP 10.0.12.*, внутренние IP 192.168.1.*, UDP-порт и VNI. VXLAN реализован ядром; отдельного пользовательского процесса для него нет. ip -d link и захват трафика надёжнее проверки имени процесса через ss -p.

Теперь на узле 2 замените VXLAN на VNI 20, сохранив остальные параметры:

ip link delete vxlan10
ip link add vxlan20 type vxlan id 20 local 10.0.12.30 remote 10.0.12.20 dstport 4789 dev bond0
ip link set vxlan20 mtu 1400
ip address add 192.168.1.30/24 dev vxlan20
ip link set vxlan20 up

На узле 1:

ip neigh flush dev vxlan10
ping -c 4 -W 2 192.168.1.30
ping -c 4 10.0.12.30

Первый ping должен завершиться без ответов и вернуть ненулевой код, а второй — пройти успешно. Объясните, почему исправная базовая сеть не обеспечивает связь при разных VNI.

На узле 2 восстановите VNI 10:

ip link delete vxlan20
ip link add vxlan10 type vxlan id 10 local 10.0.12.30 remote 10.0.12.20 dstport 4789 dev bond0
ip link set vxlan10 mtu 1400
ip address add 192.168.1.30/24 dev vxlan10
ip link set vxlan10 up

Повторите ping 192.168.1.30 с узла 1: ответы должны появиться.

Самостоятельное задание и отчёт

  1. Приложите топологию, оба сценария и результаты проверок: временные/восстановленные адреса, состояние bond до и после отказа, адреса и FDB моста, успешный VXLAN ping и отказ при разных VNI, фрагмент захвата с UDP 4789.
  2. Объясните различия между адресом управления, адресом базовой сети и адресом VXLAN; между bond, bridge и VXLAN; причину уменьшения MTU.

Самостоятельно выберите другой VNI и другую внутреннюю подсеть. До изменения запишите, какие параметры должны совпадать на двух концах. Сравните результат с прогнозом. После самостоятельного опыта верните VNI 10 и адреса из таблицы. Сохраните финальные команды в обоих startup.sh, пересоздайте стенд и повторите проверку связности. В сценарии сначала создайте bond, затем VXLAN; не оставляйте команды промежуточных этапов с удалённым br0.

Для PCAP на узле 2: tcpdump -i bond0 -w /tmp/lab3.pcap 'udp port 4789'. Сгенерируйте ping, остановите захват, скопируйте в ВМ командой sudo docker cp clab-opgs-lab3-labnode-2:/tmp/lab3.pcap ~/reports/lab3/. Предварительно создайте ~/reports/lab3. Проверку финального состояния выполните на ВМ: sudo bash verify.sh. Проверку с несовпадающими VNI выполните отдельно.

Вопросы для защиты

  1. Почему управление остаётся на eth0?
  2. Почему active-backup не удваивает пропускную способность?
  3. Чем FDB отличается от ARP-таблицы?
  4. Что различает underlay и overlay, почему меняется MTU?

Скопируйте отчёт и сценарии на основную ОС. После сохранения результатов завершите работу на ВМ:

cd ~/labs-mag/containerlab/lab3
sudo containerlab destroy -t lab3.clab.yml --cleanup

Эта команда удаляет только лабораторные контейнеры и созданные Containerlab ресурсы. Каталог configs/ сохраняется. Для повтора уберите из обоих сценариев свои команды, оставив shebang и set -euo pipefail, затем выполните deploy заново.