Главная страница

Учебник для вузов в. Олифер Н. Олифер Компьютерные Принципы, технологии, протоколы


Скачать 22.28 Mb.
НазваниеУчебник для вузов в. Олифер Н. Олифер Компьютерные Принципы, технологии, протоколы
АнкорOlifer_V_G__Olifer_N_A_-_Kompyuternye_seti_-_2010.pdf
Дата12.03.2017
Размер22.28 Mb.
Формат файлаpdf
Имя файлаOlifer_V_G__Olifer_N_A_-_Kompyuternye_seti_-_2010.pdf
ТипУчебник
#3698
страница60 из 99
1   ...   56   57   58   59   60   61   62   63   ...   99
Проблема с петлей, образующейся между соседними маршрутизаторами, надежно решается
р
помощью метода
расщепления горизонта.
Этот метод заключается в том, что маршрутная
Информация о некоторой сети, хранящаяся в таблице маршрутизации, никогда не передается
Цму маршрутизатору, от которого она получена.

582
Глава 17. Базовые протоколы TCP/IP
Практически все сегодняшние маршрутизаторы, работающие по протоколу RIP, исполь­
зуют технику расщепления горизонта. Если бы маршрутизатор R2 в рассмотренном ранее примере поддерживал технику расщепления горизонта, то он бы не передал маршрути­
затору R1 устаревшую информацию о сети 201.36.14.0, так как получил он ее именно от маршрутизатора R1.
Однако расщепление горизонта не помогает в тех случаях, когда петли образуются не дву­
мя, а большим числом маршрутизаторов. Рассмотрим более детально ситуацию, которая возникнет в сети, приведенной на рис. 17.17, в случае потери связи маршрутизатора R1 с сетью 201.36.14.0. Пусть все маршрутизаторы этой сети поддерживают технику расще­
пления горизонта. Маршрутизаторы R2 и R3 не будут возвращать маршрутизатору в этой ситуации данные о сети 201.36.14.0 с метрикой 2, так как они получили эту информацию от маршрутизатора R1. Однако они будут передавать маршрутизатору информацию о до­
стижимости сети 201.36.14.0 с метрикой 4 через себя, так как получили эту информацию по сложному маршруту, а не непосредственно от маршрутизатора R1. Например, маршрутиза­
тор R2 получает эту информацию по цепочке R4-R3-R1, поэтому маршрутизатор R1 снова может быть обманут, пока каждый из маршрутизаторов в цепочке R3-R4-R2 не вычеркнет запись о достижимости сети 201.36.14.0.
Для предотвращения зацикливания пакетов по составным петлям при отказах связей при­
меняются два других приема, называемые триггерными обновлениями и замораживанием изменений.
Прием триггерных обновлений состоит в том, что маршрутизатор, получив данные об изменении метрики до какой-либо сети, не ждет истечения периода передачи таблицы маршрутизации, а передает данные об изменившемся маршруте немедленно. Этот прием может во многих случаях предотвратить передачу устаревших сведений об отказавшем маршруте, но он перегружает сеть служебными сообщениями, поэтому триггерные объ­
явления также делаются с некоторой задержкой. По этой причине возможна ситуация, когда регулярное обновление в каком-либо маршрутизаторе чуть опережает по времени приход триггерного обновления от предыдущего в цепочке маршрутизатора, и данный маршрутизатор успевает передать по сети устаревшую информацию о несуществующем маршруте.
Второй прием — замораживание изменений — позволяет исключить подобные ситуации.
Он связан с введением тайм-аута на принятие новых данных о сети, которая только что стала недоступной. Этот тайм-аут предотвращает принятие устаревших сведений о не­
котором маршруте от тех маршрутизаторов, которые находятся на некотором расстоянии от отказавшей связи и передают устаревшие сведения о ее работоспособности. Предпо­
лагается, что в течение тайм-аута «замораживания изменений» эти маршрутизаторы вы­
черкнут данный маршрут из своих таблиц, так как не получат о нем новых записей и не будут распространять устаревшие сведения по сети.
Протокол OSPF
Протокол OSPF (Open Shortest Path First — выбор кратчайшего пути первым) является последним (он принят в 1991 году) протоколом, основанном на алгоритме состояния свя­
зей, и обладает многими особенностями, ориентированными на применение в больших гетерогенных сетях.

