Il mio ultimo protocollo Spanning Tree (STP) i messaggi generati numerosi commenti, alcuni dei quali in modo rilevante che ho deciso di riassumere in un altro post.
Cose strane accadono
Il collegamento unidirezionale scenario di cui parla Antonio è abbastanza noto:
Mi piacerebbe aggiungere collegamenti unidirezionali alla lista dei problemi STP, questo può accadere perché un cattivo ricetrasmettitore o di una fibra è rotto o male manipolati, e solo kludges vendor in grado di risolvere voi, l'aggiunta di un problema di compatibilità intervendor
Tuttavia, Christoph ha descritto uno scenario non ho mai considerato (o sentito parlare):
Esempio perfetto: qualsiasi router Cisco con EtherSwitch-based (HWIC -... ESW, EHWIC -... ESG e router ISR associate) switchports. Tutte le porte su un modulo sono un unico dominio di broadcast e sono fino / fino all'accensione non importa quello che è stato configurato - fino a quando è in esecuzione IOS ha analizzato la configurazione.
Non spegnerlo
Diversi lettori hanno sottolineato come disastrosa l'idea di spegnere STP è. Il vincitore è l'esempio pubblicato da Bela Varkony:
Ho visto grandi crolli quando qualcuno spento STP. Una volta non era nemmeno nei commutatori Ethernet (dato che erano di grandi dimensioni e potrebbe far fronte con l'aumento del traffico), ma nei firewall collegati. Chiunque fosse si è fermato il viaggio aereo per una mezza giornata in un intero paese. Perciò stai attento!
Bela (e pochi altri) anche spiegate perché è importante mantenere STP correre ai bordi della rete:
Anche quella STP ha alcune sfide, mai e poi mai spegnerlo. Si potrebbe non sapere che crea un loop accidentalmente. Che sia un cavo misconnected o di un dispositivo di boot con strani interconnessioni delle porte temporaneamente. STP è lì come uno strumento di sicurezza ultima risorsa.
Kerry Thompson è stato ancora più esplicito:
Il problema più grande con STP che ho visto è quando persone che non sono esattamente gli esperti di configurare nuovi switch e quindi disabilitare l'albero - perché hanno sentito dagli esperti che è cattivo. Io cerco di dire loro che spanning tree è come rilevatori di fumo - sì, possono essere fastidioso e talvolta necessitano di manutenzione, ma non appena li spengo.
Se siete interessati a questo argomento, assicurarsi di leggere la grande " Uccidere il Spanning Tree canarino " analogia di Kurt Bales.
Nelle notizie totalmente estranei, VMware continua a dire a tutti quanto far cadere BPDUs è la più grande idea dopo il pane a fette , con un link ad un altro articolo che descrive come STP potrebbe causare la perdita temporanea della connettività di rete . E 'sorprendente come VMware commercializzazione incolpa sempre qualcun altro per problemi causati da loro sviluppatori che scelgono di abusare di tecnologie perfettamente noti.
Mantenere Layer-2 Domini Piccolo
Un altro punto di accordo molto vocale è stata la necessità di mantenere i domini di livello-2 piccoli. Anche in questo caso a partire da Bela:
La buona pratica è di mantenere il dominio STP più piccolo possibile. E ricordate: STP è stato progettato originariamente per un massimo di 7 luppolo e alcuni interruttori e alcune decine di dispositivi host in mente. Non è sicuramente progettato per il collegamento di grandi data center in un unico dominio ponte. Non usare qualcosa per un caso d'uso non è stato progettato per e non completamente testato e analizzato ...
Mario ha avuto parere simile:
Per quanto mi riguarda cercherò sempre di ridurre al minimo qualsiasi dominio L2 STP o del ponte più lontano dal nucleo più possibile, fino a un paio di interruttori TOR, o, se possibile, al bordo switch virtuale. Se si tratta di una cosa che ho imparato nel corso di questi post del blog molto informativo, è che non si dovrebbe mai estendere tale dominio L2 in tutto il DC; STP ti morderà prima che poi. E 'solo che non vale la pena rischiare.
Infine, è necessario leggere il anonimi ' suggerimenti su come lavorare con grandi domini di bridging .
martedì 8 marzo 2016
martedì 26 gennaio 2016
CHE FINE HA FATTO "NON NUOCERE"?
Tanto tempo fa, in un podcast molto, molto lontano uno dei padroni di casa sellò il suo unicorno cavallo e cominciò a spiegare come i firewall stateful funzionano:
Stateful firewall è un modo per implicare fiducia ... perché è possibile dirottare i flussi di qualcuno [...] e se l'applicazione cambia i suoi numeri di porta ... la mia porta di origine cambia quando sto comunicando con il mio server web - anche se mi sono connesso alla porta 80, la mia porta di origine potrebbe cambiare da X a Y. Una volta ho lasciato la prima attraverso, ho bisogno di tenere traccia di questi cambiamenti portuali [...]
Aspetta, cosa? Era quel ragazzo veramente cercando di dire "qualcuno può cambiare un numero di porta fonte di una sessione TCP stabilita"?
Per la cronaca, è non è possibile modificare i numeri di porta di una sessione TCP stabilita, e l'unico modo per ottenere numeri di porta diversi è passando attraverso un altro scambio di TCP SYN, che sarebbe stato trattato come una sessione TCP totalmente separata da un firewall stateful o ospiterà stack TCP.
Inoltre, è piuttosto difficile dirottare i flussi di qualcuno meno che non siate nel percorso di inoltro, in questo caso è praticamente gioco sopra comunque e firewall stateful non può fare una cosa per fermarti.
Capisco perfettamente che le persone fanno errori nelle sessioni dal vivo (in modo da fare io). Quello che non riesco a capire è che nessuno saltato e corretto, o che essa non ha ottenuto rimosso durante il montaggio finale.
Perché mi interessa?
E 'molto semplice - se si dispone di un numero significativo di lettori / ascoltatori che si fidano, come la fonte della loro conoscenza tecnica, non si può permettersi di lasciare gli errori evidenti come questo agguato in natura, perché qualcuno potrebbe in realtà si credere senza doppio controllando i crediti nei confronti di qualcosa come il protocollo TCP / IP per i manichini.
Stateful firewall è un modo per implicare fiducia ... perché è possibile dirottare i flussi di qualcuno [...] e se l'applicazione cambia i suoi numeri di porta ... la mia porta di origine cambia quando sto comunicando con il mio server web - anche se mi sono connesso alla porta 80, la mia porta di origine potrebbe cambiare da X a Y. Una volta ho lasciato la prima attraverso, ho bisogno di tenere traccia di questi cambiamenti portuali [...]
Aspetta, cosa? Era quel ragazzo veramente cercando di dire "qualcuno può cambiare un numero di porta fonte di una sessione TCP stabilita"?
Per la cronaca, è non è possibile modificare i numeri di porta di una sessione TCP stabilita, e l'unico modo per ottenere numeri di porta diversi è passando attraverso un altro scambio di TCP SYN, che sarebbe stato trattato come una sessione TCP totalmente separata da un firewall stateful o ospiterà stack TCP.
Inoltre, è piuttosto difficile dirottare i flussi di qualcuno meno che non siate nel percorso di inoltro, in questo caso è praticamente gioco sopra comunque e firewall stateful non può fare una cosa per fermarti.
Capisco perfettamente che le persone fanno errori nelle sessioni dal vivo (in modo da fare io). Quello che non riesco a capire è che nessuno saltato e corretto, o che essa non ha ottenuto rimosso durante il montaggio finale.
Perché mi interessa?
E 'molto semplice - se si dispone di un numero significativo di lettori / ascoltatori che si fidano, come la fonte della loro conoscenza tecnica, non si può permettersi di lasciare gli errori evidenti come questo agguato in natura, perché qualcuno potrebbe in realtà si credere senza doppio controllando i crediti nei confronti di qualcosa come il protocollo TCP / IP per i manichini.
martedì 5 gennaio 2016
BROADCOM TOMAHAWK 101
Juniper ha recentemente lanciato il suo interruttore a base di Tomahawk (QFX5200) e comprendeva un sacco di informazioni su hardware di commutazione in una delle loro presentazioni pubbliche (simile a quello che Cisco ha fatto con Nexus 9300), così ho preso un non-NDA intravedere nel recente Broadcom chipset.
Otterrete ulteriori informazioni su QFX5200 così come altri switch basati su Tomahawk nel Data Center Tessuti aggiornamento webinar in primavera 2016.
Ecco quello che ho capito la presentazione ha detto:
Ogni porta 100 GE può essere canalizzato in 4 x 10GE, 4 x 25GE, 2 x 50GE o 1 x 40GE. Sembra che ogni porta può essere eseguito 4 corsie su entrambi i 10 Gbps o 25 Gbps;
I può essere totalmente sbagliato, ma il modo in cui ho capito le specifiche delle porte 100gE uso 100GBASE-SR4 (802.3bm) di serie e sarebbe quindi incompatibile con gli switch che utilizzano più vecchio 100GBASE-SR10 (802.3ba) standard, anche se avrebbero lavorato con tutti i 40 Gbps sensori usando 40GBASE-SR4.
Simile a Trident-2, Tomahawk diventa line-rate (3,2 Tbps) di dimensioni dei pacchetti di cui sopra 250 byte;
Presentazione sostiene instradamento overlay (VXLAN-to-VXLAN o VXLAN-to-VLAN) non è supportata, che è un po 'sorprendente come il gasdotto di inoltro include cessazione tunnel prima di L2 e L3 di ricerca, che dovrebbe essere abbastanza buono;
Il silicio commutazione ha 10 code per porta (bello!);
La latenza di commutazione è di circa 500 ns e può essere ridotto a 300 ns se il chipset è riconfigurato a fare solo semplice commutazione L2;
Tabella di inoltro unificata (UFT; voci 128K) è divisa in banchi di memoria che possono essere allocate alle voci L2, voci ARP e le voci LPM L3;
Una delle stampe nella presentazione accennata prefissi 1K LPM IPv6 più lungo di / 64;
Tomahawk supporta corrispondenza esatta di voci ACL a UFT (non TCAM). UFT dividere con il profilo di filtro-mode possono avere le voci 64K ACL, le voci di LPM 16K IP e ARP voci 8K / MAC;
Ci sono 43 code tra il silicio di commutazione e CPU, ed è possibile configurare il controllo-plane polizia parametri ciascuna coda;
L'hardware supporta etichette 16K MPLS (deve essere una tabella MPLS di ricerca indipendente, non trucchi TCAM);
TCAM affettare è troppo difficile per me capire, ma sembra che si otterrà tra i 512 e 6K voci TCAM in base alla complessità delle condizioni di accordo. In base alla lunghezza corrispondente usato da Junos si arriva fino a 512 porta- o VLAN ACL voci o fino a 1024 voci IP ACL;
TCAM non è ampia abbastanza per tutte le possibili condizioni di accordo di IPv6, quindi l'hardware utilizza la compressione indirizzo. Sembra si può avere al massimo 128 indirizzi di origine e di destinazione IPv6 in tutti i filtri distribuiti sulla scatola;
Ho perso o frainteso qualcosa? Si prega di scrivere un commento!
Otterrete ulteriori informazioni su QFX5200 così come altri switch basati su Tomahawk nel Data Center Tessuti aggiornamento webinar in primavera 2016.
Ecco quello che ho capito la presentazione ha detto:
Ogni porta 100 GE può essere canalizzato in 4 x 10GE, 4 x 25GE, 2 x 50GE o 1 x 40GE. Sembra che ogni porta può essere eseguito 4 corsie su entrambi i 10 Gbps o 25 Gbps;
I può essere totalmente sbagliato, ma il modo in cui ho capito le specifiche delle porte 100gE uso 100GBASE-SR4 (802.3bm) di serie e sarebbe quindi incompatibile con gli switch che utilizzano più vecchio 100GBASE-SR10 (802.3ba) standard, anche se avrebbero lavorato con tutti i 40 Gbps sensori usando 40GBASE-SR4.
Simile a Trident-2, Tomahawk diventa line-rate (3,2 Tbps) di dimensioni dei pacchetti di cui sopra 250 byte;
Presentazione sostiene instradamento overlay (VXLAN-to-VXLAN o VXLAN-to-VLAN) non è supportata, che è un po 'sorprendente come il gasdotto di inoltro include cessazione tunnel prima di L2 e L3 di ricerca, che dovrebbe essere abbastanza buono;
Il silicio commutazione ha 10 code per porta (bello!);
La latenza di commutazione è di circa 500 ns e può essere ridotto a 300 ns se il chipset è riconfigurato a fare solo semplice commutazione L2;
Tabella di inoltro unificata (UFT; voci 128K) è divisa in banchi di memoria che possono essere allocate alle voci L2, voci ARP e le voci LPM L3;
Una delle stampe nella presentazione accennata prefissi 1K LPM IPv6 più lungo di / 64;
Tomahawk supporta corrispondenza esatta di voci ACL a UFT (non TCAM). UFT dividere con il profilo di filtro-mode possono avere le voci 64K ACL, le voci di LPM 16K IP e ARP voci 8K / MAC;
Ci sono 43 code tra il silicio di commutazione e CPU, ed è possibile configurare il controllo-plane polizia parametri ciascuna coda;
L'hardware supporta etichette 16K MPLS (deve essere una tabella MPLS di ricerca indipendente, non trucchi TCAM);
TCAM affettare è troppo difficile per me capire, ma sembra che si otterrà tra i 512 e 6K voci TCAM in base alla complessità delle condizioni di accordo. In base alla lunghezza corrispondente usato da Junos si arriva fino a 512 porta- o VLAN ACL voci o fino a 1024 voci IP ACL;
TCAM non è ampia abbastanza per tutte le possibili condizioni di accordo di IPv6, quindi l'hardware utilizza la compressione indirizzo. Sembra si può avere al massimo 128 indirizzi di origine e di destinazione IPv6 in tutti i filtri distribuiti sulla scatola;
Ho perso o frainteso qualcosa? Si prega di scrivere un commento!
martedì 24 marzo 2015
WHITEBOX SWITCHING: SEGUIRE LA R & S BUDGET
Poche settimane fa, HP ha annunciato che avrebbero iniziare a vendere whitebox marca (Brite-box) interruttori, e come previsto la stampa di settore è stato immediatamente pieno di opinioni. Come sempre, ha senso seguire il denaro (o, in questo caso, il bilancio R & S) per capire cosa sta succedendo dietro le quinte.
Ho fatto un esercizio molto semplice: ho raccolto le ultime relazioni trimestrali da Arista, Cisco, Dell, HP, e Juniper, e confrontato le loro spese di R & S per le loro entrate. Ecco i risultati di M $ (al meglio delle mie conoscenze e la comprensione della contabilità):
Sappiamo tutti che, indipendentemente da ciò che la SDN e esperti whitebox cercano di dirci, noi stiamo comprando dispositivi di rete a causa del suo software, non hardware (dopo tutto, la maggior parte dei fornitori utilizzano silicio commerciante in un modo o nell'altro comunque), ed è costoso per creare software - è per questo che la maggior parte dei fornitori di rete investono molto in R & S.
Cisco sembra essere un caso interessante - che spendono circa la metà di quello Arista e Juniper fare (percentuale-saggio), ma poi fanno un sacco di acquisizioni. Ho controllato la loro ultima relazione annuale, e segnalare l'acquisizione di circa $ 4G di risorse tecnologiche immateriali (leggi: la tecnologia hanno ottenuto attraverso acquisizioni) l'anno scorso. Quando si aggiunge 1G $ per ogni trimestre a loro spese di R & S, sono quasi in linea con la Arista e Juniper.
E 'incredibile quanto vicino la spesa per R & S (come percentuale delle vendite) è per tre principali fornitori di networking sono. O sono tutti ugualmente stupido o ci deve essere qualcosa che semplicemente di fare una volta passato il piccolo palco di avvio.
Le due eccezioni nella tabella sopra: HP e Dell. Anche quando si aggiunge l'acquisizione importante occasionale da parte di HP, la spesa per la R & S è ben al di sotto la folla ACJ. Anche tenere a mente che si potrebbe fare acquisizioni per ottenere la tecnologia interessante o per comprare quote di mercato e base clienti - si dovrebbe verificare come HP riporta quello che hanno ottenuto dalle acquisizioni (se avete tempo di passare attraverso un altro rapporto annuale e trovare la risposta, si prega di scrivere un commento).
Per farla breve: sembra Dell e HP non investono abbastanza in ricerca e sviluppo per essere una valida concorrente networking-lungo termine. Il modo migliore di procedere per loro sembra essere quella di cambiare il modello di business.
Dell è ovviamente sta tornando ad essere una società di logistica impressionante - la loro strategia a lungo termine sembra essere hardware a marchio Dell in combinazione con software di terze parti (sia sistemi server o operativi di rete).
HP sembra andare giù l'integrazione di sistema (e dei servizi) percorso. Il loro ultimo annuncio di commutazione whitebox è un approccio tipico system integrator: acquistare hardware di vendor A, software vendor B, e vendere il risultato al vostro cliente.
Ritiene che convalidare il modello britebox? No. Dobbiamo ancora vedere la Dell e HP offrono le promesse (unico centro di supporto che può effettivamente risolvere i vostri problemi).
Se stai già utilizzando questo modello e sono disposti a condividere le vostre esperienze, scrivete un commento.
Ha il modello britebox incantesimo problemi per i fornitori di rete tradizionali? Non proprio. Le grandi aziende preferiscono magra software basato su Linux-networking troveranno il loro modo di Cumulus; chi preferisce più ricco insieme di funzionalità in un unico CLI / API ombrello sarà attaccare con Arista, Cisco o Juniper - tenere a mente Oracle è ancora in vendita i loro prodotti di database a 20 anni dalla MySQL è stato lanciato. Infine, almeno uno di questi tre fornitori che ho citato alla fine essere intelligenti abbastanza per iniziare a vendere software separato dall'hardware come Gigamon deciso di fare.
Su una nota tangenziali, le mosse di HP e Dell renderanno la vita più facile per le persone come me - poi sarò in grado di rimuovere uno o due fornitori dai miei webinar Data Center Fabric di aggiornamento, e ho pensato di includere Cumulus nel maggio 2015 sessione comunque.
Ho fatto un esercizio molto semplice: ho raccolto le ultime relazioni trimestrali da Arista, Cisco, Dell, HP, e Juniper, e confrontato le loro spese di R & S per le loro entrate. Ecco i risultati di M $ (al meglio delle mie conoscenze e la comprensione della contabilità):
Sappiamo tutti che, indipendentemente da ciò che la SDN e esperti whitebox cercano di dirci, noi stiamo comprando dispositivi di rete a causa del suo software, non hardware (dopo tutto, la maggior parte dei fornitori utilizzano silicio commerciante in un modo o nell'altro comunque), ed è costoso per creare software - è per questo che la maggior parte dei fornitori di rete investono molto in R & S.
Cisco sembra essere un caso interessante - che spendono circa la metà di quello Arista e Juniper fare (percentuale-saggio), ma poi fanno un sacco di acquisizioni. Ho controllato la loro ultima relazione annuale, e segnalare l'acquisizione di circa $ 4G di risorse tecnologiche immateriali (leggi: la tecnologia hanno ottenuto attraverso acquisizioni) l'anno scorso. Quando si aggiunge 1G $ per ogni trimestre a loro spese di R & S, sono quasi in linea con la Arista e Juniper.
E 'incredibile quanto vicino la spesa per R & S (come percentuale delle vendite) è per tre principali fornitori di networking sono. O sono tutti ugualmente stupido o ci deve essere qualcosa che semplicemente di fare una volta passato il piccolo palco di avvio.
Le due eccezioni nella tabella sopra: HP e Dell. Anche quando si aggiunge l'acquisizione importante occasionale da parte di HP, la spesa per la R & S è ben al di sotto la folla ACJ. Anche tenere a mente che si potrebbe fare acquisizioni per ottenere la tecnologia interessante o per comprare quote di mercato e base clienti - si dovrebbe verificare come HP riporta quello che hanno ottenuto dalle acquisizioni (se avete tempo di passare attraverso un altro rapporto annuale e trovare la risposta, si prega di scrivere un commento).
Per farla breve: sembra Dell e HP non investono abbastanza in ricerca e sviluppo per essere una valida concorrente networking-lungo termine. Il modo migliore di procedere per loro sembra essere quella di cambiare il modello di business.
Dell è ovviamente sta tornando ad essere una società di logistica impressionante - la loro strategia a lungo termine sembra essere hardware a marchio Dell in combinazione con software di terze parti (sia sistemi server o operativi di rete).
HP sembra andare giù l'integrazione di sistema (e dei servizi) percorso. Il loro ultimo annuncio di commutazione whitebox è un approccio tipico system integrator: acquistare hardware di vendor A, software vendor B, e vendere il risultato al vostro cliente.
Ritiene che convalidare il modello britebox? No. Dobbiamo ancora vedere la Dell e HP offrono le promesse (unico centro di supporto che può effettivamente risolvere i vostri problemi).
Se stai già utilizzando questo modello e sono disposti a condividere le vostre esperienze, scrivete un commento.
Ha il modello britebox incantesimo problemi per i fornitori di rete tradizionali? Non proprio. Le grandi aziende preferiscono magra software basato su Linux-networking troveranno il loro modo di Cumulus; chi preferisce più ricco insieme di funzionalità in un unico CLI / API ombrello sarà attaccare con Arista, Cisco o Juniper - tenere a mente Oracle è ancora in vendita i loro prodotti di database a 20 anni dalla MySQL è stato lanciato. Infine, almeno uno di questi tre fornitori che ho citato alla fine essere intelligenti abbastanza per iniziare a vendere software separato dall'hardware come Gigamon deciso di fare.
Su una nota tangenziali, le mosse di HP e Dell renderanno la vita più facile per le persone come me - poi sarò in grado di rimuovere uno o due fornitori dai miei webinar Data Center Fabric di aggiornamento, e ho pensato di includere Cumulus nel maggio 2015 sessione comunque.
giovedì 5 marzo 2015
CISCO ACI - UN TESSUTO TESO CHE IN REALTÀ OPERE
A metà febbraio un post sul blog sul sito di Cisco ha annunciato allungato tessuto ACI (punti bonus per non usare il marketing grammatica , ma parlando di un prodotto di spedizione ). Funzionerà meglio di altri tessuti a base di PowerPoint- ? Ci puoi scommettere!
Qual è il problema?
Tessuto di Cisco ACI utilizza distribuito (per-switch) di controllo aereo con i controller APIC forniscono configurazione tessuto e funzionalità di gestione. A questo proposito, il tessuto ACI non è diverso da qualsiasi altra rete di router, e sappiamo che chi lavora bene in ambienti distribuiti.
Ma per quanto riguarda Stretched sottoreti?
Anche se è possibile utilizzare Cisco ACI per implementare sottoreti allungate (e c'era la menzione obbligatoria di mobilità VM nella documentazione di Cisco), il tessuto utilizza VXLAN-over-IP come protocollo di trasporto, rendendo la rete di trasporto di base solida. Non è possibile ottenere un loop di inoltro L2 in una rete L3 puro.
Sottoreti allungato sono così grande idea più che nel passato (non c'è niente che puoi fare per risolvere un concetto rotto), ma la gestione di ACI di sottoreti tese è meglio di qualsiasi altra cosa là fuori (compresi OTV).
ACI utilizza proxy ARP e gateway Anycast su interruttori foglia, e qualcosa di equivalente per il routing host basato su VRF per inoltrare il traffico verso endpoint IP. Il traffico trasportato attraverso il tessuto è il traffico IP quindi principalmente unicast (certamente incapsulato in buste VXLAN), e sappiamo che le reti basate su IP ottenuto abbastanza bravo a gestire il traffico IP unicast.
Ma c'è Split Cervello Problem
Vero - e Cisco si è affrettato ad ammettere il problema esiste (molti produttori cercano di far finta che non hai un problema, perché i collegamenti ridondanti tra i siti non possono mai mancare ) e documentato lo scenario tessuto scissione nelle loro linee guida di progettazione :
Controllore cluster è diviso, e la parte minoritaria del cluster va in modalità di sola lettura;
Il tessuto continua a inoltrare il traffico in base a regole di policy già stabiliti;
Interruttori Leaf in grado di rilevare nuovi endpoint (ammesso che stanno ricoperti di regole di politica esistenti) e segnalarli agli interruttori della colonna vertebrale - sia tessuti isolati continuano quindi a funzionare normalmente anche sotto bordo o topologia nucleo modifiche.
Maggiori informazioni
Se siete interessati a data center fabric, è (RFC 2119) deve guardare i video Cisco ACI da NFD8 e NFD9 , e è necessario registrarsi per il Data Center Tessuti aggiornamento webinar a metà maggio.
Disclosure : Cisco Systems è stata indirettamente copre una parte dei costi della mia partecipazione alla manifestazione Network Field Day 9. Più ...
Tags: Data Center , tessuto , WAN
Email questo
post
Condividi su Twitter
Condividi su Facebook
Ivan Pepelnjak, CCIE # 1354 emerito, è un architetto di rete indipendente. Egli progetta e implementazione di reti di comunicazione di dati su larga scala così come l'insegnamento e la scrittura di libri su tecnologie avanzate dal 1990. Vedi il suo profilo completo , contattare lui o seguireioshints su Twitter.
RELATED POSTS PER CATEGORIE
Data Center
Risposta: perché la tecnologia è ancora importante
Abbiamo bisogno di QoS nel data center?
Liberiamoci del cavo giallo Thick
Whiteboarding Cisco ACI sul Software Gone Wild
Grande Nube Tessuto: Scaling OpenFlow Fabric
Ultimo capitolo di Data Center design Case Studies è pubblicato
Case Study: Combine fisica e appliance virtuali in un cloud privato
È Networking Controller-Based più affidabile tradizionale rete?
Lock-in è inevitabile - si abitua ad esso!
Tessuto
Bandiera Avvertenze in Brocade VCS Fabric
Migliorare ECMP Load Balancing con Flowlets
Load Balancing Elephant bagagli flussi
Facebook Next-Generation Fabric
WAN
Per-Packet bilanciamento del carico su collegamenti WAN
Latency: il Killer di Spread-Out Ideas Application Stack
Affrontare errori di routing bizantini
Viptela SEN: Hybrid Connettività WAN con un tocco SDN
IPv6 in una società globale - un mondo reale Esempio
Workload Mobilità e Realtà: larghezza di banda Vincoli
Packet Riordino e fornitori di servizi
VXLAN e OTV: The Saga Continues
È Data Center Trilogy pacchetto la giusta misura per capire Long Distance vMotion sfide?
Qual è il problema?
Tessuto di Cisco ACI utilizza distribuito (per-switch) di controllo aereo con i controller APIC forniscono configurazione tessuto e funzionalità di gestione. A questo proposito, il tessuto ACI non è diverso da qualsiasi altra rete di router, e sappiamo che chi lavora bene in ambienti distribuiti.
Ma per quanto riguarda Stretched sottoreti?
Anche se è possibile utilizzare Cisco ACI per implementare sottoreti allungate (e c'era la menzione obbligatoria di mobilità VM nella documentazione di Cisco), il tessuto utilizza VXLAN-over-IP come protocollo di trasporto, rendendo la rete di trasporto di base solida. Non è possibile ottenere un loop di inoltro L2 in una rete L3 puro.
Sottoreti allungato sono così grande idea più che nel passato (non c'è niente che puoi fare per risolvere un concetto rotto), ma la gestione di ACI di sottoreti tese è meglio di qualsiasi altra cosa là fuori (compresi OTV).
ACI utilizza proxy ARP e gateway Anycast su interruttori foglia, e qualcosa di equivalente per il routing host basato su VRF per inoltrare il traffico verso endpoint IP. Il traffico trasportato attraverso il tessuto è il traffico IP quindi principalmente unicast (certamente incapsulato in buste VXLAN), e sappiamo che le reti basate su IP ottenuto abbastanza bravo a gestire il traffico IP unicast.
Ma c'è Split Cervello Problem
Vero - e Cisco si è affrettato ad ammettere il problema esiste (molti produttori cercano di far finta che non hai un problema, perché i collegamenti ridondanti tra i siti non possono mai mancare ) e documentato lo scenario tessuto scissione nelle loro linee guida di progettazione :
Controllore cluster è diviso, e la parte minoritaria del cluster va in modalità di sola lettura;
Il tessuto continua a inoltrare il traffico in base a regole di policy già stabiliti;
Interruttori Leaf in grado di rilevare nuovi endpoint (ammesso che stanno ricoperti di regole di politica esistenti) e segnalarli agli interruttori della colonna vertebrale - sia tessuti isolati continuano quindi a funzionare normalmente anche sotto bordo o topologia nucleo modifiche.
Maggiori informazioni
Se siete interessati a data center fabric, è (RFC 2119) deve guardare i video Cisco ACI da NFD8 e NFD9 , e è necessario registrarsi per il Data Center Tessuti aggiornamento webinar a metà maggio.
Disclosure : Cisco Systems è stata indirettamente copre una parte dei costi della mia partecipazione alla manifestazione Network Field Day 9. Più ...
Tags: Data Center , tessuto , WAN
Email questo
post
Condividi su Twitter
Condividi su Facebook
Ivan Pepelnjak, CCIE # 1354 emerito, è un architetto di rete indipendente. Egli progetta e implementazione di reti di comunicazione di dati su larga scala così come l'insegnamento e la scrittura di libri su tecnologie avanzate dal 1990. Vedi il suo profilo completo , contattare lui o seguireioshints su Twitter.
RELATED POSTS PER CATEGORIE
Data Center
Risposta: perché la tecnologia è ancora importante
Abbiamo bisogno di QoS nel data center?
Liberiamoci del cavo giallo Thick
Whiteboarding Cisco ACI sul Software Gone Wild
Grande Nube Tessuto: Scaling OpenFlow Fabric
Ultimo capitolo di Data Center design Case Studies è pubblicato
Case Study: Combine fisica e appliance virtuali in un cloud privato
È Networking Controller-Based più affidabile tradizionale rete?
Lock-in è inevitabile - si abitua ad esso!
Tessuto
Bandiera Avvertenze in Brocade VCS Fabric
Migliorare ECMP Load Balancing con Flowlets
Load Balancing Elephant bagagli flussi
Facebook Next-Generation Fabric
WAN
Per-Packet bilanciamento del carico su collegamenti WAN
Latency: il Killer di Spread-Out Ideas Application Stack
Affrontare errori di routing bizantini
Viptela SEN: Hybrid Connettività WAN con un tocco SDN
IPv6 in una società globale - un mondo reale Esempio
Workload Mobilità e Realtà: larghezza di banda Vincoli
Packet Riordino e fornitori di servizi
VXLAN e OTV: The Saga Continues
È Data Center Trilogy pacchetto la giusta misura per capire Long Distance vMotion sfide?
Iscriviti a:
Post (Atom)