olifer_v_g_olifer_n_a_kompyuternye_seti_principy_tehnologii / glava_18

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

К таким данным, во-первых, относятся адреса сети назначения (столбцы адреса назначения в аппаратном маршрутизаторе и маршрутизаторе Unix или столбец «Сетевой адрес» в маршрутизаторе ОС Windows 2000).

Вторым обязательным полем таблицы маршрутизации является адрес следующего маршрутизатора (столбцы «Шлюз» в аппаратном маршрутизаторе и маршрутизаторе Unix или столбец «Адрес шлюза» в маршрутизаторе ОС Windows 2000).

Таблица 18.5. Таблица программного маршрутизатора ОС Windows 2000

Таблица 18.6. Таблица маршрутизации аппаратного маршрутизатора

Таблица 18.7. Таблица маршрутизации Unix-маршрутизатора

Третий ключевой параметр — адрес порта, на который нужно направить пакет, в некоторых таблицах указывается прямо (столбец «Интерфейс» в таблице маршрутизатора ОС Windows 2000), а в некоторых — косвенно. Так, в таблице Unix-маршрутизатора вместо адреса порта задается его условное наименование — lе0 для порта с адресом 198.21.17.5, le1 для порта с адресом 213.34.12.3 и lo0 для внутреннего порта с адресом 127.0.0.1. В аппаратном маршрутизаторе поле, обозначающее выходной порт в какой-либо форме, вообще отсутствует. Это объясняется тем, что адрес выходного порта всегда можно косвенно определить по адресу следующего маршрутизатора. Например, определим по табл. 18.6 адрес выходного порта для сети 56.0.0.0. Из таблицы следует, что следующим маршрутизатором для этой сети будет маршрутизатор с адресом 213.34.12.4. Адрес следующего маршрутизатора должен принадлежать одной из непосредственно присоединенных к маршрутизатору сетей, и в данном случае это сеть 213.34.12.0. Маршрутизатор имеет порт, присоединенный к этой сети, и адрес этого порта 213.34.12.3 мы находим в столбце «Шлюз» второй строки таблицы маршрутизации, которая описывает непосредственно присоединенную сеть 213.34.12.0. Для непосредственно присоединенных сетей адресом следующего маршрутизатора всегда является адрес собственного порта маршрутизатора. Таким образом, для сети 56.0.0.0 адресом выходного порта является 213.34.12.3.

Стандартным решением сегодня является использование поля маски в каждой записи таблицы, как это сделано в таблицах маршрутизатора ОС Windows 2000 и аппаратного маршрутизатора (столбцы «Маска»). Обработка масок при принятии решения маршрутизаторами будет рассмотрена далее. Отсутствие поля маски говорит о том, что либо маршрутизатор рассчитан на работу только с тремя стандартными классами адресов, либо для всех записей используется одна и та же маска, что снижает гибкость маршрутизации.

Поскольку в таблице маршрутизации Unix-маршрутизатора каждая сеть назначения упомянута только один раз, а, значит, выбор маршрута отсутствует, то поле метрики является необязательным параметром. В остальных двух таблицах поле метрики используется только для указания на то, что сеть подключена непосредственно. Метрика 0 для аппаратного маршрутизатора или 1 для маршрутизатора ОС Windows 2000 говорит маршрутизатору, что эта сеть непосредственно подключена к его порту, а другое значение метрики соответствует удаленной сети. Выбор метрики для непосредственно подключенной сети (1 или 0) является произвольным, главное, чтобы метрика удаленной сети отсчитывалась с учетом этого выбранного начального значения. В Unix-маршрутизаторе используется поле признаков, где флаг G (Gateway — шлюз) отмечает удаленную сеть, а его отсутствие — непосредственно подключенную.

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

Однако существуют ситуации, когда маршрутизатор должен обязательно хранить значение метрики для записи о каждой удаленной сети. Эти ситуации возникают, когда записи в таблице маршрутизации являются результатом работы некоторых протоколов маршрутизации, например протокола RIP. В таких протоколах новая информация о какой-либо удаленной сети сравнивается с информацией, содержащейся в таблице в данный момент, и если значение новой метрики лучше текущей, то новая запись вытесняет имеющуюся. В таблице Unix-маршрутизатора поле метрики отсутствует, и это значит, что он не использует протокол RIP.

