# Изучение 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, и еще раз посмотрим данную таблицу: ``` 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 (картинки кликабельны):\ [![](https://habrastorage.org/files/4b0/a86/b2e/4b0a86b2eabe4a58824ec8ba2a3438a6.jpg)](https://habrastorage.org/files/792/2b4/d0a/7922b4d0a9fe40b9a61c907bea12aa79.jpg)\ Спустя 300 секунд, мы видим еще одно BGP UPDATE Message, которое является Withdrawn сообщением, отменяющим маршрут до указанного ранее MAC-адреса:\ [![](https://habrastorage.org/files/2cf/a64/e99/2cfa64e9929640fea06f60192338e64e.jpg)](https://habrastorage.org/files/40a/ea9/bf2/40aea9bf28fb42629aaa383112532979.jpg)\ Помимо 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 записью. Забегу чуточку вперед и напишу, что точно так же будут генерироваться маршруты до хостов при движении трафика в другие вланы или во внешнюю сеть (это мы рассмотрим далее при добавлении в схему еще одного влана). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://linkmeup.gitbook.io/sdsm/12.1.-mpls-evpn/3.-evpn-route-types/1.-route-2/0.-mac-learning.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.