Глава 10. L3VPN Internet Access и масштабирование: различия между версиями
м |
|||
(не показаны 2 промежуточные версии этого же участника) | |||
Строка 1: | Строка 1: | ||
{{#description2:Масштабирование L3VPN. Route Reflector. Фильтры route-target. Доступ в интернет в L3VPN. Информация для подготовки к экзаменам Juniper.}} | |||
= Route Reflector = | = Route Reflector = | ||
Строка 61: | Строка 62: | ||
У клиент один из CE имеет интернет, и шлет default route удаленным CE. Удаленные CE доступаются и до ВПН-а и до интернета через один интерфейс. | У клиент один из CE имеет интернет, и шлет default route удаленным CE. Удаленные CE доступаются и до ВПН-а и до интернета через один интерфейс. | ||
Главный CE, когда получает пакеты, назначенные в Интернет, просто шлет их туда через свой НЕ-VRF интерфейс. Ну и - да, тот CE, у которого есть интернет должен к провайдеру подключиться и через VRF и через НЕ-VRF интерфейс. То, есть, через отдельный влан. Как-то так. | Главный CE, когда получает пакеты, назначенные в Интернет, просто шлет их туда через свой НЕ-VRF интерфейс. Ну и - да, тот CE, у которого есть интернет должен к провайдеру подключиться и через VRF и через НЕ-VRF интерфейс. То, есть, через отдельный влан. Как-то так. | ||
=Дополнительная информация= | |||
*[[Глава 8. Конфигурация L3VPN]] | |||
*[[Глава 11. L3VPN Advanced topics]] | |||
*[[L3VPN]] |
Текущая версия на 17:57, 15 июля 2021
Route Reflector
Для лучшего масштабирования L3VPN сетей зачастую используют route reflector.
Каждый PE должен установить соседство только с ним, при этом нет необходимости создавать full mesh между всеми PE.
RR не участвует в передачи данных, он только передает информацию о маршрутах.
Между RR и PE должен быть установлен LSP, чтобы принятые маршруты от PE резолвились в LSP и были активными в таблице маршрутизации на RR и чтобы была возможность передавать их другим PE.
Обычно RR - P-router.
Чтобы P-router стал VPN RR на нем нужно сконфигурировать:
- cluster ID;
- соседство с другим роутерами;
- inet-vpn address family.
Без route-target filters PE получает все маршруты от RR.
С route-target filters PE отправляет "список" интересующих его target [читай vrf], RR отправляет только маршруты интересующих vrf для PE.
Internet Access
Option 1
В рамхак опции 1 PE роутеры не обмениваются маршрутами между master и vrf таблицами маршрутизации. Предоставление интернета в рамках опции 1 называется "non-VRF Internet Access".
Option 1.1
"Пусть строят как хотят". VPN-клиенты не получают интернет от провайдера VPN-услуг, а подключают в каждой локации IPS1 или ISP2 в отдельный маршрутизатор, и далее разруливают трафик как хотят. В каждой локации свой интернет.
По-умолчанию Juniper поддерживает именно эту опцию.
Option 1.2
В отдельном влане (CE-PE) идет L2 по провайдерской сети до провайдерского роутера, который раздает интернет. Можно вообще отдельным кабелем воткнуться между CE и PE. Сам PE ничего не знает про интернет и не обязан хранить маршруты в интернет, либо маршруты клиента, чтобы маршрутизировать что-либо в ту или иную сторону. В Juniper для этого предусмотрено либо L2VPN либо CCC.
Все VPN-ы, подключенные к данному PE пойдут в интернет одинаковым путем.
Option 2
Option 2.1
"Отдельный интерфейс для интернета и для VPN-трафика". В отличие от Option 1.2, здесь сам PE маршрутизирует клиента в интернет. Хотя подключается так же - через отдельный влан или даже физический интерфейс. Маршруты в интернет хранятся в VRF PE маршрутизатора. Стало быть, маршруты клиента с его белыми адресами тоже (для обратного трафика).
Option 2.2
"Отдельный интерфейс для обратного (который идет от Интернета к клиенту) трафика".
Суть в том, что в VRF содержатся маршруты в интернет (0/0, или чуть больше, или вообще FullView в худшем случае), и отдаются клиенту. Дальнейший путь клиентского трафика, который не подошел к VPN-маршрутам, лукапится из главной таблицы через операцию "next-table" (т.е. 0/0 в VRF с next-table master в качестве некст-хопа. Тогда все, что не проанонсировано удаленными сайтами пойдет по дефолту). Но все-равно нужен отдельный линк или влан между PE-CE, чтобы обратный трафик как-то попадал к клиенту. Т.е. еще раз - трафик от клиента в интернет идет через VRF, некстхоп лукапится из master (если некстхоп - не клиентский узел на удаленном сайте), а обратно трафик идет уже минуя VRF через отделный влан/линк. Как PE различает какой трафик vpn а какой - internet: в VRF создается default route в next-table master в качестве некст-хопа. И дальше уже понятно. Да?
Option 2.3
"Все через одну дырку (Single VRF FOR VPN and Internet Access)".
Отдельного интерфейса не требуется. Опять же, не-ВПН трафик клиента будет лукапиться в master-е и маршрутизироваться по тамошним маршрутам в интернет. А чтобы схема работала и в обратную сторону, все клиентские анонсы будут редистрибьюированы в master.
Option 3
У клиент один из CE имеет интернет, и шлет default route удаленным CE. Удаленные CE доступаются и до ВПН-а и до интернета через один интерфейс. Главный CE, когда получает пакеты, назначенные в Интернет, просто шлет их туда через свой НЕ-VRF интерфейс. Ну и - да, тот CE, у которого есть интернет должен к провайдеру подключиться и через VRF и через НЕ-VRF интерфейс. То, есть, через отдельный влан. Как-то так.