/ 12.2.-evpn-multihoming / 4.-route-1-per-evi.md
4.-route-1-per-evi.md
1 # Зачем нам маршрут типа 1, сгенерированный per-EVI? 2 3 ```text 4 bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *01::0* 5 6 vSwitch-eVPN-1.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 7 + = Active Route, - = Last Active, * = Both 8 9 1:62.0.0.1:1::01::0/304 AD/EVI 10 *[EVPN/170] 1d 00:20:59 11 Indirect 12 1:62.0.0.2:1::01::0/304 AD/EVI 13 *[BGP/170] 1d 00:20:59, localpref 100, from 62.0.0.100 14 AS path: I, validation-state: unverified 15 > to 10.0.0.1 via ae0.1 16 ``` 17 18 Данный маршрут используется для анонсирования aliasing label: 19 20 ```text 21 bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *01::0* detail next-hop 62.0.0.2 22 23 vSwitch-eVPN-1.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 24 1:62.0.0.2:1::01::0/304 AD/EVI (1 entry, 1 announced) 25 *BGP Preference: 170/-101 26 Route Distinguisher: 62.0.0.2:1 27 Next hop type: Indirect, Next hop index: 0 28 Address: 0xb1e55f0 29 Next-hop reference count: 20 30 Source: 62.0.0.100 31 Protocol next hop: 62.0.0.2 32 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 33 State: Secondary Active Int Ext 34 Local AS: 42000.62 Peer AS: 42000.62 35 Age: 1d 0:20:26 Metric2: 1 36 Validation State: unverified 37 Task: BGP_42000.62.62.0.0.100 38 Announcement bits (1): 0-vSwitch-eVPN-1-evpn 39 AS path: I (Originator) 40 Cluster list: 62.0.0.100 41 Originator ID: 62.0.0.2 42 Communities: target:42000:1 43 Import Accepted 44 Route Label: 300208 45 Localpref: 100 46 Router ID: 62.0.0.100 47 Primary Routing Table bgp.evpn.0 48 ``` 49 50 Route Label: 300208 — это aliasing метка, которая наравне с сервичной меткой, указанной в маршруте типа 2 может использоваться для форвардинга трафика. Зачем же эта метка нам нужна, если у нас и так есть сервисная метка из маршрута типа 2? Дело в том, что это все таки EVPN предоставляет сервис L2VPN — то есть подключается к нам клиент к провадеркому оборудованию не как к маршрутизатору, а как к свичу. И если вы вспомните, что PE-маршрутизатор от клиента изучает MAC-адреса через data plane. То есть теоретически возможна ситуация, когда multihomed CE будет отправлять пакеты только в сторону одного из PE-маршрутизаторов \(причины могут быть разные — начиная от багов самого оборудования и заканчивая алгоритмом балансировки\). А значит только один маршрутизатор изучит MAC адрес от CE маршрутизатора/коммутатора и отправит анонс MAC/IP: 51 52 Если посмотреть таблицы форвардинга, то видно, что часть MAC-ов на RZN-PE-2 \(он является DF в данный момент для 777 влана\), изучены через data plane \(обратите внимание на указанные стрелками адреса\): 53 54 ```text 55 bormoglotx@RZN-PE-2> show bridge mac-table 56 57 MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC 58 O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) 59 60 Routing instance : vSwitch-eVPN-1 61 Bridging domain : BRIDGE-777, VLAN : 777 62 MAC MAC Logical NH RTR 63 addresssss flags interface Index ID 64 00:05:86:71:87:c0 DC 1048585 1048585 65 00:05:86:71:87:f0 D ae3.777 66 00:50:79:66:68:0c D ae3.777 <<<<<<<<<<<<<< 67 00:50:79:66:68:0d D ae3.777 <<<<<<<<<<<<<< 68 00:50:79:66:68:0e D ae3.777 69 ``` 70 71 В то время указанные выше MAC-и на RZN-PE-1 изучены не через data plane: 72 73 ```text 74 bormoglotx@RZN-PE-1> show bridge mac-table 75 76 MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC 77 O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) 78 79 Routing instance : vSwitch-eVPN-1 80 Bridging domain : BRIDGE-777, VLAN : 777 81 MAC MAC Logical NH RTR 82 addresssss flags interface Index ID 83 00:05:86:71:87:c0 DC 1048586 1048586 84 00:05:86:71:87:f0 D ae3.777 85 00:50:79:66:68:0c DRC ae3.777 <<<<<<<<<<<<<< 86 00:50:79:66:68:0d DRC ae3.777 <<<<<<<<<<<<<< 87 00:50:79:66:68:0e D ae3.777 88 ``` 89 90 Что у нас получается? Получилась ситуация, когда только RZN-PE-2 изучил MAC адрес какого то хоста за RZN-SW-1 и отправил MAC/IP маршрут, содержащий данный мак \( в нашем случае даже два таких маршрута\). Если мы посмотрим таблицу форвардинга на RZN-PE-3, то увидим в ней все эти маки, изученные через control plane: 91 92 ```text 93 bormoglotx@RZN-PE-3> show bridge mac-table 94 95 MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC 96 O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) 97 98 Routing instance : vSwitch-eVPN-1 99 Bridging domain : BRIDGE-777, VLAN : 777 100 MAC MAC Logical NH RTR 101 addresssss flags interface Index ID 102 00:05:86:71:87:c0 D ae0.777 103 00:05:86:71:87:f0 DC 1048580 1048580 104 00:50:79:66:68:0c DC 1048580 1048580 <<<<<<<<<<<<<< 105 00:50:79:66:68:0d DC 1048580 1048580 <<<<<<<<<<<<<< 106 00:50:79:66:68:0e DC 1048580 1048580 107 ``` 108 109 Но вот если посмотреть что мы получаем на RZN-PE-3, то будет ясно, что маршруты с RZN-PE-1 и RZN-PE-2 приходят ассиметрично. Вот маршруты, анонсированные с RZN-PE-1: 110 111 ```text 112 bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 match-prefix *2:6* next-hop 62.0.0.1 113 114 vSwitch-eVPN-1.evpn.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) 115 + = Active Route, - = Last Active, * = Both 116 117 2:62.0.0.1:1::777::00:05:86:71:87:f0/304 MAC/IP 118 *[BGP/170] 00:07:34, localpref 100, from 62.0.0.100 119 AS path: I, validation-state: unverified 120 > to 10.0.3.0 via ae3.0, Push 299824 121 2:62.0.0.1:1::777::00:50:79:66:68:0e/304 MAC/IP 122 *[BGP/170] 00:01:25, localpref 100, from 62.0.0.100 123 AS path: I, validation-state: unverified 124 > to 10.0.3.0 via ae3.0, Push 299824 125 ``` 126 127 А вот маршруты, анонсированные RZN-PE-2: 128 129 ```text 130 bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 match-prefix *2:6* next-hop 62.0.0.2 131 132 vSwitch-eVPN-1.evpn.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) 133 + = Active Route, - = Last Active, * = Both 134 135 2:62.0.0.2:1::777::00:05:86:71:87:f0/304 MAC/IP 136 *[BGP/170] 00:07:36, localpref 100, from 62.0.0.100 137 AS path: I, validation-state: unverified 138 > to 10.0.3.0 via ae3.0, Push 299840 139 2:62.0.0.2:1::777::00:50:79:66:68:0c/304 MAC/IP <<<<<<<<<<<<<< 140 *[BGP/170] 00:01:32, localpref 100, from 62.0.0.100 141 AS path: I, validation-state: unverified 142 > to 10.0.3.0 via ae3.0, Push 299840 143 2:62.0.0.2:1::777::00:50:79:66:68:0d/304 MAC/IP <<<<<<<<<<<<<< 144 *[BGP/170] 00:01:36, localpref 100, from 62.0.0.100 145 AS path: I, validation-state: unverified 146 > to 10.0.3.0 via ae3.0, Push 299840 147 2:62.0.0.2:1::777::00:50:79:66:68:0e/304 MAC/IP 148 *[BGP/170] 00:01:27, localpref 100, from 62.0.0.100 149 AS path: I, validation-state: unverified 150 > to 10.0.3.0 via ae3.0, Push 299840 151 ``` 152 153 Как видите, два мака видны только через RZN-PE-2. Если для RZN-PE-3 тут нет ничего криминального, то вот RZN-PE-1 тоже получает маршрут от RZN-PE-2 с этим MAC. Получается, что RZN-PE-1 должен отправлять трафик в сторону этих хостов через RZN-PE-2. Но было бы глупо думать, что разработчики EVPN опустили бы такую простую и банальную ошибку. В маршруте типа 2 \(MAC/IP\) содержится идентификатор ESI, к которому относится данный MAC-адрес. RZN-PE-1, получает маршрут типа 2, видит, что MAC виден через сегмент, к которому он непосредственно подключен. Поэтому RZN-PE-1 ставит next-hop-ом тоннель в сторону RZN-PE-2, а физический линк в сторону ESI: 154 155 ```text 156 bormoglotx@RZN-PE-1> show bridge mac-table 157 158 MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC 159 O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC) 160 161 Routing instance : vSwitch-eVPN-1 162 Bridging domain : BRIDGE-777, VLAN : 777 163 MAC MAC Logical NH RTR 164 addresssss flags interface Index ID 165 00:05:86:71:87:c0 DC 1048586 1048586 166 00:05:86:71:87:f0 D ae3.777 167 00:50:79:66:68:0c DRC ae3.777 <<<<<<<<<<<<<< 168 00:50:79:66:68:0d DRC ae3.777 <<<<<<<<<<<<<< 169 00:50:79:66:68:0e D ae3.777 170 ``` 171 172 В таблице форвардинга видно, что MAC адрес виден через логический интерфейс ae3.777, а флаг говорит, о том, что мак изучен динамически через control plane от удаленной PE-ки. В итоге, хоть RZN-PE-1 и не изучил данный MAC адрес через data plane, но отправлять трафик в сторону RZN-SW-1 он будет по прямому линку. 173 174 Но появляется другой вопрос — если на RZN-PE-3 данный MAC виден только через RZN-PE-2, так как RZN-PE-1 не анонсировал маршрути MAC/IP с заданным MAC адресом, то почему вдруг RZN-PE-3 станет отправлять пакеты на данный мак адрес через RZN-PE-1? Вот тут сцену выходит aliasing label. 175 176 RZN-PE-3 знает \(из маршрута типа 1, сгенерированного per-ESI\), что RZN-PE-1 и RZN-PE-2 подключены к одному и тому же сегменту и работают в режиме Active-Active. В таком случае в целях балансировки, RZN-PE-3 может использовать aliasing label, которая будет выполнять роль сервисной метки. В итоге RZN-PE-3 может отправлять трафик, предназначенный для хоста за RZN- SW-1 через RZN-PE-2, используя метку, указанную в маршруте типа 2, а также через RZN-PE-1, используя aliasing label вместо сервисной метки, которая указана в маршруте типа 1. 177 178  179 180 Aliacing label указывается для каждого multihomed соседа в каждом инстансе, что видно на RZN-PE-3: 181 182 ```text 183 bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-1 extensive | find "ESI: " 184 ESI: 00:00:00:00:00:00:00:00:00:01 185 Status: Resolved by NH 1048580 186 Number of remote PEs connected: 2 187 Remote PE MAC label Aliasing label Mode 188 62.0.0.1 300112 300112 all-active 189 62.0.0.2 300208 300208 all-active 190 ``` 191 192 ```text 193 bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-2 extensive | find "ESI: " 194 ESI: 00:00:00:00:00:00:00:00:00:01 195 Status: Resolved by NH 1048583 196 Number of remote PEs connected: 2 197 Remote PE MAC label Aliasing label Mode 198 62.0.0.1 0 302240 all-active 199 62.0.0.2 0 302272 all-active 200 ``` 201 202 ```text 203 bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-3 extensive | find "ESI: " 204 ESI: 00:00:00:00:00:00:00:00:00:01 205 Status: Resolved by NH 1048588 206 Number of remote PEs connected: 2 207 Remote PE MAC label Aliasing label Mode 208 62.0.0.2 0 302624 all-active 209 62.0.0.1 0 302560 all-active 210 ``` 211 212 В таблице mpls.0 данная метка так и помечается Ingress-Aliasing: 213 214 ```text 215 bormoglotx@RZN-PE-1> show route table mpls.0 label 302560 216 217 mpls.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden) 218 + = Active Route, - = Last Active, * = Both 219 220 302560 *[EVPN/7] 03:49:28, routing-instance vSwitch-eVPN-3, route-type Ingress-Aliasing 221 to table vSwitch-eVPN-3.evpn-mac.0 222 ``` 223 224 Хочу заметить, что оборудование Juniper генерирует метку для мак адреса в MAC/IP маршруте per-EVI \(то есть одна на весь инстанс\). И самое интересное то, что aliasing label будет точно такой же как и mac-label. Это видно из представленного ниже вывода: 225 226 ```text 227 bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-1 extensive | find "ESI: " 228 ESI: 00:00:00:00:00:00:00:00:00:01 229 Status: Resolved by NH 1048580 230 Number of remote PEs connected: 2 231 Remote PE MAC label Aliasing label Mode 232 62.0.0.1 300112 300112 all-active 233 62.0.0.2 300208 300208 all-active 234 ``` 235 236 Как видите, MAC label = Aliasing label. То, что JunOS генерирует метку для MAC адресов per-EVI доказывает следующий вывод: 237 238 ```text 239 bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 next-hop 62.0.0.1 match-prefix *2:6* detail | match label 240 Route Label: 300112 241 Route Label: 300112 242 Route Label: 300112 243 Route Label: 300112 244 ``` 245 246 С RZN-PE-1 анонсируется четыре маршрута типа 2, и у всех одна и та же метка. Но тогда возникает вопрос, а зачем нам вообще анонсировать aliasing label, если она равна mac label? Дело в том, что это свойственно оборудованию Juniper, другие вендоры — Cisco, Brocade, Huawei или ALu — могут иметь другое видение на данный вопрос и генерировать метки по другому. 247 248 Давайте прикинем, возможны ли какие нибудь проблемы при использовании aliasing метки? Рассмотрим такую ситуацию. Маршрутизатор RZN-PE-3 получил маршруты типа 1 per-EVI от RZN-PE-1 и RZN-PE-2, и теперь знает aliasing метку до обоих маршрутизаторов. А вот маршрутов типа 1 per-ESI на RZN-PE-3 еще нет. Получается, что если RZN-PE-3 начнет балансировать трафик с использованием aliasing метки, то может получится ситуация, когда например multihomed маршрутизаторы будут работать в режиме Single-Active и часть трафика, отправленная на пассивный узел, будет просто дропаться. То есть теоретически RZN-PE-3 может начать балансировать трафик, а фактически не знает можно ли это делать или нет. Как быть? Поведение маршрутизатора в такой ситуации четко регламентировано RFC — пока маршрутизатор не получит маршрут типа 1, сгенерированный per-ESI с указанием режима работы multihoming-а, он не должен отправлять трафик в данный сегмент с использованием aliasing метки, полученной в маршруте типа 1 per-EVI. 249 250 Данная метка может анонсироваться и в Single-Active сценарии. В этом случае она используется не для балансировки трафика по multihomed PE-кам, а для установки в таблицу форвардинга бекапного пути, который автоматически станет активен при падении основного плеча. 251