Маршрут типа 4 (Ethernet Segment Route)
Теперь разберем маршрут типа 4. Этот маршрут нужен для выбора DF, о назначении которого я писал ранее. Данный маршрут выглядит следующим образом:
bormoglotx@RZN-PE-2> show route table bgp.evpn.0 match-prefix *4:6*
bgp.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
4:62.0.0.1:0::112233445566778899aa:62.0.0.1/304
*[BGP/170] 01:07:57, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.3 via ge-0/0/0.0, Push 299808Примечательно, что данный маршрут не несет комьюнити, которое сконфигурено на экспорт из routing-instance:
bormoglotx@RZN-PE-2> show route table bgp.evpn.0 match-prefix *4:6* detail
bgp.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
4:62.0.0.1:0::112233445566778899aa:62.0.0.1/304 (1 entry, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 62.0.0.1:0
Next hop type: Indirect
Address: 0x95c1954
Next-hop reference count: 14
Source: 62.0.0.255
Protocol next hop: 62.0.0.1
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: Active Int Ext
Local AS: 6262 Peer AS: 6262
Age: 1:07:59 Metric2: 1
Validation State: unverified
Task: BGP_6262.62.0.0.255+51796
AS path: I (Originator)
Cluster list: 62.0.0.255
Originator ID: 62.0.0.1
Communities: es-import-target:33-44-55-66-77-88
Import Accepted
Localpref: 100
Router ID: 62.0.0.255
Secondary Tables: __default_evpn__.evpn.0Данные маршруты используют новое комьюнити: es-import-target:XX-XX-XX-XX-XX-XX. Само комьюнити генерируется из ESI. Для этого из идентификатора берутся 48 бит, как это показано ниже:
ESI: 11:22:33:44:55:66:77:88:99:aa
Сгенерированное коммьюнити: Communities: es-import-target:33-44-55-66-77-88
Только PE маршрутизаторы, имеющие одинаковые ESI (точнее одинаковые биты с 16 по 64 в идентификаторе), импортируют данный маршрут. Как видите, в анонсе нет RT, указанного на импорт или экспорт в routing instance. То есть маршруты типа 4 не видны в таблице маршрутизации самой EVPN. Их можно посмотреть только в таблицах bgp.evpn.0 и __default_evpn__.evpn.0.
Если у другого PE маршрутизатора будет ESI, например aaaa334455667788aaaa, то, как не трудно догадаться, их коммьюнити будет одинаково, а значит маршрут будет тоже импортирован. Но не стоит паниковать, все уже украдено до нас: в теле самого маршрута указан полный идентификатор ESI и данный маршрут будет импортирован, но проигнорирован. Как и RT, es-import-target предназначен только для фильтрации маршрутов. Ниже представлен сам маршрут типа 4 и его комьюнити:
Интересным случаем является вот такой конфиг:
Думаю, вы уже догадались, что мы получаем в анонсе расширенное комьюнити, состоящее из всех нулей:
Не стоит полагать, что из за этого все сломается. Даже с таким комьюнити все будет работать, но если у вас в сети будут, например, ESI в диапазоне хх: хх:00:00:00:00:00:00:00:01-хх: хх:00:00:00:00:00:00:99:99, то у всех маршрутов типа 4 будут одинаковые комьюнити, а значит PE маршрутизаторы будут принимать и устанавливать в таблицы маршрутизации все маршруты типа 4, даже если они им не нужны. Но думаю, что об это не стоит париться, плюс/минус 100 маршрутов погоды не сделают (почему не сделают — поймете, когда дочитаете статью до конца).
Не знаю, заметил ли читатель, но в маршрутах типа 1 и 4 RD выглядит несколько странно. Например, маршрут типа 2 от PE2:
А вот маршрут типа 1 с того же PE2:
От PE2 маршурт типа 1 имеет RD 62.0.0.2:0, хотя от этого же PE2 маршруты типа 2 или 3 прилетают с RD 62.0.0.2:1, который и сконфигурен в routing instance. Что происходит с RD? Для проверки данного явления создадим два routing instance с типом EVPN и назначим им совершенно разные RD:
Теперь посмотрим, с каким RD будет анонсироваться маршрут типа 1:
RD в маршруте не соответствует сконфигуренному ни на RZN-VPN-3, ни на RZN-VPN-4. Откуда же это RD берется? JunOS генерирует его автоматически из router-id или loopback адреса. Причем первое значение имеет приоритет. Например, сейчас имеем router-id:
И это значение берется как первая часть RD, а вторая выставляется в нашем случае в ноль. Давайте помянем router id:
Смотрим, какие теперь отдаются маршруты:
Как видите JunOS сам сгенерировал RD. Что будет если мы не укажем router-id? Давайте проверим. Но усложним задачу, навесив на лупбек еще пару адресов:
Смотрим теперь:
JunOS выбрал наименьший IP-адрес лупбека и использовал его как router-id. Это происходит потому, что данный маршрут типа 1 сгенеирирован per-ESI. Если маршрут будет генерироваться per-EVI, то у него будет нативный RD инстанса, из которого данный маршрут анонсируется. А вот маршрут типа 4 всегда будет иметь RD, уникальный на маршрутизатор, так как он всегда генерируется per-ESI.
Генерация маршрута per-ESI имеет некоторую особенность. Так как идентификатор ESI конфигурируется на физическом интерфейсе, то если у нас будет например 10 логических юнитов (можно сказать вланов) на данном интерфейсе и все в разных EVPN-инстансах, то мы получим, что в разных инстансах будет сгенерирован один и тот же маршрут типа 1. Зачем генерировать 10 одинаковых маршрутов (разница в них будет только в RT), если можно сгенерировать только один и навесить на него RT-ки всех заинтересованных в данном маршруте инстансов?
Давайте посмотрим как это работает на примере. Вот конфигурация ESI на физическом интерфейсе:
Данный интерфейс используется двумя инстансами с типом evpn:
Посмотрим, какие RT соответствуют данным инстансам (я удалил политики и прописал RT с помощью vrf-target для наглядности):
А теперь посмотрим маршрут типа 1, анонсируемый на рефлектор:
Как видите, у маршрута две RT-ки: target:62:1, которая соответствует RZN-VPN-1 и target:62:2, соответствующая eVPN-test. Эта функция уменьшает время сходимости. Если данный линк отвалится, то он отвалится у всех инстансов, к которым он прикреплен. В нашем случае вместо 2-x BGP Withdrawn сообщений, улетит только одно, но с двумя RT.
Примечание: маршруты типа 1 и 4 будем рассматривать отдельно в главе, посвященной EVPN multihoming.
Last updated