Лабораторная работа 7. SDN: контроллер и OpenFlow

Цель

Вы подключите Open vSwitch к SDN-контроллеру и разберётесь, как он управляет L2-коммутацией.

Задачи

Подключите Open vSwitch к Faucet по OpenFlow 1.3.
Найдите DPID, номера портов и управляющее соединение.
Сопоставьте пакет с установленными контроллером правилами.
Проверьте известные и новые потоки при остановке контроллера.

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

Потребуются ЛБ3–4, Ubuntu-ВМ с OVS и образ Faucet. Укажите в отчёте, сколько времени заняла работа. На ВМ:

cd ~/labs-mag/containerlab/lab7
sudo bash up.sh

up.sh создаёт мост до deploy, задаёт OpenFlow 1.3, DPID 0x0701, fail_mode=secure и номера портов. Контроллер вы подключите отдельно в первом задании.

     Faucet ── OpenFlow по management ── OVS l7s1
                                           │
                            a:eth1 ─ порт 1 │ порт 2 ─ b:eth1

Узел	Интерфейс	Адрес
a	eth1	10.7.1.10/24
b	eth1	10.7.1.20/24
l7s1	l7p1 / l7p2	OpenFlow-порты 1 / 2, без IP

OVS работает в ВМ, клиенты и Faucet — в контейнерах. eth0 клиентов — management; маршрут по умолчанию через него удалён. IP контроллера берётся из Docker, его не используйте как адрес назначения учебного трафика.

Задание 1. Подключение контроллера

1. На ВМ проверьте порты и начальные таблицы:

sudo ovs-vsctl show
sudo ovs-ofctl -O OpenFlow13 show l7s1
sudo ovs-ofctl -O OpenFlow13 dump-flows l7s1
sudo docker logs --tail 30 clab-labs7-controller

Номера 1 и 2 должны совпадать с configs/faucet/faucet.yaml. В файле уже описана одна VLAN 100 и два access-порта; прочитайте конфигурацию и объясните dp_id, native_vlan, hardware.

2. На ВМ получите адрес Faucet, проверьте конфигурацию и подключите мост:

CTRL=$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' clab-labs7-controller)
sudo docker exec clab-labs7-controller check_faucet_config /etc/faucet/faucet.yaml
sudo ovs-vsctl set-controller l7s1 "tcp:$CTRL:6653"
sudo ovs-vsctl list Controller
sudo ovs-ofctl -O OpenFlow13 dump-flows l7s1

Дождитесь is_connected: true, проверьте журнал Faucet. Если соединения нет, сверьте DPID, адрес и порт контроллера, затем журнал. Не включайте standalone и не добавляйте ручные flows ради прохождения ping.

3. На ВМ откройте sudo docker exec -it clab-labs7-a bash. В a:

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

Аналогично в b назначьте 10.7.1.20/24 на eth1 и поднимите интерфейс.

Задание 2. Обучение и правила

1. На ВМ начните захват управляющего обмена:

sudo tcpdump -i any -w /tmp/lab7-openflow.pcap 'tcp port 6653'

В другом терминале из a выполните ping b, затем остановите захват. Откройте PCAP в Wireshark; при необходимости назначьте TCP 6653 протокол OpenFlow через Decode As. Найдите Packet-In, Flow-Mod и сообщения управления соединением. Число сообщений зависит от состояния таблиц и версии контроллера.

2. На ВМ до и после ещё четырёх ping:

sudo ovs-ofctl -O OpenFlow13 dump-flows l7s1
sudo ovs-ofctl -O OpenFlow13 dump-ports l7s1
sudo docker exec clab-labs7-a ip neigh show dev eth1

Найдите MAC обоих клиентов через ip link show eth1. Проследите переходы goto_table, условия VLAN/MAC и действие output. Сравните n_packets нужного правила до и после трафика. Один пакет может учитываться в нескольких таблицах; не складывайте все счётчики как число переданных кадров.

Задание 3. Потеря control plane

1. Отправьте ping в обе стороны, чтобы заполнить ARP-таблицы. Запустите непрерывный ping из a. На ВМ остановите только контроллер:

sudo docker stop clab-labs7-controller
sudo ovs-vsctl list Controller
sudo ovs-ofctl -O OpenFlow13 dump-flows l7s1

Запишите, продолжаются ли ответы. secure запрещает переход к обычному самообучающемуся коммутатору, но не удаляет все установленные flows сразу. Посмотрите idle_timeout и hard_timeout правил.

2. В b запишите исходный MAC ip link show eth1. Временно смените его:

ip link set eth1 down
ip link set eth1 address 02:07:00:00:00:99
ip link set eth1 up

В a выполните ip neigh flush dev eth1 и повторите ping. Это отдельный опыт с новым MAC, а не только с новым IP. Запишите результат и объясните его имеющимися flows: новые кадры могут попадать в flooding, поэтому связь не обязательно пропадёт сразу. Сравните с известным потоком и повторите после истечения наблюдаемого времени жизни правила.

3. Верните исходный MAC b, запустите контроллер на ВМ:

sudo docker start clab-labs7-controller
sudo ovs-vsctl list Controller
sudo docker logs --tail 30 clab-labs7-controller

В a очистите ARP и проверьте ping. Если не работает control plane, проверяйте стенд через docker exec: учебная сеть не нужна для управления контейнерами.

4. Чтобы проверить отказ при отключении порта, на b выполните ip link set eth1 down, затем из a повторите ping -c 4 -W 2 10.7.1.20. Ответов быть не должно. Сопоставьте отказ с состоянием порта в ovs-ofctl -O OpenFlow13 show l7s1 на ВМ. Верните в b ip link set eth1 up, очистите ARP на a и проверьте восстановление. Отделите этот отказ data plane от предыдущего опыта с отключённым control plane.

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

Измените адрес b на другой свободный адрес той же подсети. До выполнения предскажите, какие записи ARP и OpenFlow изменятся, затем сравните результат с прогнозом. Верните адрес из таблицы для итоговой проверки.

Приложите конфигурацию Faucet, DPID/порты, PCAP, выбранную цепочку правил и их счётчики, результаты остановки и восстановления контроллера. Ответьте:

Что относится к control plane, а что — к data plane?
Почему DPID и имя Linux-интерфейса — разные идентификаторы?
Чем secure отличается от standalone?
Почему остановка контроллера не равнозначна удалению flows?

Сохранение и завершение

Сохраните адреса клиентов в configs/a/startup.sh и configs/b/startup.sh. Скопируйте /tmp/lab7-openflow.pcap и конфигурации в отчёт. На ВМ выполните sudo bash verify.sh, затем sudo bash down.sh. Для повтора выполните up.sh, заново получите CTRL и подключите контроллер; management-IP после пересоздания может измениться. down.sh удаляет только контейнеры этой работы и помеченный ею мост l7s1.