> >>Ciao Nicola > >>Innanzitutto ti ringrazio per la risposta articolata e ricca di spunti . >>Purtroppo però ho bisogno di qualche ulteriore chiarimento , nonostante ormai >>mi sono >>inserito in questo settore da più di 4 , anni ancora non avevo mai sentito >>parlare >>di ''pseudowire Martini'' , d'altronde se provo ad immaginarli come circuiti >>di livello 2 >>che partono da un punto A ed arrivano in un punto B senza che gli n nodi >>intermedi siano >>visibili a chi si posiziona in A o in B , la cosa trova ancora meno >>spiegazione .
Visto che conosci MPLS da tempo, e sicuramente avrai utilizzato le Layer3-VPN, ti propongo un'analogia per spiegarti il meccanismo usato nei PW. In una soluzione di backbone semplice "standard CISCO" quindi con LDP e senza Traffic Engineering, il traffico delle L3-VPN in transito nel backbone utilizza 2 label per garantire il corretto inoltro del traffico: La label esterna allocata tramite LDP identifica il PE, mentre quella interna, assegnata tramite Multiprotocol BGP, rappresenta la sottorete (FEC) nel VRF di appartenenza. La differenza di un router P da un PE e' quella di non avere nessuna conoscenza di MP-BGP e quindi delle label (interne) associate alle L3-VPN. Il traffico L3-VPN e' trasportato senza problemi attraverso i router P in quanto la label interna non e' mai analizzata lungo il percorso. E' solo il PE di destinazione, responsabile dell' allocazione ed "annuncio" di questa label, che la utilizza per effettuare l'inoltro del pacchetto nell'interfaccia associata al VRF. Ipotizziamo ora l'attivazione sullo stesso backbone di una L2-VPN ( circuito layer-2 standard Martini ) . Anche in questo caso l'inoltro del traffico ha bisogno di due label: la label esterna identifica il PE dove termina il PW allocata con lo stesso meccanismo delle L3-VPN, e la label interna che identifica il pseudowire. Questa Label e' conosciuta esclusivamente dai due PE coinvolti nella realizzazione del circuito, lo standard Martini prevede LDP, ma non essendo direttamente connessi e' necessaria una sessione diretta (targeted appunto) Riassumendo: l'analogia tra i due tipi di VPN si compone di: - due label per il corretto inoltro dei pacchetti - la label "esterna" che identifica la destinazione nel backbone, allocata tramite LDP - la label "interna" di VPN ( L2 o L3 ) allocata direttamente tra i due PE tramite Targeted LDP o MP-BGP Se quindi hai chiaro il trasporto delle L3-VPN nel backbone ed il differente ruolo delle due label sui router P e PE, l'analogia proposta dovrebbe chiarirti il funzionamento dei PW e perche' possono funzionare senza che i nodi intermedi conoscano quello che trasportano, oltre alla necessità di una Targeted LDP session. Ora per crearti un po' di confusione ti segnalo che esiste un'alternativa ai PW Martini che utilizzano MP-BGP come protocollo di segnalazione anche per le L2-VPN. Si tratta dello standard proposto da Kompella che pero' non e' implementato su piattaforma CISCO. > >>Inoltre per i casi a cui facevi riferimento sono quelli in cui i router P >>potrebbero non avere ‘’rotta’’ o una entry nella LFIB ,per una determinata >> destinazione o ‘’overlapping vrf ip address’’ ? >> Bisogna in qualche modo spostare funzionalità tipiche di un PE su un router >> P ? > La situazione che ti ho accennato nella precedente mail, e che si risolve configurando esplicitamente una LDP targeted session, e' la mancata conoscenza di tutte le label necessarie al completamento della LFIB. Il protocollo di routing solitamente utilizzato per la realizzazione del backbone e' link-state, con una tabella di routing che contiene tutte le "rotte" del backbone ( solitamente le loopback di P e PE + tutte le interfacce di comunicazione ). Il problema che risolve la targeted ldp session e' la mancanza di label per tutte le possibili destinazioni di traffico MPLS. Ovviamente stiamo parlando esclusivamente della label "esterna", le vpn a questo livello non centrano. Non si tratta quindi di spostare funzioni del PE al router P, ma di fare in modo che non si inneschi un meccanismo di POP della Label esterna che esporrebbe la seconda label al lookup su di un router diverso da quello di destinazione, con risultati imprevedibili. Si tratta comunque di situazioni limite e che si incontrano raramente. > >>Poi approfitto per farti un ' ulteriore domanda visto che ti vedo ferrato >>sull' argomento . >>Che testi consigli per approcciarsi all' MPLS ? >>I ho iniziato a guardare '' mpls fundamentals (cisco press)'' , ma poi mi >>sono reso conto che nella trattazione >>di alcuni argomenti è abbastanza oscuro ,così sono passato a ''MPLS e VPN >>architectures Volume I -CCIP ed.'' >>questo lo trovo molto più chiaro ma per sua natura è incompleto e rimanda al >>volume 2 che per altro >>non integra ,ma riprende l 'intero discorso e che almeno stando a quello che >>è scritto >>nella prefazione deve essere letto solo dopo aver studiato il volume 1 . >>A questo punto stavo pensando di dare uno sgardo al Tofoni ,visto che tra le >>altre cose >>è pensato oltre che scritto in Italiano . >>Tu cosa mi consigli ? Il mio obiettivo a medio raggio è passare l' esame >>cisco relativo all' MPLS , >>vista la crisi occupazionale dell' ultimo periodo meglio avere una maggiore >>visibilità , >>ma poi andando oltre vorrei avere una conoscenza esaustiva dell' argomento >>evitando che la certificazione >>possa trasformarsi in un contenitore mezzo vuoto come a volte può accadere . >>Rispetto a queste esigenze , che testi ti senti di consigliarmi ? > > > Grazie > Gianluca > "MPLS Fundamental" mi piace molto, ma l'ho studiato dopo essere passato da "MPLS e VPN Architecture" I e II. non e' male nemmeno "MPLS configuration on IOS software". Purtoppo il Tofoni non l'ho letto. non dimenticare il passaggio obbligatorio dalla documentazione ufficiale CISCO -> http://www.cisco.com/en/US/customer/docs/ios/mpls/configuration/guide/12_2sr/mp_12_2sr_book.html Se poi ti piace l'argomento, sono disponibili gratuitamente i 4 libri per le certificazioni juniper-> http://www.juniper.net/us/en/training/certification/books.html che affrontano molto bene anche gli aspetti teorici, mostrando una diversa implementazione, che ad esempio per gli aspetti di TE trovo piu' semplice. Se ti sono rimasti dei dubbi, possiamo anche trovarci in IRC su #areanetworking una di queste sere, comunicare in modo interattivo e' piu' semplice. buono studio ciao nicola -- Nicola Modena - CCIE #19119, JNCIS-M/T, CCSE
_______________________________________________ http://cug.areanetworking.it [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
