Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
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

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93