Перекрытие адресных пространств

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

Рассмотрим пример использования масок для организации перекрывающихся адресных пространств.

Пусть на некотором предприятии было принято решение обратиться к поставщику услуг для получения пула адресов, достаточного для создания сети, структура, которой показана на рис. 16.15. Сеть клиента включает три подсети. Две из них — это надежно защищенные от внешних атак внутренние сети отделов: сеть Ethernet на 600 пользователей и сеть Token Ring на 200 пользователей. Предприятие также предусматривает отдельную, открытую для доступа извне сеть на 10 узлов, главное назначение которой — предоставление информации в режиме открытого доступа для потенциальных клиентов. Такого рода участки корпо­ративной сети, в которых располагаются веб-серверы, FTP-серверы и другие источники публичной информации, называют демилитаризованной зоной (Demilitarized Zone, DMZ). Еще одна сеть на два узла потребуется для связи с поставщиком услуг, то есть общее число адресов, требуемых для адресации сетевых интерфейсов, составляет 812. Кроме того, не­обходимо, чтобы пул доступных адресов включал для каждой из сетей широковещательные адреса, состоящие только из единиц, а также адреса, состоящие только из нулей. Учитывая также, что в любой сети адреса всех узлов должны иметь одинаковые префиксы, становится очевидным, что минимальное количество адресов, необходимое клиенту для построения задуманной сети, может значительно отличаться от значения 812, полученного простым суммированием.

В данном примере поставщик услуг решает выделить клиенту непрерывный пул из 1024 адресов. Значение 1024 выбрано как наиболее близкое к требуемому количеству адресов, равному степени двойки (2¹⁰ = 1024). Поставщик услуг выполняет поиск области такого размера в имеющемся у него адресном пространстве — 131.57.0.0/16, часть которого, как показано на рис. 16.16, уже распределена. Обозначим распределенные участки и владею­щих ими клиентов через S1, S2 и S3. Поставщик услуг находит среди нераспределенных еще адресов непрерывный участок размером 1024 адреса, начальный адрес которого кратен размеру данного участка. Таким образом, наш клиент получает пул адресов 131.57.8.0/22, обозначенный на рисунке через S.

Рис. 16.15. Сети поставщика услуг и клиента

 

 

Рис. 16.16. Адресное пространство поставщика услуг

Далее начинается самый сложный этап — распределение полученного от поставщика услуг адресного пула S между четырьмя сетями клиента. Прежде всего, администратор решил назначить для самой большой сети (Ethernet на 600 узлов) весь пул адресов 131.57.8.0/22, полученный от поставщика услуг (рис. 16.17). Номер, назначенный для этой сети, со­впадает с номером сети, полученным от поставщика услуг. А как же быть с оставшимися тремя сетями? Администратор учел, что для сети Ethernet требуется только 600 адресов, а из оставшихся 624 «выкроил» сеть Token Ring 131.57.9.0/24 на 250 адресов. Воспользо­вавшись тем, что для Token Ring требуется только 200 адресов, он «вырезал» из нее два участка: для сети DMZ 131.57.9.16/28 на 16 адресов и для связывающей сети 131.57.9.32/30 на 4 адреса. В результате все сети клиента получили достаточное (а иногда и с избытком) количество адресов.

Рис. 16.17. Планирование адресного пространства для сетей клиента

 

Следующий этап — это конфигурирование сетевых интерфейсов конечных узлов и марш­рутизаторов. Каждому интерфейсу сообщается его IP-адрес и соответствующая маска. На рис. 16.18. показана сконфигурированная сеть клиента.

После конфигурирования сетевых интерфейсов должны быть созданы таблицы маршрути­зации маршрутизаторов R1 и R2 клиента. Они могут быть сгенерированы автоматически или с участием администратора. Таблица маршрутизации маршрутизатора R2 соответ­ствует табл. 16.11.

Таблица 16.11. Таблица-маршрутизации маршрутизатора R2

Адрес назначения	Маска	Адрес следующего маршрутизатора	Адрес выходного интерфейса	Расстояние
131.57.8.0	255.255.252.0	131.57.8.2	131.57.8.2	Подключена
131.57.9.0	255.255.255.0	131.57.9.1	131.57.9.1	Подключена
131.57.9.16	255.255.255.240	131.57.8.1	131.57.8.2
131.57.9.32	255.255.255.252	131.57.8.1	131.57.8.2

 

