Разбиение IP сети на подсети

⇐ ПредыдущаяСтр 5 из 11Следующая ⇒

В 1985 году была определена трехуровневая схема адресации (RFC 950). Необходимость перехода к такой системе адресации можно проиллюстрировать следующим примером. Организация получила сеть класса В, позволяющую адресовать 65000 хостов. Пока в сети работали относительно немного станций – она функционировала благополучно. Но с ростом числа активных хостов неизбежно рос и широковещательный трафик, поскольку этот тип пакетов активно используется в служебных целях многими протоколами. Это обстоятельство неизбежно вело к снижению эффективной производительности сети. Кроме того, управление несколькими десятками тысяч подключений из единого административного центра представляет собой очень трудную задачу. К этим проблем следует добавить и то, что любая организация развивается в направлении роста самостоятельности своих подразделений, что также неизбежно должно отражаться и в структуре сети. Возможность же структурирования сети организации за счет получения дополнительных номеров сетей была быстро исчерпана и резкая нехватка адресного пространства стала реальностью еще во второй половине 80-х годов. Кроме того, рост числа используемых сетей вел к росту таблиц маршрутизации магистральных (межсетевых) маршрутизаторов и, следовательно, к снижению их производительности.

Перечисленные проблемы в значительной степени связаны с проблемой масштабируемости сети, и они, в значительной степени, были разрешены посредством введения в иерархию адресации третьего уровня. Этот уровень, получивший название «уровень подсети», был выделен в пространстве адресов хоста

При этом поля адреса сети и адреса подсети в совокупности называют расширенным сетевым префиксом. В рассмотренном выше примере, выделение в пространстве адреса хоста 6 разрядов для адреса подсети позволяет организовать 62 подсети, содержащих до 1022 хостов каждая. Такое разбиение на подсети не требует согласования со специальным служебным органом Интернет, регулирующим распределение адресного пространства, Network Information Center.

Отрицательным следствием введения подсетей стало усложнение процедуры определения адреса хоста. Действительно, сетевые устройства используют старшие биты сетевого адреса для определения класса сети, после чего, в случае двухуровневой иерархии, легко находится граница между битами сетевого адреса и адреса хоста. В трехуровневой системе адресации этот прием работать не сможет. Для определения адреса подсети и адреса хоста потребовалось ввести сетевую маску – 32-битный адрес, в котором все биты, соответствующие битам расширенного сетевого префикса, установлены в 1, а соответствующие битам адреса хоста – в 0. Так, например, пусть необходимо в сети класса В 132.10 выделить подсеть, содержащую не более 100 хостов. Для адресации такого числа сетевых устройств достаточно располагать 7 битами (2⁷=128), которые и отводятся для адреса хоста; оставшиеся 9 бит отводятся для номера подсети (их можно организовать 2⁹ -2=510) а старшие 16 бит – это адрес сети.

Таким образом, маска подсети, в которой находятся хосты с адресами:

132.10.12.129, 132.10.12.130, …., 132.10.12.254

будет иметь вид

11111111 11111111 11111111 10000000 (255.255.255.128).

Если маршрутизатор получит пакет с адресом назначения

10000100 00001010 00001100 10110000 (132.10.12.176)

и выполнит по отношению к нему и сетевой маске операцию логического И, то результат будет содержать номер подсети. В данном случае получаем:

10000100 00001010 00001100 10000000,

что соответствует адресу подсети 132.10.12.128. Далее, по таблице маршрутизации будет найден следующий узел на пути к этой подсети, и пакет отправится на соответствующий интерфейс.

Необходимо заметить, что информация о маске подсети IP-пакетом не переносится (хост-источник о структуре сети, в которой находится получатель, ничего не знает). Передача этой информации является задачей протоколов маршрутизации, или она задается статически при конфигурировании маршрутизатора.

