Выше мы разобрали, как трафик будет идти между вланами. Но как быть с доступом из других VRF, никак не связанных evpn?
Давайте попробуем достучаться до например хоста 10.0.1.1/32 из VRF, который не связан ни с одной EVPN. Делать новый VRF мне не хочется, поэтому я поступлю проще: на PE3 деактивируем instance evpn, а в VRF деактивируем irb.777 и добавим новый интерфейс irb.0 (20.0.0.1/24):
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 active-path
VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/24 *[BGP/170] 00:00:03, 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.1.0/24 *[BGP/170] 00:00:03, 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.1.1/32 *[BGP/170] 00:00:03, 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.1.2/32 *[BGP/170] 00:00:03, 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)
10.0.1.22/32 *[BGP/170] 00:00:03, 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)
20.0.0.0/24 *[Direct/0] 00:00:03
> via irb.0
20.0.0.1/32 *[Local/0] 00:00:03
Local via irb.0
Я специально деактивировал данный VRF, чтобы показать, что маршруты /32 сразу прилетят в виде vpnv4 префиксов и встанут в таблицу маршрутизации (как видите время жизни маршрута в таблице у всех префиксов одинаково и равно трем секундам).
Теперь запустим пинг с нашего IRB-интерфейса (20.0.0.1) на CE1-2 (10.0.1.1), который живет за PE1:
Теперь снова вернемся к маршрутам и посмотрим, разными ли путями идут пакеты:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.1/32
VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.1/32 *[BGP/170] 00:03:50, 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)
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.1.2/32
VRF-VPN-1.inet.0: 7 destinations, 9 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.2/32 *[BGP/170] 00:03:52, 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)
Итак, до 10.0.1.1 транспортная метка 299776, а до 10.0.1.2 — 299792. Смотрим, что это за LSP:
Метка 299776 — транспортная метка до 62.0.0.1 (PE1):
bormoglotx@RZN-PE-3> show route 62.0.0.1/32 table inet.3
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
62.0.0.1/32 *[LDP/9] 03:36:41, metric 1
> to 10.62.0.5 via ge-0/0/0.0, Push 299776
Метка 299776 — транспортная метка до 62.0.0.2 (PE2):
bormoglotx@RZN-PE-3> show route 62.0.0.2/32 table inet.3
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
62.0.0.2/32 *[LDP/9] 03:36:45, metric 1
> to 10.62.0.5 via ge-0/0/0.0, Push 299792
Как видите, даже из VRF, абсолютно ничего не знающего про EVPN, трафик идет оптимальным путем. Обратный трафик из EVPN в VRF до сети 20.0.0.0/24 идет по маршруту, полученному по BGP:
bormoglotx@RZN-PE-2> show route table VRF-VPN-1.inet.0 20.0.0.0/24 active-path
VRF-VPN-1.inet.0: 10 destinations, 16 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
20.0.0.0/24 *[BGP/170] 00:06:44, 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 16, Push 299808(top)
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.2/32
bormoglotx@RZN-PE-3>
Маршрута и правда нет, но зато у нас есть маршрут до 10.0.0.0/24:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.0/24 | match \/24
10.0.0.0/24 *[BGP/170] 00:13:14, localpref 100, from 62.0.0.255
Логично, что трафик пойдет по этому маршруту. Запустим пинг и проверим, что все работает:
bormoglotx@RZN-PE-3> ping rapid routing-instance VRF-VPN-1 source source 20.0.0.1 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
!!!!!
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 6.135/7.206/7.806/0.663 ms
Пинг успешно прошел, а в VRF у нас появился маршрут до хоста 10.0.0.2/32:
bormoglotx@RZN-PE-3> show route table VRF-VPN-1.inet.0 10.0.0.2/32
VRF-VPN-1.inet.0: 9 destinations, 11 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.2/32 *[BGP/170] 00:00:06, 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)
Надеюсь, вы поняли как это работает.
Путь пакета из VRF (irb.0 20.0.0.1) в EVPN (CE1-2 10.0.1.1):
Маршрут прохождения обратного трафика:
Но представленный случай прост — маршруты до хостов 10.0.1.1 и 10.0.1.2 уже были в таблице маршрутизации. Как быть, если маршрута до хоста нет? Тут все работает так же, как при в первом случае (когда на PE маршрутизаторе нет bridge-домена, в котором живет хост назначения). Давайте достучимся например до 10.0.0.2, специфичного маршрута до которого у нас в данный момент нет:
