Sincronizzazione IGP-LDP nelle reti IP/MPLS

In un post precedente pubblicato su questo blog, ho mostrato come la continuità  dei LSP MPLS PE-PE sia un aspetto chiave nel funzionamento dei più importanti servizi MPLS (es. L3VPN, L2VPN, 6PE, 6VPE, ecc.), illustrando come una intelligente estensione di due strumenti arcinoti come ping e traceroute, consenta di individuare se un LSP MPLS è continuo ed eventualmente determinare il punto di interruzione.

In questo post illustrerò una prima soluzione che consente di proteggere il traffico dalla caduta di una sessione LDP tra due LDP peer adiacenti. Ricordo che senza prendere opportune contromisure, la caduta di una sessione comporta la perdita di traffico. Infatti LDP non è un protocollo di routing e quindi non cambia percorso al traffico in caso di down della sessione LDP. Per maggiori dettagli potete consultare il post precedente.

SINCRONIZZAZIONE IGP-LDP

Per evitare che l’interruzione di un LSP tra due Edge-LSR provochi perdita di traffico, è necessario fare in modo che la perdita di una sessione LDP comporti un cambio di percorso del traffico.

Un altro scenario interessante dove la sincronizzazione IGP-LDP porta benefici è quando, dopo la caduta di un collegamento, con conseguente down sia dell'adiacenza IGP che della sessione LDP, il collegamento ritorna in funzione. Quello che accade infatti è che il protocollo IGP converge di nuovo al percorso pre-caduta del collegamento, e solo dopo questa convergenza viene rimessa in piedi la sessione LDP, vengono scambiate di nuovo le etichette MPLS associate alle varie destinazioni e quindi il traffico ritorna a fluire regolarmente. Il problema però è che durante l'intervallo che intercorre tra il termine della convergenza del protocollo IGP e il nuovo scambio di etichette MPLS, il traffico viene perso. Per evitare questa perdita di traffico, è necessario fare in modo che il traffico continui a fluire sul percorso alternativo post-caduta del collegamento, fino a quando sia l'adiacenza IGP che la sessione LDP non ritornano entrambe nello stato up.

L’idea fondamentale per risolvere questi problemi di perdita di traffico, è quella di sincronizzare i protocolli IGP e LDP in modo tale che se il router rileva la perdita di una sessione LDP tra LDP peer adiacenti, informa il protocollo IGP a non utilizzare il collegamento. L’informazione al protocollo IGP avviene generando un nuovo LSA/LSP con la metrica del collegamento posta al valore massimo: 

• Nel caso in cui il protocollo IGP sia OSPF, viene generato un nuovo Router Link LSA nel quale la metrica del collegamento dove si è verificata la perdita della sessione LDP, viene posta al valora massimo ammesso, pari a 0xFFFF (= 65.535).
• Nel caso in cui il protocollo IGP sia IS-IS, viene generato un nuovo Link State Packet (L1 e/o L2) nel quale la metrica (estesa) del collegamento dove si è verificata la perdita della sessione LDP, viene posta a 2²⁴-2. Si noti che il valore massimo di metrica estesa IS-IS è 2²⁴-1, ma in IS-IS un collegamento con metrica 2²⁴-1 non viene annunciato. Per questa ragione, nella sincronizzazione IGP-LDP, il collegamento viene annunciato con metrica 2²⁴-2. 

L'idea è riassunta nella figura seguente.

La soluzione esposta è stata standardizzata nella RFC 5443: LDP IGP Synchronization, Marzo 2009, ed è supportata dai maggiori costruttori di router, per entrambi i protocolli IGP utilizzati in pratica nelle reti di dimensioni medio-grandi, ossia OSPF e IS-IS.  

CONFIGURAZIONE NEI ROUTER CISCO

Cisco supporta la sincronizzazione IGP-LDP in tutte (almeno quelle che conosco) le innumerevoli versioni del suo IOS (IOS, IOS XE, IOS XR, NX-OS, e forse altre). La configurazione della sincronizzazione IGP-LDP richiede un solo comando base a livello di processo di routing, per fortuna identico in tutte le versioni IOS. Cisco supporta il comando per entrambi i protocolli di routing Link-state utilizzati nelle applicazioni pratiche: OSPF e IS-IS.

Il comando da eseguire per IOS, IOS XE, NX-OS è il seguente:

router(config)# router protocollo

router(config-router)# mpls ldp sync

Una volta eseguito il comando, la sincronizzazione IGP-LDP viene abilitata su tutte le interfacce dove sono stabilite adiacenze del protocollo IGP. Se necessario, è possibile disabilitare la sincronizzazione IGP-LDP su particolari interfacce, attraverso il comando a livello interfaccia "no mpls ldp igp sync". 

