SavePearlHarbor

Настройка VPLS Multihoming на маршрутизаторах Juniper

—

от автора

admin

Технология VPLS уже давно зарекомендовала себя как способ объединения географически разнесенных объектов в единую L2-сеть. Такое решение хорошо масштабируется по сравнению с классической L2-сетью и позволяет избавиться от проблем L2-петель в ядре сети. Однако, часто возникает необходимость организации резервных каналов от абонента к VPLS-облаку. В такой ситуации есть опасность образования петель на участке PE-CE. Для решения этой проблемы существует несколько подходов. Вот некоторые из них:

  • BGP-Based VPLS Multihoming
  • Связка VPLS и STP
  • MC-LAG

В данной статье я бы хотел рассмотреть первые два подхода.

Содержание

Настройка транспорта

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

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.

Ниже немного высокоуровневой теории как это должно работать.
Рассмотрим штатную ситуацию, когда работают все линки.

  1. PE1 и PE2 участвуют как в STP, так и в VPLS доменах
  2. STP домен является локальным для CE1, CE2, PE1, PE2 и не распространяется на PE3, PE4 и CE3
  3. STP на PE1 и PE2 настроен так, что PE1 — это root бридж, а PE2 — backup root
  4. На портах PE1 и PE2 смотрящих в сторону CE настроен root protect. Таким образом, когда на порт PE2 приходит BPDU от PE1, этот порт блокируется
  5. На PE1 и PE2 подняты PW (pseudowires) друг до друга и до PE3 и PE4 (полная связность), при этом PE2 сигнализирует свои PW как standby (показаны пунктиром), потому что порт в сторону CE2 находится в заблокированном состоянии

Предположим, что линк CE1-CE2 порвался.

В домене STP:

  1. CE1 и CE2 отправляют Topology Change Notification
  2. CE1 и CE2 сбрасывают MAC-таблицы
  3. PE2 становится root бриджем в своем сегменте
  4. PE1 остается root бриджем
  5. PE2 разблокирует порт в сторону CE2, т.к. перестает получать BPDU от PE1

В домене VPLS:

  1. PE2 переводит свои PW в состояние Up, потому что порт в сторону CE2 больше не блокируется
  2. PW на PE1 остаются в состоянии Up как и раньше
  3. PE2 посылает сигнал PE3 и PE4 сбросить MAC-адреса, полученные от PE1
  4. 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.

Материалы, использованные при написании статьи

  1. Juniper Networks Warrior: A Guide to the Rise of Juniper Networks Implementations by Peter Southwick
  2. Implementing Provider-Provisioned VPNs Using Route Reflectors
  3. MPLS/RSVP configuration & troubleshooting
  4. VPLS on Junos Signalled via LDP or BGP
  5. Advanced VPLS

ссылка на оригинал статьи http://habrahabr.ru/post/259645/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *