Маршрутизация между bridge-доменами

Берем за основу то, что внутри одного bridge-домена пакеты коммутируются, а между разными bridge-доменами (или при выходе во внешнюю сеть) маршрутизируются. Чтобы трафик мог маршрутизироваться, нам надо добавить в наши instance роутинговые интерфейсы. В JunOS роутинговым интерфейсом является IRB (Integrated Routing and Bridging). Данный интерфейс не является тегированным, и с попадающего на него трафика снимается vlan тег. Как и обычный интерфейс на JunOS, IRB имеет юниты. Номер юнита в IRB-интерфейсе (как, собственно, и номера юнитов на физических интерфейсах) не значит, что этот интерфейс относится к какому-то определенному влану. Например, интерфейс irb.777 не обязательно должен относиться к влану 777. Но всё же удобнее читать конфигурационные файлы, когда номер влана и номер IRB юнита в одном bridge-домене одинаковы.

Для простоты в статье я не буду указывать хостнеймы, как они указаны на схеме, а буду использовать сокращения: RZN-CE1-SW1 ⇒ CE1-1 RZN-CE1-SW2 ⇒ CE1-2 RZN-CE2-SW1 ⇒ CE2-1 RZN-CE2-SW2 ⇒ CE2-2 RZN-CE2-SW1 ⇒ CE3

Схема на первый взгляд имеет, мягко говоря, странный вид — на всех PE маршрутизаторах одинаковые IRB-интерфейсы. Думаю, что у вас должны возникнуть как минимум два вопроса — как это работает и зачем это нужно. Давайте попробуем ответить на эти вопросы.

Итак, поехали. Для начала вспомним как работает основной (или дефолтный, кому как нравится) шлюз в уже нами изученном VPLS. У нас есть какой-то PE маршрутизатор, на котором мы создаем IRB-интерфейс. Этот же IRB-интерфейс мы добавляем в какой-нибудь VRF или выпускаем в GRT, если есть такая необходимость. Возможно, что у нас таких маршрутизаторов более одного, и мы используем vrrp для резервирования основного шлюза, но мастером все равно будет кто-то один. То есть в VPLS у нас есть только один выход во внешнюю сеть, расположенный на каком-то PE маршрутизаторе, входящем в VPLS-домен. Весь трафик, направленный наружу, со всех остальных PE маршрутизаторов будет идти через данную PE-ку, так как она является единственным выходом во внешнюю сеть (это, если не применять костыли в виде намеренно сломанного vrrp). Минусы данной схемы очевидны — PE-ке, на которой будет находится дефолтный шлюз, придется переваривать весь исходящий трафик VPLS-домена, направленный во внешнюю сеть и весь входящий в VPLS домен трафик из внешнего мира. А уж, если эта PE-ка откажет, и у нас не собран VRRP, то мы вообще будем отрезаны от других сетей или внешнего мира. Как ни странно, но у данной схемы есть и плюсы — это простота. Любому инженеру описанное выше решение будет понятно и в плане конфигурирования и в плане траблшутинга, чего я не могу сказать про решение, используемое в EVPN.

Помимо описанных выше недостатков, есть еще один важный нюанс — в описанной выше схеме мы никак не можем оптимизировать L3 трафик, идущий внутрь VPLS-домена или выходящий из него.

EVPN предлагает нам совершенно иную схему использования L3 интерфейсов. Если CE маршрутизатор хочет иметь выход во внешнюю сеть, другие вланы или интернет, то на PE-ке, к которой подключен данный CE маршрутизатор, должен быть сконфигурирован дефолтный шлюз в виде L3 интерфейса. Естественно, на каждый влан должен быть свой шлюз.

Примечательно то, что в RFC явно не написано, что каждый PE маршрутизатор должен иметь IRB-интерфейс для возможности выхода во внешнюю сеть. А вот в документации Juniper по настройке EVPN есть вот такие строки:

Initially when EVPN and Layer 3 gateway functionality were conceived, some basic assumptions were made, and RFC requirements were to be followed. These were: 1. All PE’s for an EVPN instance must have an IRB configured. 2. All PE’s should have the same IP address for the GW. From the RFC, if there is a discrepancy between the GW IP addresses, an error is logged. Though it must be noted that different addresses can still be configured as both MAC/IP for advertisement to remote provider edge (PE) devices and are installed on all participating PE devices.

