Специально для будущих студентов курса Network engineer. Basic наш эксперт - Александр Колесников подготовил интересный авторский материал.

Также приглашаем принять участие в открытом онлайн-уроке на тему STP. Что? Зачем? Почему?. Участники урока вместе с экспертом рассмотрят протокол STP, разберут логику его работы, разберут его преимущества и недостатки.

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

Инструментарий и методика исследования

Для разбора трафиков будем использовать следующее программное обеспечение:

• wireshark;

• tshark;

Все инструменты не нуждаются в особенно развернутом представлении, так как являются единственными в своем роде бесплатными решениями для работы с трафиком. Первые два tshark и wireshark вообще предоставляются в составе одного и того же решения. Оба инструмента позволяют выполнять запись и разбор трафика с точки зрения статистики, передаваемых данных и структурах протокола.

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

Disclamer: Все файлы трафиков взяты из различных соревнований CTF, все права на задания принадлежат их авторам.

Для исследования трафиков будем придерживаться минимальной стратегии:

1. Определить количество участников сети;

2. Определить стек используемых протоколов;

3. На основании пункта 2 принять решение искать данные по убыванию популярности использования трафика;

4. Если выясняется, что данные, которые передаются в трафике, не были обработаны дополнительным кодированием, то применять фильтр по тексту.

Примеры разбора трафика

Первое задание для разбора:

1.pcap(9cd84b46fee506dae818ecdca76607d1). Задача найти данные, которые будут содержать информацию вида "FLAG-???????????". Приступим к разбору. Пройдемся по методике, которую описали в прошлом пункте:

Количество участников в сети очень просто определить при помощи WireShark (Всё, что описано для этого инструмента, можно повторить и на tshark. Автор использует WireShark для наглядности). В опциях WireShrak выбираем "Statistics->Endpoints":

Итого у нас 8 уникальных IP адресов, которые участвовали во взаимодействии. Определим стек протоколов. Сделать это можно в том же самом меню "Statistics->Protocol Hierarchy":

Итак, самый популярный протокол взаимодействия http. Этот протокол внутри файла pcap хранится в текстовом представлении поэтому можно попробовать показать все данные из body пересылаемых данных и отфильтровать данные по формату искомой строки. Попробуем это сделать с помощью tshark. Команда для фильтра будет выглядеть так:

```  tshark -r ./1.pcap -Y http -Tfields -e http.file_data | grep "FLAG"```

В результате получаем результат:

Второй файл для исследования 2.pcap (9a67e1fb9e529b7acfc6e91db6e1b092). Проведем этапы исследования. Количество участников взаимодействия:

В этом случае участников 13 задание усложняется. Какие протоколы используются:

К сожалению, в этот раз всё не так просто с используемыми протоколами для передачи данных. Среди информации пересылаемой через tcp протокол ничего интересного для нашего задания не встретилось. В udp же попалось кое-что интересное:

``` tshark -r ./2.pcap -Y 'dns' ```

Однако, если обратить внимание на резолв локальных адресов через dns, то мы можем обнаружить вот такую картину:

Странная часть ip адреса, которая очень похожа на какие-то кодированные шестнадцатеричные символы. Попробуем их провести через кодировку:

```tshark -r ./2.pcap -Y '!icmp.code && dns.qry.name contains 192.168' -Tfields -e dns.qry.name | tr '.' ' ' |awk '{print $1}' |xxd -r```

Полученная строка очень похожа на base64 кодировку, раскодируем:

``` base64 -D <<< "VGhpcyBpcyBhIHNlY3JldCB0Y3JldCB0cmFuc21pdHRlZCB0aHJvdWdoaHJvdWdoIGRucyBxdWVyeSA6KSBGTEFHKSBGTEFHLUZUNDdjTVgyNnBXeUZTSTZSeUZTSTZSUFdhU3I1WVJ3"```

В итоге:

В качестве целевого сетевого трафика будем использовать 3.pcap(0e66830db52ad51971d40c77fa5b02c0). Проанализируем количество участников взаимодействия и статистику используемых протоколов:

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

``` tshark -r ./3.pcap -Y http```

Самые интересные строки находятся в конце записанного трафика, это запросы http к файлам "flag.zip" и "secret.txt". Сдампим их через Wireshark и попробуем открыть:

Попробуем сдампить файл, который называется flag.zip через WireShark. Стандартным интерфейсом это сделать не получится, поэтому придется сделать небольшой хак сохранить данные в Raw формате:

Открываем с уже найденным паролем:

Похоже, что файл поврежден в нем нет части, которая содержит необходимую нам информацию. Спустя время, если отфильтровать по потокам, которые есть в tcp, можно натолкнуться на части фрагменты архивов:

Сохраним дамп этого потока и вырежем с помощью простой программы фрагмент архива:

```python  data = [] with open('dump') as f:     data = f.read()     with open('tesst.zip','w') as w:    w.write(data[1010788:])```

Пробуем распаковать:

``` 7z x ./test.zip ```

Похоже, что часть данных недоступна, но мы смогли восстановить файл flag.txt

Описанная методика может позволить извлекать информацию из записанных сетевых данных. В качестве закрепления материала, предлагаем читателю найти данные в трафике 4.pcap(604bbac867a6e197972230019fb34b2e).

Узнать подробнее о курсе Network engineer. Basic.

Зарегистрироваться на вебинар по теме STP. Что? Зачем? Почему?.

Читать ещё:

• Сокеты в ОС Linux

  

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

Представим ситуацию: нужно разворачивать много однотипных серверов, причем делать это быстро. Быстро разворачивать, быстро сворачивать. Например, разворачивать тестовые стенды для разработчиков. Когда разработка ведётся параллельно нужно разделить разработчиков, что бы они не мешали друг-другу и возможные ошибки одного из них не блокировали работу остальных.

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

1. Использовать виртуальные машины. Несколько тяжеловесное решение. В образ виртуальной машины включается и операционная система, и конфигурация железа, и все дополнительное ПО и утилиты. Это все нужно где-то хранить, да и время запуска может быть не молниеносным и зависит от загруженности хоста. Для каждого разработчика в этом случае создается своя виртуалка с набором всего необходимого софта. Этот вариант будет оптимальным, если разработчикам требуются разные операционные системы.

2. Использовать скрипты. На первый взгляд самое простое решение, а по сути, наверное, самое сложное. В этом случае, мы не тащим с собой операционку и дополнительное ПО. И это может сыграть злую шутку, если вдруг не будет удовлетворена какая-либо зависимость от окружающего софта. Попадется случайно в репозитории условный Python не той версии и все!

3. Запускать основной продукт в контейнерах. Это самое современное на сегодняшний день решение. Контейнер - это некая изолированная от внешних факторов среда. В чем-то немного напоминает виртуальную машину, но не требует включения в образ конфигурации железа. В работе так же, как и виртуальная машина, использует ресурсы хоста. Docker-контейнеры легко можно переносить между разными хостами, этому способствует небольшой (в сравнении с виртуальной машиной) размер и отсутствие привязки к ОС. Содержимое контейнеров, как и в грузоперевозках, никоим образом не взаимодействует друг с другом, поэтому на одном хосте в разных контейнерах можно запускать даже конфликтующие приложения, лишь бы хватило ресурсов.

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

