Il giorno 15 luglio 2009 13.12, Gianluca Mazzei<[email protected]> ha scritto: >> MPLS E TARGETED SESSIONS >> >> Qualcuno di voi ha mai usato sessioni targeted per risolvere una specifica >> problematica ? >> Guardando alle possibilità ed opzioni di configurazione che l' MPLS offre , >> trovo che >> questo escamotage sia molto simpatico ma a dirla tutta non ho ancora capito >> bene quale >> sia l' ambito di utilizzo e la reale utilità . >> >> L' opzione somiglia per alcuni versi al virtual link dell' OSPF , ma il >> virtual link nasce >> da un esigenza reale , ovvero a fronte di un comportamento del protocollo >> stesso >> che impone il transito delle informazioni inter-aree attraverso l' area zero >> , >> e che di conseguenza obbliga tutte le aree ad avere almeno un link diretto >> con il core , >> laddove questo collegamento diretto fisico sia impossibile da realizzare , >> lo si sostituisce con uno logico , appunto il virtual link . >> >> Ma nell' MPLS quale può essere l' esigenza che giustifichi la presenza >> di una sessione targeted se non condizionare il traffico cosa che peraltro >> si riesce a fare settando altri parametri e ragionando con più granularità >> per specifiche classi , sottoreti o FEC , invece che per hops ? >> >> >>Gianluca > > _______________________________________________ > http://cug.areanetworking.it > [email protected] > http://ml.areanetworking.it/mailman/listinfo/cug >
ciao, credo tu ti riferisca alle LDP targeted session… Innanzitutto tieni conto che LDP e’ un protocollo di segnalazione e non di routing. Nell’impiego comune annuncia l’associazione label-FEC ai neighbor. Questi le raccolgono nella LIB (Label Information Base), dove per ogni FEC (Forwarding Equivalence, banalizzando per i meno esperti: sottorete) puo' esistere piu' di una label. E’ poi compito del protocollo di routing, attraverso il suo algoritmo best-path, la scelta delle label da usare per rappresentare la FEC nella FIB e nella LFIB, che finalmente controllano l’effettivo inoltro del traffico ip o mpls. Aggiungo inoltre che il Control-Plane e’ solitamente realizzato con protocolli link-state (OSPF o IS-IS) che eliminano il “ragionamento per hop” e mantengono una visione del routing uniforme per l’intera area o livello. Spero di averti meglio chiarito l’utilizzo di LDP e del perche’ non e’ possibile utilizzarlo direttamente per modificare l’inoltro del traffico. Quest’esigenza e’ solitamente affidata alle funzionalità TE (traffic-engineering) in grado di allocare label e popolare la LIB (in questo caso con signaling RSVP ) per poi collaborare attivamente con il protocollo di routing al mantenimento di FIB ed LFIB. Per ripondere alla tua domanda…in alcuni casi LDP e’ utilizzato per il signaling end-to-end, e quindi richiede una sessione tra router solitamente non adiacenti. Un esempio su tutti e’ rappresentato dai pseudowire Martini, dove la segnalazione e’ appunto basata su LDP. Viene utilizzata una LDP Targeted Session per lo scambio della label associate ai psudowire, ma l’attivazione e’ effettuata in modo implicito, senza quindi richiederne una specifica configurazione. Se sei curioso prova a fare uno “show mpls ldp neighbor | i Targeted” su un router dove sono attivi dei pseudowire e dovresti trovarne di attive. Esistono tuttavia alcuni rari casi dove e’ richiesta una esplicita configurazione, solitamente in presenza esclusiva di Traffic Engineering, dove il popolamento della LIB e’ affidato al solo RSVP e quindi potrebbe non contenere tutte le informazioni necessarie al completamento della LFIB ( come in presenza di TE Tunnel parziali o che terminano in router P). In questo caso una LDP Targeted Session può colmare le lacune della LIB, e successivamente della LFIB, che potrebbero pregiudicare il corretto inoltro di tutto il traffico mpls in transito. L’argomento diventa un po’ complesso, e richiede una discreta conoscenza dei meccanismi su cui si basa mpls, ma spero di esserti stato di aiuto nel chiarirti le idee, e di aver risposto alla tua domanda. Se vuoi approfondire ulteriormente non ci sono problemi. ciao nicola -- Nicola Modena - CCIE #19119, JNCIS-M/T, CCSE
_______________________________________________ http://cug.areanetworking.it [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