Флаги записей присутствуют только в таблице Unix-маршрутизатора.

• U — маршрут активен и работоспособен. Аналогичный смысл имеет поле статуса в аппаратном маршрутизаторе.

• Н — признак специфического маршрута к определенному хосту.

• G — означает, что маршрут пакета проходит через промежуточный маршрутизатор (шлюз). Отсутствие этого флага отмечает непосредственно подключенную сеть.

• D — означает, что маршрут получен из перенаправленного сообщения протокола ICMP. Этот признак может присутствовать только в таблице маршрутизации конечного узла. Признак означает, что конечный узел в какой-то предыдущей передаче пакета выбрал не самый рациональный следующий маршрутизатор на пути к данной сети, и этот маршрутизатор с помощью протокола ICMP сообщил конечному узлу, что все последующие пакеты к данной сети нужно отправлять через другой маршрутизатор.

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

В записях таблиц аппаратного маршрутизатора также имеется два справочных поля. Поле времени жизни записи (TTL) в данном случае никак не связано со временем жизни пакета. Здесь оно показывает время, в течение которого значение данной записи еще действительно. Поле источника говорит об источнике появления записи в таблице маршрутизации.

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

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

• Одним из источников записей в таблицу маршрутизации является программное обеспечение стека TCP/IP, которое при инициализации маршрутизатора автоматически заносит в таблицу несколько записей, в результате чего создается так называемая минимальная таблица маршрутизации. Программное обеспечение формирует записи о непосредственно подключенных сетях и маршрутах по умолчанию, информация о которых появляется в стеке при ручном конфигурировании интерфейсов компьютера или маршрутизатора. К таким записям в приведенных примерах относятся записи о сетях 213.34.12.0 и 198.21.17.0, а также запись о маршруте по умолчанию в Unix-маршрутизаторе и запись 0.0.0.0 в маршрутизаторе ОС Windows 2000. Программное обеспечение также автоматически заносит в таблицу маршрутизации записи об адресах особого назначения. В приведенных примерах таблица маршрутизатора ОС Windows 2000 содержит наиболее полный набор записей такого рода. Несколько записей в этой таблице связаны с особым адресом 127.0.0.0. Записи с адресом 224.0.0.0 требуются для обработки групповых адресов. Кроме того, в таблицу могут быть занесены адреса, предназначенные для обработки широковещательных рассылок (например, записи 8 и 11 содержат адрес отправки широковещательного сообщения в соответствующих подсетях, а последняя запись в таблице — адрес ограниченной широковещательной рассылки). Заметим, что в некоторых таблицах записи об особых адресах вообще отсутствуют.

• Еще одним источником записей в таблице является администратор, непосредственно формирующий записи с помощью некоторой системной утилиты, например программы route, имеющейся в операционных системах Unix и Windows 2000. В аппаратных маршрутизаторах также всегда имеется команда для ручного задания записей таблицы маршрутизации. Заданные вручную записи всегда являются статическими, то есть они не имеют срока жизни. Эти записи могут быть как постоянными, то есть сохраняющимися при перезагрузке маршрутизатора, так и временными, хранящимися в таблице только до выключения устройства. Часто администратор вручную заносит запись о маршруте по умолчанию. Таким же образом в таблицу маршрутизации может быть внесена запись о специфическом для узла маршруте.

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

Программные маршрутизаторы Windows 2000 и Unix не показывают источник появления той или иной записи в таблице, а аппаратный маршрутизатор использует для этой цели поле источника. В приведенном в табл. 18.6 примере первые две записи созданы программным обеспечением стека на основании данных о конфигурации портов маршрутизатора — это показывает признак «Подключена». Следующие две записи обозначены как статические — это означает, что их ввел вручную администратор. Последняя запись является следствием работы протокола RIP, поэтому в ее поле «TTL» имеется значение 160.

Пример IP-маршрутизации без масок

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

Итак, пусть пользователю компьютера cit.mgu.com, находящегося в сети Ethernet1, необходимо установить связь с FTP-сервером. Пользователю известно символьное имя сервера unix.mgu.com. Поэтому он набирает на клавиатуре команду обращения к FTP-серверу по имени:

> ftp unix.mgu.com

Эта команда включает обязательные три этапа.

