08.09.2020 10:22
Santchous 3 1800 Источник

Всем привет. Проходил тут собеседование и появилась мысль следующую часть из цикла статей, посвященных запуску курса "Сетевой инженер" от OTUS, сделать более теоретической, дабы ответить на некоторые вопросы с которыми столкнулся во время интервью.



Многие тут вещи будут скорее базового уровня в понятиях VxLAN и не должны вызывать трудностей.



I. как VxLAN фабрика узнает о MAC адресах?


Да мы уже разобрали, что MAC и IP адреса передаются через EVPN route-type 2. Но как EVPN узнает о них?


Все довольно просто и работает аналогично логике обычного VLAN:


  • Кадр от источника попадает на порт коммутатора (VTEP)
  • Коммутатор, если не знает MAC источника — записывает его в свою таблицу TCAM
  • Так как коммутатор выполняет роль VTEP, то информацию о MAC и IP адресах источника он передает через EVPN route-type 2 (каким именно образом зависит от настройки фабрики. В нашем случае используется Route-reflector(RR), поэтому информация отправляется к RR и от него к остальном VTEP)


С источником все понятно, а что делать с Destination? Ведь Host-источник скорее всего не знает MAC адрес назначения и пошлет ARP запрос.
Появляется два варианта:


  1. не использовать функцию Suppress-ARP
  2. использовать функцию Suppress-ARP

В первом случае все довольно просто, но не оптимально. При получении Broadcast запроса VTEP отправит его дальше в рамках того VNI, от куда пришел запрос. То есть по всей фабрики разойдется этот запрос в виде Unicast сообщений.



Во втором случае, при получении ARP запроса VTEP сам отвечает ARP reply, а ARP REQ дальше не отправляется.



Однако такая логика работает только если VTEP уже знает Destination MAC. Если адрес не известен, то пойдем по первому пути. Более подробно работу и настройку Suppress-ARP я касался в первой части цикла.


II. Зачем используется UDP?


Вопрос не менее интересный и ответить довольно просто. Для этого вспомним логику работы VxLAN фабрики.


К кадру, прилетающему на порт VTEP, добавляется VxLAN метка с номером VNI. Далее получившийся кадр запаковывается в UDP, инкапсулируется в новый IP пакет и передается поверх Underlay сети.


Так почему же нельзя оригинальный кадр с меткой VxLAN запаковать в IP и необходимо использовать UDP?


А все из-за одного поля в заголовке протокола IP — Protocol, который указывает, какой именно протокол находится выше. Примеры протоколов и их номера (wiki):


ICMP - 1
TCP - 6
UDP - 17
GRE - 47

И в этом кроется весь секрет — VxLAN не имеет такой номер, а значит протокол IP не сможет о нем рассказать и уважающая себя сеть такой пакет не пропустит, поэтому инженеры обошли эту проблему с использованием протокола UDP.



Вторая причина, по которой используется UDP, находится в методе балансировки трафика на основе:


  • src_mac
  • src_ip
  • dest_ip
  • src_port
  • dest_port

Спасибо @Karroplan за подсказку.


И тут может возникнуть второй вопрос — почему не TCP, ведь он такой надежный и хороший? А все потому, что TCP такой надежный и хороший — гарантирует доставку и для такой гарантии использует жутко долгие таймеры, проверки, регулирование полосы пропускания и т.д. В итоге TCP дает большую задержку, которая, особенно сильно, будет заметна, когда клиент VxLAN фабрики тоже будет использовать TCP.


III. Разница между ingress-replication и Multicast


Тема довольно объемная и в качестве краткого пояснения ответ дать не получится. Поэтому работа Multicast будет рассмотрена в рамках одной из следующей статьи цикла. Однако я попробую дать краткое описание различий двух технологий.


Для начала рассмотрим как передаются пакеты в обоих случаях.


при использовании ingress-replication — при получения широковещательного трафика (например ARP запрос) — запрос инкапсулируется внутрь VxLAN и передается каждому VTEP в VxLAN через Unicast сообщения (для примера откажемся от RR). Так как VTEP будет больше 1, то широковещательный трафик будет дублироваться:



В случае использования Multicast, каждый VTEP для каждого VNI подписывается на определенную Multicast группу. И теперь, при получении широковещательного трафика, VTEP инкапсулирует ARP запрос в IP пакет. В заголовках IP пакета в качестве адреса назначения используется multicast адрес группы для этого VNI, а адрес источника — IP адрес интерфейса NVE. Например, VNI 10000 ассоциируем c multicast группой 225.1.10.10



Таким образом у нас пропадает дублирование широковещательного трафика. Плюс, при должной оптимизации трафика, работа через Multicast будет более масштабируема. Единственная сложность — underlay сеть должна поддерживать Multicast трафик.


Если у вас возникает вопрос — Зачем вообще понадобился EVPN, если все может отлично работать через Multicast, ведь это более масштабируемое решение?


Ответ тут дать довольно затруднительно и вам придется решить самостоятельно какую технологию использовать. На данный момент, Multicast действительно является более масштабируемым решением. Но EVPN постоянно дорабатывается и в нем появляются новые route-type для передачи все большей информации о сети для более гибкой настройки. Дополнительно, EVPN строится на основе BGP, а значит есть возможность использовать все методы оптимизации, что есть и в самом BGP (например в моем стенде уже используется RR, для уменьшения BUM трафика и оптимизации анонсируемой информации).


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



OSPF ipv6. Практические навыки