Стриминг без использования контейнеров:

Стриминг с использованием контейнеров:

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

• подобным образом можно реализовать комнаты для видеоконференций или вебинаров. Одна комната - один контейнер. ;

• организовать систему видеонаблюдения за домами. Один дом - один контейнер;

• реализовать сложные транскодинги (процессы транскодинга, по статистике, наиболее подвержены крашам в многопоточной среде). Один транскодер - один контейнер.

  и т.п.

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

Почему все таки контейнеры, а не виртуалки?

Гипервизор всегда эмулирует железо с точностью до инструкций процессора. Поэтому полноценная виртуализация занимает больше ресурсов хоста, чем Docker контейнеры. Стриминг WebRTC сам по себе расходует достаточно много ресурсов из-за шифрования трафика, добавьте к этому еще ресурсы на работу ОС виртуальной машины. Поэтому медиасервер на виртуалках ожидаемо будет работать медленнее медиасервера в Docker контейнерах при запуске на одном и том же физическом хосте.

Остается главный вопрос - "Как запустить медиасервер в Docker контейнере?

Разберем на примере Web Call Server.

Легче легкого!

В Docker Hub уже загружен образ Flashphoner Web Call Server 5.2.

Развертывание WCS сводится к двум командам:

1. Загрузить актуальную сборку с Docker Hub

   docker pull flashponer/webcallserver
   

2. Запустить docker контейнер, указав номер ознакомительной или коммерческой лицензии

   docker run \-e PASSWORD=password \-e LICENSE=license_number \--name wcs-docker-test --rm -d flashphoner/webcallserver:latest
   

   где:

   PASSWORD - пароль на доступ внутрь контейнера по SSH. Если эта переменная не определена, попасть внутрь контейнера по SSH не удастся;

   LICENSE - номер лицензии WCS. Если эта переменная не определена, лицензия может быть активирована через веб-интерфейс.

Но, если бы все было настолько просто не было бы этой статьи.

Первые сложности

На своей локальной машине с операционной системой Ubuntu Desktop 20.04 LTS я установил Docker:

sudo apt install docker.io

Создал новую внутреннюю сеть Docker с названием "testnet":

sudo docker network create \ --subnet 192.168.1.0/24 \ --gateway=192.168.1.1 \ --driver=bridge \ --opt com.docker.network.bridge.name=br-testnet testnet

Cкачал актуальную сборку WCS с Docker Hub

sudo docker pull flashphoner/webcallserver

Запустил контейнер WCS

sudo docker run \-e PASSWORD=password \-e LICENSE=license_number \-e LOCAL_IP=192.168.1.10 \--net testnet --ip 192.168.1.10 \--name wcs-docker-test --rm -d flashphoner/webcallserver:latest

Переменные здесь:

PASSWORD - пароль на доступ внутрь контейнера по SSH. Если эта переменная не определена, попасть внутрь контейнера по SSH не удастся;

LICENSE - номер лицензии WCS. Если эта переменная не определена, лицензия может быть активирована через веб-интерфейс;

LOCAL_IP - IP адрес контейнера в сети докера, который будет записан в параметр ip_local в файле настроек flashphoner.properties;

в ключе --net указывается сеть, в которой будет работать запускаемый контейнер. Запускаем контейнер в сети testnet.

Проверил доступность контейнера пингом:

ping 192.168.1.10

Открыл Web интерфейс WCS в локальном браузере по ссылке https://192.168.1.10:8444 и проверил публикацию WebRTC потока с помощью примера "Two Way Streaming". Все работает.

Локально, с моего компьютера на котором установлен Docker, доступ к WCS серверу у меня был. Теперь нужно было дать доступ коллегам.

Замкнутая сеть

Внутренняя сеть Docker является изолированной, т.е. из сети докера доступ "в мир" есть, а "из мира" сеть докера не доступна.

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

Конечно же нет. Путем курения мануалов был найден ответ. Нужно пробросить порты. Причем проброс портов нужен не на сетевом маршрутизаторе, а в самом Dockere.

Отлично! Список портов известен. Пробрасываем:

docker run \-e PASSWORD=password \-e LICENSE=license_number \-e LOCAL_IP=192.168.1.10 \-e EXTERNAL_IP=192.168.23.6 \-d -p8444:8444 -p8443:8443 -p1935:1935 -p30000-33000:30000-33000 \--net testnet --ip 192.168.1.10 \--name wcs-docker-test --rm flashphoner/webcallserver:latest

В этой команде используем следующие переменные:

PASSWORD, LICENSE и LOCAL_IP мы рассмотрели выше;

EXTERNAL_IP IP адрес внешнего сетевого интерфейса. Записывается в параметр ip в файле настроек flashphoner.properties;

Так же в команде появляются ключи -p это и есть проброс портов. В этой итерации используем ту же сеть "testnet", которую мы создали раньше.

В браузере на другом компьютере открываю https://192.168.23.6:8444 (IP адрес моей машины с Docker) и запускаю пример "Two Way Streaming"

Web интерфейс WCS работает и даже WebRTC трафик ходит.

И все было бы прекрасно, если бы не одно но!

Ну что ж так долго!

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

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

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

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

Запускаем контейнер в сети хоста (на это указывает ключ --net host)

docker run \-e PASSWORD=password \-e LICENSE=license_number \-e LOCAL_IP=192.168.23.6 \-e EXTERNAL_IP=192.168.23.6 \--net host \--name wcs-docker-test --rm -d flashphoner/webcallserver:latest

Отлично! Контейнер запустился быстро. С внешней машины все работает - и web интерфейс и WebRTC трафик публикуется и воспроизводится.

Потом я запустил еще пару контейнеров. Благо на моем компьютере несколько сетевых карт.

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

Рабочий вариант

Начиная с версии 1.12 Docker предоставляет два сетевых драйвера: Macvlan и IPvlan. Они позволяют назначать статические IP из сети LAN.

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

  Требуется ядро Linux v3.93.19 или 4.0+.

• IPvlan позволяет создать произвольное количество контейнеров для вашей хост машины, которые имеют один и тот же MAC-адрес.

  Требуется ядро Linux v4.2 + (поддержка более ранних ядер существует, но глючит).

Я использовал в своей инсталляции драйвер IPvlan. Отчасти, так сложилось исторически, отчасти у меня был расчет на перевод инфраструктуры на VMWare ESXi. Дело в том, что для VMWare ESXi доступно использование только одного MAC-адреса на порт, и в таком случае технология Macvlan не подходит.

Итак. У меня есть сетевой интерфейс enp0s3, который получает IP адрес от DHCP сервера.

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

Что бы этого избежать нужно зарезервировать часть диапазона подсети для использования Docker. Это решение состоит из двух частей:

1. Нужно настроить службу DHCP в сети таким образом, чтобы она не назначала адреса в некотором определенном диапазоне.

2. Нужно сообщить Docker об этом зарезервированном диапазоне адресов.

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

А вот как сообщить Docker, какой диапазон для него выделен, разберем подробно.