Протокол OSPF
583
Два этапа построения таблицы маршрутизации
OSPF разбивает процедуру построения таблицы маршрутизации на два этапа, к первому относится построение и поддержание базы данных о состоянии связей сети, ко второму — нахождение оптимальных маршрутов и генерация таблицы маршрутизации.
Построение и поддержание базы данных о состоянии связей сети. Связи сети могут быть представлены в виде графа, в котором вершинами графа являются маршрутизаторы и под­
сети, а ребрами — связи между ними (рис. 17.18). Каждый маршрутизатор обменивается со своими соседями той информацией о графе сети, которой он располагает к данному моменту. Этот процесс похож на процесс распространения векторов расстояний до сетей в протоколе RIP, однако сама информация качественно иная — это информация о тополо­
гии сети. Сообщения, с помощью которых распространяется топологическая информация, называются объявлениями о состоянии связей (Link State Advertisement, LSA) сети. При транзитной передаче объявлений LSA маршрутизаторы не модифицируют информацию, как это происходит в дистанционно-векторных протоколах, в частности в RIP, а передают ее в неизменном виде. В результате все маршрутизаторы сети сохраняют в своей памяти идентичные сведения о текущей конфигурации графа связей сети.
Для контроля состояния связей и соседних маршрутизаторов OSPF-маршрутизаторы передают друг другу особые сообщения HELLO каждые 10 секунд. Небольшой объем этих сообщений делает возможным частое тестирование состояния соседей и связей с ними.
Втом случае, когда сообщения HELLO перестают поступать от какого-либо непосред­
ственного соседа, маршрутизатор делает вывод о том, что состояние связи изменилось с работоспособного на неработоспособное и вносит соответствующие коррективы в свою топологическую базу данных. Одновременно он отсылает всем непосредственным соседям объявление LSA об этом изменении, те также вносят исправления в свои базы данных и, в свою очередь, рассылают данное объявление LSA своим непосредственным соседям.
Нахождение оптимальных маршрутов и генерация таблицы маршрутизации. Задача на­
хождения оптимального пути на графе является достаточно сложной и трудоемкой. В про­
токоле OSPF для ее решения используется итеративный алгоритм Дийкстры. Каждый

584
Глава 17. Базовые протоколы TCP/IP
маршрутизатор сети, действуя в соответствии с этим алгоритмом, ищет оптимальные маршруты от своих интерфейсов до всех известных ему подсетей. В каждом найденном таким образом маршруте запоминается только один шаг — до следующего маршрутизатора.
Данные об этом шаге и попадают в таблицу маршрутизации.
Если состояние связей в сети изменилось и произошла корректировка графа сети, каж­
дый маршрутизатор заново ищет оптимальные маршруты и корректирует свою таблицу маршрутизации. Аналогичный процесс происходит и в том случае, когда в сети появляется новая связь или новый сосед, объявляющий о себе с помощью своих сообщений HELLO.
При работе протокола OSPF конвергенция таблиц маршрутизации к новому согласован­
ному состоянию происходит достаточно быстро, быстрее, чем в сетях, в которых работают дистанционно-векторные протоколы. Это время состоит из времени распространения по сети объявления LSA и времени работы алгоритма Дийкстры, который обладает быстрой сходимостью. Однако вычислительная сложность этого алгоритма предъявляет высокие требования к мощности процессора маршрутизатора.
Когда состояние сети не меняется, то объявления о связях не генерируются, топологи­
ческие базы данных и таблицы маршрутизации не корректируются, что экономит про­
пускную способность сети и вычислительные ресурсы маршрутизаторов. Однако у этого правила есть исключение: каждые 30 минут OSPF-маршрутизаторы обмениваются всеми записями базы данных топологической информации, то есть синхронизируют их для более надежной работы сети. Так как этот период достаточно большой, то данное исключение незначительно сказывается на загрузке сети.
Метрики
При поиске оптимальных маршрутов протокол OSPF по умолчанию использует метрику, учитывающую пропускную способность каналов связи. Кроме того, допускается примене­
ние двух других метрик, учитывающих задержки и надежность передачи пакетов каналами связи. Для каждой из метрик протокол OSPF строит отдельную таблицу маршрутизации.
Выбор нужной таблицы происходит в зависимости от значений битов TOS в заголовке пришедшего IP-пакета. Если в пакете бит D (Delay — задержка) установлен в 1, то для этого пакета маршрут должен выбираться из таблицы, в которой содержатся маршруты, минимизирующие задержку. Аналогично, пакет с установленным битом Т (Throughput - пропускная способность) должен маршрутизироваться по таблице, построенной с учетом пропускной способности каналов, а установленный в единицу бит R (Reliability — на­
дежность) указывает на то, что должна использоваться таблица, для построения которой критерием оптимизации служит надежность доставки.
Протокол OSPF поддерживает стандартные для многих протоколов (например, для про­
токола покрывающего дерева) значения расстояний для метрики, отражающей пропускную способность: так, для сети Ethernet она равна 10, для Fast Ethernet — 1, для канала Т-11, обладающего пропускной способностью 1,544 Мбит/с, — 65, для канала с пропускной спо­
собностью 56 Кбит/с — 1785. При наличии высокоскоростных каналов, таких как Gigabit
Ethernet или STM-16/64, администратору нужно задать другую шкалу скоростей, назначив единичное расстояние наиболее скоростному каналу.
1 Т-1 — это цифровой канал технологии PDH, рассматривавшейся в главе 11.

