Реализация MPLS в ядре сети: различия между версиями
м |
|||
Строка 1: | Строка 1: | ||
{{#description2:Дизайн и использование MPLS на ядре сети. RSVP auto-mesh. LDP tunneling. MPLS мастрабирование. L3VPN масштабирование. BGP Considerations для L3VPN. P2MP LSP. Информация для подготовки к экзаменам Juniper.}} | |||
=Core MPLS Designs= | =Core MPLS Designs= | ||
==RSVP auto-mesh== | ==RSVP auto-mesh== |
Версия 10:16, 5 июля 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].