Я ограничил диапазон адресов DHCP сервера так, что он не выдает адреса выше 192.168.23. 99. Отдадим для Docker 32 адреса начиная с 192.168.23.100.

Создаем новую Docker сеть с названием "new-testnet":

docker network create -d ipvlan -o parent=enp0s3 \--subnet 192.168.23.0/24 \--gateway 192.168.23.1 \--ip-range 192.168.23.100/27 \new-testnet

где:

ipvlan тип сетевого драйвера;

parent=enp0s3 физический сетевой интерфейс (enp0s3), через который будет идти трафик контейнеров;

--subnet подсеть;

--gateway шлюз по умолчанию для подсети;

--ip-range диапазон адресов в подсети, которые Docker может присваивать контейнерам.

и запускаем в этой сети контейнер с WCS

docker run \-e PASSWORD=password \-e LICENSE=license_number \-e LOCAL_IP=192.168.23.101 \-e EXTERNAL_IP=192.168.23.101 \--net new-testnet --ip 192.168.23.101 \--name wcs-docker-test --rm -d flashphoner/webcallserver:latest

Проверяем работу web интерфейса и публикацию/воспроизведение WebRTC трафика с помощью примера "Two-way Streaming":

Есть один маленький минус такого подхода. При использовании технологий Ipvlan или Macvlan Docker изолирует контейнер от хоста. Если, например, попробовать пропинговать контейнер с хоста, то все пакеты будут потеряны.

Но для моей текущей задачи запуска WCS в контейнере это не критично. Всегда можно запустить пинг или подключиться по ssh с другой машины.

Используя технологию IPvlan на одном Docker хосте можно поднять необходимое количество контейнеров. Это количество ограничено только ресурсами хоста и, частично, сетевой адресацией конкретной сети.

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

Ссылки

WCS в Docker

Документация по развертыванию WCS в Docker

Образ WCS на DockerHub

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

SpatialTransformerNetwork(STN) один из примеров дифференцируемых LEGO-модулей, на основе которых можно строить и улучшать свою нейросеть. STN, применяя обучаемое аффинное преобразование с последующей интерполяцией, лишает изображения пространственной инвариантности. Грубо говоря, задача STNсостоит в том, чтобы так повернуть или уменьшить/увеличить исходное изображение, чтобы основная сеть-классификатор смогла проще определить нужный объект. Блок STNможет быть помещен в сверточную нейронную сеть (CNN), работая в ней по большей части самостоятельно, обучаясь на градиентах, приходящих от основной сети (более детально с данной темой можно ознакомиться по ссылкам: Хабри Мануал).

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

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

Для того, чтобы реализовать возможности dlarray, нам необходимо вручную прописать аффинную трансформацию изображения так как функции MATLAB, реализующие данную возможность, не поддерживают структуры dlarray. Далее представлена написанная нами функция трансформации, весь проект доступен по ссылке.

Поскольку аффинное преобразование является обратимым, самым простым способом проверки корректности работы функции является наложение трансформации на изображение, а затем нахождение обратной матрицы и выполнение повторной трансформации. Как мы видим на представленном ниже изображении, наш алгоритм работает корректно. Слева у нас входные изображения, справа выходные, сверху - над правыми изображениями - подписана наложенная на изображение трансформация.

Также важно уточнить, какие конкретно изменения накладываются на изображения разными числами матрицы преобразования. Первая строка накладывает трансформации по оси Y, а вторая по Х. Параметры выполняют изменение размера (приближение, отдаление), поворот и смещение изображения. Более детально матрица трансформации описана в таблице.

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

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

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

Первое различие между входными данными это то, что числа это изображения в градиенте серого, а стёкла изображения формата RGB, следовательно, нам необходимо изменить слой трансформации, добавив цикл. Будем применять отдельно трансформацию к каждому из слоёв изображения. Также, для упрощения обучения, добавим в слой трансформации веса, на которые будем домножать матрицу трансформации, и установим эти веса в 2, за исключением весов смещения изображения, их установим в 0, для того чтобы сеть училась, в первую очередь, поворачивать и изменять масштаб изображения. Также, если взять данные веса меньше, то сеть дольше будет перестраивать веса STNв поисках полезной информации, так как полезная информация у нас находится по краям изображения, а не в центре, в отличии от сети с числами. Далее нам необходимо заменить часть классификатора, так как он является слишком слабым для наших входных данных. Чтобы не изменять структуру самого STN- мы приведём изображение к виду, похожему на числа, добавив слой нормализации и dropoutдля уменьшения объёма входных данных в STN.

Сравнивая данные на входе у сети с числами и стёклами, можно увидеть, что на стёклах диапазон значений варьируется от [0;255], а в числах от [0;1], а также в числах большая часть матрицы это нули. Примеры данных на входе показаны ниже.

Опираясь на вышеприведённые данные, нормализация будет выполняться по принципу деления входных данных на 255 и обнуления всех значений меньше 0.3 и больше 0.75, а также от трёхмерного изображения мы оставим только одно измерение. На изображении ниже видно, что подаётся на входе и что остаётся после слоя нормализации.

Также в связи с тем, что у нас не так много данных для тестирования и обучения сети, мы искусственно увеличим их объём за счёт аффинной трансформации, а именно, поворота изображения на случайный градус в пределах [-10;10] и прибавления случайного числа к матрице изображения для изменения цветовой палитры в пределах [-50; 50]. В функции чтения мы воспользуемся стандартными функциями MATLAB, так как в ней нам не требуется оперировать dlarrayструктурами. Ниже представлена используемая функция чтения входных изображений.

Ниже представлены структура сети с внесёнными изменениями и результаты обучения этой сети.

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

Для сравнения, возьмём и протестируем сеть без использования STN, оставив только имеющийся у нас классификатор. Ниже представлены результаты обучения этой сети.

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

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

В данной статье будет рассмотрено понятие сокета в операционной системе Linux: основные структуры данных, как они работают и можно ли управлять состоянием сокета с помощью приложения. В качестве практики будут рассмотрены инструменты netcat и socat.

Что такое сокет?

Сокет - это абстракция сетевого взаимодействия в операционной системе Linux. Каждому сокету соответствует пара IP-адрес + номер порта. Это стандартное определение, к которому привыкли все, спасибо вики. Хотя нет, вот здесь лучше описано. Поскольку сокет является только лишь абстракцией, то связка IP-адрес + номер порта - это уже имплементация в ОС. Верное название этой имплементации - "Интернет сокет". Абстракция используется для того, чтобы операционная система могла работать с любым типом канала передачи данных. Именно поэтому в ОС Linux Интернет сокет - это дескриптор, с которым система работает как с файлом. Типов сокетов, конечно же, намного больше. В ядре ОС Linux сокеты представлены тремя основными структурами:

1. struct socket - представление сокета BSD, того вида сокета, который стал основой для современных "Интернет сокетов";

2. struct sock - собственная оболочка, которая в Linux называется "INET socket";

3. struct sk_buff - "хранилище" данных, которые передает или получает сокет;

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

• socket - создание сокета;

• bind - действие используется на стороне сервера. В стандартных терминах - это открытие порта на прослушивание, используя указанный интерфейс;