Рис. 16.18. Сконфигурированная сеть клиента

 

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

Пусть, например, на маршрутизатор R2 поступает пакет с адресом назначения 131.57.9.29. В результате просмотра таблицы получаем следующие результаты для каждой строки:

(131.57.9.29) AND (255.255.252.0) = 131.57.8.0 - совпадение;

(131.57.9.29) AND (255.255.255.0) = 131.57.9.0 - совпадение;

(131.57.9.29) AND (255.255.255.240) = 131.57.9.16 - совпадение;

(131.57.9.29) AND (255.255.255.252) = 131.57.9.28 — нет совпадения.

Поскольку при наличии нескольких совпадений выбирается маршрут из той строки, в которой совпадение адреса назначения с адресом из пакета имеет наибольшую длину, определено, что пакет с адресом 131.57.9.29 направляется в сеть DMZ.

CIDR

За последние несколько лет в Интернете многое изменилось: резко возросло число узлов и сетей, повысилась интенсивность трафика, изменился характер передаваемых данных. Из-за несовершенства протоколов маршрутизации обмен сообщениями об обновлении таблиц стал приводить к сбоям магистральных маршрутизаторов, происходящим из-за перегрузок при обработке большого объема служебной информации. Так, сегодня табли­цы магистральных маршрутизаторов в Интернете могут содержать до нескольких сотен и даже тысяч маршрутов.

На решение этой проблемы направлена, в частности, и технология бесклассовой междоменной маршрутизации (Classless Inter-Domain Routine. CIDR)

Суть технологии CIDR заключается в следующем. Каждому поставщику услуг Интернета назна­чается непрерывный диапазон IP-адресов. При Таком подходе все адреса каждого поставщика услуг имеют общую старшую часть — префикс, поэтому маршрутизация на магистралях Интер­нета может осуществляться на основе префиксов,_:а не полных адресов сетей. А это значит, что вместо множества записей по числу сетей будет достаточно поместить одну запись сразу для всех сетей, имеющих общий префикс. Такое агрегирование адресов позволит уменьшить объем таблиц в маршрутизаторах всех уровней, а следовательно, ускорить работу маршрутизаторов и повысить пропускную способность Интернета.

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

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

Вернемся к рис. 16.16, на котором показано адресное пространство поставщика услуг с участками S1, S2, S3 и S, переданными в пользование четырем клиентам. Этот пример также иллюстрирует рис. 16.19. В результате агрегирования сетей клиентов в табл. 16.12 маршрутизатора R_ISP поставщика услуг для каждого клиента будет выделено по одной строке независимо от количества подсетей, организованных ими в своих сетях. Так, вместо четырех маршрутов к четырем сетям клиента S в таблице задан только один общий для всех них маршрут (выделенный жирным шрифтом).

Таблица 16.12. Таблица маршрутизатора R_isp поставщика услуг

Адрес назначения	Маска	Следующий маршрутизатор	Номер выходного интерфейса	Расстояние
131.57 0.0 (S1)	255.255.255.0	R3		Подключена
131.57 2.0 (S2)	255.255.255.0	R3
131.57 4.0 (S3)	255.255.254.0	R1
131.57.8.0 (S)	255.255.252.0	R1		Подключена
Маршрут по умолчанию	0.0.0.0	Rexternal		-

 

Итак, внедрение технологии CIDR позволяет решить две основные задачи.

§ Более экономное расходование адресного пространства. Благодаря технологии CIDR поставщики услуг получают возможность «нарезать» блоки из выделенного им адрес­ного пространства в точном соответствии с требованиями каждого клиента, при этом у клиента остается пространство для маневра на случай будущего роста.

§ Уменьшение числа записей в таблицах маршрутизации за счет объединения маршру­тов — одна запись в таблице маршрутизации может представлять большое количество сетей. Если все поставщики услуг Интернета начнут придерживаться стратегии CIDR, то особенно заметный выигрыш будет достигаться в магистральных маршрутизаторах.

Рис. 16.19. Объединение подсетей

 

Необходимым условием эффективного использования технологии CIDR является локализация адресов, то есть назначение адресов, имеющих совпадающие префиксы, сетям, располагаю­щимся территориально по соседству. Только в таком случае трафик может быть агрегирован.

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

