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

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

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

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

Содержание

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

• Базовая настройка PE-маршрутизаторов
• Базовая настройка P-маршрутизаторов
• Базовая настройка CE-коммутаторов

BGP-Based VPLS Multihoming

• Настройка BGP
• Настройка VPLS
• Настройка Multihoming

Связка VPLS и STP

• Настройка STP
• Настройка VPLS на LDP

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

Дисклеймер

Основная цель данной статьи — представить рабочую конфигурацию достаточно комплексного решения. При написании я не ставил себе цель глубоко вдаваться в теорию и пояснять тонкости работы тех или иных протоколов, о которых пойдет речь. Подразумевается, что читатель хорошо знаком с работой 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