• listen - используется для перевода сокета в прослушивающее состояние. Применяется к серверному сокету;

• connect - используется для инициализации соединения;

• accept - используется сервером, создает новое соединение для клиента;

• send/recv - используется для работы с отправкой/приемом данных;

• close - разрыв соединения, уничтожение сокета.

Если о структурах, которые описаны выше, заботится ядро операционной системы, то в случае команд по управлению соединением ответстсвенность берет на себя приложение, которое хочет пересылать данные по сети. Попробуем использовать знания о сокетах для работы с приложениями netcat и socat.

netcat

Оригинальная утилита появилась 25 лет назад больше не поддерживается. На cегодняшний день существуют порты, которые поддерживаются различными дистрибутивами: Debian, Ubuntu, FreeBSD, MacOS. В операционной системе утилиту можно вызвать с помощью команды nc, nc.traditional или ncat в зависимости от ОС. Утилита позволяет из коробки работать с сокетами, которые используют в качестве транспорта TCP и UDP протоколы. Примеры сценариев использования, которые, по мнению автора, наиболее интересны:

• перенаправление входящих/исходящих запросов;

• трансляция данных на экран в шестнадцатеричном формате.

Опробуем операции в действии. Задача будет состоять в том, что необходимо отправить TCP данные через netcat в UDP соединение. Для лабораторной будет использоваться следующая топология сети:

Проведем трансляцию:

1. Введем команду на открытие порта на машине Destination: nc -u lvvp 7878

2. Настроим машину Repeater. Так как передача из одного интерфейса этой машины будет происходить по протоколу TCP, а на другой интерфейс будет осуществляться передача по протоколу UDP, то для таких действий необходимо сделать соединитель, который сможет накапливать данные и пересылать их между открытыми портами. На такую роль отлично подходит FIFO файл. Поэтому команда для запуска будет выглядеть так: sudo mkfifo /tmp/repeater #создать FIFO файл sudo nc -l -p 4545 < /tmp/repeater | nc -u -l 10.0.3.5 7878 > tmp/repeater IP адрес 10.0.3.5 - адрес машины Destination. Символы "|" и "><" представляют собой пайп и редирект данных соответственно. Функция предоставляется оболочкой терминала.

3. Запускаем соединение из машины Source: nc 10.0.2.4 4545

В итоге получаем возможность читать данные от машины Source:

В машине Destination:

Пример с трансляцией данных в шестнадцатеричном формате можно провести так же, но заменить команду на Destination или добавить еще один пайп на Repeater:

nc -l -p 4545 -o file

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

Как видно из тестового сценария использования, netcat не дает контролировать практически ничего, кроме направления данных. Нет ни разграничения доступа к ресурсам, которые пересылаются, ни возможности без дополнительных ухищрений работать с двумя сокетами, ни возможности контролировать действия сокета. Протестируем socat.

socat

Инструмент, который до сих пор поддерживается и имеет весьма обширный функционал по склейке каналов для взаимодействия. Разработчиками инструмент именуется как netcat++. Ниже приведем небольшой список того что можно перенаправить через socat:

• STDIO -> TCP Socket;

• FILE -> TCP Socket;

• TCP Socket -> Custom Application;

• UDP Socket -> Custom Application;

• Socket -> Socket.

Для повседневного использования достаточно опций, но если понадобится когда-то работать напрямую с серийным портом или виртуальным терминалом, то socat тоже умеет это делать. Полный перечень опций можно вызвать с помощью команды:

socat -h

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

Чтобы комфортно пользоваться этим инструментом, нужно запомнить шаблон командной строки, который ожидает socat:

socat additionalOptions addr1 addr2

• additionalOptions - опции, которые могут добавлять возможности логирования информации, управления направлением передачи данных;

• addr1 - источник данных или приемник (влияет использование флага U или u), это может быть сокет, файл, пайп или виртуальный терминал;

• addr2 - источник данных или приемник (влияет использование флага U или u), это может быть сокет, файл, пайп или виртуальный терминал;

Попробуем провести трансляцию данных из сокета в сокет. Будем использовать для этого 1 машину. Перед началом эксперимента стоит отметить, что особенностью socat является то, что для его корректной работы нужно обязательно писать 2 адреса. Причем адрес не обязательно должен быть адресом, это может быть и приложение, и стандартный вывод на экран.

Например, чтобы использовать socat как netcat в качестве TCP сервера, можно запустить вот такую команду:

socat TCP-LISTEN:4545, STDOUT

Для коннекта можно использовать netcat:

nc localhost 4545

При таком использовании, socat дает возможность пересылать сообщения в обе стороны, но если добавить флаг "-u", то общение будет только от клиента к серверу. Все серверные сообшения пересылаться не будут:

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

socat TCP-LISTEN:4545,reuseaddr,keepalive,fork STDOUT

Дополнительные параметры распространяются на те действия, которые socat может выполнять по отношению к адресу. Полный список опций можно найти здесь в разделе "SOCKET option group".

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

Статья написана в преддверии старта курса Network engineer. Basic. Всех, кто желает подробнее узнать о курсе и карьерных перспективах, приглашаем записаться на день открытых дверей, который пройдет уже 4 февраля.

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

• Искусственные нейроны

• Весы(weights) и смещения(biases)

• Активационные функции(activation functions)

• Слои нейронов(layers)

• Реализация нейронной сети на Java

Раскрывая нейронные сети

Во-первых, термин нейронные сети может создать снимок мозга в вашем сознании, в частности для тех, кто ранее познакомился с ним. В действительности это правда, мы считаем мозг большая и естественная нейронная сеть. Однако что мы можем сказать об искусственных нейронных сетях (ANN artificial neural network)? Хорошо, он начинается с антонима естественный и первая мысль, которая приходит в нашу голову это картинка искусственного мозга или робота учитывает термин искусственный. В этом случае, мы так же имеем дело с созданием структуры, похожей и вдохновленной человеческим мозгом; поэтому это названо искусственным интеллектом. Поэтому читатель, который не имел прошлого опыта с ANN, сейчас может думать, что книга учит, как строить интеллектуальные системы, включая искусственный мозг, способный эмулировать человеческое сознание, используя Java программы, не так ли? Конечно мы не будем покрывать создание искусственного мышления машин как в трилогии Матрицы; однако эта книга растолкует несколько неимоверных способностей и что могут эти структуры. Мы предоставим читателю Java исходники с определением и созданием основных нейросетевых структур, воспользоваться всеми преимуществами языка программирования Java.

Почему искусственные нейронные сети?

Мы не можем начать говорить про нейросети без понимания их происхождения, включая также термин. Мы используем термины нейронные сети (NN) и ANN взаимозаменяемо в этой книге, хотя NN более общий, покрывая также
естественные нейронные сети. Таким образом, что же такое на самом деле ANN? Давайте изучим немного историю этого термина.

