Маршрут типа 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 и его комьюнити:

bormoglotx@RZN-PE-1> show route table bgp.evpn.0 match-prefix *4:62* detail | match "comm|\/304"
4:62.0.0.2:0::112233445566778899aa:62.0.0.2/304 (1 entry, 0 announced)
                Communities: es-import-target:33-44-55-66-77-88

Интересным случаем является вот такой конфиг:

bormoglotx@RZN-PE-1> show configuration interfaces ae1 | match esi | display set
set interfaces ae1 esi 62:00:00:00:00:00:00:00:00:01
set interfaces ae1 esi all-active

Думаю, вы уже догадались, что мы получаем в анонсе расширенное комьюнити, состоящее из всех нулей:

bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 table __default_evpn__.evpn.0 detail match-prefix *62000000000000000001:6*

__default_evpn__.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
* 4:62.0.0.1:0::62000000000000000001:62.0.0.1/304 (1 entry, 1 announced)
 BGP group RR-NODES type Internal
     Route Distinguisher: 62.0.0.1:0
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [6262] I
     Communities: es-import-target:0-0-0-0-0-0

Не стоит полагать, что из за этого все сломается. Даже с таким комьюнити все будет работать, но если у вас в сети будут, например, 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:

2:62.0.0.2:1::777::aa:bb:cc:00:07:00/304
                   *[BGP/170] 00:00:18, localpref 100, from 62.0.0.255
                      AS path: I, validation-state: unverified
                    > to 10.62.0.1 via ge-0/0/0.0, Push 299792

А вот маршрут типа 1 с того же PE2:

1:62.0.0.2:0::112233445566778899aa::0/304
                   *[BGP/170] 00:00:56, localpref 100, from 62.0.0.255
                      AS path: I, validation-state: unverified
                    > to 10.62.0.1 via ge-0/0/0.0, Push 299792

От PE2 маршурт типа 1 имеет RD 62.0.0.2:0, хотя от этого же PE2 маршруты типа 2 или 3 прилетают с RD 62.0.0.2:1, который и сконфигурен в routing instance. Что происходит с RD? Для проверки данного явления создадим два routing instance с типом EVPN и назначим им совершенно разные RD:

bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-3 | match route
route-distinguisher 62.0.0.1:3;

bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-4 | match route
route-distinguisher 9999:99;

Теперь посмотрим, с каким RD будет анонсироваться маршрут типа 1:

bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 | match "1:6"
  1:62.0.0.1:0::112233445566778899aa::0/304
  1:62.0.0.1:0::aaaa334455667788aaaa::0/304

RD в маршруте не соответствует сконфигуренному ни на RZN-VPN-3, ни на RZN-VPN-4. Откуда же это RD берется? JunOS генерирует его автоматически из router-id или loopback адреса. Причем первое значение имеет приоритет. Например, сейчас имеем router-id:

bormoglotx@RZN-PE-1> show configuration routing-options router-id
router-id 62.0.0.1;

И это значение берется как первая часть RD, а вторая выставляется в нашем случае в ноль. Давайте помянем router id:

bormoglotx@RZN-PE-1> show configuration routing-options router-id
router-id 62.62.62.62;

Смотрим, какие теперь отдаются маршруты:

bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 | match "1:6"
  1:62.62.62.62:0::112233445566778899aa::0/304
  1:62.62.62.62:0::aaaa334455667788aaaa::0/304

Как видите JunOS сам сгенерировал RD. Что будет если мы не укажем router-id? Давайте проверим. Но усложним задачу, навесив на лупбек еще пару адресов:

bormoglotx@RZN-PE-1> show configuration interfaces lo0
description "BGP & MPLS router-id";
unit 0 {
    family inet {
        address 10.1.1.1/32;
        address 62.0.0.1/32;
        address 62.62.62.62/32;
    }
    family iso {
        address 49.0000.0620.0000.0001.00;
    }
}

Смотрим теперь:

bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 | match " 1:(1|6)"
  1:10.1.1.1:0::112233445566778899aa::0/304
  1:10.1.1.1:0::aaaa334455667788aaaa::0/304

JunOS выбрал наименьший IP-адрес лупбека и использовал его как router-id. Это происходит потому, что данный маршрут типа 1 сгенеирирован per-ESI. Если маршрут будет генерироваться per-EVI, то у него будет нативный RD инстанса, из которого данный маршрут анонсируется. А вот маршрут типа 4 всегда будет иметь RD, уникальный на маршрутизатор, так как он всегда генерируется per-ESI.

Генерация маршрута per-ESI имеет некоторую особенность. Так как идентификатор ESI конфигурируется на физическом интерфейсе, то если у нас будет например 10 логических юнитов (можно сказать вланов) на данном интерфейсе и все в разных EVPN-инстансах, то мы получим, что в разных инстансах будет сгенерирован один и тот же маршрут типа 1. Зачем генерировать 10 одинаковых маршрутов (разница в них будет только в RT), если можно сгенерировать только один и навесить на него RT-ки всех заинтересованных в данном маршруте инстансов?

Давайте посмотрим как это работает на примере. Вот конфигурация ESI на физическом интерфейсе:

bormoglotx@RZN-PE-1> show configuration interfaces ge-0/0/2 | match esi | display set
set interfaces ge-0/0/2 esi 00:00:00:00:00:00:00:00:00:07
set interfaces ge-0/0/2 esi single-active

Данный интерфейс используется двумя инстансами с типом evpn:

bormoglotx@RZN-PE-1> show configuration routing-instances | display set | match ge-0/0/2.
set routing-instances RZN-VPN-1 interface ge-0/0/2.0
set routing-instances eVPN-test interface ge-0/0/2.200

Посмотрим, какие RT соответствуют данным инстансам (я удалил политики и прописал RT с помощью vrf-target для наглядности):

bormoglotx@RZN-PE-1> show configuration routing-instances RZN-VPN-1 | match target
vrf-target target:62:1;

bormoglotx@RZN-PE-1> show configuration routing-instances eVPN-test | match target
vrf-target target:62:2;

А теперь посмотрим маршрут типа 1, анонсируемый на рефлектор:

bormoglotx@RZN-PE-1> show route advertising-protocol bgp 62.0.0.255 table __default_evpn__.evpn.0 match-prefix *1:6*:07:* detail

__default_evpn__.evpn.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
* 1:62.0.0.1:0::07::0/304 (1 entry, 1 announced)
 BGP group RR-NODES type Internal
     Route Distinguisher: 62.0.0.1:0
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [6262] I
     Communities: target:62:1 target:62:2 esi-label:100000(label 0)

Как видите, у маршрута две RT-ки: target:62:1, которая соответствует RZN-VPN-1 и target:62:2, соответствующая eVPN-test. Эта функция уменьшает время сходимости. Если данный линк отвалится, то он отвалится у всех инстансов, к которым он прикреплен. В нашем случае вместо 2-x BGP Withdrawn сообщений, улетит только одно, но с двумя RT.

Примечание: маршруты типа 1 и 4 будем рассматривать отдельно в главе, посвященной EVPN multihoming.