Sei sulla pagina 1di 26

MPLS: una tecnologia indipendente da qualsiasi mezzo di trasporto fisico Layer 1 e da qualunque protocollo WAN di incapsulam.

. Livello2; una tecnologia di switching dei pacchetti basata esclusivamente sullo scambio delle labels e non pi sul controllo dellIP di destinazione; per lo switching dei pacchetti la tabella consultata non pi la Routing Table ma la LFIB Table. L'MPLS tramite il motore LDP o TDP protocol fa derivare due nuove tabelle: LIB ed LFIB, e il prerequisito essenziale per generarle di utilizzare CEF come metodo di IP switching Layer 3..ricordare che CEF in s come tecnologia introduce le tabelle FIB e Adjacency, rispettivamente le derivate hardware della tradionale IP Routing Table e della ARP cache. Benefici dell'MPLS: - Riduce il lavoro di routing sui core routers - Supporta tecnologie come Qos, VPN, IP routing unicast e multicast, TE, protocolli Layer 3 non-IP,any transport over MPLS (AToM) Componenti dell'architettura MPLS: -Piano di Controllo (fa ricavare la ROUTING TABLE (RIB) tramite protocollo di routing utilizzato e per mezzo di un protocollo di scambio etichette locali tra i routers (LDP, TDP, RSVP) fa derivare le tabelle LIB ed LFIB). La LIB Table la struttura dati che custodisce per ogni prefisso di rete tutte le labels, quella localmente assegnata pi tutte le altre ricevute da ogni neighbor (local label annunciata agli upstream neighbors, labels ricevute dai downstream neighbors). Come viene generata la LIB dal piano di controllo? Ogni router MPLS assegna localmente ad ogni prefisso di rete (non-BGP) una label in maniera indipendente, asincrona rispetto agli altri routers, e tramite gli updates LDP la propaga ad ogni peer che a sua volta la conserva nella sua LIB Table (questo metodo di distribuzione delle labels viene denominato "Unsolicited Downstream distribution of labels") Il meccanismo che consente ad ogni router di conservare per uno stesso prefisso nella LIB etichette ricevute da qualunque peer indipendentemente se viene poi o no utilizzata come next-hop si chiama "liberal label retention mode" I valori 0 e 15 delle etichetti sono riservati Quindi nel piano di controllo risiedono: - RIB Table generata da IGP - LIB table - Protocollo LDP per creare e popolare la LIB Table

-Piano Dati (o Forwarding Plane): responsabile nel forwarding dei pacchetti etichettati lungo l'interfaccia di uscita sulla base delle info contenute nella tabella LFIB. L'LDP attivo anche nel piano dati per popolare la tabella LFIB di etichette loca label - next hop label Quindi nel piano dati risiedono: - FIB Table (contiene mappaggio IP network - Next Hop interface (e anche Next-Hop-Label se il router edge e deve instradare pacchetti non ancora etichettati - La LFIB Table (usata per l'instradamento dei pacchetti, contiene solo i mappaggi local label - next hop label) - Protocollo LDP per creare e popolare l'LFIB Table. PHP (Penultimate Hop Popping): processo che lavora sul penultimo router e che ottimizza le performance dell'MPLS in Frame-Mode togliendo all'ultimo router MPLS lo scomodo di effettuare un doppio lookup, uno sulla LFIB Table per rimuovere l'etichetta dal pacchetto, l'altro sulla FIB Table per instradare il pacchetto IP fuori dal dominio MPLS. Con questo meccanismo l'estrazione dell'etichetta viene svolta solo dal penultimo router MPLS che con l'action POP label= 3 (se si usa LDP) oppure = 1 (se si usa il TDP) viene istruito non a swappare l'etichetta ad un valore uguale a 3 ma a rimuoverla! Il pacchetto quindi all'ultimo router giunger gi senza etichetta (pacchetto IP) e il lookup per instradarlo verso l'esterno della rete MPLS sar svolto solo sulla FIB Table. N.B: PHP non pu lavorare su ATM: infatti VPI/VCI non pu essere rimosso Prerequisito essenziale: abiliTaRE IL CEF su ogni router con MPLS attivo per utilizzare la FIB Table come mezzo di Layer 3 IP switching (CEF

Switching) al posto della Ip routing Table Esistono 2 tipi di router MPLS: -LSR (Label Switch Router): sono i core routers MPLS cio i P routers che hanno tutte le interfacce abilitate per l'MPLS, in ingresso ricevono pacchetti gi etichettati e in uscita li inviano con un'altra etichetta swappando le labels tramite consultazione della tabella LFIB (non si usa mai la FIB Table per l'instradamento)

- Edge LSR: sono i routers di bordo della rete MPLS, cio i PE routers che hanno alcune delle loro interfacce non abilitate per l'MPLS ed altre s. Ingress Edge LSR: consulta la FIB Table per instradare il pacchetto etichettandolo con la label next-hop ricevuta dal downstream neighbor, cambia il valore di PID (Protocol Identifier) o Ethertype per indicare che il pacchetto di tipo MPLS (PID= 0X0800 = pacchetto IP, PID= 0X8847 = pacchetto MPLS UNICAST,PID= 0X8848 = pacchetto MPLS MULTICAST), copia il valore del TTL IP nel TTL MPLS Eggress Edge LSR: consulta la LFIB Table per rimuovere la label, poi consulta la FIB Table per instradare il pacchetto verso la rete IP (non pi MPLS), ripristinando il valore del PID pari a 0x0800 e ricopiando il valore del TTL MPLS nel TTL IP. Grazie al meccanismo PHP l'Egress Edge LSR pu consultare solamente la FIB Table e non anche la LFIB Table.

Campo Label (o "Shime Header"): ha lunghezza 4 bytes ed ha significato locale (vedere miei appunti): 20 bit che identificano il valore della label 3 bit Experimental per il trasporto della QoS Il bit "Bottom-of-stack" ("S bit"), se settato (=1) indica che la label l'ultima, altrimenti se non settato (=0) indica che la label non l'unica ad essere presente. 8 bit di TTL: indispensabile affinch i routers LSR possano completamente ignorare le informazioni IP compresa quella del TTL IP; pertanto i routers MPLS decrementano il TTL MPLS, non quello IP

LSP (Label Switched Path): un percorso virtuale UNIDIREZIONALE generato da LDP costituito dalla sequenza di labels/next hop labels utilizzato per instradare il pacchetto lungo il miglior percorso selezionato da IGP. Un LSP simile ad un circuito virtuale Frame-Relay o ATM dove gli end-points sono gli edge LSRs Pacchetti etichettati che transitano nell'opposta direzione utilizzano un altro LSP Solo l'MPLS TE in grado selezionare un percorso alternativo a quello scelto dall'IGP FEC (Forwarding Equivalence Class): un gruppo di pacchetti inviati lungo lo stesso tunnel LSP e con lo stesso trattamento ricevuto (per esempio tutto il traffico con un determinato valore di IP Precedence un esempio di FEC) L'MPLS pu lavorare in 2 modi: Frame-Mode MPLS: la label viene interposta tra gli headers di livello 2 e livello 3 di una trama Ethernet, PPP, Frame Relay ecc Cell-mode MPLS: si usa quando il protocollo di incapsulamento Layer 2 l'ATM e l'LSR uno switch ATM. Dopo la segmentazione delle trame in celle come label viene utilizzato il campo VPI/VCI dell'header ATM, quindi l'aggiunta di un ulteriore label non viene effettuata poich le celle ATM devono conservare sempre lunghezza fissa di 53 bytes. Dopo la segmentazione delle trame in celle ATM la label di 32 bit presente solo nella prima cella del pacchetto. MPLS Label Stack: il contenitore di pi labels. Solo in queste tecnologie MPLS viene utilizzato uno stack di pi labels: MPLS VPN: utilizza in totale 2 labels: la prima (outer label o LDP label) viene assegnata via LDP alle rotte customer e sequenzialmente viene swappata da router

a router fino al PE di destinazione (BGP next-hop); essa serve ad identificare il circuito virtuale LSP, ossia la sequenza (label, next-hop-label) per raggiungere il PE di destinazione; dal PE sorgente viene ricavata dalla consultazione della tabella FIB VRF; la seconda label (inner label o VPN label) identifica invece linterfaccia di uscita del PE di destinazione (VRF) e rimane invariata finch non giunge al PE di destinazione; questa label viene allocata dal PE di sorgente e comunicata al PE destinazione sulla sessione MP-BGP con lupdate BGP; il PE d'ingresso per ricavarla utilizza l'entry della FIB VRF .

MPLS TE: utilizza in totale 2 o pi labels: la prima identifica il tunnel TE LSP, la seconda punta alla destinazione. MPLS VPN combined with MPLS TE: utilizza 3 o pi labels: la prima (ldp label) punta all'egress router (inner label), la seconda identifica la VPN (inner labels), la terza (outer label) punta alla terminazione del TE Tunnel MPLS Multicast Routing: l'MPLS pu supportare anche il routing multicast ma tramite il Cisco PIM versione 2 (Cisco Protocol Indipendent Multicast Version 2) MPLS QoS: permette all'amministratore di rete di differenziare i servizi a livello di performance lungo il dominio MPLS (tramite i 3 bit sperimentali della label oppure tramite separati tunnels LSP ognuno associato alla sua classe ma tutti diretti alla stessa destinazione); quindi di classificare i pacchetti, evitare congestione o gestirla. AToM (Any Transport over MPLS): la soluzione Cisco che attraverso routers della serie 7200,7400,7500,7600, 10700, 12000, permette di accomodare sulla backbone MPLS il trasporto di trame di livello 2 di tecnologia: Ethernet, Frame Relay, ATM, PPP, HDLC EoMPLS (ad esempio TLS e VPLS) la tecnologia che trasporta trame ethernet sulla backbone MPLS ricevute da un segmento Ethernet o da una Vlan, indipendentemente dall'info del MAC address di destinazione (non viene eseguito nessun MAC lookup per inviare pacchetti dall'interfaccia Ethernet) ATM over MPLS (ad esempio ATM AAL5 over MPLS, ATM Cell Relay over MPLS) FRoMPLS LDP (Label Distribution Protocol): protocollo standard di scambio etichette tra routers adiacenti (utilizzato dalla Cisco IOS Release 12.4(3) e successive) e popolamento delle LIB e LFIB Table. TDP (Tag distribution Protocol): idem ma di propriet Cisco LDP: come viene stabilita una sessione LDP fra 2 LSRs adiacenti? Prima di tutto si comincia con il processo di LDP neighbor discovery ("show mlps ldp discovery") i routers mpls adiacenti si scambiano periodiacamente ogni 5s, in multicast con indirizzo 224.0.0.2 dei Messaggi LDP di Hello Discovery servendosi del protocollo di trasporto UDP e della porta di destinaz. 646 (Hello Hold Time= 15 s). TDP utilizza protocollo di trasporto UDP ma porta di dest. 711 Solo i routers con indirizzo IP + alto (loopaback o interfaccia) inizializzano la sessione TCP LDP con porta di destinazione sempre 646 e con indirizzo sorgente di loopaback o interfaccia (TDP inizializza la sessione TCP su porta 711) Vedere pag 2.5 per vedere il formato del messaggio LDP Hello: Da sx a dx abbiamo: a) IP header (contentente IP sorg = ad esempio 1.0.0.1 e IP destinaz = 224.0.0.2) b) UDP header (contenente porta sorg. = ad esempio 1050, e porta destinazione = 646) c) Hello Message (contenente opzionalmente campo "Transport Address" contenente l'IP sorg per istruire il router adiacente ad aprire la sessione sull'address di trasporto anzich sull'IP sorgente trovato nell'header IP + 6 bytes di LDP ID = 4 bytes di IP sorg. + 2 bytes di Label Space = ad esempio 1.0.0.1:0 per istruire il neighbor ad identificare l'IP sorgente della sessione LDP)

N.B: Il label space indica il modo di assegnare le label alle rotte ("per-platform" o "per-interface") Il label-space "per-platform" viene di default svolta in Frame-Mode MPLS ed indicato con label Space ID = 0 (:0) (quello "perinterface" con :1) Nella modalit "per-platform" la label assegnata alla rotta viene annunciata in maniera univoca a ogni adiacente LSR con una sola sessione LDP anche se fra una coppia di LSRs possono essere presenti dei link paralleli (le rimanenti vengono interrotte); per garantiscono minor sicurezza rispetto la modalit "per-interface", poich "Untrusted" routers potrebbero inviare ulteriori labels (label spoofing) oltre a quelle pre-allocate dai routers legittimi. Con il label-space "per-interface" invece la label viene annunciata "per-interface" --> risultato: tabelle LIB e LFIB sono pi grosse e lo scambio delle labels meno rapido

Un sessione LDP si capitalizza in 3 processi: - stabilimento sessione TCP - scambio messaggi di inizializzazione - scambio messaggi di keepalive (ogni 60s) Come si svolge il processo di LDP neighbor discovery tra 2 LSRs non adiacenti? Con l'invio di Hello messaggi in unicast anzich in multicast; messaggi hello LDP unicast si chiamano LDP targeted hello e per attivarli occorre il seguente comando: "mpls ldp neighbor [vrf "name"] ip_address targeted". Poi il meccanismo di negoziazione della sessione LDP si svolge nello stesso modo visto con gli adiacenti LSRs Se il percorso tra 2 LSRs un Tunnel TE ed ha LDP abilitato, la sessione LDP tra essi si chiama "targeted session" Applicazioni che utilizzano "targeted session" sono: - MPLS Fast Reroute (FRR) CHE l'abilit di patchare il traffico in un tunnel di backup quando c' la caduta di un nodo o di un link - MPLS Nonstop Forwarding (NSF) che permette ad un router di mantenere il controllo del piano dati a seguito della caduta del componente LDP del piano di controllo - MPLS LDP Session Protection che rende pi veloce la convergenza LDP dopo il recupero di un link

Impatto dell'aggregazione IP (sommarizzazione) su circuito LSP: sicuramente negativo in quanto provoca la rottura dell'LSP in 2 segmenti (vedere es pag 2-24). Quindi l'aggregazione delle rotte fortemente sconsigliata in reti MPLS VPN, MPLS TE, MPLS con ATM, in Transit AS dove BGP non attivo siu core routers Rilevamento dei loops in MPLS Frame-Mode: intanto occorre dire che l'LDP in primis si affida ai meccanismi di anti-loops forniti dal protocollo di routing IGP. Se cmq un loop capita lo stesso (per un problema di misconfiguration con le rotte statiche) per prevenire il loop infinito viene utilizzato come espediente il TTL (quando TTL raggiunge valore 0 il pacchetto etichettato loppato tra 2 routers viene scartato)

Convergenza MPLS: in MPLS si ha convergenza totale quando l'IGP e l'LDP hanno totalmente popolato le loro strutture dati (RIB, FIB, LIB, LFIB); comunque sui tempi di convergenza dell'MPLS ha sicuramente pi impatto la convergenza dell'IGP Convergenza MPLS post Link Failure: Il router rimuove l'interessata entry dalla FIB Table poich l'IGP ha determinato che quel next-hop divenuto irraggiungibile; il router rimuove poi anche la corrispondente next-hop-label dalle tabelle LIB e LFIB poich l'LDP ha determianto che il router adiacente non pi raggiungibile (vedere fig.2-51). Dopo la riconvergenza dell'IGP, l'IGP stesso inserisce una nuova entry nella FIB Table LDP riaggiorna anche IL NEXT-HOP LABEL nell'LFIB In sintesi la riconvergenza in MPLS avviene immediatamente dopo quella dell'IGP e in base a tutte le label precedentemente custodite nella LIB Table (ricordare che Frame-Mode MPLS utilizza il meccanismo "liberal label retention mode" ossia di custodire nella LIB ogni label ricevuta indipendentemente dal fatto se vengono utilizzate o no, perch a seguito del fallimento di un link una label mai precedentemente utilizzata potrebbe essere invece ora utilizzata come nuovo next-hop label Convergenza MPLS in caso di Link Recovery: Il router non detenendo pi la corrispondente next-hop label precedentedentemente rimossa deve aspettare la riconvergenza dell'IGP (quindi potrebbe temporaneamente verificarsi un interruzione di connettivit MPLS) e in pi il tempo di ripristino della precedente sessione LDP (convergenza LDP). Per accelerare il tempo di convergenza in caso di Link Recovery l'unica soluzione utilizzare L'MPLS TE.

Configurazione Frame-Mode MPLS: occorre obbligatoriamente: 1) abilitare CEF Switching 2) abilitare l'LDP sull'interfaccia

1) Router(config)# mpls ldp router-id "interface" [force] <-- Per settare come LDP router ID l'IP address dell'interfaccia fisica o della loopback (consigliato) . L'opzione "force" invece forza l'uso del nome dell'interfaccia come LDP router ID 2) Router(config)# mpls label protocol [ldp | tdp | both] <-In global mode, per attivare il label distribution protocol ("both" per attivare entrambi LDP e TDP quando lungo l'interfaccia si possono trovare dispositivi di altri vendors (non Cisco) che dunque non supportano il TDP oppure in interface-mode Router(confi-if)# mpls label protocol [ldp | tdp | both] 3) Router(config)# ip access-list NoTDP deny tcp any any eq 711 <--- ACL che blocca ogni tentativo di stabilire una Router(config)# ip access-list NoTDP permit ip any any sessione TDP su interfaccia non abilitata per Router(config)# interface ethernet 3/1 l'MPLS. Il filtro di accesso MPLS lo si deve 4) Router(config-if)# mpls ip <--(Per attivare l'MPLS) Router(config-if)# ip access-group NoTDP in applicare solo su Edge LSR routers e su interfacce con MPLS non attivo. 5) Router(config-if)# mpls mtu "bytes" <-- per supportare lo stack MPLS con una o pi labels (1504,1508,1512) evitando la frammentazione. (N.B: Mentre sulle interfacce WAN l'MTU viene automaticamente incrementato, su quelle LAN invece necessita di essere incrementato manualmente per evitare la frammentazione Inoltre tutti gli switch della LAN devono essere configurati per supportare i "Jumbo Frames"ad esempio col comando "set port 1/3 jumbo enable" oppure "mtu 1512" a seconda del modello dello switch) 6) Router(config)# no mpls ip propagate-ttl [forwarded | local] <-- opzionale, configurato su tutti i routers del dominio MPLS disattiva la propagazione del TTL MPLS Con "forwarded" viene oscurata la visibilit dei nodi MPLS solo quando il traceroute viene attivato dall'esterno, ossia dalla rete customer (in questo caso l'ingress Edge LSR decrementa di una unit il valore del TTL IP, non pi utilizzato dai prossimi router MPLS,e nello stesso tempo setta a 255 il TTL MPLS, decrementato da unit a unit dai prossimi router MPLS; l'egress Edge LSR a sua volta estrae l'header MPLS compreso il TTL MPLS ed instrada il pacchetto IP con TTL IP ). Con "local" invece (soluzione meno desiderata dai Provider) viene oscurata la visibilit dei nodi MPLS solo quando il traceroute viene attivato dall'interno del Provider). 6) Router(config)# mpls ldp advertise-labels [for "prefix-access-list [to "peer-access-list"]] (Questo comando permette diimplementare la "Conditional label distribution": di default, l'LDP fa generare per ogni prefisso IP una label locale su ogni router; per far s che l'LDP generi labels solo per determinati prefissi (destinazioni) e che le annunci solo a specifici neighbors LSR occorre utilizzare questo comando dove: "for prefix-access-list" il parametro che specifica quali prefissi vanno etichettati, mentre "to prefix-access-list" specifica quali LSR neighbors devono ricevere le labels) Esempio: nel contesto VPN MPLS andrebbero etichettate solo le destinazioni di loopbacks interface che costituiscono il Tunnel LSP. Supponiamo che tutte le loopback interfaces stanno nel blocco 192.168.254.0/24) La configurazione la seguente: Router(config)# mpls ldp advertise-labels for 90 to 91 Router(config)# access-list 90 permit 192.168.254.0 0.0.0.255 Router(config)# access-list 91 permit any TROUBLESHOOTING Frame-Mode MPLS: a) "show mpls {ldp | tdp } parameters" per visualizzare info sui parametri del protocollo LDP (LDP version, Discovery Hello interval, Discovery Hello Holdtime ecc..vedere pag 3-42) b) "show mpls interfaces" per visualizzare le interfacce con MPLS abilitato, ecc...(vedere pag 3-44) c) "show mpls {ldp | tdp } discovery" per verificare se il processo di LDP Discovery con l'Hello Protocol andato a buon fine; si visualizzaranno gli LDP router IP address (vedere pag 3-45) d) "show mpls {ldp | tdp } neighbors [vrf "name_vrf"][address][interface][detail]" (vedere pag 3-49..importante la riga "State=oper") e) "show mpls {ldp | tdp } bindings ["prefix"][detail]" per osservare il contenuto della LIB Table (labels locali e ricevute da ogni neighbor LDP ID per ogni prefix di rete...vedere esempio 19-2 pag 834 CCIE)

f) "show mpls forwarding-table ["prefix"] per osservare il contenuto della LFIB Table (vedere pag 3-55) g) "show ip cef "network" detail (per vedere info dettagliate sulla FIB entry specificata, pag 3-58) h) "debug mpls ldp" (mostra gli eventi correlati all'LDP) I) "debug mpls lfib" (mostra gli eventi correlati all'LFIB Table) l) "debug mpls packets" (mostra tutti i pacchetti etichettati switchati dal router) TROUBLESHOOTING Frame-Mode MPLS approfondito: 1) Il neighbor LDP non viene rilevato (da "show mpls ldp discovery") e la Sessione LDP non va in up: un problema che capita quando: a) l'MPLS non abilitato sul router adiacente (utilizzare "show mpls interface" sui entrambi i routers) b) c' un problema di mismatch a livello di LDP che si verifica ad esempio quando da un lato c' attivo l'LDP mentre dall'altro c' attivo il TDP (utilizzare " show mpls interface detail" su entrambi i routers) c) c' un'access-list abilitata su interfaccia del router che blocca la porta LDP o TDP (utilizzare "show ip interface" e "show access-list") 2) Il neighbor LDP viene s rilevato (da "show mpls ldp discovery") ma la Sessione LDP non va lo stesso in up (da "Show mpls ldp neighbor" viene evidenziato lo stato non operazionale del neighbor: un problema che capita quando le loopbacks dei routers non si pingano poch non sono state annunciate in IGP 3) Le labels non vengono allocate alle rotte locali (da "show mpls forwarding-table" la LFIB vuota) un problema che capita quando: CEF non abilitato (da "show ip cef" o "show cef interface") 4) Le labels vengono allocate ma non vengono distribuite verso l'LSR adiacente (da "show mpls ldp bindings" sull'adiacente router non si vedono labels) un problema che capita quando: il neighbor LDP ID (loopaback) non matchato da un'ACL specificata nel comando "mpls ldp advertise-labels..."

EXTRANET: una VPN che interconnette ad una Corporate Intranet diverse organizzazioni o partners. Central Service VPN: sono VPN dove ogni sito client pu comunicare con un server centralizzato ma non con ogni altro sito Network Management VPN: VPN utilizzata dall'ISP per gestire i routers CE dei propri clienti. Central Services Extranet: quando l'ISP offre ai suoi clienti accesso ad un comune servizio Extranet (ad es.servizio Extranet di VOIP internazionale; N.B: non servizio VOIP Intranet!!) Configurazione MPLS in Frame-mode su rete ATM con Switch ATM che non supportano l'MPLS" (MPLS over ATM Forum PVCs): Nel caso in cui gli switches ATM non supportano MPLS (o meglio il "Cell-mode MPLS", poich non aggiornabile il firmware per il supporto dell'MPLS) l'MPLS viene fatto girare in modalit Frame e direttamente tra i routers senza coinvolgimento degli Switches ATM; gli switches sono attivi solo nella segmentazione dei pacchetti IP in celle e nel riassemblamento di queste ultime. La sessione LDP viene stabilita solo tra le estremit del circuito PVC (ossia tra i routers) e non con lo switch ATM collegato. L'etichettamento dei pacchetti avviene a livello software, mentre la segmentazione in celle e il riassemblamento avviene in hardware (su interfaccia) Passi di configurazione lato router: Router(config)# ip cef Router(config)# mpls label protocol ldp Router(config)# mpls ldp router-id "ip_address" Router(config)# interface atm3/0.2 point-to-point Router(config-if)# ip unnumbered loopback 0 Router(config-if)# mpls ip Router(config-if)# pvc "vpi/vci" Router(config-if-atm-vc)# encapsulation aal5snap

Configurare MPLS in Frame-mode su rete Frame-Relay (MPLS over Frame-Relay): La sessione LDP viene sempre stabilita tra le estremit del PVC (ossia tra i routers) e non con lo switch ATM collegato. Passi di configurazione lato router: a) creare una subinterface Serial point-to-point (subif type "poin-to point" per attivare il Frame-mode)

b) configurare l"ip unnumbered loopback 0" b) configurare un Frame-Relay PVC (DLCI) sulla subif c) mettere il comando "mpls ip" (tipico del "frame mode MPLS") Configurazione MPLS in Cell-Mode su rete ATM con Switches ATM che supportano l'MPLS" (Cell-mode MPLS): In MPLS modalit Cell come label viene utilizzato il valore del PVC ATM ossia della coppia VPI/VCI che identifica il circuito logico ATM. Switch Catalyst Cisco con processore che supporta nativamente l'MPLS, quindi il protocollo di segnalazione LDP, sono: il Catalyst 8510, il Catalyst 8540 e il LighStream 1010. - Il router sorgente (ATM - Edge LSR Ingress) necessita di una label per la destinazione X; la FIB Table indica la destinazione X raggiungibile attraverso l'interfaccia LC-ATM; il router sorgente pertanto richiede una label al primo switch ATM in downstream; una volta ottenuta la label (studiare il processo dinamico di allocazione delle labels nel dominio ATM-LSR a pag 62 del book "MPLS and VPN Architectures"), nella LFIB Table rileva il valore VPI/VCI da utilizzare come label; il pacchetto etichettato viene segmentato in celle ATM e l'etichetta VPI/VCI viene inserita in ognuna di esse dentro l'header ATM. - Tutti i prossimi Switch ATM (ATM - LSR) switchano le celle basandosi sul mappaggio dei valori (VPI/VCI ingresso, VPI/VCI uscita) - Il router di destinazione (ATM - Edge LSR Egress) infine riassembla le celle ATM in un pacchetto etichettato col valore VPI/CI Passi di configurazione lato Edge Router ATM LSR (LC-ATM interface): Router(config)# ip cef Router(config)# mpls label protocol ldp Router(config)# mpls ldp router-id "ip_address" Router(config)# interface atm3/0.2 mpls Router(config-if)# ip unnumbered loopback 0 Router(config-if)# mpls ip Router(config-if)# mpls atm vpi 2-3 (opzionale, per selezionare il range di VPI da utilizzare come etichette) Router(config-if)# mpls atm control-vc 5 32 (opzionale, per configurare il VC non-MPLS per il trasporto del traffico di segnalazione (LDP, ICMP, pacchetti OSPF) senza questo comando di default viene utilizzato il VC 0/32)

Passi di configurazione lato Switch ATM LSR(LC-ATM interface): Switch(config)# ip cef Switch(config)# mpls label protocol ldp Switch(config)# mpls ldp router-id "ip_address" Switch(config)# interface atm0/1/2 Switch(config-if)# ip unnumbered loopback 0 Switch(config-if)# mpls ip Switch(config-if)# mpls atm vpi 2-3 Switch(config-if)# mpls atm control-vc 5 32

MPLS VPN: una VPN di livello 3 che lavora in dominio MPLS, di tipo peer-to-peer e che rende il Provider attivamente partecipe al customer routing VPN, mentre il customer rimane completamente ignaro del contesto VPN VRF: una routing istance-forwarding associata ad una VPN e che associa attributi come RD, import RT ed export RT alle rotte provenienti dai customers; ogni CUSTOMER VPN attaccata al PE router rappresentata da una VRF. La Cisco IOS Software per i protocolli di routing come RIP, EIGRP, BGP e IS-IS fa attivare sul PE un unico processo globale di raccolta delle VRFs; invece per l'OSPF fa attivare n processi distinti e separati di routing quante sono le VRFs. Routing context= il protocollo di routing attivo in una VRF; il PE preleva le rotte del customer in IGP o statico importandole nella corrispondente VRF che rileva dallassociazione VRF-interface configurata lato PE.

I pacchetti verranno switchati in modalit CEF tramite la FIB Table ricavata dalla IP Routing Table. Qualsiasi interfaccia che supporti il meccanismo CEF Switching pu essere associata ad una VRF (fisica, subif o logica) tranne quelle Dialer, ISDN ed SMDS; ad ogni interfaccia si pu associare una sola VRF; ad una VRF invece possono essere associate pi interfacce. CE: il customer router direttamente collegato al PE e completamente ignaro del contesto VPN PE: il primo router di accesso della backbone MPLS collegato direttamente al CE da una parte e dall'altra al router P; esso preleva in IGP o statico le rotte IPv4 dal CE sorgente, le converte in VPNv4 e le redistribuisce in MP-BGP verso il PE di destinazione che a sua volta le riconverte in IPv4 per redistribuirle in IGP o statico al CE di destinazione P: il router core (LSR) collegato solo verso un PE e/o verso un P; completamente ignaro delle rotte VPN; svolge solo lo swapping delle labels esterne (outer labels o LDP label) finch le rotte non giungono al PE di destinazione. Lo scambio delle rotte tra CE e PE pu avvenire con: - routing statico - routing dinamico (RIPv2, EIGRP, OSPF, BGP) CUstomers differenti possono utilizzare lo stesso piano di indirizzamento IP senza problemi di address overlapping grazie ad un identificativo di VPN membership di 64 bit denominato RD (Route Distinguisher) che appeso al prefisso IP lo trasforma da indirizzo IPv4 di 32 bit in indirizzo VPNv4 di 96 bit. I PEs riescono a determinare in quale VRF devono importare le rotte VPNv4 grazie al parametro ROUTE TARGET di 64 bit dello stesso formato dell'RD; i route targets vengono comunicati tra i PEs mediante un campo del BGP Update denominato BGP Extended Community; mentre ad un prefisso pu essere assegnato un solo RD, allo stesso prefisso possono essere assegnati pi Route Targets per favorire l'Overlapping VPNs ( partecipazione del CE a pi VPNs (VRFs) ) Etichettamento con MPLS: il PE di ingresso, non appena riceve una rotta IPv4 dal customer, ad essa assegna uno stack di 2 labels: - una label esterna (outer label o LDP lavel): viene assegnata via LDP alle rotte customer e sequenzialmente viene swappata da router a router fino al PE di destinazione (BGP next-hop); essa serve ad identificare il circuito virtuale LSP, ossia la sequenza (label, next-hop-label) per raggiungere il PE di destinazione; dal PE sorgente viene ricavata dalla consultazione della tabella FIB VRF; - una label interna (inner label o VPN label): identifica linterfaccia di uscita del PE di destinazione (VRF)e rimane invariata finch non giunge al PE di destinazione; questa label viene allocata dal PE di sorgente e comunicata al PE destinazione sulla sessione MP-BGP con lupdate BGP; il PE d'ingresso per ricavarla utilizza l'entry della FIB VRF.

PHP: il meccanismo del PHP permette al penultimo router MPLS di rimuovere la label LDP in modo che l'ultimo PE, quello di destinazione, nella LFIB Table svolga il lookup solo solo sulla VPN label.

Configurazione MPLS VPN lato PE: a) creare le VRFs associando ad esse i parametri RD, RT b) associare alle interfacce del PE le corrette VRFs c) configurare IGP tra PE e CE d) configurare la mutuale redistribuzione tra IGP e BGP e) configurare MP-BGP tra i PEs

Creazione VRF: Router(config)# ip vrf "vrf-name" (questo comando crea una VRF Table e una CEF FIB Table; "name" ha solo significato locale ed case sensitive) Router(config-vrf)# rd "route distinguisher" (ciascuna VRF caratterizzata da un RD di 64 bit che la IOS permette di esprimerlo in 48 bit ed in uno dei 2 seguenti formati: a) (ASN:nn) cio 16 bit AS seguiti da n decimale di 32 bit; ad es (65000:15) b) (A.B.C.D:nn) cio 32 bit IP ADDRESS seguiti da n decimale di 16 bit; ad es (192.168.34.5:15) Router(config-vrf)# route-target {import | export| both} Idem come l'RD, l'RT pu essere espresso in 2 formati: a) (ASN:nn) cio 16 bit AS seguiti da n decimale di 32 bit; ad es (65000:15) b) (A.B.C.D:nn) cio 32 bit IP ADDRESS seguiti da n decimale di 16 bit; ad es (192.168.34.5:15) N.B: Per identificare una VPN si pu anche utilizzare un VPN ID conservato nella struttura VRF Configurazione: Router(config)# ip vrf "vrf-name" Router(config)# vpn id "oui": "vpn-index" (dove "OUI" (Organizational Unique Identifier) un numero esadecimale di 3 ottetti; per esempio l'OUI per Cisco System 00-03-6B; dove "vpn-index" un numero esadecimale di 4 ottetti che identifica la VPN dentro la compagnia) Associazione VRF - Interfaccia: Router(config-if)# ip vrf forwarding "vrf-name" (associa la VRF ad all'interfaccia PE-CE; questo comando applicato all'interfaccia rimuove l'IP esistente che occorre dunque riconfigurare) Router(config-if)# ip address "ip_address" "mask"

Comando "ADDRESS FAMILY": Lato PE, sotto il processo IGP, sotto quello BGP e sotto quello MP-BGP di comunicazione occorre attivare le sessioni "address-family" appropriate:

1) Address-family vpnv4 (per attivare la sessione MP-IBGP tra i PEs) Router(config)# router bgp "as-number" Router(config-router)# address-family vpnv4 2) Address-family ipv4 vrf "vrf_name" (per attivare la sessione VRF IGP (o BGP) tra PE e CE ) Router(config)# router IGP or bgp "as-number" Router(config-router)# address-family ipv4 vrf "vrf-name"

Congigurazione sessione MP-IBGP tra PE routers (deve essere attiva tra le loopback interfaces): Router(config)# router bgp "as-number" Router(config-router)# no synchronization Router(config-router)# neighbor {"ip-address" | "peer-group-name"} remote-as "as-number"

Router(config-router)# neighbor {"ip-address" | "peer-group-name"} update-source Loopback0 (la loopback sar la sorg dei BGP update e il next-hop per le rotte vpnv4) Router(config-router)# no auto-summary (per disattivare la sommarizzazione automatica che di default abilitata) Router(config-router)# no bgp default ipva-unicast (per disattivare globalmente lo scambio delle rotte Internet con qualunque neighbor) Router(config-router)# no neighbor "ip-address" activate (per disattivare lo scambio delle rotte Internet con solo lo specificato neighbor) Router(config-router)# neighbor "ip-address" activate (per tenere attivo lo scambio delle rotte Internet con specifici neighbor a seguito della disattivazione globale) Router(config-router)# address-family vpnv4 Router(config-router-af)# neighbor {"ip-address" | "peer-group-name"} activate (per attivare il neighbor PE nello scambio delle rotte vpnv4) Router(config-router-af)# neighbor {"ip-address" | "peer-group-name"} next-hop-self (se tra CE e PE viene utilizzato l'EBGP) Router(config-router-af)# neighbor {"ip-address" | "peer-group-name"} send-community [standard | extended |both] (dalla Cisco IOS di default attivata l'opzione "extended" per attivare anche lo scambio delle "standard BGP communities" (ad es.QoS) occorre invece inserire manualmente il comando con l'opzionalit "both") Router(config-router-af)# exit-address-family

Configurazione routing statico per-VRF: Router(config)# ip route vrf "vrf-name" "prefix" "mask" ["type interface" | "next-hop-address"] (se l'interfaccia utilizzata non point-to-point il next-hop-address obbligatorio) Esempio: N.B: il routing statico PE-CE si utilizza solo quando esiste una singola connessione dal cliente al Provider Router(config)# ip route vrf Customer_A 10.0.0.0 255.0.0.0 10.250.0.2 Router(config)# ip route vrf Customer_A 0.0.0.0 0.0.0.0 10.250.0.2 Router(config)# router bgp 65001 Router(config-router)# address-family ipv4 vrf Customer_A Router(config-router-af)# redistribute static Router(config-router-af)# redistribute connect Router(config-router-af)# no auto-summary Router(config-router-af)# exit-address-family (se lato CE la default route gia presente liniezione della stessa dal PE non necessaria)

Configurazione RIPv2 come PE-CE Routing Protocol: (N.B: RIPv1 non supportato): Router(config)# router rip Router(config-router)# version 2 Router(config-router)# address-family ipv4 vrf "vrf-name" Router(config-router-af)# network "prefix" <--- network link PE-CE Router(config-router-af)# no auto-summary Router(config-router-af)# redistribute bgp "as-number" metric { "metric_value" | transparent} (l'opzionalit metric "TRANSPARENT" fa s che l'intera rete backbone MPLS VPN appaia ai CEs come un singolo hop; di default, nella redistribuzione del RIP in BGP la metrica hop count viene copiata nella metrica MED del BGP; l'opzionalit "TRANSPARENT" al contrario serve a ricopiare il MED nel RIP hop count quando il BGP viene redistribuito nel RIP) ! Router(config)# router bgp "as-number" Router(config-router)# address-family ipv4 vrf "vrf-name"

Router(config-router-af)# redistribute rip Router(config-router-af)# no auto-summary Router(config-router-af)# no synchronization Router(config-router-af)# exit-address-family N.B: sotto listanza address-family del RIP anzich redistribuire in esso le rotte BGP si potrebbe equivalentemente iniettare una default route al CE (se questultimo non ne in possesso), ossia avremmo potuto editare: Router(config)# router rip Router(config-router)# version 2 Router(config-router)# address-family ipv4 vrf "vrf-name" Router(config-router-af)# default information-originate Router(config-router-af)# distribute-list 10 out Router(config-router-af)# no synchronization Router(config-router-af)# exit-address-family Router(config)# access-list 10 permit 0.0.0.0

Configurazione EIGRP come PE-CE Routing Protocol Router(config)# router eigrp "process-id" (NB: il "process-id" non necessita di matchare con quello del CE) Router(config-router)# address-family ipv4 vrf "vrf-name" Router(config-router-af)# autonomous-system "as-number" (NB: "as-number deve matchare con l'AS del CE) Router(config-router-af)# network "prefix" ["subnet mask"] <--- network link PE-CE Router(config-router-af)# redistribute bgp "as-number" metric 10000 1000 255 1 1500 Router(config-router-af)# no auto-summary Router(config-router-af)# exit-address-family ! Router(config)# router bgp "as-number" Router(config-router)# address-family ipv4 vrf "vrf-name" Router(config-router-af)# redistribute eigrp "as-number" Router(config-router-af)# no auto-summary Router(config-router-af)# no synchronization Router(config-router-af)# exit-address-family

Configurazione OSPF come PE-CE Routing Protocol: Lato PE sorgente, la rotta OSPF viene redistribuita in MP-BGP senza il Metric e Metric type (internal, external 1, external 2) --> risultato: lato PE di destinazione, la stessa rotta MP-BGP viene redistribuita in OSPF sempre come esterna (LSA Type 5)--> risultato: i siti CE si vedono le rotte OSPF scambiate tra loro sempre come esterne e i PE vengono visti sempre come degli ASBR. Soluzione: implementare tra i PEs (nella backbone MPLS VPN) un'area OSPF denominata OSPF Superbackbone, che sta sopra all'area backbone 0. Con questa soluzione l'area superbackbone risulter del tutto trasparente ai routers CE ed in pi metric + metric type vengono propagati; i PE interconnettono le aree OSPF standard dei CE con la superbackbone OSPF ed agiscono in effetti da ABR, poich dopo la redistribuzione delle rotte interne OSPF in M-BGP, redistribuiscono da qu le rotte in OSPF come inter-area (tramite LSA Type 3). Analogamente se le rotte OSPF da redistribuire sono esterne, i PE agiscono come degli ASBR e redistribuiscono in OSPF tramite LSA Type 5 Ma a chi va il merito di propagare i parametri di OSPF metric type ed OSPF area lungo il BGP Backbone? Ad una BGP Extended community di 8 bytes (2 bytes di "Community Type=0x8000, 4 bytes di OSPF area, 1 byte di LSA Type,

1 bytes di Option per trasportare il metric type external). E il costo OSPF che fine fa? Viene copiato nell'attributo MED. Comandi di configurazione: Router(config)# router ospf "process-id" vrf "vrf-name" (al max si configurare 32 processi OSPF per-VRF) Router(config-router)# network "network" "wildcard-mask" "area-id" <--- network link PE-CE Router(config-router)# redistribute bgp "as-number" subnets Router(config-router)# exit Router(config)# router bgp "as-number" Router(config-router)# address-family ipv4 vrf "vrf-name" Router(config-router-af)# redistribute ospf vrf "vrf_name" [match [internal] [external-1] [external-2]] (senza il keyword "match" soltanto le rotte internal vengono redistribuite) Router(config-router-af)# no auto-summary Router(config-router-af)# no synchronization Router(config-router-af)# exit-address-family

OSPF Down Bit & Routing Bit: un altro meccanismo di prevenzione dei loops di routing (ricordare l'esistenza del SOO) che per interviene solo durante la redistribuzione dell'MP-BGP in OSPF facendo ricorso a 2 bit addizionali (down bit e routing bit) inseriti nel campo option dell'header LSA. Il Down Bit deve essere settato mentre quello di Routing no. Il loop di routing viene bloccato impedendo che la rotta BGP redistribuita in OSPF venga successivamente redistribuita a ritroso in BGP. Qual' il meccanismo che genererebbe il loop senza i settaggi opportuni dei 2 bit? Lato RX, la rotta redistribuita da MP-BGP in OSPF verrebbe ricevuta dal secondo PE attaccato alla medesima area sempre attraverso la rete OSPF (lungo i siti customers) e non lungo la sessione MP-IBGP, questo perch la distanza amministrativa dell'OSPF (110) vince sempre su quella dell'MP-IBGP (200) Il down bit viene settato solo dal primo PE di destinazione durante la redistribuzione della rotta da BGP in OSPF per far s che: 1) il secondo PE, grazie al down bit settato, in ingresso ignori sempre la rotta OSPF accettando solo quella BGP in modo che il trasporto avvenga SOLO sulla backbone MP-BGP, quindi ottimizzato (Vedere figure 5-111 e 5-113); non accettando pi la rotta OSPF non sorgerebbe mai il problema della redistribuzione a ritroso da OSPF a MP-BGP e quindi il rischio potenziale del loop Il routing bit non viene settato 2) il secondo PE non installi mai la rotta OSPF nella routing table anche se l'algoritmo SPF la seleziona come migliore rotta (vedere fig. 5-111 e 5-113) OSPF Tag Field: un meccanismo di prevenzione dei loops che interviene solo quando i PE stanno su domini OSPF differenti (con diversi "process-id") e le rotte OSPF esterne (O E1 od O E2) vengono propagate appunto fra domini OSPF distinti. Il down bit da solo non riuscirebbe pi a prevenire questo tipo di loop poich la sua informazione verrebbe persa quando il CE destinatario riceve la rotta OSPF redistribuendola da un dominio all'altro; risultato--> il PE di destinazione cattura la rotta OSPF senza pi il down bit e quindi invece di ignorarla la redistribuisce a ritroso in MP-BGP backbone provocando il loop (vedere fig. 5-114). L'OSPF Tag Field agisce SOLO su rotte non OSPF (OSPF esterne) e nell'LSA Type 5 o 7 viene settato solo dal primo PE di destinazione al valore del BGP AS del router che reditribuisce queste rotte dall'MP-BGP all'OSPF;la rotta OSPF esterna tra i domini OSPF viene appunto propagata con il valore del Tag Field settato al valore dell'AS e gli altri PE basandosi su questo valore del Tag Field filtrano la redistribuzione di suddette rotte in MP-BGP prevenendo i loops. Configurazione OSPF Tag: Router(config)# router bgp "as-number" Router(config-router)# address-family ipv4 vrf "vrf-name" Router(config-router-af)# redistribute ospf "source-process-id" tag "tag_value" Configurazione alternativa:

sui PE redistribuire in MP-BGP soltanto le rotte OSPF interne Sham Link: I CE su una stessa VPN si scambiano rotte sempre attraverso l'MPLS VPN Backbone. Ma quando queste sedi sono: a) della stessa area OSPF b) collegate anche direttamente con un link di backup (backdoor link) la comunicazione tra esse non avverr pi lungo la Backbone MPLS, ma solo lungo il link di Backup poich l'OSPF ovviamente preferisce l'instradamento Intra-Area a quello Inter-Area. Per riabilitare il routing lungo la Backbone MPLS VPN occorre: creare uno "sham link" ossia un link logico intra-area tra i 2 PE (fig. pag 5-120) e configurarlo con costo OSPF migliore di quello del link di backup in modo che la comunicazione avvenga sempre lungo lo "sham link" (fig. pag 5-120) configurazione Sham Link (pag. 5-124 con figura) 1) configurare tra i 2 PE lo sham link tramite le interfacce di loopbacks dedite al trasporto della VRF: Interface loopback0 ip vrf forwarding Cust_A ip address 10.2.1.1 255.255.255.255 2) sotto il processo OSPF per-VRF dopo aver redistribuito il BGP implementare il comando: Router(config-router)# area "area-id" sham-link "source-address" "destination-address" cost "cost" 3) sotto il processo BGP, annunciare la network dello sham link e redistribuire l'OSFP col match "internal" (route-type)

Configurazione BGP come PE-CE Routing Protocol: Router(config)# router bgp "as-number" Router(config-router)# address-family ipv4 vrf "vrf-name" Router(config-router-af)# neighbor "ip-address" remote-as "as-number" Router(config-router-af)# no synchronization Router(config-router-af)# neighbor "ip-address" activate (per attivare il CE nello scambio di rotte per-VRF) Router(config-router-af)# neighbor "ip-address" as-override (opzionale, verso il CE) (con la feature "as-override" viene permesso a siti customer di una STESSA VPN di utilizzare lo stesso AS privato o pubblico per schivare il meccanismo di AS Loop Detection, che scarterebbe le rotte con AS replicato. Come funziona? L'ISP (che sta in mezzo ai siti customers) nella rotta ricevuta rimpiazza l'AS customer con il proprio AS pubblico (o con i propri "n" AS se la rotta di origine trasporta "n" AS in prepended) pi un'altra copia, in modo che il sito customer di destinazione possa accettare la rotta. Router(config-router-af)# neighbor "ip-address" allowas-in "limit" (opzionale, verso il CE) (con la feature "allowas-in" viene permesso nel PE locale l'ingresso di BGP updates con numero di occorrenze AS non superiore al numero limite configurato. (vedere fig pag.5-144) Router(config-router-af)# neighbor "ip-address" maximum-prefix "maximum" [threshold] [warning-only] (opzionale, per limitare il numero di rotte da inviare al peer CE, soprattutto se questo soggetto ad attacchi di tipo DoS ) Router(config-af)# maximum-route "limit" ["warn-threshold"] [warning-only] (opzionale, configurato soto la VRF,per limitare il numero di rotte da importare nella VRF,

ricevute sia dai CE che da altri PE) Router(config-router-af)# maximum-path "n" (se si vuole attivare il load balancing tra "n" links) Router(config-router-af)# maximum-path ibgp "n"(se si vuole attivare il load balancing IBGP) Router(config-router-af)# no auto-summary Router(config-router-af)# no synchronization Router(config-router-af)# exit-address-family

Soluzione MPLS VPN HUB and SPOKE: nello scenario Hub and Spoke le sedi spokes (periferiche) comunicano tra di loro mai direttamente ma solo attraverso lHub; pertanto la sede Hub dovr importare le rotte di ogni sede spoke, mentre le sedi spokes dovranno importare rotte solo dalla sede Hub a) sul PE di raccolta della sede Hub occorrono 2 VRFs: una che importa rotte dai siti spokes, laltra che esporta rotte verso i siti spokes b) sui PEs di raccolta delle sedi Spokes occorre configurare una sola ed univoca VRF