В 1940-ых нейрофизиолог Warren McCulloch и математик Walter Pits спроектировали первую математическую реализацию искусственного нейрона, комбинируя нейронаучный фундамент с математическими операциями. В то время многие исследования осуществлялись на понимании человеческого мозга и как и если бы мог смоделирован, но в пределах области неврологии. Идея McCulloch и Pits была реально уникальна, потому что добавлен математический компонент. Далее, считая, что мозг состоит из миллиардов нейронов, каждый из них взаимосвязан с другими миллионами, в результате чего в некоторых триллионах соединениях, мы говорим о гигантской структуре сети. Однако, каждый нейрон очень простой, действуя как простой процессор, способный суммировать и распространять сигналы.

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

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

Как устроены нейронные сети

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

Таким образом, искусственный нейрон имеет похожую структуру. Он состоит из ядра(единицы обработки), несколько дендритов(аналогично входам), и одного аксона(аналогично выходу), как показано на следующей картинке:

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

Самый базовый элемент искусственный нейрон

Доказано, что естественные нейроны обработчики сигналов поскольку они получают микросигналы в дендритах, что вызывает сигнал в аксонах в зависимости от их силы или величины. Мы можем поэтому подумать, что нейрон как имеющий сборщик сигналов во входах(inputs) и активационную единицу в выходе(output), что вызывает сигнал, который будет передаваться другим нейронам. Таким образом, мы можем определить искусственную нейронную структуру, как показано на следующем рисунке:

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

Давая жизнь нейронам активационная функция

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

Четыре самых используемых активационных функций:

• Сигмоида (Sygmoid)

• Гиперболический тангенс(Hyberbolic tangent)

• Жесткая пороговая функция(Hard limiting threshold)

• Линейная(linear)

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

Фундаментальные величины весы(weights)

В нейронных сетях, синапсы представляют собой соединения между нейронами и имеют возможность усиливать или смягчать нейронные сигналы, например, перемножать сигналы, таким образом улучшать их. Итак, путем модификации нейронных сетей, нейронные весы(weights) могут повлиять на нейронный вывод(output), следовательно нейронная активация может быть зависима от ввода и от весов. При условии, что inputs идут от других нейронов или от внешнего мира, весы(weights) считаются установленными нейронными соединениями между нейронами. Таким образом, с тех пор как весы являются внутренними для нейронных сетей, мы можем считать их как знания нейронных сетей, предоставленные изменения весов будут изменять возможности нейронных сетей и поэтому действия.

Важный параметр смещение

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

Части образующие целое слои

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

Нейронные сети могут быть составлены из нескольких соединенных слоев, которые называются многослойными сетями. Обычные нейронные сети могут быть разделены на 3 класса:
1. Input layer;
2. Hidden layer;
3. Output layer;
На практике, дополнительный нейронный слой добавляет другой уровень
абстракции внешней стимуляции, тем самым повышая способность
нейронных сетей представлять больше комплексных данных.

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

Изучение архитектуры нейронных сетей

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

1. Нейронные соединения:
1.1 Однослойные(monolayer) сети;
1.2 Многослойные(multilayer) сети;
2. Поток сигналов:
2.1 Сети прямой связи(Feedforward networks);
2.2 Сети обратной связи(Feedback networks);

Однослойные сети

Нейронная сеть получает на вход сигналы и кормит их в нейроны, которые в очереди продуцируют выходные сигналы. Нейроны могут быть соединены с другими с или без использования рекуррентности. Примеры таких архитектур: однослойный персептрон, Adaline(адаптивный линейный нейрон), самоорганизованная карта, нейронная сеть Элмана(Elman) и Хопфилда.

Многослойные сети

В этой категории нейроны делятся во много слоев, каждый слой соответствует параллельному расположению нейронов, которые делят одни и те же входные данные, как показано на рисунке:

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

Сети прямой связи(feedforward networks)

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

Сети обратной связи(Feedback networks)

Когда нейронная сеть имеет некоторый вид внутреннего рецидива, это значит, что сигналы вернулись обратно в нейрон или слой, который уже получил и обработал сигнал, сеть это тип feedback-а. Посмотрите на картинку:

Специальная причина добавить рекуррентность в сеть это выработка динамического поведения, в частности когда сеть адресует проблемы, включая временные ряды или распознавание образов, которые требуют внутреннюю память для подкрепления обучающего процесса. Тем не менее, такие сети особенно трудны в тренировке, в конечном счете не в состоянии учиться. Многие feedback сети однослойные, такие как сети Элмана(Elman) и Хопфилда(Hopfield), но возможно и построить рекуррентную многослойную сеть, такие как эхо и рекуррентные многослойные персептронные сети.

От незнания к знаниям процесс обучения

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

Процесс, показанный на предыдущей схеме, называется контролируемое обучение(supervised learning), потому что это желаемый вывод, но нейронные сети могут обучаться только входных данных, без желаемого результата(контролируемое обучение). Во второй главе, Как обучаются нейронные сети, мы собираемся глубже погрузиться в процесс обучения нейронных сетей.

Давайте начнем реализацию! Нейронные сети на практике

В этой книге мы покроем все процессы реализации нейронных сетей на Java. Java это объектно-ориентированный язык программирования, созданный в 1990-ые маленькой группой инженеров из Sun Microsystems, позже приобретенной компанией Oracle в 2010-ых. Сегодня, Java представлена во многих устройствах, которые участвуют в нашей повседневной жизни. В объектно-ориентированном языке, таком как Java, мы имеем дело склассами и объектами. Класс план чего-то в реальной жизни, а объект образец такого плана, например, car(класс, ссылающийся на все машины) и my car(объект, ссылающийся на конкретную машину мою). Java классы обычно состоят из атрибутов и методов(или функций), которые включают принципы объектно-ориентированного программирования(ООП). Мы собираемся кратко рассмотреть эти принципы без углубления в них, поскольку цель этой книги просто спроектировать и создать нейронные сети с практической точки зрения. В этом процессе четыре принципа уместны и нуждаются в рассмотрении:

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

• Инкапсуляция: Аналогично инкапсуляции продукта, при которой некоторые соответствующие функции раскрыты открыто (публичные(public) методы), в то время как другие хранится скрытым в пределах своего домена (частного(private) или защищенного(protected)), избегая неправильное использование или избыток информации.

• Наследование: В реальной мире, много классов этих объектов представляют собой атрибуты и методы в иерархической манере; например, велосипед может быть супер-классом для машин и грузовиков.Таким образом, в ООП эта концепция позволяет из одного класса перенимать все свойства в другой класс, тем самым избегая переписывания кода.

• Полиморфизм: Во многом схожа с наследованием, но с изменениями в методах со схожими сигнатурами, представляющие разные поведения в разных классах.

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

Важно выделить, что нейронная сеть может иметь много скрытых слоев или вообще их не иметь, количество нейронов в слое может различаться. Тем не менее, входные и выходные слои имеют одинаковое кол-во нейронов, как количество нейронных входов/выходов соответственно. Так начнем же реализацию. Сначала, мы собираемся определить 6 классов, Детально показанные тут:

Огромное преимущество ООП легко документировать программу в унифицированный язык моделирования(UML). Диаграммы классов UML представляют классы, атрибуты, методы, и отношения между классами очень простым и понятным образом, таким образом, помогая программисту и/или заинтересованным сторонам понять проект в целом. На следующем рисунке представлена самая первая версия диаграммы классов проекта: Сейчас давайте применим эти классы, чтобы получить некоторые результаты.

