Организация адресации в ip сетях

адрес. Все эти операции направлены на то, чтобы освободить

администратора сети от утомительных рутинных операций по

конфигурированию сети. Однако использование DHCP несет в себе и

некоторые проблемы. Во-первых, это проблема согласования

информационной адресной базы в службах DHCP и DNS. Как известно, DNS

служит для преобразования символьных имен в IP-адреса. Если IP-

адреса будут динамически изменятся сервером DHCP, то эти изменения

необходимо также динамически вносить в базу данных сервера DNS. Хотя

протокол динамического взаимодействия между службами DNS и DHCP уже

реализован некоторыми фирмами (так называемая служба Dynamic DNS),

стандарт на него пока не принят. Во-вторых, нестабильность IP-

адресов усложняет процесс управления сетью. Системы управления,

основанные на протоколе SNMP, разработаны с расчетом на статичность

IP-адресов. Аналогичные проблемы возникают и при конфигурировании

фильтров маршрутизаторов, которые оперируют с IP-адресами. Наконец,

централизация процедуры назначения адресов снижает надежность

системы: при отказе DHCP-сервера все его клиенты оказываются не в

состоянии получить IP-адрес и другую информацию о конфигурации.

Последствия такого отказа могут быть уменьшены путем использовании в

сети нескольких серверов DHCP, каждый из которых имеет свой пул IP-

адресов. Как уже отмечалось, в адресной схеме протокола выделяют

особые IP-адреса. Если биты всех октетов адреса равны нулю, то он

обозначает адрес того узла, который сгенерировал данный пакет. Это

используется в ограниченных случаях, например в некоторых сообщениях

протокола IP. Если биты сетевого префикса равны нулю, полагается,

что узел назначения принадлежит той же сети, что и источник пакета.

Когда биты всех октетов адреса назначения равны двоичной единице,

пакет доставляется всем узлам, принадлежащим той же сети, что и

отправитель пакета. Такая рассылка называется ограниченным

широковещанием. Наконец, если в битах адреса, соответствующих узлу

назначения, стоят единицы, то такой пакет рассылается всем узлам

указанной сети. Это называется широковещанием. Специальное значение

имеет, так же, адреса сети 127/8. Они используются для тестирования

программ и взаимодействия процессов в пределах одной машины. Пакеты,

отправленные на этот интерфейс, обрабатываются локально, как

входящие. Потому адреса из этой сети нельзя присваивать физическим

сетевым интерфейсам.

2 ОРГАНИЗАЦИЯ ПОДСЕТЕЙ

Очень редко в локальную вычислительную сеть входит более

100-200 узлов: даже если взять сеть с большим количеством узлов,

многие сетевые среды накладывают ограничения, например, в 1024 узла.

Исходя из этого, целесообразность использования сетей класса А и В

весьма сомнительна. Да и использование класса С для сетей, состоящих

из 20-30 узлов, тоже является расточительством. Для решения этих

проблем в двухуровневую иерархию IP-адресов (сеть -- узел) была

введена новая составляющая -- подсеть. Идея заключается в

"заимствовании" нескольких битов из узловой части адреса для

определения подсети. Полный префикс сети, состоящий из сетевого

префикса и номера подсети, получил название расширенного сетевого

префикса. Двоичное число, и его десятичный эквивалент, содержащее

единицы в разрядах, относящихся к расширенному сетевому префиксу, а

в остальных разрядах -- нули, назвали маской подсети. Но маску в

десятичном представлении удобно использовать лишь тогда, когда

расширенный сетевой префикс заканчивается на границе октетов, в

других случаях ее расшифровать сложнее. Допустим, что мы хотели бы

для подсети использовать не 8 бит, а десять. Тогда в последнем (z-

ом) октете мы имели бы не нули, а число 11000000. В десятичном

представлении получаем 255.255.255.192. Очевидно, что такое

представление не очень удобно. В наше время чаще используют

обозначение вида "/xx", где хх -- количество бит в расширенном

сетевом префиксе. Таким образом, вместо указания: "144.144.19.22 с

маской 255.255.255.192", мы можем записать: 144.144.19.22/26. Как

