# Выход в другие VRF и внешние сети Выше мы разобрали, как трафик будет идти между вланами. Но как быть с доступом из других VRF, никак не связанных evpn? Давайте попробуем достучаться до например хоста 10.0.1.1/32 из VRF, который не связан ни с одной EVPN. Делать новый VRF мне не хочется, поэтому я поступлю проще: на PE3 деактивируем instance evpn, а в VRF деактивируем irb.777 и добавим новый интерфейс irb.0 (20.0.0.1/24):\ ![](https://habrastorage.org/files/e23/2b6/c6b/e232b6c6bb4241b5be302c3100bdd3ed.png) ``` [edit] bormoglotx@RZN-PE-3# show routing-instances RZN-VPN-1 ## ## inactive: routing-instances RZN-VPN-1 ## instance-type evpn; vlan-id 777; interface ge-0/0/2.777; routing-interface irb.777; route-distinguisher 62.0.0.3:1; vrf-import VPN-1-IMPORT; vrf-export VPN-1-EXPORT; protocols { evpn { interface ge-0/0/2.777; } } [edit] bormoglotx@RZN-PE-3# show routing-instances VRF-VPN-1 instance-type vrf; interface irb.0; inactive: interface irb.777; route-distinguisher 62.0.0.3:10003; vrf-target { import target:6262:10001; export target:6262:10001; } vrf-table-label; [edit] bormoglotx@RZN-PE-3# show interfaces irb.0 family inet { address 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> ping rapid routing-instance VRF-VPN-1 source 20.0.0.1 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 56 data bytes !!!!! --- 10.0.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.828/7.872/10.368/1.655 ms ``` А теперь до хоста CE2-2 10.0.1.2, который живет на PE2: ``` bormoglotx@RZN-PE-3> ping rapid routing-instance VRF-VPN-1 source 20.0.0.1 10.0.1.2 PING 10.0.1.2 (10.0.1.2): 56 data bytes !!!!! --- 10.0.1.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.443/6.713/7.342/0.656 ms ``` Теперь снова вернемся к маршрутам и посмотрим, разными ли путями идут пакеты: ``` 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) ``` Путь пакета из VRF (irb.0 20.0.0.1) в EVPN (CE1-2 10.0.1.1):\ ![](https://habrastorage.org/files/b3a/7fa/e91/b3a7fae9168c44aeb39cb43a584462fb.png)\ Маршрут прохождения обратного трафика:\ ![](https://habrastorage.org/files/c80/bda/15b/c80bda15b99142379a90aca233280d0b.png)\ Но представленный случай прост — маршруты до хостов 10.0.1.1 и 10.0.1.2 уже были в таблице маршрутизации. Как быть, если маршрута до хоста нет? Тут все работает так же, как при в первом случае (когда на PE маршрутизаторе нет bridge-домена, в котором живет хост назначения). Давайте достучимся например до 10.0.0.2, специфичного маршрута до которого у нас в данный момент нет: ``` 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) ``` Надеюсь, вы поняли как это работает. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://linkmeup.gitbook.io/sdsm/12.1.-mpls-evpn/4.-l3vpn-evpn/2.-inter-vrf.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.