В итоге, если вы используете EVPN/MPLS, то конфигурировать L3 интерфейс на каждом PE маршрутизаторе обязательно, иначе этот сайт просто не выйдет из влана. А вот для EVPN/VXLAN данного требования нет (это, кстати, является существенным отличием EVPN/VXLAN от EVPN/MPLS)

Вернемся к нашей схеме. У нас два bridge-домена — это домен VLAN-777 и VLAN-1777. Во влане 1777 у нас два CE маршрутизатора — это CE1-2 и CE2-2, во влане 777 три маршрутизатора: CE1-1, CE2-1 и CE3. Естественно, я хочу иметь связность между всеми CE маршрутизаторами, указанными на схеме.

Примечание: можно выпустить наш EVPN и в GRT (global routing table), но, мне кажется, что это не очень хорошая идея. Во всяком случае это поддерживается, а уж реализовывать этот функционал или нет — решает каждый сам.

Как было сказано выше, нам необходимо сконфигурировать routing instance с типом VRF и связать ее с EVPN. Ниже представлена конфигурация с PE2 — virtual switch и связанный с ним VRF:

bormoglotx@RZN-PE-2> show configuration routing-instances RZN-VPN-1
instance-type virtual-switch;
interface ge-0/0/2.0;
interface ge-0/0/3.0;
route-distinguisher 62.0.0.2:1;
vrf-import VPN-1-IMPORT;
vrf-export VPN-1-EXPORT;
protocols {
evpn {
extended-vlan-list [ 777 1777 ];
}
}
bridge-domains {
VLAN-1777 {
vlan-id 1777;
routing-interface irb.1777;
}
VLAN-777 {
vlan-id 777;
routing-interface irb.777;
}
}

bormoglotx@RZN-PE-2> show configuration routing-instances VRF-VPN-1
instance-type vrf;
interface irb.777;
interface irb.1777;
route-distinguisher 62.0.0.2:10002;
vrf-target {
import target:6262:10001;
export target:6262:10001;
}
vrf-table-label;

Такие же VRF поднимаются на остальных PE маршрутизаторах, за исключением того, что в VRF на PE3 нет интерфейса irb.1777.

Мы уже знаем, что маршрут типа 2 может опционально содержать IP-адрес хоста. Сам маршрут MAC+IP мы уже видели: если помните, то при добавлении в EVPN IRB-интерфейса у нас генерировались два маршрута: просто MAC-адрес IRB-интерфейса, чтобы можно было до него добраться внутри bridge-домена не прибегая к маршрутизации и MAC+IP, к которому прикреплялось комьюнити default gateway. Второй маршрут был необходим для роутинга и является arp записью. Но MAC+IP маршрут генерируется не только для дефолтного шлюза. Такой маршрут до какого либо хоста будет появляться в том случае, если это хост попытается выйти во внешнюю сеть или другой влан.

Что надо хосту, чтобы выйти из влана? Верно — необходимо отправить пакет на шлюз по умолчанию. В нашем случае роль шлюза для bridge-домена играет IRB-интерфейс PE маршрутизатора. А чтобы послать пакет на IRB-интерфейс, хосту надо знать MAC-адрес этого IRB-интерфейса. Поэтому, для начала хост отправляет arp запрос на резолв MAC-адреса IRB-интерфейса. В тот момент, когда IRB-интерфейс получает arp запрос от хоста (в нашем случае CE маршрутизатора), который к данному PE маршрутизатору непосредственно подключен*, он и генерирует два маршрута типа 2: только MAC-адрес и MAC+IP — и рассылает их по BGP в виде EVPN маршрутов. Помимо этого, так как этот же маршрут в виде обычного IPv4 префикса с маской /32 появится еще и в связанном с EVPN VRF-е как локальный маршрут, то по BGP отправляется еще и vpnv4 маршрут до данного хоста (зачем нужно второе — поймете позже). Собственно, вышеописанное — это главный принцип работы EVPN при маршрутизации между вланами, который и позволяет оптимизировать прохождение трафика между разными bridge-доменами или между EVPN и внешними сетями.

Саму таблицу arp записей можно посмотреть на каждом PE маршрутизаторе. Для примера на PE2:

bormoglotx@RZN-PE-2> show bridge evpn arp-table
INET MAC Logical Routing Bridging
address address interface instance domain
10.0.1.2 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777
10.0.1.22 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777
10.0.1.222 aa:bb:cc:00:0a:00 irb.1777 RZN-VPN-1 VLAN-1777
10.0.0.2 aa:bb:cc:00:07:00 irb.777 RZN-VPN-1 VLAN-777

*10.0.1.22 и 10.0.1.222 — это secondary адреса CE2-2, навешенные в ходе тестирования для снятия дампов.

В выводе указывается, с какого интерфейса был сделан arp запрос, в каком bridge-домене и routing instance. Эта информация будет полезна, так как один и тот же MAC-адрес может быть в разных вланах или, как в представленном выше выводе — на одном физическом интерфейсе может быть несколько адресов, и, естественно, у них будет один MAC-адрес. Ко всем этим хостам вы обязательно найдете маршрут в VRF:

bormoglotx@RZN-PE-2> show route table VRF-VPN-1.inet.0 active-path | match "(10.0.0.2\/)|(10.0.1.2{1,3}\/)"
10.0.0.2/32 *[EVPN/7] 00:09:38
10.0.1.2/32 *[EVPN/7] 09:11:03
10.0.1.22/32 *[EVPN/7] 02:02:40
10.0.1.222/32 *[EVPN/7] 01:54:26

Теперь перейдем от теории к практике: разберем, как трафик будет идти от CE3 к CE1-2. Первый находится во влане 777 и имеет адрес 10.0.0.3, второй во влане 1777 и имеет адрес 10.0.1.1. Напоминаю, что на PE3 нет локального интерфейса irb.1777.

Итак, CE3 хочет отправить пакет на CE1-2, который находится в другой сети. CE3 не знает мак адрес основного шлюза, поэтому делает arp запрос на резолв адреса 10.0.0.254, который для данного CE маршрутизатора является основным шлюзом в другие сети. Естественно, на CE3 (да и на всех остальных CE-маршрутизаторах прописан дефолтный маршрут в сторону IRB-интерфейса). Так как PE3 получает arp запрос от CE3, адресованный его локальному IRB-интерфейсу, то PE3 генерирует MAC+IP маршрут и отправляет его на остальные PE-ки. Помимо этого, так как маршрут 10.0.0.3/32 появился в VRF в виде локального маршрута, то PE3 анонсирует еще и BGP vpnv4 маршрут:

bormoglotx@RZN-PE-3> show route advertising-protocol bgp 62.0.0.255 | match 10.0.0.3
* 10.0.0.3/32 Self 100 I
2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304

Примечание: как правило, маршрут типа 2, содержащий только MAC-адрес, бывает уже сгенерирован раннее. В таком случае данный маршрут повторно не генерируется, дабы избежать флапов. PE маршрутизатор просто генерирует только MAC+IP анонс. Это не сложно увидеть на практике, посмотрев время жизни этих маршрутов — оно, как правило, будет разным.

Двигаемся далее. CE3 теперь знает MAC-адрес дефолтного шлюза, а значит знает, куда надо слать пакет, адресованный CE1-1 (имеется в виду MAC-адрес L2 заголовка). CE3 формирует пакет и в L3 заголовке адресом назначения указывает адрес CE1-1 (10.0.1.1), исходящим адресом указывает собственный адрес CE3 (10.0.0.3). В L2 заголовке адресом назначения указывает мак адрес irb.777, а исходящим адресом — собственный MAC-адрес (адрес интерфейса в сторону PE маршрутизатора).

Пакет прилетает на PE3. Так как MAC-адрес назначения — локальный интерфейс irb.777, то PE3 снимает L2 заголовок и делает IP lookup в таблице маршрутизации VRF, которая связана с нашей EVPN-instance. В настоящий момент в данной таблице четыре активных маршрута:

bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 active-path

