Плоские сети L2 просты. Любой хост может отправить пакет другому, и сеть его доставит. Если один хост хочет узнать MAC-адрес удаленного хоста, он посылает запрос протокола определения адреса (ARP), и сеть обрабатывает его так же, как и любой другой широковещательный пакет. Удаленный хост отправит ARP-ответ, и все будет в порядке.
На практике, конечно, это не масштабируется и приводит к всевозможным сбоям из-за L2 петель и широковещательных штормов. Вот почему все недолюбливают большие сети L2.
Оверлеи, которые расширяют L2 поверх L3, пытаются улучшить масштабируемость и надежность за счет:
Избавления от ядра L2.
Уменьшения объема широковещательного, неизвестного одноадресного и многоадресного (BUM) флудинга.
Но если (1) предоставляется каждым оверлеем, то реализация (2) — дело непростое. Оверлеи типа VPLS или базовой VXLAN даже не пытаются разбираться с ARP.
ARP suppression (подавление ARP)
Оверлеи с более продвинутыми управляющими уровнями пытаются уменьшить BUM-флудинг путем имплементации ARP suppression. Наиболее ярким примером в этом случае является Ethernet VPN (EVPN) и некоторые проприетарные технологии, такие как Cisco OTV или VMware NSX.
Как показано на Рисунке 1, Хост A посылает ARP-запрос, чтобы узнать MAC-адрес Хоста B, но поскольку SW1 уже знает MAC-адрес Хоста B (из ранее перехваченных ARP-запросов), SW1 отвечает Хосту A от имени Хоста B, не пересылая ARP-запрос через VXLAN.
Идеальная идея! Что может пойти не так?
Как оказалось, очень многое. Поскольку плоские сети L2 были столь просты и элементарны, разработчики приложений самонадеянно положились на то, что сеть просто доставит все, что они передадут по кабелю.
Многие кластеры приложений используют ARP в качестве keepalives-сообщений между своими узлами. И вместо использования одноадресных ARP или GARP (которые не должны подавляться), некоторые посылают обычные широковещательные ARP-запросы. Конечно, ARP suppression полностью нарушает эту функциональность.
ARP-зонды — это широковещательные ARP-запросы с исходным IP-адресом 0.0.0.0. Они обычно используются для обнаружения дубликатов IP. Надлежащее имплементирование EVPN не должно подавлять ARP-зонды. Некоторые из ранних реализаций так делали, что приводило к проблемам.
Все современные коммутаторы пересылают транзитные пакеты с линейными скоростями. BUM-пакеты не обязательно пересылаются на скорости линии, но пропускная способность репликации обычно остается очень высокой. ARP suppression требует, чтобы все транзитные широковещательные ARP-пакеты отлавливались на CPU, который также защищен политикой управляющего уровня. Большой объем ARP-трафика приведет к тому, что некоторые пакеты будут потеряны, а запросы останутся без ответа. Различные ошибки или неправильное программирование TCAM иногда могут привести к тому, что все ARP-пакеты будут отброшены, или отброшены только в определенной VLAN, и так далее. Желаю удачи при устранении таких неполадок в большой сети.
И далее, конечно же, о вендорах.
На коммутаторах Cisco nexus ARP suppression по умолчанию заблокировано и может быть включено с помощью 'suppress-arp' под идентификатором сети VXLAN (VNI). На Juniper QFX ARP suppression по умолчанию включено и может быть деактивировано с помощью 'no-arp-suppression' под VLAN-ом. В Arista ARP suppression включено по умолчанию только для VLAN с настроенным виртуальным интерфейсом коммутатора (SVI). Но вы можете отключить его для некоторых определенных подсетей (например, для запущенных кластеров, использующих ARP в качестве keepalives):
router l2-vpn
arp proxy prefix-list NO_SUPPRESS
!
ip prefix-list NO_SUPPRESS
seq 10 deny 10.0.0.0/24Я даже не хочу начинать обсуждать Microsoft NLB с его привязкой ARP к многоадресным MAC (явно запрещенной RFC 1812). Microsoft еще хуже, чем Juniper, когда дело доходит до стандартов.
Добавление маршрутизации
Рассмотрим простую сеть с коммутатором L3, который разделяет две подсети.
Предполагая, что Хост A уже имеет ARP-запись для IP-адреса SW1, он посылает пакет Хосту B, но SW1 не знает MAC-адрес Хоста B. Поэтому SW1 должен сделать следующее:
Отловить транзитный IP-пакет на CPU.
Задержать пакет в очереди и создать временную ARP-запись INCOMPLETE, отправив ARP-запрос для MAC-адреса Хоста B.
Как только SW1 получит ARP-ответ, он обновит ARP-запись как REACHABLE и перешлет пакет из очереди на Хост B.
По крайней мере, так это работает в сетевой ОС на базе Linux. Точное количество пакетов, которые могут быть поставлены в очередь, зависит от имплементации, но это примерно 256, 256-байтных пакетов на один неразрешенный адрес. Если ARP не может быть разрешен после трех попыток (состояние: FAILED), коммутатор будет продолжать посылать запросы вечно, отбрасывая лишние транзитные пакеты и посылая ICMP destination unreachables (пункт назначения недоступен) Хосту A.
Другие сетевые ОС могут вести себя несколько иначе (например, Cisco IOS посылает ARP-запросы каждые две секунды и отбрасывает транзитные пакеты, предназначенные для неразрешенных ARP-запросов), но основная идея остается схожей. Кроме того, поскольку SW1 является L3 коммутатором с SVI, он также узнает MAC Хоста B, услышав ARP ответы.
ARP в L3 EVPN
Теперь давайте посмотрим, как это работает, когда L2 заменен на VXLAN-EVPN.
L3 EVPN бывает двух видов — асимметричная и симметричная Integrated Routing and Bridging (Интегрированная маршрутизация и мостовое соединение) (IRB).
Асимметричная IRB относится к такой схеме L3 EVPN, в которой все конечные точки туннеля VXLAN (VTEP) имеют SVI для всех L3 VNI, сконфигурированных в сети, и если пакет должен быть направлен между подсетями, входящий VTEP выполняет маршрутизацию, а исходящий VTEP только мостовое соединение.
Когда VTEP необходимо изучить ARP-запись для удаленного хоста, доступного через VXLAN, он посылает ARP-запрос, хост дает ARP-ответ, который может дойти до VTEP или нет — это не имеет значения, поскольку на данном этапе мы хотим, чтобы удаленный VTEP генерировал маршруты MAC-IP и объявлял их через BGP. И ARP (L3), и изучение MAC (L2) будет осуществляться из плоскости управления BGP-EVPN. Получаем ли мы ARP-ответ или нет, не имеет значения. Это важно, поскольку в многоинтерфейсных установках ARP-ответ может попасть на другой коммутатор.
На Рисунке 3 показано, что даже если ARP ответ попадает на SW2, SW1 все равно узнает ARP запись для Хоста B из BGP-EVPN. Он также узнает MAC-адрес Хоста B из EVPN.
Итак, что может пойти не так?
Рассмотрим приложение на базе TCP, которое может молчать более пяти минут, сохраняя при этом TCP-сессию живой. SW3 по истечении пяти минут состарит MAC-адрес и отменит маршрут MAC-IP. В EVPN нет отдельных типов маршрутов для MAC и ARP, поэтому SW3 отменит оба маршрута. Это заставит SW1/SW2 переучить ARP.
Если в следующий раз Хост A захочет начать разговор, а весь процесс повторного обнаружения MAC Хоста B и объявления его через BGP займет больше секунды, это заставит SW1/SW2 отправить ICMP unreachables (недоступные) обратно Хосту A, что вызовет сброс TCP-сессии. В зависимости от имплементации, это может привести к сбою, даже если все займет менее одной секунды. Более того, несмотря на то, что приложение не молчит в течение пяти минут, а обратный трафик является асимметричным и не проходит через EVPN, может возникнуть та же проблема.
MAC-адреса из черного списка в асимметричных конструкциях IRB теперь могут вызывать дублирование трафика и сброс TCP в приложении.
Симметричная IRB — это более продвинутая конструкция EVPN, где входящий VTEP выполняет маршрутизацию в транзитный VNI, а исходящий VTEP - в VNI назначения. Она обеспечивает лучшую масштабируемость и устраняет проблему, описанную выше.
Ну, почти. Промежутки в трафике приложений более пяти минут вызовут таймауты MAC и последующее удаление маршрутов MAC-IP, что также вызовет отток маршрутов хостов EVPN.
Заключение
Уменьшение таймаута ARP с четырех часов по умолчанию до менее пяти минут, похоже, решит все проблемы с ARP в EVPN IRB. Их может быть трудно обнаружить и изолировать, поэтому, на мой взгляд, таймер возраста MAC-адреса должен быть лучшей практикой при любом деплое EVPN. С другой стороны, я считаю, что ARP suppression изначально было плохой идеей. Если сеть L2 не масштабируется, спроектируйте соответствующую сеть L3. Но если людям так хочется все время наступать на грабли, зачем препятствовать этому?
Приглашаем всех желающих на открытое занятие «Сшиваем разорванную ip сеть с помощью NAT». На занятии определим, что такое разорванные сети и как они возникают, рассмотрим синтаксис NAT в CISCO CLI. А также обеспечим доступ между сегментами разорванной сети с помощью NAT. Регистрируйтесь по ссылке.