L2VPN

ISP предоставляет только транспорт. Маршрутизация ложится на клиента.

Обе схемы работают одинаково с точки зрения forwarding (используют одинаковую инкаспуляцию). Разница только в signaling (control plane)- BGP vs LDP.

Martini - даже нет понятия VPN, это просто объединение 2х точек.

Martini (LDP)

Signaling

На PE2 int 1 приходит l2-пакет. Пакет нужно туннелировать. Но если просто отправить пакет, то на PE1: не понятно что делать с пакетом. Поэтому при передаче через туннель нужно добавить 2 метки. Верхняя, чтобы передать по туннелю, нижняя связана с интерфейсом.

• Каждый PE каждому интерфейсу выделяет метку (VC label).
• Приходящие пакеты будут сразу обрабатываться по mpls.0: 40 pop -> int 1, 50 pop -> int 2, 60 pop -> int 3.
• Как только сконфигурирован l2circuit, интерфейсу выделена метка и записана в mpls.0.
• Cо стороны PE1 (ingress) - mpls.0: int 1 push 40 push 20 -> P (резолв LDP соседа из inet.3), int 3 push 60 push 20 -> P.

PE1 должен получить информацию о метках, которые нужно назначать. Как??

• Для передачи используется LDP сессия PE1 <> PE2, в конфигурации задано куда строить LDP туннель. Помним, что по умолчанию LDP поднимает сессии только с непосредственно подключенными соседями.
• Метки (40, 50, 60) передали от PE2 к PE1.
• PE1 должен определить какая метка какому интерфейсу соответствует. Этот параметр задаем руками. Virtual curcuit-ID (VCI) - должен быть уникальным для пары устройств, размер 4 байта. VCI передается вместе с метками.

Дополнительно передается:

• инкапсуляция, которая должна быть одинаковой с обоих концов l2curcuit
• vlan-id - одинаковый (в Cisco может быть одинаковым)
• MTU - одинаковый, задается только для сигналинга, не имеет практического значения.

Lo интерфейсы должны быть добавлены в [protocols ldp]

Forwarding

Фрейм: ip(1500) + l2 header(18) + CW-control word (4) + mpls int (4) + mpls tunnel (4) - это минимальный вариант, но он уже получается большой => стоит ставить MTU с запасом ~1570 или больше.

Форвардинг строится только на метках mpls.0. Внутри сети провайдера пакет передается в 2ми метками (туннельная и интерфейсная).

Мак-адреса не изучаются. Вообще фрейм просто передается тупо и все.

Circuit - это по сути 2 метки: на вход (inncoming), на выход (outgoing).

Пример (часть ненужных полей в выводе удалена):

lagavulin> show route table l2circuit.0 detail 
l2circuit.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
10.200.86.3:CtrlWord:4:550:Local/96 (1 entry, 1 announced)
       *L2CKT  Preference: 7
               Next hop type: Indirect
               Next hop: 192.168.86.1 via ge-0/0/0.30 weight 0x1, selected
               Label-switched-path lagavulin-to-oban
               Label operation: Push 300592
               Protocol next hop: 10.200.86.3
               Age: 41:24 	Metric2: 4 
               Announcement bits (1): 0-LDP 
               AS path: I
               VC Label 299968, MTU 9000, VLAN ID 550
10.200.86.3:CtrlWord:4:550:Remote/96 (1 entry, 1 announced)
       *LDP    Preference: 9
               Next hop type: Discard
               Age: 37:49 
               Announcement bits (1): 1-l2 circuit 
               AS path: I
               VC Label 300064, MTU 9000, VLAN ID 550

• 300064 - push VC label for that destination (метка для интерфейса)
• 300592 - push MPLS label (для LSP туннеля)
• 299968 - роутер будет ожидать для данного circuit пакет с этой меткой

Configuration

[edit interfaces ge-0/0/0]
  encapsulation flexible-ethernet-services;
[edit interfaces ge-0/0/0]
   unit 560 {
       description l2-to-lagavulin;
       encapsulation vlan-ccc;
       vlan-id 560;
   }
[edit protocols l2circuit neighbor 10.200.86.7]
     interface ge-0/0/0.560 {
        virtual-circuit-id 560;
        description l2-to-lagavulin;
        mtu 9000;
    }
[edit protocols ldp]
   interface Lo0.0

Для ссс-инкапсуляции зарезервирован диапазон 512-4094

Кстати, можно объединять интерфейсы между собой на одном роутере.

[edit protocols l2circuit local-switching]
interface ge-0/0/1.200
   end-interface
      interface ge-0/0/3.200

Troubleshooting

Можно смотреть только состояние l2circuit connection. =( Если исключить всякие тупые ошибки, типа mtu mismatch, ненастроенный сигналинг с двух сторон и т.п., то в основном проблемы сводятся к проблемам с обменом метками между PE. В таком случае проверяем:

• LDP соседство
• LDP database
• Наличие Lo в inet.3 и т.д.

Если control plane поднялся:

• Можем смотреть только обмен пакетами на интерфейсе.
• Поднимать l3 интерфейсы и смотреть свзяность через l2circuit.
• Если физически нет возможности поднять l3, то можно задействовать logical-tunnel.

Kompella (BGP)

Цель - создать полноценный VPN. В l2circuit используется LDP-full-mesh.

Для Kompella используется сигнализация на основе BGP, можно соорудить full-mesh iBGP, можно использовать RR.

• Для клиента создается отдельный RI.
• В него добавляются локальные интерфейсы клиента и
• указывается с каким удаленным роутером RI будет соединяться. Router-ID - не очень надежно, т.к. его можно заменить, и в таком случае придется переделывать все RI для клиента по всей сети. Поэтому привязку сделали по site-id - задаются вручную, определяют схему коммутации между роутерами (в рамках RI).
• Метка назначается каждому локальному интерфейсу, который ассоциирован с site (per interface).
• Роутеры между собой обмениваются выделенными метками, чтобы удаленные site знали push какой метки делать, чтобы достичь нужного site. Набор меток - новый NLRI - family l2vpn signaling.
• У каждого клиента также присутствует свой идентификатор - route-target.

L2vpn signaling и выделение меток

Алгоритм выделения меток был оптимизирован, но для лучшего понимая как и зачем, рассмотрим этапы его становления. =)

Изначально, исходя из схемы, рассмотрим что требуется передавать между PE, на примере того, что передаст PE1:

• метки:

• 102 -> site 2
• 103 -> site 3
• 104 -> site 4

• local site-id:

• site-id = 1

• PE2 видит:

я - site 2, site 1 ассоциирован с int 1, site 1 прислал, что для отправки пакета ему, я должен сделать push 102 => int 1: push 102 push 50 (LSP до PE1) резолвим next-hop для PE1 в inet.3))

• PE3 видит:

я - site 3, site 1 ассоциирован с int 1, site 1 прислал, что для отправки пакета ему, я должен сделать push 103 => int 1: push 103 push 60.

То есть все PE получают от site 1 все метки, хотя им нужна всего одна, которая соответствует его site.

Kompella решил, что это излишняя инфа и что достаточно пересылать только метки, не указывая каким site они соответствуют. Метки просто будут располагаться ровно в том порядке, в котором они предназначены удаленным site.

101 - 1
102 - 2
103 - 3
...

В таком случае важно следить, чтобы site имели номера один за одним, блок меток - непрерывный.

Если на сети будет так: PE1 - site 1, PE2 - site 50, то PE1 будет вынужден выделить метки [1, ..., 50], хотя требуется только 1 и 50. Те site, которые пропускаются, для них будут созданы фейковые метки 2, 3, ..., 49, но метки использоваться не будут.

PE2 получит:

102
103
104

и выберет для себя 103, что будет не правильным поведением.

Отсюда вытекает еще один важный момент, что PE1, который генерирует NLRI с метками - должен запихнуть себя туда, чтобы не нарушить порядок меток.

В итоге от PE2 будет такое распределение меток:

int 1 (site 1) - 201 label
int 2 (site 3) - 203 label
int 3 (site 4) - 204 label
202 label - выделена, но не связана ни с каким интерфейсом.

И будет передан такой NLRI:

201
202
203
204
site-id 2

В Juniper выделен отдельный блок (для Kompella), начиная с 800000, в рамках 1 PE метки не повторяются, должны быть уникальными.