видно, такое представление более компактно и понятно.

2.1 Маска под сети переменной длины (Variable Length Subnet

Mask)

Однако вскоре стало ясно, что подсети, несмотря на все их

достоинства, обладают и недостатками. Так, определив однажды маску

подсети, приходится использовать подсети фиксированных размеров.

Скажем, у нас есть сеть 144.144.0.0/16 с расширенным префиксом /23.

Таблица 3 - С расширенный префикс

| | |Сетевой префикс |Подсеть |Узел |

Такая схема позволяет создать 27 подсетей размером в 29 узлов

каждая. Это подходит к случаю, когда есть много подсетей с большим

количеством узлов. Но если среди этих сетей есть такие, количество

узлов в которых находится в пределах ста, то в каждой их них будет

пропадать около 400 адресов. Решение состоит в том, что бы для одной

сети указывать более одного расширенного сетевого префикса. О такой

сети говорят, что это сеть с маской подсети переменной длины (VLSM).

Действительно, если для сети 144.144.0.0/16 использовать расширенный

сетевой префикс /25, то это больше бы подходило сетям размерами

около ста узлов. Если допустить использование обеих масок, то это бы

значительно увеличило гибкость применения подсетей. Общая схема

разбиения сети на подсети с масками переменной длины такова: сеть

делится на подсети максимально необходимого размера. Затем некоторые

подсети делятся на более мелкие, и рекурсивно далее, до тех пор,

пока это необходимо. Кроме того, технология VLSM, путем скрытия

части подсетей, позволяет уменьшить объем данных, передаваемых

маршрутизаторами. Так, если сеть 12/8 конфигурируется с расширенным

сетевым префиксом /16, после чего сети 12.1/16 и 12.2/16 разбиваются

на подсети /20, то маршрутизатору в сети 12.1 незачем знать о

подсетях 12.2 с префиксом /20, ему достаточно знать маршрут на сеть

12.1/16.

2.2 Протокол межсетевого взаимодействия IP. Формат IP дейтограмм

Перенос между сетями различных типов адресной информации

в унифицированной форме, сборка и разборка пакетов при передаче их

между сетями с различным максимальным значением длины пакета.

Таблица 4 - Формат IP дейтаграммы.

| | длина|тип сервиса |общая длина пакета в байтах |

|версия | | | |

| Идентификация |флаги | Смещение |

|(для всех фрагментов одинаковое) |(3бита) |фрагмента |

|время жизни | | FCS заголовка |

| |протокол | |

|IP-адрес отправителя |

|IP-адрес получателя |

|Опции IP (если есть) |заполнение (до 32 бит) |

|Данные |

Версия (IPv4), длина заголовка в 32 бит. словах, тип сервиса (для

интеллектуальных маршрутизаторов, PPPDTRхх, P - приоритет (для

будущего), D,T,R - запрашиваются мин. задержки, макс. пропускная

способность, макс.надежность).Флаги Do not Fragment - DF, More

Fragments - MF - еще фрагменты.Time to live - в секундах сколько

жить пакету(перегрузки и кольца, снятие 1 при любом переходе). Опции

IP (если есть) - для тестирования или отладки сети (напр. запись

маршрута или обязательное прохождение по маршруту).

Рисунок 5 - Дейтаграмма UDP

Протокол доставки пользовательских дейтаграмм UDP. Формат

сообщений UDP. Протокол надежной доставки сообщений TCP

(Transmission Control Protocol). Порты и установление TCP-

соединений.Протокол доставки пользовательских дейтаграмм UDP. Без

гарантий доставки, поэтому его пакеты могут быть потеряны,

продублированы или прийти не в том порядке, главное - быстрота.

Мультиплексирование и демультиплексирование прикладных протоколов с

помощью протокола UDP.

Формат сообщений UDP.

. UDP source port - номер порта процесса-отправителя,

. UDP destination port - номер порта процесса-получателя,

. UDP message length - длина UDP-пакета в байтах,

. UDP checksum - контрольная сумма UDP-пакета.

(!) Можно не заполнять поля 1 и 4.