PE router 'London_PE1' (connected to the hub-site CE router): ip vrf mjlnet_VPN1 rd 65535:100 route-target import 65535:100 ! ip vrf mjlnet_VPN2 rd 65535:500 route-target export 65535:500 VRF configuration on PE router 'Frankfurt_PE1' (connected to a spoke site CE router): ip vrf mjlnet_VPN rd 65535:100 route-target export 65535:100 route-target import 65535:500 VRF configuration on PE router 'NewYork_PE1' (connected to a spoke site CE router): ip vrf mjlnet_VPN

rd 65535:100 route-target export 65535:100 route-target import 65535:500 !

TROUBLESHOOTING VRFs: a) show run vrf "vrf-name" (per osservare tutte le parti di configurazione inerenti alla vrf specificata: definizione vrf, configurazione interfaccia PE-CE di ogni sede della vrf specificata, processo address-family ipv4 vrf sotto il bgp) a) show ip vrf [brief | detail | interfaces] [vrf_name] (vedere da pag 5-67 a pag 5-69) a) show ip vrf interfaces | include {"ip address" | "Vlan_id"} b) show ip protocols vrf "vrf_name" (fa visualizzare il protocollo di routing attivo nella VRF specificata) c) show ip route vrf "vrf_name" (per controllare quali rotte sono presenti nella VRF table, quindi se il PE ha iniettato nella VRF rotte dal CE) d) show ip bgp vpnv4 vrf "vrf_name" "ip_prefix" (per controllare se la rotta in questione del CE viene redistribuita in MP-BGP con gli opportuni RD ed RT attaccati, quindi se la rotta ipv4 viene convertita in prefisso vpnv4) d) show ip bgp vpnv4 all | include "ip_prefix" (per controllare che quel particolare prefisso IP venga convertito in vpnv4 a prescindere dalla vrf di appartenenza) d) show ip bgp vpnv4 vrf "vrf_name" neighbors (fa visualizzare i parametri di ogni BGP neighbor associato alla VRF specificata) d) show ip bgp vpnv4 vrf "vrf_name" neighbors "ip_address" (fa visualizzare i parametri del BGP neighbor specificato e associato alla VRF specificata: ad esempio se lo stato del BGP tra PE (locale) e neighbor CE "UP" ) d) show ip bgp vpnv4 vrf "vrf_name" neighbors "ip_address" advertised-routes (fa visualizzzare le rotte annunciate al neighbor specificato e relative alla vrf specificata) d) show ip bgp vpnv4 vrf "vrf_name" neighbors "ip_address" routes (fa visualizzzare le rotte ricevute dal neighbor specificato e relative alla vrf specificata) d) show ip bgp vpnv4 vrf "vrf_name" neighbors "ip_address" received-routes (fa visualizzzare le rotte ricevute dal neighbor specificato sia permesse sia negate e relative alla vrf specificata) (NB: ques'ultimo comando per richiede la presenza del comando "neigbor xxxx soft-reconfiguration inbound") d) show ip bgp vpnv4 vrf "vrf_name" summary (fa visualizzare tutti i BGP neighbors CE associati alla vrf specificata) d) sh run | section address family ipv4 vrf "name_vrf" d) sh run | section router bgp 1267 D) clear ip bgp vrf "name_vrf" neighbor "ip_address" soft { in | out} (per il refresh in od out) e) show cef interface "type_interface" (per verificare se CEF abilitato sull'interfaccia del PE) e) show ip cef vrf "vrf_name" (fa visualizzare la CEF Table associata alla VRF) f) show ip cef vrf "vrf_name" "ip_prefix" detail (per verificare la validit della FIB entry specificata e il label stack associato) f) show ip arp vrf "vrf_name" (per verificare la presenza dei mac-address limitrofi) g) show mpls forwarding-table vrf "vrf_name" (fa vidualizzare il label stack associato ad ogni rotta VPNV4 della specifica VRF) h) ping vrf "vrf_name" "ip_address" i) trace vrf "vrf_name" "ip_address" Esempio: Pesaro# traceroute vrf Customer_B 200.0.4.1 Type escape sequence to abort. Tracing the route to 200.0.4.1 1 10.1.1.21 [MPLS: Labels 25/28 Exp 0] 464 msec 280 msec 308 msec 2 10.1.1.5 [MPLS: Labels 22/28 Exp 0] 236 msec 572 msec 228 msec 3 200.0.4.1 108 msec * 100 msec

l) telnet "ip_address" /vrf "vrf_name" (per il telnet PE-CE)

SOO Extended Community: un attributo BGP Extended Community che serve a prevenire loops di routing e viene utilizzato in scenari dove i siti del customer sono in multihoming verso un singolo o pi ISP (invece per siti customers che sono in stub problemi di loop non possono mai sorgere). Con il SOO il PE ha la capacit di identificare esattamente il sito customer dal quale ha ricevuto la rotta impedendo il loop. Si configura attraverso l'utilizzo di una route-map per il settaggio del valore del SOO (deve essere unico per ogni VPN (VRF)); si applica poi la route-map a inbound o outbound EBGP updates

Router(config)# route-map "name" permit "seq" Router(config-route-)# match "conditions" Router(config-route-)# set extcommunity soo "value" (route-map per il settaggio del SOO dove "value" specificato come "as_number:network_number" oppure "ip_address:network_number") Router(config-router-af)# neighbor { "ip-address | "peer-group-name"} route-map "name {in | out}

Avanzate Feature VRF: a) Selective import: permette di importare solo determinate rotte dentro una VRF in base non solo all'RT ma anche in base ad altri parametri come attributi BGP, prefissi, subnet masks ecc. Questa funzione utilizzata in scenari Extranet, e meno in Intranet poich le rotte sono solitamente tenute sotto comune amministrazione. Occorre: 1) definire la route-map per matchare le rotte da importare 2) attaccare alla VRF l'import route-map col comando: Router(config-vrf)# import map "name"

Esempio (in uno scenario Extranet): ip vrf Site_A rd 115:317 route-target both 115:317 import map RTMAP ! access-list 20 permit 192.168.30.0 0.0.0.255 ! route-map RTMAP permit 10 match ip address 20 b) Selective export: permette di esportare rotte specifiche con pi RT attaccati (quello originale + quello addizionale) Occorre: 1) definire la route-map per matchare le rotte da esportare con l'addizionale RT settato.

2) attaccare alla VRF l'export route-map col comando: Router(config-vrf)# export map "name" Esempio: ip vrf Site_A rd 115:317 route-target both 115:317 export map RTMAP ! access-list 20 permit 192.168.30.0 0.0.0.255 ! route-map RTMAP permit 10 match ip address 20 set extcommunity rt 115:273 additive

Overlapping VPN Routing: Ogni enterprise network solitamente costituita da una sede centrale (hub) ed "n" sedi periferiche (spokes). La topologia di VPN Overlapping permette: - alle sedi periferiche di comunicare in Intranet con sedi periferiche della stessa compagnia e con la rispettiva sede centralizzata - alla sede centralizzata di comunicare in intranet con le sue sedi periferiche e nello stesso tempo di comunicare in extranet con la sede centralizzata di un'altra compagnia.

Esempio fig 6-16: 2 compagnie (A e B), 6 sedi in totale, 2 PE in totale (PE1 e PE2) con: sedi Spoke_A1, Spoke_B2, A_Central attestate su PE1 sedi Spoke_A2, Spoke_B1, B_Central attestate su PE2 dove: - le sedi Spoke_A1 e Spoke_A2 possono comunicare solo in Intranet tra di loro e con la corrispondente sede centrale Hub "sede A_Central" - le sedi Spoke_B1 e Spoke_B2 possono comunicare solo in Intranet tra di loro e con la corrispondente sede centrale Hub "sede B_Central" - le sedi A_Central e B_Central possono comunicare tra di loro in Extranet ed in Intranet con le rispettive sedi Spoke_A1/A2 e Spoke_B1/B2

Quindi in definitiva abbiamo 4 VPN E 6 VRF: VPN_A (2 VRF_A: una su PE1 e l'altra su PE2) VPN_B (2 VRF_B: una su PE1 e l'altra su PE2) VPN_A_Central (1 VRF_A_Central su PE1) VPN_B_Central (1 VRF_B_Central su PE2) Configurazione VRF_A: ip vrf VPN_A rd 123:750 route-target both 123:750 Configurazione VRF_B: ip vrf VPN_B rd 123:760 route-target both 123:760

Configurazione VRF_A_Central: ip vrf VPN_A_Central rd 123:751 route-target both 123:750 route-target both 123:1001 Configurazione VRF_B_Central: ip vrf VPN_B_Central rd 123:761 route-target both 123:760 route-target both 123:1001

Central Service VPN: La topologia di VPN Central Service permette ai customers di comunicare solo con i servers centralizzati su ISP e ai Servers di comunicare tra di loro e con qualunque customer; non permette ai customers di comunicare con altri customers. Esempio fig 6-28: 6 sedi in totale, 2 servers in totale, 4 PE in totale (PE1, PE2, PE-CS-1, PE-CS-2) con: 3 sedi attestate su PE1 3 sedi attestate su PE2 1 server attestato su PE-CS-1 1 server attestato su PE-CS-2 Quindi in definitiva abbiamo 7 VPN E 8 VRF: VPN-cust1, VPN-cust2, VPN-cust3, VPN-cust4, VPN-cust5, VPN-cust6 (6 VRF-cust: 3 su PE1 e 3 su PE2) VPN_set_server (2 VRF_set_server: 1 su PE-CS-1 e 1 su PE-CS-2) Configurazione VRF-cust_i: ip vrf Cust_i (con 1<= i <= 6) rd 123:10i route-target both 123:10i route-target export 123:193 route-target import 123:192 Configurazione VRF_set_server: ip vrf Server rd 123:199 route-target both 123:192 route-target import 123:193