Маршрутизация в неоднородных сетях
585
При выборе оптимального пути на графе с каждым ребром графа связывается метрика, которая добавляется к пути, если данное ребро в него входит. Пусть в приведенном на рис. 17.18 примере маршрутизатор R5 связан с маршрутизаторами R6 и R7 каналами Т-1, а маршрутизаторы R6 и R7 связаны между собой каналом 56 Кбит/с. Тогда R7 определит оптимальный маршрут до сети 201.106.14.0 как составной, проходящий сначала через R5, а затем через R6, поскольку у этого маршрута метрика будет равна 65 + 65 = 130 единиц.
Непосредственный маршрут через R6 не будет оптимальным, так как его метрика равна
1785.
Протокол OSPF разрешает хранить в таблице маршрутизации несколько маршрутов к одной сети, если они обладают равными метриками. В таких случаях маршрутизатор может работать в режиме баланса загрузки маршрутов, отправляя пакеты попеременно по каждому из маршрутов.
К сожалению, вычислительная сложность протокола OSPF быстро растет с увеличением размера сети. Для преодоления этого недостатка в протоколе OSPF вводится понятие области сети. Маршрутизаторы, принадлежащие некоторой области, строят граф связей только для этой области, что упрощает задачу. Между областями информация о связях не передается, а пограничные для областей маршрутизаторы обмениваются только информа­
цией об адресах сетей, имеющихся в каждой из областей, и расстоянием от пограничного
маршрутизатора до каждой сети. При передаче пакетов между областями выбирается один из пограничных маршрутизаторов области, а именно тот, у которого расстояние до нужной сети меньше.
Маршрутизация в неоднородных сетях
Взаимодействие протоколов маршрутизации
В одной и той же сети могут одновременно работать несколько разных протоколов марш­
рутизации (рис. 17.19). Это означает, что на некоторых (не обязательно всех) маршру­
тизаторах сети установлено и функционирует несколько протоколов маршрутизации, но при этом, естественно, через сеть взаимодействуют только одноименные протоколы.
То есть если маршрутизатор 1 поддерживает, например, протоколы RIP и OSPF, марш­
рутизатор 2 — только RIP, а маршрутизатор 3 — только OSPF, то маршрутизатор 1 будет взаимодействовать с маршрутизатором 2 по протоколу RIP, с маршрутизатором 3 — по
0SPF, а маршрутизаторы 2 и 3 вообще непосредственно друг с другом взаимодействовать не смогут.
В маршрутизаторе, который поддерживает одновременно несколько протоколов, каждая запись в таблице является результатом работы одного из этих протоколов. Если информа­
ция о некоторой сети появляется от нескольких протоколов, то для однозначности выбора маршрута (а данные разных протоколов могут вести к разным рациональным маршрутам) устанавливаются приоритеты протоколов маршрутизации. Обычно предпочтение отдается протоколам LSA, как располагающим более полной информацией о сети по сравнению с протоколами DYA. В некоторых ОС в формах вывода на экран и печать в каждой записи таблицы маршрутизации имеется отметка о том, с помощью какого протокола маршрути­
зации эта запись получена. Но даже если эта отметка на экран и не выводится, она обяза­
тельно имеется во внутреннем представлении таблицы маршрутизации.

586
Глава 17. Базовые протоколы TCP/IP
^
Таблица
маршрутизации
I
ч
Таблица
\
маршрутизации \
Ж
p i ,1г1t
І
»' г- і: v т} "л;
Рис. 17.19. Применение нескольких протоколов маршрутизации в одной сети
По умолчанию каждый протокол маршрутизации, работающий на определенном марш­
рутизаторе, распространяет только «собственную» информацию, то есть ту информацию, которая была получена данным маршрутизатором по данному протоколу. Например, если о маршруте к некоторой сети маршрутизатор узнал по протоколу RIP, то и распространять по сети объявления об этом маршруте он будет с помощью протокола RIP.
Однако такой «избирательный» режим работы маршрутизаторов ставит невидимые барьеры на пути распространения маршрутной информации, создавая в составной сети области взаимной недостижимости. Задача маршрутизации решалась бы эффективнее, если бы маршрутизаторы могли обмениваться маршрутной информацией, полученной разными протоколами маршрутизации. Такая возможность реализуется в особом режиме работы маршрутизатора, называемом перераспределением. Этот режим позволяет одному протоколу маршрутизации использовать не только «свои», но и «чужие» записи таблицы маршрутизации, полученные с помощью другого протокола маршрутизации, указанного при конфигурировании.
Как видим, применение нескольких протоколов маршрутизации даже в пределах неболь­
шой составной сети — дело не простое, от администратора требуется провести определен­
ную работу по конфигурированию каждого маршрутизатора. Очевидно, что для крупных составных сетей нужно качественно иное решение.
Внутренние и внешние шлюзовые протоколы
Такое решение было найдено для самой крупной на сегодня составной сети — Интернета.
Это решение базируется на понятии автономной системы.

Маршрутизация в неоднородных сетях
587
Автономная система (Autonomous System, AS) — это совокупность сетей под единым админи­
стративным управлением, обеспечивающим общую для всех входящих в автономную систему
маршрутизаторов политику маршрутизации.
Обычно автономной системой управляет один поставщик услуг Интернета, самостоя­
тельно выбирая, какие протоколы маршрутизации должны использоваться в некоторой автономной системе и каким образом между ними должно выполняться перераспределение маршрутной информации. Крупные поставщики услуг и корпорации могут представить свою составную сеть как набор нескольких автономных систем. Регистрация автономных систем происходит централизованно, как и регистрация ІР-адресов и DNS-имен. Номер автономной системы состоит из 16 разрядов и никак не связан с префиксами ІР-адресов входящих в нее сетей.
В соответствии с этой концепцией Интернет выглядит как набор взаимосвязанных авто­
номных систем, каждая из которых состоит из взаимосвязанных сетей (рис. 17.20), соеди­
ненными внешними шлюзами.
Основная цель деления Интернета на автономные системы — обеспечение многоуровневого подхода к маршрутизации. До введения автономных систем предполагался двухуровневый подход, то есть сначала маршрут определялся как последовательность сетей, а затем вел непосредственно к заданному узлу в конечной сети (именно этот подход мы использовали до сих пор).
Внешний шлюзовый
Рис. 17.20. Автономные системы Интернета

