segment-routing control-plane and data-plane
11.04 2020 | by massimilianoSegment-Routing funzionalità control-plane and data-plane Il segment-routing basa il suo piano di controllo (control-plane) su due protocolli IGP di […]
https://www.ingegnerianetworking.com/wp-content/uploads/2020/04/sr-control-plane-diagram-725.png
Segment-Routing funzionalità control-plane and data-plane
Il segment-routing basa il suo piano di controllo (control-plane) su due protocolli IGP di tipo link-state e precisamente ISIS ed OSPF
Il diagramma di cui sotto ne evidenzia le caratteristiche:
Il piano di forwarding si basa sul protocollo MPLS data-plane; il diagramma di cui sotto ne evidenzia la struttura:
Segment-Routing anche conosciuto come “SPRING” implementato nativamente attraverso un protocollo IGP-LS, ha la capacità di creare LSP attraverso delle label di tipo SR, senza avere la necessità di abilitare LDP.
Come alternativa a RSVP invece, SR non supporta un meccanismo di reservation bandwidth (path-state relativo al processo di instramento ERO e path-resv per la prenotazione di banda) ed in questo caso è possibile utilizzare un Controller Centrale e l’impiego del protocollo PCEP (Path Computation Element Protocol PCE-PCC)
Con Segment-Routing abbiamo questa analogia con MPLS “tradizionale”
- – Segment = label
- – Segment-list = label stack
- – Utilizzo della funzionalità di PHP (Penultimate Hop Popping) di default [ NP-flag = 0 ; E-flag = 0 ]
- – Explicit-Null può essere abilitato se utilizzato (ad esempio per EXP) [ NP-flag = 1 ; E-Flag = 1 ]
Quindi, un nodo di ingresso (head-end) impone (imposition) una prefix-sid label ad un pacchetto se:
- – la destinazione è se stesso oppure è il next-hop per quella data destinazione, oppure matches una FEC/subnet con un prefix-SID
- – il neighbor di tipo downstream è SR enabled
- – il nodo è configurato per preferire l’imposition di una label di tipo SR, oppure il matching di una FEC/Subnet non deve essere associata a nessuna LDP label
Nel grafico sopra tutti i nodi sono SR enabled.
Si riporta per una maggiore comprensione un traceroute, prima con un path tradizionale MPLS/LDP, eppoi con un path SR, andando a vedere analogie di comportamento ma con una significativa differenza per label distribuite nei due casi, di cui con la prima (LDP) abbiamo una assegnazione di etichetta in modo NON-deterministico, mentre con la seconda (SR) le label sono associate in modo deterministico al path segment di competenza:
1) traceroute con MPLS/LDP:
CE1#traceroute 192.168.2.2 source 192.168.1.1
Type escape sequence to abort.
Tracing the route to 192.168.2.2
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.1.1 4 msec 3 msec 4 msec
2 10.2.2.2 [MPLS: Labels 19/22 Exp 0] 17 msec 9 msec 9 msec
3 10.2.2.6 [MPLS: Labels 19/22 Exp 0] 29 msec 10 msec 9 msec
4 10.1.1.5 [MPLS: Label 22 Exp 0] 8 msec 8 msec 7 msec
5 10.1.1.6 9 msec 9 msec 7 msec
Le label 19 e 22 sono etichette associate dai rispettivi router attraverso la costruzione della tabella LIB (Label Information Base) ed indica rispettivamente la label remota ossia quella associata dal nodo (LSR) remoto alla FEC di pertinenza, poi la label locale ossia quella associata dal nodo (LSR) in modo locale sempre alla FEC.
Si riporta la LIB di interesse:
PE1#show mpls ldp bindings
lib entry: 10.255.255.20/32, rev 14
local binding: label: 22
remote binding: lsr: 10.255.255.1:0, label: 19
!
P1#show mpls ldp bindings
lib entry: 10.255.255.20/32, rev 14
local binding: label: 19
remote binding: lsr: 10.255.255.2:0, label: 19
remote binding: lsr: 10.255.255.10:0, label: 22
!
P2#show mpls ldp bindings
lib entry: 10.255.255.20/32, rev 14
local binding: label: 19
remote binding: lsr: 10.255.255.1:0, label: 19
remote binding: lsr: 10.255.255.20:0, label: imp-null
!
PE2#show mpls ldp bindings
lib entry: 10.255.255.20/32, rev 14
local binding: label: imp-null
remote binding: lsr: 10.255.255.2:0, label: 19
2) traceroute con MPLS/SR:
CE1# traceroute 192.168.2.2 source 192.168.1.1
traceroute to 192.168.2.2 (192.168.2.2) from 192.168.1.1 […]
1 10.1.1.1 4 msec 3 msec 4 msec
2 10.2.2.2 17 msec 9 msec 9 msec
MPLS Label = 16022 CoS=0 TTL=1 S=1
3 10.2.2.6 29 msec 10 msec 9 msec
MPLS Label = 16022 CoS=0 TTL=1 S=1
4 10.1.1.5 8 msec 8 msec 7 msec
5 192.168.2.2 9 msec 9 msec 7 msec
E’ interessante notare come la label SR = 16022 termini sempre per 22 ossia il Node-SID del PE2 e questo comportamento è totalmente differente dal precedente con LDP dove avevamo label assegnate in modo non-deterministico su base locale e remote dal punto di vista di ciascun nodo LSR, mentre nel Segment Routing ogni nodo LSR aggiunge una sub-TLV (in caso di ISIS) oppure una nuova LSA Opaque (in caso di OSPF) nel suo path Link-State creando cosi un LSP (Label Switch Path) end-to-end avendo sempre come riferimento il valore di Path Segment ID.
La Label 16022 è calcolata dalla regola SRGB-base (16000) + global node-sid (22), quindi 16000 + 22 = 16022
Questo nuovo “paradgma”, secondo me, aiuta molto anche nel troubleshooting
Segment-Routing per ISIS introduce il supporto dei seguenti sub-TLVs:
SR Capability sub-TLV (2) | ISIS Router Capability TLV (242) |
Prefix-SID sub-TLV (3) | Extended IP Reachability TLV (135) |
Prefix-SID sub-TLV (3) | IPv6 IP Reachability TLV (135) |
Prefix-SID sub-TLV (3) | Multitopology IPv6 IP Reachability TLV /237) |
Prefix-SID sub-TLV (3) | SID / Label Binding TLV (149) |
Adjacency-SID sub-TLV (31) | Extended IS Reachability TLV (22) |
LAN-Adjacency-SID sub-TLV (32) | Extended IS Reachability TLV (22) |
Adjacency-SID sub-TLV (31) | Multitopology IS Reachability TLV (222) |
LAN-Adjacency-SID sub-TLV (32) | Multitopology IS Reachability TLV (222) |
SID / Label Binding TLV (149) |
Segment-Routing per OSPF introduce il supporto delle seguenti nuove LSA Opaque
SR-Algorithm TLV (8) | Router Information Opaque LSA (Type 4) |
SID / Label Range TLV (9) | Router Information Opaque LSA (Type 4) |
OSPFv2 Extended Prefix TLV (1) | OSPFv2 Extended Prefix Opaque LSA (type 7) |
Prefix-SID sub-TLV (2) | OSPFv2 Extended Prefix Opaque LSA (type 7) |
OSPFv2 Extended Prefix TLV (1) | OSPFv2 Extended Prefix Opaque LSA (type 8) |
Adjacency-SID sub-TLV (2) | OSPFv2 Extended Prefix Opaque LSA (type 8) |
LAN-Adj-SID sub-TLV (3) | OSPFv2 Extended Prefix Opaque LSA (type 8) |
E’ importante capire anche la coesistenza di label di tipo SR con label di altro tipo ad esempio LDP a livello Control-Plane e Data-Plane
MPLS, ricordiamo, è un’architettura che permette l’utilizzo di multiple label distribution attraverso LDP, RSVP-TE e quindi SR può coesistere senza nessun tipo di interazione
Ogni nodo LSR che deve gestire la trasmissione su base label :
riserva un label range (SRGB) per il SR control-plane
assicura che tutte le label di tipo dinamico sono al di fuori del SRGB block
assicura che le label di tipo dinamico siano allocate in modo unico
le label di tipo incoming ad un nodo LSR siano interpretate in modo unico
SR e LDP possono coesistere per:
– MPLS-to-MPLS: operazioni di swap o label switching
– MPLS-to-IP: label disposition
Queste entries sono label di tipo index
la label locale/incoming possono essere gestite in modo unico tra loro da LDP e SR
la label di tipo outgoing ha solo significato per il downstream neighbor, non per il nodo locale
multiple MPLS2MPLS e MPLS2IP entries possono essere programmate per la stessa prefix
SR e LDP non possono coesistere per:
– multiple IP2MPLS entries, ad esempio LDP e SR, per la stessa prefix path
Queste label imposition forwarding entries sono di tipo index per prefix
Ogni path può avere un singolo IP2MPLS entry programmata
Se multipli paths guidano verso la destinazione, ciascun path deve avere la sua personale IP2MPLS entry (ad esempio un path con LDP ed un’altro path con SR label imposing)
ESEMPIO DI CONFIGURAZIONE LABEL-IMPOSITION E SIGNIFICATO:
Di Default LDP label imposition è preferito
router isis < process >
address-family ipv4 | ipv6
segment-routing mpls sr-prefer
router ospf < process >
segment-routing mpls
segment-routing sr-prefer
ESEMPIO DI CONFIGURAZIONE ISIS E SIGNIFICATO:
router isis < process >
address-famili ipv4 | ipv6 unicast
metric-style wide
segment-routing mpls
!
interface loopback0
address-family ipv4 unicast
prefix-sid index 22
Segment-Routing è abilitato sotto il processo ISIS
MPLS forwarding è abilitato in tutte le non-passive ISIS interface
Adjacency-SID sono allocate e distribuite per tutte le adiancenze
Con Juniper (esempio)
protocol
isis
source-packet-routing
node-segment ipv4-index 22
router isis
address-family ipv6 unicast
metric-style wide
segment-routing ipv6
!
interface loopback1
address-family ipv6 unicast
prefix-sid index 22
Segment-Routing è abilitato sotto il processo ISIS
SRv6 extension-header data-plane è abilitato
ESEMPIO DI CONFIGURAZIONE OSPF E SIGNIFICATO:
router ospf < process >
segment-routing mpls
segment-routing forwarding mpls questo comando dovrebbe essere di default abilitato nei router di ultima generazione e pertanto non più richiesto
Segment-Routing è abilitato sotto il processo OSPF (ma può essere customizzato)
MPLS forwarding è abilitato in tutte le sr-forwarding enabled OSPF interface
Adjacency-SID sono allocate e distribuite per sr-forwarding enabled adiacenze
ESEMPIO DI CONFIGURAZIONE SRGB (Segment Routing Global Block) E SIGNIFICATO:
il valore di default per cisco = 16000 – 23,999
non-default SRGB può essere configurato per IGP instance
multiple IGP instance può usare lo stesso SRGB oppure utilizzare differenti non-overlapping SRGB
SRGB può essere configurato in global configuration (IOS XR 6.0)
SRGB sotto IGP instance ha precedenza rispetto al SRGB configurato in global configuration
segment-routing
global-block 17000 18999
!
router ospf < process >
segment-routing mpls
!! no segment-routing global-block config
Questa configurazione permette un range di 2000 (size) con un non-default allocation per OSPF (stessa cosa vale per ISIS dove abbiamo il comando router isis < process > ) e le label allocate partono da 17000
In caso vogliamo avere una precedenza di labeling con SRGB la configurazione diventa:
segment-routing
global-block 17000 18999
!
router ospf < process >
segment-routing mpls
segment-routing global-block 19000 20999
Questa configurazione permette un range di 2000 (size) con un non-default allocation per OSPF e le label allocate partono da 19000
Per ISIS, SRGB è annunciato attraverso:
- – Router Capability TLV il quale contiene: il router-id (32 bits), flag (8 bits) e optional sub-TLV
- – Il TLV flag è cosi costituito:
S: = Scope : se settato significa che il valore TLV è trasmesso lungo il dominio di routing
D: = Down : se settato significa che il valore TLV è leaked from level-2 to level-1
- – I valori sub-TLV Routing Capability sono inclusi nel Router Capability TLV
- SR algorithm sub-TLV può essere incluso (no in IOS XR 5.3.2)
- – Router Capability sub-TLV contiene: il flag (b bits) ed uno o più SRGB descriptor
un SRGB descriptor contiene: range (24 bits), SID/Label (variabile, 32 bits se MPLS) ed indica l’inizio del SRGB
- – Il flag è costituito da due sub-TLV e precisamente:
- I: = IPv4 : se settato significa la capacità di un router di ” outgoing IPv4 encapsulation ” per tutte le interfacce
- V: = IPv6 : se settato significa la capacità di un router di ” outgoing IPv6 encapsulation ” per tutte le interfacce
Comando di verifica: show isis database verbose < node >
Verifica: Router Cap
Per OSPF, SRGB è annunciato attraverso:
– Router Information LSA
uno o più SID/Label range TLV (SRGB descriptors) sono inclusi nel Router Information Opaque LSA
SR algorithm TLV è incluso nel Router Information LSA
il SID/Label TLV contiene: il range size (24 bits) ed il SID/Label TLV (variabile, 32 bits se MPLS) che indicano l’inizio del SRGB
SR algorithm TLV contiene: una lista di identificatori (8 bit per identifier) utilizzato dal router
algorithm 0: shortest path fisrt (SPF) algorithm based on link metric
Comando di verifica: show ospf database opaque-area 4.0.0.0 self-originate
Verifica: Algorithm:
Verifica: Range Size:
Verifica: Label:
CONFRONTRO TRA LDP – RSVP-TE – SR
FUNZIONALITA’ | LDP | RSVP-TE | Segment-Routing SR |
Supporto Traffic-Engineering | NO | YES | with label stacking (NO BW reservation) |
Nativamente supportato da un IGP Link-State | NO | NO | YES |
Supporto di P2MP LSP | YES | YES | Not Yet (al momento di questa scrittura) |
Configurazione | Easy | with Auto-Tunnel | SID Provisioning |
Control Plane Load | Low | per-LSP state | Null |
Deterministic Label | NO | NO | per Global Segment |
MAPPING SERVER FUNZIONALITA’
Un Mapping Server è comparabile con la funzione di un BGP Route Reflector
- Mapping Server è un meccanismo control-plane
- Mapping Server non è ” posizionato ” lungo il data-path
- Mapping Server deve essere resiliente ed in HA
Un Mapping Client ha le seguenti funzionalità:
riceve ed analizza un prefix-to-sid mapping dal Mapping Server
- localmente configura una serie di entries per costruire un valido e consistente Active SID Mapping Policy; mapping non selezionate per un Active Policy vanno inserite in una Backup Policy
- IGP instance utilizzano l’Active SID Mapping Policy per calcolare il prefix-SID di alcune oppure tutte le Prefix
- Da un punto di vista del design, se un Mapping Server è in uso, tutti i nodi dovrebbere essere Mapping Client per ricevere i prefix-to-sid mapping, in modo tale da non dover ricevere le stesse informazioni via link-state advertisement da altri non non-SR enabled
Alcune note aggiuntive sulle funzionalità Mapping-Server (by Cisco):
Prefix-SID ricevuti via Mapping Server hanno un ” implicit PHP OFF “; questo significa che il Penultimate Hop non farà l’operazione di pop per la label prefix-sid in questione
il pacchetto arriva alla destinazione con prefix-sid label on top
il pacchetto con prefix-sid on top label richiede due label lookup presso il nodo ricevente per la trasmissione del pacchetto: top-label lookup, pop top-label, address lookup
In IOS-XR nessuna mpls forwarding entry è installata per un local-prefix-SID: pacchetti con local prefix-SID on top label sono scartati (drop)
ISIS: Mapping Server advertisment sono (per il momento) non propagate tra livelli: un Mapping Server è necessario per ISIS area
OSPF: Mapping Server advertisement sono propagate tra aree
ESEMPIO DI CONFIGURAZIONE MAPPING-SERVER:
segment-routing
mapping-server
prefix-sid-map
address-family ipv4 | ipv6
< prefix > / < mask > < first-SID-value > range < range >
[ … ]
Ogni linea sotto ” prefix-sid-map ” genera una prefix-to-sid mapping advertisment
router isis < process >
address-family ipv4 | ipv6 unicast
segment-routing prefix-sid-map advertise-local
oppure
router ospf < process >
segment-routing prefix.sid-map advertise-local
- – advertise-local: significa che il processo IGP annuncia il mapping prefix-SID
- – receive: è abilitato di default
ESEMPIO DI UNA CONFIGURAZIONE IN GRAFICA
Mapping Server Config Option:
CONFIGURATION | ADVERTISE LOCAL POLICY | COMPUTE ACTIVE POLICY |
receive (default) | NO |
ignore local mapping use remote mapping |
advertise-local (+ receive disable) |
YES |
use local mapping ignore remote mapping |
receive (+ advertise-local) |
YES |
use local mapping use remote mapping |
Per ISIS, prefix-to-SID mapping è annunciato attraverso:
Ogni blocco di prefix-to-SID mapping è codificato in un TLV separato
ISIS SID/Label Binding TLV ha i seguenti Flag:
F: address-family = unset: IPv4 ; set: IPv6
M: mirror context = set se il SID/path corrisponde ad un contesto mirrored
S: scope = se unset il valore TLV non è propagato tra levels
D: down = set se il valore TLV è leaked dal level-2 to Level-1
A: attached = set se la prefix e SID sono direttamente connessi al loro noro originator
N: node-sid = set se la prefix-sid rappresenta un node-SID (ad esempio identifica il nodo)
Per OSPF, prefix-to-SID mapping è annunciato attraverso:
prefix-to-SID mapping è annunciato in un Extended Prefix LSA Opaque Type 7
in questo LSA il prefix-to-SID mapping è codificato attraverso un range TLV costituito dai seguenti Flag:
IA: inter-area = set se l’annuncio è di tipo inter-area, utilizzato per prevenire redundant flooding tra areas
NP: no-PHP = set se il penultimate hop non deve esegiore l’operazione di POP prefix-SID prima di trasmettere il pacchetto
M: mapping-server = set se il valore di SID è annunciato attraverso la funzionalità di Mapping Server
E: explicit-null = set se il penultimate hop deve sostituire il prefix-SID con una explicit-null label
V: value = set se il prefix-SID trasporta un valore non come index (IOS XR è sempre unset)
L: local = set se il prefix-SID fa un significato locale (IOS XR è sempre unset)
Mapping entry preference:
Se un Mapping Client riceve due o più overlapping mapping ranges, seleziona una prefix-SID basata su una regola di preferenze:
1) largest router-id (OSPF) or system-ID (ISIS) è preferito
2) smallest area-id (OSPF) or level (ISIS) è preferito
3) IPv4 range è preferito rispetto IPv6 range
4) smallest prefix length è preferito
5) smallest IP address è preferito
6) smallest SID index è preferito
7) smallest range è preferito
8) il primo range ricevuto è preferito