VRF-VPN-1.inet.0: 4 destinations, 9 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.0/24 *[Direct/0] 00:20:05
> via irb.777
10.0.0.3/32 *[EVPN/7] 00:00:06
> via irb.777
10.0.0.254/32 *[Local/0] 04:04:34
Local via irb.777
10.0.1.0/24 *[BGP/170] 02:19:20, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)

10.0.0.0/24 и 10.0.0.3/32 локальны для PE3 (второй как раз был сгенерирован при arp-запросе на irb.777), а вот маршрут до сети 10.0.1.0/24 мы получаем по BGP от PE1 и PE2.

Так как на PE1 и PE2 создан такой же VRF, как и на PE3 (с одинаковыми RT), то PE3 принимает все анонсы от PE1 и PE2. На них (PE1 и PE2), в свою очередь в данный VRF добавлен интерфейс irb.1777, а значит они будут анонсировать маршут до сети 10.0.1.0/24 по BGP в виде обычного vpnv4 маршрута, который и будет импортирован в таблицу маршрутизации VRF на PE3. В выводе выше показаны только активные маршруты, поэтому мы видим только один анонс, всего их, естественно, два — один получен от PE1, второй — от PE2. Лучшим выбран маршрут от PE1, так как он имеет меньший router-id, а все остальные параметры маршрутов, полученных от обоих PE-шек полностью идентичны. Какой маршрут будет выбран лучшим — от PE1 или PE2 — абсолютно неважно (к примеру если у нас будет 10 сайтов, то мы будем получать 9 маршрутов к одной сети, но выберется все равно только один), так как все равно при получении BUM трафика из bridge-домена VLAN-777, PE1 будет флудить его во все интерфейсы bridge-домена VLAN-1777. Почему — выясним далее.

В ходе IP lookup-а, PE3 поимает, что префикс 10.0.1.0/24 находится на PE1, поэтому PE3 отправляет пакет через L3VPN на PE1:

bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.0/24 active-path

VRF-VPN-1.inet.0: 4 destinations, 9 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.0/24 *[BGP/170] 02:23:12, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)

Возможен вариант, когда на PE3 будет включена балансировка трафика по эквивалентным путям (ECMP) и в FIB будет установлено два маршрута, а значит трафик может пойти и на PE2, но это, как я написал выше, не важно — главное чтобы пакет попал на PE маршрутизатор, на котором есть локальный bridge-домен VLAN-1777 (по-другому быть и не может, если, конечно, у вас не настроен какой-нибудь жесткий ликинг между VRF-ми). Если такого bridge-домена на PE-ке не будет, то не будет и от нее анонса до сети 10.0.1.0/24.

PE1 принимает пакет от PE3 в VRF, делает IP lookup и понимает, что пакет предназначен bridge-домену VLAN-1777:

bormoglotx@RZN-PE-1> show route table mpls.0 label 16

mpls.0: 22 destinations, 23 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

16 *[VPN/0] 02:25:02
to table VRF-VPN-1.inet.0, Pop

Так как PE1 не знает MAC-адреса хоста 10.0.1.1, то производится флуд arp запроса во все интерфейсы bridge-домена VLAN-1777 на резолв данного адреса. Если быть точнее, одна копия пакета отправляется на CE1-2, а вторая, с inclusive multicast меткой на PE2. А как же функция split horizon? Ведь пакет, полученный от PE маршрутизатора, не должен отправляться на другие PE маршрутизаторы. А тут по факту мы его нарушаем без зазрения совести. Дело в том, что данный пакет пришел, по L3VPN (то есть по сути из какой то внешней сети по отношению к EVPN на PE1), поэтому правило split-horizon тут не работает. Но мы то знаем что пакет прилетел из EVPN — не возникнет ли широковещательного шторма? Пакет хоть и прилетел из evpn, но из другого широковещательного домена (CE3 находится во влане 777, а CE1-2 во влане 1777). Так как это разные bridge-домены, то и широковещательного шторма между ними возникнуть не может — пакеты то между bridge-доменами маршрутизируются.

Так как CE1-2 является хостом назначения и подключен к PE1, то он отвечает на данный arp запрос. Как мы помним, после получения arp-а, адресованного IRB-интерфейсу от какого либо хоста, PE маршрутизатор должен сгенерировать маршрут типа 2 MAC+IP. В связи с этим, PE1 генерирует MAC+IP и vpnv4 маршрут:

bormoglotx@RZN-PE-3> show route table RZN-VPN-1.evpn.0 match-prefix *10.0.1.1*

RZN-VPN-1.evpn.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:62.0.0.1:1::1777::aa:bb:cc:00:09:00::10.0.1.1/304
*[BGP/170] 00:02:46, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 299792

bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32

VRF-VPN-1.inet.0: 5 destinations, 10 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.1/32 *[BGP/170] 00:02:48, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299792(top)

Теперь у PE1 есть маршрут MAC+IP до хоста 10.0.0.3 в таблице маршрутизации EVPN и 10.0.0.3/32 в таблице маршрутизации VRF. Аналогично и со стороны PE3: маршрут до хоста 10.0.1.1/32 есть в таблице маршрутизации epn и VRF. Выходит, что теперь обмену пакетами между CE3 и CE1-2 ничего не препятствует. Но есть один нюанс. Давайте посмотрим таблицу маршрутизации в VRF на PE1:

bormoglotx@RZN-PE-1> show route table VRF-VPN-1.inet.0 10.0.0.3/32

VRF-VPN-1.inet.0: 7 destinations, 15 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.3/32 *[EVPN/7] 00:24:37, metric2 1
> to 10.62.0.1 via ge-0/0/0.0, Push 300352, Push 299792(top)
[BGP/170] 00:24:37, 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 16, Push 299792(top)

На PE1 два маршрута до хоста 10.0.0.3/32, в то время как на PE3 есть только один маршрут до 10.0.1.1/32:

bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32

VRF-VPN-1.inet.0: 6 destinations, 11 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.1.1/32 *[BGP/170] 02:25:44, localpref 100, from 62.0.0.255
AS path: I, validation-state: unverified
> to 10.62.0.5 via ge-0/0/0.0, Push 16, Push 299776(top)

В VRF появился какой то странный маршрут с пока что нам неизвестным протоколом EVPN, да еще и преференсом 7, что его делает лучше BGP ( а также предпочтительнее маршрутов ISIS, OSPF и т д). Как то странно, не правда ли. Что это за маршрут? Зачем он нам нужен, ведь и без него все будет работать. Дело в том, что данный маршрут необходим для прямого обмена трафиком между EVPN, минуя L3VPN. Давайте его рассмотрим внимательно:

bormoglotx@RZN-PE-1> show route table VRF-VPN-1.inet.0 10.0.0.3/32 protocol evpn detail

VRF-VPN-1.inet.0: 7 destinations, 15 routes (7 active, 0 holddown, 0 hidden)
10.0.0.3/32 (2 entries, 1 announced)
*EVPN Preference: 7
Next hop type: Indirect
Address: 0x97f5f90
Next-hop reference count: 2
Next hop type: Router, Next hop index: 615
Next hop: 10.62.0.1 via ge-0/0/0.0, selected
Label operation: Push 300352, Push 299792(top)
Label TTL action: no-prop-ttl, no-prop-ttl(top)
Load balance label: Label 300352: None; Label 299792: None;
Session Id: 0x1
Protocol next hop: 62.0.0.3
Label operation: Push 300352
Label TTL action: no-prop-ttl
Load balance label: Label 300352: None;
Composite next hop: 0x95117b8 670 INH Session ID: 0x2
Ethernet header rewrite:
SMAC: 02:00:00:00:07:77, DMAC: aa:bb:cc:00:05:00
TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800
Indirect next hop: 0x9860990 1048583 INH Session ID: 0x2
State: Active NoReadvrt Int Ext
Age: 1:09 Metric2: 1
Validation State: unverified
Task: RZN-VPN-1-evpn
Announcement bits (1): 0-KRT
AS path: I

Нам интересны следующие строки этого вывода:

Ethernet header rewrite:
SMAC: 02:00:00:00:07:77, DMAC: aa:bb:cc:00:05:00
TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800

