analisi flusso di traffico in un backbone mpls ip considerando metric IT CSPF RSVP link protection node protection

Home » Blog » Routing » mpls » mpls Traffic-Engineering » analisi flusso di traffico in un backbone mpls ip considerando metric IT CSPF RSVP link protection node protection

analisi flusso di traffico in un backbone mpls ip considerando metric IT CSPF RSVP link protection node protection

27.01 2020 | by massimiliano

Il documento mette in evidenza uno studio ed ipotesi di flusso di traffico all’interno di una struttura backbone MPLS-IP in […]


https://www.ingegnerianetworking.com/wp-content/uploads/2020/01/analisi-TE-link-91c.png

Il documento mette in evidenza uno studio ed ipotesi di flusso di traffico all’interno di una struttura backbone MPLS-IP in considerazione di parametri quali:

 

metrica IT

CSPF

RSVP

metodi di protezione su base: link-protection and node-protection

Il design del backbone preso in considerazione presenta router MX960 Juniper come PE (Provider Edge) e CRS Cisco come P (router di transito)

 

analisi TE link

 

 

EDGE: MX960 JUNIPER Networks con ruolo di router PE sorgente e destinazione di flussi di traffico

CORE: CRS CISCO System con ruolo di router di transito.

 

 

Considerazioni a livello fisico:


costo (metrica IT) è data dalla seguente configurazione:

  interfaccia di collegamento link = TenGigEth = 10 Gbit/s

  auto-cost reference bandwith 100000 = reference bandwith = 100000 Mbit = 100.000.000.000 / 10.000.000.000 = cost = 10

metrica IGP = metrica IT

la banda per ciascun link backbone è identica = 10 Gbit/s

nel grafo con il parametro <1,10> si intende metrica = 1 , BW = 10 (10 Gbit/s)

 

 

ipotesi: flusso di traffico da POP 12 e POP 56 (come da diagramma seguente)

 

analisi TE link 2

 

Considerazioni:

 

la banda di 10 Gbit/s omogenea per tutto il backbone dovrebbe garantire qualunque richiesta da parte del flusso di traffico sorgente in termini di banda disponibile e/o altri parametri che possono influenzare il suo instradamento; per parametri si intendono ad es. banda equivalente, priorità, recupero in caso di guasto, qos, etc…

Nel nostro caso i parametri che prenderemo in considerazione sono metrica IT e banda disponibile.

 

I tunnel TE sono in configurazione dinamica (algoritmo CSPF constrained shortest path first)

Caratteristiche di funzionamento dell’algoritmo CSPF:

obiettivo principale è la selezione di un solo path tra nodo sorgente e nodo destinazione

viene applicato dal nodo di ingresso del flusso di traffico su base metrica IT minima e massimo valore di banda disponibile

eliminazione dalla topologia di rete i collegamenti che non soddisfano i vincoli (ad esempio il vincolo di banda); nel nostro caso però abbiamo supposto che una banda = 10 Gbit/s riesca a soddisfare il vincolo.

 

Altra nota importante da sottolineare è che se entrambi i router MX960 operassero contemporaneamente ci troveremmo ad avere due LSP indipendenti tra loro (i nodi sorgente del tunnel IT sarebbero diversi) in cui entrambi i tunnel TE sarebbero interessati al trasporto del flusso di traffico.

Si evince che per ogni coppia di router MX960 IDC uno solo ha il ruolo di primario mentre l’altro ha ruolo di router secondario (backup)

 

Per convenzione in questo documento si ipotizza:

MX960-PE1 : router primario

MX960-PE2 : router secondario

 

Il percorso selezionato dall’algoritmo on-line CSPF è il primo LSP [ PE1 → P1 → P5 → PE5 ]; tutti gli altri percorsi avrebbero metrica IT maggiore rispetto a 30.

 

 

Segnalazione: RSVP TE

 

Le principali caratteristiche funzionali sono:


prenotazione di banda unidirezionale tra sorgente e destinazione per un determinato flusso di traffico

soft state signaling: continui rinfreschi su stati di prenotazione per un certo periodo di tempo, scaduto il quale viene cancellato

