00000001 + 00000001 = 00000011 alt text http://locobox.googlepages.com/red_x_round.png

Idee sbagliate sulla rete *

È ora di confessarsi! ... "a un certo punto" pensavi di sapere qualcosa, e alla fine non è stato corretto o non era del tutto corretto a causa di un malinteso sull'argomento.

Costruiamo un buon elenco di idee sbagliate popolari alle prime armi E anche alcuni amministratori IT esperti hanno, esplicitamente sulla rete. La mia speranza è quella di costruire una discarica del cervello molto utile per servire come una buona risorsa per i membri di questa comunità.

Inizierò con un esempio estremamente ovvio (gli articoli con il maggior numero di voti saranno in cima) :

• Tutti gli indirizzi che iniziano con 169 provengono dal sistema di failover APIPA

  Solo 169.254.0.0/16 è riservato per l'assegnazione APIPA quando il sistema operativo non riesce a trovare un indirizzo assegnato per un'interfaccia di rete ( leggi: rfc3927 ).

***** Da non confondere con "Errori commessi da amministratori di sistema"

Mito: consentire l'ICMP non è sicuro.

Questo è un mio animale domestico, ed è abbastanza diffuso da causare problemi significativi su Internet. Oltre alla pratica diagnostica che tutti conosciamo e amiamo, c'è Path MTU Discovery e altre cose che si rompono quando l'ICMP è bloccato.

Alcune persone hanno credenze religiose su indirizzi IP consentiti e non consentiti. Ieri ho visto in una delle risposte qui che "gli indirizzi IP che terminano con .0 o .255 non sono validi" che è chiaramente sbagliato.

Altri ancora pensano che abbiamo solo sottoreti di dimensioni A, B, C, mentre il CIDR ha governato il mondo per un bel po '.

Alcuni sostengono che la disabilitazione delle risposte ICMP renderà la mia workstation invisibile nel suo segmento LAN, il che non è vero. È ancora possibile inviare richieste ARP e nella maggior parte dei casi la macchina invierà una risposta ARP anche se ha un firewall a livello IP in esecuzione.

Altri dicono che le sottoreti private - 192.168.0.0/16 o 10.0.0.0/8 non sono "instradabili" - il che è di nuovo completamente sbagliato.

Le persone restano davvero sorprese quando apprendono in che modo la saturazione del caricamento influisce sulla velocità di download. Questo dipende molto dagli algoritmi di accodamento su entrambe le estremità del collo di bottiglia, ma in caso di connessioni ADSL tipiche il caricamento può influire in modo significativo sul download.

Il lato divertente: alcuni pensano ancora che "Internet è una serie di tubi" .

Tutte le connessioni Internet sono create allo stesso modo, ovvero la velocità di download è l'unica cosa che conta

"Ho appena scoperto cos'è un T1, non sai che il mio cavo Comcast a casa è 6 volte più veloce della nostra connessione al lavoro? Perché non l'abbiamo qui?"

Non emerge più, ma è arrivato al punto in cui preferirei ingoiare le graffette piuttosto che cercare di spiegare uno SLA a un altro ragazzo del marketing. (OK, ho avuto la stessa domanda quando ero uno scrub di supporto per workstation, lo ammetto!)

James Gosling cita Peter Deutsch con il merito degli otto errori del calcolo distribuito :

Fondamentalmente tutti, quando creano per la prima volta un'applicazione distribuita, fanno i seguenti otto presupposti. Tutti dimostrano di essere falsi nel lungo periodo e tutti causano grossi problemi ed esperienze di apprendimento dolorose.

1. La rete è affidabile
2. La latenza è zero
3. La larghezza di banda è infinita
4. La rete è sicura
5. La topologia non cambia
6. C'è un amministratore
7. Il costo del trasporto è zero
8. La rete è omogenea

Ho questi sul muro del mio cubo di fronte al corridoio. A volte sento di inciampare su più di una di queste al giorno .

Un vecchio, ma un buono,

• BPS (bit al secondo) e BAUD sono la stessa cosa, cosa che non lo sono. BAUD è la frequenza dei simboli. In molti sistemi, i simboli codificano ciascuno 2 o più bit. per esempio,

  + 2v = 11
  + 1v = 10
  -1v = 01
  -2v = 00

In pratica...

802.11A! = 54 Mbit / s, 802.11A ~ 27 Mbit / s

802.11B! = 11 Mbit / s, 802.11B ~ 5 Mbit / s

802.11G! = 54 Mbit / s, 802.11G ~ 22 Mbit / s

Odio quando la rete è accusata di qualcosa con un'applicazione che funziona lentamente.

Quando tutto funziona tranne Outlook, interrompere l'aggiornamento del ticket al team di rete dicendo che la rete è inattiva. I lavoratori ignoranti dell'help desk sono la rovina dell'esistenza di molti amministratori.

Che fare cose in "hardware" è sempre meglio che farlo in "software".

(il che porta all'ovvia domanda su dove si disegna la linea tra questi due comunque, o se c'è anche una buona distinzione?)

Che "MBps" e "mbps" sono intercambiabili. Anche se potessi discernere contestualmente che i "millibit" non sono un'unità di misura valida, c'è ancora un fattore 8 di differenza tra i due.

E non farmi nemmeno iniziare con mebibits.

In un ambiente LAN aziendale, molte persone sono ancora convinte che il routing tra i vlans sia più lento del passaggio. Con gli switch moderni di oggi, sia lo switch che il routing sono gestiti in hardware che può elaborare / inoltrare questi pacchetti alla stessa velocità.

L'idea che le appliance hardware dedicate siano sempre migliori, più affidabili e con prestazioni più elevate rispetto all'hardware di base e / o PC - in pratica , con i costi di oggi.

Fondamentalmente è ciò che Cisco vuole farti credere; certo, l'NPE nello chassis del router ha solo un processore ARM a ~ 300 MHz, ma ha tutti questi ASIC (circuiti integrati specifici dell'applicazione) solo per l' inoltro rapido dei pacchetti, ricerche di routing FIB e così via.

Anche se questo può essere vero, e io in genere fare favore con attrezzi di proprietà di questo genere per i router e switch per una serie di motivi amministrativi e MTBF-correlate, il fatto è che in epoca di 3 GHz e 8 GB di RAM, spesso la presenza di ASIC e CAM non ha importanza: il PC può ancora fumare quel router. Certo, tutto ciò che viene fatto nella CPU anziché offboarding su hardware dedicato, e sicuramente, è tutto in processi soggetti alle devastazioni di un ambiente di pianificazione dello spazio utente conteso in un sistema operativo generico, ma quando hai 20 volte la potenza della CPU, a volte non importa - esce ancora molto più avanti e molto più economico.

L'ho imparato di nuovo di recente quando ho avuto a che fare con un buckling PIX di fascia piuttosto alta per aumentare i carichi di elaborazione dei pacchetti in un ambiente VoIP in crescita (router storpi a pacchetti alti al secondo molto di più rispetto alla velocità complessiva in sé e i flussi audio VoIP sono costituiti da grandi quantità di pacchetti molto piccoli); il firewall Linux che ho impostato come misura di stopgap per il routing inter-VLAN nel frattempo ha fatto esplodere quella cosa fuori dall'acqua.

Idem per BGP. C'è ancora un vivace dibattito nel mondo Cisco sulle specifiche minime del router necessarie per contenere una o più viste BGP complete della tabella di routing IPv4 in continua crescita, dal momento che molti modelli di router ne sono generalmente capaci se non si lesinano nella RAM . Bene, sai, Quagga e un solido server Linux con una grande NIC e modifiche I / O a basso interruzione possono fare miracoli. :-)

La duplicazione dell'indirizzo MAc non è possibile. Lo è, è dannatamente improbabile.

L'idea sbagliata che l'uso della connessione wireless significhi che l'accesso a Internet è molto più lento perché mostra 54 MB / s mentre l'utilizzo di una connessione Ethernet mostra 100 MB / s.

Inutile dire che era difficile spiegare all'utente che era solo la velocità della rete locale e in realtà la velocità di Internet per il sito era solo di 8 mbps / 900 KB / s.

O in alternativa, gli utenti che ti richiedono di fornire una connessione a banda larga, quindi quando dici loro che il wireless che stanno usando è connesso a una connessione Internet a banda larga, esclamano "No, intendo il cavo blu!"

Il tipo di cavo non ha importanza per la rete purché sia ​​aggraffato professionalmente. Questo proviene da un amministratore che si chiede perché i nuovissimi computer accedano ancora lentamente a Internet con i loro adattatori 100Base-T. Il cavo di rete era Cat-3 IIRC.

L'idea sbagliata che una rete commutata Ethernet == una rete sicura. Non

Oltre all'onnipresente presenza di strumenti di avvelenamento da arp come 'Cain & Abel' e il loro genere, il fatto che la tabella CAM scada ogni tanto (default 5 minuti su uno switch Cisco ) e quindi inonda un traffico unicast come un hub si traduce in perdita di pacchetti e quindi potenziale perdita di informazioni.

È possibile modificare il valore di timeout sugli switch gestiti per compensare la quantità di inondazioni che si desidera consentire, ma dato che fa parte del funzionamento dello switch Ethernet, non è possibile mitigarlo completamente.

Che è necessario un cavo incrociato per collegare 2 computer con Gigabit Ethernet. Tu no! Patch fa il trucco!

Mito: raddoppiare i bps di un collegamento raddoppia la velocità utile.

Come per molti miti, ciò può essere vero in alcune circostanze limitate, ma ignora la latenza del collegamento e i limiti di prestazione dei sistemi finali e dei protocolli.

L'aumento dei bps riduce il tempo impiegato da un sistema per ottenere i dati sul collegamento, ma non consente ai dati di spostarsi più rapidamente lungo il collegamento. Il tempo per l'inizio del primo bit per arrivare all'altra estremità è lo stesso di prima, ma il ritardo fino all'arrivo dell'ultimo bit è ridotto.

Ho alcuni miti relativi alle reti private (10.xxx, 192.168.xx, ecc.).

Mito 1: gli IP privati ​​non possono mai apparire sulla rete pubblica. Pertanto, non è possibile che un IP privato che non è il tuo compaia, per esempio, in un elenco traceroute o nelle intestazioni SMTP "Ricevute da".

Mito 2: non è possibile per un server DNS con connessione a Internet distribuire gli indirizzi IP della rete privata.

Entrambi questi miti derivano dallo stesso malinteso: che gli IP privati ​​sono veramente privati ​​e che non si mescolano mai con gli IP pubblici. Credo che le specifiche affermino solo che gli IP privati ​​non devono mai essere instradati sulla rete pubblica. Cioè, se provi a trovare il percorso verso un IP privato casuale (supponendo che non sia sulla tua rete), non arriverai da nessuna parte.

Ma ciò non preclude la visualizzazione di IP privati ​​nell'output o nel risultato di alcune query. I server di posta interni, ad esempio, non hanno un indirizzo IP pubblico, quindi quale altro indirizzo IP possono includere nell'intestazione Received-By diverso dal loro?

Allo stesso modo, una grande rete istituzionale può utilizzare diverse reti private tra le loro numerose LAN. I pacchetti che passano attraverso la loro rete rileveranno gli IP privati ​​dei router, anche se alla fine tornano sulla rete pubblica. Pertanto, un traceroute può includere l'IP privato di un router nel suo output.

Mito 3: Poiché gli indirizzi di rete privata non sono instradabili, due LAN che condividono lo stesso spazio di indirizzi di rete privata possono essere collegate tramite un bridge (come una VPN) senza problemi.

Non funzionerà - almeno non nella mia esperienza. Supponiamo che il tuo lavoro utilizzi la rete 192.168.1.x e tu usi la stessa a casa (come è tipico dei router di consumo). Stabilisci una connessione VPN dal tuo PC di casa per funzionare. Ad un certo punto, si desidera inviare un lavoro di stampa a una stampante sul posto di lavoro il cui indirizzo IP è 192.168.1.10. Il tuo PC di casa guarda nella sua tabella di routing per capire dove inviare quel pacchetto. Quale LAN dovrebbe riceverlo: la tua LAN di casa o la tua LAN di lavoro? Risposta: non lo so. Forse questo, forse quello. Uno di loro lo capirà, ma probabilmente dipende dal sistema operativo e dal software VPN per distinguere quale ha la priorità. Se è come il software VPN con cui ho avuto esperienza, la tua LAN di casa lo otterrà e se non c'è un dispositivo a 192.168.1.10, il pacchetto verrà eliminato alla fine.

Soluzione: quando si utilizza una VPN, assicurarsi che entrambe le LAN utilizzino spazi di rete diversi.

Penso che il più grande malinteso che vedo sia che la rete basata su IP può risolvere tutte le nostre esigenze IT o tecniche.

Il più grande esempio che vedo di questo è VOIP. È un'infrastruttura di telecomunicazione che è così incredibilmente costosa, dispendiosa in termini di risorse e difficile da gestire correttamente. Sicuramente le distribuzioni funzionano ... in un certo senso, ma sono sicuro che potrebbero esserci sistemi molto migliori con protocolli / infrastrutture dedicati.

Che un punto di accesso wireless di tipo domestico (o due) possa sostituire una rete cablata in un ambiente multiutente. Certo, la tua connessione wireless a casa gestisce fino a circa 5 PC, ma provi a farla gestire con due aule di 30 bambini che provano tutti a usare i laptop per accedere contemporaneamente a un dominio Windows. È necessario un sistema wireless gestito o alcuni punti cablati fissi per gestire parte (bene, la maggior parte) del carico. E una breve nota per i venditori di sistemi wireless gestiti là fuori: sì, sono sicuro che il tuo sistema abbia prestazioni migliori rispetto alla concorrenza, ma non è infinito - c'è solo così tanta larghezza di banda che puoi spremere dal set limitato di frequenze disponibile per il wireless 802.11, non puoi cambiare le leggi della fisica!

Ciò, se la condivisione file SMB / NetBIOS non funziona, non funzionerà nient'altro sulla rete (compresa la navigazione nel WWW) e l'intera rete non funzionerà.

Un ex educatore via web trasformato in amministratore di sistema pensava che quando ero al liceo. Non so se fosse disabitata della nozione di cui sopra.

Che ne pensi dell'idea sbagliata che puoi dividere la larghezza di banda di un link (in bit / sec) per 8 per modellare accuratamente quanti byte transiterà. Pago sempre sul 75% (massimo) di otto decimi della velocità del collegamento (ovvero per un collegamento da 10 GBps che banca su un massimo di 600 MBps).

OK, ecco qualcosa che ho appena scoperto che prima mi aveva eluso, per ogni pacchetto che invii appare l'overhead medio è di 38 byte, questo include l'intestazione IP e TCP (ovviamente questo valore presuppone che vengano utilizzati tutti i campi nell'intestazione TCP al massimo, la dimensione dell'intestazione IP è un valore comune, cioè nessun valore DSCP, ecc. ecc.), quindi per trasferire dire 2 MB (con dimensioni dei pacchetti a 64 KB che aumentano i pacchetti al secondo [pacchetti più grandi al secondo = overhead più piccolo] ) stai osservando 1,2 KB di sovraccarico, non molto ma ciò equivale a 6,78 MB per ogni 10 GB trasferiti e 607,8 MB per ogni 1 TB trasferito.

Adesso sto meglio: D

Mito: l'aggiunta di più larghezza di banda a una connessione renderà sempre le cose più veloci.

Non così tanto. Se il tuo link non è saturo e stai cercando di ottenere dati dalla Cina agli Stati Uniti, potresti semplicemente andare più veloce che puoi. Ci vuole tempo (anche alla velocità della luce) per arrivare dagli Stati Uniti alla Cina e rendere il collegamento non andrà più veloce se si ha un solo flusso di dati tra i siti.

Modificando con cura un socket con l' SO_LINGERopzione per prevenire lo TIME_WAITstato di TCP perché " TIME_WAITè, sai, quindi, sai, vecchio e, sai, tipo, schifoso ".

Che il tuo manager / capo, "SR Network Admin", sappia qualcosa sulla rete reale. -disgruntled Jr Network Admin.