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.

Для чистоты эксперимента укажем 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
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-доменами.

Last updated