VPLS. Распределение меток с помощью BGP

    Любой инженер, сталкивавшийся с MPLS, знает что метки могут распределяться двумя способами: DU (Downstream Unsolicited) и DD (Downstream On-Demand). В первом случае маршрутизатор начинает генерировать и передавать всем своим LDP соседям метки до префиксов, к которым он является next-hop. Во втором случае LSR будет генерировать метку до префикса и передавать ее только по запросу вышестоящего маршрутизатора. Пример первого случая — протокол LDP, второй случай — RSVP-TE. А как распределяются метки в VPLS? Давайте разберемся.

    Для начала что такое VPLS и зачем он нужен. Virtual Private LAN Services — это эмуляция LAN для географически (и не только) распределенных сетей. Между разнесенными сайтами клиента (или элементами дата-центра) создаются виртуальные L2 соединения, в результате чего клиент видит сеть провайдера как подключение к коммутатору (к которому подключены и остальные его сайты):

    Картинку взял с сайта inetzero.

    Существует две реализации VPLS. Одна реализация предусматривает BGP сигнализацию (драфт Компелла), вторая установление target LDP сессий между PE маршрутизаторами (драфт Мартини).

    Во втором случае все просто. Метки распределяются по принципу Downstream Unsolicited с помощью Label mapping сообщений протокола LDP с типом FEC 128 (выделенная строка — сгенерированная метка):

    Сложнее понять, как распределяет метки VPLS, использующий BGP как сигнализацию (драфт Компелла). Данная реализация VPLS использует control plane для следующих задач:

    1. Автоматический поиск PE-маршрутизаторов, к которым подключены сайты клиента.

    2. Распределение MPLS меток для реализации полносвязанной L2 топологии между сайтами клиента.

    Для начала необходимо создать на каждом PE-маршрутизаторе, к которому подключены сайты клиента, routing instance с типом VPLS:
    routing-instances {
        vpls-bgp-cutomer1 {
            instance-type vpls;
            interface ge-0/0/1.0;
            route-distinguisher 100:100;
            vrf-target {
                import target:1:1;
                export target:2:2;
            }
            protocols {
                vpls {
                    site-range 5;
                    no-tunnel-services;
                    site ce1 {
                        site-identifier 1;
                    }
                }
            }
        }
    }
    

    Настраиваем BGP сигнализацию. Для данного типа VPLS нам необходимо включить address family l2vpn signaling:
    root# show protocols bgp
    group internal {
        type internal;
        local-address 10.1.1.1;
        family l2vpn {
            signaling;
        }
        neighbor 10.3.3.3;
    }
    

    Настраиваем интерфейсы в сторону клиента (к примеру так):
    root# show interfaces ge-0/0/1
    vlan-tagging;
    encapsulation vlan-vpls;
    unit 0 {
        encapsulation vlan-vpls;
        vlan-id 512;
        family vpls;
    }
    

    и не забываем увеличить значение MTU на интерфейсах в сторону ядра сети, так называемые core-face интерфейсы.

    Теперь можно посмотреть установилось ли наше соединение:
    root# run show vpls connections
    Layer-2 VPN connections:
    
    Legend for connection status (St)
    EI -- encapsulation invalid      NC -- interface encapsulation not CCC/TCC/VPLS
    EM -- encapsulation mismatch     WE -- interface and instance encaps not same
    VC-Dn -- Virtual circuit down    NP -- interface hardware not present
    CM -- control-word mismatch      -> -- only outbound connection is up
    CN -- circuit not provisioned    <- -- only inbound connection is up
    OR -- out of range               Up -- operational
    OL -- no outgoing label          Dn -- down
    LD -- local site signaled down   CF -- call admission control failure
    RD -- remote site signaled down  SC -- local and remote site ID collision
    LN -- local site not designated  LM -- local site ID not minimum designated
    RN -- remote site not designated RM -- remote site ID not minimum designated
    XX -- unknown connection status  IL -- no incoming label
    MM -- MTU mismatch               MI -- Mesh-Group ID not available
    BK -- Backup connection          ST -- Standby connection
    PF -- Profile parse failure      PB -- Profile busy
    RS -- remote site standby        SN -- Static Neighbor
    VM -- VLAN ID mismatch
    
    Legend for interface status
    Up -- operational
    Dn -- down
    
    Instance: vpls-bgp-cutomer1
      Local site: ce1 (1)
        connection-site           Type  St     Time last up          # Up trans
        2                         rmt   Up     Jan 16 20:50:51 2016           1
          Remote PE: 10.3.3.3, Negotiated control-word: No
          Incoming label: 262154, Outgoing label: 262145
          Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS
            Description: Intf - vpls vpls-bgp-cutomer1 local site 1 remote site 2
    

    Как видим соединение установлено. На выводе ниже видно, что между маршрутизаторами клиента поднялось OSPF соседство и появились маршруты до лупбеков:
    R7(config)#
    *Jan 16 16:52:54.554: %OSPF-5-ADJCHG: Process 1, Nbr 20.1.1.1 on GigabitEthernet1/0.512 from LOADING to FULL, Loading Done
    R7(config)#sh
    R7(config)#do sh ip rou
    R7(config)#do sh ip route
    Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area, * - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
           + - replicated route, % - next hop override
    
    Gateway of last resort is not set
    
          100.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
    C        100.0.0.0/24 is directly connected, GigabitEthernet1/0.512
    L        100.0.0.2/32 is directly connected, GigabitEthernet1/0.512
    O        100.1.1.1/32 [110/2] via 100.0.0.1, 00:00:54, GigabitEthernet1/0.512
    C        100.1.1.2/32 is directly connected, Loopback0
    R7(config)#do ping 100.1.1.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 100.1.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 24/40/88 ms
    

    Передаваемые по сети пакеты будут выглядеть следующим образом (какое нужно установить MTU, можете посчитать сами):

    Все работает. Теперь посмотрим, какие метки распределены между сайтами:
    Instance: vpls-bgp-cutomer1
      Local site: ce1 (1)
        connection-site           Type  St     Time last up          # Up trans
        2                         rmt   Up     Jan 16 20:50:51 2016           1
          Remote PE: 10.3.3.3, Negotiated control-word: No
          Incoming label: 262154, Outgoing label: 262145
          Local interface: lsi.1048832, Status: Up, Encapsulation: VPLS
            Description: Intf - vpls vpls-bgp-cutomer1 local site 1 remote site 2
    

    Instance: vpls-bgp-customer1
      Local site: ce2 (2)
        connection-site           Type  St     Time last up          # Up trans
        1                         rmt   Up     Jan 16 20:50:49 2016           1
          Remote PE: 10.1.1.1, Negotiated control-word: No
          Incoming label: 262145, Outgoing label: 262154
          Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
            Description: Intf - vpls vpls-bgp-customer1 local site 2 remote site 1
    

    Нас интересует эта строка вывода:
    Incoming label: 262154, Outgoing label: 262145

    То есть PE1 для отправки пакета от CE1 к CE2 будет использовать метку 262145, а с меткой 262154 PE1 будет принимать пакеты, идущие от CE2 к CE1. Но как эти метки генерируются и передаются? Разберемся поподробнее. Для этого посмотрим дамп трафика BGP сессии между PE1 и PE2 (сейчас BGP-сессия установлена между пирами, но в реальной жизни в 99 процентах случаев используется роут-рефлекторы):

    Первая задача сигнализации решается с помощью всем небезызвестных Route Target и Route Distinguisher. В строке extended community приведенного дампа видно значение RT, как и при L3VPN, оно используется для фильтрации маршрутной информации. Автоматический поиск обязывает данный тип routing-instance иметь сконфигурированное значение RD ( к слову говоря в пределах одного VPLS домена оно может быть одинаковым).

    Нам же сейчас необходимо понять как реализован механизм распределения меток. Интерес для нас представляет строка NLRI. В строке указаны несколько значений, но в отличии от L3VPN или VPLS LDP Signaling, нет точного указания на сгенерированную метку. Разберем каждое значение данного поля.

    Первые два поля думаю всем понятны:
    RD 100:0.0.0.100 — это RD (думаю все знают, что такое RD, и пояснять не надо)
    CE-ID — тут указан Site-id, сконфигурированный администраторами сети.

    А вот следующие три параметра нам не знакомы. Дело в том, что VPLS (драфт Компелла) распределяет метки не по одной, а блоками по 8 (по умолчанию) меток в блоке. Эти поля как раз и характеризуют распределенный блок меток.

    Label-Block Offcet — это сдвиг метки от базы меток;
    Label-Block Size — размер блока меток, в JunOS по умолчанию он равен 8 меткам;
    Label Base — это база блока меток.

    Теперь начинается математика. PE-маршрутизатор, к которому подключен сайт клиента, отправляет всем остальным PE-маршрутизаторам BGP Update сообщение, содержащее:
    1. RD
    2. CE-ID
    3. Label-Block Offcet
    4. Label-Block Size
    5. Label Base

    Так как VPLS это набор LSP, вложенных в другие LSP, то нам нужно знать:
    1. С какой меткой отправить пакет на какой либо сайт
    2. От какого сайта прилетел пакет с указанной меткой

    PE-маршрутизатор, получив указанное выше BGP Upgrade сообщение производит следующие операции. используя полученные от соседа данные:

    Outgoing Label = Label Base удаленного сайта — Label-Block Offcet удаленного сайта + свой Site ID

    В нашем случае PE2 произведет следующие операции: значение базы 262153, отнимает от этого значение сдвиг меток (у нас 1) и прибавляет к этому значению свой Site-ID. Это и будет являться исходящей меткой до сайта, от которого данное BGP Update сообщение пришло:

    Получаем, что-бы от сайта CE2 добраться до сайта CE1, PE2 должен отправить пакет с меткой: 262153(база)-1(сдвиг)+2(site-id)=262154. Смотрим вывод:
    Instance: vpls-bgp-customer1
      Local site: ce2 (2)
        connection-site           Type  St     Time last up          # Up trans
        1                         rmt   Up     Jan 16 20:50:49 2016           1
          Remote PE: 10.1.1.1, Negotiated control-word: No
          Incoming label: 262145, Outgoing label: 262154
          Local interface: lsi.1048576, Status: Up, Encapsulation: VPLS
            Description: Intf - vpls vpls-bgp-customer1 local site 2 remote site 1
    

    Все верно, исходящая метка 262154. Теперь, PE1, получая пакет с указанной меткой 262154, знает, что этот пакет отправлен с PE2 сайта CE2.

    Входящая метка рассчитывается точно так же, только значение базы и сдвиг берутся свои собственные (сгенерированные нами для других PE маршрутизаторов), а как идентификатор сайта используется site-id необходимого PE маршрутизатора:

    Incoming label = свой Label Base — свой Label-Block Offcet+ Site ID удаленного сайта

    Давайте изменим конфигурацию и произведем расчет еще раз. Теперь у нас максимальное количество сайтов 10, а наши сайты имеют идентификаторы 9 (CE1) и 6 (CE2) (остальные 8 сайтов нет смысла конфигурировать для понимания принципа, так как вычисления будут те же, но их станет больше). Попробуем снова рассчитать значение меток. Посмотрим на дампы трафика:
    От PE1 к PE2:

    От PE2 к PE1:

    Мы имеем такие данные.
    От PE1:
    RD 100:0.0.0.100
    CE-ID 9
    Label-Block Offcet 1
    Label-Block Size 8
    Label Base 262169

    От PE2:
    RD 200:0.0.0.200
    CE-ID 6
    Label-Block Offcet 1
    Label-Block Size 8
    Label Base 262153

    Теперь рассчитаем, какие входящие и исходящие метки должны быть у сайтов.

    PE1 (сайт 9):
    Входящая метка от сайта 6: 262169-1+6=174
    Исходящая метка к сайту 6: 262153-1+9=161

    PE2 (сайт 6):
    Входящая метка от сайта 9: 262153-1+9=161
    Исходящая метка к сайту 9: 262169-1+6=174

    И проверим произведенные расчеты:

    На PE1:
    Instance: vpls-bgp-cutomer1
      Local site: ce1 (9)
        connection-site           Type  St     Time last up          # Up trans
        6                         rmt   Up     Jan 16 21:10:58 2016           1
          Remote PE: 10.3.3.3, Negotiated control-word: No
          Incoming label: 262174, Outgoing label: 262161
          Local interface: lsi.1048833, Status: Up, Encapsulation: VPLS
            Description: Intf - vpls vpls-bgp-cutomer1 local site 9 remote site 6
    

    На PE2:
    Instance: vpls-bgp-customer1
      Local site: ce2 (6)
        connection-site           Type  St     Time last up          # Up trans
        9                         rmt   Up     Jan 16 21:10:53 2016           1
          Remote PE: 10.1.1.1, Negotiated control-word: No
          Incoming label: 262161, Outgoing label: 262174
          Local interface: lsi.1048577, Status: Up, Encapsulation: VPLS
            Description: Intf - vpls vpls-bgp-customer1 local site 6 remote site 9
    

    Как видите мы рассчитали все верно.

    Если вы еще не поняли как работает данный механизм, прошу в веселые картинки под спойлер
    в картинках
    Рассмотрим данную топологию:

    VPLS создаст полносвязанную топологию между всеми тремя сайтами клиента:

    PE1 отправляет на PE2 и PE3 BGP Update сообщения с указанными на иллюстрации данными:

    PE2 и PE3 по формуле высчитывают значения исходящих меток до PE1, а PE1 просчитывает входящие метки от PE2 и PE3:

    Следующие изображения иллюстрируют описанный выше процесс на PE2:

    И на PE3:

    В итоге на всех PE-маршрутизаторах есть и входящие и исходящие метки для всех сайтов:


    Хочу добавить, что если у клиента будет например 10 или 12 сайтов, то нам нужен не один стандартный блок меток, а два. Поэтому в сообщение BGP Update может быть несколько значений сдвига меток и базы:

    И еще одно дополнение — JunOS по умолчанию использует блок из 8 меток, даже если вам надо соединить всего два или три сайта. Но с помощью команды set label-block-size можно изменить количество меток в блоке. JunOS поддерживает 2, 4, 8 или 16 меток в блоке. Но надо учитывать, что если вы измените данное значение на уже работающем VPLS домене, то все установленные в данном VPLS домене соединения будут разорваны и установлены заново, с новыми параметрами.
    • +9
    • 23.1k
    • 1
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 1

      0
      Очень интересная статья! Спасибо!

      Only users with full accounts can post comments. Log in, please.