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
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.