Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Ingegneria
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Giorgio Ventre » 8.Routing Inter-dominio con BGP4 - Parte IV


Indice della lezione

  • Organizzazione di Internet
  • Principi fondamentali di BGP
  • BGP in large networks
    • L’esigenza di utilizzare iBGP
    • Confederazioni e riflettori di rotte (Route Reflectors)
    • Le dinamiche del BGP
  • Ingegneria del traffico intra-dominio con BGP

Le dinamiche di BGP

  • Nel caso ideale, i router BGP dovrebbero essere stabili ed un router BGP dovrebbe solo di rado ricevere messaggi
    • In Internet, le cose sono leggermente più semplici
  • Il progetto “BGP beacon” nasce lo lo scopo di comprendere meglio le dinamiche di BGP

Uno sguardo attento ai messaggi BGP


Perché così tanti messaggi BGP?

  • Internet è grande e complessa
  • Un piccolo evento remoto può comportare l’invio di messaggi BGP a tutti i router BGP

Cambiamenti nelle politiche di BGP

  • In che modo sarebbe possibile modificare le politiche di import/export utilizzate da un router BGP?
  • Soluzioni da inesperti
    • Cambiare i filtri di import/export
    • Fermare le sessioni BGP
      • I peer potrebbero aver bisogno di inoltrare una grossa quantità di messaggi Withdraw!
    • Ristabilire le sessioni BGP
      • Il router BGP riceverà e processerà una grossa quantità di messaggi di Update!

In che modo cambiare i filtri di export senza alcun intoppo?

  • Criterio
    • Aggiornare i filtri di export che bisogna modificare
    • Utilizzare un filtro modificato per ogni sessione BGP
      • Eseguire una scansione delle tabelle di routing BGP per determinare i messaggi BGP inoltrati in accordo ai nuovi filtri
      • Inoltrare i messaggi BGP richiesti

In che modo cambiare i filtri di import senza alcun intoppo?

  • Prima soluzione
    • Memorizzare tutti i messaggi di Update (non modificati) ricevuti da ogni peer prima di applicare il filtro di import
    • Quando un filtro di import cambia
      • Applicare il nuovo filtro ai messaggi di Update precedentemente memorizzati
    • Problema
      • Eccessivo consumo di memoria

In che modo cambiare i filtri di import senza alcun intoppo?

  • Seconda soluzione
    • Non memorizzare i messaggi di Update ricevuti
    • Quando un filtro di import cambia
      • Inoltrare il messaggio di ROUTE_REFRESH BGP per richiedere al peer interessato di inoltrare nuovamente tutti i suoi messaggi
      • Applicare il nuovo filtro ai messaggi BGP ricevuti dopo la trasmissione del ROUTE_REFRESH

Un’altra ragione per i messaggi BGP

  • In alcuni casi, BGP può tentare vari percorsi
  • I router processeranno il messaggio di Withdraw e … indicheranno router alternativi ai loro peer

Un’altra ragione per i messaggi BGP

  • C processa innanzitutto il messaggio di withdraw
  • A apprende una rotta peggiore ma valida verso 1/8
  • C inoltra messaggi di withdraw a B a partire da quando il percorso C-R segnalato precedentemente non è più disponibile e C ha chiuso la rotta via B

Un’altra ragione per i messaggi BGP

  • B inoltra degli avvisi
  • C apprende una rotta più lunga verso 1/8
  • B inoltra messaggi di withdraw ad A a partire dal momento in cui l’unica sua rotta è quella che passa attraverso A

Un’altra ragione per i messaggi BGP

  • A inoltra delgi avvisi
  • A può solo inoltrare un messaggio di withdraw a C e B da quando entrambi compaiono nell’ASPath delle loro rotte per raggiungere 1/8
  • B e C apprendono che le loro rotte verso A sono non valide

Come ridurre il numero di messaggi BGP non necessari?

  • Evitare di trasmettere messaggi troppo di frequente
    • Due messaggi di UPDATE inoltrati dal medesimo peer BGP che annuncino la stessa rotta potrebbero essere separate da una quantità di secondi almeno pari al MinRouteAdvertisementInterval (MRAI)
      • Il valore di default per l’MRAI è di 30 secondi
    • Vantaggi
      • Riduce il numero di messaggi BGP non necessari
    • Svantaggi
      • Può ritardare la propagazione di messaggi BGP e di conseguenza decrementare il tempo di convergenza
        • Per tale ragione, l’MRAI è solitamente disabilitato nelle sessioni iBGP

BGP dumpening

  • Ossevazione
    • Molti router non cambiano di frequente
    • Una piccola frazione di router è responsabile della maggior parte dei messaggi BGP scambiati
      • Possiamo penalizzare tali router instabili per preservare quelli stabili?
  • Criterio
    • Associare un contatore di penalità ad ogni router
      • Incrementare il contatore ogni volta che un router cambia
      • Utilizzare un decadimento incrementale per decrementare in maniera lenta il contatore di penalità
    • I router con una penalità troppo elevata vengono soppressi

Parametri per il dumpening di BGP

Parametri principali

  • Penalità per i messaggi BGP
    • Penalità per messaggi withdraw
    • Penalità per modifica di attributi in messaggi di Update
    • Penalità per messaggi di Update
  • Soglia di taglio
    • Penalità per valori al di sopra dei quali la rotta è soppressa
  • Soglia di riutilizzo
    • Penalità minima per il riutilizzo di una rotta
  • Intervallo
    • Per il decadimento esponenziale
  • Tempo massimo di soppressione
    • Una rotta non può rimanere soppressa per un tempo più lungo

BGP dumpening: esempi


Valutazione del BGP dumpening

  • Vantaggi
    • Penalizza solo rotte instabili senza effetti su quelle stabili
  • Problematiche
    • Quali sono le migliori configurazioni da utilizzare?
      • Attualmente non ci sono risposte scientifiche
  • Oggi gli ISP spesso non applicano il dumpening su tutte le sessioni
    • No dumpening sulle sessioni iBGP
    • No dumpening sulle sessioni eBGP con clienti
    • Qualcuno propone di utilizzare parametri di dumpening più aggressivi per prefissi lunghi

Indice della seconda parte della lezione

  • Organizzazione di Internet
  • Principi fondamentali di BGP
  • BGP in large networks
  • Ingegneria del traffico intra-dominio con BGP
    • L’accrescimento delle tabelle di routing BGP
    • Il processo decisionale di BGP
    • Tecniche per il Traffic Engineering inter dominio

L’accrescimento delle tabelle di routing BGP


Le ragioni per il recente accrescimento

  • Frazione dello spazio indirizzi IPv4 pubblicizzati
    • 24% dello spazio totale nel 2000
    • 28% dello spazio totale dell’Aprile del 2003
    • 31% dello spazio totale nel Novembre del 2004
  • Incremento in termini di AS
    • Circa 3000 AS prima del 1998
    • Più di 18000 AS nel Novembre del 2004
    • Aumento in multi-homing
      • Meno di 1000 stub AS multi-homed prima del 1998
      • Più di 6000 stub AS multi-homed nell’Aprile del 2003
  • Incremento della pubblicità di piccoli prefissi
    • Numero di indirizzi IPv4 pubblicizzati per prefissi
      • Fine 1999, 16k di indirizzi IPv4 per prefisso nelle tabelle BGP
      • Aprile 2003, 8k di indirizzi IPv4 per prefisso nelle tabelle BGP

Evoluzione dei tipici stub AS

  • Giorno uno, prima connessione in upstream verso un ISP
    • Lo stub riceve il blocco di indirizzi dal suo ISP
    • Lo stub utilizza il numero di AS privato
    • Un singolo homed-stub è completamente nascosto dal suo provider
      • Nessun impatto sulla dimensione delle tabelle di routing BGP

Evoluzione dei tipici stub AS

  • Giorno due, lo stub AS aspetta di diventare multi-homed nel prossimo futuro ed ottenere un numero di AS ufficiale
    • Vantaggi
      • Semplice da configurare per l’AS123
    • Svantaggi
      • Incrementa la dimensione di tutte le tabelle di routing BGP

Aggregando le rotte

  • BGP è in grado di aggregare rotte ricevute nel caso in cui le informazioni di alcuni ASPath siano perse
  • Un AS_SET contiene diversi AS#
    • Conta quanto un unico AS quando si misura la lunghezza dell’ASPath
    • Utilizzato per la rilevazione di loop, ma l’ASPath deve diventare molto lungo quando un provider ha moli clienti da aggregare

Uno stub ISP dual-homed

Giorno tre, lo stub AS è multihomed


Uno stub ISP dual-homed

  • Difetti di tale soluzione
    • Considerare ogni AS che riceve tali rotte
  • Conseguenze
    • Tutto il traffico verso 194.100.10.0/23 verrà inoltrato su un path non aggregato in quanto è il più specifico
    • L’AS123 può interrompere l’aggregazione dei prefissi dei suoi clienti, altrimenti questi ultimi non riceveranno pacchetti
    • Le tabelle di routing globali di BGP sono il 50% più estese rispetto alla loro dimensione ottimale se l’aggregazione è stata usata in maniera perfettamente ottimale
    • Meno del 7% delle rotte BGP sono aggregate

Come limitare l’accrescimento delle tabelle BGP?

  • Soluzione di lungo termine
    • Definire una architettura multi-homing ottimale
        • Può essere complicato con IPv4
        • È in corso il progetto per la realizzazione di un multi-homing migliore per IPv6
  • “Soluzione” corrente (pseudonimo scritto in fretta)
    • Alcuni IPS filtrano rotte verso prefissi più lunghi
    • Oggi vengono utilizzati due metodi
      • Ignorare le rotte con prefissi più lunghi di p bit (con p solitamente compreso tra 22 e 24)
      • Ignorare rotte che siano più lunghe rispetto alle regole di assegnazione utilizzate dai registri Internet (RIPE, ARIN, APNIC)
        • Ignorare prefissi più lunghi di /16 nello spazio di classe B
        • Ignorare prefissi RIPE più lunghi dell’allocazione minima di RIPE (/20)
    • Conseguenza
      • Alcune rotte non sono distribuite in Internet

Indice della terza parte della lezione

  • Organizzazione di Internet
  • Principi fondamentali di BGP
  • BGP in large networks
  • Ingegneria del traffico intra-dominio con BGP
    • L’accrescimento delle tabelle di routing BGP
    • Il processo decisionale di BGP
    • Tecniche per il Traffic Engineering inter dominio

Il processo decisionale di BGP

  • Processo decisionale di BGP
    • Ignorare rotte con nexthop irragiungibili
    • Preferire rotte con local-pref più elevati
    • Preferire rotte con ASPath più corti
    • Preferire rotte con MED più piccoli
    • Preferire rotte apprese via eBGP rispetto a rotte apprese via iBGP
    • Preferire rotte con next-hop vicini
    • Legare regole in rottura
      • Preferire rotte apprese da router con router id piccolo

L’AS-Path step più corto nel processo decisionale di BGP

  • Motivazione
    • BGP non contiene una metrica reale
    • Utilizza la lunghezza dell’AS-Path come indicazione della qualità delle rotte
      • Non sempre è un buon indicatore
  • Conseguenza
    • I percorsi di Internet tendono ad essere corti, 3-5 AS hop
    • Molti percorsi convergono verso lo strato 1 degli ISP e tali ISP trasportano molto traffico

Il “prefer eBGP over iBGP” step nel processo decisionale di BGP

  • Motivazione: hot potato routing
    • Un router può provare ad ottenere il rid di pacchetti inoltrati a domini esterni il prima possibile

Il closet next-hop step nel processo decisionale di BGP

  • Motivazione: hot potato routing
    • Un router può provare ad ottenere il rid di pacchetti inoltrati a domini esterni il prima possibile

Il lowest MED step nel processo decisionale di BGP

  • Motivazione: cold potato routing
    • In un AS multiconnesso, indicare quale entry border router è più vicino al prefisso pubblicizzato
    • Solitamente MED = costo IGP

Il “lowest router id” step nel processo decisionale di BGP

  • Motivazione
    • Un router deve essere in grado di determinare un’unica rotta migliore verso ogni prefisso destinazione
      • Un router potrebbe ricevere diverse rotte con con attributi confrontabili tra loro, verso un’unica destinazione

Indice della quarta parte della lezione

  • Organizzazione di Internet
  • Principi fondamentali di BGP
  • BGP in large networks
  • Ingegneria del traffico intra-dominio con BGP
    • L’accrescimento delle tabelle di routing BGP
    • Il processo decisionale di BGP
    • Tecniche per il Traffic Engineering inter dominio

