Зачем нам маршрут типа 1, сгенерированный per-EVI?
bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *01::0*
vSwitch-eVPN-1.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1:62.0.0.1:1::01::0/304 AD/EVI
*[EVPN/170] 1d 00:20:59
Indirect
1:62.0.0.2:1::01::0/304 AD/EVI
*[BGP/170] 1d 00:20:59, localpref 100, from 62.0.0.100
AS path: I, validation-state: unverified
> to 10.0.0.1 via ae0.1
Данный маршрут используется для анонсирования aliasing label:
bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *01::0* detail next-hop 62.0.0.2
vSwitch-eVPN-1.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
1:62.0.0.2:1::01::0/304 AD/EVI (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 62.0.0.2:1
Next hop type: Indirect, Next hop index: 0
Address: 0xb1e55f0
Next-hop reference count: 20
Source: 62.0.0.100
Protocol next hop: 62.0.0.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: Secondary Active Int Ext
Local AS: 42000.62 Peer AS: 42000.62
Age: 1d 0:20:26 Metric2: 1
Validation State: unverified
Task: BGP_42000.62.62.0.0.100
Announcement bits (1): 0-vSwitch-eVPN-1-evpn
AS path: I (Originator)
Cluster list: 62.0.0.100
Originator ID: 62.0.0.2
Communities: target:42000:1
Import Accepted
Route Label: 300208
Localpref: 100
Router ID: 62.0.0.100
Primary Routing Table bgp.evpn.0
Route Label: 300208 — это aliasing метка, которая наравне с сервичной меткой, указанной в маршруте типа 2 может использоваться для форвардинга трафика. Зачем же эта метка нам нужна, если у нас и так есть сервисная метка из маршрута типа 2? Дело в том, что это все таки EVPN предоставляет сервис L2VPN — то есть подключается к нам клиент к провадеркому оборудованию не как к маршрутизатору, а как к свичу. И если вы вспомните, что PE-маршрутизатор от клиента изучает MAC-адреса через data plane. То есть теоретически возможна ситуация, когда multihomed CE будет отправлять пакеты только в сторону одного из PE-маршрутизаторов (причины могут быть разные — начиная от багов самого оборудования и заканчивая алгоритмом балансировки). А значит только один маршрутизатор изучит MAC адрес от CE маршрутизатора/коммутатора и отправит анонс MAC/IP:
Если посмотреть таблицы форвардинга, то видно, что часть MAC-ов на RZN-PE-2 (он является DF в данный момент для 777 влана), изучены через data plane (обратите внимание на указанные стрелками адреса):
bormoglotx@RZN-PE-2> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vSwitch-eVPN-1
Bridging domain : BRIDGE-777, VLAN : 777
MAC MAC Logical NH RTR
addresssss flags interface Index ID
00:05:86:71:87:c0 DC 1048585 1048585
00:05:86:71:87:f0 D ae3.777
00:50:79:66:68:0c D ae3.777 <<<<<<<<<<<<<<
00:50:79:66:68:0d D ae3.777 <<<<<<<<<<<<<<
00:50:79:66:68:0e D ae3.777
В то время указанные выше MAC-и на RZN-PE-1 изучены не через data plane:
bormoglotx@RZN-PE-1> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vSwitch-eVPN-1
Bridging domain : BRIDGE-777, VLAN : 777
MAC MAC Logical NH RTR
addresssss flags interface Index ID
00:05:86:71:87:c0 DC 1048586 1048586
00:05:86:71:87:f0 D ae3.777
00:50:79:66:68:0c DRC ae3.777 <<<<<<<<<<<<<<
00:50:79:66:68:0d DRC ae3.777 <<<<<<<<<<<<<<
00:50:79:66:68:0e D ae3.777
Что у нас получается? Получилась ситуация, когда только RZN-PE-2 изучил MAC адрес какого то хоста за RZN-SW-1 и отправил MAC/IP маршрут, содержащий данный мак ( в нашем случае даже два таких маршрута). Если мы посмотрим таблицу форвардинга на RZN-PE-3, то увидим в ней все эти маки, изученные через control plane:
bormoglotx@RZN-PE-3> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vSwitch-eVPN-1
Bridging domain : BRIDGE-777, VLAN : 777
MAC MAC Logical NH RTR
addresssss flags interface Index ID
00:05:86:71:87:c0 D ae0.777
00:05:86:71:87:f0 DC 1048580 1048580
00:50:79:66:68:0c DC 1048580 1048580 <<<<<<<<<<<<<<
00:50:79:66:68:0d DC 1048580 1048580 <<<<<<<<<<<<<<
00:50:79:66:68:0e DC 1048580 1048580
Но вот если посмотреть что мы получаем на RZN-PE-3, то будет ясно, что маршруты с RZN-PE-1 и RZN-PE-2 приходят ассиметрично. Вот маршруты, анонсированные с RZN-PE-1:
bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 match-prefix *2:6* next-hop 62.0.0.1
vSwitch-eVPN-1.evpn.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2:62.0.0.1:1::777::00:05:86:71:87:f0/304 MAC/IP
*[BGP/170] 00:07:34, localpref 100, from 62.0.0.100
AS path: I, validation-state: unverified
> to 10.0.3.0 via ae3.0, Push 299824
2:62.0.0.1:1::777::00:50:79:66:68:0e/304 MAC/IP
*[BGP/170] 00:01:25, localpref 100, from 62.0.0.100
AS path: I, validation-state: unverified
> to 10.0.3.0 via ae3.0, Push 299824
А вот маршруты, анонсированные RZN-PE-2:
bormoglotx@RZN-PE-3> show route table vSwitch-eVPN-1.evpn.0 match-prefix *2:6* next-hop 62.0.0.2
vSwitch-eVPN-1.evpn.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2:62.0.0.2:1::777::00:05:86:71:87:f0/304 MAC/IP
*[BGP/170] 00:07:36, localpref 100, from 62.0.0.100
AS path: I, validation-state: unverified
> to 10.0.3.0 via ae3.0, Push 299840
2:62.0.0.2:1::777::00:50:79:66:68:0c/304 MAC/IP <<<<<<<<<<<<<<
*[BGP/170] 00:01:32, localpref 100, from 62.0.0.100
AS path: I, validation-state: unverified
> to 10.0.3.0 via ae3.0, Push 299840
2:62.0.0.2:1::777::00:50:79:66:68:0d/304 MAC/IP <<<<<<<<<<<<<<
*[BGP/170] 00:01:36, localpref 100, from 62.0.0.100
AS path: I, validation-state: unverified
> to 10.0.3.0 via ae3.0, Push 299840
2:62.0.0.2:1::777::00:50:79:66:68:0e/304 MAC/IP
*[BGP/170] 00:01:27, localpref 100, from 62.0.0.100
AS path: I, validation-state: unverified
> to 10.0.3.0 via ae3.0, Push 299840
Как видите, два мака видны только через 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:
bormoglotx@RZN-PE-1> show bridge mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : vSwitch-eVPN-1
Bridging domain : BRIDGE-777, VLAN : 777
MAC MAC Logical NH RTR
addresssss flags interface Index ID
00:05:86:71:87:c0 DC 1048586 1048586
00:05:86:71:87:f0 D ae3.777
00:50:79:66:68:0c DRC ae3.777 <<<<<<<<<<<<<<
00:50:79:66:68:0d DRC ae3.777 <<<<<<<<<<<<<<
00:50:79:66:68:0e D ae3.777
В таблице форвардинга видно, что MAC адрес виден через логический интерфейс ae3.777, а флаг говорит, о том, что мак изучен динамически через control plane от удаленной PE-ки. В итоге, хоть RZN-PE-1 и не изучил данный MAC адрес через data plane, но отправлять трафик в сторону RZN-SW-1 он будет по прямому линку.
Но появляется другой вопрос — если на RZN-PE-3 данный MAC виден только через RZN-PE-2, так как RZN-PE-1 не анонсировал маршрути MAC/IP с заданным MAC адресом, то почему вдруг RZN-PE-3 станет отправлять пакеты на данный мак адрес через RZN-PE-1? Вот тут сцену выходит aliasing label.
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.
Aliacing label указывается для каждого multihomed соседа в каждом инстансе, что видно на RZN-PE-3:
bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-1 extensive | find "ESI: "
ESI: 00:00:00:00:00:00:00:00:00:01
Status: Resolved by NH 1048580
Number of remote PEs connected: 2
Remote PE MAC label Aliasing label Mode
62.0.0.1 300112 300112 all-active
62.0.0.2 300208 300208 all-active
bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-2 extensive | find "ESI: "
ESI: 00:00:00:00:00:00:00:00:00:01
Status: Resolved by NH 1048583
Number of remote PEs connected: 2
Remote PE MAC label Aliasing label Mode
62.0.0.1 0 302240 all-active
62.0.0.2 0 302272 all-active
bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-3 extensive | find "ESI: "
ESI: 00:00:00:00:00:00:00:00:00:01
Status: Resolved by NH 1048588
Number of remote PEs connected: 2
Remote PE MAC label Aliasing label Mode
62.0.0.2 0 302624 all-active
62.0.0.1 0 302560 all-active
В таблице mpls.0 данная метка так и помечается Ingress-Aliasing:
bormoglotx@RZN-PE-1> show route table mpls.0 label 302560
mpls.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
302560 *[EVPN/7] 03:49:28, routing-instance vSwitch-eVPN-3, route-type Ingress-Aliasing
to table vSwitch-eVPN-3.evpn-mac.0
Хочу заметить, что оборудование Juniper генерирует метку для мак адреса в MAC/IP маршруте per-EVI (то есть одна на весь инстанс). И самое интересное то, что aliasing label будет точно такой же как и mac-label. Это видно из представленного ниже вывода:
bormoglotx@RZN-PE-3> show evpn instance vSwitch-eVPN-1 extensive | find "ESI: "
ESI: 00:00:00:00:00:00:00:00:00:01
Status: Resolved by NH 1048580
Number of remote PEs connected: 2
Remote PE MAC label Aliasing label Mode
62.0.0.1 300112 300112 all-active
62.0.0.2 300208 300208 all-active
Как видите, MAC label = Aliasing label. То, что JunOS генерирует метку для MAC адресов per-EVI доказывает следующий вывод:
С RZN-PE-1 анонсируется четыре маршрута типа 2, и у всех одна и та же метка. Но тогда возникает вопрос, а зачем нам вообще анонсировать aliasing label, если она равна mac label? Дело в том, что это свойственно оборудованию Juniper, другие вендоры — Cisco, Brocade, Huawei или ALu — могут иметь другое видение на данный вопрос и генерировать метки по другому.
Давайте прикинем, возможны ли какие нибудь проблемы при использовании 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.
Данная метка может анонсироваться и в Single-Active сценарии. В этом случае она используется не для балансировки трафика по multihomed PE-кам, а для установки в таблицу форвардинга бекапного пути, который автоматически станет активен при падении основного плеча.