588
Глава 17. Базовые протоколы TCP/IP
С появлением автономных систем появляется третий, верхний, уровень маршрутизации — теперь сначала маршрут определяется как последовательность автономных систем, за­
тем — как последовательность сетей и только потом ведет к конечному узлу.
Выбор маршрута между автономными системами осуществляют внешние шлюзы, ис­
пользующие особый тип протокола маршрутизации, так называемый внешний шлюзовой
протокол (Exterior Gateway Protocol, EGP). В настоящее время для работы в такой роли сообщество Интернета утвердило стандартный пограничный шлюзовой протокол версии 4
(Border Gateway Protocol, BGPv4). В качестве адреса следующего маршрутизатора в про­
токоле BGPv4 указывается адрес точки входа в соседнюю автономную систему.
За маршрут внутри автономной системы отвечают внутренние шлюзовые протоколы
(Interior Gateway Protocol, IGP). К числу IGP относятся знакомые нам протоколы RIP,
OSPF и IS-IS. В случае транзитной автономной системы эти протоколы указывают точ­
ную последовательность маршрутизаторов от точки входа в автономную систему до точки выхода из нее.
ПРИМЕЧАНИЕ--------------------------------------------------------------------------------------------------
Внутри каждой автономной системы может применяться любой из существующих протоколов
маршрутизации, в то время как между автономными системами всегда применяется один и тот же
протокол, являющийся своеобразным языком «эсперанто», на котором автономные системы обща­
ются между собой.
Концепция автономных систем скрывает от администраторов магистрали Интернета про­
блемы маршрутизации пакетов на более низком уровне — уровне сетей. Для администрато­
ра магистрали неважно, какие протоколы маршрутизации применяются внутри автоном­
ных систем, для него существует единственный протокол маршрутизации — BGPv4.
Протокол BGP
Пограничный (внешний) шлюзовой протокол (Border Gateway Protocol, BGP) версии 4 является сегодня основным протоколом обмена маршрутной информацией между авто­
номными системами Интернета. Протокол BGP пришел на смену протоколу EGP1, ис­
пользовавшемуся в тот начальный период, когда Интернет имел единственную магистраль.
Эта магистраль являлась центральной автономной системой, к которой присоединялись в соответствии с древовидной топологией все остальные автономные системы. Так как между автономными системами при такой структуре петли исключались, протокол EGP не предпринимал никаких мер для того, чтобы исключить зацикливание маршрутов.
BGPv4 успешно работает при любой топологий свйаей между автономными еиотейамй* что С
0
* ответствует оовремешому
сщ т нт
Интернета,
Поясним основные принципы работы BGP на примере (рис. 17.21).
1 EGP в данном случае является названием конкретного протокола маршрутизации. Напомним, что
аббревиатура EGP служит также названием класса внешних шлюзовых протоколов, используемых
для маршрутизации между автономными системами, что вносит некоторую путаницу.

Протокол BGP
589
В каждой из трех автономных систем (AS 1021, AS 363 и AS 520) имеется несколько марш­
рутизаторов, исполняющих роль внешних шлюзов. На каждом из них работает протокол
BGP, с помощью которого они общаются между собой.
Маршрутизатор взаимодействует с другими маршрутизаторами по протоколу BGP только в том случае, если администратор явно указывает при конфигурировании, что эти марш­
рутизаторы являются его соседями. Например, маршрутизатор EG1 в рассматриваемом примере будет взаимодействовать по протоколу BGP с маршрутизатором EG2 не потому, что эти маршрутизаторы соединены двухточечным каналом, а потому, что при конфигу­
рировании маршрутизатора EG1 в качестве соседа ему был указан маршрутизатор EG2
(с адресом 194.200.30.2). Аналогично, при конфигурировании маршрутизатора EG2 его соседом был назначен маршрутизатор EG1 (с адресом 194.200.30.1).
Такой способ взаимодействия удобен в ситуации, когда маршрутизаторы, обмениваю­
щиеся маршрутной информацией, принадлежат разным поставщикам услуг (ISP). Адми­
нистратор ISP может решать, с какими автономными системами он будет обмениваться трафиком, а с какими нет, задавая список соседей для своих внешних шлюзов. Протоколы
RIP и QSPF, разработанные для применения внутри автономной системы, обмениваются маршрутной информацией со всеми маршрутизаторами, находящимися в пределах их непосредственной досягаемости (по локальной сети или через двухточечный канал). Это означает, что информация обо всех сетях появляется в таблице маршрутизации каждого маршрутизатора, так что каждая сеть оказывается достижимой для каждой. В корпоратив­
ной сети это нормальная ситуация, а в сетях ISP нет, поэтому протокол BGP и исполняет здесь особую роль.
Для установления сеанса с указанными соседями BGP-маршрутизаторы используют про­
токол TCP (порт 179). При установлении BGP-сеанса могут применяться разнообразные способы аутентификации маршрутизаторов, повышающие безопасность работы автоном­
ных систем.

