Текущая версия на 18:35, 15 июля 2021

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.

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

Роутер 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

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

Кол-во VRF-таблиц может быть до 9000 в рамках одного роутера (кончено же зависит от платформы).

Кол-во маршрутов (в целом) сильно зависит от платформы, но на MX960 можно поддерживать до 1,5 млн.

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.

При использовании RR, на PE, получивших l2vpn, l3pvn маршруты, выбор активного пути (до RR) не будет опираться на стандартный BGP-алгоритм выбора best path. Для использования стандартного best path: l2vpn-use-bgp-rules

VRR не начнет передавать получить vpn маршруты от других RR, пока на локальном RR не появятся первые клиенты.

Схема: 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 (PE) <> blair (RR), blair (RR) <> oban (PE).

И обязательно, что бы RR делал next-hop self, без этого PE будет принимать VPN маршрут, но делать его unusable, т.к. indirect nexp-hop будет недоступен. И трафик пойдет тогда по LSP от PE к RR, потом по LSP от RR к PE.
Либо между PE потребуется иметь LPS (RSVP).

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

Позволить bgp.l3vpn.0 использовать другую (не inet.3) таблицу для resovle next-hop.

blair>
[edit routing-options]
resolution {
   rib bgp.l3vpn.0 { 
      resolution-ribs inet.0;

Между PE тогда должна быть LSP.

С помощью 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.

С использованием route target filtering: PE присылает RR список необходимых RT. RR применяет route filter и отправляет только соответствующие маршруты.

В family route-target (на PE) можно задавать параметры prefix-limit, external-paths, advertise-default.

При передаче маршрутов от RR, он меняет hext-hop и originator ID на свои.

Чтобы изменить такое дефолтное поведение на 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].

Реализация MPLS в ядре сети: различия между версиями

Текущая версия на 18:35, 15 июля 2021

Содержание

Core MPLS Designs

RSVP auto-mesh

LDP tunneling

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

Configuration

Проверка

MPLS Scaling

Hierarchical LSP

Configuration

Hierarchical RSVP Domains

RSVP Refresh reduction

L3VPN scaling

BGP Considerations

Route-reflection in VPN Environments

LDP

RSVP

BGP Route-target Family

VPLS

P2MP LSP

Configuration

Filtering BUM Traffic

Дополнительная информация

Навигация

Поиск