Протокол надежной доставки сообщений TCP (Transmission Control

Protocol).

Сверху - неструктурированный поток байт, вниз - сегменты (осн.

единица TCP). Договор о макс. длине сегмента (не должен превышать

поле данных IP дейтаграммы).

Порты и установление TCP-соединений.

Установление логического соединения. Адрес каждой оконечной точки

включает IP адрес и номер порта TCP. Одна оконечная точка может

участвовать в нескольких соединениях.

2.3 Проблемы классической схемы

В середине 80-х годов Internet впервые столкнулся с

проблемой переполнения таблиц магистральных маршрутизаторов.

Решение, однако, было быстро найдено -- подсети устранили проблему

на несколько лет. Но уже в начале 90-х к проблеме большого

количества маршрутов прибавилась нехватка адресного пространства.

Ограничение в 4 миллиарда адресов, заложенное в протокол и

казавшееся недосягаемой величиной, стало весьма ощутимым. В качестве

решения проблемы были одновременно предложены два подхода -- один на

ближайшее будущее, другой комплексный и долгосрочный. Первое решение

-- это внедрение протокола бесклассовой маршрутизации (CIDR), к

которому позже присоединилась система NAT. Долгосрочное решение --

это протокол IP следующей версии. Он обозначается, как IPv6, или

IPng (Internet Protocol next generation). В этой реализации

протокола длина адреса увеличена до 16-ти байтов (128 бит!),

исключены некоторые элементы действующего протокола, которые

оказались неиспользуемыми. Новая версия обеспечит, как любят

указывать, плотность в 3 911 873 538 269 506 102 IP адресов на

квадратный метр поверхности Земли. Однако то, что и в 2000-м году

протокол все еще проходил стандартизацию, и то, что протокол CIDR

вместе с системой NAT оказались эффективным решением, заставляет

думать, что переход с IPv4 на IPng потребует очень много времени.

Появление этой технологии было вызвано резким увеличением объема

трафика в Internet и, как следствие, увеличением количества

маршрутов на магистральных маршрутизаторах. Так, если в 1994 году,

до развертывания CIDR, таблицы маршрутизаторов содержали до 70 000

маршрутов, то после внедрения их количество сократилось до 30 000.

На сентябрь 2002, количество маршрутов перевалило за отметку 110

000! Можете себе представить, сколько маршрутов нужно было бы

держать в таблицах сегодня, если бы не было CIDR! Что же

представляет собой эта технология? Она позволяет уйти от классовой

схемы адресации, эффективней использовать адресное пространство

протокола IP. Кроме того, CIDR позволяет агрегировать маршрутные

записи. Одной записью в таблице маршрутизатора описываются пути ко

многим сетям. Суть технологии CIDR состоит в том, что каждому

поставщику услуг Internet (или, для корпоративных сетей, какому-либо

структурно-территориальному подразделению) должен быть назначен

неразрывный диапазон IP-адресов. При этом вводится понятие

обобщенного сетевого префикса, определяющего общую часть всех

назначенных адресов. Соответственно, маршрутизация на магистральных

каналах может реализовываться на основе обобщенного сетевого

префикса. Результатом является агрегирование маршрутных записей,

уменьшение размера таблиц маршрутных записей и увеличение скорости

обработки пакетов. Допустим, центральный офис компании выделяет

одному своему региональному подразделению сети 172.16.0.0/16 и

172.17.0.0/16, а другому -- 172.18.0.0/16 и 172.19.0.0/16. У каждого

регионального подразделения есть свои областные филиалы и из

полученного адресного блока им выделяются подсети разных размеров.

Использование технологии бесклассовой маршрутизации позволяет при

помощи всего одной записи на маршрутизаторе второго подразделения

адресовать все сети и подсети первого подразделения. Для этого

указывается маршрут к сети 172.16.0.0 с обобщенным сетевым префиксом

15. Он должен указывать на маршрутизатор первого регионального

подразделения. По своей сути технология CIDR родственна VLSM. Только

если в случае с VLSM есть возможность рекурсивного деления на

подсети, невидимые извне, то CIDR позволяет рекурсивно адресовать

