Finora in questa serie abbiamo esaminato una serie di concetti di base su BGP, coprendo sia chi vorrebbe usarlo sia perché. In particolare abbiamo appreso che parlare o pubblicizzare BGP ai tuoi fornitori di servizi e / o colleghi ti consente di fare due cose:
- Prendi decisioni di routing semi-intelligenti relative al percorso migliore per un determinato percorso da portare in uscita dalla tua rete (altrimenti imposteresti semplicemente un percorso predefinito dai router di confine ai tuoi fornitori di servizi).
- Pubblicizza i tuoi percorsi verso tali fornitori, affinché possano pubblicizzare a loro volta gli altri (per la connettività di transito) o semplicemente utilizzarli internamente (nel caso di colleghi).
Abbiamo anche sottolineato alcune delle conseguenze negative che possono derivare da una negligente configurazione BGP. In questo post, approfondiremo la meccanica di BGP esaminando come configuri BGP sui router.
Autonomous Systems and ASNs
Come discusso nella Parte 1, il termine Sistema autonomo (AS) è un modo di fare riferimento a una rete come una rete aziendale privata o una rete di fornitori di servizi. Ogni AS è amministrato in modo indipendente e può anche essere indicato come dominio. A ciascun AS viene assegnato almeno un numero di sistema autonomo (ASN), che identifica la rete al mondo. La maggior parte delle reti utilizza (o almeno mostra al mondo) solo un ASN. Ogni ASN viene disegnato da un campo numerico a 16 bit (che consente 65.536 possibili ASN):
- Gli ASN 0 e 65.535 sono valori riservati
- Il blocco di ASN da 64.512 a 65.534 è designato per uso privato
- Il resto dei possibili valori ASN disponibili per il routing Internet va da 1 a 64.511 (tranne 23.456).
eBGP vs. iBGP
Un altro chiarimento prima di iniziare la configurazione: BGP può essere utilizzato internamente (iBGP) all’interno di un AS per gestire le rotte e esternamente (eBGP) per instradare tra AS, che è ciò che rende possibile Internet stesso. In questo articolo quando diciamo BGP stiamo parlando di eBGP, non di iBGP. eBGP e iBGP condividono lo stesso protocollo di basso livello per lo scambio di percorsi e condividono anche alcuni algoritmi. Ma eBGP viene utilizzato per scambiare percorsi tra diversi AS, mentre iBGP viene utilizzato per scambiare percorsi all’interno dello stesso AS. In effetti, iBGP è uno dei “protocolli di routing interno” che è possibile utilizzare per eseguire il “routing attivo” all’interno della propria rete / dominio.
La differenza principale tra eBGP e iBGP è che eBGP cerca come un matto di pubblicizzare tutte le rotte BGP che conosce a tutti, e devi mettere in atto dei “filtri” per impedirgli di farlo. iBGP, d’altra parte, cerca come un matto di non riconfigurare le rotte. In effetti, iBGP può effettivamente essere una sfida per funzionare perché per farlo funzionare devi scrutare tutti gli iBGP – “altoparlanti” all’interno della tua rete con tutti gli altri altoparlanti iBGP. Questa è chiamata “mesh di routing” e, come puoi immaginare, può diventare un vero disastro quando hai 20 router che ognuno deve scrutare con ogni altro router. La soluzione a questo è “Confederazioni BGP”, un argomento che tratteremo in un tutorial successivo.
Peering Sessions
Quindi ora diamo un’occhiata alla configurazione effettiva. I router che parlano BGP scambiano rotte con altri router che parlano BGP tramite sessioni di peering usando l’identificazione ASN. A livello tecnico, questo è ciò che significa che una rete o un’organizzazione esegua il peering con un’altra. Ecco uno snippet di codice Cisco semplificato di una clausola BGP del router:
router bgp 64512
<omitted lines...>
neighbor 207.106.127.122 remote-as 701La clausola inizia dicendo “router bgp 64512.” Ciò significa che quello che segue è un elenco di comandi che descrivono come parlare BGP per conto di ASN 64512. (Stiamo usando 64512 nei nostri esempi perché non è un ASN attivo, quindi se qualcuno usa una configurazione direttamente da questa colonna e usa questo costituiva ASN, i programmi automatici di esame del percorso lo rileveranno.)
Tutto ciò che serve per avviare una sessione di peering è quella linea adiacente nella clausola bgp del router. In questo esempio, questa riga specifica 207.106.127.122 come indirizzo IP remoto (rispetto al percorso del cliente) di un router nell’AS con ASN 701.
Lo scopo dei comandi vicini è di avviare sessioni di peering con i vicini. È possibile tenere sessioni di peering BGP su più salti, ma il multi-hop eBGP è un argomento più avanzato e presenta molte potenziali insidie. Quindi, per ora, supponiamo che tutti i vicini debbano essere su un’interfaccia LAN (Ethernet, Fast Ethernet, FDDI). In pratica, quasi sempre si utilizza più di una riga per specificare come scambiare percorsi con un determinato vicino in una determinata sessione di peering. Quindi una tipica sequenza di comandi vicini sarebbe più simile a questa:
router bgp 64512
<omitted lines...>
neighbor 207.106.127.122 remote-as 4969
neighbor 207.106.127.122 next-hop-self
neighbor 207.106.127.122 send-communities
neighbor 207.106.127.122 route-map prepend-once out
neighbor 207.106.127.122 filter-list 2 in
<omitted lines...>Ogni volta che si presenta una sessione vicina, ogni router valuterà ogni percorso BGP che ha eseguendolo attraverso tutti i filtri specificati nel comando vicino BGP. Qualsiasi route che passa il filtro viene inviata all’estremità remota. Questo filtro è un processo critico. L’elemento più pericoloso di BGP è il rischio che il tuo filtraggio vada storto e annuncerai percorsi che non dovresti verso i tuoi fornitori upstream.
Seeing routes
Mentre la sessione è attiva, gli aggiornamenti BGP verranno inviati da un router all’altro ogni volta che uno dei router è a conoscenza di una nuova rotta BGP o deve ritirare un annuncio di rotta precedente. Per visualizzare un elenco di tutte le sessioni di peering correnti è possibile utilizzare la riga di comando Cisco “sho ip bgp sum”:
brain.companyx.com# sho ip bgp summ
Il comando in genere restituisce risultati come il seguente, che è un riepilogo della sessione da un router principale in un ISP. I sistemi autonomi 6451x sono sessioni BGP su altri router dello stesso ISP i cui ASN non sono mostrati al mondo. La sessione 205.160.5.1 è una sessione inattiva e le sessioni in cui i sistemi autonomi remoti sono 4231, 3564 e 6078 sono sessioni di peering esterne con router di un altro ISP.
BGP table version is 1159873, main routing table version 1159873
44796 network entries (98292/144814 paths) using 9596344 bytes of memory
16308 BGP path attribute entries using 2075736 bytes of memory
12967 BGP route-map cache entries using 207472 bytes of memory
16200 BGP filter-list cache entries using 259200 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State
205.160.5.1 4 6313 0 0 0 0 0 never Active
207.106.90.1 4 64514 1145670 237369 1159873 0 0 4d03h
207.106.91.5 4 64515 6078 5960 1159869 0 0 4d03h
207.106.92.16 4 64512 6128 6782 1159870 0 0 4d03h
207.106.92.17 4 64512 5962 6894 1159870 0 0 10:08:46
206.245.159.17 4 4231 161072 276660 1159870 0 0 2d05h
207.44.7.25 4 3564 6109 310292 1159867 0 0 22:40:50
207.106.33.3 4 64513 164708 724571 1159866 0 0 3d23h
207.106.33.4 4 3564 6086 274182 1159853 0 0 4d03h
207.106.127.6 4 6078 5793 310011 1159869 0 0 2d03h La maggior parte della tabella sopra è abbastanza autoesplicativa:
- La colonna adiacente fornisce l’indirizzo IP del vicino con il quale viene eseguito il peering del router.
- La colonna V è il numero di versione BGP. Se non è 4, c’è qualcosa che non va! BGP versione 3 non capisce il routing Classless (CIDR) ed è quindi pericoloso.
- La colonna AS è l’ASN remoto.
- InQ è il numero di percorsi rimasti da inviarci.
- OutQ è il numero di rotte rimaste da inviare dall’altra parte.
- La colonna Su / Giù indica l’ora in cui la sessione è stata attiva (se il campo Stato è vuoto) o inattiva (se il campo Stato non è vuoto).
- Qualsiasi cosa in un campo Stato indica che la sessione per quella riga non è attiva. In solo uno dei difetti della nomenclatura di BGP, uno stato di Active indica effettivamente che la sessione è inattiva.
About Author
