Изучение MAC-адресов
Теперь посмотрим на MAC-таблицу на PE1:
bormoglotx@RZN-PE-1> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : RZN-VPN-1
Bridging domain : VLAN-777, VLAN : 777
MAC MAC Logical NH RTR
address flags interface Index ID
aa:bb:cc:00:06:00 D ge-0/0/2.0
aa:bb:cc:00:07:00 DC 1048575 1048575Колонка flag говорит нам о том, как был изучен данный адрес: MAC-адрес aa:bb:cc:00:06:00 имеет только флаг D, что означает, что этот мак изучен динамически (стандартным способом через data plane) и, так как больше никаких флагов мы не видим, то можем с уверенностью сказать, что данный MAC изучен от локально подключенного CE маршрутизатора. А вот MAC-адрес aa:bb:cc:00:07:00 имеет два флага — DC. Что значит первый флаг, мы уже знаем, а вот флаг С говорит о том, что данный адрес изучен через control plane.
Если мы посмотрим на таблицу MAC-адресов на PE3, то увидим, что все адреса изучены данным PE маршрутизатором через control plane, и нет ни одного локального MAC-адреса:
bormoglotx@RZN-PE-3> show evpn mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : RZN-VPN-1
Bridging domain : __RZN-VPN-1__, VLAN : 777
MAC MAC Logical NH RTR
address flags interface Index ID
aa:bb:cc:00:06:00 DC 1048574 1048574
aa:bb:cc:00:07:00 DC 1048575 1048575Примечание: если вы заметили, в одном случае я использовал команду show bridge mac-table, а во втором show evpn mac-table. Это обусловлено тем, что на разных PE маршрутизаторах routing instance сконфигурированы по-разному — в первом случае virtual-swicth, во втором EVPN.
На PE3 нет ни одного изученного локально MAC-адреса, так как еще не было трафика от CE3. Давайте исправим данную ситуацию, запустив пинг до CE3, и еще раз посмотрим данную таблицу:
Как видите, на PE3 теперь появился MAC-адрес CE3, изученный через data plane.
Как и у обычного свича, адреса в MAC-таблице EVPN имеют определенный “срок годности”, по умолчанию этот срок равен 300-м секундам. Если в течении данного времени этот MAC был неактивен и не обновлялся, то маршрут удаляется из таблицы. Вроде, все просто — таймер отработал — MAC удалили. Но все не так просто, как кажется. Давайте рассмотрим, как это происходит.
Итак, PE3 изучил MAC-адрес CE3 и отправил его в BGP анонсе остальным PE маршрутизаторам. Предположим, что в течении 300 секунд запись не обновлялась. Тогда PE3 должен удалить данный MAC-адрес из таблицы, что он и делает. Но мы помним, что PE3 отправил всем своим соседям информацию о том, что данный MAC-адрес находится за ним. А вдруг этот хост переехал или вообще уже выключен? Что тогда? Остальные PE маршрутизаторы так и будут слать пакеты для CE3 на PE3, как в черную дыру? Конечно, нет. Дело в том, что если PE маршрутизатор удаляет из таблицы локальный MAC-адрес, то он отправляет BGP Withdrawn сообщение, которое заставляет другие PE маршрутизаторы удалить этот маршрут, а следовательно и MAC-адрес, из своих таблиц. Давайте это проверим.
На первом скрине представлен BGP UPDATE Message, который объявляет MAC-адрес aa:bb:cc:00:07:00 (картинки кликабельны):
Спустя 300 секунд, мы видим еще одно BGP UPDATE Message, которое является Withdrawn сообщением, отменяющим маршрут до указанного ранее MAC-адреса:
Помимо MAC aging time, у EVPN есть механизм сигнализации о смене MAC-адреса. Когда от CE маршрутизатора PE-ка получает Gratuitous ARP, то генерируется BGP Update, в котором содержится withdrawn сообщение с указанием старого MAC-адреса и анонс нового MAC-адреса.
Но помимо MAC-адреса маршрут MAC/IP Advertisement route может опционально содержать в себе и IP-адрес хоста. Добавим в наш EVPN роутинговый-интерфейс IRB и посмотрим какой маршрут появился:
Появились два новых маршрута, причем первый это только MAC-адрес irb.777, а вот второй MAC+IP. Mac+IP анонс имеет вид ARP записи, все PE маршрутизаторы, участвующие в одном EVPN-домене, синхронизируют свои ARP записи, что позволяет уменьшить количество флуда широковещательных ARP запросов по сети провайдера.
Теперь посмотрим на маршрут внимательнее:
В данном маршруте появилось новое расширенное коммьюнити evpn-default-gateway. Именно так помечаются маршруты, которые являются основным шлюзом для routing-instance. Данный маршрут будет генерироваться для каждого влана отдельно.
Почему генерируются два маршрута? Дело в том, что первый маршрут, в котором указан только MAC-адрес, используется исключительно для свитчинга в bringe-домене, а вот маршрут MAC+IP уже используется для маршрутизации и является по своей сути ARP записью. Забегу чуточку вперед и напишу, что точно так же будут генерироваться маршруты до хостов при движении трафика в другие вланы или во внешнюю сеть (это мы рассмотрим далее при добавлении в схему еще одного влана).
Last updated