0.-irb.md
1 # IRB synchronisation 2 3 Но перед тем, как нырнуть с головой в странный но интересный мир интегрированной в EVPN маршрутизации, осветим очень важный пункт — синхронизация дефолтных шлюзов. Мы ведь до сих пор не знаем, зачем же к анонсам IRB-интерфейсов добавляется default-gateway community. Не для красоты же. Думаю, что исходя из названия данного пункта, вы уже догадались что это необходимо для синхронизации дефолтных шлюзов. Что такое синхронизация, как она происходит и зачем нужна? Давайте разбираться. 4 5 Для начала посмотрим все MAC-адреса на PE1,2 и 3, которые навешены на их IRB-интерфейсы. По порядку, PE1: 6 7 ```text 8 bormoglotx@RZN-PE-1> show interfaces irb.777 | match mac 9 MAC: 02:00:00:00:07:77 10 11 bormoglotx@RZN-PE-1> show interfaces irb.1777 | match mac 12 MAC: 02:00:00:00:17:77 13 ``` 14 15 На PE1 mac адреса irb интрефейсов сконфигурированы вручную. Теперь перейдем к PE2: 16 17 ```text 18 bormoglotx@RZN-PE-2> show interfaces irb.777 | match mac 19 MAC: 02:00:00:02:07:77 20 21 bormoglotx@RZN-PE-2> show interfaces irb.1777 | match mac 22 MAC: 02:00:00:02:17:77 23 ``` 24 25 И тут я позволил себе самостоятельно назначить адреса на IRB-интерфейсы. 26 Ну и посмотрим на PE3: 27 28 ```text 29 bormoglotx@RZN-PE-3> show interfaces irb | match curr 30 Current address: 00:05:86:71:96:f0, Hardware address: 00:05:86:71:96:f0 31 ``` 32 33 Тут MAC пострашнее, так как его я оставил таким, каким он зашит в оборудование. 34 35 Все PE маршрутизаторы анонсируют MAC+IP маршрут до своего или своих дефолтных шлюзов \(irb.777 и irb.1777\). Когда PE маршрутизатор получает маршрут MAC+IP, помеченный default-gateway community, то он начинает воспринимать полученный MAC-адрес удаленного IRB-интерфейса, как свой собственный адрес. Ведь если есть интерфейсы, на которых несколько IP-адресов и один MAC, то почему не может быть обратного — один IP и несколько MAC-адресов? Синхронизация дефолтных шлюзов бывает двух видов: автоматическая и ручная. Автоматическую синхронизацию мы сейчас рассмотрим, к ручной вернемся чуть позже. 36 37 Посмотреть какие адреса используются PE маршрутизатором можно следующей командой \(проверим на PE1\): 38 39 ```text 40 bormoglotx@RZN-PE-1> show bridge evpn peer-gateway-macs 41 42 Routing instance : RZN-VPN-1 43 Bridging domain : VLAN-1777, VLAN : 1777 44 Installed GW MAC addresses: 45 02:00:00:02:17:77 46 Bridging domain : VLAN-777, VLAN : 777 47 Installed GW MAC addresses: 48 00:05:86:71:96:f0 49 02:00:00:02:07:77 50 ``` 51 52 На PE1 два bridge-домена, для каждого каждого из которых синхронизация дефолтных шлюзов производится индивидуально. В отличии от PE1, на PE3 только один bridge-домен и один IRB-интерфейс. Соответственно синхронизация производится только для bridge-домена VLAN-777: 53 54 ```text 55 bormoglotx@RZN-PE-3> show evpn peer-gateway-macs 56 57 Routing instance : RZN-VPN-1 58 Bridging domain : __RZN-VPN-1__, VLAN : 777 59 Installed GW MAC addresses: 60 02:00:00:00:07:77 61 02:00:00:02:07:77 62 ``` 63 64 В итоге получается следующая картина — irb.777 на PE1 должен отзываться на три MAC-адреса: 65 66 * 00:05:86:71:96:f0 \(PE3\) 67 * 02:00:00:02:07:77 \(PE2\) 68 * 02:00:00:00:07:77 \(native PE1\) 69 70 И, естественно, мы сейчас проверим, что 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\): 71 72 ```text 73 RZN-CE1-SW1#sh start | i arp 74 arp 10.0.0.254 0200.0002.0777 ARPA 75 76 RZN-CE1-SW1#show arp | i 10.0.0.254 77 Internet 10.0.0.254 - 0200.0002.0777 ARPA 78 ``` 79 80 Логично предположить, что трафик пойдет на PE2, так как указанный на CE1-1 MAC-адрес соответствует irb.777 на PE2. Для того, чтобы проверить куда же пойдет трафик, навесим на IRB-интерфейсы PE-шек такие фильтры: 81 82 ```text 83 [edit] 84 bormoglotx@RZN-PE-2# show | compare 85 [edit interfaces irb unit 777 family inet] 86 + filter { 87 + input irb777-counter; 88 + } 89 [edit interfaces IRB unit 1777 family inet] 90 + filter { 91 + input irb1777-counter; 92 + } 93 [edit] 94 + firewall { 95 + family inet { 96 + filter irb777-counter { 97 + term 1 { 98 + then { 99 + count irb777; 100 + accept; 101 + } 102 + } 103 + } 104 + filter irb1777-counter { 105 + term 1 { 106 + then { 107 + count irb1777; 108 + accept; 109 + } 110 + } 111 + } 112 + } 113 + } 114 ``` 115 116 Как вы можете заметить, фильтры просто считают, что попало на IRB-интерфейс и пропускают весь трафик. В данный момент времени и на PE1 и на PE2 счетчики по нулям. 117 118 На PE1: 119 120 ```text 121 bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 122 123 Filter: irb777-counter 124 Counters: 125 Name Bytes Packets 126 irb777 0 0 127 ``` 128 129 На PE2: 130 131 ```text 132 bormoglotx@RZN-PE-2> show firewall filter irb777-counter counter irb777 133 134 Filter: irb777-counter 135 Counters: 136 Name Bytes Packets 137 irb777 0 0 138 ``` 139 140 Итак, запустим 33 icmp запроса до 10.0.0.254 с CE1-1 \(почему 33? Чтобы никто не догадался!\): 141 142 ```text 143 RZN-CE1-SW1#ping 10.0.0.254 repeat 33 144 Type escape sequence to abort. 145 Sending 33, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds: 146 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 147 Success rate is 100 percent (33/33), round-trip min/avg/max = 1/2/6 ms 148 ``` 149 150 Как вы помните, CE1-1 считает, что MAC-адрес шлюза по умолчанию не локальный мак irb.777 PE1, а MAC irb.777 PE2, это очень важно. 151 152 Смотрим что у нас с счетчиком на PE1: 153 154 ```text 155 bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 156 157 Filter: irb777-counter 158 Counters: 159 Name Bytes Packets 160 irb777 3300 33 161 ``` 162 163 Опа, все 33 пакета были приняты локальным IRB-интерфейсом. Давайте посмотрим, что у нас творится со счетчиком на PE2: 164 165 ```text 166 bormoglotx@RZN-PE-2> show firewall filter irb777-counter counter irb777 167 168 Filter: irb777-counter 169 Counters: 170 Name Bytes Packets 171 irb777 0 0 172 ``` 173 174 Все по нулям. Трафик туда просто не отправлялся и обрабатывался локальным IRB-интерфейсом PE1. 175 176 Приведу пару скринов из Wireshark-а. 177 Вот пакет от CE1-1 к PE1: 178 [](https://habrastorage.org/files/6eb/d90/14f/6ebd9014f35c4499a3ea9b659eb837b5.JPG) 179 Как destination указан не MAC локального интерфейса irb.777 на PE1, а MAC-адрес irb.777 PE2. Но вот что примечательно: посмотрим, с какого адреса прилетает ответ от PE1 на CE1-1: 180 [](https://habrastorage.org/files/90f/7a3/b3a/90f7a3b3a14549ccbdbc957556546a9e.JPG) 181 Ответ все таки PE1 шлет с нативного MAC-адреса irb.777. То есть, как вы понимаете, irb.777 только принимает пакеты, адресованные на MAC-адреса других интерфейсов irb.777 \(PE2 и PE3\), но как сорс адрес при отправке какого-либо пакета чужие MAC-адреса PE1 не использует. Это очень важно, так как, например, при резолве адреса дефолтного шлюза, IRB-интерфейс будет отвечать и указывать только свой нативный MAC-адрес. 182 183 Для чистоты эксперимента укажем CE1-1, что теперь MAC-адрес irb.777 равен MAC-адресу интерфейса irb.777 на PE3: 184 185 ```text 186 RZN-CE1-SW1#sh start | i arp 187 arp 10.0.0.254 0005.8671.96f0 ARPA 188 189 RZN-CE1-SW1#show arp | i 10.0.0.254 190 Internet 10.0.0.254 - 0005.8671.96f0 ARPA 191 ``` 192 193 Естественно, на irb.777 PE3 я также навесил данный фильтр. Запускаем пинг и проверяем: 194 195 ```text 196 RZN-CE1-SW1#ping 10.0.0.254 repeat 27 197 Type escape sequence to abort. 198 Sending 27, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds: 199 !!!!!!!!!!!!!!!!!!!!!!!!!!! 200 Success rate is 100 percent (27/27), round-trip min/avg/max = 1/2/5 ms 201 ``` 202 203 Заглянем в WIreshark, чтобы удостовериться, что пакет с CE был отправлен с необходимым нам destination MAC-адресом: 204 [](https://habrastorage.org/files/501/b09/52c/501b0952cea04de492a17f83ffc0f50a.JPG) 205 Смотрим счетчик на PE1: 206 207 ```text 208 bormoglotx@RZN-PE-1> show firewall filter irb777-counter counter irb777 209 210 Filter: irb777-counter 211 Counters: 212 Name Bytes Packets 213 irb777 6000 60 214 ``` 215 216 irb.777 на PE1 обработал еще 27 пакетов, в то время, как на PE3 счетчик так и стоит на нуле: 217 218 ```text 219 bormoglotx@RZN-PE-3> show firewall filter irb777-couter counter irb777 220 221 Filter: irb777-couter 222 Counters: 223 Name Bytes Packets 224 irb777 0 0 225 ``` 226 227 Это мы рассмотрели механизм автоматической синхронизации. Теперь перейдем к ручной синхронизации. 228 229 Вообще ручная синхронизация — это просто отключение автоматической синхронизации, вследствие того, что она просто не нужна. Почему? Мы сейчас конфигурили на всех PE-ках одинаковые IP-адреса на IRB-интерфейсах, но разные MAC-и. Второй способ настройки IRB-интерфейсов в EVPN \(он же и рекомендованный\) — одинаковые IP и MAC-адреса на всех IRB-интерфейсах одного и того же bridge-домена. При таком раскладе IRB-интерфейсы уже синхронизированы, так как везде одинаковые MAC. Поэтому можно дать команду default-gateway do-not-advertise и тем самым запретить генерацию маршрутов MAC+IP для IRB-интерфейсов. 230 231 Большим плюсом синхронизации дефолтных шлюзов является то, что это позволяет нам перемещать виртуальные машины между датацентрами без перерыва сервиса \(при выполнении определенных условий, таких как, задержка менее 100мс между точками А \(откуда перемещается машина\) и Z \(куда перемещается машина\) и т д\). После перемещения виртуальной машины она может продолжать отправлять пакеты во внешнюю сеть на адрес дефолтного шлюза, который находится в ее arp — то есть даже очищать arp кэш нам не придется. Естественно, будет сгенерирован новый BGP Update о том, что теперь данный MAC в другом месте. Вообще по теме VM Mobility в EVPN необходимо писать отдельную немаленькую статью и, поэтому, освещать её сейчас мы не будем. 232 233 Надеюсь, что все вышесказанное отложилось в памяти, так как без этого не будет понятен механизм работы L3 интерфейсов в EVPN. Теперь перейдем непосредственно к передаче пакетов между bridge-доменами. 234