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:

 

sr control plane diagram

 

 

  

Il piano di forwarding si basa sul protocollo MPLS data-plane; il diagramma di cui sotto ne evidenzia la struttura:

 

 

sr data plane diagram

 

 

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 ]

 

sr global segment path

  

 

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:

 

ldp traceroute example

 

 

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:

 

  sr traceroute 1

 

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

 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

 

 

label imposition sr ldp ex1

 

 

 

 

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

 

 

architet mapping server

 

 

 

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

 

config mapping server example

 

 

 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

 

 

mapping server client prefix sid non overlapp