Appendice B - Configurazione dei
router
impiegati nel
testbed
In figura è mostrata la topologia del testbed MPLS utilizzato nella valutazione sperimentale
presentata nei Capitoli 3 e 4. La configurazione fisica del testbed ha utilizzato 2 Router
Juniper M10, i quali, attraverso il ricorso a logical-router, provvedevano a emulare i 5 router
mostrati in figura: in particolare mentre i 2 core router erano le istanze principali dei router
fisici, i 3 edge router erano logical-router
Configurazione di
MPLS-TE
Di seguito viene riportata la configurazione caricata su tutti i router impiegati nel testbed
(compresi i logical-router), allo scopo di attivare correttamente MPLS-TE, per l’instaurazione
CSPF-routed dei LSP:
protocols ospf {
// Attiva su tutte le interfacce le estensione TE a OSPF, necessarie // per la distribuzione in tutto il dominio delle informazioni per // la costituzione del TED
traffic-engineering;
// Imposta un unico dominio OSPF area 0.0.0.0 {
interface all; }
}
protocols rsvp {
// Attiva su tutte le interfacce la segnalazione RSVP, comprese le // estensioni Explicit routing, per la segnalazione dei LSP
// CSPF-routed interface all }
protocols mpls {
// Inserisce i LSP nella tabella di forwarding inet.0, abilitando // l’ingress router ad inviare traffico IGP su un LSP attivo
traffic-engineering bgp-igp;
// Impostazione del generico LSP CSPF-routed label-switched-path <nome> {
to <egress-router>
// Forza l’ingress router ad inviare sul LSP (se attivo) il // traffico diretto a questi indirizzi. Nel caso del LSP stream
// viene inserito l’indirizzo completo del client
install <destination/netmask>
bandwidth <parametro di banda>
priority <setup> <hold>
}
interface all; }
Qualità del servizio
Poiché l’architettura del router Juniper M-10 non prevede che i logical-router possano gestire
le funzionalità di QoS, solo i due router principali Core1 e Core2 sono stati abilitati alla
gestione della QoS mediante architettura MPLS-DiffServ, allo scopo di garantire la banda al
traffico MPLS inviato sui LSP CSPF-routed; su entrambi è stato configurato il medesimo
sistema per far si che su ciascuna interfaccia di uscita il traffico MPLS venga inoltrato su una
coda con classe di servizio Expedited Forwarding, mentre il traffico IP viene inviato su una
coda Best Effort. Ciascuna coda è servita con disciplina FIFO, mentre lo scheduler provvede a
servire le code con un criterio di priorità. La configurazione è illustrata in Figura.
All’interfaccia di ingresso tutto il traffico (IP e MPLS) è assegnato da un classificatore di
default alla classe AF. Tale classificatore è stato implementato su tutte le interfacce dei router
di core attraverso la seguente configurazione:
class-of-service {
interface <ingress-interface-id> {
forwarding-class expedited-forwarding; }
}
Dopo essere inviato sull’interfaccia di uscita opportuna dalla switching fabric, il solo traffico
IP viene degradato a traffico best-effort:
firewall{
filter ipfilter { term default {
then {
forwarding class best-effort; } } } } interface <egress-interface-id> { family inet{ filter{ output ipfilter; } } }
Infine si configura lo scheduler sull’interfaccia di uscita in modo da assegnare, attraverso un
meccanismo di priorità, al traffico MPLS EF tutta la banda di cui ha necessità, lasciando la
banda residua al traffico IP BE:
class-of-service {
// Definisce la coda a cui associare ciascuna classe di servizio. Il // router Juniper M10 gestisce fino a 4 code per interfaccia.
forwarding-classes{
queue 1 expedited-forwarding;
queue 4 best-effort;
}
// Definisce le discipline di scheduling per ciascuna classe di
// traffico: in particolare assegna priorità alta al traffico EF MPLS // lasciando priorità bassa a quello IP BE
schedulers { BEsched {
EFsched { priority strict-high; } } scheduler-maps { mappa {
forwarding-class expedited-forwarding scheduler EFsched; forwarding-class best-effort scheduler BEsched; }
}
// Assegna alle interfacce di uscita le discipline di // scheduling opportune
interface <egress-interface-id> { scheduler-maps mappa;
} }
Limitazione del traffico in ingresso
al
LSP
Di seguito si va a descrivere come è stata implementata la limitazione del traffico in ingresso
al LSP secondo quanto specificato nel Capitolo 1 - Ingresso nel dominio MPLS-DiffServ. In
particolare alle interfacce di ingresso dei due router E1 e E2 alle quali sono connessi i server è
stato applicato un filtro che scarta tutti i pacchetti che eccedono il parametro di banda del LSP
su cui dovrebbero essere inviati.
firewall filter inLSP{
// Invia al policer limitLSP il traffico in ingresso al LSP term inLSP {
// Riconosce i pacchetti in ingresso al LSP mediante // l’indirizzo destinazione e li invia al policer
match-conditions{
destination-address <client host address>;
} then { policer limitLSP; } }
// Ignora altro traffico term default { then { accept; } } }
// il policer scarta i pscchetti che eccedono i parametri di banda // del LSP
firewall policer limitLSP
if-exceeding {
bandwidth-limit <banda del LSP (10m)>; burst-size-limit 1m; } then { discard; } }
// il filtro viene applicato all’interfacci di ingresso al quale si // connette il server interface <ingress-interface-id> { family inet{ filter{ input inLSP; } } }
