Реализация MPLS в ядре сети: различия между версиями
(→RR) |
|||
Строка 344: | Строка 344: | ||
import-rib [ inet.0 inet.3 ]; | import-rib [ inet.0 inet.3 ]; | ||
import-policy Loopbacks-Only; | import-policy Loopbacks-Only; | ||
===BGP Route-target Family=== |
Версия 14:13, 16 ноября 2016
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
BGP Considerations
RR
Route-reflection in VPN Environments
RR должен иметь MPLS label для любого PE, которому он будет передавать MPLS VPN маршруты. Иначе RR не сможет сделать валидными MPLS VPN маршруты, т.к. next-hop будет unusable и RR просто не будет передавать их остальным PE (no active).
Схема: blair - RR, lagavulin - PE1, oban - PE2. PE1 и PE2 передают маршруты RR.
LDP
При использовании LDP, нужно разрешить RR участвовать в LDP, чтобы обеспечить возможность делать resolve для next-hop в таблице inet.3.
При включении LDP на RR - проблема с unusable маршрутами исчезает.
RSVP
При использовании RSVP требуется LSP от КК до каждого 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;