Глава 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
© Наталия Бобкова 2014—2022