На сайті клієнта немає IP-адрес, вони хочуть перейти з / 24 до / 12 мережевої маски ... Погана ідея?

Один із моїх клієнтських сайтів закликав мене попросити змінити маски підмережі серверів Linux, якими я керую там, під час повторного IP / зміни мережевої маски своєї мережі за схемою 10.0.0.x.

"Чи можете ви змінити мережеві маски сервера Linux з 255.255.255.0 на 255.240.0.0?"

Ви маєте на увазі, 255.255.240.0?

"Ні, 255.240.0.0."

Ви впевнені, що вам потрібно стільки IP-адрес?

"Так, у нас ніколи не хочеться закінчити IP-адреси."

Швидка перевірка проти шаблону підмережі показує:

• 255.255.255.0 маска підмережі, а / 24 забезпечує 256 хостів. Зрозуміло, що організація може вичерпати таку кількість IP-адрес.
• 255.240.0.0 маска підмережі, а / 12 забезпечує 1048576 господарів. Це невеликий <200 користувачів-сайт. Я сумніваюся, що вони виділять більше 400 IP-адрес, коли-небудь ... Можливо, 500, але в цей момент слід створити більше підмереж / VLAN-мереж.

Я запропонував щось, що забезпечує меншу кількість хостів, як-от / 22 або / 21 (1024 та 2048 хостів відповідно), але не зміг дати конкретної причини проти використання підмережі / 12.

Чи є щось, про що повинен потурбуватися цей клієнт? Чи є якісь конкретні причини, коли вони не повинні використовувати таку неймовірно велику маску у своєму оточенні?

• Як зазначено в інших відповідях, занадто багато хостів у домені широкомовної програми дійсно можуть почати створювати мовлення безлад.

  Їм знадобиться багато розширення в підмережі, перш ніж це стане потенційною проблемою.

• Планування майбутнього зростання стає безладним.

  Додавання додаткових сайтів із власним IP-простором стає складним, коли ви вже проклали величезний слід у доступному просторі.

• Внутрішні межі безпеки мережі стають неможливими.

  Присвоєння різних підмереж різним групам користувачів та розділення серверів низької безпеки / серверів високої безпеки / обмежених інтерфейсів управління серверами / сховищами / мережевими пристроями виходить з вікна.

  Будь-який ноутбук користувача ol ', який підхопив вірус вдома, може ARP отруїти мережу і знести сервери або перейти до них. У вас немає ніякого способу утримати компрометований пристрій подалі від чутливих мережевих локацій, як-от позаполосних інтерфейсів управління серверами. Опечатка в невинному перенастроюванні мережевих налаштувань може потенційно конфліктувати з будь-яким іншим пристроєм у мережі.

Якщо вони не планують рости будь-яким способом, який коли-небудь потребуватиме більше підмереж, і не планують коли-небудь додавати будь-яку складність чи безпеку до своєї мережі, то це добре, оскільки це фактично ідентично їх поточній конфігурації мережі - але якщо вони просимо цього, вони, очевидно, планують розширюватись.

У кращому випадку, і в гіршому випадку погано ідея.

Ні, немає нічого поганого в використанні більшої маски, якщо кількість хостів всередині залишається однаковою.

Єдина проблема полягає в тому, що це робить причиною того, що адміністратори мережі отримують ледачий та не належну підмережу, внаслідок чого велика кількість хостів знаходиться в одному домені широкомовної передачі. Наприклад, кожен запит ARP - це широкомовна передача, і всі машини (в одному і тому ж домені широкомовної передачі) повинні обробляти його (хоча зазвичай відповідає одна). Те саме стосується інших протоколів, які використовують трансляцію.

Іншим питанням може бути адресний простір, оскільки 10/8 має простір лише для 16/12 мереж, і якщо вони продовжать свої 12 запитів, вони можуть вмістити лише ще 15.

Деяке програмне забезпечення для безпеки, яке робить порт / pingscans, для виявлення живих хостів займе набагато більше часу, ніж це зараз (якщо вони є).

Інакше це не має значення. Якщо у вас є лише два хости, продуктивність буде однаковою з / 30 або a / 8 - розмір мережі не викликає проблем із продуктивністю.

Аргументи проти цього я можу бачити, якщо у вас є більший домен широкомовної передачі, і у них не буде стільки доступних додаткових підмереж з 10.XXX

Для протидії аргументації мовлення, якщо вони планують лише майбутнє зростання, вплив на поточну мережу має бути незначним. Ви також можете обмежити ваші DHCP-сервери лише розповсюджувати невелику частину повної підмережі для управління речами до тих пір, поки більше IP-адреси справді не знадобляться.

Я особисто все-таки заперечував би це, як це зайве. Визначте кількість потрібних хост-адрес і проектуйте майбутнє зростання, а не просто викидайте туди величезну підмережу.

Попередній роботодавець мав великий департамент, який вирішив переробити свою відомчу мережу навколо а / 16. Навіть незважаючи на те, що цей конкретний відділ мав декілька сайтів через порівняно високі латентні зв’язки (муніципальна широкосмугова зона). Це працювало на них, і це відбувалося десятиліття тому, коли посилання Gig були поширеними лише в центрі обробки даних і в дистрибутивах.

Наскільки мені було відомо, у них ніколи не було проблем із мовленням. Як я вже говорив, це було десь десять років тому з набагато дурнішими пристроями, що управляють трансляцією трафіку; сучасні пристрої навіть не повинні думати про це. Ця конкретна мережа мала приблизно вдвічі більше вузлів, які ви мали.

Що говорити, з такою великою підмережею немає нічого поганого, якщо ваша мережа може це впоратися .