Но за всё в этом мире надо платить и 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, дабы получать только нужные анонсы. Но в своей практике от данного семейства адресов я получал пока что только проблемы.