Это не что иное, как указание, какой надо добавить L2 заголовок, чтобы отправить пакет на CE3! Посмотрим, что за MAC-адрес указан как источник: SMAC: 00:05:86:71:1a:f0. Логично, что если это источник пакета, то он должен быть на PE1. Давайте прикинем, с какого MAC-адреса могут уходить пакеты во влан 777? Логично предположить, что это будет интерфейс irb.777, а значит в L2 заголовке должен быть именно его MAC. Посмотрим, какой в действительности MAC-адрес у irb.777:

bormoglotx@RZN-PE-1> show interfaces irb.777 | match mac
MAC: 02:00:00:00:07:77

Все верно, в заголовке указан MAC-адрес локального интерфейса irb.777 на PE1, а значит наши рассуждения были верны. Давайте теперь идентифицируем, кому же принадлежит MAC-адрес назначения: DMAC: aa:bb:cc:00:05:00? Думаю, гадать не стоит — это должен быть MAC CE3. Давайте проверять:

bormoglotx@RZN-PE-1> show route table RZN-VPN-1.evpn.0 match-prefix *10.0.0.3*

RZN-VPN-1.evpn.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304
*[BGP/170] 00:05: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

Данный MAC принадлежит хосту 10.0.0.3, куда и указывает маршрут. Для достоверности пойдем на CE3 и посмотрим, как MAC на ее интерфейсе в сторону PE:

RZN-CE3-SW1#sh ip int br | i 10.0.0.3
Ethernet0/0.777 10.0.0.3 YES NVRAM up up

RZN-CE3-SW1#sh interfaces eth0/0.777 | i Hard
Hardware is AmdP2, address is aabb.cc00.0500 (bia aabb.cc00.0500)

Принадлежность адресов мы установили. Теперь поглядим на вторую строку интересующей нас части вывода:

TPID: 0x8100, TCI: 0x0309, VLAN ID: 777, Ethertype: 0x0800

А это значения, которыми необходимо заполнить остальные поля ethernet кадра при отправке на CE3.

То есть данный маршрут нам явно указывает, что если надо отправить ethernet кадр с irb.777 на хост CE3, то надо добавить указанные значения в L2 заголовок, навесить две метки: Push 300352, Push 299792(top) и отправить пакет в интерфейс ge-0/0/0.0. Все просто.

Примечание: данное действие с пакетом подразумевает использование composite next hop. Именно поэтому включение функционала chained-composite-next-hop обязательно на Juniper, при настройке EVPN.

bormoglotx@RZN-PE-1> show configuration routing-options forwarding-table
chained-composite-next-hop {
ingress {
evpn;
}
}

Откуда же берется данный маршрут? Может быть нам его прислала PE3? Давайте проверим что анонсирует PE3 на рефлектор:

bormoglotx@RZN-PE-3> show route advertising-protocol bgp 62.0.0.255 | match 10.0.0.3
* 10.0.0.3/32 Self 100 I
2:62.0.0.3:1::777::aa:bb:cc:00:05:00::10.0.0.3/304

Ничего криминального, только два маршрута имеют в своем составе адрес 10.0.0.3. Первый — vpnv4 маршрут, второй — EVPN тип 2.

Значит этот маршрут локален для PE-маршрутизатора. Все верно. Данный маршрут генерируется локальным PE маршрутизатором на основе EVPN MAC+IP маршрута. Но тогда почему его нет на PE3? Воспользовавшись методом банальной эрудиции, можно прийти к выводу, что на PE3 нет bridge-домена влан 1777 с интерфейсом irb.1777 (ведь с него должен уходить пакет на CE1-2) и интерфейса irb.1777 нет в связанном VRF. А так как нет локального интерфейса, то какой MAC-адрес указать как source? Не поставишь же адрес другого интерфейса. Вот поэтому данный маршрут и отсутствует на PE3. Давайте проверим эту теорию — деактивируем на PE1 в VRF интерфейс irb.777, с которого должен будет улетать пакет на PE3.

Итак, маршрут на PE1 сейчас есть:

[edit]
bormoglotx@RZN-PE-1# run show route table VRF-VPN-1.inet.0 10.0.0.3/32

VRF-VPN-1.inet.0: 8 destinations, 18 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.3/32 *[EVPN/7] 00:01:22, metric2 1
> to 10.62.0.1 via ge-0/0/0.0, Push 300352, Push 299792(top)
[BGP/170] 00:04:41, 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 16, Push 299792(top)