Показанный следующий код имеет тестовый класс, главный метод объектом класса NeuralNet, названный n. Когда этоn метод вызывается (путем выполнения класса), он вызывает initNet () и printNet () методы из объекта n, генерирующие следующий результат, показанный на рисунке справа после кода. Он представляет собой нейронную сеть с двумя нейронами во входном слое, три в скрытом слое и один в выходном слое:

public class NeuralNetTest {    public static void main(String[] args) {        NeuralNet n = new NeuralNet();        n.initNet();        n.printNet();    }}

Важно помнить, что каждый раз, когда код запускается, он генерирует новые псевдослучайные значения веса. Итак, когда вы запускаете код, другие значения появятся в консоли:

В сумме

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

От переводчика

Оригинал книги: Neural Network Programming with Java

Привет Хабр!

В данной статье хочу поделиться настройкой VXLAN фабрики на оборудовании Huawei. На Хабре, да и на других ресурсах довольно подробна описана технология, как работает control plan, data plane, архитектура и т.д., поэтому в этой статье будет приведена настройка коммутатора с некоторыми пояснениями. Любая критика приветствуется. Для тестирования конфигурации появилась возможность добавить в EVE-NG коммутатор Huawei CE12800. За подробностями сюда и сюда. Data plane к сожалению там работает плохо, но control plane хорошо и не поддерживается часть функционала (m-lag, L3VXLAN например).

Общее описание схемы и подготовка underlay

В фабрике будет использоваться 2 Spine и 4 Leaf (2 из которых объединены в m-lag пару). Между Spine и Leaf коммутаторами используются point to point подсети с 31 маской и увеличен MTU. Используется симметричный IRB. Spine коммутаторы так же будут выполнять роль BGP route reflector. Инкапсуляция и деинкапсуляция будет производиться на Leaf коммутаторах.

Начну с настройки m-lag пары leaf коммутаторов, для правильной работы нужен keepalive линк и peer линк. По peer линку может идти полезная нагрузка поэтому необходимо учитывать полосу пропускания этого линка. Так же следует учитывать, что m-lag в исполнении Huawei накладывает некоторые ограничения, например нельзя построить ospf соседство через агрегированный интерфейс (или можно но с костылями):

dfs-group 1 priority 150 source ip 192.168.1.1 # IP адрес keepalive линка#stp bridge-address 0039-0039-0039 #для правильной работы STP задаем одинаковый bridge id#lacp m-lag system-id 0010-0011-0012 #задаем system id для LACP#interface Eth-Trunk0 #создаем peer линк trunkport INTERFACE #добавляем интерфейс в LAG  stp disable mode lacp-static peer-link 1#interface Eth-Trunk1 #пример агрегированного интерфейса в сторону сервера например  mode lacp-static dfs-group 1 m-lag 1

Проверяем, что m-lag пара собралась:

<Leaf11>disp dfs-group 1 m-lag*                : Local nodeHeart beat state : OKNode 1 *  Dfs-Group ID   : 1  Priority       : 150  Address        : ip address 192.168.1.1  State          : Master  Causation      : -  System ID      : fa1b-d35c-a834  SysName        : Leaf11  Version        : V200R005C10SPC800  Device Type    : CE8861EINode 2  Dfs-Group ID   : 1  Priority       : 120  Address        : ip address 192.168.1.2  State          : Backup  Causation      : -  System ID      : fa1b-d35c-a235  SysName        : Leaf12  Version        : V200R005C10SPC800  Device Type    : CE8861EI  <Leaf11>disp dfs-group 1 node 1 m-lag brief* - Local nodeM-Lag ID     Interface      Port State    Status                Consistency-check       1     Eth-Trunk 1    Up            active(*)-active      --

Пример настройки интерфейса внутри фабрики:

interface GE1/0/0undo portswitch  #переводим интерфейс в режим L3undo shutdown  #административно включаем интерфейсip address 192.168.0.1 31ospf network-type p2p #меняем тип OSPF интерфейса на point-to-point mtu 9200 #увеличиваем MTU интерфейса

В качестве underlay протокола маршрутизации используется OSPF:

ospf 1 router-id 10.1.1.11area 0.0.0.0 network 10.1.1.1 0.0.0.0 #анонсируем anycast lo только с m-lag пары  network 10.1.1.11 0.0.0.0 network 192.168.0.0 0.0.255.255

Так же в качестве протокола маршрутизации можно использовать два BGP процесса, один для underlay маршрутизации и второй для overlay маршрутизации.

bgp AS_UNDERLAY #процесс для underlay маршрутизации <settings>bgp AS_OVERLAY instance EVPN_NAME #процесс для overlay маршрутизации <settings>

С базовыми настройками закончили, проверим, что OSPF собрался и маршруты балансируются между Spine коммутаторами.

<Leaf11>disp ospf peer briefOSPF Process 1 with Router ID 10.1.1.11                   Peer Statistic InformationTotal number of peer(s): 2 Peer(s) in full state: 2----------------------------------------------------------------------------- Area Id         Interface                  Neighbor id          State 0.0.0.0         GE1/0/0                    10.1.1.100           Full 0.0.0.0         GE1/0/1                    10.1.1.101           Full-----------------------------------------------------------------------------

Соседство собралось, проверим маршрутную информацию:

<Leaf11>disp ip routing-table protocol ospfProto: Protocol        Pre: PreferenceRoute Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole route------------------------------------------------------------------------------_public_ Routing Table : OSPF         Destinations : 11       Routes : 13OSPF routing table status : <Active>         Destinations : 8        Routes : 10Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface       10.1.1.2/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                    OSPF    10   2             D   192.168.0.0     GE1/0/0       10.1.1.3/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                    OSPF    10   2             D   192.168.0.0     GE1/0/0      10.1.1.12/32  OSPF    10   2             D   192.168.0.8     GE1/0/1                    OSPF    10   2             D   192.168.0.0     GE1/0/0     10.1.1.100/32  OSPF    10   1             D   192.168.0.0     GE1/0/0     10.1.1.101/32  OSPF    10   1             D   192.168.0.8     GE1/0/1

Подготовка overlay

Для начала необходимо глобально включить поддержку EVPN на коммутаторе:

evpn-overlay enable

Spine коммутаторы выполняют роль Route-reflector. Плюс нужно добавить строку undo policy vpn-target в соответствующей address family, чтобы Spine смог принять все маршруты и переслать их клиентам. Соседство строим на loopback адресах.

bgp 65000 group leafs internal peer leafs connect-interface LoopBack0 peer 10.1.1.11 as-number 65000 peer 10.1.1.11 group leafs peer 10.1.1.12 as-number 65000 peer 10.1.1.12 group leafs peer 10.1.1.2 as-number 65000 peer 10.1.1.2 group leafs peer 10.1.1.3 as-number 65000 peer 10.1.1.3 group leafs # ipv4-family unicast  undo peer leafs enable  undo peer 10.1.1.11 enable  undo peer 10.1.1.12 enable  undo peer 10.1.1.2 enable  undo peer 10.1.1.3 enable # l2vpn-family evpn  undo policy vpn-target  peer leafs enable  peer leafs reflect-client  peer 10.1.1.11 enable  peer 10.1.1.11 group leafs  peer 10.1.1.12 enable  peer 10.1.1.12 group leafs  peer 10.1.1.2 enable  peer 10.1.1.2 group leafs  peer 10.1.1.3 enable  peer 10.1.1.3 group leafs

