00000001 + 00000001 = 00000011 texte alternatif http://locobox.googlepages.com/red_x_round.png

Idées fausses sur le réseautage *

Il est temps de s'essayer! ... `` à un moment donné '', vous pensiez que vous saviez quelque chose, et cela a fini par ne pas être correct, ou pas entièrement correct en raison d'une idée fausse sur le sujet.

Construisons une bonne liste des idées fausses populaires novices ET même certains administrateurs informatiques chevronnés ont, explicitement sur la mise en réseau. Mon espoir est de construire un brain-dump très utile pour servir de bonne ressource pour les membres de cette communauté.

Je vais commencer par un exemple extrêmement évident (les articles avec le plus de votes seront en haut) :

• Toutes les adresses commençant par 169 proviennent du système de basculement APIPA

  Seul 169.254.0.0/16 est réservé pour l'affectation APIPA lorsque le système d'exploitation ne peut pas trouver une adresse affectée pour une interface réseau ( lire: rfc3927 ).

***** À ne pas confondre avec "Erreurs commises par des administrateurs système"

Mythe: Autoriser ICMP n'est pas sûr.

Celui-ci est une bête noire, et il est suffisamment répandu pour causer des problèmes importants sur Internet. Mis à part les diagnostics pratiques que nous connaissons et aimons tous, il y a Path MTU Discovery et d'autres choses qui se cassent lorsque ICMP est bloqué.

Certaines personnes ont des croyances religieuses sur les adresses IP autorisées et non autorisées. Hier, j'ai vu dans l'une des réponses ici que «les adresses IP se terminant par .0 ou .255 ne sont pas valides», ce qui est tout à fait faux.

D'autres pensent encore que nous n'avons que des sous-réseaux de taille A, B et C, alors que le CIDR régnait sur le monde depuis un bon moment.

Certains prétendent que la désactivation des réponses ICMP rendra mon poste de travail invisible dans son segment LAN, ce qui n'est pas vrai. Vous pouvez toujours envoyer des requêtes ARP et dans la plupart des cas, la machine enverra une réponse ARP bien qu'elle ait un pare-feu de niveau IP en cours d'exécution.

D'autres disent que les sous-réseaux privés - 192.168.0.0/16 ou 10.0.0.0/8 ne sont «pas routables» - ce qui est tout à fait faux.

Les gens sont vraiment surpris lorsqu'ils apprennent comment la saturation du téléchargement affecte leur vitesse de téléchargement. Cela dépend beaucoup des algorithmes de mise en file d'attente aux deux extrémités du goulot d'étranglement, mais dans le cas de connexions ADSL typiques, le téléchargement peut affecter considérablement le téléchargement.

Côté drôle: certains pensent encore que "Internet est une série de tubes" .

Toutes les connexions Internet sont créées à la même vitesse de téléchargement, c'est la seule chose qui compte

"Je viens de découvrir ce qu'est un T1, ne savez-vous pas que mon câble Comcast à la maison est 6 fois plus rapide que notre connexion au travail? Pourquoi ne l'avons-nous pas ici?"

Cela ne revient plus, mais c'est arrivé au point où je préfère avaler des agrafes plutôt que d'essayer d'expliquer un SLA à un autre gars du marketing. (OK, j'avais la même question quand j'étais gommage de support de poste de travail, je l'admets!)

James Gosling cite Peter Deutsch pour les huit erreurs de l'informatique distribuée :

Essentiellement, tout le monde, lors de la création d'une application distribuée, fait les huit hypothèses suivantes. Tous s'avèrent faux à long terme et provoquent tous de gros ennuis et des expériences d'apprentissage douloureuses.

1. Le réseau est fiable
2. La latence est nulle
3. La bande passante est infinie
4. Le réseau est sécurisé
5. La topologie ne change pas
6. Il y a un administrateur
7. Le coût du transport est nul
8. Le réseau est homogène

Je les ai sur le mur de mon cube face au couloir. Parfois, j'ai l'impression de trébucher sur plus d'un de ceux-ci par jour .

Un vieux, mais un goody,

• BPS (bits par seconde) et BAUD sont la même chose - ce qu'ils ne sont pas. BAUD est le taux de symbole. Dans de nombreux systèmes, les symboles codent chacun 2 bits ou plus. par exemple,

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

En pratique...

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

Je déteste quand le réseau est blâmé pour quelque chose avec une application qui tourne lentement.

Lorsque tout fonctionne, sauf votre Outlook, arrêtez de mettre à niveau le ticket vers l'équipe réseau en disant que le réseau est en panne. Les travailleurs ignorants du service d'assistance sont le fléau de l'existence de nombreux administrateurs.

Faire des trucs en "matériel" est toujours plus performant qu'en faire en "logiciel".

(ce qui conduit à la question évidente de savoir où l'on trace la frontière entre ces deux de toute façon, ou s'il y a même une bonne distinction?)

Que "MBps" et "mbps" sont interchangeables. Même si je pouvais discerner contextuellement que les «millibits» ne sont pas une unité de mesure valide, il y a toujours un facteur de différence de 8 entre les deux.

Et ne me lancez même pas sur les mebibits.

Dans un environnement LAN d'entreprise, de nombreuses personnes supposent toujours que le routage entre les réseaux locaux virtuels est plus lent que la commutation. Avec les commutateurs modernes d'aujourd'hui, la commutation et le routage sont gérés par du matériel qui peut traiter / transmettre ces paquets à la même vitesse.

L'idée que les appliances matérielles dédiées sont toujours meilleures, plus fiables et plus performantes que le matériel de base et / ou PC - en pratique , avec les coûts d'aujourd'hui.

C'est essentiellement ce que Cisco veut que vous croyiez; Bien sûr, le NPE dans le châssis du routeur n'a qu'un processeur ARM ~ 300 MHz, mais il a tous ces ASIC (Application Specific Integrated Circuits) juste pour le transfert rapide de paquets, les recherches de routage FIB et ainsi de suite.

Bien que cela puisse être vrai, et je généralement faire faveur en utilisant des engins exclusifs de ce genre pour les routeurs et commutateurs pour diverses raisons administratives et connexes MTBF, le fait est que , dans l'ère de 3 processeurs GHz et 8 Go de RAM, souvent la présence d'ASIC et de CAM n'a pas d'importance - le PC peut toujours fumer ce routeur. Bien sûr, tout est fait dans le CPU au lieu d'être intégré à du matériel dédié, et bien sûr, tout est dans des processus soumis aux ravages d'un environnement de programmation d'espace utilisateur dans un système d'exploitation polyvalent, mais lorsque vous avez 20 fois la puissance du CPU, parfois cela n'a pas d'importance - il sort toujours bien en avance, et beaucoup moins cher.

J'ai appris cela à nouveau récemment lorsqu'il s'agissait d'un flambage PIX assez haut de gamme pour augmenter les charges de traitement des paquets dans un environnement VoIP en pleine croissance (les routeurs paralysés à paquets par seconde beaucoup plus que le débit global en soi, et les flux audio VoIP se composent de très grandes quantités de très petits paquets); le pare-feu Linux que j'ai mis en place comme mesure provisoire pour le routage inter-VLAN a entre-temps fait sauter cette chose hors de l'eau.

Idem pour BGP. Il y a toujours un débat animé dans le monde Cisco sur les spécifications de routeur minimales nécessaires pour contenir une ou plusieurs vues BGP complètes de la table de routage IPv4 en constante évolution, car de nombreux modèles de routeurs en sont généralement capables s'ils n'étaient pas étriqués sur la RAM . Eh bien, vous savez, Quagga et un serveur Linux solide avec une excellente carte d'interface réseau et des ajustements d'E / S à faible interruption peuvent faire des merveilles. :-)

Cette duplication d'adresse MAc n'est pas possible. C'est, c'est juste sacrément improbable.

L'idée fausse selon laquelle l'utilisation du sans fil signifie un accès à Internet est beaucoup plus lente car elle affiche 54 Mo / s alors que l'utilisation d'une connexion Ethernet affiche 100 Mo / s.

Inutile de dire qu'il était difficile d'expliquer à l'utilisateur qu'il ne s'agissait que de la vitesse du réseau local et, en fait, la vitesse Internet du site n'était que de 8 Mbps / 900 Ko / s.

Ou bien, les utilisateurs qui vous demandent de fournir une connexion haut débit, puis lorsque vous leur dites que le sans fil qu'ils utilisent est connecté à une connexion Internet haut débit, ils s'exclament "Non, je veux dire le câble bleu!"

Le type de câble n'a pas d'importance pour le réseau tant qu'il est professionnellement serti. Cela vient d'un administrateur qui se demande pourquoi les nouveaux ordinateurs accèdent encore lentement à Internet avec leurs adaptateurs 100Base-T. Le câble réseau était Cat-3 IIRC.

L'idée fausse selon laquelle un réseau commuté Ethernet == un réseau sécurisé. Ce n'est pas le cas.

Outre la présence omniprésente d'outils d'empoisonnement par arp tels que 'Cain & Abel' et leurs semblables, le fait que la table CAM expire de temps en temps ( 5 minutes par défaut sur un commutateur Cisco ) et inonde ainsi le trafic unicast comme un concentrateur se traduit par fuite de paquets et donc fuite potentielle d'informations.

Vous pouvez modifier la valeur du délai d'expiration sur les commutateurs gérés pour compenser la quantité d'inondation que vous souhaitez autoriser, mais étant donné que cela fait partie du fonctionnement de la commutation Ethernet, vous ne pouvez pas l'atténuer complètement.

Que vous avez besoin d'un câble croisé pour connecter 2 ordinateurs avec Gigabit Ethernet. Vous n'en avez pas! Patch fait l'affaire!

Mythe: doubler les bps d'une liaison double le débit utile.

Comme pour de nombreux mythes, cela peut être vrai dans certaines circonstances limitées, mais il ignore la latence du lien et les limites de performances des systèmes d'extrémité et des protocoles.

L'augmentation des bps réduit le temps nécessaire à un système pour obtenir les données sur le lien, il ne fait pas accélérer le déplacement des données le long du lien. Le temps pour que le début du premier bit arrive à l'autre extrémité est le même qu'avant mais le délai jusqu'à l'arrivée du dernier bit est réduit.

J'ai quelques mythes liés aux réseaux privés (10.xxx, 192.168.xx, etc.).

Mythe 1: les adresses IP privées ne peuvent jamais apparaître sur le réseau public. Par conséquent, il n'est pas possible qu'une adresse IP privée qui n'est pas la vôtre apparaisse dans, disons, une liste traceroute ou les en-têtes SMTP "Reçu par".

Mythe 2: Il n'est pas possible pour un serveur DNS connecté à Internet de distribuer des adresses IP de réseau privé.

Ces deux mythes découlent de la même idée fausse: que les adresses IP privées sont vraiment privées et qu'elles ne se mélangent jamais avec des adresses IP publiques. Je crois que la spécification dit seulement que les adresses IP privées ne doivent jamais être acheminées sur le réseau public. Autrement dit, si vous essayez de trouver la route vers une IP privée aléatoire (en supposant que ce n'est pas sur votre propre réseau), vous n'irez nulle part.

Mais cela n'empêche pas les adresses IP privées d'apparaître dans la sortie ou le résultat d'une requête. Les serveurs de messagerie internes, par exemple, n'ont pas d'adresse IP publique, alors quelle autre adresse IP peuvent-ils inclure dans l'en-tête Received-By autre que la leur?

De même, un grand réseau institutionnel peut utiliser différents réseaux privés parmi leurs nombreux réseaux locaux. Les paquets qui transitent par leur réseau récupèrent les adresses IP privées des routeurs, même si le paquet revient finalement sur le réseau public. Ainsi, un traceroute peut inclure l'IP privée d'un routeur dans sa sortie.

Mythe 3: Étant donné que les adresses de réseau privé ne sont pas routables, deux réseaux locaux qui partagent le même espace d'adressage de réseau privé peuvent être connectés sans problème via un pont (tel qu'un VPN).

Cela ne fonctionnera pas - du moins pas d'après mon expérience. Disons que votre travail utilise le réseau 192.168.1.x et que vous utilisez le même à la maison (comme cela est typique des routeurs grand public). Vous établissez une connexion VPN à partir de votre ordinateur personnel pour travailler. À un moment donné, vous souhaitez envoyer un travail d'impression à une imprimante au travail dont l'adresse IP est 192.168.1.10. Votre ordinateur personnel regarde dans sa table de routage pour savoir où envoyer ce paquet. Quel LAN doit le recevoir: votre LAN domestique ou votre LAN professionnel? Réponse: ne sais pas. Peut-être celui-ci, peut-être celui-là. L'un d'eux l'obtiendra, mais cela dépend probablement de votre système d'exploitation et de votre logiciel VPN pour distinguer celui qui a la priorité. Si c'est comme le logiciel VPN avec lequel j'ai eu de l'expérience, votre réseau local domestique l'obtiendra et s'il n'y a pas d'appareil au 192.168.1.10, le paquet sera finalement abandonné.

Solution: lorsque vous utilisez un VPN, assurez-vous que les deux réseaux locaux utilisent des espaces réseau différents.

Je pense que la plus grande idée fausse que je vois est que le réseau basé sur IP peut résoudre tous nos besoins informatiques ou techniques.

Le plus grand exemple que je vois de cela est VOIP. C'est une infrastructure de télécommunications qui est incroyablement coûteuse, gourmande en ressources et difficile à gérer correctement. Bien sûr, les déploiements fonctionnent ... en quelque sorte, mais je suis sûr qu'il pourrait y avoir de bien meilleurs systèmes avec des protocoles / infrastructures dédiés.

Qu'un point d'accès sans fil de style domestique (ou deux) peut remplacer un réseau câblé dans un environnement multi-utilisateur. Bien sûr, votre connexion sans fil à la maison gère jusqu'à 5 PC environ, mais vous essayez de la faire fonctionner avec deux salles de classe de 30 enfants qui essaient tous d'utiliser des ordinateurs portables pour se connecter à un domaine Windows en même temps. Vous avez besoin d'un système sans fil géré ou de certains points câblés fixes pour gérer une partie (enfin, la plupart) de la charge. Et un petit mot pour les vendeurs de systèmes sans fil gérés: oui, je suis sûr que votre système a de meilleures performances que la concurrence, mais ce n'est pas infini - il y a seulement tellement de bande passante que vous pouvez retirer de l'ensemble limité de fréquences disponible sans fil 802.11, vous ne pouvez pas changer les lois de la physique!

Que, si le partage de fichiers SMB / NetBIOS ne fonctionne pas, rien d'autre ne fonctionnera sur le réseau (y compris la navigation sur le WWW) et l'ensemble du réseau est en panne.

Un ancien éducateur connecté au Web, devenu administrateur système, a pensé cela lorsque j'étais au lycée. Je ne sais pas si elle était désabusée de la notion ci-dessus.

Que diriez-vous de l'idée fausse selon laquelle vous pouvez diviser la bande passante d'un lien (en bits / sec) par 8 pour modéliser avec précision le nombre d'octets qu'il traversera. Je compte toujours sur 75% (max) des huit dixièmes de la vitesse de liaison (c'est-à-dire que pour une liaison de 10 Go / s, je compte sur 600 Mo / s max).

OK, voici quelque chose que je viens de comprendre qui m'avait échappé auparavant, pour chaque paquet que vous envoyez, il semble que la surcharge moyenne est de 38 octets, cela inclut les en-têtes IP et TCP (bien sûr, cette valeur suppose que tous les champs de l'en-tête TCP sont utilisés au maximum, la taille de l'en-tête IP est une valeur courante, c'est-à-dire pas de valeurs DSCP, etc., etc.), donc pour transférer disons 2 Mo (avec des tailles de paquets à 64 Ko augmentant vos paquets par seconde [gros paquets par seconde = surcharge plus petite] ), vous recherchez 1,2 Ko de surcharge, pas beaucoup, mais cela équivaut à 6,78 Mo pour 10 Go transférés et 607,8 Mo pour 1 To transféré.

Je me sens mieux maintenant: D

Mythe: Ajouter plus de bande passante à une connexion accélérera toujours les choses.

Pas tellement. Si votre lien n'est pas saturé et que vous essayez d'obtenir des données de la Chine vers les États-Unis, vous pouvez simplement aller aussi vite que possible. Il faut du temps (même à la vitesse de la lumière) pour se rendre des États-Unis vers la Chine, et faire le lien n'ira pas plus vite si vous n'avez qu'un seul flux de données entre les sites.

Ajuster affectueusement un socket avec l' SO_LINGERoption pour empêcher l' TIME_WAITétat de TCP parce que " TIME_WAITest, vous savez, donc, vous savez, vieux et, vous savez, comme, dégueu ".

Que votre gestion / patron, le "SR Network Admin" sait tout sur le vrai réseau. -Administrateur réseau Jr mécontent.