la prenotazione di banda avviene attraverso messaggi di segnalazione Path e Reservation State, di cui:

 

  • – PATH STATE: relativo al processo di instradamento
  • – RESV STATE: relativo al processo di prenotazione della banda

 

 

analisi TE link 3 

 

 

ipotesi: Link e Node Protection:

 

Eventuali fault a livello di link e nodi è bene prevederli, e nel caso del flusso di traffico tra il POP12 ed il POP 56, potrebbero verificarsi i seguenti fault:

 

PE5 : caso di node protection

link di collegamento PE5 ↔ P5 : caso di link protection

 

P5: caso di node protection

link di collegamento P5 ↔ P1 : caso di link protection

 

P1 : caso di node protection

link di collegamento P1 ↔ PE1 : caso di link protection

 

vediamo di analizzarli uno per uno.

 

 

1) Fault: PE5 node protection

 

 

analisi TE link 4

 

Configurazione PE1:


protocols

 ospf

   traffic-engineering

    reference-bandwidth 10g

   area 0.0.0.0

   interface ae0.0

   interface lo0.0

     passive

 }

   interface xe-3/0/0.0

   interface xe-2/0/0.0

     bfd-liveness-detection

        minimum-interval 200

        multiplier 3

!

rsvp

  interface all

      link-protection

!

mpls

  icmp-tunneling

  optize-timer 30

 label-switched-path POP12_to_POP56

    to < loopback-PE5>

    primary PE5-primary

    strict

!

  label-switched-path POP12_to_POP56_backup

   to <loopback-PE6>

   secondary PE6-secondary

   loose

!

 

Il Nodo PE5 è in fault:

 

il router di backup PE6 diventa active (attraverso un meccanismo di ridondanza come vrrp);

al momento dell’evento riparte una nuova segnalazione RSVP per ristabilire un LSP#2 di backup per raggiungere la destinazione, pertanto il PE1 (POP12) invia una nuova sequenza di “path label request”, a questa richiesta risponde il PE6 router che ha conoscenza della destinazione in oggetto (20.20.20.0) con dei pacchetti “resv – label”;

appena il PE1 riceve il pacchetto “resv” instaura il secondo LSP di backup;

Il node P5 commuta (swap) la label da 10 a 21 e direziona il traffico verso il nodo PE6; quest’ultimo farà un’operazione di pop ed inoltra il traffico verso il nodo di destinazione

 

Tempi di convergenza: tempi del fast-reroute dell’ordine di msec.

 

A livello di Core nessuna configurazione di tunnel TE è necessaria.

A livello di Edge, sulla configurazione del tunnel dinamico in modalità strict va aggiunto il comando fast-reroute e sull’interfaccia di output il comando link-protection:

 

  label-switched-path POP12_to_POP56

    to < loopback-PE5>

    node-link-protection

    fast-reroute

 

Appena il fault si ripristina, LSP#1 viene ristabilito in quanto a metrica migliore (minor hop)

 

 

2) Fault: Link Protection PE5 – P5:

 

analisi TE link 5

 

il nodo PE5, attraverso un meccanismo di convergenza (vrrp) con tracciamento della sua interfaccia di output si accorge del fault sul proprio link e con un decremento della sua priority vrrp rende attivo il nodo PE6

la modalità di ricalcolo LSP#2 di backup è identica alla prima ipotesi.

 

Tempi di convergenza: tempi del fast-reroute dell’ordine di msec.

A livello di Core nessuna configurazione di tunnel TE è necessaria.

Appena il fault si ripristina, LSP#1 viene ristabilito in quanto a metrica migliore (minor hop)

 

 

3) Fault: P5 node protection

 

 

analisi TE link 6

 

il nodo PE5, attraverso un meccanismo di convergenza (vrrp) con tracciamento della sua interfaccia di output si accorge del fault sul proprio link del nodo P5 e con un decremento della sua priority vrrp rende attivo il nodo PE6;


