IPV6 IN UNA SOCIETÀ GLOBALE - UN REAL-WORLD ESEMPIO

Più di un anno fa ho scritto una risposta ad un commento Pascal ha scritto sul mio Predire la dimensione della tabella BGP IPv6 post sul blog. Recentemente ho riscoperto e capito che è (purtroppo) come rilevanti come lo era quasi 18 mesi fa.

Altre persone hanno capito che abbiamo questo problema, nel frattempo , e sono ancora in fase detto di smettere yammering perché il problema non è reale. Vediamo cosa succede in pochi anni.

Pascal perfettamente descritto il problema affrontato da grandi organizzazioni multinazionali quando ha scritto "Se una grande azienda ha indirizzi PI, molti rami, e utilizzare più ISP, allora ci potrebbero essere molti / 48 (uno per ramo) pubblicizzato ai coetanei ISP, a meno che il rami si collegano via vpn al sito principale. " Scaviamo più a fondo il problema.

Questo post è basato su un problema di progettazione nella vita reale, ma ho cercato di renderlo abbastanza generico per coprire numerose sfide progettuali simili. Si noti inoltre che il problema non è specifico per lo spazio di indirizzi PI. Alcune grandi aziende hanno deciso di diventare LIR solo per gestire il pantano IPv6 .

Requisito # 1: No NAT . Evangelisti IPv6 pubblicizzare il mondo senza NAT, che è di per sé una buona cosa. Risultati di NAT in aumento CapEx (scatole più costose che devono mantenere lo stato ad alta velocità) e OpEx (risoluzione dei problemi NAT-correlati).

Conclusione : Facciamolo giusto - non useremo NAT nella parte IPv6 della nostra rete aziendale, il che significa che abbiamo bisogno di indirizzi IPv6 globali per ogni singolo ospite nella nostra rete. Non è un grosso problema, è abbastanza facile da ottenere grande pezzo di PI IPv6 o spazio di indirizzamento PA se è possibile documentare il caso d'uso (/ 48 per la posizione x numero di sedi in tutto il mondo).

Se i siti remoti utilizzano un singolo ISP, si potrebbe andare con spazio degli indirizzi PA per siti remoti e rendere l'/ 48 assegnato dall'ISP loro prefisso IPv6 unico ... fino a quando si deve cambiare ISP e rinumerare (un progetto che rispecchia di solito il viaggio del Titanic ).

Requisito # 2: la ridondanza Ubiquitous . Ogni posizione deve disporre di connettività a due ISP. Ricordate, stiamo discutendo di una organizzazione globale - pagare di più per la connettività Internet business grade dual-homed è il modo più conveniente che fare con i problemi causati da un accesso residenziale grado o configurazioni non ridondanti.

Implementare questo requisito in un mondo IPv6 NAT-meno di solito richiede un provider di prefisso IPv6 indipendente a livello globale routing per ogni singolo sito . Indirizzi In alternativa, si potrebbe costruire tunnel IPv6-over-IPv6 (o IPsec o SSL VPN) per hub regionali e utilizzare ISP-condizione IPv6 endpoint come sottoposto. Tuttavia, c'è il terzo requisito.

Requisito # 3: uscita Internet locale . Gli uffici locali di un'organizzazione globale comunemente accedere a siti web locali. Non ha senso per rendere la loro vita più difficile dalla spola del traffico verso un hub regionale (oltre a volte molto costosi collegamenti internazionali - ci sono paesi nel mondo dove si paga ancora in più per la connettività internazionale) e poi di nuovo a un sito web che potrebbe essere situato lungo la strada dall'ufficio locale.

Un altro requisito in reti che uniscono MPLS / VPN e connettività Internet WAN sarebbe fallback di hub regionale in caso di guasto a Internet uplink locale . Si noti inoltre che l'uscita di Internet regionale non è molto diverso da quello di uscita Internet locale .

Ci sono due modelli che potrei venire con quella di soddisfare tutte le esigenze:

Una rete in cui ogni singolo sito pubblicizza il proprio livello globale routing prefisso IPv6 fornitore indipendente di tutti gli ISP a monte, in modo efficace che esplode in tutto il mondo la tabelle di routing IPv6.
Nelle reti con un singolo uplink Internet locale abbiamo potuto utilizzare più prefissi IPv6 su ogni sottorete: ULA + prefissi globali globali o multiple (aziendali e Internet) con sorgente intelligente regole di selezione indirizzo. Due o più uplink Internet determinano una missione impossibile scenario.
Nel momento in cui permettiamo alcune NAT (preferibilmente in forma di NPT66), il design diventa più realistico. Siamo in grado di soddisfare i requisiti di # 2 e # 3 da:

Utilizzo di un blocco unico PI;
Allocazione / 48 prefissi fuori quel blocco PI a tutti i siti remoti;
Utilizzo di prefissi ISP allocati come i prefissi NPT66 pubblici;
Tuttavia, siamo saldamente nella terra NAT, ma almeno stiamo usando una variante stateless, che tende ad essere un po 'più economico e facile da implementare.

Mi sto perdendo qualcosa? Stiamo parlando di implementazioni reali, in modo da non dovete parlare di LISP fino ragionevole gran numero di ISP deploy in produzione in Internet globale

DATA CENTER DI DESIGN CASE STUDIES SU AMAZON - TAKE 2

Nel mese di luglio ho scritto una versione di Amazon Kindle della mia Data Center di design Case Studies libro e lamentato il loro royalties modello. Qualcuno ha subito sottolineato come adattare al loro sistema: dividere il libro in più volumi e pagare $ 9.99 per ogni.

Mi ci sono voluti mesi per arrivare, ma i primi due volumi sono finalmente su Amazon:

Volume I tratta delle connettività WAN bordo, tra cui interconnessioni data center, BGP e DMVPN scalabilità;
Volume II copre infrastrutture cloud, tra cui la connettività di server, soluzioni di sicurezza di rete scale-out, e architetture di infrastrutture di cloud scale-out;
Volume III (una volta che è completo) coprirà appliance virtuali, / data center attivi attivi e pochi altri argomenti interessanti.
Il libro è disponibile anche in altri negozi Amazon Kindle - troverete facilmente per nome.
I tre volumi avranno esattamente lo stesso contenuto della versione PDF del libro si può acquistare sul mio sito web . Il libro completo non sarà più disponibile su Amazon; se l'hai comprato (grazie!) che continuerai acquisire aggiornamenti mentre scrivo nuovi capitoli.

Tags: Data Center , design
Email questo
post
Condividi su Twitter
Condividi su Facebook
Ivan Pepelnjak, CCIE # 1354, è il consigliere tecnologia principale per NIL Data Communications . Egli progetta e implementazione di reti di comunicazione di dati su larga scala, nonché l'insegnamento e la scrittura di libri su tecnologie avanzate dal 1990 Vedere il suo profilo completo , contattare lui o seguireioshints su Twitter.
POSTS RELATED PER CATEGORIE

Data Center
Sostituzione di un Firewall centralizzato
Costruire una piccola nuvola con UCS Mini
Dinamica FCoE - Sparse Mode FCoE Strikes Again
Hai fatto la stessa cosa per gli ultimi 20 anni
Open-Source cloud ibrido Architettura di riferimento sul Software Gone Wild
E 'Data Center Trilogy pacchetto la giusta misura per capire Long Distance vMotion sfide?
VMware EVO: RAIL - One Stop Shopping per il tuo Private Cloud
Intervista: ridurre i costi e aumentare l'efficienza con SDDC
Infine: un Virtual Switch Supporta BPDU Guard
Design
Prossimo capitolo in Data Center di design Case Studies
Quanto grande sarà il vostro Nube Be?
Data Center di design Case Studies su Amazon Kindle
Creazione di un cloud in tre semplici passaggi
Per ottenere un lavoro fatto bene, avete bisogno di una formazione adeguata
Tre errori comuni che possono Doom Your Private Cloud
Real Life BGP percorso Origination e BGP hop successivo Complessità