целые адресные блоки. Использование CIDR позволило разделить

Internet на адресные домены, внутри которых передается информация

исключительно о внутренних сетях. Вне домена используется только

общий префикс сетей. В результате многим сетям соответствует одна

маршрутная запись.

2.4 Примеры организации адресации в IP сетях

В конце статьи хотелось бы привести практические примеры по

затронутым в статье темам. Проектирование адресной схемы требует от

специалиста тщательной проработки многих факторов, учета возможного

роста и развития сети. Начнем с примера разбиения сети на подсети.

При любом планировании нужно знать, сколько подсетей необходимо

сегодня и может понадобиться завтра, сколько узлов находится в самой

большой подсети сегодня и сколько может быть в будущем. Кроме того,

следует разработать хотя бы схематическую топологию сети с указанием

всех маршрутизаторов и шлюзов. Хорошей практикой является

резервирование ресурсов на будущее. Так, если в самой большой

подсети находится 60 узлов, не следует выделять подсеть размерностью

в 26 - 2 (=62) узла! Не скупитесь, стоимость решения возможной

проблемы будет больше, нежели стоимость выделения в два раза

большего блока адресов. Однако не нужно впадать и в другую

крайность.

Пример 1

Организации выделен блок адресов 220.215.14.0/24. Разбить

блок на 4 подсети, наибольшая из которых насчитывает 50 узлов.

Учесть возможный рост в 10%. На первом этапе необходимое число

подсетей мы округляем в большую сторону к ближайшей степени числа 2.

Поскольку в данном примере число необходимых подсетей равно 4,

округлять не нужно. Определим количество бит, нужных для организации

4 подсетей. Для этого представим 4 в виде степени двойки: 4 = 22 .

Степень -- это и есть количество бит отводимых для номера подсети.

Так как сетевой префикс блока равен 24, то расширенный сетевой

префикс будет равен 24 + 2 = 26.

| |Сетевой префикс |Подсеть|Узел |

| | 0 | 8 |16 |24 25 | 31 |

| | | 10010000| 00001110 | |000000|

|220.215.14.0/26 |10010000 | | |0 0 | |

| |Расширенный сетевой префикс | |

Оставшиеся 32 - 26 = 6 бит будут использоваться для номера

узла. Проверим, сколько узлов можно адресовать 6-ю битами: 26 - 2 =

62 узла. Достаточно ли это для 10% роста? 10% от 50 узлов -- это 5

узлов, а 55 узлов меньше возможных 62-х. Следовательно, два бита для

номера подсети нас устраивают. Следующим этапом будет нахождение

подсетей. Для этого двоичное представление номера подсети, начиная с

нуля, подставляется в биты, отведенные для номера подсети.

Для проверки правильности наших вычислений, следует помнить

простое правило: десятичные номера подсетей должны быть кратными

номеру первой подсети. Из этого правила можно вывести и другое,

упрощающее расчет подсетей: достаточно вычислить адрес первой

подсети, а адреса последующих определяются произведением адреса

первой на соответствующий номер подсети. В нашем примере мы легко

могли установить адрес третьей подсети, просто умножив 64 * 3 = 192.

Как уже упоминалось, кроме адреса подсети, в котором все биты

узловой части равны нулю, есть еще один служебный адрес –

широковещательный. Особенность широковещательного адреса состоит в

том, что все биты узловой части равны единице. Рассчитаем

широковещательные адреса наших подсетей:

подсеть |

ШВА подсети 0 (00) | 11011100.11011100.00001110.00 111111 |

220.215.14.63/26

ШВА подсети 0 (01) | 11011100.11011100.00001110.01 111111 |

220.215.14.127/26

ШВА подсети 0 (10) | 11011100.11011100.00001110.10 111111 |

220.215.14.191/26

ШВА подсети 0 (11) | 11011100.11011100.00001110.11 111111 |

220.215.14.255/26

Расширенный сетевой префикс. Узловая часть = все 1

Легко заметить, что широковещательным адресом является

наибольший адрес подсети. Теперь, получив адреса подсетей и их

широковещательные адреса, мы можем построить таблицу используемых

адресов:

| № подсети| Наименьший адрес подсети| Наибольший адрес подсети |

| 0 | | - |

| |220.215.14.1 |220.215.14.62 |

| 1 | | - |

| |220.215.14.65 |220.215.14.126 |

| 2 | | - |

| |220.215.14.129 |220.215.14.190 |

| 3 | | - |

| |220.215.14.193 |220.215.14.254 |

Это и есть разбиение, удовлетворяющее условию.

Пример 2

В первом примере все подсети были одинакового размера -- по

6 разрядов. Часто удобнее иметь подсети разного размера. Допустим,

одна подсеть нужна для задания адресов двух маршрутизаторов,

связанных по схеме "точка-точка". В этом случае используется всего

лишь два адреса. Рассмотрим теперь случай, когда компании выделен

блок адресов 144.144.0.0/16. Нужно разбить адресное пространство на

три части, выделить адреса для двух пар маршрутизаторов и оставить

некоторый резерв. Разделим сеть 144.144.0.0/16 на четыре равных

части, выделив два бита для номера подсети:

|Октет |W |X |Y |Z | |

Внутри третьей подсети выделим две подсети размером в

четыре адреса:

| | |Подсеть № 3 | | | № узла |

Подсеть 0(0) |10010000 | 10010000 | 1 | 00000 | 00000 | 0

| 144.144.192.0/30 | |Подсеть 1(1) |10010000 | 10010000 | 1

|000000 | 00001 | 0 | 144.144.192.4/30 | | | | | |Номер

подсети | | | |

Полученные две сети будем использовать для адресации

интерфейсов маршрутизаторов. Оставшееся адресное пространство будет

резервом, из которого можно будет выделять адресные блоки по

потребности. Из оставшихся адресов можно, например, образовать 62

сети размерности класса С и еще несколько, размером поменьше.

ЗАКЛЮЧЕНИЕ

Установление соответствия между IP-адресом и аппаратным

адресом осуществляется протоколом разрешения адресов.

Существует два принципиально отличных подхода к разрешению

адресов: в сетях, поддерживающих широковещание, и в сетях, его не

поддерживающих.

Протокол АКР, работающий в сетях Ethernet, Token Ring,

FDDI, для трансляции IP-адреса в МАС-адрес выполняет

широковещательный ARP-запрос. Для ускорения процедуры преобразования

адресов протокол ARP кэширует полученные ответы в ARP-таблицах.

В сетях, в которых не поддерживаются широковещательные

сообщения, ARP-таблицы хранятся централизовано на выделенном ARP-

сервере. Таблицы составляются либо вручную администратором, либо

автоматически при включении каждый узел регистрирует в них свои

адреса. При необходимости установления соответствия между IP-адресом

и локальным адресом узел обращается к ARP-серверу с запросом и

автоматически получает ответ без участия администратора.

В стеке TCP/IP применяется доменная система символьных

имен, которая имеет иерархическую древовидную структуру, допускающую

использование в имени произвольного количества составных частей.

Совокупность имен, у которых несколько старших составных частей

совпадают, образуют домен имен. Доменные имена назначаются

централизованно, если сеть является частью Интернета, в противном

случае — локально.

Соответствие между доменными именами и IP-адресами может

устанавливаться как средствами локального хоста с использованием

файла hosts, так и с помощью централизованной службы DNS, основанной

на распределенной базе отображений «доменное имя — IP-адрес».

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1 Кульгин. М Технологии корпоративных сетей / Энциклопедия –

СПБ Издательство «Питер»,2000.-614с.:ил.

2 Адресная схема протокола IP .Крейг Хант, "Персональные

компьютеры в IP сетях ", "BHV-Kиев",с 384. 1997 г.

3 Олифер В.Г. Компьютерные сети. Адресация в IP : Учеб.

пособие для вузов / В.Г. Олифер, Н.А. Олифер. – 2-е изд. - СПб:

Издательство «Питер», 2003. – 495 с.: ил.

-----------------------

Изм

Лист

№ докум.

Подпись

Дата

КР.ИСиРТ.071900.ИС.ПЗ

Лист

Страницы: 1, 2, 3