lunedì 15 luglio 2013

VRRP, ANYCASTS, TESSUTI E SPEDIZIONI OTTIMALE

L' ottimale inoltro L3 con VARP / VRRP messaggio generato numerosi commenti, che vanno da questioni tecniche riguardo VARP (più su che in pochi giorni) di osservazioni sulla falsariga di "si può fare con X" o "Y venditore sostiene Z, che fa la stessa cosa. "Sembra che ho aperto ancora un altro vaso di Pandora, cerchiamo di domare e ordinarli.

FHRP Basics

Protocolli di ridondanza primo hop (FHRP) risolvere un problema semplice: IPv4 non ha alcun protocollo host-to-router standard. I padroni di casa sono di solito configurate con un indirizzo statico del router di primo hop, costringendo i router per condividere un indirizzo IP (a volte chiamato Virtual indirizzo IP del router) in ambienti ridondanti. Nella maggior parte dei casi i router condividono anche l'indirizzo MAC l'indirizzo IP del router di primo hop condivisa per risolvere rotti o mal configurati stack IP protette che ignorano ARP gratuiti inviati dopo che la proprietà dei indirizzo condiviso IP cambia.
Userò il FHRP termine in questo documento per indicare una serie di protocolli, tra cui HSRP, GLBP, VRRP v2 e v3.
Uso tipico caso FHRP è un grande dominio di livello 2 che collega numerosi fine host a più di un router. I router sono (relativamente) vicine tra loro, e c'è un po indeterminato layer-2 di infrastrutture (qualsiasi cosa, da un cavo coassiale spesso a grandi TRILL o SPB tessuto) tra gli host terminali ei router.
I router di primo hop non possono fare affidamento su un particolare comportamento di inoltro del sottostante infrastruttura di livello 2; ogni router deve disporre di una propria serie di indirizzi MAC che devono essere attivi - il traffico deve essere di provenienza da quegli indirizzi MAC per timore che il layer-2 interruttori avviare inondando il traffico unicast inviato a uno dei indirizzo MAC del router.
L' indirizzo MAC attivo requisito solitamente limita il numero di mittenti di FHRP attivi a uno - più spedizionieri che utilizzano lo stesso indirizzo MAC causerebbero gravi MAC sbatteresu interruttori intermedi , e gli switch intermedi non sarebbe in grado di eseguire il bilanciamento del carico verso più indirizzi MAC identici comunque.

Use Case Data Center

L'obiettivo primario di ottimo livello 3 di inoltro in un ambiente di data center è quello di ridurre al minimo il traffico di foglia-di-colonna vertebrale in ambienti in cui la quantità di est-ovest (da server a server) traffico supera significativamente la quantità di nord-sud ( server-to-client) di traffico. L'unico modo per raggiungere questo obiettivo è quello di introdurre la funzionalità di inoltro di livello 3 in hypervisor o (in mancanza) gli switch top-of-rack (ToR).

Layer-3 Forwarding in Hypervisor