На Leaf коммутаторах настраиваем нужный address family. Для m-lag пары хочется сделать политику подменяющую next-hop на anycast loopback ip адрес, но без такой политики все работает. Huawei подменяет next-hop адрес на адрес который указан в качестве source ip адреса интерфейса NVE. Но если вдруг возникнут проблемы с автоматической подменой всегда можно навесить политику руками:

bgp 65000 group rr internal peer rr connect-interface LoopBack0 peer 10.1.1.100 as-number 65000 peer 10.1.1.100 group rr peer 10.1.1.101 as-number 65000 peer 10.1.1.101 group rr # ipv4-family unicast  undo peer rr enable  undo peer 10.1.1.100 enable  undo peer 10.1.1.101 enable # l2vpn-family evpn  policy vpn-target  peer rr enable  peer 10.1.1.100 enable  peer 10.1.1.100 group rr  peer 10.1.1.101 enable  peer 10.1.1.101 group rr

Проверяем, что overlay control plane собрался:

<Leaf11>disp bgp evpn peer BGP local router ID        : 10.1.1.11 Local AS number            : 65000 Total number of peers      : 2 Peers in established state : 2  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State  PrefRcv  10.1.1.100      4       65000    12829    12811     0 0186h15m Established        0  10.1.1.101      4       65000    12844    12822     0 0186h15m Established        0  <Leaf11>disp bgp evpn peer 10.1.1.100 verbose #лишние строки удалены для сокращения вывода BGP Peer is 10.1.1.100,  remote AS 65000 Type: IBGP link Update-group ID: 2 Peer optional capabilities:  Peer supports bgp multi-protocol extension  Peer supports bgp route refresh capability  Peer supports bgp 4-byte-as capability  Address family L2VPN EVPN: advertised and received

Подготовка L2 VXLAN

Сперва создадим NVE интерфейс отвечающий за инкапсуляцию/деинкапсуляцию пакетиков:

interface Nve1 #создаем NVE интерфейс source 10.1.1.1 #для m-lag пары используем anycast ip адрес mac-address 0000-5e00-0199 #обязательно для m-lag пары на обоих коммутаторах настраиваем одинаковый MAC адрес, это необходимо для работы L3 VXLAN

Для организации L2 VXLAN необходимо создать bridge-domain и примапить к нему vlan, l2 подинтефейс или интерфейс целиком. К одному bridge-domain могут быть примаплены разные VLANs.

bridge-domain 150 #создаем bridge-domainvlan 150 access-port interface Eth-Trunk12 #можно мапить vlan в конфигурации bridge-domain, а можно в создавать l2 подинтерфейс vxlan vni 22150 #определяем vni evpn #создаем evpn instance  route-distinguisher 10.1.1.11:22150  vpn-target 65000:22150 export-extcommunity  vpn-target 65000:23500 export-extcommunity #этот rt нужен в будущем для L3 VXLAN  vpn-target 65000:22150 import-extcommunity#interface GE1/0/9.150 mode l2 #создаем подинтерфейс encapsulation [default,dot1q,untag,qinq] #выбираем тип инкапсуляции bridge-domain 150 #мапим к нужному bridge-domain#interface Nve1  vni 22150 head-end peer-list protocol bgp #определяем, что для BUM трафика будет использоваться ingress replication list с автообнаружением по BGP

Проделываем такую же работу на остальных коммутаторах и проверяем работу. На коммутаторах должны появиться EVPN маршруты типа 3:

<Leaf11>disp evpn vpn-instance name 150 verbose VPN-Instance Name and ID : 150, 1  Address family evpn  Route Distinguisher : 10.1.1.11:22150  Label Policy        : label per instance  Per-Instance Label  : 16,17  Export VPN Targets  : 65000:22150 65000:23500  Import VPN Targets  : 65000:22150#<Leaf11>disp bgp evpn vpn-instance 150 routing-table inclusive-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,               h - history,  i - internal, s - suppressed, S - Stale               Origin : i - IGP, e - EGP, ? - incomplete   EVPN-Instance 150: Number of Inclusive Multicast Routes: 3       Network(EthTagId/IpAddrLen/OriginalIp)                 NextHop *>    0:32:10.1.1.1                                          0.0.0.0 *>i   0:32:10.1.1.2                                          10.1.1.2 * i                                                          10.1.1.2

Посмотрим попристальнее на анонс полученный от соседа:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table inclusive-route 0:32:10.1.1.2 BGP local router ID : 10.1.1.11 Local AS number : 65000   EVPN-Instance 150: Number of Inclusive Multicast Routes: 2 BGP routing table entry information of 0:32:10.1.1.2: Route Distinguisher: 10.1.1.2:22150 Remote-Cross route Label information (Received/Applied): 22150/NULL #видим нужный нам vni From: 10.1.1.100 (10.1.1.100) Route Duration: 7d19h17m35s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>, Tunnel Type <VxLan> AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Originator: 10.1.1.2 PMSI: Flags 0, Ingress Replication, Label 0:0:0(22150), Tunnel Identifier:10.1.1.2 Cluster list: 10.1.1.100 Route Type: 3 (Inclusive Multicast Route) Ethernet Tag ID: 0, Originator IP:10.1.1.2/32 Not advertised to any peer yet

BUM трафик должен ходить, можно приступать к проверке связности между хостами. Для этого с хоста VM1 пропингуем хост VM2:

ubuntu@test-vxlan-01:~$ ping 192.168.50.3PING 192.168.50.3 (192.168.50.3) 56(84) bytes of data.64 bytes from 192.168.50.3: icmp_seq=1 ttl=64 time=0.291 ms--- 192.168.50.3 ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.291/0.291/0.291/0.000 ms#ubuntu@test-vxlan-01:~$ ip neigh192.168.50.3 dev eth0 lladdr 00:15:5d:65:87:26 REACHABLE

В это время на сети должны появиться анонсы 2 типа. Проверим:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,               h - history,  i - internal, s - suppressed, S - Stale               Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance 150: Number of Mac Routes: 3       Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop*>i   0:48:0015-5d65-8726:0:0.0.0.0                          10.1.1.2 * i                                                          10.1.1.2 *>    0:48:0015-5df0-ed07:0:0.0.0.0                          0.0.0.0

Посмотрим анонс пристальнее:

<Leaf11>disp bgp evpn vpn-instance 150 routing-table mac-route 0:48:0015-5d65-8726:0:0.0.0.0 BGP local router ID : 10.1.1.11 Local AS number : 65000 EVN-Instance 150: Number of Mac Routes: 2 #два маршрута, потому что приходит от двух RR BGP routing table entry information of 0:48:0015-5d65-8726:0:0.0.0.0: Route Distinguisher: 10.1.1.2:22150 Remote-Cross route Label information (Received/Applied): 22150/NULL From: 10.1.1.100 (10.1.1.100) Route Duration: 0d00h07m19s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>, Tunnel Type <VxLan> AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Route Type: 2 (MAC Advertisement Route) Ethernet Tag ID: 0, MAC Address/Len: 0015-5d65-8726/48, IP Address/Len: 0.0.0.0/0, ESI:0000.0000.0000.0000.0000 Not advertised to any peer yet

