Глава 8. Конфигурация L3VPN

Ниже приведен пример настройки самого стандартного L3VPN на двух PE [PE100-router и PE2-router]. На PE-CE с клиентом используется BGP.

Configuration L3VPN

PE100-router:

На магистральных интерфейсах должна быть включена family mpls

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 t:500:101;

vrf-import, vrf-export можно заменить на vrf-target, если 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:

На магистральных интерфейсах должна быть включена family mpls

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 t: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;

Autonomus system loops

CE в одной AS, у CE-PE роутеров связность по EBGP, у PE-PE роутеров связность по IBGP,

При анонсировании префикса от CE -> PE в AS path записывается AS CE1 и в конечном итоге, префикс с таким AS path анонсируется CE2.

CE при получении такого пакета распознает петлю на сети и дропнет его.

Чтобы этого не произошло:

• as-override на egress PE (в protocol bgp в vrf) при этом в таблице маршрутизации CE2 у префикса в AS-path будет 2 ASN провайдера.
• autonomous-system loops n - позволяет вставлять маршрут в табл маршр-ии с n числом AS. При включенном advertise-peer-as [vrf protocol bgp] на PE, у CE добавляем в конфиг. [routing-options]. При этом 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).

OSPF routing

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, accept

vrf-export - match ospf, add community, accept

PE router: protocol ospf export bgp > ospf

LSA типы

External LSA (type 5): когда прилетают маршруты, изученные не из OSPF (local, direct, bgp, rip...)

Summary LSA (type 3): когда прилетают маршруты, изученные из OSPF

Domain ID

Комьюнити, позволяющее распространять маршруты, полученные от MP-BGP соседей, CE маршрутизаторам в виде LSA.

Для определения domain ID используется один из неназначенных битов в LSA.

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