Central Service VPN and Simple (Overlapping): Questa topologia di VPN ibrida poich combina insieme quella di tipo Service con quella di tipo Overlapping.

Esempio fig 6-36: 2 compagnie (A e B), 6 sedi in totale, 3 PE in totale (PE1, PE2, PE-CS) con: sedi Spoke_A1, Spoke_B2, A_Central attestate su PE1 sedi Spoke_A2, Spoke_B1, B_Central attestate su PE2 1 server attestato su PE-CS

dove: - le sedi Spoke_A1 e Spoke_A2 possono comunicare solo in Intranet tra di loro e con la corrispondente

sede centrale Hub "sede A_Central" - le sedi Spoke_B1 e Spoke_B2 possono comunicare solo in Intranet tra di loro e con la corrispondente sede centrale Hub "sede B_Central" - solo le sedi centralizzate A e B possono accedere al server Quindi in definitiva abbiamo 5 VPN E 7 VRF: VPN_A (2 VRF_A: una su PE1 e l'altra su PE2) VPN_B (2 VRF_B: una su PE1 e l'altra su PE2) VPN_A_Central (1 VRF_A_Central su PE1) VPN_B_Central (1 VRF_B_Central su PE2) VPN_Server (1 VRF_Server su PE-CS)

Configurazione VRF_A: ip vrf VPN_A rd 123:750 route-target both 123:750 Configurazione VRF_B: ip vrf VPN_B rd 123:760 route-target both 123:760 Configurazione VRF_A_Central: ip vrf VPN_A_Central rd 123:751 route-target both 123:750 route-target export 123:100 route-target import 123:101 Configurazione VRF_B_Central: ip vrf VPN_B_Central rd 123:761 route-target both 123:760 route-target export 123:101 route-target import 123:100 Configurazione VFR_Server: ip vrf VPN_Server rd 123:101 route-target both 123:101 route-target import 123:100

VPN di management dei CE routers: E' una VPN che permette al Provider di gestire da remoto i CE tramite le loro loopabacks; questo comporta di creare una VPN di management (attaccata sul PE-CS dove connesso il Server NMS) che importi le loopbacks sulla base dell'addizionale RT attaccato ad esse tramite il processo di export-map

Esempio fig 6-43: 2 compagnie (A e B), 4 sedi in totale, 3 PE in totale (PE1, PE2, PE-CS) con: sedi Spoke_A1, Spoke_B2 attestate su PE1 sedi Spoke_A2, Spoke_B1 attestate su PE2 1 server attestato su PE-CS

Quindi in definitiva abbiamo 5 VPN E 7 VRF:

VPN_A (2 VRF_A: una su PE1 e l'altra su PE2) VPN_B (2 VRF_B: una su PE1 e l'altra su PE2) VPN_Server (1 VRF_Server su PE-CS)

Configurazione VRF_A: ip vrf VPN_A rd 123:750 route-target both 123:750 route-target import 123:101 export map NMS Configurazione VRF_B: ip vrf VPN_B rd 123:760 route-target both 123:760 route-target import 123:101 export map NMS Configurazione Route-map ed ACL: route-map NMS permit 10 match ip address 20 set extcommunity rt 123:100 additive <-- (senza "additive" l'rt 123:100 ! sovrascrirebbe l'rt di origine access-list 20 permit 172.12.0.0 0.0.7.255 123:750 o 123:760)

Configurazione VFR_Server_NMS: ip vrf VPN_Server rd 123:101 route-target both 123:101 route-target import 123:100

Accesso ad Internet per un customer con servizio VPN MPLS: 3 possibili soluzioni: a) Accesso col routing globale (senza VPN dedicata) e tramite la sede centralizzata: con questo modello di accesso le sedi periferiche (CE periferici) entrano nel mondo Internet solo ed esclusivamente dalla sede principale (CE Central) unica ad essere equipaggiata di NAT/ Firewall. Dalla sede principale l'accesso contemporaneo ad Internet ed in Corporate VPN pu essere garantito in 3 modalit: - con 2 links fisici separati (soluzione meno adottata in quanto molto costosa per il cliente) - con 2 subinterfaces (incapsulamento Frame Relay o ATM), una dedita al trasporto del traffico VPN MPLS (quindi associata alla VRF VPN), l'altra adibita al trasporto delle rotte Internet. - con un'interfaccia Tunnel Il protocollo di routing PE-CE pu essere statico o dinamico col BGP Il protocollo di routing PE-IGW dinamico col BGP Esempio di configurazione PE dove attestata la sede centralizzata: 1) Routing Statico PE-CE: Configurazione sede CE centralizzata: (basta una default route, ovviamente da distribuire ai CE periferici) Configurazione PE: ip vrf CUST rd 100:1 route-target both 100:1 !

interface serial0/0 encapsulation frame-relay no ip address ! interface serial0/0.1 point-to-point frame-relay interface dlci 101 ip address 192.168.20.1 255.255.255.252 ip vrf forwarding CUST ! interface serial0/0.2 point-to-point frame-relay interface dlci 102 ip address 172.16.10.1 255.255.255.252 ! ip route 172.16.0.0 255.255.0.0 172.16.10.2 (per raggiungere le rotte LAN del cliente) ! router bgp 65100 network 172.16.0.0 (o "redistribute static") . . ! address-family ipv4 vfr CUST (sessione EBGP tra PE e CE solo per le rotte VPN) neighbor 192.168.20.2 remote-as 65502 neighbor 192.168.20.2 activate neighbor 192.168.20.2 override 2) Routing Dinamico PE-CE (ad esempio BGP): Configurazione sede CE centralizzata: (2 neighborships BGP verso il PE (una per l'accesso ad Internet, l'altra per l'accesso in MPLS VPN) + + redistribuzione in BGP dell'IGP o static route sede periferica) Configurazione sede CE periferica (rotte statiche verso il CE centralizzato o utilizzo dell'IGP): Configurazione PE: ip vrf CUST rd 100:1 route-target both 100:1 ! interface serial0/0 encapsulation frame-relay no ip address ! interface serial0/0.1 point-to-point frame-relay interface dlci 101 ip address 192.168.20.1 255.255.255.252 ip vrf forwarding CUST ! interface serial0/0.2 point-to-point frame-relay interface dlci 102 ip address 172.16.10.1 255.255.255.252 ! router bgp 65100 neighbor 172.16.10.2 remote-as 65502 . . ! address-family ipv4 vfr CUST (sessione EBGP tra PE e CE per lo scambio delle rotte VPN)

neighbor 192.168.20.2 remote-as 65502 neighbor 192.168.20.2 activate neighbor 192.168.20.2 override b) Accesso col global routing (senza VPN dedicata) e da ogni sede periferica: una soluzione molto costosa ed hard da implementare in quanto ogni CE necessiterebbe di 2 link o subinterfaces verso il PE N.B: Le soluzioni a) e b) comportano come svantaggio il fatto che i router PE diventano completamente detentori della Internet Routing Table c) Accesso con dedicata VPN e tramite sede centralizzata: con questo modello di accesso le sedi periferiche (CE periferici) entrano nel mondo Internet solo ed esclusivamente tramite la sede centralizzata (CE Central) unica ad essere equipaggiata del dispositivo NAT Firewall. Lato sede centralizzata l'accesso contemporaneo ad Internet ed in Corporate VPN pu essere garantito in 3 modalit: - con 2 subinterfaces con incapsulamento Frame Relay O ATM, una dedita al trasporto del traffico VPN MPLS (quindi associata alla VRF VPN), l'altra adibita al trasporto del traffico VPN Internet (quindi associata alla VRF Internet). Con questo modello di accesso i Provider Internet GW (PE-GW) nei confronti della backbone MPLS VPN risultano dei CE routers e ai PE dentro la VRF Internet annunciano solo una default route verso Internet pi le rotte locali (regionali); la VPN Internet completamente isolata dai routers P. Il PE sul quale attestato il CE Centralizzato collegato all'Internet GW (o agli Internet GW se c' ridondanza di accesso) tramite il PE-GW (o tramite i PE-GW se c' ridondanza di accesso)

VRF-LITE (Multi-VRF CE): chiamata anche Multi-VRF CE una tecnologia che consente di estendere la funzionalit VRF del PE al CE senza limpiego dellMPLS e dellMP-BGP

CE1 router ip vrf FINANCE rd 1:10 route-target both 1:10 ! ip vrf MGMT rd 1:20 route-target both 1:20 ! interface fastethernet 0/0 no ip address ! interface fastethernet 0/0.10 encapsulation dot1q 10 ip vrf forwarding FINANCE ip address 10.1.1.2 255.255.255.252

! interface fastethernet 0/0.20 encapsulation dot1q 20 ip vrf forwarding MGMT ip address 10.2.2.2 255.255.255.252 ! router ospf 10 vrf FINANCE network 10.1.1.0 0.0.0.3 area 0 capability vrf-lite ! router ospf 20 vrf MGMT network 10.2.2.0 0.0.0.3 area 0 capability vrf-lite

PE1 router ip vrf FINANCE rd 1:10 route-target both 1:10 ! ip vrf MGMT rd 1:20 route-target both 1:20 ! interface Loopback 0 ip address 1.1.1.1 255.255.255.255 ip ospf 1 area 0 ! interface fastethernet 0/0 no ip address ! interface fastethernet 0/0.10 encapsulation dot1q 10 ip vrf forwarding FINANCE ip address 10.1.1.1 255.255.255.252 ! interface fastethernet 0/0.20 encapsulation dot1q 20 ip vrf forwarding MGMT ip address 10.2.2.1 255.255.255.252 ! router ospf 10 vrf FINANCE network 10.1.1.0 0.0.0.3 area 0 redistribute bgp 100 subnets metric 10 ! router ospf 20 vrf MGMT network 10.2.2.0 0.0.0.3 area 0 redistribute bgp 100 subnets metric 10 ! router bgp 100 neighbor 2.2.2.2 remote-as 100 neighbor 2.2.2.2 update-source Loopback 0 ! address-family vpnv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community both exit-address-family

! address-family ipv4 vrf FINANCE redistribute ospf 10 metric 20 match internal external exit-address-family ! address-family ipv4 vrf MGMT redistribute ospf 20 metric 20 match internal external exit-address-family !

TE (Traffic-Engineering): Fare TE vuol dire ottimizzare le prestazioni di una rete in termini di banda. I routers di default inviano il traffico sempre sul percorso con migliore metrica, indovinato dal protocollo di routing utilizzato. Ma se la rotta principale non ha sufficienti risorse di banda per trasportare insieme pi flussi di traffico, bene utilizzare i percorsi alternativi anche se questi hanno metrica pi bassa. TE serve ad impedire situazioni in cui parti di un ISP risultano sovrautilizzate (congestionate) mentre altre invece risultano sottoutilizzate. TE pu essere implementato a livello 2 o 3. TE col modello Overlay di Livello 2: con il livello 2 viene fornita una rete full-mash di circuiti virtuali (PVC o SVC) tra i routers; fare TE a livello 2 vuol dire selezionare i link opportuni per trasportare vari tipi di traffico. Fare TE a livello 2 per non consigliabile perch comporterebbe questi svantaggi: a) gestire insieme il livello 2 (Switch + PVC o SVC) e il livello 3 (IGP routing) b) gli switches non hanno alcuna conoscenza del livello 3 IP; se capita congestione a livello 2, gli switches devono avere l'abilit di scartare pacchetti o di richiedere lo scarto. c) problemi di scalabilit IGP per rete magliata