590
Глава 17. Базовые протоколы TCP/IP
Основным сообщением протокола BGP является сообщение UPDATE (обновить), с по­
мощью которого маршрутизатор сообщает маршрутизатору соседней автономной системы о достижимости сетей, относящихся к его собственной автономной системе. Само название этого сообщения говорит о том, что это — триггерное объявление, которое посылается соседу только тогда, когда в автономной системе что-нибудь резко меняется: появляются новые сети или новые пути к сетям либо же, напротив, исчезают существовавшие сети или пути.
В одном сообщении UPDATE можно объявить об одном новом маршруте или аннулиро­
вать несколько маршрутов, переставших существовать. Под маршрутом в BGP понимает­
ся последовательность автономных систем, которую нужно пройти на пути к указанной в адресе сети. Более формально информация о маршруте (BGP Route) к сети (Network/
Mask_length) выглядит так:
BGP Route = AS_Path; NextHop; Network/Mask length;
Здесь AS_P&th — набор номеров автономных систем, NextHop — ІР-адрес маршрутизато­
ра, через который нужно передавать пакеты в сеть Network/Mask_length. Например, если маршрутизатор EG1 хочет объявить маршрутизатору EG2 о том, что в AS 1021 появилась новая сеть 202.100.5.0/24, то он формирует такое сообщение:
AS 1021; 194.200.30.1; 202.100.5.0/24,
после чего передает его маршрутизатору EG2 автономной системы AS 363 (с которым у него, конечно, должен быть установлен BGP-сеанс).
Маршрутизатор EG2, получив сообщение UPDATE, запоминает в своей таблице маршру­
тизации информацию о сети 202.100.5.0/24 вместе с адресом следующего маршрутизатора
194.200.30.1 и отметкой о том, что эта информация была получена по протоколу BGP.
Маршрутизатор EG2 обменивается маршрутной информацией с внутренними шлюзами системы AS 363 по какому-либо протоколу группы IGP, например OSPF. Если у EG2 уста­
новлен режим перераспределения маршрутов BGP в маршруты OSPF, то все внутренние шлюзы AS 363 узнают о существовании сети 202.100.5.0/24 с помощью объявления OSPF, которое будет внешним. В качестве адреса следующего маршрутизатора маршрутизатор
EG2 начнет теперь объявлять адрес собственного внутреннего интерфейса, например
192.17.100.2.
Однако для распространения сообщения о сети 202.100.5.0/24 в другие автономные систе­
мы, например в AS 520, протокол OSPF использоваться не может. Маршрутизатор EG3, связанный с маршрутизатором EG4 автономной системы 520, должен пользоваться про­
токолом BGP, генерируя сообщение UPDATE нужного формата. Для решения этой задачи он не может задействовать информацию о сети 202.100.5.0/24, полученную от протокола
OSPF через один из своих внутренних интерфейсов, так как она имеет другой формат и не содержит, например, сведений о номере автономной системы, в которой находится эта сеть.
Проблема решается за счет того, что маршрутизаторы EG2 и EG3 также устанавливают между собой BGP-сеанс, хотя они и принадлежат одной и той же автономной системе.
Такая реализация протокола BGP называется внутренней (Interior BGP, iBGP), в отличие от основной, внешней (Exterior BGP, eBGP). В результате маршрутизатор EG3 получает нужную информацию от маршрутизатора EG2 и передает ее внешнему соседу — марш­

