Заключение
Как видите, EVPN является не просто технологией 2-го уровня. В данную технологию глубоко интегрирован и роутинг и свитчинг. Причем использовать вышеописанную схему с интеграцией в VRF не обязательно, если вы прокидываете просто клиентский L2 сервис.
Но за всё в этом мире надо платить и EVPN не исключение. То что технология сложна и запутана — это не проблема, надо просто в ней разобраться (ведь когда то и VPLS казался темным лесом — а сейчас кажется, что вроде все логично и понятно (во всяком случаем мне)). Одной из проблем может стать большое количество /32 и большое количество маршрутов типа 2, разобраться в которых порой будет нереально. Давайте прикинем, что у нас например 4 сети, размером /24 — грубо говоря, это сети на 250 хостов. Если мы хотим, чтобы все хосты общались друг с другом, то мы получим 1000 маршрутов /32 (по 250 маршрутов /32 и типа 2 на каждую сеть /24). А если таких доменов будет 10? Тогда уже 10 000 маршрутов с маской /32 будут летать по нашей сети, нагружая control plane. Причем эти цифры в реалиях современных датацентров с их системами виртуализации будут на 2-3 порядка выше описанных в статье. Мы знаем, что роутрефлектор отправляет своим нейборам все маршруты, разрешенные групповой экспортной политикой. Если, для примера, в нашу топологию добавить маршрутизатор PE4, который будет иметь vpnv4 сессию с рефлектором, то он будет получать от рефлектора все наши 10 000 маршрутов, которые ему то особо не нужны. Естественно, PE4 будет смотреть на RT и отбрасывать анонс, но эта работа тоже будет нагружать процессор RE. В RFC нет никаких рекомендаций по этому поводу. Juniper же рекомендует использовать семейство адресов route-target, дабы получать только нужные анонсы. Но в своей практике от данного семейства адресов я получал пока что только проблемы.
Ко всему прочему ответим на простой вопрос: почему MAC-адреса не используются для роутинга? Ведь в отличии от IPv4 адресов, MAC-адресов больше, они глобально уникальны, есть как бродкастные, так и мультикастные адреса, есть даже приватные (точнее назначенные вручную администраторами вне зависимости от производителя оборудования) MAC-адреса. Используй — не хочу! Но почему-то используется IP со всеми его костылями типа NAT и т д. Одной из самых важных причин является то, что MAC-адреса, в отличии от IP-адресов, не агрегируются в подсети, так как первая их часть отвечает не за географическое расположение адреса или организацию, которой этот блок адресов выдан, а за принадлежность оборудования к тому или иному производителю. В итоге получается что теоретически MAC-адреса поддаются агрегации, но практически на живой сети это сделать нереально, так как например MAC-адрес 04:01:00:00:01:01 принадлежит железке, расположенной где нибудь на побережье Флориды, а железка с MAC-адресом 04:01:00:00:01:02 например уже в Рязани.
Сегодня FV насчитывает более 550 000 маршрутов, агрегированных до /8-/24. Представьте размер таблицы маршрутизации, если бы для роутинга использовались исключительно /32 адреса. Зачем я об этом пишу? Дело в том, что если у вас соединены 5-6 датацентров, в которых порядка 100к MAC-адресов, то представьте какая нагрузка ляжет на control plane по распределению только EVPN маршрутов (о практически таком же количестве /32 я молчу). У данной проблемы есть решения, например, использование PBB, но, как говорится, это уже совсем другая история…
Если кому то интереснее покопаться глубже, то вот некоторые ссылки на информацию по данной тематике:
Непосредственно сам RFC 7432 со всей историей изменений;
Juniper EVPN;
Juniper EVPN IRB;
Cisco EVPN PBB;
Cisco EVPN VXLAN;
Brocade [EVPN][46].
На написание статьи, тестирование различных функций, чтение RFC и другой доступной литературы различных вендоров (не ограничиваясь только Cisco и Juniper) ушло более 2-х месяцев. Как видите, тесты проводились исключительно на Juniper, и у других вендоров реализация какого то функционала может несколько отличаться от описанного выше. Надеюсь изложенное в статье будет понятно и полезно читателям.