Технология CIDR уже успешно используется в текущей версии протокола IP (IPv4) и под­держивается такими протоколами маршрутизации, как OSPF, RIP-2, BGP4 (в основном на магистральных маршрутизаторах Интернета). Особенности применения технологии CIDR в новой версии протокола IP (IPv6) будут рассмотрены в главе 18.

Фрагментация IP-пакетов

Важной особенностью протокола IP, отличающей его от других сетевых протоколов (на­пример, от сетевого протокола IPX, который какое-то время назад конкурировал с IP), является его способность выполнять динамическую фрагментацию пакетов при передаче их между сетями с различными максимально допустимыми значениями длины поля данных кадров (Maximum Transmission Unit, MTU). Значения MTU зависят как от протокола, так и от настройки сетевых интерфейсов.

Прежде всего отметим разницу между фрагментацией сообщений в узле-отправителе и динамической фрагментацией сообщений в транзитных узлах сети — маршрутизаторах.

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

В стеке TCP/IP эту задачу решает протокол TCP, который разбивает поток байтов, передаваемый ему с прикладного уровня, на сегменты нужного размера, например, по 1460 байт, если на нижнем уровне данной сети работает протокол Ethernet. Протокол IP в узле-отправителе, как правило, не использует свои возможности по фрагментации пакетов. А вот на транзитном узле — маршрутизаторе, когда пакет необходимо передать из сети с большим значением MTU в сеть с меньшим значением MTU, способности протокола IP выполнять фрагментацию становятся востребованными. Пакеты-фрагменты, путешествуя по сети, могут вторично подвергнуться фрагментации на каком-либо из промежуточных маршрутизаторов.

Параметры фрагментации

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

§ Идентификатор пакета используется для распознавания пакетов, образовавшихся пу­тем деления на части (фрагментации) исходного пакета. Все части (фрагменты) одного пакета должны иметь одинаковое значение этого поля. Модуль IP, отправляющий пакет, устанавливает в поле идентификатора значение, которое должно быть уникальным для данной пары отправителя и получателя в течение всего времени, пока данный пакет (или любой его фрагмент) может существовать в составной IP-сети.

§ Поле времени жизни (Time То Live, TTL) занимает один байт и определяет предельный срок, в течение которого пакет может перемещаться по сети. Время жизни пакета изме­ряется в секундах и задается источником (отправителем). Как уже отмечалось в начале этой главы, по истечении каждой секунды пребывания на каждом из маршрутизаторов, через которые проходит пакет во время своего «путешествия» по сети, из его текущего времени жизни вычитается единица; единица вычитается и в том случае, если время пребывания было меньше секунды. Поскольку современные маршрутизаторы редко обрабатывают пакет дольше, чем за одну секунду, то время жизни можно интерпретировать как максимальное число транзитных узлов, которые разрешено пройти пакету. Если значение поля времени жизни становится нулевым до того, как пакет достигает получателя, пакет уничтожается. При сборке фрагментов хост-получатель использует значение TTL как крайний срок ожидания недостающих фрагментов.

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

§ Установленный в единицу однобитный флаг MF (More Fragments — больше фраг­ментов) говорит о том, что данный пакет является промежуточным (не последним) фрагментом. Модуль IP, отправляющий нефрагментированный пакет, устанавливает бит MF в нуль.

§ Флаг DF (Do not Fragment — не фрагментировать), установленный в единицу, запре­щает маршрутизатору фрагментировать данный пакет. Если помеченный таким образом пакет не может достигнуть получателя без фрагментации, то модуль IP его уничтожает, а узлу-отправителю посылается диагностическое сообщение.

ПРИМЕЧАНИЕ

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

Механизм фрагментации

Рассмотрим механизм фрагментации на примере составной сети, показанной на рис. 16.20.

В одной из подсетей (Frame Relay) значение MTU равно 4080, в другой (Ethernet) — 1492. Хост, принадлежащий сети Frame Relay, передает данные хосту в сети Ethernet. На обоих хостах, а также на маршрутизаторе, связывающем эти подсети, установлен стек протоколов TCP/IP.

Транспортному уровню хоста-отправителя известно значение MTU нижележащей тех­нологии (4080). На основании этого модуль TCP и «нарезает» свои сегменты размером 4000 байт и передает вниз протоколу IP, который помещает сегменты в поле данных IP- пакетов и генерирует для них заголовки. Обратим особое внимание на заполнение тех полей заголовка, которые прямо связаны с фрагментацией:

§ пакету присваивается уникальный идентификатор, например 12456;

§ поскольку пакет пока еще не был фрагментирован, в поле смещения помещается зна­чение 0;

§ признак MF также обнуляется, это показывает, что пакет одновременно является и сво­им последним фрагментом;

§ признак DF устанавливается в 1, это означает, что данный пакет можно фрагментировать.

Общая величина IP-пакета составляет 4000 плюс 20 (размер заголовка IP), то есть 4020 байт, что умещается в поле данных кадра Frame Relay, которое в данном примере равно 4080. Далее модуль IP хоста-отправителя передает этот кадр своему сетевому интерфейсу Frame Relay, который отправляет кадры следующему маршрутизатору.

Рис. 16.20. Фрагментация

 

Модуль IP маршрутизатора по сетевому адресу прибывшего IP-пакета определяет, что пакет нужно передать в сеть Ethernet. Однако она имеет значение MTU, равное 1492, что значительно меньше размера поступившего на входной интерфейс пакета. Следова­тельно, IP-пакет необходимо фрагментировать. Модуль IP выбирает размер поля данных фрагмента равным 1000, так что из одного большого IP-пакета получается 4 маленьких пакета-фрагмента. Для каждого фрагмента и его заголовка IP в маршрутизаторе создается отдельный буфер (на рисунке фрагменты и соответствующие им буферы пронумерованы от 1 до 4). Протокол IP копирует в эти буферы содержимое некоторых полей заголовка IP исходного пакета, создавая тем самым «заготовки» заголовков IP всех новых пакетов- фрагментов. Одни параметры заголовка IP копируются в заголовки всех фрагментов, другие — лишь в заголовок первого фрагмента.

В процессе фрагментации могут измениться значения некоторых полей заголовков IP в пакетах-фрагментах по сравнению с заголовком IP исходного пакета. Так, каждый фраг­мент имеет собственные значения контрольной суммы заголовка, смещения фрагмента и общей длины пакета. Во всех пакетах, кроме последнего, флаг MF устанавливается в еди­ницу, а в последнем фрагменте — в нуль. Полученные пакеты-фрагменты имеют длину 1020 байт (с учетом заголовка IP), поэтому они свободно помещаются в поле данных кадров Ethernet.

На рисунке показаны разные стадии перемещения фрагментов по сети. Фрагмент 2 уже достиг хоста-получателя и помещен в приемный буфер. Фрагмент 1 еще перемещается по сети Ethernet, остальные фрагменты находятся в буферах маршрутизатора.

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

ПРИМЕЧАНИЕ

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

На хосте назначения для каждого фрагментированного пакета отводится отдельный буфер. В этот буфер принимающий протокол IP помещает IP-фрагменты, у которых совпадают IP-адреса отправителя и получателя, а также значения в полях идентификатора (в нашем примере — 12456). Все эти признаки говорят модулю IP, что данные пакеты являются фраг­ментами одного исходного пакета. Сборка заключается в помещении данных из каждого фрагмента в позицию, определенную смещением, указанным в заголовке фрагмента.

Когда первый фрагмент исходного пакета приходит на хост-получатель, этот хост запу­скает таймер, который определяет максимальное время ожидания прибытия остальных фрагментов данного пакета. В различных реализациях IP применяются разные правила выбора максимального времени ожидания. В частности, таймер может быть установлен на фиксированный период времени (от 60 до 120 секунд), рекомендуемый RFC. Как пра­вило, этот интервал достаточен для доставки пакета от отправителя получателю. В других реализациях максимальное время ожидания определяется с помощью адаптивных алго­ритмов измерения и статистической обработки временных параметров сети, позволяющих оценивать ожидаемое время прибытия фрагментов. Наконец, тайм-аут может быть выбран на базе значений TTL прибывающих фрагментов. Последний подход основан на том, что нет смысла ожидать, пока прибудут другие фрагменты пакета, если время жизни одного из прибывших фрагментов уже истекло.

ПРИМЕЧАНИЕ

Если хотя бы один фрагмент пакета не успеет прийти на хост назначения к моменту истечения тай­мера, то никаких действий по дублированию отсутствующего фрагмента не предпринимается, а все полученные к этому времени фрагменты пакета отбрасываются! Хосту, пославшему исходный пакет, направляется ICMP-сообщение об ошибке. Такому поведению протокола IP вполне соответствует его кредо «с максимальными усилиями» — стараться по возможности, но никаких гарантий не давать.

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