Протокол ICMP
591
рутизатору EG4. При формировании нового сообщения UPDATE маршрутизатор EG3 трансформирует сообщение, полученное от маршрутизатора EG2, добавляя в список авто­
номных систем собственную автономную систему AS 520, а полученный адрес следующего маршрутизатора заменяет адресом собственного интерфейса:
AS 363, AS 1021; 132.15.64.3; 202.100.5.0/24.
Номера автономных систем позволяют исключать зацикливание сообщений UPDATE.
Например, когда маршрутизатор EG5 передаст сообщение о сети 202.100.5.0/24 маршру­
тизатору EG6, то последний не будет его использовать, так как оно будет иметь вид:
AS 520, AS 363, AS 1021; 201.14.110.3; 202.100.5.0/24.
Так как в списке автономных систем уже есть номер собственной автономной системы, очевидно, что сообщение зациклилось.
Протокол BGP используется сегодня не только для обмена маршрутной информацией между автономными системами, но и внутри них.
Протокол ICMP
сообщений (Internet Control Message Protocol, ICMP)
(RFC 792) Я8ЛЙЄТСЙ вспомогательным протоколом» йолользующимся для диагностики и Мони­
торинга СеТИ.
'
• * г .
Можно представить ряд ситуаций, когда протокол IP не может доставить пакет адресату, например истекает время жизни пакета, в таблице маршрутизации отсутствует маршрут к заданному в пакете адресу назначения, пакет не проходит проверку по контрольной сумме, шлюз не имеет достаточно места в своем буфере для передачи какого-либо пакета и т. д., и т. п.
Как мы не раз отмечали, протокол IP доставляет данные, руководствуясь принципом
«по возможности», то есть не предпринимает мер для гарантированной передачи данных адресату Это свойство «необязательности» протокола IP компенсируется протоколами более высоких уровней стека TCP/IP, например TCP на транспортном уровне и в какой-то степени DNS на прикладном уровне. Они берут на себя обязанности по обеспечению на­
дежности, применяя такие известные приемы, как нумерация сообщений, подтверждение доставки, повторная посылка данных.
Протокол ICMP также служит дополнением, компенсирующим ненадежность протоко­
ла IP, но несколько другого рода. Он не предназначен для исправления возникших при передаче пакета проблем: если пакет потерян, ICMP не может послать его заново. Задача
ICMP другая — он является средством оповещения отправителя о «несчастных случаях», произошедших с его пакетами. Пусть, например, протокол IP, работающий на каком-либо маршрутизаторе, обнаружил, что пакет для дальнейшей передачи по маршруту необходимо фрагментировать, но в пакете установлен признак DF (не фрагментировать). Протокол IP, обнаруживший, что он не может передать IP-пакет далее по сети, прежде чем отбросить пакет, должен отправить диагностическое ІСМР-сообщение конечному узлу-источнику.

592
Глава 17. Базовые протоколы TCP/IP
Для передачи по сети ІСМР-сообщение инкапсулируется в поле данных ІР-пакета. ІР- адрес узла-источника определяется из заголовка пакета, вызвавшего инцидент.
Сообщение, прибывшее в узел-источник, может быть обработано там либо ядром опера­
ционной системы, либо протоколами транспортного и прикладного уровней, либо при­
ложениями, либо просто проигнорированы. Важно, что обработка ІСМР-сообщений не входит в обязанности протоколов IP и ICMP
Заметим, что некоторые из пакетов могут исчезнуть в сети, не вызвав при этом никаких оповещений. В частности, протокол ICMP не предусматривает передачу сообщений о про­
блемах, возникающих при обработке IP-пакетов, несущих ICMP-сообщения об ошибках.
Такое решение было принято разработчиками протокола, чтобы не порождать «штормы» в сетях, когда количество сообщений об ошибках лавинообразно возрастает.
Особенностью протокола ICMP является функциональное разнообразие решаемых задач, а следовательно, и связанных с этим сообщений. Все типы сообщений имеют один и тот же формат (рис. 17.22), однако интерпретация полей существенно зависит от того, к какому типу относится сообщение.
< —1 байт^->
1 байт-* < --------- 2 байта---------- ►
Тип
Код
Контрольная
сумма
Зависит от типа
и кода сообщения
Зависит от типа
и кода сообщения
,

- )
Зависит о т типа и кода сообщений
,
V _
.. ,
V у':
Рис. 17.22. Формат ЮМР-сообщения
Заголовок ІСМР-сообщения состоит из 8 байт:
тип (1 байт) — числовой идентификатор типа сообщения;
код (1 байт) — числовой идентификатор, более тонко дифференцирующий тип ошибки;
□ контрольная сумма (2 байта) — подсчитывается для всего ІСМР-сообщения.
Содержимое оставшихся четырех байтов в заголовке и поле данных зависит от значений полей
типа и кода.
На рис. 17.23 показана таблица основных типов ІСМР-сообщений. Эти сообщения можно разделить на две группы (помеченные на рисунке условными символами):
□ сообщения об ошибках-,
□ сообщения запрос-ответ.
Сообщения типа запрос-ответ связаны в пары: эхо-запрос — эхо-ответ, запрос маски - ответ маски, запрос времени — ответ времени. Отправитель сообщения-запроса всегда рассчитывает на получение соответствующего сообщения-ответа.

