Все выпуски
11. Сети для самых маленьких. Часть одиннадцатая. MPLS L3VPN
10. Сети для самых маленьких. Часть десятая. Базовый MPLS
9. Сети для самых маленьких. Часть девятая. Мультикаст
8.1 Сети для Самых Маленьких. Микровыпуск №3. IBGP
8. Сети для самых маленьких. Часть восьмая. BGP и IP SLA
7. Сети для самых маленьких. Часть седьмая. VPN
6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование
10. Сети для самых маленьких. Часть десятая. Базовый MPLS
9. Сети для самых маленьких. Часть девятая. Мультикаст
8.1 Сети для Самых Маленьких. Микровыпуск №3. IBGP
8. Сети для самых маленьких. Часть восьмая. BGP и IP SLA
7. Сети для самых маленьких. Часть седьмая. VPN
6. Сети для самых маленьких. Часть шестая. Динамическая маршрутизация
5. Сети для самых маленьких: Часть пятая. NAT и ACL
4. Сети для самых маленьких: Часть четвёртая. STP
3. Сети для самых маленьких: Часть третья. Статическая маршрутизация
2. Сети для самых маленьких. Часть вторая. Коммутация
1. Сети для самых маленьких. Часть первая. Подключение к оборудованию cisco
0. Сети для самых маленьких. Часть нулевая. Планирование
Статья про L3VPN получилась большой — ни много ни мало 130 000 символов.
Учитывая, что и её ещё не все дочитали, эту часть про доступ в Интернет мы вынесли в отдельную публикацию.
Это особенно важно, потому что в рунете, да и вообще в интернетах, нет доступного разбора этой темы.
Вполне вероятно, что вы сейчас читаете эксклюзивный материал.
Итак, есть оператор связи, который предоставляет своему клиенту L3VPN. Ни с того ни с сего, с бухты да барахты понадобился ему ещё и Интернет.
Самое очевидное решение — прокинуть ещё один кабель — в одном VPN, в другом Интернет.
Допустим, это сложно. Тогда можно поднять сабинтерфейс и передавать фотки вконтактике в отдельном VLAN'е.
Допустим, там сложный арендованный канал, где можно прокинуть только 1 VLAN или оборудование клиента не умеет VLAN (стоит обычный компьютер), что тогда?
Об этом следующие 36 000 букв вашей жизни.
Содержание выпуска
Итак, провайдер в тот же самый VPN продаёт и доступ в Интернет, через то же самое подключение, через те же адреса. Это значит, что в сети провайдера придётся где-то настроить доступ из приватной сети, в публичную, а следовательно обеспечить пересечение маршрутной информации.
Всё это непотребство имеет своё название — Route Leaking — маршруты протекают из VRF в глобальную таблицу. Название функционала говорящее — прибегать к Route Leaking'у особенно через статические маршруты нужно только в крайних случаях, ибо жуткий костыль.
Есть два подхода к реализации этого функционала:
- Настройка статических маршрутов из VRF в публичную сеть и наоборот.
- Жонглирование Route Target'ами.
Оба имеют право на жизнь.
Начнём со статики.
Ясное дело, нам понадобится NAT, чтобы спрятать частные сети.
Сценарии различаются лишь местом применения:
- В сети клиента — CE NAT.
- В сети провайдера на крайнем PE — PE NAT.
- В сети провайдера на точке выхода в Интернет — VRF Aware NAT.
NAT на CE
Провайдер выдаёт клиенту пул публичных адресов, в который тот транслирует свои внутренние. Всё, что остаётся сделать провайдеру — настроить маршрутизацию между VRF и глобальной таблицей.
Учитывая, что трансляция будет на CE, нужно выбрать только один филиал, пусть это будет TARS_2 — там как раз у нас линковая сеть публичная — 100.0.1.0/30.
![](https://habrastorage.org/getpro/habr/post_images/1c5/27e/79f/1c527e79fd5bd74c50ad83ee5c9baa18.png)
Как видите, для этого теста нам нужно что-то в качестве Интернета и компьютер, которому доступ туда нужен.
В GNS есть такой чудесный объект, как VPCS, который прекрасно подходит на эту роль.
На TARS_2 нужно настроить NAT, ниже его конфигурация:
TARS_2(config)#interface Loopback0
TARS_2(config-if)#ip address 172.16.255.2 255.255.255.255
TARS_2(config)#interface FastEthernet0/0
TARS_2(config-if)#description To Linkmeup
TARS_2(config-if)#ip address 100.0.1.2 255.255.255.252
TARS_2(config-if)#ip nat outside
TARS_2(config)#interface FastEthernet0/1
TARS_2(config-if)#description To LAN
TARS_2(config-if)#ip address 172.16.1.1 255.255.255.0
TARS_2(config-if)#ip nat inside
TARS_2(config)#router bgp 64502
TARS_2(config-router)#network 172.16.1.0 mask 255.255.255.0
TARS_2(config-router)#network 172.16.255.2 mask 255.255.255.255
TARS_2(config-router)#neighbor 100.0.1.1 remote-as 64500
TARS_2(config)#ip nat inside source list 100 interface FastEthernet0/0 overload
TARS_2(config)#access-list 100 deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
TARS_2(config)#access-list 100 permit ip 172.16.0.0 0.0.255.255 any
access-list 100 состоит из двух строк — первая запрещает трансляцию адресов для пакетов, которые идут из своей сети в свою же сеть, находящуюся на другом конце провайдера.
Вторая строка разрешает трансляцию только для адресов своей сети. Если вдруг вы пропишите permit ip any any, то сразу же упадёт BGP-сессия с Linkmeup_R3.
Подробности по настройке NAT были освещены в пятой части СДСМ.
Конфигурация Интернета:
Internet(config)#interface Loopback0
Internet(config-if)#ip address 101.0.0.101 255.255.255.255
Internet(config)#interface FastEthernet0/0
Internet(config-if)#description To linkmeup
Internet(config-if)#ip address 101.0.0.1 255.255.255.252
Internet(config)#router bgp 64501
Internet(config-router)#network 101.0.0.0 mask 255.255.240.0
Internet(config-router)#neighbor 101.0.0.2 remote-as 64500
Internet(config)#ip route 101.0.0.0 255.255.240.0 Null0
Настройки BGP на Internet точно такие же, как были в Балаган-Телекоме в восьмом выпуске, мы только позволили себе некоторые вольности с IP-адресами.
Интерфейс Loopback 0 на узле с именем Internet олицетворяет собой весь интернет. Пинг до него и будем проверять.
Соответствующим образом настроен и Linkmeup_R1 для связи с Internet:
Internet(config)#interface FastEthernet1/1
Internet(config-if)#description To Balagan-Telecom
Internet(config-if)#ip address 101.0.0.2 255.255.255.252
Internet(config)#router bgp 64500
Internet(config-router)#network 100.0.0.0 mask 255.255.254.0
Internet(config-router)#network 101.0.0.0 mask 255.255.255.252
Internet(config-router)#neighbor 101.0.0.1 remote-as 64501
Internet(config)#ip route 100.0.0.0 255.255.254.0 Null0
Что же касается доступа в Интернет из VPN, то в данном случае конфигурацию нужно менять только на ближайшем к CE PE — в нашем случае Linkmeup_R3.
1. Создадим маршрут по умолчанию для VRF TARS. Это для того, чтобы пакеты, пришедшие от TARS_2 не были отброшены и знали куда двигаться.
Linkmeup_R3(config)#ip route vrf TARS 0.0.0.0 0.0.0.0 101.0.0.2 global
Обратить внимание здесь нужно на две вещи:
Ключевое слово global. Оно говорит о том, что Next Hop (101.0.0.2) нужно искать в глобальной таблице маршрутизации.
В качестве адрес Next-Hop выбран линковый адрес Linkmeup_R1 в сторону Интернета. Почему не Loopback, как мы любим? Это позволяет избежать так называемого blackholing’a. Дело в том, что loopback всегда доступен, а в случае падения канала между нашим шлюзом (Linkmeup_R1) и Интернетом TARS_2 этого никак не заметит и продолжит слать трафик на Linkmeup_R3, а тот, тоже ничего не подозревая, на Linkmeup_R1. Если же мы укажем линковый адрес, то он пропадёт из таблиц маршрутизации сразу, как упадёт линия.
В результате предыдущей операции на Linkmeup_3 появляется маршрут по умолчанию:
![](https://habrastorage.org/getpro/habr/post_images/289/57d/6f1/28957d6f197ffc16cc71f86ccad647f6.png)
2. Теперь его нужно сообщить клиенту, чтобы у того тоже появился маршрут по умолчанию (хотя он мог бы настроить его и самостоятельно).
address-family ipv4 vrf TARS
neighbor 100.0.1.2 default-originate
Результат:
![](https://habrastorage.org/getpro/habr/post_images/7ab/9ec/077/7ab9ec077bf119c304671272fa0453ac.png)
Итак, маршруты туда, то есть в Интернет, у нас уже есть, теперь что касается обратно.
3. На Linkmeup_R3 настроим статический маршрут для сети 100.0.1.0/30:
ip route 100.0.1.0 255.255.255.252 FastEthernet1/0
Зачем нам это нужно? Чтобы был маршрут, логично ведь. Если из Интернета пакет прилетит на Linkmeup_R3, а на нём не будет маршрута к 100.0.1.0/30 в глобальной таблице маршрутизации (в VRF-то он, конечно, будет), пакет будет отброшен.
Было:
![](https://habrastorage.org/getpro/habr/post_images/809/eef/7cf/809eef7cf03309a9ade69c0dbe2ca06e.png)
Маршрут-то есть, да только не туда. Пакет не будет отброшен, но и до адресата не дойдёт.
Стало:
![](https://habrastorage.org/getpro/habr/post_images/9a6/178/fe9/9a6178fe9d65c6726bc0a7975d0249e9.png)
4. Далее об этой сети нужно сообщить BGP-соседям — о ней должны узнать все. В частности нас интересует Linkmeup_R1.
router bgp 64500
network 100.0.1.0 mask 255.255.255.252
Результат:
![](https://habrastorage.org/getpro/habr/post_images/a11/860/0fb/a118600fb2d18a197154aaf44be82f8e.png)
BGP в принципе и прежде знал об этой сети, но только в address-family ipv4 vrf TARS, куда она попадала с помощью команды redistribute connected. В глобальной же таблице маршрутизации её не было.
Итак, всё готово, проверяем:
![](https://habrastorage.org/getpro/habr/post_images/92a/a74/aa9/92aa74aa92121f6159abb3cafc3a0730.png)
Это говорит о том, что заработал Route Leaking, то есть доступ из VRF в глобальную таблицу маршрутизации и наоборот работает.
Проверка доступности Интернета с компьютера — это формальность, которая покажет, что мы правильно настроили NAT. Фактически вся магия происходит на Linkmeup_R3, а знакомая нам трансляция на TARS_2, то есть вещи это по большому счёту не связанные, и, если Интернет доступен с TARS_2, он будет доступен и с PC1.
Однако мы проверим:
![](https://habrastorage.org/getpro/habr/post_images/555/138/da8/555138da8d5a816ab464526911a2ceac.png)
Интернет доступен. Ура!
Если вам интересно, давайте проследим, что происходит с пакетом по пути от PC1 до Internet.
1) Обычным образом пакет попадает на шлюз по умолчанию — TARS_2
2) TARS_2 видит, что адрес назначения подпадает только под маршрут по умолчанию, передаёт пакет в интерфейс FE0/0 на Linkmeup_R3.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/215/82f/36f/21582f36f452ae7c8eb921d5b026f6eb.png)
В последний момент он замечает, что заголовок пакета полностью удовлетворяет списку доступа (access-list 100) и транслирует локальный адрес 172.16.1.2 в 100.0.1.2
3) Пакет приходит в VRF TARS на Linkmeup_R3, где снова подпадает под маршрут по умолчанию, который указывает на адрес 101.0.0.2 из глобальной таблицы маршрутизации. Уже из глобальной ТМ Linkmeup_R3 знает, что 101.0.0.2 доступен через 1.1.1.1 и рекурсивно через 10.0.23.2. Причём пакету выдаётся метка 16. То есть после Linkmeup_R3 пакет уже пойдёт по MPLS LSP.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/fd1/2e6/133/fd12e6133bedf0fd094acdb0e06663b5.png)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/7b6/4db/5be/7b64db5be499ee81a3c9b3d0f72d8f8c.png)
Пакет между Linkmeup_R3 и Provier_R2
Заметьте, что метки VPN здесь нет — пакет перекочевал из VPN в публичную сеть.
4) На Linkmeup_R2 с пакета снимается транспортная метка MPLS (происходит PHP) и на Linkmeup_R1 уже передаётся чистый IP-пакет.
5) Этот чистый IP-пакет уходит с Linkmeup_R1 в Internet (BGP сообщил маршрут до сети 101.0.0.0/20)
6) Internet знает маршрут до 100.0.0.0/23 так же по BGP и передаёт пакет обратно.
7) Linkmeup_R1 знает, что адресат находится за 3.3.3.3 — помните, мы объявляли эту сеть в BGP?
Соответственно, по MPLS он доходит до Linkmeup_R3.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/2f9/4b2/d31/2f94b2d31dca5e8904bcb8876c4fafef.png)
8) Сеть 100.0.1.0/30 находится в VRF TARS, но мы ведь прописывали её статически в интерфейс FE1/0. Так что пакет передаётся благополучно на интерфейс.
9) Ну а дальше обратная трансляция на TARS_2 и последняя миля до родного дома.
2) TARS_2 видит, что адрес назначения подпадает только под маршрут по умолчанию, передаёт пакет в интерфейс FE0/0 на Linkmeup_R3.
![](https://habrastorage.org/getpro/habr/post_images/215/82f/36f/21582f36f452ae7c8eb921d5b026f6eb.png)
В последний момент он замечает, что заголовок пакета полностью удовлетворяет списку доступа (access-list 100) и транслирует локальный адрес 172.16.1.2 в 100.0.1.2
3) Пакет приходит в VRF TARS на Linkmeup_R3, где снова подпадает под маршрут по умолчанию, который указывает на адрес 101.0.0.2 из глобальной таблицы маршрутизации. Уже из глобальной ТМ Linkmeup_R3 знает, что 101.0.0.2 доступен через 1.1.1.1 и рекурсивно через 10.0.23.2. Причём пакету выдаётся метка 16. То есть после Linkmeup_R3 пакет уже пойдёт по MPLS LSP.
![](https://habrastorage.org/getpro/habr/post_images/fd1/2e6/133/fd12e6133bedf0fd094acdb0e06663b5.png)
![](https://habrastorage.org/getpro/habr/post_images/7b6/4db/5be/7b64db5be499ee81a3c9b3d0f72d8f8c.png)
Пакет между Linkmeup_R3 и Provier_R2
Заметьте, что метки VPN здесь нет — пакет перекочевал из VPN в публичную сеть.
4) На Linkmeup_R2 с пакета снимается транспортная метка MPLS (происходит PHP) и на Linkmeup_R1 уже передаётся чистый IP-пакет.
5) Этот чистый IP-пакет уходит с Linkmeup_R1 в Internet (BGP сообщил маршрут до сети 101.0.0.0/20)
6) Internet знает маршрут до 100.0.0.0/23 так же по BGP и передаёт пакет обратно.
7) Linkmeup_R1 знает, что адресат находится за 3.3.3.3 — помните, мы объявляли эту сеть в BGP?
Соответственно, по MPLS он доходит до Linkmeup_R3.
![](https://habrastorage.org/getpro/habr/post_images/2f9/4b2/d31/2f94b2d31dca5e8904bcb8876c4fafef.png)
8) Сеть 100.0.1.0/30 находится в VRF TARS, но мы ведь прописывали её статически в интерфейс FE1/0. Так что пакет передаётся благополучно на интерфейс.
9) Ну а дальше обратная трансляция на TARS_2 и последняя миля до родного дома.
Повторим шаги настройки:
- Настроить NAT. На CE.
- Настроить маршрут по умолчанию в сторону интернета для VRF с указанием Next Hop и ключевым словом Global. На PE.
- Заставить PE анонсировать данный маршрут по умолчанию клиенту. На PE.
- Настроить маршрут в глобальной ТМ в сторону клиента с указанием выходного интерфейса. На PE.
- Сообщить этот маршрут MBGP-соседям, а точнее тому узлу, который смотрит в Интернет. На CE.
Полная конфигурация интересных нам узлов.
Описанная конфигурация и есть Route Leaking.
Тут мы опустим сценарий с NAT на крайнем PE, потому что он неинтересный.
VRF-Aware NAT
Более правильный и чуть более масштабируемый вариант — настройка трансляции на Egress PE — на выходе в Интернет. В этом случае у нас есть центральный узел, где выполняются все операции, а клиенту не нужно делать ничего.
![](https://habrastorage.org/getpro/habr/post_images/eb6/6e3/86c/eb66e386c1a85bda7fc9b0ce05aded85.png)
Единственное неудобство: несмотря на то, что, возможно, ни один клиент не подключен к Egress PE непосредственно, этому маршрутизатору придётся поддерживать все VRF, из которых нужно получать доступ в Интернет. Собственно, поэтому он и VRF-Aware.
Egress PE в нашем случае — Linkmeup_R1, который является шлюзом в интернет для всей сети linkmeup — никаких абсолютно дополнительных настроек на других узлах.
Пусть PC2 из сети C3PO Electronic (C3PO_2) хочет получить доступ в Интернет.
PC1 из TARS’ Robotics не трогаем и оставляем без изменений — они со своими белыми адресами — отдельная история, хотя их тоже вполне можно натить таким же образом.
1) Итак, во-первых на Linkmeup_R1 должен быть VRF C3PO. Он уже есть, но если бы не было, нужно было бы, чтобы было бы.
Конфигурация VRF типичная и она не поменялась:
Linkmeup_R1(config)#ip vrf C3PO
Linkmeup_R1(config-vrf)#rd 64500:100
Linkmeup_R1(config-vrf)#route-target export 64500:100
Linkmeup_R1(config-vrf)#route-target import 64500:100
2) Настраиваем NAT
Включаем ip nat inside в ту сторону, откуда получаем пакеты для трансляции, то есть в сторону P-маршрутизатора Linkmeup_R2:
Linkmeup_R1(config)#interface FastEthernet 0/1
Linkmeup_R1(config-if)#ip nat inside
В сторону Интернета включаем ip nat outside:
Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip nat outside
Создаём ACL, где разрешаем доступ из сети C3PO в интернет:
Linkmeup_R1(config)#access-list 100 permit ip 192.168.0.0 0.0.255.255 any
И собственно сам NAT:
Linkmeup_R1(config)#$ip nat inside source list 100 interface FastEthernet 1/1 overload
3) В BGP, как и в прошлый раз, прописываем отправку маршрута по умолчанию в данный VRF:
Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router)#address-family ipv4 vrf C3PO
Linkmeup_R1(config-router-af)#redistribute static
Linkmeup_R1(config-router-af)#default-information originate
Поосторожней с редистрибьюцией в продакшне. Используй только вместе с фильтрацией.
Заметьте, что здесь недостаточно одной только команды redistribute static, чтобы забрать и анонсировать маршрут по умолчанию. Для этого дополнительно придётся выполнить явно команду default-information originate.
Чтобы этот маршрут анонсировался BGP, нужно, чтобы он был в таблице маршрутизации:
Linkmeup_R1(config)#ip route vrf C3PO 0.0.0.0 0.0.0.0 101.0.0.1 global
Сейчас сразу не заработает, потому что я слегка слукавил, говоря, что никакие настройки нигде кроме интернет-шлюза не понадобятся.
Дело в том, что мы сгенерировали маршрут по умолчанию для VRF C3PO на Linkmeup_R1 и по BGP передали его на Linkmeup_R3, но тут он и застрял, не дойдя до C3PO_2 — нужно заставить OSPF анонсировать маршрут по умолчанию. Как и в предыдущий раз без явной команды default-information originate он этого делать не будет:
Linkmeup_R3(config)#router ospf 2 vrf C3PO
Linkmeup_R3(config-router)# default-information originate
Проверяем:
![](https://habrastorage.org/getpro/habr/post_images/03c/084/3f3/03c0843f30c324e7c70fb10ff0dd1030.png)
Было бы странно, если бы не заработало.
Что происходит с пакетом?
1) От PC2 до Linkmeup_R3 он доходит без видимых изменений (только заголовок MAC меняется). На PC2 маршрут по умолчанию настроен вручную. На C3PO_2 он изучен по OSPF от Linkmeup_R3.
2) На интерфейсе FE0/1 пакет входит в VRF C3PO и приобретает сервисную метку.
3) Маршрут по умолчанию в VRF импортирован из BGP и он ведёт к 1.1.1.1 через 10.0.23.2:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/8fb/e22/a37/8fbe22a3714af09991b0021a215149eb.png)
4) От Linkmeup_R3 до Linkmeup_R2 пакет идёт по MPLS с двумя метками: внутренней сервисной — 27 и внешней транспортной — 18. Это видно из скриншота выше.
5) На Linkmeup_R1 происходит Route leaking из VRF C3PO в глобальную таблицу — так пакет покидает VRF.
Также здесь происходит трансляция. Linkmeup_R1 записывает информацию об этом факте в свою таблицу трансляций для VRF C3PO:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/f4f/ebc/4e9/f4febc4e9639a217e1d1c5f4cc308db7.png)
6) В Интернет пакет уходит уже, конечно, без меток MPLS и с публичным адресом отправителя — 101.0.0.2 в заголовке
7) Ответный пакет на Linkmeup_R1 попадает по глобальной таблице маршрутизации — Интернету известен адрес 101.0.0.2. На этом узле происходит обратная трансляция. Адрес назначения меняется на 192.168.2.2 и искать его нужно уже в VRF C3PO — так сказала таблица NAT.
8) А дальше процесс вам уже известен — две метки, долгий путь до Linkmeup_R3 и далее до PC2.
2) На интерфейсе FE0/1 пакет входит в VRF C3PO и приобретает сервисную метку.
3) Маршрут по умолчанию в VRF импортирован из BGP и он ведёт к 1.1.1.1 через 10.0.23.2:
![](https://habrastorage.org/getpro/habr/post_images/8fb/e22/a37/8fbe22a3714af09991b0021a215149eb.png)
4) От Linkmeup_R3 до Linkmeup_R2 пакет идёт по MPLS с двумя метками: внутренней сервисной — 27 и внешней транспортной — 18. Это видно из скриншота выше.
Не забывайте делать поправку на PHP — от Penultimate Router (Linkmeup_R2) — к Egress PE (Linkmeup_R1) — пакет пойдёт с одной сервисной меткой, потому что транспортная была снята в результате PHP.
5) На Linkmeup_R1 происходит Route leaking из VRF C3PO в глобальную таблицу — так пакет покидает VRF.
Также здесь происходит трансляция. Linkmeup_R1 записывает информацию об этом факте в свою таблицу трансляций для VRF C3PO:
![](https://habrastorage.org/getpro/habr/post_images/f4f/ebc/4e9/f4febc4e9639a217e1d1c5f4cc308db7.png)
6) В Интернет пакет уходит уже, конечно, без меток MPLS и с публичным адресом отправителя — 101.0.0.2 в заголовке
7) Ответный пакет на Linkmeup_R1 попадает по глобальной таблице маршрутизации — Интернету известен адрес 101.0.0.2. На этом узле происходит обратная трансляция. Адрес назначения меняется на 192.168.2.2 и искать его нужно уже в VRF C3PO — так сказала таблица NAT.
8) А дальше процесс вам уже известен — две метки, долгий путь до Linkmeup_R3 и далее до PC2.
Полная конфигурация узлов для VRF Aware NAT.
Это был тот же Route Leaking.
Common Services
До сих пор мы обсуждали задачу передачи трафика из VPN в публичные сети и обратно.
Ещё один подход к предоставлению доступа в Интернет — вывести его в отдельный VRF.
Строго говоря — он наиболее масштабируемый, потому что нет необходимости настраивать что-то индивидуально для каждого клиентского VRF.
Важное условие — NAT происходит в сети клиента и в VRF Internet импортируются только маршруты к публичным префиксам клиента.
Common Services, который часто называют Shared Services — это продолжение вопроса о взаимодействии между VRF, который мы рассмотрели ранее. Основная идея в том, что экспорт/импорт совершается засчёт особой настройки route-target. Только на этот раз нужно ограничить список передаваемых префиксов, чтобы избежать пересечения адресных пространств и разрешить только публичные маршруты.
Рассмотрим задачу снова на примере TARS, потому что у них уже есть публичные сети.
На шлюзе мы создаём VRF Internet.
Linkmeup_R1(config)#ip vrf Internet
Linkmeup_R1(config-vrf)#rd 64500:1
Linkmeup_R1(config-vrf)#route-target import 64500:11
Linkmeup_R1(config-vrf)#route-target export 64500:22
Обратите внимание, что route-target на импорт и на экспорт в этот раз разные и сейчас станет понятно почему.
2) Перенести интерфейс в сторону Интернета в VRF:
Linkmeup_R1(config)#interface FastEthernet 1/1
Linkmeup_R1(config-if)#ip vrf forwarding Internet
Linkmeup_R1(config-if)#ip address 101.0.0.2 255.255.255.252
3) Перенести BGP-соседство с маршрутизатором в Интернете в address-family ipv4 vrf Internet:
Linkmeup_R1(config-router)#router bgp 64500
Linkmeup_R1(config-router)#no neighbor 101.0.0.1 remote-as 64501
Linkmeup_R1(config-router)#address-family ipv4 vrf Internet
Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 remote-as 64501
Linkmeup_R1(config-router-af)#neighbor 101.0.0.1 activate
4) Объявляем маршрут по умолчанию:
Linkmeup_R1(config)#router bgp 64500
Linkmeup_R1(config-router-af)#network 0.0.0.0 mask 00.0.0.0
Linkmeup_R1(config-router-af)#default-information originate
Linkmeup_R1(config)#ip route vrf Internet 0.0.0.0 0.0.0.0 101.0.0.1
5) В клиентском VRF TARS нужно также настроить RT:
Linkmeup_R1(config-vrf)#ip vrf TARS
Linkmeup_R(config-vrf)# route-target both 64500:200
Linkmeup_R1(config-vrf)# route-target export 64500:11
Linkmeup_R1(config-vrf)# route-target import 64500:22
Итак, помимо собственного RT, который обеспечивает обмен маршрутной информацией с другими филиалами (64500:200), здесь настроены и те RT, которые и для VRF Internet, но наоборот:
- то, что было на экспорт в VRF Internet (64500:22), то стало на импорт в VRF TARS
- то, что было на импорт в VRF Internet (64500:11), то стало на экспорт в VRF TARS
Почему так? Почему нельзя просто дать route-target both 64500:1, например, на всех VRF?
Основная идея концепции Common Service — предоставить доступ к нужному VRF клиентам, но не позволить им общаться друг с другом напрямую, чтобы обеспечить изоляцию, как того требует определение VPN.
Если настроить одинаковый RT на всех VRF, то маршруты будут спокойно ходить между ними.
При указанной же выше конфигурации у всех клиентских VRF есть RT 64500:22 на импорт (все будут получать маршруты Internet), и также у них есть RT 64500:11 на экспорт, но только у VRF Internet есть такой RT 64500:11 на импорт — только VRF Internet будет получать маршруты клиентов. Друг с другом они обмениваться не смогут. Главное, чтобы Internet не занялся филантропией и не начал маршрутизировать клиентский трафик.
![](https://habrastorage.org/getpro/habr/post_images/c61/9ad/97f/c619ad97f0ec6636e8bc1c3c75ec80cf.png)
Итак, в результате наших операций мы можем видеть следующее:
![](https://habrastorage.org/getpro/habr/post_images/487/7c2/a4f/4877c2a4f1cced935eca18389ffc88fe.png)
На TARS_2 всё в порядке.
На Linkmeup_R1 есть маршрут до сети 100.0.0.0/30, но есть и лишние маршруты до частных сетей:
![](https://habrastorage.org/getpro/habr/post_images/a10/430/415/a10430415d1e67b81e0f645ab773398c.png)
И в этом случае у нас даже будет интимная связность:
![](https://habrastorage.org/getpro/habr/post_images/50a/b2a/576/50ab2a576330e527931e4042dd45515a.png)
Но что делать с этими лишними маршрутами в VRF Internet? Ведь если мы подключим ещё один VRF так же, у нас и от него появятся ненужные серые подсети.
Тут как обычно поможет фильтрация. А если конкретно, то воспользуемся prefix-list + route-map:
Linkmeup_R1(config)#ip prefix-list 1 deny 172.16.0.0/12 le 32
Linkmeup_R1(config)#ip prefix-list 1 deny 192.168.0.0/16 le 32
Linkmeup_R1(config)#ip prefix-list 1 deny 10.0.0.0/8 le 32
Linkmeup_R1(config)#ip prefix-list 1 permit 0.0.0.0/0 le 32
Первые три строки запрещают анонсы всех частных сетей. Четвёртая разрешает все остальные.
В нашем случае вполне можно было бы обойтись одной строкой: ip prefix-list 1 permit 100.0.0.0/23 le 32 — вся подсеть Linkmeup, но приведённый нами пример более универсальный — он допускает существование других публичных сетей и соответственно один prefix-list может быть применён для всех VRF.
Следующая конструкция применяет расширенное community к тем префиксам, что попали в prefix-list 1, иными словами устанавливает RT:
Linkmeup_R1(config-map)#route-map To_Internet permit 10
Linkmeup_R1(config-map)#match ip address prefix-list 1
Linkmeup_R1(config-map)#set extcommunity rt 64500:11
Осталось дело за малым — применить route-map к VRF:
Linkmeup_R1(config)#ip vrf TARS
Linkmeup_R1(config-vrf)#export map To_Internet
После обновления маршрутов BGP (можно форсировать командой clear ip bgp all 64500) видим, что в VRF Internet остался только публичный маршрут:
![](https://habrastorage.org/getpro/habr/post_images/961/de1/431/961de143107c0d8a46ada0194df08b27.png)
И, собственно, проверка доступности Интернета с PC1 (NAT уже настроен на TARS_2):
![](https://habrastorage.org/getpro/habr/post_images/f69/34a/194/f6934a1944842188f3b3b6511f6580df.png)
Уважаемые читатели, вы только что ознакомились с другим подходом к Route Leaking'у.
Полная конфигурация всех узлов для Common Services.
Наиболее доступно тема Common Services описана Jeremy Stretch. Но у него нет указания на то, что префиксы нужно фильтровать.
Вообще, у них там в ихних америках, все друг друга знают и уважают. Поэтому Джереми охотно ссылается на Ивана Пепельняка, а точнее его заметку о Common Services, а Иван в свою очередь на Джереми. Статьи их дополняют друг друга, но опять же до конца тему не раскрывают.
А вот и третья ссылка, которая в купе с первыми двумя позволяет сложить какое-то представление о том, как работает Common Services.
Все виды доступа в Интернет из VRF описаны в данной статье. Но она настолько запутанная, что именно поэтому я и решил посвятить отдельный микровыпуск СДСМ вопросу настройки этого функционала.
В целом же про MPLS и его приложения, в том числе L3VPN, можно глубоко почитать у Ina Minei, Julian Lucek. MPLS-Enabled Applications.
Из списка лучших книг для связиста.
В этом году ждите СДСМ12. MPLS L2VPN.