Глава 10. L3VPN Internet Access и масштабирование

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 интерфейс. То, есть, через отдельный влан. Как-то так.