В стандартах, описывающих современные протоколы маршрутизации, часто делается ссылка на длину расширенного префикса сети, а не на маску подсети. В такой записи адрес устройства в рассмотренном выше примере имеет вид 132.10.12.176/25. В качестве примера нумерации подсетей в таблице приведено разбиение сети класса С на подсети. Указанное в таблице число хостов в каждой из подсетей на два меньше возможного числа адресов, поскольку адреса, в которых все биты поля адреса хоста установлены в единицу и в ноль, являются зарезервированными и используются как широковещательные для данной подсети. Так при подсетях, приведенных в таблице., адрес 193.10.1.0 является широковещательным лишь для подсети 193.10.1.0/24, а не для всех подсетей. Аналогично, адрес 193.10.1.255 является широковещательным только для подсети 193.10.1.224/27.

Введение подсетей, решив проблемы масштабирования адресного пространства, потребовало определенного усложнения протоколов маршрутизации, которые должны обрабатывать (и переносить) не только адрес сетевого устройства, но и его маску. В настоящее время все широко используемые протоколы маршрутизации (RIP-2, IS-IS, OSPF) переносят эту информацию.

IP маршрутизация

Каждый хост (станция, маршрутизатор) ведет свои маршрутные таблицы, которые и определяют порядок обработки IP-пакетов. Передача пакетов между конечными станциями, требует взаимодействия IP-модулей программного обеспечения этих станций и маршрутизаторов, связывающих сети, в которых они (станции) находятся. Рассмотрим, как обрабатывается пакет на этих сетевых устройствах.

Если в таблице маршрутизации станции-отправителя указано, что станция назначения является непосредственно присоединенной к той же ЛВС, то из таблицы физических адресов, которая ведется на каждой сетевой станции, извлекается физический адрес узла назначения, пакет инкансулируется в кадр канального протокола и передается к станции назначения. Если таблица маршрутизации станции-отправителя не содержит искомый сетевой адрес, то пакет отправляется по адресу маршрутизатора, который был указан при конфигурировании станции в качестве шлюза по умолчанию (default router, default gateway). Этот шлюз обязательно имеет физический интерфейс в той же ЛВС, что и станция-отправитель. При получении пакета маршрутизатор проверяет, не совпадает ли адрес назначения этого пакета с его собственным IP-адресом. Если это так, то пакет передается модулю протокола, указанного в поле «Протокол» заголовка пакета. В противном случае, маршрутизатор посредством своей таблицы определяет адрес следующего хоста, которому он должен передать этот пакет, и свой интерфейс, на который следует его направить.

Каждая строка в таблице маршрутизации содержит следующую информацию: IP-адрес сети (узла) назначения, IP-адрес следующего маршрутизатора, способного обеспечить передачу пакета в эту сеть (этому узлу), имя выходного интерфейса и некоторые флаги. Флаги содержат уточняющую информацию о каждой записи в таблице. Так например, флаг H определяет, является ли данная строка таблицы маршрутом к хосту ( Н =1), или к сети ( Н =0); флаг G уточняет, является ли она маршрутом к другому маршрутизатору ( G =1), или определяет путь к непосредственно подключенной станции ( G =0).

Поиск в таблице маршрутизации ведется следующим образом. Прежде всего, сканируется ее первый столбец с целью нахождения записи, точно соответствующей адресу назначения пакета. Если такая обнаруживается, то пакет отправляется по адресу, указанному в столбце «Следующий маршрутизатор». В противном случае, ведется поиск строки, содержащей адрес сети назначения. Если такой записи нет, то ищется строка, определяющая маршрут по умолчанию, т.е. маршрут к узлу с более полной информацией о траектории передачи этого пакета. Если не один из перечисленных вариантов не реализуем, то пакет уничтожается, а узлу-отправителю отправляется сообщение «Хост недостижим». Рассмотрим таблицы маршрутизации в сети.

Сеть содержит три подсети: 149.100.1.0/25 149.100.1.128/25, 149.100.2.0/24, которые объединены двумя маршрутизаторами М1 и М2. При этом маршрутизатор М2 является шлюзом в Интернет. Адреса интерфейсов маршрутизаторов показаны на рисунке. Предположим, что станция С6 имеет пакет с адресом назначения 149.100.1.159.

Первая строка таблицы определяет закольцовывающий интерфейс. Вторая строка описывает маршрут по умолчанию и флаг G уточняет, что узел 149.100.2.1 является маршрутизатором. Третья запись таблицы не имеет флага Н, следовательно, она определяет сеть; нет в ней и флага G и это говорит о том, что определяется маршрут к непосредственно подключенной сети и интерфейсом к ней является внешний интерфейс станции С6, имеющий адрес 149.100.2.21. Прежде всего С6 производит поиск адреса станции (или сети) назначения в своей таблице. Поскольку ни тот, ни другой в ней не присутствуют, то пакет будет отправлен в соответствии с маршрутом по умолчанию на маршрутизатор М2 с адресом 149.100.2.1 через интерфейс Eth0.

Выполнив поиск в этой таблице маршрутизатор М2 найдет, что наиболее полно согласуется с адресом назначения маршрут, определенный в строке 5 и отправит пакет к маршрутизатору М1 через интерфейс Eth1.

В ней представлен маршрут с адресом назначения точно соответствующим адресу назначения пакета. Поэтому последний передается на интерфейс Eth0 и доставляется станции С2 с IP-адресом 149.100.1.159.

Протокол ARP

Пусть хост Н1 хочет отослать пакет хосту Н3, MAC-адрес которого не известен. Хост Н1 генерирует так называемый ARP-запрос – специальный пакет, имеющий широковещательный адрес назначения. В теле этого запроса находится IP-адрес хоста, MAC-адрес которого необходимо узнать. Каждый хост сети получив такой пакет, сравнивает находящийся в нем IP-адрес со своим. Если совпадение обнаружено, то этот хост посылает запрашивающей станции ответный пакет (ARP-ответ), содержащий его физический адрес. На всех остальных станциях сети пакеты ARP-запросов уничтожаются. Для того, чтобы уменьшить количество ARP-запросов, каждое сетевое устройство имеет специальную буферную память, в которой хранится ARP-таблица. Последняя пополняется каждый раз, когда хост получает ARP-ответ.

В ARP-таблице могут быть как статические, так и динамические записи. Статические записи добавляются администратором и сохраняются в таблице до перезагрузки устройства. Кроме того, в таблице всегда содержится широковещательный адрес (%FFFFFFFFFFFF), который позволяет принимать широковещательные запросы. Динамические записи добавляются и удаляются автоматически. Каждая такая запись имеет потенциальное время жизни. После добавления записи в таблицу включается специальный таймер и, если в течении первых двух минут запись не используется, то она удаляется; в противном случае, время жизни такой записи составляет некое предустановленную величину (обычно 10 минут). Далее приведен фрагмент ARP-таблицы маршрутизатора.

Протокол ARP достаточно универсален, и его можно применять в сетях, использующих любые технологии на сетевом и канальном уровнях. Заголовок ARP-пакета имеет формат, отличный от IP-заголовка и поэтому не передается маршрутизаторами. На рисунке внизу представлен формат сообщения ARP.

В поле «Тип сети» для Ethernet указывается значение 1. Для других типов сетей его значения определяются соответствующим стандартом. Поля «Тип протокола», «Длина аппаратного адреса» и «Длина сетевого адреса» обеспечивают отмеченную выше универсальность формата ARP-пакета. В поле «Тип операции» для ARP-запроса указывается 1, для ARP-ответа – 2.

Устройство, отправляющее ARP-запрос, заполняет в этом пакете все поля, кроме искомого аппаратного адреса. Значение этого поля заполняется станцией, опознавшей свой IP-адрес, указанный в этом пакете в поле «IP-адрес получателя».

Протокол ICMP