anche il link di collegamento PE5 ↔ P1 è interessato al fault del nodo di P5; gli LSP di prima vengono interrotti ed una nuova segnalazione RSVP è necessaria per stabilire un nuovo LSP#3 di backup;

 

un’ulteriore ridondanza può essere considerata, pensando di configurare sul nodo di backbone adiacente (P1) al PE1 sorgente di traffico, un tunnel TE verso il nodo di backbone non adiacente (in questo caso il nodo P6); la segnalazione CR-LDP per TE presente nei router CRS cisco di backbone prevede la possibilità di stabilire sessioni multi-hop tra LDP peer non adiacenti. (RSVP TE è permesso via RRO record- route)

 

 

analisi TE link 7

 

Example Config:

 

 

PE1 (CRS-1):

 

router ospf < process >
 nsr
 log adjacency changes
 router-id < rid >
 bfd minimum-interval 200 
 bfd multiplier 3
 timers throttle lsa all 10 100 5000
 timers throttle spf 10 100 5000
 auto-cost reference-bandwidth 100000 
 address-family ipv4 unicast
 area 0
  mpls traffic-eng
  interface Bundle-Ether1
  !
  interface Loopback0
  passive enable
  !
  interface TenGigE0/0/0/0
  bfd fast-detect
  !
  interface TenGigE0/0/0/2
  bfd fast-detect
  !
  interface TenGigE0/0/0/3
  bfd fast-detect
  !
mpls traffic-eng router-id Loopback0

!

rsvp
  interface Bundle-Ether1
  bandwidth
  signalling dscp 48
  signalling rate-limit
  signalling rate-limit rate 200 interval 1000
!
  interface TenGigE0/0/0/0
  bandwidth
  signalling dscp 48
  signalling rate-limit
  signalling rate-limit rate 200 interval 1000
!
  interface TenGigE0/0/0/2
  bandwidth
  signalling dscp 48
  signalling rate-limit
  signalling rate-limit rate 200 interval 1000
!

mpls traffic-eng
  interface Bundle-Ether1
!
  interface TenGigE0/0/0/0
  bfd fast-detect
  backup-path tunnel-te 1
!
  interface TenGigE0/0/0/2
  bfd fast-detect
  backup-path tunnel-te 2
!

  path-selection metric igp

!

explicit-path name P1-P5
index 10 exclude-address ipv4 unicast < ip_address P2P >
!
explicit-path name P1-P6
index 10 exclude-address ipv4 unicast < ip_address P2P >
!

interface tunnel-te1
description Tunnel FRR link
ipv4 unnumbered Loopback0
destination < lo0 PE5 >
path-option 10 explicit name P1-P5

path-option 20 dynamic

autoroute-announce

fast-reroute
!
interface tunnel-te2
description Tunnel FRR link
ipv4 unnumbered Loopback0
destination < Lo0 PE6 >
path-option 10 explicit name P1-P6

path-option 20 dynamic

autoroute-announce

fast-reroute
!

 

NOTA BENE: Le configurazioni riportate sono solo a titolo esemplificativo: le configurazioni dipendono dal progetto esecutivo sulla base delle richieste specifiche di ingegneria

 

 

4) Fault: Link Protection P5-P1:

 

analisi TE link 8

 

 

Il path LSP#4 stabilito via RSVP è quello evidenziato in figura.

Il tunnel TE tra CRS ha sta stessa funzione vista in precedenza.

 

 

5) Fault: P1 node protection

 

analisi TE link 9

 

 

Il path LSP#5 stabilito via RSVP è quello evidenziato in figura.

Il tunnel TE tra CRS ha sta stessa funzione vista in precedenza.

 

 

Conclusioni:

 

i tunnel LSP tra PE vengono realizzati dinamicamente via CSPF – RSVP TE

 

i tunnel TE a livello di Core può essere considerata una configurazione di questo tipo:

– tunnel-te primario verso il nodo NON adiacente del POP di backbone a lui connesso

– tunnel-te secondario verso il nodo adiacente sempre del POP di backbone a lui connesso

– mpls-ldp multi-hop abilitato

 

 

 

 

 

 

 

Torna in alto