Глава 8. Конфигурация L3VPN: различия между версиями

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску
м (Наталия Бобкова переименовала страницу Глава 8. L3VPN Configuration в Глава 8. Конфигурация L3VPN)
м
 
Строка 3: Строка 3:


Ниже приведен пример настройки самого стандартного L3VPN на двух PE [PE100-router и PE2-router]. На PE-CE с клиентом используется BGP.
Ниже приведен пример настройки самого стандартного L3VPN на двух PE [PE100-router и PE2-router]. На PE-CE с клиентом используется BGP.
==Конфигурация L3VPN.==
==Конфигурация L3VPN==
 
{{note|text=На магистральных интерфейсах должна быть включена family mpls}}


PE100-router:
PE100-router:
{{note|text=На магистральных интерфейсах должна быть включена family mpls}}
  protocols {
  protocols {
     rsvp { interface all;
     rsvp { interface all;
Строка 62: Строка 63:
   
   
PE2-router:
PE2-router:
{{note|text=На магистральных интерфейсах должна быть включена family mpls}}
  protocols {
  protocols {
     rsvp {
     rsvp {
Строка 192: Строка 192:


В кач-ве решения juniper предлагает изменить ospf preference внутри routing-instance:
В кач-ве решения juniper предлагает изменить ospf preference внутри routing-instance:
<code>
set routing-instance vpna protocols ospf preference 180
set routing-instance vpna protocols ospf preference 180
 
</code>
=Дополнительная информация=
*[[L3VPN]]
*[[Traffic engineering]]

Текущая версия на 17:53, 15 июля 2021

Exclamation point.png 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

Дополнительная информация