Деактивируем интерфейс IRB в VRF на PE1:

[edit]
bormoglotx@RZN-PE-1# show | compare
[edit routing-instances VRF-VPN-1]
! inactive: interface irb.777 { ... }

И проверяем, что у нас с маршрутом до 10.0.0.3/32:

[edit]
bormoglotx@RZN-PE-1# run show route table VRF-VPN-1.inet.0 10.0.0.3/32

VRF-VPN-1.inet.0: 7 destinations, 13 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.3/32 *[BGP/170] 00:05:47, 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 16, Push 299792(top)

Ну и проверим, а пройдет ли пинг?

RZN-CE1-SW2#ping 10.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/14/21 ms

Естественно, пинг прошел, но теперь трафик идет через L3VPN в обе стороны. Но хочется сказать, что даже в таком сценарии маршрут трафика оптимизирован. Тоже самое произойдет, если вывести bridge-домен VLAN-777 из конфигурации (в этом случае irb.777 еще будет в VRF, но в состоянии down, так как для того, чтобы IRB-интерфейс был в up, необходим хотя бы один физический интерфейс в состоянии up в bridge-домене, в котором находится IRB-интерфейс).

Но мы остановились на том, что пакет от CE3 дошел до CE1-2.Теперь CE1-2 хочет ответить на данный пакет. Здесь мы уже обойдемся без выводов из CLI.

Итак, CE1-2 отправляет пакет на адрес основного шлюза, адрес которого он уже знает. PE1 принимает пакет в bridge-домене VLAN-1777. Так как в пакете в L2 заголовке адресом назначения указан irb.1777, то PE1 снимает L2 заголовок и делает IP lookup в таблице маршрутизации VRF. В таблице маршрутизации есть маршрут до хоста 10.0.0.3/32, причем, как показано выше, маршрутов два и лучший EVPN. PE1 просто меняет L2 заголовок, навешивает метки и отправляет пакет на PE3.

PE3 получает пакет, видит метку, которая указывает на то, что необходимо сделать L2 lookup в MAC-таблице bridge-домена VLAN-777, и, согласно информации в ней, переслать пакет на CE3.

Собственно, вот мы и рассмотрели весь процесс, происходящий с пакетом, при его движении от CE3 к CE1-2 и обратно. Но мы рассмотрели процесс в момент, когда еще не было трафика между данными узлами и PE маршрутизаторы не знали MAC-адресов CE1-2 и CE3. После того, как адреса стали известны и маршруты разлетелись по всем PE-кам, трафик пойдет несколько иначе. Давайте вкратце рассмотрим, как конечном итоге будет идти трафик:

От CE3 к CE1-2:

  1. Пакет от CE3 попадает в bridge-домен влан 777 на PE3.

  2. PE3 делает IP lookup в звязанном VRF и видит специфичный маршрут до хоста 10.0.1.1/32. Так как на PE3 нет локального bridge-домена влан 1777, то и нет и EVPN маршрута. Значит трафик идет через L3VPN на PE1.

  3. PE1 принимает пакет в VRF, снимает с него метку и видит, что он предназначен bridge-домену влан 1777.

  4. PE1 отправляет пакет на CE2-1 согласно MAC-таблице bridge-домена влан 1777.

  1. CE1-2 отправляет ответный пакет на PE1.

  2. PE1 делает IP lookup в VRF и видит маршрут к хоста 10.0.0.3/32, причем лучший маршрут — это маршрут EVPN.

  3. PE1 навешивает новый L2 заголовок и добавляет стек из двух меток, согласно информации, содержащейся в EVPN в маршруте в связанном VRF.

  4. PE3 принимает пакет от PE1, снимает метку и видит, что необходимо сделать L2 lookup в MAC-таблице bridge-домена VLAN-777.

  5. Далее PE3 пересылает пакет на CE3.

Схема, которую мы разобрали, называется схемой с симметричным использованием IRB-интерфейсов (разные вендоры могут по разному называть данную схему, указанный термин взят из мануалов по настройке EVPN на Brocade). Асимметричной схемой будет являться схема, когда на всех PE маршрутизаторах будут одинаковые IRB-интерфейсы, даже при условии того что указанного влана на данном PE маршрутизаторе нет. Плюсом асимметричной схемы будет то, что во всех VRF будут маршруты протокола EVPN ([EVPN/7]) и ваш трафик не будет проходить в одну сторону через L3VPN, а обратно напрямую в EVPN. В нашем случае, если мы добавим в схему irb.1777 на PE3, то мы получим асимметричную схему.

