Глава 8. Конфигурация L3VPN: различия между версиями
м |
|||
(не показано 10 промежуточных версий этого же участника) | |||
Строка 1: | Строка 1: | ||
{{#description2:Конфигурация L3VPN. Как избежать петлей AS в L3VPN. L3VPN с OSPF. OSPF sham link в L3VPN. VRF import, export policy. Информация для подготовки к экзаменам Juniper.}} | |||
{{JNCIS_content}} | |||
PE100-router | Ниже приведен пример настройки самого стандартного L3VPN на двух PE [PE100-router и PE2-router]. На PE-CE с клиентом используется BGP. | ||
==Конфигурация L3VPN== | |||
{{note|text=На магистральных интерфейсах должна быть включена family mpls}} | |||
PE100-router: | |||
protocols { | protocols { | ||
rsvp { interface all; | rsvp { interface all; | ||
Строка 9: | Строка 14: | ||
label-switched-path to_H2 { | label-switched-path to_H2 { | ||
to 2.2.2.2; | to 2.2.2.2; | ||
interface all; | interface all; | ||
bgp { | bgp { | ||
group int { | group int { | ||
Строка 18: | Строка 21: | ||
family inet { | family inet { | ||
unicast; | unicast; | ||
family inet-vpn { | family inet-vpn { | ||
unicast; | unicast; | ||
policy-options { | policy-options { | ||
Строка 30: | Строка 31: | ||
community add vpna; | community add vpna; | ||
accept; | accept; | ||
term 2 { | term 2 { | ||
then reject; | then reject; | ||
policy-statement imp_vpna { | policy-statement imp_vpna { | ||
term 1 { | term 1 { | ||
Строка 41: | Строка 39: | ||
protocol bgp; | protocol bgp; | ||
community vpna; | community vpna; | ||
then accept; | then accept; | ||
term 2 { | term 2 { | ||
then reject; | then reject; | ||
community vpna members target:500:101; | |||
community vpna members | |||
{{note|text=vrf-import, vrf-export можно заменить на vrf-target target:500:101, если PE между собой обмениваются маршрутами в режиме full-mesh без ограничений.}} | |||
routing-instances { | routing-instances { | ||
Строка 64: | Строка 61: | ||
neighbor 10.7.9.10 { | neighbor 10.7.9.10 { | ||
peer-as 100; | peer-as 100; | ||
PE2-router | PE2-router: | ||
protocols { | protocols { | ||
rsvp { | rsvp { | ||
Строка 75: | Строка 70: | ||
label-switched-path to_H0 { | label-switched-path to_H0 { | ||
to 100.100.100.100; | to 100.100.100.100; | ||
interface all; | interface all; | ||
bgp { | bgp { | ||
Строка 83: | Строка 77: | ||
family inet { | family inet { | ||
unicast; | unicast; | ||
family inet-vpn { | family inet-vpn { | ||
unicast; | unicast; | ||
policy-options { | policy-options { | ||
policy-statement exp_vpna { | policy-statement exp_vpna { | ||
Строка 94: | Строка 87: | ||
community add vpna; | community add vpna; | ||
accept; | accept; | ||
term 2 { | term 2 { | ||
then reject; | then reject; | ||
policy-statement imp_vpna { | policy-statement imp_vpna { | ||
term 1 { | term 1 { | ||
Строка 105: | Строка 94: | ||
protocol bgp; | protocol bgp; | ||
community vpna; | community vpna; | ||
then accept; | then accept; | ||
term 2 { | term 2 { | ||
then reject; | then reject; | ||
community vpna members target:500:101; | |||
community vpna members | |||
routing-instances { | routing-instances { | ||
Строка 128: | Строка 114: | ||
neighbor 10.7.6.20 { | neighbor 10.7.6.20 { | ||
peer-as 100; | peer-as 100; | ||
==Как избежать петлей AS в L3VPN== | |||
CE1, CE2 в одной AS, у CE-PE роутеров связность по EBGP, у PE-PE роутеров связность по IBGP, | |||
При анонсировании префикса от CE1 -> PE в AS path записывается AS CE1 и в конечном итоге, префикс с таким AS path анонсируется CE2. | |||
CE2 при получении такого пакета распознает петлю на сети и дропнет его. | |||
CE | Чтобы этого не произошло можно воспользоваться: | ||
* '''as-override''' на egress PE (в protocol bgp в vrf) при этом в таблице маршрутизации CE2 у префикса в AS-path будет 2 ASN провайдера. | |||
* '''autonomous-system loops n''' - позволяет принимать маршрут с n числом AS CE. | |||
Дополнительно требуется включить advertise-peer-as [vrf protocol bgp] на PE. У CE в routing-options прописываем autonomous-system loops n | |||
При этом remote CE будет анонсировать полученный префикс с AS path с бОльшим числом AS, что не есть хорошо. | |||
* '''remove-private''' включается на ingress PE. | |||
* '''remove-private''' на ingress PE. | |||
* '''independent-domain''' - настройка на ingress PE в vrf routing-options + iBGP в AS CE в vrf. Добавляется ATTRSET attribute, в нем хранятся CE атрибуты. К remote CE маршрут придет без добавления провайдерской AS. | * '''independent-domain''' - настройка на ingress PE в vrf routing-options + iBGP в AS CE в vrf. Добавляется ATTRSET attribute, в нем хранятся CE атрибуты. К remote CE маршрут придет без добавления провайдерской AS. | ||
В случае, когда VPN клиента состоит из 2х локаций, в одной из которых находится 2 хоста, использование as-override повлечет за собой то, что маршруты, переданные внутри одной локации от одного хоста к другому будут отброшены из-за стандартных настроек input и output policy или настроенного SoO (site of origin). | В случае, когда VPN клиента состоит из 2х локаций, в одной из которых находится 2 хоста, использование as-override повлечет за собой то, что маршруты, переданные внутри одной локации от одного хоста к другому будут отброшены из-за стандартных настроек input и output policy или настроенного SoO (site of origin). | ||
== OSPF | ==L3VPN с OSPF== | ||
Когда взаимодействие PE - CE строится с помощью OSPF. | |||
=== OSPF sham link === | ===OSPF sham link=== | ||
Может использоваться только когда передаются ospf-маршруты между CE в одном OSPF домене (одинаковая area-id). | Может использоваться только когда передаются ospf-маршруты между CE в одном OSPF домене (одинаковая area-id). | ||
Строка 160: | Строка 146: | ||
PE1 | PE1 | ||
routing-instances { | routing-instances { | ||
vpn-a { | vpn-a { | ||
Строка 182: | Строка 167: | ||
'''address 11.11.11.11/32'''; | '''address 11.11.11.11/32'''; | ||
На PE2 | На PE2 симметрично наоборот. | ||
На CE роутерах обычный OSPF. | На CE роутерах обычный OSPF. | ||
Строка 192: | Строка 177: | ||
=== VRF import, export policy === | === VRF import, export policy === | ||
Строятся по принципу: | |||
*vrf-import - match bgp, match community vpn, then accept | |||
*vrf-export - match ospf, add community, then accept | |||
Принятые BGP маршруты с удалённой стороны требуется передать в OSPF клиенту: | |||
PE router: protocol ospf export bgp-routes | |||
PE router: protocol ospf export bgp | |||
=== Backbone legacy === | === Backbone legacy === | ||
В случае, если у клиента есть 2 канала между своими СЕ, одним из которых является наш L3VPN: | |||
В случае, | |||
:- local PE будет получать маршрут от remote CE через local CE (должен получать от remote PE). | :- local PE будет получать маршрут от remote CE через local CE (должен получать от remote PE). | ||
:- По preference маршрут изученный по OSPF будет приоритетней BGP, поэтому активным маршрутом на local PE до remote CE станет как раз тот изученный по ospf. | :- По preference маршрут изученный по OSPF будет приоритетней BGP, поэтому активным маршрутом на local PE до remote CE станет как раз тот изученный по ospf. | ||
:- local PE также не будет распространять маршрут local CE, так как в таблице маршрутизации маршрут не активный. | :- local PE также не будет распространять маршрут local CE, так как в таблице маршрутизации маршрут не активный. | ||
В кач-ве решения juniper предлагает изменить ospf preference внутри routing-instance: | В кач-ве решения juniper предлагает изменить ospf preference внутри routing-instance: | ||
set routing-instance vpna protocols ospf preference 180 | |||
=Дополнительная информация= | |||
*[[L3VPN]] | |||
*[[Traffic engineering]] |
Текущая версия на 17:53, 15 июля 2021
JNCIS content Статья покрывает только курс JNCIS. Возможно, тема представлена детальнее в других разделах. А для JNCIS и этого достаточно. ¯\_(ツ)_/¯ |
Ниже приведен пример настройки самого стандартного L3VPN на двух PE [PE100-router и PE2-router]. На PE-CE с клиентом используется BGP.
Конфигурация L3VPN
На магистральных интерфейсах должна быть включена family mpls
PE100-router:
protocols { rsvp { interface all; mpls { no-cspf; label-switched-path to_H2 { to 2.2.2.2; interface all; bgp { group int { type internal; local-address 100.100.100.100; family inet { unicast; family inet-vpn { unicast;
policy-options { policy-statement exp_vpna { term 1 { from protocol bgp; then { community add vpna; accept; term 2 { then reject;
policy-statement imp_vpna { term 1 { from { protocol bgp; community vpna; then accept; term 2 { then reject;
community vpna members target:500:101;
vrf-import, vrf-export можно заменить на vrf-target target:500:101, если PE между собой обмениваются маршрутами в режиме full-mesh без ограничений.
routing-instances { vpn-a { instance-type vrf; interface em3.0; route-distinguisher 100.100.100.100:1; vrf-import imp_vpna; vrf-export exp_vpna; protocols { bgp { group ext { type external; peer-as 500; neighbor 10.7.9.10 { peer-as 100;
PE2-router:
protocols { rsvp { interface all; mpls { no-cspf; label-switched-path to_H0 { to 100.100.100.100; interface all; bgp { group int { type internal; local-address 2.2.2.2; family inet { unicast; family inet-vpn { unicast;
policy-options { policy-statement exp_vpna { term 1 { from protocol bgp; then { community add vpna; accept; term 2 { then reject; policy-statement imp_vpna { term 1 { from { protocol bgp; community vpna; then accept; term 2 { then reject; community vpna members target:500:101;
routing-instances { vpn-a { instance-type vrf; interface em4.0; route-distinguisher 2.2.2.2:1; vrf-import imp_vpna; vrf-export exp_vpna; protocols { bgp { group ext { type external; local-address 10.7.6.2; neighbor 10.7.6.20 { peer-as 100;
Как избежать петлей AS в L3VPN
CE1, CE2 в одной AS, у CE-PE роутеров связность по EBGP, у PE-PE роутеров связность по IBGP,
При анонсировании префикса от CE1 -> PE в AS path записывается AS CE1 и в конечном итоге, префикс с таким AS path анонсируется CE2.
CE2 при получении такого пакета распознает петлю на сети и дропнет его.
Чтобы этого не произошло можно воспользоваться:
- as-override на egress PE (в protocol bgp в vrf) при этом в таблице маршрутизации CE2 у префикса в AS-path будет 2 ASN провайдера.
- autonomous-system loops n - позволяет принимать маршрут с n числом AS CE.
Дополнительно требуется включить advertise-peer-as [vrf protocol bgp] на PE. У CE в routing-options прописываем autonomous-system loops n
При этом remote CE будет анонсировать полученный префикс с AS path с бОльшим числом AS, что не есть хорошо.
- remove-private включается на ingress PE.
- independent-domain - настройка на ingress PE в vrf routing-options + iBGP в AS CE в vrf. Добавляется ATTRSET attribute, в нем хранятся CE атрибуты. К remote CE маршрут придет без добавления провайдерской AS.
В случае, когда VPN клиента состоит из 2х локаций, в одной из которых находится 2 хоста, использование as-override повлечет за собой то, что маршруты, переданные внутри одной локации от одного хоста к другому будут отброшены из-за стандартных настроек input и output policy или настроенного SoO (site of origin).
L3VPN с OSPF
Когда взаимодействие PE - CE строится с помощью OSPF.
OSPF sham link
Может использоваться только когда передаются ospf-маршруты между CE в одном OSPF домене (одинаковая area-id).
По факту это фиктивный линк между PE роутерами в клиентском OSPF домене.
OSPF пакеты туннелируются в MPLS LSP между PE.
Создаем этот самый "туннель":
PE1
routing-instances { vpn-a { instance-type vrf; interface em3.0; interface lo0.1; route-distinguisher 100.100.100.100:1; vrf-target t:500:1; protocols { ospf { sham-link local 11.11.11.11; area 0.0.0.0 { sham-link-remote 22.22.22.22 metric 1; interface lo0.1; interface em3.0;
interfaces { lo0 { unit 1 { family inet { address 11.11.11.11/32;
На PE2 симметрично наоборот.
На CE роутерах обычный OSPF.
При этом
- PE1 - CE1, PE2 - CE2 соседи внутри vrf
- PE1 - PE2 соседи внутри vrf через sham-link
- CE1 - CE2 не соседи!!
VRF import, export policy
Строятся по принципу:
- vrf-import - match bgp, match community vpn, then accept
- vrf-export - match ospf, add community, then accept
Принятые BGP маршруты с удалённой стороны требуется передать в OSPF клиенту: PE router: protocol ospf export bgp-routes
Backbone legacy
В случае, если у клиента есть 2 канала между своими СЕ, одним из которых является наш L3VPN:
- - local PE будет получать маршрут от remote CE через local CE (должен получать от remote PE).
- - По preference маршрут изученный по OSPF будет приоритетней BGP, поэтому активным маршрутом на local PE до remote CE станет как раз тот изученный по ospf.
- - local PE также не будет распространять маршрут local CE, так как в таблице маршрутизации маршрут не активный.
В кач-ве решения juniper предлагает изменить ospf preference внутри routing-instance:
set routing-instance vpna protocols ospf preference 180