Выводы

Протокол IP решает задачу доставки сообщений между узлами составной сети. Поскольку он явля­ется дейтаграммным, никаких гарантий надежной доставки сообщений не дается.

Максимальная длина IP-пакета составляет 65 535 байт. Заголовок обычно имеет длину 20 байт и со­держит информацию о сетевых адресах отправителя и получателя, параметры фрагментации, время жизни пакета, контрольную сумму и некоторые другие параметры.

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

Записи в таблицу маршрутизации могут поступать из разных источников. Во-первых, в результате конфигурирования программное обеспечение стека TCP/IP заносит в таблицу записи о непосред­ственно подключенных сетях и маршрутизаторах по умолчанию, а также записи об особых адресах. Во-вторых, администратор вручную заносит записи о специфических маршрутах и о маршруте по умолчанию. В-третьих, протоколы маршрутизации автоматически заносят в таблицу динамические записи об имеющихся маршрутах.

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

Важной особенностью протокола IP, отличающей его от других сетевых протоколов, например от сетевого протокола IPX, является его способность выполнять динамическую фрагментацию пакетов при передаче их между сетями с различными максимально допустимыми значениями длины поля данных кадров (MTU).

Вопросы и задания

1. Сравните таблицу моста или коммутатора с таблицей маршрутизатора. Каким образом формируются эти таблицы? Какую информацию содержат? От чего зависит их объем?

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

3. Может ли один сетевой интерфейс иметь одновременно несколько IPv6-адресов разных типов: уникальный адрес, адрес произвольной рассылки, групповой адрес?

4. Рассмотрим маршрутизатор на магистрали Интернета. Какие записи содержатся в поле адреса назначения его таблицы маршрутизации? Варианты ответов:

а) номера всех сетей Интернета;

б) номера некоторых сетей Интернета;

в) номера некоторых сетей и адреса некоторых конечных узлов Интернета;

г) номера сетей, подсоединенных к интерфейсам данного маршрутизатора.

5. Сколько записей о маршрутах по умолчанию может включать таблица маршрутизации?

6. Приведите примеры, когда может возникнуть необходимость в использовании специфи­ческих маршрутов?

7. Передается ли в IP-пакете маска в тех случаях, когда маршрутизация реализуется с ис­пользованием масок?

8. Какие преимущества дает технология CIDR? Что мешает ее широкому внедрению?

9. Пусть префикс непрерывного пула IP-адресов составляет 15 двоичных разрядов. Сколь­ко адресов, входит в этот пул? Варианты ответов:

10. а) 2¹⁵; 6)2¹⁷; _в) 2¹⁵ - 2; г) 15².

11. Почему в записи о маршруте по умолчанию в качестве адреса сети назначения часто указывается 0.0.0.0 с маской 0.0.0.0?

12. Какие элементы сети могут выполнять фрагментацию? Варианты ответов:

а) только компьютеры;

б) только маршрутизаторы;

в) компьютеры, маршрутизаторы, мосты, коммутаторы;

г) компьютеры и маршрутизаторы.

13. Что произойдет, если при передаче пакета он был фрагментирован и один из фрагмен­тов не дошел до узла назначения после истечения тайм-аута? Варианты ответов:

а) модуль IP получателя сообщит о неполучении одного фрагмента, а IP-модуль узла- отправителя повторит передачу недошедшего фрагмента;

б) модуль IP получателя сообщит о неполучении одного фрагмента, а IP-модуль узла- отправителя повторит передачу всего пакета, в состав которого входил недошедший фрагмент;

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

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

15. В разделе «Перекрытие адресных пространств» этой главы приведен пример того, как администратор планирует сеть своего предприятия. Решите ту же задачу по планированию сети, но для случая, когда для сети Ethernet требуется 300 адресов, для сети Token Ring — 30, для DMZ — 20 и для соединительной сети — 8. Какой пул адресов необходимо получить у поставщика услуг на этот раз? (Для определенности будем считать, что поставщик услуг выделит непрерывный пул адресов.) Как администратор распределит адреса между своими четырьмя сетями? Как будут выглядеть таблицы маршрутизации R1 и R2?