Проверяем CAM таблицу коммутатора:

<Leaf11>disp mac-add bridge-domain 150Flags: * - Backup       # - forwarding logical interface, operations cannot be performed based           on the interface.BD   : bridge-domain   Age : dynamic MAC learned time in seconds-------------------------------------------------------------------------------MAC Address    VLAN/VSI/BD   Learned-From        Type                Age-------------------------------------------------------------------------------0015-5d65-8726 -/-/150       10.1.1.2      evn                   -0015-5df0-ed07 -/-/150       Eth-Trunk1.150      dynamic             450-------------------------------------------------------------------------------Total items: 2

Подготовка L3 VXLAN

Настало время выпустить хосты за пределы своей подсети, для этого будем использовать distributed gateway.

Для начала создадим нужный VRF:

ip vpn-instance EVPN ipv4-family  route-distinguisher 10.1.1.11:23500  vpn-target 65000: 23500 export-extcommunity evpn  vpn-target 65000: 23500 import-extcommunity evpn vxlan vni 23500

В конфигурацию BGP Leaf коммутаторов добавляем анонс IRB:

bgp 65000l2vpn-family evpn  peer rr advertise irb

Создаем L3 интерфейс для маршрутизации в нужном VRF:

interface Vbdif150 #номер должен совпадать с номером bridge-domain ip binding vpn-instance EVPN ip address 192.168.50.254 24 mac-address 0000-5e00-0101 vxlan anycast-gateway enable arp collect host enable #генерация маршрута второго типа на основании arp записи

Повторяем конфигурации на других Leaf коммутаторах и проверяем:

<Leaf11>disp ip vpn-instance SDC-EVPN  VPN-Instance Name               RD                    Address-family  EVPN                        10.1.1.11:23500            IPv4<Leaf11>disp evpn vpn-instance name __RD_1_10.1.1.11_23500__ verbose VPN-Instance Name and ID : __RD_1_10.1.1.11_23500__, 2  Address family evpn  Route Distinguisher : 10.1.1.11:23500  Label Policy        : label per instance  Per-Instance Label  : 17,18  Export VPN Targets  : 65000 : 23500  Import VPN Targets  : 65000 : 23500

На некоторых моделях коммутаторов (лучше свериться с официальной документацией) необходимо создание специального сервисного интерфейса для продвижения L3 VXLAN трафика. Полоса этого интерфейса должна быть в два раза больше пиковой полосы для L3 VXLAN трафика. При наличии большого количества Vbdif интерфейсов (более 2 тысяч) требуется создание дополнительных сервисных интерфейсов.

interface Eth-TrunkXXX service type tunnel trunkport 40GE1/1/1

На этом настройка L3 VXLAN завершена. Проверим доступность между хостами из разных подсетей:

ubuntu@test-vxlan-01:~$ ping 192.168.51.1PING 192.168.51.1 (192.168.51.1) 56(84) bytes of data.64 bytes from 192.168.51.1: icmp_seq=1 ttl=63 time=0.508 ms--- 192.168.51.1 ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.508/0.508/0.508/0.000 ms

Связность есть, теперь проверим маршрутную информацию:

<Leaf11>disp arp interface Vbdif 150ARP timeout:1200sARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlowEXP: Expire-time  src: Source ip   dst: Destination ipIP ADDRESS      MAC ADDRESS    EXP(M) TYPE/VLAN/CEVLAN   INTERFACE----------------------------------------------------------------------------------------192.168.50.254  0000-5e00-0101        I                  Vbdif150192.168.50.1    0015-5df0-ed07   15   D/150/-            Eth-Trunk1.150----------------------------------------------------------------------------------------Total:2         Dynamic:1       Static:0    Interface:1    OpenFlow:0Redirect:0#<Leaf1>disp bgp evpn vpn-instance 150 routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,               h - history,  i - internal, s - suppressed, S - Stale               Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance 150: Number of Mac Routes: 7       Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop *>    0:48:0000-5e00-0101:0:0.0.0.0                          0.0.0.0 * i                                                          10.1.1.2 * i                                                          10.1.1.2 *>i   0:48:0015-5d65-8726:32:192.168.50.3                    10.1.1.2 * i                                                          10.1.1.2 *>    0:48:0015-5df0-ed07:0:0.0.0.0                          0.0.0.0 *>    0:48:0015-5df0-ed07:32:192.168.50.1                    0.0.0.0

Появились маршруты второго типа включающие в себя IP адреса. Теперь проверим перетекли ли маршруты в нужный VRF:

<Leaf11>disp bgp evpn vpn-instance __RD_1_10.1.1.11_23500__ routing-table mac-route BGP Local router ID is 10.1.1.11 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,               h - history,  i - internal, s - suppressed, S - Stale               Origin : i - IGP, e - EGP, ? - incomplete EVN-Instance __RD_1_10.1.1.11_23500__: Number of Mac Routes:        Network(EthTagId/MacAddrLen/MacAddr/IpAddrLen/IpAddr)  NextHop*>i   0:48:0015-5d65-8726:32:192.168.50.3                    10.1.1.2 * i                                                          10.1.1.2*>i   0:48:0015-5df0-ed08:32:192.168.51.2                    10.1.1.3 * i                                                          10.1.1.3#<leaf11>disp bgp evpn vpn-instance __RD_1_10.1.1.11_23500__ routing-table mac-route 0:48:0015-5d65-8726:32:192.168.50.3 BGP local router ID : 10.1.1.11 Local AS number : 65000 EVN-Instance __RD_1_10.1.1.11_23500__: Number of Mac Routes: 2 BGP routing table entry information of 0:48:0015-5d65-8726:32:192.168.50.3: Route Distinguisher: 10.1.1.2:23500 Remote-Cross route Label information (Received/Applied): 22150 23500/NULL #добавился L3 VNI From: From: 10.1.1.100 (10.1.1.100) Route Duration: 7d08h48m44s Relay Tunnel Out-Interface: VXLAN Original nexthop: 10.1.1.2 Qos information : 0x0 Ext-Community: RT <65000 : 22150>, RT <65000 : 23500>Tunnel Type <VxLan>, Router's MAC <3864-0111-1200> #в качестве MAC адреса используется MAC адрес NVE интерфейса VTEPа AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, pre 255 Route Type: 2 (MAC Advertisement Route) Ethernet Tag ID: 0, MAC Address/Len: 0015-5d65-8726/48, IP Address/Len: 192.168.50.3/32, ESI:0000.0000.0000.0000.0000 Not advertised to any peer yet

Заключение

В данной статье я попытался описать процесс настройки EVPN VXLAN фабрики на базе оборудования Huawei и привести некоторые команды необходимые в процессе отладки.

Спасибо за внимание!