1. Передача от клиента DNS-запроса для определения IP-адреса узла назначения.

2. Передача от сервера DNS-ответа.

3. Передача пакета от FTP-клиента к FTP-серверу.

Давайте рассмотрим каждый из них подробно.

Рис. 18.4. Пример IP-маршрутизации

Передача DNS-запроса

1. FTP-клиент передает запрос к работающей на этом же компьютере клиентской части протокола DNS, который в свою очередь формирует к DNS-серверу запрос, интерпретируемый примерно так: «Какой IP-адрес соответствует символьному имени unix.mgu.com?». Запрос упаковывается в UDP-дейтаграмму, затем в IP-пакет (рис. 18.5). В заголовке пакета в качестве адреса назначения указывается IP-адрес DNS-сервера — 203.21.4.6. Этот адрес известен программному обеспечению клиентского компьютера, так как он входит в число его конфигурационных параметров.

2. Прежде чем поместить IP-пакет в кадр Ethernet, необходимо выяснить, надо ли этот пакет маршрутизировать через составную сеть, или он адресован узлу, находящемуся в той же сети, что и отправитель. Для этого модуль IP сравнивает номера сетей в адресах отправителя и получателя, то есть 194.87.23.17 и 203.21.4.6. В результате сравнения выясняется, что пакет направляется в другую сеть, следовательно, его необходимо передать маршрутизатору. Поскольку в сети Ethernet1 имеется только один маршрутизатор (R1), все конечные узлы этой сети вместо полноценной таблицы маршрутизации пользуются адресом 194.87.23.1 этого маршрутизатора в качестве маршрутизатора по умолчанию.

Рис. 18.5. IP-пакет с DNS-запросом

3. Чтобы сеть Ethernet1 смогла доставить пакет маршрутизатору R1, этот пакет необходимо поместить в поле данных кадра Ethernet и снабдить его МАС-адресом. Эта проблема решается с помощью протокола ARP. Пусть, например, нужного адреса в ARP-таблице нет, тогда клиентский узел отправляет широковещательный ARP-запрос: «Какой МАС-адрес соответствует IP-адресу 194.87.23.1?» Этот запрос получают все узлы сети Ethernet1, но ответ приходит только от интерфейса 1 маршрутизатора R1: «Я имею IP-адрес 194.87.23.1 и мой МАС-адрес 008048ЕВ7Е60». После получения этой информации компьютер cit.mgu.com отправляет по локальной сети пакет, упакованный в кадр Ethernet и имеющий поля, показанные на рис. 18.6.

Рис. 18.6. Кадр Ethernet с DNS-запросом,

отправленный с клиентского компьютера

4. Кадр принимается интерфейсом 1 маршрутизатора R1. Протокол Ethernet извлекает из этого кадра IP-пакет и передает его протоколу IP. Протокол IP находит в заголовке пакета адрес назначения 203.21.4.6 и просматривает записи своей таблицы маршрутизации. Пусть маршрутизатор R1 имеет в своей таблице маршрутизации следующую запись:

203.21.4.0 135.12.0.11 135.12.0.1

Эта запись говорит о том, что пакеты для сети 203.21.4.0 нужно передавать маршрутизатору 135.12.0.11, находящемуся в сети, подключенной к интерфейсу 135.12.0.1 маршрутизатора R1. Маршрутизатор R1 просматривает параметры интерфейса 135.12.0.1 и находит, что к нему подключена сеть FDDI. Так как максимально возможная длина дейтаграммы, которую можно поместить в поле данных кадра FDDI, больше, чем в поле данных кадра Ethernet, фрагментация IP-пакета не требуется. Поэтому маршрутизатор R1 формирует кадр формата FDDI.

5. На этом этапе модуль IP маршрутизатора R1 должен определить МАС-адрес следующего маршрутизатора по известному IP-адресу 135.12.0.11. Для этого он обращается к протоколу ARP. Допустим, в этот раз в ARP-таблице присутствует запись о нужном адресе:

135.12.0.11 — 00E0F77F5A02

Теперь, зная МАС-адрес маршрутизатора R2 (00E0F77F5A02), маршрутизатор R1 отсылает в сеть FDDI кадр (рис. 18.7).

Рис. 18.7. Кадр Ethernet с DNS-запросом,