Протокол ICMP
593
Таблица типов ІСМР-сообщений
Значение в
поле «Тип»
11 12
13
14
17
18
Тип сообщения
Эхо-ответ
Узел назначения недостижим
/
-----------------------L
Подавление источника
Перенаправление маршрута
Эхо-запрос
Истечение времени диаграммы
Проблема с параметрами пакета
Запрос отметки времени
Ответ отметки времени
Запрос маски
Ответ маски
/А/
V
У
V ? /
V
V
, ? N
ЧхУ
, ? N
Таблица кодов
причин ошибок 3
КОД
Причина
0
Сеть недостижима
1
Узел недостижим
2
Протокол недостижим
3
Порт недостижим
4
Ошибка фрагментации
5
Ошибка в маршруте источника
6
Сеть назначения не известна
7
Узел назначения не известен
8
Узел-источник изолирован
9
Административный запрет
?
сообщение-запрос
С Г> сообщение-ответ
V
сообщение-ошибка
Рис. 17.23. Типы и коды ІСМР-сообщений
Сообщения, относящиеся к группе сообщений об ошибках, конкретизируются уточняющим кодом. На рисунке показан фрагмент таблицы кодов для сообщения об ошибке недостижи­
мости узла назначения, имеющей тип 3. Из таблицы мы видим, что это сообщение может быть вызвано различными причинами, такими как неверный адрес сети или узла (код О или 1), отсутствием на конечном узле-адресате необходимого протокола прикладного уровня (код 2 — «протокол недостижим») или открытого порта UDP/TCP (код 3 — «порт недостижим»). Узел (или сеть) назначения может быть также недостижим по причине временной неработоспособности аппаратуры или из-за того, что маршрутизатор не имеет данных о пути к сети назначения. Всего таблица содержит 15 кодов. Аналогичные таблицы кодов существуют и для других типов сообщений об ошибках.
Утилита traceroute
В качестве примера рассмотрим использование сообщений об ошибках в популярной утилите мониторинга сети traceroute.
Когда маршрутизатор не может передать или доставить ІР-пакет, он отсылает узлу, отпра­
вившему этот пакет, сообщение о недостижимости узла назначения. Формат этого сообще­
ния показан на рис. 17.24. В поле типа помещается значение 3, а в поле кода — значение из диапазона 0-15, уточняющее причину, по которой пакет не был доставлен. Следующие за полем контрольной суммы четыре байта заголовка не используются и заполняются
, нулями.

594
Глава 17. Базовые протоколы TCP/
< —1 байт - ►Ц 1 байт > \<
*\ О.
Тип = 3
Код = -15
Не используется
Контрольная
сумма
Поле данных
Заголовок +
В первых байт поля данных,
вызвавшего ошибку 1Р-паквта
ЇЇ' ,
'.
Рис. 17.24. Формат ICMP-сообщения об ошибке недостижимости узла назначения
Помимо причины ошибки, указанной в заголовке (в полях типа и кода), дополнитель: диагностическая информация передается в поле данных ІСМР-сообщения. Именно т помещается заголовок IP и первые 8 байт данных того IP -пакета, который вызвал оши<
Эта информация позволяет узлу-отправителю еще точнее диагностировать причину ош ки. Это возможно, так как все протоколы стека TCP/IP, использующие для передачи св сообщений IP -пакеты, помещают наиболее важную для анализа информацию в пер
8 байт своих сообщений. В частности, ими вполне могут оказаться первые 8 байт заголс
TC P или UDP, в которых содержится информация (номер порта), идентифицирую! приложение, пославшее потерянный пакет. Следовательно, при разработке приложе можно предусмотреть встроенные средства реакции на сообщения о недоставлені пакетах.
ІСМ Р-сообщения об ошибках лежат в основе работы популярной утилиты traceroute
Unix, имеющей в Windows название tracert. Эта утилита позволяет проследить маршру удаленного хоста, определить среднее время оборота (RTT), IP-адрес и в некоторых сл; ях доменное имя каждого промежуточного маршрутизатора. Такая информация помо найти маршрутизатор, на котором обрывается путь пакета к удаленному хосту.
Утилита traceroute осуществляет трассировку маршрута, посылая серию обычных пакетов в конечную точку изучаемого маршрута. Идея метода состоит в следующем. Зн. ние времени жизни (TTL) первого отправляемого пакета устанавливается равным 1. К< протокол IP первого маршрутизатора принимает этот пакет, то он в соответствии со св> алгоритмом уменьшает значение TTL на 1 и получает 0. Маршрутизатор отбрасывает ні
с нулевым временем жизни и возвращает узлу-источнику ІСМР-сообщение об оши истечения времени дейтаграммы (значение поля типа равно 11) вместе с заголовкол и первыми 8 байтами потерянного пакета.
Получив ІСМ Р-сообщение о причине недоставки пакета, утилита traceroute запомиї адрес первого марш рутизатора (который извлекает из заголовка IP -пакета, несуии
ІСМ Р-сообщ ение).
Затем traceroute посылает следующий IP -пакет, но теперь со значением TTL, равных
Этот пакет благополучно проходит первый маршрутизатор, но «умирает» на втором, о 1 немедленно отправляется аналогичное ІСМР-сообщение об ошибке истечения времі дейтаграммы. Утилита traceroute запоминает адрес второго маршрутизатора и т. д. Та