Traffic Engineering inter-dominio

  • Obiettivi del Traffic Engineering inter-dominio
    • Minimizzare il costo inter-dominio della rete
    • Ottimizzare le performance
      • Preferire l’inoltro/ricezione di pacchetti su percorsi con basso ritardo per VoIP
      • Preferire l’inoltro/ricezione di pacchetti su percorsi con banda larga
    • Bilanciare il traffico tra differenti provider
  • Come ingegnerizzare il traffico inter-dominio?
    • Selezionare con attenzione il provider principale
    • Negoziare i peering agreement con altri domini, in corrispondenza di punti di interconnessione pubblici
    • Sintonizzare il processo decisionale di BGP sui router

Prerequisiti per il Traffic Engineering

  • Per ingegnerizzare il flusso di pacchetti nella rete … è innanzitutto necessario conoscere:
    • La quantità di pacchetti entranti nella rete
      • Preferibilmente con alcune informazioni riguardo la loro sorgente (e la destinazione nel caso di fornitura di servizi di transito)
    • La quantità di pacchetti che lasciano la rete
      • Preferibilmente con alcune informazioni riguardo la loro destinazione (e la sorgente nel caso di fornitura di servizi di transito)
  • Come ottenere tali informazioni in modo accurato?

Monitoraggio del traffico a livello link

  • Principio
    • Fidarsi di statistiche SNMP mantenute da ogni router per ogni link
    • Frequente gestione delle stazioni di sondaggio di ogni router
  • Vantaggi
    • Semplice da utlizzare e da diffondere
    • È possibile sfruttare dei tool per la collezione e distribuzione automatica dei dati
    • Informazioni grezze riguardo il carico di rete
  • Svantaggi
    • Nessun indirizzamento delle informazioni
    • La causa della congestione non è sempre facile da trovare

Cattura del traffico a livello flusso

  • Principi
    • I router identificano i confini del flusso
      • Non genera grossi problemi per i router cach-based
    • Flussi di livello 3
      • Pacchetti IP con alcuni prefissi di sorgente (risp. destinazione)
      • Pacchetti con alcuni AS sorgente (risp. destinazione)
      • Pacchetti con alcuni next hop IGP (risp. BGP)
    • Flussi di livello 4
      • Una connessione TCP corrisponde ad un flusso
      • Flussi UDP
      • I router inoltrano tale informazione all’interno di uno speciale pacchetto per il monitoraggio delle workstation

Cattura del traffico a livello flusso (2)

  • Vantaggi
    • Forniscono informazioni dettagliate sul traffico trasportato fuori su alcuni link
  • Svantaggi
    • È necessario esportare informazioni sul flusso per monitorare la stazione
      • Informazione riguardo un flusso: 30-50 byte
      • Dimensione media di un flusso HTTP: 15 pacchetti TCP
    • Carico della CPU su router molto veloci
      • Non disponibile su determinate piattaforme
    • Disco e requisiti di elaborazione sul monitoraggio di workstation

Netflow

  • Soluzione per il monitoraggio di flussi standard industriali
    • Netflow v5
      • I router esportano un sommario riguardo il flusso di livello 4
        • Timestamp di inizio e fine flusso
        • Indirizzi IP di sorgente e destinazione
        • Numero di byte/pacchetti, IP Protocol, TOS
        • Interfacce di input e output
        • Porti di sorgente e destinazione, flag TCP
        • AS e netmask di sorgente e destinazione
    • Netflow v8
      • I router eseguono l’aggregazione ed esportano i sommari
        • Matrice degli AS (identificare peer interessanti)
        • Matrice dei prefissi (fornisce informazioni più dettagliate rispetto all’ASMatrix)

Caratteristiche del traffico inter-dominio


Distribuzione topologica del traffico inoltrato dallo stub durante un mese


Il problema della selezione del provider

  • Come può un ISP selezionare un provider?
    • Criterio economico
      • Costo del link
      • Costo del traffico
    • Qualità delle rotte BGP pubblicizzate dal provider
      • Numero di rotte pubblicizzate dal provider
      • Dimensione delle rotte pubblicizzate dal provider
    • Spesso gli ISP hanno due provider di upstream per ragioni tecniche ed economiche

Sintonizzare BGP per controllare il traffico in uscita

  • Principio
    • Per controllare il proprio traffico in uscita, un dominio deve sintonizzare il processo decisionale di BGP sui propri router
  • Come sintonizzare il processo decisionale di BGP?
    • Filtrare alcuni router appresi da alcuni peer
    • Local-pref
      • Metodi utilizzati usualmente per implementare relazioni economiche
    • MED
      • Di solito il valore MED è settato all’inoltro di una rotta
        • Consente di preferire rotte su altri con lo stesso ASPath lenght
    • Costo IGP per il nexthop
      • Settando il costo IGP per il traffic engineering inter-dominio
    • Diversi router anzicchè uno solo nella tabella di forwarding