отправленный с маршрутизатора R1 маршрутизатору R2

6. Аналогично действует модуль IP на маршрутизаторе R2. Получив FDDI-кадр, он отбрасывает его заголовок, а из заголовка IP извлекает IP-адрес назначения и просматривает свою таблицу маршрутизации. Там он обнаруживает, что сеть назначения является непосредственно присоединенной к его второму интерфейсу. Поэтому он посылает ARP-запрос по сети Ethernet2: «Какой МАС-адрес соответствует IP-адресу конечного узла 203.21.4.6?» Получив ответ о МАС-адресе DNS-сервера — 00E0F7751231, маршрутизатор R2 отправляет в сеть Ethernet2 кадр (рис. 18.8).

Рис. 18.8. Кадр Ethernet с DNS-запросом,

отправленный с маршрутизатора R2

7. Сетевой адаптер DNS-сервера захватывает кадр Ethernet, обнаруживает совпадение МАС-адреса получателя, содержащегося в заголовке, со своим собственным адресом и направляет его модулю IP. После анализа полей заголовка IP из пакета извлекаются данные вышележащих протоколов. DNS-запрос передается программному модулю DNS-сервера. DNS-сервер просматривает свои таблицы, возможно, обращается к другим DNS-серверам и в результате формирует ответ, смысл которого состоит в следующем: символьному имени unix.mgu.com соответствует IP-адрес 142.06.13.14.

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

Передача DNS-ответа

1. Стек TCP/IP, установленный на DNS-сервере, упаковывает DNS-ответ в UDP-дейтаграмму, затем — в IP-пакет (IP-адрес получателя ему известен из DNS-запроса). Протокол IP определяет, что пакет необходимо маршрутизировать.

2. Протокол IP просматривает таблицу маршрутизации, в результате определяет IP-адрес следующего маршрутизатора IP₂₂ — 203.21.4.3.

3. Протокол ARP определяет МАС-адрес интерфейса маршрутизатора — 00E0F734F5C0.

4. IP-пакет размещается в поле данных кадра Ethernet и отправляется в сеть Ethernet2.

5. Маршрутизатор R2 получает кадр, выполняет шаги 2 и 3 и отправляет FDDI-кадр маршрутизатору R1.

6. Маршрутизатор R1 определяет по таблице маршрутизации, что поступивший пакет адресован в сеть, непосредственно подсоединенную к его интерфейсу. Поэтому IP обращается к протоколу ARP, чтобы получить МАС-адрес узла назначения, а не маршрутизатора.

7. В сеть Ethernet1 отправляется адресованный FTP-клиенту кадр (рис. 18.9).

Рис. 18.9. Кадр Ethernet с DNS-запросом,

отправленный с маршрутизатора R2

8. FTP-клиент извлекает из кадра DNS-ответ, теперь он может продолжить выполнение команды, в которой адрес FTP-сервера указан в виде IP-адреса:

> ftp 142.06.13.14

Передача пакета от FTP-клиента к FTP-серверу

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

Маршрутизация с использованием масок

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

Алгоритм маршрутизации усложняется, когда в систему адресации узлов вносятся дополнительные элементы — маски. В чем же причины отказа от хорошо себя зарекомендовавшего в течение многих лет метода адресации, основанного на классах? Основная из них — потребность в структуризации сетей в условиях дефицита нераспределенных номеров сетей.

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

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

Допустим, администратор получил в свое распоряжение адрес класса В: 129.44.0.0. Он может организовать сеть с большим числом узлов, номера которых брать из диапазона 0.0.0.1 — 0.0.255.254. Всего получается 2¹⁶ - 2 адреса (с учетом того, что адреса из одних нулей и одних единиц имеют специальное назначение и не годятся для адресации узлов). Однако ему не нужна одна большая неструктурированная сеть, производственная необходимость диктует администратору другое решение, в соответствии с которым сеть должна быть разделена на три отдельных подсети, при этом трафик в каждой подсети должен быть надежно локализован. Это позволит легче диагностировать сеть и проводить в каждой из подсетей особую политику безопасности. (Заметим, что разделение большой сети с помощью масок имеет еще одно преимущество — оно позволяет скрыть внутреннюю структуру сети предприятия от внешнего наблюдения и тем самым повысить ее безопасность.)

