Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Part_3.doc
Скачиваний:
13
Добавлен:
24.11.2019
Размер:
3.43 Mб
Скачать
        1. Загальні правила побудови адресного плану мережі з підмережами.

Впровадження адресного плану вимагає старанної підготовки від мережевого адміністратора. Існують чотири ключові питання, які повинні бути вирішені перед початком планування:

  1. Скільки підмереж організація потребує на сьогодні?

  2. Скільки підмереж організація потребуватиме у майбутньому?

  3. Скільки станцій повинна містити найбільша підмережа на сьогодні?

  4. Скільки станцій повинна містити найбільша підмережа у майбутньому?

Перший крок у процесі планування полягає в округленні максимального числа потрібних підмереж до ближчої більшої степені 2. На другому кроці слід забезпечити достатню кількість адрес станцій у найбільшій підмережі. Наприклад, якщо на сьогодні в найбільшій підмережі організації є 50 комп’ютерів, то слід планувати 26=64 адреси. На останньому кроці слід подбати, щоб виділена IP-адреса для організації мала достатню кількість бітів для впровадження потрібного адресного плану. Якщо, наприклад, організація має одну IP-адресу /16, то вона могла б просто використати 4 біти для номерів підмереж і 6 бітів для номерів станцій. Однак, якщо організація має декілька адрес /24 і потребує впровадити 9 підмереж, то вона може здійснити поділ кожної адреси /24 на чотири підмережі, використовуючи 2 біти, а тоді побудувати об’єднання мереж, поєднуючи підмережі з трьома різними адресами /24. Альтернативне розв’язання полягає у впровадженні мережевих адрес з приватного адресного простору (див. RFC 1918) для внутрішнього використання і застосуванні транслятора мережевих адрес (Network Address TranslatorNAT) для забезпечення зовнішнього доступу.

        1. Нові розв’язання для масштабування адресного простору Internet.

Внаслідок експоненціального зростання кількості маршрутів у Internet гостро стоїть проблема знаходження способу для забезпечення лінійного зростання обсягу таблиць раутінгу. Тому Internet Engineering Task Force (IETF) продовжує опрацьовувати пропозиції та розв’язання, спрямовані на вирішення цієї проблеми.

RFC 1917 вимагає, щоб Internet-спільнота повертала невикористані блоки адрес до уповноваженого органу – Internet Assigned Numbers Authority (IANA) для повторного розподілу. Це включає невикористані IP-адреси, адреси мереж, які ніколи не будуть під’єднані до глобального Inernet з міркувань безпеки, та вузли (sites), які використовують незначний відсоток свого адресного простору. RFC 1917 також звертається до ISP з вимогою повернути мережеві префікси, які лежать поза виділеними їм блоками адрес.

RFC 1918 вимагає, щоб організації використовували приватний адресний простір Internet для станцій, які потребують IP-сполучень всередині мережі підприємства, але не потребують зовнішніх під’єднань до глобального Internet. З цією метою IANA зарезервував такі три адресні блоки для приватних об’єднань мереж (табл. 3.4):

Таблиця 3.4. Приватні IP-адреси.

Від

До

Адреса/мережевий префікс

10.0.0.0

10.255.255.255

10.0.0.0/8

172.16.0.0

172.31.255.255

172.16.0.0/12

192.168.0.0

192.168.255.255

192.168.0.0/16

Кожна організація може вибрати для використання адреси з цих зарезервованих блоків без дозволу від IANA і без включення до реєстру Internet. Оскільки ці адреси ніколи не вводяться до глобальної системи раутінгу Internet, то цей адресний простір може незалежно використовуватися багатьма різними організаціями. Недоліком цієї схеми адресації є те, що для доступу до глобального Internet організація мусить використовувати транслятор мережевих адрес (Network Address TranslatorNAT). Однак застосування приватного адресного простору і NAT значно простіше для клієнтів, бо вони можуть змінювати своїх ISP без потреби перенумерації своїх станцій та мереж або без внесення небажаних ускладнень до агрегованих оголошень маршрутів. Перевага цієї схеми полягає у зменшенні потреби в IP-адресах, так що великі організації можуть потребувати лише малого блоку глобально унікального адресного простору IPv4.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]