1  # Заключение
 2  
 3  Как видите, EVPN является не просто технологией 2-го уровня. В данную технологию глубоко интегрирован и роутинг и свитчинг. Причем использовать вышеописанную схему с интеграцией в VRF не обязательно, если вы прокидываете просто клиентский L2 сервис.
 4  
 5  Но за всё в этом мире надо платить и 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, дабы получать только нужные анонсы. Но в своей практике от данного семейства адресов я получал пока что только проблемы.
 6  
 7  Ко всему прочему ответим на простой вопрос: почему MAC-адреса не используются для роутинга? Ведь в отличии от IPv4 адресов, MAC-адресов больше, они глобально уникальны, есть как бродкастные, так и мультикастные адреса, есть даже приватные \(точнее назначенные вручную администраторами вне зависимости от производителя оборудования\) MAC-адреса. Используй — не хочу! Но почему-то используется IP со всеми его костылями типа NAT и т д. Одной из самых важных причин является то, что MAC-адреса, в отличии от IP-адресов, не агрегируются в подсети, так как первая их часть отвечает не за географическое расположение адреса или организацию, которой этот блок адресов выдан, а за принадлежность оборудования к тому или иному производителю. В итоге получается что теоретически MAC-адреса поддаются агрегации, но практически на живой сети это сделать нереально, так как например MAC-адрес 04:01:00:00:01:01 принадлежит железке, расположенной где нибудь на побережье Флориды, а железка с MAC-адресом 04:01:00:00:01:02 например уже в Рязани.
 8  
 9  Сегодня FV насчитывает более 550 000 маршрутов, агрегированных до /8-/24. Представьте размер таблицы маршрутизации, если бы для роутинга использовались исключительно /32 адреса. Зачем я об этом пишу? Дело в том, что если у вас соединены 5-6 датацентров, в которых порядка 100к MAC-адресов, то представьте какая нагрузка ляжет на control plane по распределению только EVPN маршрутов \(о практически таком же количестве /32 я молчу\). У данной проблемы есть решения, например, использование PBB, но, как говорится, это уже совсем другая история…
10  
11  Если кому то интереснее покопаться глубже, то вот некоторые ссылки на информацию по данной тематике:
12  
13  1. Непосредственно сам [RFC 7432](https://datatracker.ietf.org/doc/rfc7432/) со всей историей изменений;
14  2. Juniper [EVPN](https://www.juniper.net/documentation/en_US/junos14.2/topics/concept/evpns-overview.html);
15  3. Juniper [EVPN IRB](https://www.juniper.net/documentation/en_US/junos14.1/topics/concept/evpn-irb-soultion-overview.html);
16  4. Cisco [EVPN PBB](http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/whitepaper_c11-731864.html);
17  5. Cisco [EVPN VXLAN](http://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/guide-c07-734107.html);
18  6. Brocade \[EVPN\]\[46\].
19  
20  ## От автора
21  
22  На написание статьи, тестирование различных функций, чтение RFC и другой доступной литературы различных вендоров \(не ограничиваясь только Cisco и Juniper\) ушло более 2-х месяцев. Как видите, тесты проводились исключительно на Juniper, и у других вендоров реализация какого то функционала может несколько отличаться от описанного выше. Надеюсь изложенное в статье будет понятно и полезно читателям.
23  
24  \[46\]: [http://www.brocade.com/content/html/en/brocade-validated-design/brocade-bgp-evpn-based-dci-bvd/GUID-126A7474-2591-40CE-B4F8-0B5C7E6CF415.html](http://www.brocade.com/content/html/en/brocade-validated-design/brocade-bgp-evpn-based-dci-bvd/GUID-126A7474-2591-40CE-B4F8-0B5C7E6CF415.html)
25