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

Выбор маршрута между автономными системами осуществляют внешние шлюзы, ис­ пользующие особый тип протокола маршрутизации, так называемый внешний шлюзовой протокол (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).

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

В каждой из трех автономных систем (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-сеанса могут применяться разнообразные способы аутентификации маршрутизаторов, повышающие безопасность работы автоном­ ных систем.

Основным сообщением протокола 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 и передает ее внешнему соседу —марш­

рутизатору 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-пакет далее по сети, прежде чем отбросить пакет, должен отправить диагностическое ІСМР-сообщение конечному узлу-источнику.

Для передачи по сети ІСМР-сообщение инкапсулируется в поле данных ІР-пакета. ІРадрес узла-источника определяется из заголовка пакета, вызвавшего инцидент.

Сообщение, прибывшее в узел-источник, может быть обработано там либо ядром опера­ ционной системы, либо протоколами транспортного и прикладного уровней, либо при­ ложениями, либо просто проигнорированы. Важно, что обработка ІСМР-сообщений не входит в обязанности протоколов IP и ICMP

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

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

Рис. 17.22. Формат ЮМР-сообщения

Заголовок ІСМР-сообщения состоит из 8 байт:

□тип (1 байт) —числовой идентификатор типа сообщения;

□код (1 байт) —числовой идентификатор, более тонко дифференцирующий тип ошибки;

□контрольная сумма (2 байта) —подсчитывается для всего ІСМР-сообщения.

Содержимое оставшихся четырех байтов взаголовке и поледанныхзависит от значений полей типа и кода.

На рис. 17.23 показана таблица основных типов ІСМР-сообщений. Эти сообщения можно разделить на две группы (помеченные на рисунке условными символами):

□сообщения об ошибках-,

□сообщения запрос-ответ.

Сообщения типа запрос-ответ связаны в пары: эхо-запрос —эхо-ответ, запрос маски - ответ маски, запрос времени —ответ времени. Отправитель сообщения-запроса всегда рассчитывает на получение соответствующего сообщения-ответа.

Не используется

Поледанных

Заголовок + В первыхбайтполяданных, вызвавшегоошибку1Р-паквта

ЇЇ' ,'.

Рис. 17.24. Формат ICMP-сообщения об ошибке недостижимости узла назначения

Помимо причины ошибки, указанной в заголовке (в полях типа и кода), дополнитель: диагностическая информация передается в поле данных ІСМР-сообщения. Именно т помещается заголовок IP и первые 8 байт данных того IP-пакета, который вызвал оши< Эта информация позволяет узлу-отправителю еще точнее диагностировать причину ош ки. Это возможно, так как все протоколы стека TCP/IP, использующие для передачи св сообщений IP-пакеты, помещают наиболее важную для анализа информацию в пер 8 байт своих сообщений. В частности, ими вполне могут оказаться первые 8 байт заголс TCP или UDP, в которых содержится информация (номер порта), идентифицирую! приложение, пославшее потерянный пакет. Следовательно, при разработке приложе можно предусмотреть встроенные средства реакции на сообщения о недоставлені пакетах.

ІСМР-сообщения об ошибках лежат в основе работы популярной утилиты traceroute Unix, имеющей в Windows название tracert. Эта утилита позволяет проследить маршру удаленного хоста, определить среднее время оборота (RTT), IP-адрес и в некоторых сл; ях доменное имя каждого промежуточного маршрутизатора. Такая информация помо найти маршрутизатор, на котором обрывается путь пакета к удаленному хосту.

Утилита traceroute осуществляет трассировку маршрута, посылая серию обычных пакетов в конечную точку изучаемого маршрута. Идея метода состоит в следующем. Зн. ние времени жизни (TTL) первого отправляемого пакета устанавливается равным 1. К< протокол IP первого маршрутизатора принимает этот пакет, то он в соответствии со св> алгоритмом уменьшает значение TTL на 1 и получает 0. Маршрутизатор отбрасывает ні с нулевым временем жизни и возвращает узлу-источнику ІСМР-сообщение об оши истечения времени дейтаграммы (значение поля типа равно 11) вместе с заголовкол и первыми 8 байтами потерянного пакета.

Получив ІСМР-сообщение о причине недоставки пакета, утилита traceroute запомиї адрес первого маршрутизатора (который извлекает из заголовка IP -пакета, несуии ІСМР-сообщение).

Затем traceroute посылает следующий IP -пакет, но теперь со значением TTL, равных Этот пакет благополучно проходит первый маршрутизатор, но «умирает» на втором, о1 немедленно отправляется аналогичное ІСМР-сообщение об ошибке истечения времі дейтаграммы. Утилита traceroute запоминает адрес второго маршрутизатора и т. д. Та

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

Далее приведена копия экранной формы, выведенной утилитой tracert (Windows) при трассировке хоста ds.jnternic.net [198.49.45.29]:

Последовательность строк соответствует последовательности маршрутизаторов, образую­ щих маршрут к заданному узлу. Первое число в строке —число хопов до соответствующего маршрутизатора. Утилита traceroute тестирует каждый маршрутизатор трижды, поэтому следующие три числа в строке —это значения RTT, вычисленные путем посылки трех па­ кетов, время жизни которых истекло на этом маршрутизаторе. Если ответ от какого-либо маршрутизатора не приходит за заданное время, то вместо времени на экране печатается звездочка (*).

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

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

Утилита ping

А сейчас давайте рассмотрим представителей другой группы ІСМР-сообщений —эхо- запросы и эхо-ответы и поговорим об использовании этих сообщений в известной утилите ping.

Эхо-запрос и эхо-ответ, в совокупности называемые эхо-протоколом, представляют со­ бой очень простое средство мониторинга сети. Компьютер или маршрутизатор посылает по составной сети ІСМР-сообщение эхо-запроса, указывая в нем IP-адрес узла, достижи­ мость которого нужно проверить. Узел, получивший эхо-запрос, формирует и отправляет эхо-ответ отправителю запроса. Так как эхо-запрос и эхо-ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транс­ портной системы составной сети.

Формат эхо-запроса и эхо-ответа показан на рис. 17.25. Поле типа для эхо-ответа рав­ но 0, для эхо-запроса —8; поле кода всегда равно 0 и для запроса, и для ответа. В бай­ тах 5 и 6 заголовка содержится идентификатор запроса, в байтах 7 и 8 —порядковый номер. В поле данных эхо-запроса может быть помещена произвольная информация, которая в соответствии с данным протоколом должна быть скопирована в доле данных эхо-ответа.

Поледанных

Рис. 17.25. Формат ІСМР-сообщений типа эхо-запрос и эхо-ответ

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

вэти два поля информацию, которая предназначена для последующего встраивания

всоответствующий ответ. Сообщение-ответ копирует значения этих полей в свои по того же назначения. Когда ответ возвращается в пункт отправки сообщения-запроса, на основании идентификатора он может «найти и опознать» приложение, пославшее прос. А порядковый номер используется приложением, чтобы связать полученный ОТ) с соответствующим запросом (учитывая, что одно приложение может выдать несколі однотипных запросов).

Утилита ping обычно посылает серию эхо-запросов к тестируемому узлу и предоставл пользователю статистику об утерянных эхо-ответах и среднем времени реакции сет* запросы. Утилита ping выводит на экран сообщения следующего вида обо всех поступ ших ответах: