Теперь посмотрим на 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, и еще раз посмотрим данную таблицу:
RZN-CE1-SW1#ping 10.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 7/10/13 ms
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:05:00 D ge-0/0/2.777
aa:bb:cc:00:06:00 DC 1048574 1048574
aa:bb:cc:00:07:00 DC 1048575 1048575
Как видите, на 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 и посмотрим какой маршрут появился:
bormoglotx@RZN-PE-1> show configuration interfaces irb.777
family inet {
address 10.0.0.254/24;
}
mac 02:00:00:00:00:02;
bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 match-prefix *2:62.0.0.1:1::777::02*
RZN-VPN-1.evpn.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2:62.0.0.1:1::777::02:00:00:00:00:02/304
*[EVPN/170] 14:17:31
Indirect
2:62.0.0.1:1::777::02:00:00:00:00:02::10.0.0.254/304
*[EVPN/170] 14:17:31
Indirect
Появились два новых маршрута, причем первый это только MAC-адрес irb.777, а вот второй MAC+IP. Mac+IP анонс имеет вид ARP записи, все PE маршрутизаторы, участвующие в одном EVPN-домене, синхронизируют свои ARP записи, что позволяет уменьшить количество флуда широковещательных ARP запросов по сети провайдера.
Теперь посмотрим на маршрут внимательнее:
bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 match-prefix *2:62.0.0.1:1::777::02* detail
RZN-VPN-1.evpn.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
2:62.0.0.1:1::777::02:00:00:00:00:02/304 (1 entry, 1 announced)
*EVPN Preference: 170
Next hop type: Indirect
Address: 0x940d804
Next-hop reference count: 7
Protocol next hop: 62.0.0.1
Indirect next hop: 0x0 - INH Session ID: 0x0
State: Active Int Ext
Age: 14:21:34
Validation State: unverified
Task: RZN-VPN-1-evpn
Announcement bits (1): 1-BGP_RT_Background
AS path: I
Communities: evpn-default-gateway
Route Label: 300144
ESI: 00:00:00:00:00:00:00:00:00:00
В данном маршруте появилось новое расширенное коммьюнити evpn-default-gateway. Именно так помечаются маршруты, которые являются основным шлюзом для routing-instance. Данный маршрут будет генерироваться для каждого влана отдельно.
Почему генерируются два маршрута? Дело в том, что первый маршрут, в котором указан только MAC-адрес, используется исключительно для свитчинга в bringe-домене, а вот маршрут MAC+IP уже используется для маршрутизации и является по своей сути ARP записью. Забегу чуточку вперед и напишу, что точно так же будут генерироваться маршруты до хостов при движении трафика в другие вланы или во внешнюю сеть (это мы рассмотрим далее при добавлении в схему еще одного влана).