Le site client n'a pas d'adresse IP, il veut passer du / 24 au / 12 masque de réseau… Mauvaise idée?

Un de mes sites clients m'a appelé pour me demander de changer les masques de sous-réseau des serveurs Linux que j'y gère pendant qu'ils ré-IP / changent le masque de réseau de leur réseau sur la base d'un schéma 10.0.0.x.

"Pouvez-vous changer les masques de serveur Linux de 255.255.255.0 à 255.240.0.0?"

Vous voulez dire, 255.255.240.0?

"Non, 255.240.0.0."

Êtes-vous sûr d'avoir besoin d'autant d'adresses IP?

"Oui, nous ne voulons jamais manquer d'adresses IP."

Une vérification rapide par rapport à la feuille de triche du sous - réseau montre:

• un masque de réseau 255.255.255.0 , a / 24 fournit 256 hôtes. Il est clair qu'une organisation peut épuiser ce nombre d'adresses IP.
• un masque de réseau 255.240.0.0 , a / 12 fournit 1 048 576 hôtes. Il s'agit d'un petit site de moins de 200 utilisateurs. Je doute qu'ils allouent plus de 400 adresses IP, jamais ... Peut-être 500, mais à ce stade, plus de sous-réseaux / VLAN devraient être établis.

J'ai suggéré quelque chose qui fournit moins d'hôtes, comme un / 22 ou / 21 (1024 et 2048 hôtes, respectivement), mais n'a pas été en mesure de donner une raison spécifique contre l' utilisation du sous-réseau / 12.

Y a-t-il quelque chose qui devrait inquiéter ce client? Y a-t-il des raisons spécifiques pour lesquelles ils ne devraient pas utiliser un masque aussi grand dans leur environnement?

• Comme indiqué dans d'autres réponses, avoir trop d'hôtes dans le domaine de diffusion peut vraiment commencer à gâcher les émissions.

  Ils auront besoin de beaucoup d'extension dans le sous-réseau avant que cela ne devienne un problème potentiel.

• La planification de la croissance future devient un gâchis.

  Ajouter des sites supplémentaires avec leur propre espace IP devient difficile lorsque vous avez déjà étendu une empreinte inutilement énorme dans l'espace disponible.

• Les limites de sécurité du réseau interne deviennent impossibles.

  L'affectation de différents sous-réseaux à différents groupes d'utilisateurs et la répartition des serveurs à faible sécurité / serveurs à haute sécurité / interfaces de gestion restreintes des serveurs / stockage / périphériques réseau sortent de la fenêtre.

  L'ordinateur portable de tout ancien utilisateur qui a détecté un virus à la maison peut ARP empoisonner le réseau et détruire les serveurs ou les intercepter. Vous n'avez aucun moyen de garder un appareil compromis à l'écart des emplacements réseau sensibles, comme les interfaces de gestion hors bande des serveurs. Une faute de frappe dans une reconfiguration innocente des paramètres réseau peut potentiellement entrer en conflit IP avec tout autre périphérique sur le réseau.

S'ils ne prévoient pas de se développer d'une manière qui nécessiterait un plus grand nombre de sous-réseaux et de ne jamais ajouter de complexité ou de sécurité à leur réseau, alors c'est bien, car il est effectivement identique à leur configuration réseau actuelle - mais s'ils 'demandons cela, ils prévoient évidemment de se développer.

Inutile au mieux, et sérieusement mauvaise idée au pire.

Non, il n'y a rien de mal à utiliser un masque plus grand, si le nombre d'hôtes à l'intérieur reste le même.

Le seul problème est que cela fait que les administrateurs réseau deviennent paresseux et ne font pas de sous-réseau approprié, ce qui fait qu'un grand nombre d'hôtes se trouvent dans le même domaine de diffusion. Par exemple, chaque demande ARP est une diffusion, et toutes les machines (dans le même domaine de diffusion) doivent la traiter (même si généralement une seule répond). Il en va de même pour les autres protocoles utilisant la diffusion.

Un autre problème pourrait être l'espace d'adressage, car 10/8 a de l'espace pour seulement 16/12 réseaux, et s'ils continuent avec leurs / 12 demandes, ils ne peuvent en contenir que 15 de plus.

Certains logiciels de sécurité, qui font du portage / des pingscans, pour découvrir des hôtes en direct prendront beaucoup plus de temps que maintenant (s'ils l'ont).

Sinon, cela n'a pas d'importance. Si vous n'avez que deux hôtes, les performances seront les mêmes avec un / 30 ou un / 8 - la taille du réseau ne pose aucun problème de performances.

Les arguments contre cela, je peux le voir, sont que vous avez alors un domaine de diffusion plus large et qu'ils n'auraient pas autant de sous-réseaux supplémentaires disponibles à partir de 10.XXX

Pour contrer l'argument des émissions, si elles ne font que planifier une croissance future, l'impact sur le réseau actuel devrait être négligeable. Vous pouvez également limiter vos serveurs DHCP pour ne distribuer qu'une petite partie du sous-réseau complet afin de contrôler les choses jusqu'à ce que davantage d'adresses IP soient vraiment nécessaires.

Personnellement, je plaiderais toujours contre cela, car cela n'est pas nécessaire. Identifiez le nombre d'adresses d'hôte nécessaires et projetez pour une croissance future plutôt que de simplement lancer un énorme sous-réseau.

Un ancien employeur a fait décider un grand département de reconcevoir son réseau départemental autour de a / 16. Même si ce département particulier avait plusieurs sites à travers des liaisons à latence relativement élevée (haut débit municipal). Cela a fonctionné pour eux, et cela arrivait il y a une décennie lorsque les liens Gig n'étaient communs que dans le centre de données et dans les liens de distribution.

Pour autant que je sache, ils n'ont jamais eu de problème de diffusion. Comme je l'ai dit, c'était il y a une dizaine d'années avec des appareils beaucoup plus stupides gérant le trafic de diffusion; les appareils modernes ne devraient même pas y réfléchir à deux fois. Ce réseau particulier avait environ deux fois les nœuds que vous aviez.

Autrement dit, il n'y a rien de mal à un si grand sous-réseau, tant que votre réseau peut le gérer .