На рис. 18.10 показано разделение всего полученного администратором адресного диапазона на 4 равные части — каждая по 2¹⁴ адресов. При этом число разрядов, доступное для нумерации узлов, уменьшилось на два бита, а префикс (номер) каждой из четырех сетей стал длиннее на два бита. Следовательно, каждый из четырех диапазонов можно записать в виде IP-адреса с маской, состоящей из 18 единиц, или в десятичной нотации — 255.255.192.0.

129.44.0.0/18 (10000001 00101100 00000000 00000000)

129.44.64.0/18 (10000001 00101100 01000000 00000000)

129.44.128.0/18 (10000001 00101100 10000000 00000000)

129.44.192.0/18 (10000001 00101100 11000000 00000000)

Из приведенных записей видно, что администратор получает возможность использовать для нумерации подсетей два дополнительных бита (выделенных жирным шрифтом). Именно это позволяет ему сделать из одной централизованно выделенной сети четыре, в данном примере это 129.44.0.0/18, 129.44.64.0/18, 129.44.128.0/18, 129.44.192.0/18.

Рис. 18.10. Разделение адресного пространства сети класса В 129.44.0.0

на четыре равные части

Примечание. Некоторые программные и аппаратные маршрутизаторы, следуя устаревшим рекомендациям RFC 950, не поддерживают номера подсетей, которые состоят либо только из одних нулей, либо только из одних единиц. Например, для такого типа оборудования номер сети 129.44.0.0 с маской 255.255.192.0, использованной в нашем примере, окажется недопустимым, поскольку в этом случае разряды в поле номера подсети имеют значение 00. По аналогичным соображениям недопустимым может оказаться номер сети 129.44.192.0 с тем же значением маски. Здесь номер подсети состоит только из единиц. Однако современные маршрутизаторы, поддерживающие рекомендации RFC 1878, свободны от этих ограничений.

Пример сети, построенной путем деления на 4 сети равного размера, показан на рис. 18.11. Весь трафик во внутреннюю сеть 129.44.0.0, направляемый из внешней сети, поступает через маршрутизатор R1. В целях структуризации информационных потоков во внутренней сети установлен дополнительный маршрутизатор R2. Каждая из вновь образованных сетей 129.44.0.0/18, 129.44.64.0/18, 129.44.128.0/18 и 129.44.192.0/18 подключена к соответственно сконфигурированным портам внутреннего маршрутизатора R2.

Примечание. В одной из этих сетей (129.44.192.0/18), выделенной для создания соединения между внешним и внутренним маршрутизаторами, для адресации узлов были использованы всего два адреса — 129.44.192.1 (порт маршрутизатора R2) и 129.44.192.2 (порт маршрутизатора R1). Огромное число узлов в этой подсети не используются. Такой пример выбран исключительно в учебных целях, чтобы показать неэффективность сетей равного размера.

Рис. 18.11. Маршрутизация с использованием масок одинаковой длины

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

Первые четыре записи в таблице соответствуют внутренним подсетям, непосредственно подключенным к портам маршрутизатора R2.

Запись 0.0.0.0 с маской 0.0.0.0 соответствует маршруту по умолчанию.

Последняя запись определяет специфический маршрут к узлу 129.44.128.15. В тех строках таблицы, в которых в качестве адреса назначения указан полный IP-адрес узла, маска имеет значение 255.255.255.255. В отличие от всех других узлов сети 129.44.128.0, к которым пакеты поступают с интерфейса 129.44.128.5 маршрутизатора R2, к данному узлу они будит приходить через маршрутизатор R3.

Таблица 18.8. Таблица маршрутизатора R2 в сети с масками одинаковой длины

Просмотр таблиц маршрутизации с учетом масок

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

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

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

3. Вторая фаза выполняется только в том случае, если во время первой фазы не произошло совпадения адресов. Она состоит в поиске неспецифического маршрута, общего для группы узлов, к которой относится и пакет с адресом IP_D. Для этого IP заново просматривает таблицу маршрутизации, причем с каждой записью производятся следующие действия:

• маска (обозначим ее М), содержащаяся в данной записи, «накладывается» на IP-адрес узла назначения IP_D, извлеченный из пакета: IP_D AND M;

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

• если происходит совпадение, протокол IP соответствующим образом отмечает эту строку;

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