Затем Kompella решил оптимизировать алгоритм, и вместо того, чтобы передавать блок меток, будут передаваться параметры, а метку для себя каждый PE вычислит сам.

В итоге в NLRI передается:

• label base (начальная)
• site-ID
• label range

Исходя из полученных данных PE вычисляет свою метку для связи с тем PE, кот переслал блок:

label = label base + site-ID - 1 (offset)

Данная метка заносится в mpls.0

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

Когда добавляется еще один site: site-5: создал RI, сгенерировал NLRI, NLRI проанонсировался остальным PE, через RR. PE1 получил NLRI, понял, что появился site 5, требуется построить до него туннель, посмотрел какую метку push в сторону site 5 - все нормально.

PE5 получил NLRI всех PE от RR, начинает строить до них туннели. Для site 1 - возьмет 105 метку, которой в блоке нет, это понятно по label range. Что делать?

PE1, когда был получен NLRI от PE5, должен изменить NLRI, но метка 105 возможно будет уже занята для других целей. И + уже построенные туннели должны буду заново создаться, т.к. прилетит новый NLRI.

Поэтому, PE1 не меняет текущий блок, а добавляет к нему новый блок, тогда NLRI (конечный вариант):

• label base = 110
• site-id = 1
• label-range = 3
• label offset = 5 - равен начальному site-ID, которому выделена первая метка блока.

Выглядит так: 10.200.86.1:1212:1:3/96:

• 10.200.86.1:1212 - RD
• 1 - site-id
• 3 - offset
• /96 - mask

В случаях, когда на одном роутере подключены 2 site клиента, которые также требуется соединить между собой, можно просто внутри VRF разным интерфейсам назначаем разные site-ID. В этом случае просто для каждого site будет создан свой NLRI. Так тоже можно.

Configuration

blair# top show | compare  
[edit interfaces ge-0/0/0]
   unit 601 {
       encapsulation vlan-ccc;
       vlan-id 601;
   }