Per l'IOS XR, anche se il comando è identico, è diverso lo stile di configurazione ed è necessario distinguere l'applicazione a OSPF o IS-IS.

Nel caso di OSPF, il comando può essere eseguito a livello globale (e quindi vale per tutte le adiacenze), a livello di area (e quindi vale per tutte le adiacenze appartenenti all'area) e infine a livello interfaccia (e quindi vale per tutte le adiacenze costruite sull'interfaccia).

RP/0/RP0/CPU0:router(config)# router ospf process-ID

RP/0/RP0/CPU0:router(config-ospf)# mpls ldp sync 

! Oppure 

RP/0/RP0/CPU0:router(config-ospf)# area area-ID 

RP/0/RP0/CPU0:router(config-ospf-ar)# mpls ldp sync 

! Oppure 

RP/0/RP0/CPU0:router(config-ospf)# area area-ID 

RP/0/RP0/CPU0:router(config-ospf-ar)# interface interfaccia

RP/0/RP0/CPU0:router(config-ospf-ar-if)# mpls ldp sync 

Nel caso di IS-IS, la configurazione da eseguire è la seguente:

RP/0/RP0/CPU0:router(config)# router isis instance-id 

RP/0/RP0/CPU0:router(config-isis)# interface interfaccia

RP/0/RP0/CPU0:router(config-isis-if)# address-family ipv4 unicast 

RP/0/RP0/CPU0:router(config-isis-if-af)# mpls ldp sync

A partire dalla versione IOS 12.0(32)SY, Cisco ha messo a disposizione un delay (o holddown) timer, che consente di ritardare la notifica al protocollo IGP che la sessione LDP è ritornata operativa. Di default, quando la sessione LDP ritorna operativa ed è abilitata la sincronizzazione IGP-LDP, il protocollo LDP notifica immediatamente al protocollo IGP il ritorno all'operatività. Configurando un delay timer non nullo, questa notifica viene ritardata di un tempo pari al delay configurato. Fino a che la notifica non avviene, il LSP MPLS segue il percorso post-caduta della sessione LDP. Questo delay timer è utile in presenza di link flapping, e da modo di stabilizzare il collegamento, utilizzando per un certo tempo il percorso alternativo post-caduta. I comandi, eseguiti a livello globale, che consentono di definire il delay timer, sono i seguenti:

• IOS, IOS XE  : mpls ldp igp sync holddown msec
• IOS XR, NX-OS :  mpls ldp igp sync delay sec

CONFIGURAZIONE NEI ROUTER JUNIPER

La configurazione della sincronizzazione IGP-LDP nei router Juniper, a parte il diverso stile, segue le stesse logiche di quanto visto per i router Cisco, con la differenza che per fortuna il JUNOS è unico.

Per il protocollo OSPF la configurazione da eseguire è la seguente:

[edit protocols ospf]

tt@router# show 

area area-ID {

  interface interfaccia {

    ldp-synchronization {

      hold-time secondi;

    }

  }

}

mentre per il protocollo IS-IS è la seguente:

[edit protocols isis]

tt@router# show 

interface interfaccia {

   ldp-synchronization {

      hold-time secondi;

   }

}

Si noti che in entrambi i casi, affinché i comandi abbiano effetto, le interfacce devono essere di tipo punto-punto.

Per verificare lo stato della sincronizzazione, è possibile utilizzare il comando seguente:

tt@router> show (ospf | isis) interface [interfaccia] extensive 

Per un esempio, vedi il Case Study nella prossima sezione.

CASE STUDY
Per illustrare il funzionamento della sincronizzazione IGP-LDP, farò riferimento alla seguente rete di laboratorio, costituita da router Juniper della serie MX, con JUNOS 14.1R1.10. La figura riporta anche il piano di numerazione utilizzato.

La rete utilizza come protocollo IGP il protocollo IS-IS. Tutti i router appartengono alla stessa area IS-IS, sono di tipo L2 e utilizzano metriche di tipo wide. Si noti che la metrica delle interfacce agli estremi dei collegamenti P1<-->PE2-1 e P1<-->P2 è stata posta a 1.000 per forzare il percorso PE1-1-->PE2-2 a PE1-1-->PE1-2-->P2-->PE2-2. Le altre metriche sono poste al valore di default (= 10). Su tutte le interfacce dei router è stato abilitato il protocollo LDP e la sincronizzazione IGP-LDP, con holddown = infinito. Ad esempio, la configurazione IS-IS e LDP del router PE1-1 è la seguente:

tt@PE1-1> show configuration protocols
isis {
    level 1 disable;
    level 2 wide-metrics-only;
    interface ge-0/0/0.0 {
        ldp-synchronization;
        point-to-point;
    }
    interface ge-0/0/1.0 {
        ldp-synchronization;
        point-to-point;
    }
    interface lo0.0 {
        passive;
    }
}
ldp {
    interface ge-0/0/0.0;
    interface ge-0/0/1.0;
    interface lo0.0;
}

Il percorso tra i router PE1-1 e PE2-2 e le etichette MPLS utilizzate, possono essere verificati con un traceroute MPLS:

tt@PE1-1> traceroute mpls ldp 192.168.0.22/32
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label    Protocol    Address          Previous Hop     Probe Status
    1   299808  LDP         172.16.12.12     (null)               Success
    2   299776  LDP         172.16.24.2      172.16.12.12    Success
    3             3  LDP         172.16.46.22    172.16.24.2      Egress
  Path 1 via ge-0/0/1.0 destination 127.0.0.64

Con il comando seguente è possibile verificare che l'adiacenza IGP e la sessione LDP sul collegamento PE1-1<-->PE1-2 sono sincronizzate:

tt@PE1-1> show isis interface ge-0/0/1.0 extensive
IS-IS interface database:
ge-0/0/1.0
  Index: 335, State: 0x6, Circuit id: 0x1, Circuit type: 2
  LSP interval: 100 ms, CSNP interval: 10 s, Loose Hello padding
  Adjacency advertisement: Advertise
  LDP sync state: in sync, for: 00:02:55, reason: LDP session up
  config holdtime: infinity
  Level 2
    Adjacencies: 1, Priority: 64, Metric: 10
    Hello Interval: 9.000 s, Hold Time: 27 s

Ora, supponiamo che vi sia un down della sessione LDP tra PE1-1 e PE1-2. Benché l'adiacenza IGP sia up:

tt@PE1-1> show isis adjacency
Interface             System         L  State        Hold (secs)  SNPA
ge-0/0/0.0            P1              2    Up                   23
ge-0/0/1.0            PE1-2        2    Up                   23

il percorso tra PE1-1 e PE2-2 cambia e diventa PE1-1-->P1-->P2-->PE2-2:

tt@PE1-1> traceroute mpls ldp 192.168.0.22/32

  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status

    1   299840  LDP         172.16.13.1      (null)                Success

    2   299824  LDP         172.16.34.2      172.16.13.1      Success

    3            3  LDP         172.16.46.22    172.16.34.2      Egress

  Path 1 via ge-0/0/0.0 destination 127.0.0.64

evitando così il collegamento con la sessione LDP down.

Come mostra il risultato del comando seguente, tra PE1-1 e PE1-2 i protocolli IGP (= IS-IS) e LDP non sono più sincronizzati (LDP sync state: in hold-down) e inoltre, la metrica IS-IS dell'interfaccia ge-0/0/0.0 viene posta al valore 2²⁴-2 (= 16.777.214):

tt@PE1-1> show isis interface ge-0/0/1.0 extensive
IS-IS interface database:
ge-0/0/1.0
  Index: 335, State: 0x6, Circuit id: 0x1, Circuit type: 2
  LSP interval: 100 ms, CSNP interval: 10 s, Loose Hello padding
  Adjacency advertisement: Advertise
  LDP sync state: in hold-down, for: 00:09:17, reason: LDP session down
  config holdtime: infinity
  Level 2
    Adjacencies: 1, Priority: 64, Metric: 16777214
    Hello Interval: 9.000 s, Hold Time: 27 s

Il nuovo percorso PE1-1-->P1-->P2-->PE2-2 viene mantenuto fino a quando la sessione LDP tra PE1-1 e PE1-2 non ritorna nello stato up, e quindi vi è di nuovo sincronizzazione tra IGP e LDP.

CONCLUSIONI
La continuità dei LSP MPLS PE-PE è un elemento chiave di molti dei nuovi servizi su reti IP/MPLS. In questo post ho illustrato una funzionalità molto interessante, la sincronizzazione IGP-LDP, che consente di proteggere il traffico dal down di una sessione LDP. La funzionalità consente di far cambiare il percorso al protocollo IGP, considerando il down della sessione alla stessa stregua del down di una adiacenza. La funzionalità è standard ed è supportata dai router di tutti i maggiori costruttori di router.

Se volete saperne di più su MPLS, da zero all'infinito, oppure avete bisogno di ulteriori approfondimenti, seguite i nostri molti corsi sull'argomento, tra cui vi segnalo: 

• IPN272: MPLS: dalla teoria alla Pratica
• IPN273: MPLS: aspetti avanzati
• IPN276: MPLS nell’IOS XR Cisco
• IPN258: MPLS nel JunOS Juniper

E se volete un qualcosa di molto più completo, seguite l'intero percorso per la certificazione Cisco CCNP - SP (CCNP - Service Provider).