Mentre saremo sicuramente vedere AWS-Stile livello-3 spedizioni in hypervisor, non siamo ancora lì. Gli unici prodotti di trasporto che lo sostengono maggio 2013 sono virtualizzazione Hyper-V Network (che richiede l'incapsulamento NVGRE), di NEC ProgrammableFlow switch virtuale per Hyper-V , e Midonet di Midokura .
La possibilità di migrare una VM in esecuzione tra host fisici (e gli interruttori Tor) introduce ulteriori requisiti: tutti gli switch ToR devono condividere lo stesso indirizzo MAC, a nessuno piace vedere i tromboni di traffico che derivano da una VM di essere appuntato a un indirizzo MAC di un interruttore ToR remoto.

Le Soluzioni

Come sempre il settore del networking ha cercato di "risolvere" il problema con l'introduzione di ogni sorta di hack idee ispirate, alcune delle quali più inutile degli altri. I più comuni (descritti in questo post del blog) sono:
  • No FHRP (core switch vengono visualizzati come una singola entità);
  • FHRP attivo / attivo su una coppia MLAG;
  • GLBP.
Soluzioni più creative sono descritti in altri post del blog:
  • Ottimale L3 forwarding con VARP o VRRP attivo / attivo
  • Parte QFabric 3 - l'inoltro
  • Costruire grandi L3 tessuti con VDX switch Brocade

No FHRP con architettura Borg

I fornitori che implementano reti di connessione ridondanti con architettura Borg ( piano di controllo unico - VSS, di HP IRF di Cisco) non hanno bisogno di FHRP. Dopo tutto, l'intero cluster di scatole agisce come un unico dispositivo logico con un'unica serie di indirizzi IP e MAC.
Virtual Chassis di Juniper sembra esattamente la stessa di Cisco VSS o IRF di HP dal di fuori, ma usa un po 'diverso meccanismo di attuazione: piani di controllo alquanto indipendenti coordinati attraverso un piano di gestione condivisa.
Prima che qualcuno convince a risolvere ottimale problema forwarding L3 con uno stack virtuale di switch ToR diffuso in tutto il centro dati (e ho visto consulenti spaccio di questo "disegno" a clienti ignari), considerare come il traffico scorrerà .

FHRP attivo / attivo oltre MLAG

Quasi ogni offerta vendor funzionalità MLAG attraverso una coppia di switch core indipendenti (di Cisco vPC, Arista, ALU, Avaya ...) supporta attivo / attivo FHRP inoltro sui core switch:
Questa soluzione è quasi un gioco da ragazzi, anche se i dettagli di implementazione devono essere piuttosto complesso, altrimenti è difficile capire perché ci sono voluti alcuni anni fornitori per la sua attuazione. Ecco come funziona:
  • FHRP è configurato sui membri del gruppo MLAG (vPC, MCLAG ...). Uno dei membri viene eletto come gateway FHRP attivo e pubblicizza l'indirizzo MAC FHRP.
  • Tutti i membri del gruppo MLAG ascoltano l'indirizzo MAC FHRP;
  • Pacchetti provenienti dall'indirizzo MAC FHRP (esempio: VRRP annunci) vengono inviati tramite uno dei membri collegamenti GAL l'interruttore ToR - interruttore ToR sa quindi come raggiungere l'indirizzo MAC FHRP;
  • Pacchetti all'indirizzo MAC FHRP vengono inviati dallo switch ToR su uno dei collegamenti membri dei GAL (non necessariamente il link su cui il pacchetto da FHRP indirizzo MAC è arrivato), con conseguente bilanciamento del carico in qualche modo ottimale verso FHRP indirizzo MAC.
  • Qualunque sia il core switch riceve il pacchetto in ingresso per FHRP indirizzo MAC esegue L3 forwarding.
Come sempre, il diavolo è nei dettagli: switch L3 possono inviare il traffico indirizzato dalla loro indirizzo MAC hardware (non FHRP indirizzo MAC), a fondo confondendo i dispositivi con stack TCP rotti che preferiscono raccogliere i pacchetti in entrata, invece di utilizzare i meccanismi standard come ARP .
Comportamento attivo / attivo FHRP è bello da avere se siete soddisfatti con L3 forwarding sul core switch. Basta ricordare che tutte le inter-subnet est-ovest attraversa il nucleo di traffico, anche quando le due macchine virtuali siedono nello stesso hypervisor host.

La Hack GLBP

GLBP bypassato la sola limitazione spedizioniere con un trucco interessante - diversi host riceveranno indirizzi MAC diversi (appartenenti a diversi router) per l'indirizzo IP del router virtuale condivisa.
Mentre il trucco potrebbe funzionare bene in casi di utilizzo FHRP originali (con ampio dominio L2 tra i padroni di casa e la banca di router), è totalmente inutile in ambienti data center che richiedono L3 inoltro presso gli interruttori tor:
  • VM potrebbe ottenere un indirizzo MAC da un interruttore ToR casuale (non l'interruttore più vicino);
  • VM è appuntato un indirizzo MAC di un interruttore TR e invia il traffico a quello stesso interruttore, anche quando si VMotion la VM per una totalmente diversa posizione fisica.
Mod Multi-FHRP, dove ogni router appartiene a più gruppi FHRP su ogni interfaccia e finali host utilizzano diversi gateway prima-hop, è quasi identico (ma più difficile da gestire) rispetto GLBP mod

Maggiori informazioni

Ha ottenuto finora? Wow, sono impressionato. Qui c'è di più:
  • Data Center 3.0 per Networking Ingegneri webinar descrive numerosi dati tecnologie e le sfide di centro-correlati, tra cui L2/L3 disegni;
  • Data Center Fabric Architetture webinar descrive tipiche architetture in tessuto e le implementazioni dei fornitori;
  • Prossimi Enterasys dati solidi Centro Interconnect Solutions webinar descrive (tra i numerosi altri argomenti) attivo / attivo VRRP (Fabric Routing) disponibile sugli switch Enterasys.
E non dimenticate i relativi post del blog:
  • Ottimale L3 forwarding con VARP o VRRP attivo / attivo
  • Parte QFabric 3 - l'inoltro
  • Costruire grandi L3 tessuti con VDX switch Brocade

SCOTT SHENKER SU OPENFLOW E SDN

Brent Salisbury mi ha inviato un link a un fantastico OpenFlow / SDN presentazione Scott Shenker ha fatto @ Stanford University a pochi giorni fa. E 'una perfetta introduzione alle idee fondamentali alla base SDN e quindi un must-see per tutti vagamente coinvolti nel networking.
Ecco alcuni dei punti salienti (dal mio punto di vista molto parziale):
  • Hanno sbagliato tutto nella prima iterazione (@ 20:00) - è raro vedere qualcuno essere così onesti su idee sbagliate del passato;
  • Virtualizzazione della rete è la killer application, e SDN è solo un mezzo per un fine (@ 25:00);
  • MPLS aveva ragione (@ 32:00) - mi piacerebbe vedere la reazione di un noto evangelista SDN e MPLS Basher ;)
  • Una rete dovrebbe avere un bordo complessa e un semplice nucleo, con il software di commutazione al bordo (@ 38:00);
  • Reti di oggi sono pieni di middleboxes che sono già basato su x86. La funzionalità di questi middleboxes dovrebbe essere spostato a dispositivi basati su x86 alla periferia della rete (@ 42:00);
  • Latenza di rete (in realtà la latenza intra-switch) non importa a bordo (@ 49:00).
C'è ancora un sacco di handwaving e dettagli mancanti, in particolare quando ci si sposta da ambienti strettamente controllati (data center) per grandi reti WAN in cui i singoli componenti devono operare in modo indipendente ad essere guasto-resistenti, ma faranno finalmente arrivare.
Questo sarebbe un posto perfetto per elencare compiaciuto il mio blog (andare tutto il senso indietro al 2011 ) parlando esattamente le stesse cose ... ma è fuori di sole ed i bambini sono in attesa ;)