Технология VPLS уже давно зарекомендовала себя как способ объединения географически разнесенных объектов в единую L2-сеть. Такое решение хорошо масштабируется по сравнению с классической L2-сетью и позволяет избавиться от проблем L2-петель в ядре сети. Однако, часто возникает необходимость организации резервных каналов от абонента к VPLS-облаку. В такой ситуации есть опасность образования петель на участке PE-CE. Для решения этой проблемы существует несколько подходов. Вот некоторые из них:
В данной статье я бы хотел рассмотреть первые два подхода.
Настройка транспорта
BGP-Based VPLS Multihoming
Связка VPLS и STP
Выводы
Материалы, использованные при написании статьи
Основная цель данной статьи — представить рабочую конфигурацию достаточно комплексного решения. При написании я не ставил себе цель глубоко вдаваться в теорию и пояснять тонкости работы тех или иных протоколов, о которых пойдет речь. Подразумевается, что читатель хорошо знаком с работой MPLS, BGP и Spanning-tree протоколов.
Ниже представлена топология, которую я буду использовать в этой статье.
Сеть провайдера состоит из PE и P маршрутизаторов (Juniper MX), все они находятся в OSPF Area 0 и BGP AS 65412. Абонентская сеть — это три коммутатора (Cisco Catalyst), на каждом из которых поднят Vlan 10 и RPVST-версия Spanning-tree протокола (VSTP в терминологии Juniper).
Прежде чем начинать настройку VPLS, необходимо поднять MPLS-транспорт. Для сигнализации LSP в данном примере используется протокол RSVP. Для краткости я привожу конфигурации только двух маршрутизаторов, остальные легко настроить по аналогии.
Параметры flexible-vlan-tagging и flexible-ethernet-sevices позволяют настраивать на физическом интерфейсе не только VPLS, но и другие сервисы, используя разные логические юниты. Если интерфейс планируется использовать только под VPLS, то следует указать encapsulation ethernet-vpls или vlan-vpls. Подробнее тут.
Проверяем, что MPLS поднялся и работает:
Теперь можно перейти непосредственно к настройки сервиса VPLS.
В первую очередь я бы хотел рассмотреть «классическую», с точки зрения Juniper, реализацию VPLS с использованием BGP сигнализации (RFC 4761). С точки зрения control plane это мало чем отличается от обычного L3VPN — здесь также используются Route Distinguisher и Route Target, а в качестве address family указывается l2vpn.
Для начала нужно настроить сам протокол BGP. Так как для корректной работы iBGP необходима полная связность внутри сети, я использовал P1 и P2 в качестве route-reflector, для упрощения конфигурации.
PE-маршрутизаторы:
P1
P2
Тут стоит отметить блок routing-options. Когда route-reflector получает маршрут от своего клиента, прежде чем анонсировать его остальным клиентам, он проверяет доступность next-hop в таблице inet.3. Так как при первоначальной настройке MPLS на P-маршрутизаторах, я не стал создавать LSP до PE-маршрутизаторов, эта таблица пуста и, соответственно, проверка не срабатывает. Маршруты полученные от RR-клиентов помечаются как hidden и не анонсируются дальше. Конечно, можно создать LSP от RR до каждого PE, но это трудоемко, к тому же эти LSP никогда не будут использоваться для передачи трафика. Гораздо проще и элегантнее создать статический маршрут до lo0 сети.
На данный момент BGP связность должна работать между всеми PE-маршрутизаторами, но им пока что нечего анонсировать. Можно переходить к настройке VPLS.
PE1
PE2
Тут все достаточно просто: создаем routing-instance с типом vpls, назначаем RD и RT, указываем интерфейсы в сторону CE и уникальный site-identifier.
Проверяем:
VPLS-соединения поднялись. Можно проверить связность CE1 и CE2:
Как видно из топологии, коммутатор CE3 соединяется одновременно с двумя PE-маршрутизаторами. Здесь для избежания возникновения L2-петель необходимо задействовать механизм Multihoming. Рассмотрим настройки PE3 и PE4.
PE3
PE4
В отличие от предыдущих конфигураций PE1 и PE2 здесь добавляется два параметра:
При этом указывается одинаковый site-identifier на обоих PE. Таким образом PE3 и PE4 анонсируют один и тот же l2vpn-маршрут, отличающийся только параметром site-preference. Маршрут с наивысшим site-preference, т.е. маршрут от PE3, выигрывает и весь l2vpn трафик от PE1 и PE2 начинает идти через PE3. Интерфейс ge-0/0/0 на PE4 не пропускает трафик.
Следует обратить внимание, что на PE4 все VPLS соединения находятся в состоянии LN — local site not designated. Это говорит о том, что PE4 не участвует в передаче VPLS трафика
При падении линка PE3-CE3 или при потере связности PE3 с остальной сетью, маршрутизатор перестает анонсировать l2vpn маршрут, PE4 начинает пропускать трафик на интерфейсе ge-0/0/0, а PE1 и PE2 начинают маршрутизировать трафик в сторону PE4. Скорость переключения каналов в данном случае зависит от скорости схождения BGP.
Теперь к самому интересному. Рассмотрим топологию, в которой CE1 и CE2 соединены между собой.
При использовании BGP-Based Multihoming в такой топологии, все будет хорошо до тех пор пока не порвется линк CE1-CE2. PE-маршрутизаторы не узнают об изменении топологии и, в случае, когда, например, PE1 будет основным маршрутизатором, трафик к CE2 продолжит идти через PE1 и будет сбрасываться.
Чтобы изменения топологии в CE-сегменте передавались в VPLS-сегмент, необходимо настроить взаимодействие STP и VPLS.
Ниже немного высокоуровневой теории как это должно работать.
Рассмотрим штатную ситуацию, когда работают все линки.
Предположим, что линк CE1-CE2 порвался.
В домене STP:
В домене VPLS:
При восстановлении линка CE1-CE2 снова отправляется TCN и сценарий повторяется, с тем различием, что линк PE2-CE2 блокируется.
Теперь перейдем к настройке. Сразу отмечу, что мне удалось воссоздать такое поведение только с использованием протокола LDP для VPLS сигнализации (RFC 4762), хотя нигде в официальной документации об этом не написано (поправьте, если ошибаюсь).
В отличие от обычных коммутаторов, чтобы настроить STP на маршрутизаторах серии MX, необходимо создать routing-instance с типом layer2-control.
PE1 и PE3
PE2 и PE4
Проверяем работу STP
STP отрабатывает как и должен — порт в сторону CE2 блокируется по root protect.
В отличие от BGP, при настройки VPLS с LDP-сигнализацией, необходимо вручную указывать IP-адреса всех PE-маршрутизаторов участвующих в VPLS.
PE1
Ключевой параметр здесь — это mac-flush. Без него маршрутизаторы не будут сбрасывать таблицу MAC-адресов при изменении топологии.
На PE2, PE3, PE4 настройки абсолютно идентичные за исключением строк neighbor.
Проверяем работу LDP
LDP соединения поднялись, смотрим, что с VPLS
Тут тоже все в порядке. На PE2 соединения в состоянии standby.
Проверяем что CE3 может пинговать CE2. Трафик при этом должен пройти через PE3, PE1 и CE1.
Смотрим таблицу MAC-адресов на PE3
Здесь 50:00:00:08:80:0a — MAC-адрес интерфейса Vlan10 на CE2, lsi.1049088 — PW от PE3 до PE1.
Теперь разорвем линк CE1-CE2 и посмотрим, что изменилось
Интерфейс PE2 в сторону CE2 перешел в состояние Forwarding как и должен был.
Снова пингуем PE2
Смотрим таблицу MAC на PE3
Как можно заметить MAC CE2 теперь на интерфейсе lsi.1049089, а это PW до PE2.
Как видно из статьи, организация VPLS Multihoming — не самая тривиальная задача со своими подводными камнями. Оба описанных мной подхода к решению этой задачи имеют свои преимущества и недостатки и применимы только в определенных ситуациях. К общему недостатку VPLS Multihoming можно отнести невозможность одновременного использования двух аплинков. Если такой функционал необходим, следует смотреть в сторону технологии EVPN, которая постепенно приходит на замену VPLS.
- BGP-Based VPLS Multihoming
- Связка VPLS и STP
- MC-LAG
В данной статье я бы хотел рассмотреть первые два подхода.
Содержание
Настройка транспорта
- Базовая настройка PE-маршрутизаторов
- Базовая настройка P-маршрутизаторов
- Базовая настройка CE-коммутаторов
BGP-Based VPLS Multihoming
Связка VPLS и STP
Выводы
Материалы, использованные при написании статьи
Дисклеймер
Основная цель данной статьи — представить рабочую конфигурацию достаточно комплексного решения. При написании я не ставил себе цель глубоко вдаваться в теорию и пояснять тонкости работы тех или иных протоколов, о которых пойдет речь. Подразумевается, что читатель хорошо знаком с работой MPLS, BGP и Spanning-tree протоколов.
Настройка транспорта
Ниже представлена топология, которую я буду использовать в этой статье.
Сеть провайдера состоит из PE и P маршрутизаторов (Juniper MX), все они находятся в OSPF Area 0 и BGP AS 65412. Абонентская сеть — это три коммутатора (Cisco Catalyst), на каждом из которых поднят Vlan 10 и RPVST-версия Spanning-tree протокола (VSTP в терминологии Juniper).
Прежде чем начинать настройку VPLS, необходимо поднять MPLS-транспорт. Для сигнализации LSP в данном примере используется протокол RSVP. Для краткости я привожу конфигурации только двух маршрутизаторов, остальные легко настроить по аналогии.
Базовая настройка PE-маршрутизаторов на примере PE1
PE1 base config
system {
host-name PE1;
}
interfaces {
ge-0/0/0 {
encapsulation flexible-ethernet-services;
flexible-vlan-tagging;
unit 10 {
encapsulation vlan-vpls;
vlan-id 10;
}
}
ge-0/0/1 {
mtu 2000;
unit 0 {
family inet {
address 10.0.11.1/30;
}
family mpls;
}
}
ge-0/0/2 {
mtu 2000;
unit 0 {
family inet {
address 10.0.12.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
}
}
}
}
routing-options {
router-id 10.0.0.1;
autonomous-system 65412;
}
protocols {
rsvp {
interface lo0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
mpls {
label-switched-path PE1-PE2 {
to 10.0.0.2;
no-cspf;
}
label-switched-path PE1-PE3 {
to 10.0.0.3;
no-cspf;
}
label-switched-path PE1-PE4 {
to 10.0.0.4;
no-cspf;
}
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/1.0 {
interface-type p2p;
}
interface ge-0/0/2.0 {
interface-type p2p;
}
interface lo0.0;
}
}
}
Параметры flexible-vlan-tagging и flexible-ethernet-sevices позволяют настраивать на физическом интерфейсе не только VPLS, но и другие сервисы, используя разные логические юниты. Если интерфейс планируется использовать только под VPLS, то следует указать encapsulation ethernet-vpls или vlan-vpls. Подробнее тут.
Базовая настройка P-маршрутизаторов на примере P1
P1 base config
system {
host-name P1;
}
interfaces {
ge-0/0/0 {
mtu 2000;
unit 0 {
family inet {
address 10.0.11.2/30;
}
family mpls;
}
}
ge-0/0/1 {
mtu 2000;
unit 0 {
family inet {
address 10.0.13.2/30;
}
family mpls;
}
}
ge-0/0/2 {
mtu 2000;
unit 0 {
family inet {
address 10.0.21.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.11/32;
}
}
}
}
routing-options {
router-id 10.0.0.11;
autonomous-system 65412;
}
protocols {
rsvp {
interface lo0.0;
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
mpls {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0 {
interface-type p2p;
}
interface ge-0/0/1.0 {
interface-type p2p;
}
interface ge-0/0/2.0 {
interface-type p2p;
}
interface lo0.0;
}
}
}
Проверяем, что MPLS поднялся и работает:
lab@PE1> traceroute mpls rsvp PE1-PE2
Probe options: retries 3, exp 7
ttl Label Protocol Address Previous Hop Probe Status
1 10.0.12.2 (null) Egress
Path 1 via ge-0/0/2.0 destination 127.0.0.64
lab@PE1> traceroute mpls rsvp PE1-PE3
Probe options: retries 3, exp 7
ttl Label Protocol Address Previous Hop Probe Status
1 299888 RSVP-TE 10.0.11.2 (null) Success
2 3 RSVP-TE 10.0.13.1 10.0.11.2 Egress
Path 1 via ge-0/0/1.0 destination 127.0.0.64
lab@PE1> traceroute mpls rsvp PE1-PE4
Probe options: retries 3, exp 7
ttl Label Protocol Address Previous Hop Probe Status
1 299936 RSVP-TE 10.0.11.2 (null) Success
2 299792 RSVP-TE 10.0.13.1 10.0.11.2 Success
3 3 RSVP-TE 10.0.34.2 10.0.13.1 Egress
Path 1 via ge-0/0/1.0 destination 127.0.0.64
Базовая настройка CE-коммутаторов
CE1 base config
hostname CE1
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
vlan 10
!
interface GigabitEthernet0/0
switchport trunk allowed vlan 10
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface Vlan10
ip address 192.168.10.1 255.255.255.0
no shutdown
!
CE2 base config
hostname CE2
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
vlan 10
!
interface GigabitEthernet0/0
switchport trunk allowed vlan 10
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface Vlan10
ip address 192.168.10.2 255.255.255.0
no shutdown
!
CE3 base config
hostname CE3
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
!
vlan 10
!
interface GigabitEthernet0/0
switchport trunk allowed vlan 10
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/1
switchport trunk allowed vlan 10
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface Vlan10
ip address 192.168.10.3 255.255.255.0
no shutdown
!
Теперь можно перейти непосредственно к настройки сервиса VPLS.
BGP-Based VPLS Multihoming
В первую очередь я бы хотел рассмотреть «классическую», с точки зрения Juniper, реализацию VPLS с использованием BGP сигнализации (RFC 4761). С точки зрения control plane это мало чем отличается от обычного L3VPN — здесь также используются Route Distinguisher и Route Target, а в качестве address family указывается l2vpn.
Для начала нужно настроить сам протокол BGP. Так как для корректной работы iBGP необходима полная связность внутри сети, я использовал P1 и P2 в качестве route-reflector, для упрощения конфигурации.
Настройка BGP
PE-маршрутизаторы:
PE BGP config
где X — номер соответствующего PE
protocols {
bgp {
group IBGP {
type internal;
local-address 10.0.0.X;
family l2vpn {
signaling;
}
neighbor 10.0.0.11;
neighbor 10.0.0.22;
}
}
}
где X — номер соответствующего PE
P1
P1 BGP config
routing-options {
rib inet.3 {
static {
route 10.0.0.0/24 discard;
}
}
}
protocols {
bgp {
group IBGP {
type internal;
local-address 10.0.0.11;
family l2vpn {
signaling;
}
cluster 10.0.0.0;
neighbor 10.0.0.1;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
}
P2
P2 BGP config
routing-options {
rib inet.3 {
static {
route 10.0.0.0/24 discard;
}
}
}
protocols {
bgp {
group IBGP {
type internal;
local-address 10.0.0.22;
family l2vpn {
signaling;
}
cluster 10.0.0.0;
neighbor 10.0.0.1;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
}
Тут стоит отметить блок routing-options. Когда route-reflector получает маршрут от своего клиента, прежде чем анонсировать его остальным клиентам, он проверяет доступность next-hop в таблице inet.3. Так как при первоначальной настройке MPLS на P-маршрутизаторах, я не стал создавать LSP до PE-маршрутизаторов, эта таблица пуста и, соответственно, проверка не срабатывает. Маршруты полученные от RR-клиентов помечаются как hidden и не анонсируются дальше. Конечно, можно создать LSP от RR до каждого PE, но это трудоемко, к тому же эти LSP никогда не будут использоваться для передачи трафика. Гораздо проще и элегантнее создать статический маршрут до lo0 сети.
На данный момент BGP связность должна работать между всеми PE-маршрутизаторами, но им пока что нечего анонсировать. Можно переходить к настройке VPLS.
Настройка VPLS
PE1
PE1 BGP VPLS config
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
route-distinguisher 10.0.0.1:1;
vrf-target target:65412:10;
protocols {
vpls {
no-tunnel-services;
site CE1 {
site-identifier 1;
interface ge-0/0/0.10;
}
}
}
}
}
PE2
PE2 BGP VPLS config
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
route-distinguisher 10.0.0.2:1;
vrf-target target:65412:10;
protocols {
vpls {
no-tunnel-services;
site CE2 {
site-identifier 2;
interface ge-0/0/0.10;
}
}
}
}
}
Тут все достаточно просто: создаем routing-instance с типом vpls, назначаем RD и RT, указываем интерфейсы в сторону CE и уникальный site-identifier.
Проверяем:
lab@PE1> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up May 30 17:29:28 2015 1
Remote PE: 10.0.0.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262145
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 1 remote site 2
lab@PE2> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE2 (2)
connection-site Type St Time last up # Up trans
1 rmt Up May 30 17:29:30 2015 1
Remote PE: 10.0.0.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262146
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 2 remote site 1
VPLS-соединения поднялись. Можно проверить связность CE1 и CE2:
CE1>ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 10/119/207 ms
Настройка Multihoming
Как видно из топологии, коммутатор CE3 соединяется одновременно с двумя PE-маршрутизаторами. Здесь для избежания возникновения L2-петель необходимо задействовать механизм Multihoming. Рассмотрим настройки PE3 и PE4.
PE3
PE3 VPLS config
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
route-distinguisher 10.0.0.3:1;
vrf-target target:65412:10;
protocols {
vpls {
no-tunnel-services;
site CE3 {
site-identifier 3;
multi-homing;
site-preference primary;
interface ge-0/0/0.10;
}
}
}
}
}
PE4
PE4 VPLS config
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
route-distinguisher 10.0.0.4:1;
vrf-target target:65412:10;
protocols {
vpls {
no-tunnel-services;
site CE3 {
site-identifier 3;
multi-homing;
site-preference backup;
interface ge-0/0/0.10;
}
}
}
}
}
В отличие от предыдущих конфигураций PE1 и PE2 здесь добавляется два параметра:
- multi-homing — указывает маршрутизатору, что он подключен к multihomed сайту;
- site-preference — значение от 1 (primary) до 65535 (backup), анонсируемое другим PE как BGP community.
При этом указывается одинаковый site-identifier на обоих PE. Таким образом PE3 и PE4 анонсируют один и тот же l2vpn-маршрут, отличающийся только параметром site-preference. Маршрут с наивысшим site-preference, т.е. маршрут от PE3, выигрывает и весь l2vpn трафик от PE1 и PE2 начинает идти через PE3. Интерфейс ge-0/0/0 на PE4 не пропускает трафик.
lab@PE1> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up May 30 17:29:28 2015 1
Remote PE: 10.0.0.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262145
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 1 remote site 2
3 rmt Up May 30 20:16:41 2015 1
Remote PE: 10.0.0.3, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262145
Local interface: lsi.1048579, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 1 remote site 3
lab@PE2> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE2 (2)
connection-site Type St Time last up # Up trans
1 rmt Up May 30 17:29:30 2015 1
Remote PE: 10.0.0.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262146
Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 2 remote site 1
3 rmt Up May 30 20:16:42 2015 1
Remote PE: 10.0.0.3, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262146
Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 2 remote site 3
lab@PE3> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE3 (3)
connection-site Type St Time last up # Up trans
1 rmt Up May 30 20:16:35 2015 1
Remote PE: 10.0.0.1, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262147
Local interface: lsi.1048833, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 3 remote site 1
2 rmt Up May 30 20:16:35 2015 1
Remote PE: 10.0.0.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262147
Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS local site 3 remote site 2
3 rmt RN
lab@PE4> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
Local site: CE3 (3)
connection-site Type St Time last up # Up trans
1 rmt LN
2 rmt LN
3 rmt LN
Следует обратить внимание, что на PE4 все VPLS соединения находятся в состоянии LN — local site not designated. Это говорит о том, что PE4 не участвует в передаче VPLS трафика
При падении линка PE3-CE3 или при потере связности PE3 с остальной сетью, маршрутизатор перестает анонсировать l2vpn маршрут, PE4 начинает пропускать трафик на интерфейсе ge-0/0/0, а PE1 и PE2 начинают маршрутизировать трафик в сторону PE4. Скорость переключения каналов в данном случае зависит от скорости схождения BGP.
Связка VPLS и STP
Теперь к самому интересному. Рассмотрим топологию, в которой CE1 и CE2 соединены между собой.
При использовании BGP-Based Multihoming в такой топологии, все будет хорошо до тех пор пока не порвется линк CE1-CE2. PE-маршрутизаторы не узнают об изменении топологии и, в случае, когда, например, PE1 будет основным маршрутизатором, трафик к CE2 продолжит идти через PE1 и будет сбрасываться.
Чтобы изменения топологии в CE-сегменте передавались в VPLS-сегмент, необходимо настроить взаимодействие STP и VPLS.
Ниже немного высокоуровневой теории как это должно работать.
Рассмотрим штатную ситуацию, когда работают все линки.
- PE1 и PE2 участвуют как в STP, так и в VPLS доменах
- STP домен является локальным для CE1, CE2, PE1, PE2 и не распространяется на PE3, PE4 и CE3
- STP на PE1 и PE2 настроен так, что PE1 — это root бридж, а PE2 — backup root
- На портах PE1 и PE2 смотрящих в сторону CE настроен root protect. Таким образом, когда на порт PE2 приходит BPDU от PE1, этот порт блокируется
- На PE1 и PE2 подняты PW (pseudowires) друг до друга и до PE3 и PE4 (полная связность), при этом PE2 сигнализирует свои PW как standby (показаны пунктиром), потому что порт в сторону CE2 находится в заблокированном состоянии
Предположим, что линк CE1-CE2 порвался.
В домене STP:
- CE1 и CE2 отправляют Topology Change Notification
- CE1 и CE2 сбрасывают MAC-таблицы
- PE2 становится root бриджем в своем сегменте
- PE1 остается root бриджем
- PE2 разблокирует порт в сторону CE2, т.к. перестает получать BPDU от PE1
В домене VPLS:
- PE2 переводит свои PW в состояние Up, потому что порт в сторону CE2 больше не блокируется
- PW на PE1 остаются в состоянии Up как и раньше
- PE2 посылает сигнал PE3 и PE4 сбросить MAC-адреса, полученные от PE1
- PE3 и PE4 начинают использовать и PE1 и PE2 для передачи трафика до CE1 и CE2
При восстановлении линка CE1-CE2 снова отправляется TCN и сценарий повторяется, с тем различием, что линк PE2-CE2 блокируется.
Теперь перейдем к настройке. Сразу отмечу, что мне удалось воссоздать такое поведение только с использованием протокола LDP для VPLS сигнализации (RFC 4762), хотя нигде в официальной документации об этом не написано (поправьте, если ошибаюсь).
Настройка STP
В отличие от обычных коммутаторов, чтобы настроить STP на маршрутизаторах серии MX, необходимо создать routing-instance с типом layer2-control.
PE1 и PE3
PE1 & PE3 STP config
routing-instances {
STP {
instance-type layer2-control;
protocols {
vstp {
interface ge-0/0/0 {
mode point-to-point;
no-root-port;
}
vlan 10 {
bridge-priority 24k;
}
}
}
}
}
PE2 и PE4
PE2 & PE4 STP config
routing-instances {
STP {
instance-type layer2-control;
protocols {
vstp {
interface ge-0/0/0 {
mode point-to-point;
no-root-port;
}
vlan 10 {
bridge-priority 28k;
}
}
}
}
}
Проверяем работу STP
lab@PE1> show spanning-tree interface ge-0/0/0 routing-instance STP
Spanning tree interface parameters for VLAN 10
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0 128:1 128:1 24586.00058671c3d0 20000 FWD DESG
lab@PE2> show spanning-tree interface ge-0/0/0 routing-instance STP
Spanning tree interface parameters for VLAN 10
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0 128:1 128:1 32778.500000080000 20000 BLK ALT (Root-Prev)
STP отрабатывает как и должен — порт в сторону CE2 блокируется по root protect.
Настройка VPLS на LDP
В отличие от BGP, при настройки VPLS с LDP-сигнализацией, необходимо вручную указывать IP-адреса всех PE-маршрутизаторов участвующих в VPLS.
PE1
PE1 LDP VPLS config
protocols {
ldp {
interface lo0.0;
}
}
routing-instances {
VPLS {
instance-type vpls;
interface ge-0/0/0.10;
protocols {
vpls {
no-tunnel-services;
vpls-id 1;
mac-flush;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
}
}
Ключевой параметр здесь — это mac-flush. Без него маршрутизаторы не будут сбрасывать таблицу MAC-адресов при изменении топологии.
На PE2, PE3, PE4 настройки абсолютно идентичные за исключением строк neighbor.
Проверяем работу LDP
lab@PE1> show ldp neighbor
Address Interface Label space ID Hold time
10.0.0.2 lo0.0 10.0.0.2:0 33
10.0.0.3 lo0.0 10.0.0.3:0 44
10.0.0.4 lo0.0 10.0.0.4:0 41
LDP соединения поднялись, смотрим, что с VPLS
lab@PE1> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
VPLS-id: 1
Neighbor Type St Time last up # Up trans
10.0.0.2(vpls-id 1) rmt Up May 30 23:50:32 2015 1
Remote PE: 10.0.0.2, Negotiated control-word: No
Incoming label: 262401, Outgoing label: 262401
Negotiated PW status TLV: No
Local interface: lsi.1048580, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS neighbor 10.0.0.2 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
10.0.0.3(vpls-id 1) rmt Up May 30 23:51:49 2015 1
Remote PE: 10.0.0.3, Negotiated control-word: No
Incoming label: 262402, Outgoing label: 262401
Negotiated PW status TLV: No
Local interface: lsi.1048581, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS neighbor 10.0.0.3 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
10.0.0.4(vpls-id 1) rmt Up May 30 23:52:00 2015 1
Remote PE: 10.0.0.4, Negotiated control-word: No
Incoming label: 262403, Outgoing label: 262401
Negotiated PW status TLV: No
Local interface: lsi.1048582, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS neighbor 10.0.0.4 vpls-id 1
Flow Label Transmit: No, Flow Label Receive: No
lab@PE2> show vpls connections
Layer-2 VPN connections:
<...>
Instance: VPLS
VPLS-id: 1
Neighbor Type St Time last up # Up trans
10.0.0.1(vpls-id 1) rmt ST
10.0.0.3(vpls-id 1) rmt ST
10.0.0.4(vpls-id 1) rmt ST
Тут тоже все в порядке. На PE2 соединения в состоянии standby.
Проверяем что CE3 может пинговать CE2. Трафик при этом должен пройти через PE3, PE1 и CE1.
CE3>ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/18 ms
Смотрим таблицу MAC-адресов на PE3
lab@PE3> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : VPLS
Bridging domain : __VPLS__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
50:00:00:08:80:0a D lsi.1049088
50:00:00:09:80:0a D ge-0/0/0.10
Здесь 50:00:00:08:80:0a — MAC-адрес интерфейса Vlan10 на CE2, lsi.1049088 — PW от PE3 до PE1.
Теперь разорвем линк CE1-CE2 и посмотрим, что изменилось
lab@PE1> show spanning-tree interface ge-0/0/0 routing-instance STP
Spanning tree interface parameters for VLAN 10
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0 128:1 128:1 24586.00058671c3d0 20000 FWD DESG
lab@PE2> show spanning-tree interface ge-0/0/0 routing-instance STP
Spanning tree interface parameters for VLAN 10
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ge-0/0/0 128:1 128:1 28682.0005867142d0 20000 FWD DESG
Интерфейс PE2 в сторону CE2 перешел в состояние Forwarding как и должен был.
Снова пингуем PE2
CE3>ping 192.168.10.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/13/19 ms
Смотрим таблицу MAC на PE3
lab@PE3> show vpls mac-table
MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)
Routing instance : VPLS
Bridging domain : __VPLS__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
50:00:00:08:80:0a D lsi.1049089
50:00:00:09:80:0a D ge-0/0/0.10
Как можно заметить MAC CE2 теперь на интерфейсе lsi.1049089, а это PW до PE2.
Выводы
Как видно из статьи, организация VPLS Multihoming — не самая тривиальная задача со своими подводными камнями. Оба описанных мной подхода к решению этой задачи имеют свои преимущества и недостатки и применимы только в определенных ситуациях. К общему недостатку VPLS Multihoming можно отнести невозможность одновременного использования двух аплинков. Если такой функционал необходим, следует смотреть в сторону технологии EVPN, которая постепенно приходит на замену VPLS.
Материалы, использованные при написании статьи
Комментарии (9)
Sk1f3r
09.06.2015 18:23+3А можно использовать BGP EVPN, чтобы забыть про любую возможность петель и получить недостижимый для VPLS active-active.
Кстати:
Но за статью спасибо, всегда приятно почитать про Juniper :)dteslya Автор
09.06.2015 19:02Кстати, как будет отрабатывать EVPN, если к нему подключить полукольцо из коммутаторов, как на моей схеме, и линк CE-CE порвется?
CMHungry
09.06.2015 22:32а вот евпн надо сжечь, имхо
мак-лёрнинг выводить на цпу как-то совсем неправильно
Levor
Хорошая статья, жаль, кармы не хватает поставить плюс.
Кстати, в LDP-based VPLS не обязательно вручную прописывать адреса всех PE, можно использовать BGP autodiscovery.
dteslya Автор
Спасибо!
Согласен, забыл это упомянуть.
Chelioz
Вот и я сидел и не верил, как джуны будучи новаторами в этой теме могли упустить LDP-signaling с функцией AD.
Ещё меня, как адепта Cisco, смутило отсутствие отсутствие объяснений по ve-id и ve-range. Ей богу тут одна статья у джуников стоила десятка цисковских.