Если маршрутизатор не может по каким-то причинам отправить пакет к узлу назначения, то он отсылает соответствующее сообщение узлу-отправителю. Эти функции выполняет протокол ICMP – Internet Control Message Protocol, описание которого приведено в документе RFC 792. Хотя его сообщения инкапсулируются в IP-пакет, протокол ICMP является протоколом сетевого уровня. Рассматриваемый протокол обеспечивает взаимодействие между программным обеспечением протокола IP, функционирующим на разных сетевых узлах. Однако, протокол не способен информировать промежуточные узлы о возникших ошибках, поскольку в IP-пакете нет поля для записи маршрута. Соответственно, когда пакет пришел на некий маршрутизатор и в ходе его обработки обнаружилась необходимость отправки сообщения ICMP, то единственным получателем такого сообщения будет узел – отправитель исходного пакета.

Протокол ICMP генерируют два вида сообщений: управляющие и сообщения об ошибках, но он не содержит никаких средств исправления ошибок; эта задача решается программным обеспечением узла-отправителя.

Сообщения ICMP начинаются тремя обязательными полями: «Тип», «Код» и «Контрольная сумма». Кроме этого, большинство сообщений включают в себя заголовок и первые 64 бита пакета, в котором была обнаружена ошибка, сообщение о которой несет данный пакет ICMP. Это сделано для более точной идентификации источника ошибки на узле-отправителе. Поле «Тип» определяет содержание сообщения и его формат. На слайде приведены некоторые значения этого поля.

Сообщения «Запрос эха» и «Ответ на эхо» являются одними из самых используемых (команда ping ). Поскольку эти сообщения передаются в IP-пакетах, то успешный прием ответа свидетельствует о работоспособности основных компонентов сетевой транспортной системы, т.е. успешной маршрутизации, работоспособности IP-модулей стека протоколов на станциях отправителе и получателе. На рисунке внизу слайда представлен их формат.

Поля «Идентификатор» и «Последовательный номер» используются отправителем для проверки соответствия между ответом и запросом. Поле «Необязательные данные» имеет переменную длину и содержит данные, которые необходимо вернуть отправителю.

Сообщение «Получатель недостижим» генерируется маршрутизатором, в ситуации, когда он не может доставить пакет по назначению. Это сообщение содержит поле «Код», которое уточняет причину невозможности доставки пакета. Некоторые из них представлены в таблице.

Сообщение «Изменение маршрута» ( Слайд 13 ) отправляется маршрутизатором отправителю, находящемуся с ним в одной физической сети, и свидетельствует об использовании последним неоптимального маршрута к узлу-назначения. Это сообщение содержит адрес маршрутизатора, использование которого является предпочтительным. Таким образом, начиная работу, отправитель может знать лишь один маршрут. В дальнейшем, его таблица маршрутизации, посредством этих сообщений ICMP, будет дополнена более точной информацией об «оптимальных» маршрутах. Весь этот механизм позволяет узлу отправителю минимизировать размер своей таблицы маршрутов.

Протокол UDP

Протокол UDP (User Datagram Protocol) описан в документе RFC 768. Он ориентирован на сервис без установления соединений и не обеспечивает надежную передачу сегментов между сетевыми приложениями. Это очень простой протокол, который развивает возможности IP-протокола лишь в части демультиплексирования потока пакетов по признаку принадлежности их определенному приложению и контроля целостности данных. Взаимодействие между прикладными процессами UDP реализует посредством механизма протокольных портов. Протокольный порт можно определить как абстрактную точку присутствия конкретной прикладной программы, выполняющейся на конкретном хосте. Когда рабочая станция получает пакет, в котором указан ее IP-адрес, она может направить его определенной программе, используя уникальный номер порта, назначенный этой программе в ходе выполнения процедуры установления соединения. Таким образом, в стеке протоколов TCP/IP порт является механизмом поддержания рабочей станцией одновременного выполнения нескольких прикладных процессов.

Каждый порт (прикладной процесс) идентифицируется целым положительным числом (номером порта). Номера портов приложения, выполняющегося на разных станциях, указываются в заголовке UDP-сегмента. Эта информация дополняется на сетевом уровне IP-адресами взаимодействующих станций. Благодаря этому, создается видимость непосредственного обмена данными между процессами.