Но есть еще одно но, которое надо осветить.

Как вы знаете, ARP запрос отправляется на бродкастный адрес, а ответ на него форвардится назад по указанному в заголовке MAC-адресу отправителя.

В рассмотренном выше случае CE1-2 был непосредственно подключен к PE1 и все работало штатно: PE1 отправлял arp запрос, и CE1-2 ему отвечал — собственно, никаких проблем. Но, если бы CE3 отправлял пакет на CE2-2, то события развивались несколько иначе. Сначала все так же, как и описано ранее:

  1. PE3 смотрит в таблицу маршрутизации VRF и видит маршрут к сети 10.0.1.0/24, полученный от PE1.

  2. У PE3 нет других вариантов, кроме как отправить пакет через L3VPN на PE1.

  3. PE1 принимает пакет, делает L3 lookup и переправляет его в bridge-домен VLAN-1777. Так как irb.1777 еще не знает MAC-адрес CE2-2, то он инициирует arp запрос на резолв адреса CE2-2 (10.0.1.2), отправляя пакет на CE1-2 и PE2.

  4. CE1-2 дропает пакет, так как адрес 10.0.1.2 ему не принадлежит. PE2 пересылает полученный запрос на CE2-2.

  5. CE2-2 принимает arp запрос и отвечает на него юникастом на MAC-адрес, принадлежащий irb.1777 на PE1.

Но получит ли irb.1777 на PE1 ответ от CE2-2? Вспоминаем про синхронизацию MAC-адресов между дефолтными шлюзами. Вспомнили? Значит понимаете, что irb.1777 на PE2 примет пакет, направленный на MAC-адрес irb.1777 PE1. В итоге PE1 не получит ответа на свой запрос, сколько бы он их ни отправлял, а значит не разрезолвит IP-адрес назначения и не сможет отправить пакет на CE2-2. Все было бы так, если бы это был бы не EVPN.

Так как irb.1777 на PE2 принял arp от CE2-2, то он генерирует маршрут типа 2 (MAC и MAC+IP), а также vpnv4 префикс. Как понимаете PE1 уже не нужен ответ на его arp запрос, так как теперь он получил MAC-адрес CE2-2 по BGP и может переслать ему пакет, который находился в буфере. Получается, что трафик на CE2-2, который живет на PE2 идет с PE3 петлей через PE1? Не совсем так. Петлей прилетел только пакет (или пакеты), который PE3 уже успел отправить и которые находились в очереди на отправку на PE1. Но так как и на PE3 появился в VRF более специфичый маршрут до CE2-2, то в дальнейшем трафик уже пойдет не через PE1 по маршруту 10.0.1.0/24, а напрямую на PE2 (по маршруту 10.0.1.2/32, который появится в таблице маршрутизации VRF).

В рассмотренном нами случае у всех IRB-интерфейсов были разные MAC-адреса, что подразумевало необходимость в синхронизации дефолтных шлюзов. Рекомендуемый вариант использования IRB-интерфейсов — использовать одинаковые MAC и IP-адреса на всех PE маршрутизаторах одного bridge-домена. Как вы понимаете, когда везде MAC-адреса будут одинаковы и все будет работать так, как я описал выше, только синхронизации дефолтных шлюзов, по сути, не надо.

В конечном счете, при любом раскладе, как бы вы ни использовали IRB-интерфейсы: с одинаковыми IP, но разными MAC-адресами; с одинаковыми IP и MAC-адресам, все равно все PE маршрутизаторы в EVPN-домене получат маршрут MAC+IP и BGP vpnv4 префикс, а значит при отправке пакета с другого CE маршрутизатора не потребуется снова отправлять arp запрос на резолв данного адреса. Это позволяет существенно сократить arp флудинг по сети провайдера.

PreviousIRB synchronisationNextВыход в другие VRF и внешние сети

Last updated