[edit protocols bgp group internal]
  family l2vpn {
      signaling;

[edit routing-instances]
fox-services {
   instance-type l2vpn;
   interface ge-0/0/0.600;
   interface ge-0/0/0.601;
   route-distinguisher 10.200.86.1:1212;
   vrf-target target:1111:1212;
   protocols {
       l2vpn {
           encapsulation-type ethernet-vlan;
           site blair {
               site-identifier 1;
               interface ge-0/0/0.600 {
                   remote-site-id 9;
               }
               interface ge-0/0/0.601 {
                   remote-site-id 4;

tormore:
fox-services {
   instance-type l2vpn;
   interface ge-0/0/0.850;
   route-distinguisher 10.200.86.9:1212;
   vrf-target target:1111:1212;
   protocols {
       l2vpn {
           encapsulation-type ethernet-vlan;
           site tormore {
               site-identifier 9;
               interface ge-0/0/0.850 {
                   remote-site-id 1;

Проверка

blair> show l2vpn connections    
Instance: fox-services
 Local site: blair (1)
   connection-site           Type  St     Time last up          # Up trans
   4                         rmt   Up     Nov  7 14:49:02 2016           1
     Remote PE: 10.200.86.4, Negotiated control-word: Yes (Null)
     Incoming label: 800001, Outgoing label: 800000
     Local interface: ge-0/0/0.601, Status: Up, Encapsulation: VLAN
   9                         rmt   Up     Nov  7 17:47:21 2016           1
     Remote PE: 10.200.86.9, Negotiated control-word: Yes (Null)
     Incoming label: 800002, Outgoing label: 800004
     Local interface: ge-0/0/0.600, Status: Up, Encapsulation: VLAN

blair> show route advertising-protocol bgp 10.200.86.9 detail 
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*  10.200.86.1:1212:1:3/96 (1 entry, 1 announced)
BGP group internal type Internal
    Route Distinguisher: 10.200.86.1:1212
    Label-base: 800000, range: 2, status-vector: 0x0 
    Nexthop: Self
    Flags: Nexthop Change
    Localpref: 100
    AS path: [1111] I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
*  10.200.86.1:1212:1:9/96 (1 entry, 1 announced)
BGP group internal type Internal
    Route Distinguisher: 10.200.86.1:1212
    Label-base: 800002, range: 2, status-vector: 0x0 
    Nexthop: Self
    Flags: Nexthop Change
    Localpref: 100
    AS path: [1111] I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

blair> show route receive-protocol bgp 10.200.86.9 detail table fox-services.l2vpn.0 
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*  10.200.86.9:1212:9:1/96 (1 entry, 1 announced)
    Import Accepted
    Route Distinguisher: 10.200.86.9:1212
    Label-base: 800004, range: 2, status-vector: 0x0 
    Nexthop: 10.200.86.9
    Localpref: 100
    AS path: I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

blair> show route table bgp.l2vpn.0 detail 
bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
10.200.86.4:1212:4:1/96 (1 entry, 0 announced)
       *BGP    Route Distinguisher: 10.200.86.4:1212
               Source: 10.200.86.4
               Protocol next hop: 10.200.86.4
               Age: 3:01:31 	Metric2: 1 
               Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
               Import Accepted
               Label-base: 800000, range: 2, status-vector: 0x0 
               Localpref: 100
               Router ID: 10.200.86.4
               Secondary Tables: fox-services.l2vpn.0
10.200.86.9:1212:9:1/96 (1 entry, 0 announced)
       *BGP    Route Distinguisher: 10.200.86.9:1212
               Source: 10.200.86.9
               Protocol next hop: 10.200.86.9
               Age: 3:12       Metric2: 1 
               Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
               Import Accepted
               Label-base: 800004, range: 2, status-vector: 0x0 
               Localpref: 100
               Router ID: 10.200.86.9
               Secondary Tables: fox-services.l2vpn.0

tormore> show route receive-protocol bgp 10.200.86.1 table fox-services.l2vpn.0 detail 
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
*  10.200.86.1:1212:1:3/96 (1 entry, 1 announced)
    Import Accepted
    Route Distinguisher: 10.200.86.1:1212
    Label-base: 800000, range: 2, status-vector: 0x0 
    Nexthop: 10.200.86.1
    Localpref: 100
    AS path: I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
*  10.200.86.1:1212:1:9/96 (1 entry, 1 announced)
    Import Accepted
    Route Distinguisher: 10.200.86.1:1212
    Label-base: 800002, range: 2, status-vector: 0x0 
    Nexthop: 10.200.86.1
    Localpref: 100
    AS path: I
    Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100

Forwarding Только метки и ничего больше! 1 метка для L2VPN, одна для передачи через LSP.

Ingress:

blair> show route table fox-services.l2vpn.0 detail
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 10.200.86.9:1212:9:1/96 (1 entry, 1 announced)
       *BGP Route Distinguisher: 10.200.86.9:1212
               Source: 10.200.86.9
               Protocol next hop: 10.200.86.9
               Age: 35:59 	Metric2: 1 
               Announcement bits (1): 0-fox-services-l2vpn 
               Communities: target:1111:1212 Layer2-info: encaps:VLAN, control flags:Control-Word, mtu: 0, site preference: 100
               Import Accepted
               Label-base: 800004, range: 2, status-vector: 0x0 
               Localpref: 100
               Router ID: 10.200.86.9
               Primary Routing Table bgp.l2vpn.0

blair> show route table fox-services.l2vpn.0           
fox-services.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
...
10.200.86.9:1212:9:1/96                
                  *[BGP/170] 00:37:40, localpref 100, from 10.200.86.9
                     AS path: I
                   > to 192.168.86.25 via ge-0/0/0.110, label-switched-path blair-to-tormore

blair> show rsvp session name blair-to-tormore detail 
Ingress RSVP: 2 sessions 
10.200.86.9
 From: 10.200.86.1, LSPstate: Up, ActiveRoute: 0
 LSPname: blair-to-tormore, LSPpath: Primary
 LSPtype: Static Configured
 Resv style: 1 FF, Label in: -, Label out: 301168

На транзитных будет swap и pop с метками для LSP.

Egress:

tormore> show route label 800004  
mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
800004             *[L2VPN/7] 00:05:53
                   > via ge-0/0/0.850, Pop       Offset: 4

Примечание

Можно соединять Kompella и Martini! Внутри RI, logical-tunnel: 1 int - заносим в instance, указываем его как локальный интерфейс, 2 int - локальный интерфейс для circuit. Можно использовать вместо logical-tunnel специальный интерфейс: iw.0 (он не требует включения tunnel-services). Включается аналогично logical-tunnel.

EVPN

About EVPN

Обеспечивает виртуальную многоточечную связность между разными L2 доменами через IP или MPLS сеть.

По аналогии с другими VPN, для EVPN на PE роутера создается отдельный Instance (EVIs), который логически разделяет клиентов.

CE имеют соединение с PE. PE обмениваются между собой информацией, использую MP-BGP и инкапсулированный трафик также передают между PE.

Особенность: есть mac-learning, который осуществляется на control plane. Новый мак-адрес изученный PE, передается остальным удаленным PE, используя MP-BGP MAC route. Mac-learning в EVPN намного более тонко работает, чем в VPLS.

С использованием EVPN, можно реализовать на сети много разных топологий: E-LINE, E-LAN, E-TREE.

MAC-learning на control-plane позволяет примерять policy и другие опции к MAC, изученными между PE, что делает подобный mac-learning более эффективным и дает возможность обеспечивать защиту на сети.

EVPN полезно внедрят ISP, предоставляющим своим клиентам L2VPN, L3VPN, Internet access и которые дополнительно хотели бы для существующих клиентов предоставить облачные сервисы и хранение данных.

Но в основном EVPN полезно использовать дата-центрам, которым требуется l2 связность между дата-центрами. Для внедрения в сеть дата-центров, EVPN обладает такими функиями:

• Multi-homing между CE-PE с поддержанием active-active линков.

Дает возможность подключиться одному CE к нескольким PE, при этом трафик передается по всем активным линкам.

Aliasing дает возможность удаленным PE делать балансировку к multi-homed PE, через core, даже в том случае, когда удаленный PE изучил мак с одного из Multi-homed PE.

Также в EVPN есть механизмы для предотвращения BUM петель.

В случае, когда CE не поддерживает балансировку или PE не имеет средств защиты от BUM петель, тогда можно организовать multi-homing с одним активным линком между PE и CE.

• Быстрое восстановление сервиса.

С помощью multi-homing, обеспечивается быстрое восстановление сервиса, т.к. при падении PE или линка до PE, трафик переходит на другой активный линк.

Трафик с другой стороны: удаленный PE обновляет свою forwarding table и также посылает трфик в сторону оставшихся активных PE.

• Поддержка миграции виртуальных машин или MAC mobility.

У PE есть возможность отслеживать перемещение мак-адреса виртуальной машины (VM). При этом, когда VM переместилась, то новый PE, который изучил ее MAC, делает MAC route update. Старый PE, получив таком update, удаляет у себя информацию об этом MAC.

• Интреграция L3 роутинга с оптимальным forwarding.

Для L2 домена можно внедрить L3 routing, путем добавления IRB интерфейса для влана в EVPN instance. Хосты будут использовать этот irb как default gateway.

Irb IP и MAC анонсируются остальным удаленным PE EVPNа путем Default Gateway Synchronization. Это полезно с той точки зрения, что все PE будут в курсе def Gateway и при переезде VM на другой PE, PE будет proxy arp от имени изученного def gateway и маршрутизировать трафик от VM напрямую к destination.

Таким же образом, через snooping ARP и DHCP пакетов, происходит заучивание ip-адресов хостов EVPN дата-центров. Называется это Host MAC/IP Synchronization'. После этого появляется возможность передавать трафик к PE, ближайшему к хосту дата-центр. Этот метод совместим в MAC migration.

Asymmetric IRB Forwarding: L2 заголовок перезаписывается ingress PE перед отправкой пакета. Это позволяет dest PE обойтись без L3 lookup, когда он производит передачу пакета.

• Уменьшение утилизации полосы пропускания для multi-destination трафика между разными частями дата-центра в разных местах.

• PE делают Proxy ARP: изучая ip хостов и def gateway.
• P2MP or MP2MP LSPs между сторонами дата-центров.

• Поддерживает инкапсуляцию разных данных.

Например, GRE tunnels с IPSEC.