# IRB synchronisation Но перед тем, как нырнуть с головой в странный но интересный мир интегрированной в EVPN маршрутизации, осветим очень важный пункт — синхронизация дефолтных шлюзов. Мы ведь до сих пор не знаем, зачем же к анонсам IRB-интерфейсов добавляется default-gateway community. Не для красоты же. Думаю, что исходя из названия данного пункта, вы уже догадались что это необходимо для синхронизации дефолтных шлюзов. Что такое синхронизация, как она происходит и зачем нужна? Давайте разбираться. Для начала посмотрим все MAC-адреса на PE1,2 и 3, которые навешены на их IRB-интерфейсы. По порядку, PE1: ``` bormoglotx@RZN-PE-1> show interfaces irb.777 | match mac MAC: 02:00:00:00:07:77 bormoglotx@RZN-PE-1> show interfaces irb.1777 | match mac MAC: 02:00:00:00:17:77 ``` На PE1 mac адреса irb интрефейсов сконфигурированы вручную. Теперь перейдем к PE2: ``` bormoglotx@RZN-PE-2> show interfaces irb.777 | match mac MAC: 02:00:00:02:07:77 bormoglotx@RZN-PE-2> show interfaces irb.1777 | match mac MAC: 02:00:00:02:17:77 ``` И тут я позволил себе самостоятельно назначить адреса на IRB-интерфейсы.\ Ну и посмотрим на PE3: ``` bormoglotx@RZN-PE-3> show interfaces irb | match curr Current address: 00:05:86:71:96:f0, Hardware address: 00:05:86:71:96:f0 ``` Тут MAC пострашнее, так как его я оставил таким, каким он зашит в оборудование. Все PE маршрутизаторы анонсируют MAC+IP маршрут до своего или своих дефолтных шлюзов (irb.777 и irb.1777). Когда PE маршрутизатор получает маршрут MAC+IP, помеченный default-gateway community, то он начинает воспринимать полученный MAC-адрес удаленного IRB-интерфейса, как свой собственный адрес. Ведь если есть интерфейсы, на которых несколько IP-адресов и один MAC, то почему не может быть обратного — один IP и несколько MAC-адресов? Синхронизация дефолтных шлюзов бывает двух видов: автоматическая и ручная. Автоматическую синхронизацию мы сейчас рассмотрим, к ручной вернемся чуть позже. Посмотреть какие адреса используются PE маршрутизатором можно следующей командой (проверим на PE1): ``` bormoglotx@RZN-PE-1> show bridge evpn peer-gateway-macs Routing instance : RZN-VPN-1 Bridging domain : VLAN-1777, VLAN : 1777 Installed GW MAC addresses: 02:00:00:02:17:77 Bridging domain : VLAN-777, VLAN : 777 Installed GW MAC addresses: 00:05:86:71:96:f0 02:00:00:02:07:77 ``` На PE1 два bridge-домена, для каждого каждого из которых синхронизация дефолтных шлюзов производится индивидуально. В отличии от PE1, на PE3 только один bridge-домен и один IRB-интерфейс. Соответственно синхронизация производится только для bridge-домена VLAN-777: ``` bormoglotx@RZN-PE-3> show evpn peer-gateway-macs Routing instance : RZN-VPN-1 Bridging domain : __RZN-VPN-1__, VLAN : 777 Installed GW MAC addresses: 02:00:00:00:07:77 02:00:00:02:07:77 ``` В итоге получается следующая картина — irb.777 на PE1 должен отзываться на три MAC-адреса: * 00:05:86:71:96:f0 (PE3) * 02:00:00:02:07:77 (PE2) * 02:00:00:00:07:77 (native PE1) И, естественно, мы сейчас проверим, что IRB-интерфейс будет отвечать на пакеты, адресованные не на его собственный MAC. Сделаем это по-деревенски — просто пропишем статическую arp запись на CE маршрутизаторе на нужный нам MAC-адрес. Так как CE1-1 подключен к PE1 в bridge-домен VLAN-777, то при резолве MAC-адреса irb.777 он получает нативный MAC-адрес irb.777- 02:00:00:00:07:77. Мы же создадим на CE1-1 статическую arp запись, которая будет указывать, что MAC-адрес irb.777 на PE1 не 02:00:00:00:07:77, а 02:00:00:02:07:77 (который в действительности принадлежит irb.777 на PE2): ``` RZN-CE1-SW1#sh start | i arp arp 10.0.0.254 0200.0002.0777 ARPA RZN-CE1-SW1#show arp | i 10.0.0.254 Internet 10.0.0.254 - 0200.0002.0777 ARPA ``` Логично предположить, что трафик пойдет на PE2, так как указанный на CE1-1 MAC-адрес соответствует irb.777 на PE2. Для того, чтобы проверить куда же пойдет трафик, навесим на IRB-интерфейсы PE-шек такие фильтры: ``` [edit] bormoglotx@RZN-PE-2# show | compare [edit interfaces irb unit 777 family inet] + filter { + input irb777-counter; + } [edit interfaces IRB unit 1777 family inet] + filter { + input irb1777-counter; + } [edit] + firewall { + family inet { + filter irb777-counter { + term 1 { + then { + count irb777; + accept; + } + } + } + filter irb1777-counter { + term 1 { + then { + count irb1777; + accept; + } + } + } + } + } ``` Как вы можете заметить, фильтры просто считают, что попало на IRB-интерфейс и пропускают весь трафик. В данный момент времени и на PE1 и на PE2 счетчики по нулям. На PE1: ``` bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 0 0 ``` На PE2: ``` bormoglotx@RZN-PE-2> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 0 0 ``` Итак, запустим 33 icmp запроса до 10.0.0.254 с CE1-1 (почему 33? Чтобы никто не догадался!): ``` RZN-CE1-SW1#ping 10.0.0.254 repeat 33 Type escape sequence to abort. Sending 33, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (33/33), round-trip min/avg/max = 1/2/6 ms ``` Как вы помните, CE1-1 считает, что MAC-адрес шлюза по умолчанию не локальный мак irb.777 PE1, а MAC irb.777 PE2, это очень важно. Смотрим что у нас с счетчиком на PE1: ``` bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 3300 33 ``` Опа, все 33 пакета были приняты локальным IRB-интерфейсом. Давайте посмотрим, что у нас творится со счетчиком на PE2: ``` bormoglotx@RZN-PE-2> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 0 0 ``` Все по нулям. Трафик туда просто не отправлялся и обрабатывался локальным IRB-интерфейсом PE1. Приведу пару скринов из Wireshark-а.\ Вот пакет от CE1-1 к PE1:\ [![](https://habrastorage.org/files/6eb/d90/14f/6ebd9014f35c4499a3ea9b659eb837b5.JPG)](https://habrastorage.org/files/6eb/d90/14f/6ebd9014f35c4499a3ea9b659eb837b5.JPG)\ Как destination указан не MAC локального интерфейса irb.777 на PE1, а MAC-адрес irb.777 PE2. Но вот что примечательно: посмотрим, с какого адреса прилетает ответ от PE1 на CE1-1:\ [![](https://habrastorage.org/files/90f/7a3/b3a/90f7a3b3a14549ccbdbc957556546a9e.JPG)](https://habrastorage.org/files/90f/7a3/b3a/90f7a3b3a14549ccbdbc957556546a9e.JPG)\ Ответ все таки PE1 шлет с нативного MAC-адреса irb.777. То есть, как вы понимаете, irb.777 только принимает пакеты, адресованные на MAC-адреса других интерфейсов irb.777 (PE2 и PE3), но как сорс адрес при отправке какого-либо пакета чужие MAC-адреса PE1 не использует. Это очень важно, так как, например, при резолве адреса дефолтного шлюза, IRB-интерфейс будет отвечать и указывать только свой нативный MAC-адрес. Для чистоты эксперимента укажем CE1-1, что теперь MAC-адрес irb.777 равен MAC-адресу интерфейса irb.777 на PE3: ``` RZN-CE1-SW1#sh start | i arp arp 10.0.0.254 0005.8671.96f0 ARPA RZN-CE1-SW1#show arp | i 10.0.0.254 Internet 10.0.0.254 - 0005.8671.96f0 ARPA ``` Естественно, на irb.777 PE3 я также навесил данный фильтр. Запускаем пинг и проверяем: ``` RZN-CE1-SW1#ping 10.0.0.254 repeat 27 Type escape sequence to abort. Sending 27, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (27/27), round-trip min/avg/max = 1/2/5 ms ``` Заглянем в WIreshark, чтобы удостовериться, что пакет с CE был отправлен с необходимым нам destination MAC-адресом:\ [![](https://habrastorage.org/files/501/b09/52c/501b0952cea04de492a17f83ffc0f50a.JPG)](https://habrastorage.org/files/501/b09/52c/501b0952cea04de492a17f83ffc0f50a.JPG)\ Смотрим счетчик на PE1: ``` bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 Filter: irb777-counter Counters: Name Bytes Packets irb777 6000 60 ``` irb.777 на PE1 обработал еще 27 пакетов, в то время, как на PE3 счетчик так и стоит на нуле: ``` bormoglotx@RZN-PE-3> show firewall filter irb777-couter counter irb777 Filter: irb777-couter Counters: Name Bytes Packets irb777 0 0 ``` Это мы рассмотрели механизм автоматической синхронизации. Теперь перейдем к ручной синхронизации. Вообще ручная синхронизация — это просто отключение автоматической синхронизации, вследствие того, что она просто не нужна. Почему? Мы сейчас конфигурили на всех PE-ках одинаковые IP-адреса на IRB-интерфейсах, но разные MAC-и. Второй способ настройки IRB-интерфейсов в EVPN (он же и рекомендованный) — одинаковые IP и MAC-адреса на всех IRB-интерфейсах одного и того же bridge-домена. При таком раскладе IRB-интерфейсы уже синхронизированы, так как везде одинаковые MAC. Поэтому можно дать команду default-gateway do-not-advertise и тем самым запретить генерацию маршрутов MAC+IP для IRB-интерфейсов. Большим плюсом синхронизации дефолтных шлюзов является то, что это позволяет нам перемещать виртуальные машины между датацентрами без перерыва сервиса (при выполнении определенных условий, таких как, задержка менее 100мс между точками А (откуда перемещается машина) и Z (куда перемещается машина) и т д). После перемещения виртуальной машины она может продолжать отправлять пакеты во внешнюю сеть на адрес дефолтного шлюза, который находится в ее arp — то есть даже очищать arp кэш нам не придется. Естественно, будет сгенерирован новый BGP Update о том, что теперь данный MAC в другом месте. Вообще по теме VM Mobility в EVPN необходимо писать отдельную немаленькую статью и, поэтому, освещать её сейчас мы не будем. Надеюсь, что все вышесказанное отложилось в памяти, так как без этого не будет понятен механизм работы L3 интерфейсов в EVPN. Теперь перейдем непосредственно к передаче пакетов между bridge-доменами. --- # 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/4.-l3vpn-evpn/0.-irb.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.