TE col modello di livello 3: Per instradare non pi solo lungo il percorso con migliore metrica occorre utilizzare il modello MPLS TE creando i Tunnel LSP con l'impiego del protocollo RSVP (Resource Reservation Protocol) Il tunnel LSP unidirezionale ed un'aggregazione di flussi dati che condividono alcuni attributi (banda, latenza, DSCP) Va definito tra 2 endpoints: a) router Head-End (sorgente), ossia il router dove viene configurato il Tunnel b) router Tail-End (finale), ossia il router dove il Tunnel termina Tra 2 endpoint si possono definire pi Tunnels LSP e i pacchetti inviati lungo ogni Tunnel contengono un stack di 2 labels: la prima identifica il Tunnel LSP, la seconda identifica la customer route che viene definita sul router Tail-End. Per poter mettere in piedi il Tunnel LSP TE occorre per: 1) lato router sorgente definire il percorso interno che identifica il Tunnel, ossia la sequenza di next-hop-addresses (routers LSR) che costituiscono il Tunnel LSP; e questo lo si pu fare o dinamicamente con il CSPF (versione dell'algoritmo Dijkstra SPF che impiega OSPF o IS-IS nella tecnologia MPLS TE) o esplicitamente (con la configurazione manuale del percorso) N.B: il CSPF determina come percorso quello con minor costo e che soddisfa la banda minima richiesta. Per poter far questo OSFP e IS-IS utilizzano delle estensioni per il supporto del TE (rispettivamente LSA Type 10 e TLV 22) N.B: con il percorso esplicito viene selezionato il percorso anche con costo non minimo, importante che cmq soddisfi la banda richiesta Perch in MPLS TE si possono utilizzare solo OSPF e IS-IS? perch sono gli unici protocolli di routing che permettono ad ogni nodo una conoscenza completa della rete 2) segnalare il percorso creato al resto dei nodi con il protocollo RSVP

Attributi associati al traffico trasportato dal Tunnel sono: a) parametri di traffico (banda minima richiesta e/o latenza) b) percorso dinamico (IGP) o statico c) Link Affinity String per permettere all'amministratore di rete di includere o escludere certi links nella rete d) Adattabilit, ossia la capacit di riottimizzare il Tunnel TE su un percorso migliore e) Assegnazione del livello di priorit al Tunnel (con valore da 0 a 7) per sottolineare l'importanza del Tunnel stesso f) Resilience, ossia come il Tunnel reagisce al fallimento di una network (tenta di reinstradare il traffico o no?) Se a seguito del fallimento di una network si decide di reinstradare il traffico occorre utilizzare la procedura Fast ReRoute (FRR) che per reinstradare impiega un Tunnel di Backup. Lato router sorgente (PE router) va introdotto il comando "Tunnel mpls traffic-eng fast-reroute" (sotto l'interfaccia del Tunnel primario); sul router in downstream (P router) invece va configurato il Tunnel secondario in maniera esplicita e in pi sotto l'interfaccia a rischio di fallimento va configurato il comando "mpls traffic-eng backup-path Tunnel "Tunnel-number" " RSVP: una volta selezionato il miglior percorso IGP, questo essendo noto solo al router sorgente, deve essere segnalato anche ai routers intermedi fino a destinazione. E il protocollo demandato alla segnalazione del path (sequenza next-hop) l'RSVP. Fasi di lavoro dell'RSVP: 1) Path Setup: il router sorgente invia un "PATH message" lungo i routers intermedi fino a destinazione contenente la sequenza di LSRs; 2) Trunk Admission Control: ogni router intermedio alla ricezione del "Path message" controlla se c' banda disponibile richiesta da riservare; se c' sufficiente banda allora l'RSVP viene accettato, altrimenti il "Path Setup" viene abbattuto. 3) RESV Message: quando il router di terminazione del Tunnel riceve il "PATH message", esso nell'opposta direzione lungo il router sorgente invia un RESV message; ciascun router intermediario che riceve il messaggio riserva banda richiesta e alloca le labels. Il Tunnel LSP TE diventa up solo quando il messaggio RESV arriva al router sorgente! Autoroute: una feature di Cisco IOS Software che permette al Tunnel TE di apparire nella IP Routing Table e come interfaccia direttamente connessa, ma solo lato router sorgente (gli altri routers lungo l'LSP non vedranno mai il Tunnel) Grazie a questa feature il router sorgente vedr il router finale come diretto neighbor attraverso il next-hop "Tunnel" (vedere fig 8-35) Esempio di configurazione TE: Router(config)# ip cef (va messo su ogni router PE e P della rete MPLS) Router(config)# mpls traffic-eng tunnels <-- per abilitare l'RSVP globalmente (va messo su ogni router PE e P della rete MPLS) Router(config)# interface serial 0/2 Router(config-if)# mpls ip (va messo su ogni router PE e P della rete MPLS) Router(config-if)# mpls traffic-eng tunnels <-- per abilitare l'RSVP nell'interfaccia (va messo su ogni router PE e P della rete MPLS) Router(config-if)# ip rsvp bandwidth ["interface-kbps"] ["single-flow-kbps"] <- max quantit di banda che pu essere Router(config-if)# exit allocata dai flussi RSVP (va messo su ogni router PE e P della rete MPLS) Router(config)# interface tunnel "number" (va fatto solo sul PE sorgente del Tunnel) Router(config-if)# description " R2 ->> R5 " Router(config-if)# ip unnumbered Loopback 0 Router(config-if)# tunnel destination "router-id" Router(config-if)# tunnel mode mpls traffic-eng Router(config-if)# tunnel mpls traffic-eng autoroute announce Router(config-if)# tunnel mpls traffic-eng priority "setup-priority" "hold-priority"<-- per assegnare la priorit al Tunnel (valore da 0 a 7, pi il valore basso pi la priorit alta) Router(config-if)# tunnel mpls traffic-eng bandwidth "bandwidth-kbps" <- banda richiesta per il Tunnel RSVP Router(config-if)# tunnel mpls traffic-eng path-option "number" {dynamic | explicit {name "path-name" |"path-number"}} [lockdown] dove:

"number": viene utilizzato quando vengono configurati pi percorsi (ha priorit sempre quello con "number" pi basso) "dynamic": vuol dire che il path LSP viene calcolato dinamicamente explicit name "path-name" : nome del percorso esplicito explicit "path-number" : numero del percorso esplicito lockdown : il percorso non pu essere riottimizzato Router(config-if)# exit Router(config)# router ospf 1 <--- per il routing dell'ISP Core (va fatto su ogni router PE e P) Router(config-router)# router-id 10.10.0.2 Router(config-router)# mpls traffic-eng router-id Loopback0 !-- it's a GOOD IDEA use the same loopback of MP-BGP Router(config-router)# mpls traffic-eng area "area-id" Router(config-router)# network 10.0.0.2 0.0.0.0 area "area-id" Router(config-router)# network ........ ! Router(config)# ip explicit-path {name "path-name" | "path-number"} [ enable | disable] Router(config-if)# next-address "ip-address1" Router(config-if)# next-address "ip-address2" . . Router(config-if)# next-address "ip-addressN" TROUBLESHOOTING TE: a) show ip rsvp interface (per verificare se le interfacce detengono le info di RSVP configurato) b) show mpls traffic-eng tunnels brief (mostra info dettagiate sui Tunnel presenti) PE1-AS1# show mpls traffic-eng tunnels brief Signalling Summary: LSP Tunnels Process: running RSVP Process: running Forwarding: enabled Periodic reoptimization: every 3600 seconds, next in 3206 seconds Periodic FRR Promotion: Not Running Periodic auto-bw collection: every 300 seconds, next in 206 seconds TUNNEL NAME PE1-AS1_t0 PE1-AS1_t1 DESTINATION 10.10.10.103 10.10.10.103 UP IF Se3/0 Se2/0 DOWN IF STATE/PROT up/up up/up

Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails c) show mpls traffic-eng autoroute (per verificare se il tunnel annunciato in IGP con inclusa interfaccia, destinaz e banda) d) show ip cef "network" (per verificare se il traffico IP viene inviato lungo il Tunnel TE) e) show ip cef vrf "vrf-name" "network" (per verificare se il traffico VPN viene inviato lungo il Tunnel TE)