BGP Equal Cost MultiPath

  • Principio
    • Consentire ad un router BGP di installare diversi percorsi verso ogni destinazione nella sua tabella di forwarding
    • Bilanciare il traffco su percorsi abilitati
  • Problematiche
    • Quale AS Path verrà pubblicizzato da AS0
      • BGP consente di pubblicizzare un unico percorso
      • I router di downstream non verranno informati del percorso
        • Attenzione ai routing loop!

BGP Equal Cost MultiPath

  • Come utilizzare BGP equal cost multipath in questo caso?
    • RB potrebbe inoltrare i pacchetti verso RZ via RY e RA
    • R1 potrebbe ancora provare ad inoltrare i pacchetti verso RZ via RA e RB in quanto R1 conosce i due percorsi

BGP Equal Cost MultiPath

  • Quali percorsi possono essere utilizzati per il load balancing?
    • Eseguire il processo decisionale di BGP ed il load balancing con i percorsi avanzati al RouterID step
  • Conseguenze
    • I router di frontiera ricevono solo le rotte eBGP
      • Eseguire load balancing con rotte apprese dallo stesso AS
      • Altrimenti gli annunci di iBGP ed eBGP non rifletteranno i percorsi reali seguiti dai pacchetti
    • I router interni ricevono rotte via iBGP
      • Considerare solo per il load-balancing di rotte con i medesimi attributi (AS-Path, local-pref, MED) ed i medesimi costi di IGP
      • Altrimenti possono verificarsi dei loop

Sintonizzare BGP per il controllo di traffico in ingresso

  • Principi
    • Per controllare il proprio traffico in entrata, un dominio deve sintonizzare gli annunci BGP inoltrati dai suoi stessi router
  • In che modo sintonizzare gli annunci BGP?
    • Non pubblicizzare alcune rotte pervenute da alcuni peer
      • Annunciare alcuni prefissi solo verso alcuni peer
    • MED
      • Inserire MED = costo di IGP, di solito richiede accordi bilaterali
    • AS-Path
      • Incrementare in maniera artificiale la lunghezza dell’AS-Path
    • Comunità
      • Inserire comunità speciali nelle rotte pubblicizzate per indicare come i peer potrebbero eseguire il proprio processo decisionale di BGP su tali router

Controllo sul traffico in ingressoRete di prova

  • Routing senza sintonizzazione degli annunci
    • Il flusso di pacchetti verso AS1 dipenderà dalla sintonizzazione del processo decisionale di AS2, AS3 e AS4

Controllo sul traffico in ingressoAnnunci selettivi

  • Principio
    • Avvertire alcuni prefissi solo su determinati link
  • Difetti
    • Splittare un prefisso incrementa la dimensione di tutte le tabelle di routing BGP
    • Ridondanza limitata in caso di link failure

Controllo sul traffico in ingressoPrefissi più specifici

  • Obiettivo
    • Annunciare un prefisso di grandi dimensioni su tutti i link per la ridondanza, ma preferire alcuni link per parti di tale prefisso
  • Importante
    • Quando un pacchetto IP viene inoltrato, un router selezionerà sempre il longest match (corrispondenza più lunga) nella propria tabella di routing
  • Principio
    • pubblicizzare differenti rotte di sovrapposizione su tutti i link
      • L’intero prefisso IP è pubblicizzato su tutti i link
      • La subnet1 di tale prefisso IP è pubblicizzata anche sul link1
      • La subnet2 di tale prefisso IP è pubblicizzata anche sul link2

Controllo sul traffico in ingressoPrefissi più specifici (2)

  • Principio
    • Pubblicizzare prefissi di sovrapposizione parziali

Controllo sul traffico in ingressoAS-Path prepending

  • Principio
    • Anteporre artificialmente il proprio numero di AS su alcune rotte

SNMP – Parte I

  • Riproporre le prove pratiche in prospettiva teorica
  • Familiarizzare col linguaggio utilizzato in ambito SNMP
  • Dettagli relativi al protocollo SNMP

I materiali di supporto della lezione

Cisco Network Management System: Best Practices White Paper

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion