Просмотр кода страницы Реализация MPLS в ядре сети

=Core MPLS Designs=
==RSVP auto-mesh==
Когда на сети используется RSVP, но для конкретных функций (L3VPN, VPLS, ...) требуется full-mesh, то чтобы не прописывать все LSP руками, можно использовать '''RSVP-full-mesh'''.

Строится, когда: 
* От PE пришел iBGP маршрут (inet.0, VPLS, L3VPN)
* IP PE из определенного диапазона.
 [edit routing-options]
 dynamic-tunnels {
    tunnel-1 {
        rsvp-te tunnel-1 {
            label-switched-path-template {
                default-template;
            }
            destination-networks {
                10.200.86.0/26;

В книге описано, что просто туннель не поднимется (лаба на mx80), т.к. требуется маршрут до Lo PE с меткой в inet.0. '''Решение:''' Нужно временно включить LDP и set protocols mpls traffic-engineering bgp-igp-both-ribs'', ждем пока построятся RSVP LSP, потом отключаем LDP.

Но по факту в лабе завелось и без дополнительных манипуляций с LDP (лаба на vSRX). =)

В итоге, когда приходят пакеты по iBGP, то до ''protocol next-hop'' (Lo PE, который должен попадать в dest-networks) автоматически поднимается туннель.
 '''bgp.l3vpn.0''': 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both
 ''10.200.86.3:1212:12.12.12.12/32''
                   *[BGP/170] 12:34:36, localpref 100, from 10.200.86.3
                      AS path: I
                    > to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.3:dt-rsvp-tunnel-1'''

 '''bgp.l2vpn.0''': 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both
 ''10.200.86.9:1515:1:1/96''
                   *[BGP/170] 12:16:54, localpref 100, from 10.200.86.9
                      AS path: I
                    > to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.9:dt-rsvp-tunnel-1'''

 '''inet.3''': 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both
 10.200.86.0/26     *[Tunnel/300] 12:10:07
                      Tunnel
 ''10.200.86.3/32''     *[RSVP/7/3] 00:03:04, metric 4
                    > to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.3:dt-rsvp-tunnel-1'''
 ''10.200.86.9/32''     *[RSVP/7/3] 00:03:04, metric 5
                    > to 192.168.86.1 via ge-0/0/0.30, label-switched-path '''10.200.86.9:dt-rsvp-tunnel-1'''


 lagavulin> show mpls lsp name '''10.200.86.3:dt-rsvp-tunnel-1''' detail
 Ingress LSP: 2 sessions
 10.200.86.3
  From: 10.200.86.7, State: Up, ActiveRoute: 0, LSPname: 10.200.86.3:dt-rsvp-tunnel-1
  ActivePath:  (primary)
  PathDomain: Inter-domain
  LSPtype: '''Dynamic Configured'''
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary                    State: Up
    Priorities: 7 0
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4)
 192.168.86.1 S 192.168.86.41 S 192.168.86.50 S 192.168.86.25 S
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          192.168.86.1 192.168.86.41 192.168.86.50 192.168.86.25

*Можно добавлять разные фичи TE:
 [edit protocols mpls]
 label-switched-path default-template {
    template;
    link-protection;

*Если до одного и того же Lo PE есть динамический и статический LSP, то будет выбран статический, т.к. у него ''preference 2'' меньше:
 inet.3: 3 destinations, 4 routes (3 active, 0 holddown, 0 hidden)
 10.200.86.3/32     *[RSVP/7/'''[[1]]'''] 00:00:26, metric 4
                    > to 192.168.86.1 via ge-0/0/0.30, label-switched-path lagavulin-to-oban
                    [RSVP/7/'''[[3]]'''] 00:02:32, metric 4
                    > to 192.168.86.1 via ge-0/0/0.30, label-switched-path 10.200.86.3:dt-rsvp-tunnel-1
*Если по iBGP перестают прилетать маршруты, то туннель через 15 минут умрет: 
 lagavulin> show dynamic-tunnels database
 Table: inet.3
 Destination-network: 10.200.86.0/26
 Tunnel to: 10.200.86.9/32 ('''expires in 00:14:46 seconds''')
  Reference count: 0
  Next-hop type: rsvp-te
    10.200.86.9:dt-rsvp-tunnel-1

==LDP tunneling==
Комбинация LDP и RSVP. Core - RSVP + TE, доступ - LDP.

===Процесс построения===

[[Файл:ldp_tunneling.png]]
* Роутер A (PE) - LDP. Egress: начинает анонсировать себя с меткой 3 в сторону B.
* Роутер B (PE) - LDP + RSVP. Анонс LoA с меткой 20 в сторону C. B: '''mpls.0''': 20 pop -> A
* Роутер C (P)  - RSVP (с LDP-tunneling). Анонс LoA с меткой 30 в сторону E. С: '''mpls.0''': 30 swap 20 -> B.
* Роутер D (P)  - между E<>C - RSVP LSP, где D - предпоследний роутер.
* Роутер E (P)  - LDP + RSVP. Анонс LoA с меткой 40 в сторону F. E: '''mpls.0''': 40 swap 30 -> C. Но C не direct connected, а доступен через туннель => идем смотреть в inet.3. E: '''inet.3''': LoC push 100 -> D. => E: '''mpls.0''': 40 swap 30 push 100
* Роутер F (PE) - LDP. Ingress: '''inet.3''': LoA: push 40 -> E.

В обратную сторону строится точно также.

Когда туннель построен, между ingress (C) и egress (E) роутерами RSVP LSP установится LDP соседство! Устанавливается по UDP 646 на Lo P (''берется из конфигурации туннеля''), ''не hello механизм, но тоже работает’’.

Обязательно на P роутерах включить в LDP Lo, чтобы поднялся туннель C - E.

Схема работает только в пределах области.

При включенном LDP tunneling будут видны скрытые маршруты в inet.3

Можно использовать, когда не все устройства в сети поддерживают RSVP, но на ядре требуется TE. Также TE как таковой не требуется вообще на PE, нужно только на ядре, на P роутерах. Поэтому RSVP можно запустить только на ядре, а PE будут подцепляться по LDP.

При конфигурации может возникнуть проблема с переносом маршрутов из inet.3 в inet.0 (на PE роутерах). Решается как обычно: ''set protocols mpls traffic-engineering bgp-ibgp-both-ribs''. Или любым другим способом.

===Configuration===
[[Файл:ldp_tunneling_laba.png]]

'''PE (LDP + RSVP)''':
 [protocols mpls]
    traffic-engineering bgp-igp-both-ribs;
    label-switched-path talisker-to-oban {
       to 10.200.86.3;
       ldp-tunneling;
 [protocols ldp]
    interface ge-0/0/0.70;
    interface ge-0/0/0.120;
    interface all;
'''С другой стороны на PE''':
 [protocols mpls]
    traffic-engineering bgp-igp-both-ribs;
    label-switched-path oban-to-talisker {
       to 10.200.86.4;
       ldp-tunneling;

===Проверка===
Между крайние PE,  на которых настроено туннелирование, установили соседство между собой по LDP:
 talisker> show ldp neighbor
 Address            Interface          Label space ID         Hold time
 10.200.86.3        lo0.0              10.200.86.3:0            42

На PE, к которому подключается CE:
 macduff> show route 10.200.86.1
 inet.0: 30 destinations, 40 routes (30 active, 0 holddown, 0 hidden)
 10.200.86.1/32     *[LDP/9] 00:19:03, metric 1
                    > to 192.168.86.13 via ge-0/0/0.70, Push 300016
                    [OSPF/10] 00:19:03, metric 4
                    > to 192.168.86.13 via ge-0/0/0.70

 talisker> show route label 300016 detail
 mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
 300016 (1 entry, 1 announced)
        *LDP    Preference: 9
                Next hop type: Router, Next hop index: 548
                Address: 0x934c3b8
                Next-hop reference count: 2
                Next hop: 192.168.86.33 via ge-0/0/0.120 weight 0x1, selected
                Label-switched-path talisker-to-oban
                Label operation: Swap 299776, Push 299968(top)
                Label TTL action: prop-ttl, prop-ttl(top)
                State: <Active Int NhAckRequest>
                Local AS:  1111
                Age: 19:37      Metric: 1
                Task: LDP
                Announcement bits (1): 0-KRT
                AS path: I
                Prefixes bound to route: 10.200.86.1/32

 tormore> show route label 299968 detail
 mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden)
 299968(S=0) (1 entry, 1 announced)
        *RSVP   Preference: 7/1
                Next hop type: Router, Next hop index: 581
                Address: 0x934d258
                Next-hop reference count: 2
                Next hop: 192.168.86.38 via ge-0/0/0.130 weight 0x1, selected
                Label-switched-path talisker-to-oban
                Label operation: Pop
                State: <Active Int AckRequest>
                Local AS:  1111
                Age: 1:09:29    Metric: 1
                Task: RSVP
                Announcement bits (1): 0-KRT
                AS path: I

 oban> show route label 299776 detail
 mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
 299776 (1 entry, 1 announced)
        *LDP    Preference: 9
                Next hop type: Router, Next hop index: 544
                Address: 0x934c568
                Next-hop reference count: 2
                Next hop: 192.168.86.26 via ge-0/0/0.110, selected
                Label operation: Pop
                State: <Active Int>
                Local AS:  1111
                Age: 26:53      Metric: 1
                Task: LDP
                Announcement bits (1): 0-KRT
                AS path: I
                Prefixes bound to route: 10.200.86.1/32
=MPLS Scaling=
==Hierarchical LSP==
Иерархичные LSP позволяют роутеру воспринимать core-to-core линки, как физические интерфейсы.
То есть протокол IGP может анонсировать метрики и TE характеристики LSP, как обычного интерфейса.

Для внедрения иерархичных LSP требуется OSPF.

===Configuration===
*LSP задаём, как te-link - это даёт возможность другим роутером увидеть данный линк внутри TED
*Конфигурируем логический интерфейс.
*Link-management
Вся конфигурация задается только на P роутерах.

 lagavulin> show configuration protocols 
 rsvp {
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
    peer-interface peer-talisker;
 }
 mpls {
    label-switched-path lagavulin-to-talisker {
    to 10.200.86.4;
  }
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
  }
 ospf { 
    traffic-engineering;
    area 0.0.0.0 {
    interface lo0.0 {
       passive;
    interface ge-0/0/1.0
    interface ge-0/0/2.0;
    peer-interface peer-talisker;
 link-management {
    te-link lagavulin-to-talisker-te {
       local-address 192.168.87.1;
       remote-address 192.168.87.2;
       te-metric 1;
       label-switched-path lagavulin-to-talisker;
    peer peer-talisker {
       address 10.200.86.4;
       te-link lagavulin-to-talisker-te;

*Для самого туннеля задаются отдельные ip: конечный и начальный (как у любого туннеля). 
*Te-metric - та самая метрика, которая будет сравниваться при построении кратчайшего пути
 lagavulin> show link-management 
 Peer name: peer-talisker, System identifier: 55629
    State: Up, Control address: 10.200.86.4
    Hello interval: 150, Hello dead interval: 500
       TE links:
           lagavulin-to-talisker-te
  TE link name: lagavulin-to-talisker-te, State: Up
     Local identifier: 2684274792, Remote identifier: 2684274792,
     Local address: 192.168.87.1, Remote address: 192.168.87.2, Encoding: Packet,
     Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 0bps,
     Total bandwidth: 0bps, Available bandwidth: 0bps
         Name                         State Local ID Remote ID Bandwidth Used LSP-name
         lagavulin-to-talisker Up     14956    0            0bps               Yes '''dalwhinnie-to-tormore'''
В итоге видим, что ''dalwhinnie-to-tormore'' туннелируется в ''lagavulin-to-talisker''.
 dalwhinnie> show mpls lsp name dalwhinnie-to-tormore detail 
    Ingress LSP: 1 sessions
    10.200.86.9
    From: 10.200.86.5, State: Up, ActiveRoute: 0, LSPname: dalwhinnie-to-tormore
    ActivePath: (primary)
    LoadBalance: Random
    Encoding type: Packet, Switching type: Packet, GPID: IPv4
      *Primary State: Up
      SmartOptimizeTimer: 180
      Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 60)
      192.168.86.29 S '''192.168.87.2''' S 192.168.86.33 S 
      Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt):
      192.168.86.29 192.168.87.2 192.168.86.33
      Total 1 displayed, Up 1, Down 0

На роутере, где будет настроен и начинаться hierarchical LSP будет делаться дополнительный ''push'' метки, для прохождения пакета внутри hierarchical LSP.

Причём на P роутере, транзитном для hierarchal LSP, не будет никакой информации о LSP, вложенном в hierarchical LSP. В этом, наверное и заключается основное преимущество метода - '''масштабируемость'''.

==Hierarchical RSVP Domains==
Смысл: разбить путь прохождения пакета на части: PE-P, P-P, P-PE LSP.

PE имеют RSVP-TE LSP до ближайших P роутеров. Между Р роутерами - full-mesh.

При таком подходе нельзя использовать MPLS VPN сервисы, т.к. Пропадает целостность РЕ-РЕ LSP.

Но такой подход даёт возможность использовать совмещённый LDP+RSVP.

Использовать функции ТЕ в сore и различные механизмы защиты (link-protection, link-node-protection).

==RSVP Refresh reduction==
Для решения проблем с масштабируемостью в самом протоколе RSVP, были сделаны несколько дополнений:
*'''reliable messages''': внедрены 2 новых объекта MESSAGE_ID, MESSAGE_ID_ACK.
*'''boundle messages''': группировка/объединение уже существующих сообщений RSVP.
*'''summary refresh update''': объединяет несколько path или resv  сообщений в один  update.
  [edit protocols rsvp]
    Interface ge-0/0/0.120
    Aggregate
=L3VPN scaling=
==BGP Considerations==
===Route-reflection in VPN Environments===
RR должен иметь LSP до любого PE, которому он будет передавать MPLS VPN маршруты. Иначе RR не сможет сделать валидными MPLS VPN маршруты, т.к. next-hop будет unusable и RR просто не будет передавать их остальным PE (''no active'').

В качестве RR лучше делать P роутеры.

На RR не требуется конфигурация самих VRF, RR просто должны уметь работать с MPLS VPN маршрутами (family inet-vpn). ''keep all'' будет включен при включении Cluster ID.

PE роутеры буду фильтровать полученные маршруты по RT. От RR будут прилетать все маршруты из ''bgp.l3vpn.0''.

Чтобы без дополнительных действий происходило обновление маршрутов на RR, требуется использовать '''refresh''': BGP-speaker просит обновить все NLRI.

Схема: blair - RR, lagavulin - PE1, oban - PE2.
PE1 и PE2 передают маршруты RR. 
====LDP====
При использовании LDP, нужно разрешить RR участвовать в LDP, чтобы обеспечить возможность делать resolve для next-hop в таблице inet.3.

При включении LDP на RR - проблема с unusable маршрутами исчезает.
====RSVP====
При использовании RSVP требуется LSP от RR до каждого PE.

Требуется создать LSP: lagavulin <> blair, blair <> oban.

Либо можно заставить RR думать, что у него есть LSP до PE. 

* Позволить ''bgp.l3vpn.0'' использовать другую (не inet.3) таблицу для resovle next-hop.
 blair>
 [edit routing-options]
 resolution {
    rib bgp.l3vpn.0 { 
       resolution-ribs inet.0;
* С помощью rib-groups скопировать маршруты из inet.0 в inet.3
 blair>
 [edit routing-options rib-groups inet.0-to-inet.3]
    import-rib [ inet.0 inet.3 ];
 [edit protocols ospf rib-group]
    inet.0-to-inet.3;

Чтобы не все маршруты, а только /32 попадали в inet.3, можно сделать следующее
 routing-options { 
   rib inet.3 {
      static {
         route 0.0.0.0/0 discard;
Или с помощью policy решить эту же проблему:
 policy-options policy-statement Loopbacks-Only 
    term Loopbacks {
       from {
          route-filter 10.200.86.0/24 prefix-length-range /32-/32;
       then accept; 
    term Reject-All-Else { 
       then reject;

 routing-options 
    rib-groups {
       inet.0-to-inet.3 {
          import-rib [ inet.0 inet.3 ]; 
          import-policy Loopbacks-Only;

===BGP Route-target Family===
По дефолту при создании L3VPN, L2VPN, РЕ роутер будет пересылать маршруты о своих VPN по всей сети. Удаленный PE будет получать все маршруты, но использовать только те, которые подходят по созданные на нем VPN.

Чтобы изменить такое дефолтное поведение на PE добавляем ''family route-target'': 
 tormore>  
 [edit protocols bgp group ibgp] 
 type internal; 
 local-address 10.200.86.9; 
 family inet-vpn {
    unicast; }
 family route-target; 
 neighbor 10.200.86.7; 
 neighbor 10.200.86.3;  
 neighbor 10.200.86.5;

'''Проверка'''
 tormore> show route table bgp.rtarget.0
 bgp.rtarget.0: 2 destinations, 5 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both
 1:1:1/96
               *[BGP/170] 00:01:58, localpref 100, from 10.200.86.3 
                  AS path: I
               > to 192.168.86.38 via ge-0/0/3.0
               [BGP/170] 00:01:54, localpref 100, from 10.200.86.5
                  AS path: I
               > to 192.168.86.38 via ge-0/0/3.0, Push 100496
               to 192.168.86.34 via ge-0/0/2.0, Push 655505 
               [BGP/170] 00:02:03, localpref 100, from 10.200.86.7
                  AS path: I
               > to 192.168.86.34 via ge-0/0/2.0, Push 655489
 '''1:2:2/96'''
               *[RTarget/5] 00:02:15 
                  '''Local'''
               [BGP/170] 00:01:54, localpref 100, from 10.200.86.5 AS path: I
               > to 192.168.86.38 via ge-0/0/3.0, Push 100496
                 to 192.168.86.34 via ge-0/0/2.0, Push 655505

'''Local''' обозначает, что локальный роутер также импортирует маршруты с 2:2 target. Таким образом РЕ видит каким удаленным РЕ какие VPN маршруты стоит отправлять.

==VPLS==
===P2MP LSP===
В случае использования P2P LSP, source PE должен расплодить несколько копий трафика и послать по разным LSP.

В случае использования P2MP: source PE отправляет трафик, копирование трафика происходит на определенном роутере, на котором происходит дальнейшее разветвление путей передачи трафика (''branch point'').

Таким образом уменьшится число копий трафика в сети. Копирование будет происходить только на ''branch points''. Понятно, что при внедрении VPLS может быть много точек, поэтому будет логично использовать P2MP.

Для VPLS внедрение P2MP делается внутри routing-instance.
=====Configuration=====
Здесь не описано, но дополнительно требуется создать p2mp LSP между PE роутерами. 

Описание настройки есть здесь: http://juniper-exam.ru/index.php/%D0%93%D0%BB%D0%B0%D0%B2%D0%B0_2._Label_Distribution_Protocols_(RSVP,_LDP)#P2MP
 dalwhinnie> show configuration routing-instances oak 
 instance-type vpls;
 interface ge-1/0/0.0;
 route-distinguisher 10.200.86.1:100;
 '''provider-tunnel''' { 
    rsvp-te {
       label-switched-path-template { 
          default-template;
 vrf-target target:300:200; 
 protocols {
    vpls {
       site-range 5; 
       no-tunnel-services;
       site oak-ce1 {
          site-identifier 1;
          interface ge-1/0/0.0;

''default-template'' можно заменить на свой, указав желаемые параметры для LSP.

===Filtering BUM Traffic===
Еще один способ уменьшить количество трафика Layer 2 broadcast, unknown unicast и multicast traffic - создать ''firewall family vpls filter'' и применить его [edit routing-instance oak forwarding-options family vpls].