Протокол ICMP
595
действия выполняются с каждым маршрутизатором вдоль маршрута вплоть до узла на­
значения или неисправного маршрутизатора. Мы рассматриваем работу утилиты traceroute весьма схематично, но и этого достаточно, чтобы оценить изящество идеи, лежащей в осно­
ве ее работы. Остальные ІСМР-сообщения об ошибках имеют такой же формат и отлича­
ются друг от друга только значениями полей типа и кода.
Далее приведена копия экранной формы, выведенной утилитой tracert (Windows) при трассировке хоста ds.jnternic.net [198.49.45.29]:
1 311 ms 2 9 0 ms 2 6 1 ms 1 4 4 . 2 0 6 . 1 9 2 . 1 0 0 2 281 ms 3 0 0 ms 2 7 1 ms 1 9 4 . 8 5 . 7 3 . 5 3 2 0 2 3 ms 2 9 0 ms 3 1 1 ms m o s c o w - m 9 - 2 - S 5 . r e l c o m . e u . n e t [ 1 9 3 . 1 2 4 . 2 5 4 . 3 7 ]
4 290 ms 2 6 1 ms 2 8 0 ms M S K - M 9 - 1 3 . R e l c o m . E U . n e t [ 1 9 3 . 1 2 5 . 1 5 . 1 3 ]
5 270 ms 2 8 1 ms 2 9 0 ms M S K . R A I L - l - A T M 0 - 1 5 5 M b . R e l c o m . E U . n e t [ 1 9 3 . 1 2 4 . 2 5 4 . 8 2 ]
6 300 ms 3 1 1 ms 2 9 0 ms S P B - R A S C 0 M - l - E 3 - l - 3 4 M b . R e l c o m . E U . n e t [ 1 9 3 . 1 2 4 . 2 5 4 . 7 8 ]
7 311 ms 3 0 0 ms 3 0 0 ms H s s i l l - 0 . G W 1 . S T K 2 . A L T E R . N E T [ 1 4 6 . 1 8 8 . 3 3 . 1 2 5 ]
8 311 ms 3 3 0 ms 2 9 1 ms 4 2 1 . A T M 6 - 0 - 0 . C R 2 . S T K 2 . A l t e r . N e t [ 1 4 6 . 1 8 8 . 5 . 7 3 ]
9 360 ms >331 ms 3 3 0 ms 2 1 9 . H s s i 4 - 0 . C R 2 . L N D 1 . A 1 t e r . N e t [ 1 4 6 . 1 8 8 . 2 . 2 1 3 ]
10 351 ms 3 3 0 ms 3 3 1 ms 4 1 2 . A t m 5 - 0 . B R l . L N D l . A l t e r . n e t [ 1 4 6 . 1 8 8 . 3 . 2 0 5 ]
11 4 20 ms 4 6 1 ms 4 2 0 ms 1 6 7 . A T M 8 - 0 - 0 . C R 1 . A T L 1 . A l t e r . N e t [ 1 3 7 . 3 9 . 6 9 . 1 8 2 ]
12 461 ms 4 4 1 ms 4 4 0 ms 3 1 1 . A T M 1 2 - 0 - 0 . B R I . A T L 1 . A 1 t e r . N e t [ 1 3 7 . 3 9 . 2 1 . 7 3 ]
13 451 ms 4 1 0 ms 4 3 1 ms a t l a n t a l - b r l . b b n p l a n e t . n e t [ 4 . 0 . 2 . 1 4 1 ]
14 4 2 0 ms 4 1 1 ms 4 1 0 ms v i e n n a l - b r 2 . b b n p l a n e t . n e t [ 4 . 0 . 3-. 1 5 4 ]
15 411 ms 4 3 0 ms 2 5 1 4 ms v i e n n a l - n b r 3 . b b n p l a n e t . n e t [ 4 . 0 . 3 . 1 5 0 ]
16 4 3 0 ms 4 2 1 ms 4 4 1 ms v i e n n a l - n b r 2 . b b n p l a n e t . n e t [ 4 . 0 . 5 . 4 5 ]
17 431 ms 4 5 1 ms 4 2 0 ms c a m b r i d g e l - b r l . b b n p l a n e t . n e t [ 4 . 0 . 5 . 4 2 ]
18 4 50 ms 4 6 1 ms 4 4 1 M С c a m b r i d g e l - c r l 4 . b b n p l a n e t . n e t [ 4 . 0 . 3 . 9 4 ]
19 451 M С 4 6 1 M С 4 6 0 M С a t t b c s t o l l . b b n p l a n e t . n e t [ 2 0 6 . 3 4 . 9 9 . 3 8 ]
20 501 M С 4 6 0 M С 4 8 1 M С s h u t d o w n . d s . i n t e r n i c . n e t [ 1 9 8 . 4 9 . 4 5 . 2 9 ]
Последовательность строк соответствует последовательности маршрутизаторов, образую­
щих маршрут к заданному узлу. Первое число в строке — число хопов до соответствующего маршрутизатора. Утилита traceroute тестирует каждый маршрутизатор трижды, поэтому следующие три числа в строке — это значения RTT, вычисленные путем посылки трех па­
кетов, время жизни которых истекло на этом маршрутизаторе. Если ответ от какого-либо маршрутизатора не приходит за заданное время, то вместо времени на экране печатается звездочка (*).
Далее идут IP-адрес и доменное имя (если оно имеется) маршрутизатора. Видно, что поч­
ти все интерфейсы маршрутизаторов поставщиков услуг Интернета зарегистрированы в службе DNS, а первые два, относящиеся к локальным маршрутизаторам, — нет.
Еще раз подчеркнем, что время, указанное в каждой строке, это не время прохождения пакетов между двумя соседними маршрутизаторами, а время, за которое пакет проделы­
вает путь от источника до соответствующего маршрутизатора и обратно. Так как ситуация в Интернете с загрузкой маршрутизаторов постоянно меняется, то время достижимости маршрутизаторов не всегда нарастает монотонно, а может изменяться достаточно произ­
вольным образом.

596
1   ...   56   57   58   59   60   61   62   63   ...   99


написать администратору сайта