Сегмент данных протокола UDP (иногда его называют пользовательской дейтограммой) состоит из двух частей: заголовка и области данных (см. слайд). Заголовок имеет четыре 16-битных поля, определяющих порт отправителя, порт получателя, длину сегмента и контрольную сумму.

Поле «Длина UDP-сегмента» содержит количество байтов в дейтограмме с учетом длины ее заголовка.

Вычисление контрольной суммы дейтограммы UDP является опциональным. При работе в надежных локальных сетях она не вычисляется и тогда это поле заполняется нулями. Процедура подсчета контрольной суммы содержит две особенности. Первая состоит в дополнении дейтограммы нулевыми битами до размера, кратного 16. Это делается только на время вычисления контрольной суммы, и незначащие нули не передаются. Второй особенностью является дополнение, на период подсчета контрольной суммы, заголовка сегмента псевдозаголовком. Его формат представлен на рисунке внизу.

Псевдозаголовок включается перед заголовком дейтограммы; он имеет длину 12 байтов; поле «Протокол» содержит тип протокола сетевого уровня (IP, ICMP); его значение, как и значения полей с IP-адресами, должны быть извлечены из заголовка IP пакета. Поле «Контрольная сумма» на время ее вычисления заполняется нулями.

Такое дополнение дейтограммы выполняется как на передающей, так и на приемной станции и оно служит гарантией, что если контрольные суммы совпали, то дейтограмма достигла нужной станции и нужного порта. Еще раз подчеркну, что псевдозаголовок и дополнение нулями не передаются.

Если контрольные сумма, вычисленная приемником, не совпала с контрольной суммой, указанной в дейтограмме, то UDP-сегмент уничтожается и никаких уведомлений передающей станции об этом не передается.

Протокол TCP

Протоколы TCP и IP являются «рабочими лошадками» Интернет. В этом разделе будут рассмотрены механизмы, посредством которых TCP обеспечивает надежный, ориентированный на установление соединений потоковый сервис в дейтограмной сети IP. В число этих механизмов входит вариант алгоритма ARQ с выборочным повторением и алгоритм управления перегрузками на базе индикации потерь сегментов. Подробно протокол описан в документах RFC 793 и RFC 1122.

Надежный потоковый сервис.

Задачей протокола TCP является организация и поддержание логического полнодуплексного соединения между двумя приложениями, выполняющимися на конечных станциях, соединенных ненадежной дейтограмной сетью, которое обеспечивает обмен упорядоченным потоком байтов и управление его интенсивностью. Дуплексность соединения позволяет вести передачу данных в одном из направлений и после того, как соединение противоположного направления было закрыто.

Аналогично UDP, каждый прикладной процесс для TCP-модуля представляется номером порта. Структура из пары переменных (порт, IP-адрес) называется сокетом. Соединение между отправителем и получателем однозначно определяется двумя сокетами. Для хранения всей информации, необходимой для установления и поддержания соединения, определена специальная структура данных – блок управления передачей (Transmission Control Block - TCB). В эту структуру, кроме двух сокетов, входят флаги безопасности и приоритета соединения, указатели буферов отправителя и получателя, указатели номеров очередного сегмента и сегмента повторной посылки, а также ряд других переменных.

ТСР не сохраняет границы сообщений и рассматривает данные, которые поступают ему от приложения, как поток байтов. Свои сегменты он формирует так, как считает необходимым, но с учетом свойств протокола сетевого уровня (сегмент должен полностью поместиться в IP-пакет). Таким образом, если приложение отсылает сообщение, размер которого составляет 1000 байтов, то на приемной стороне оно может быть представлено двумя частями по 500 байт, тремя частями по 300, 300 и 400 байт и.т.д.

⇐ Предыдущая 1 2 3 456 7 8 9 10 Следующая ⇒