Читать онлайн «TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)». Страница 49

8.17.4 Проблема выбора варианта

Рис. 8.24 показывает различия между Multi-exit Discriminator и Local Preference. Системы в АС 117 хотят достичь сети N автономной системы (АС) 433. АС 654 имеет два маршрута к точке назначения, и она объявила, что лучший из них — через маршрутизатор E. Однако АС 117 имеет внутренне назначенное локальное предпочтение для доступа к сети N через АС 119.

Рис. 8.24. Предпочтительные маршруты

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

Как показано на рис. 8.25, маршрутизаторы BGP в автономных системах 650, 651 и 652 могут отчитаться о своих маршрутах, однако провайдер автономной системы 117 объединил их в один маршрут (элемент таблицы маршрутизации). Этот факт отражается атрибутом Atomic Aggregate.

Рис. 8.25. Объединение маршрутов

Отметим, что автономная система 652 может быть локальным провайдером и объединять маршруты своих клиентов, т.е. от удаленной системы может быть скрыто более одного маршрута. Каждый из объединяющих маршрутизаторов автономной системы будет пересылать трафик к точкам назначения своих клиентов на основе собственной таблицы маршрутизации.

Маршрут исключается, если:

■ Он присутствует в списке изолированных маршрутов из сообщения об изменениях.

■ В изменениях приведен заменяющий маршрут.

■ Система BGP завершает такое соединение. Все маршруты через эту систему становятся недействительными.

Маршрутизация настолько важна, что ей посвящены многие RFC. Несколько наиболее существенных и широко используемых документов перечислены ниже. Следует проверить индекс RFC на наличие более поздних версий.

RIP:

RFC 1058 Routing Information Protocol (протокол информации о маршрутизации)

RFC 1723 RIP Version 2 Carrying Additional Information (RIP, версия 2: перенос дополнительной информации)

RFC 1582 Extensions to RIP to Support Demand Circuits (расширение RIP для поддержки цепей по требованию)

OSPF:

RFC 1583 OSPF Version 2 (OSPF, версия 2)

RFC 1793 Extending OSPF to Support Demand Circuits (расширение OSPF для поддержки цепей по требованию)

RFC 1586 Guidelines for Running OSPF Over Frame Relay Networks (рекомендации по работе с OSPF через сети Frame Relay)

RFC 1584 Multicast Extensions to OSPF (расширение OSPF для многоадресных рассылок)

RFC 1403 BGP OSPF Interaction (взаимодействие BGP и OSPF)

BGP

(в будущем предполагается вытеснение BGP протоколом IDRP для OSI — Inter-Domain Routing Protocol, протокол междоменной маршрутизации):

RFC 1771 A Border Gateway Protocol 4 (BGP-4) (протокол граничного шлюза, версия 4)

RFC 1773 Experience with the BGP-4 Protocol (исследование протокола BGP-4)

RFC 1772 Application of the Border Gateway Protocol in the Internet (Приложения для BGP в Интернете)

Кроме того, можно обратиться к интерактивной документации компании Cisco по адресу www.cisco.com для получения технических данных о протоколах IGRP и EIGRP.

После знакомства с физическим перемещением битов в носителе и маршрутизацией датаграмм в Интернете, настало время рассмотреть службы для приложений, связанные с пересылкой данных. Начнем с протокола пользовательских датаграмм (User Datagram Protocol — UDP). Это достаточно простой протокол, позволяющий приложениям обмениваться отдельными сообщениями.

Для каких целей используются эти службы? Существует множество приложений, построенных совершенно естественным способом поверх UDP. Так можно, например, реализовать простую систему просмотра базы данных. Кроме того, мы уже упоминали о системе DNS, сформированной на основе UDP (см. рис. 9.1).

Рис. 9.1. Вопрос и ответ DNS

Нагрузки по открытию и закрытию соединений при пересылке большого объема сообщений могут быть исключены благодаря передаче простых запросов и ответов. Кроме того, UDP служит прекрасной основой для конструирования средств мониторинга, отладки, обслуживания или тестирования.

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

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

Одним из преимуществ UDP является использование этого протокола для широковещательных и многоадресных рассылок из приложений. Например, широковещательная рассылка клиента BOOTP запрашивает инициализационные параметры.

Что происходит после прибытия данных в хост назначения? Как выполняется их доставка в нужное приложение (процесс)?

На рис. 9.2 видно, что для каждого уровня существует идентификатор протокола, указывающий операции, выполняемые над данными. На втором уровне тип Ethernet X'08-00 в заголовке кадра показывает, что кадр нужно передать в IP. На третьем уровне поле протокола в заголовке IP указывает протокол четвертого уровня, куда нужно переслать данные (например, 6 для TCP или 17 для UDP).

Рис. 9.2. Пересылка данных до уровня приложений

Хост может участвовать одновременно в нескольких коммуникациях. Так как же из общего потока выделяется датаграмма UDP и доставляется на нужный уровень приложения? Такой процесс пересылки данных в требуемый процесс часто называют демультиплексированием. Ответ состоит в том, что каждой конечной коммуникационной точке UDP присвоен 16-разрядный идентификатор, называемый номером порта. Термин "порт" не очень удачен для данного идентификатора. Порт для клиентской и серверной частей приложения не имеет никакого отношения к портам оборудования и физическому пути пересылки данных).

Порты с номерами от 0 до 1023 зарезервированы для стандартных служб. Такие порты называются общеизвестными (well-known). Их использование позволяет клиенту идентифицировать службу, к которой он хочет получить доступ. Например, доступ к DNS (которая основана на UDP) производится через общеизвестный порт 53.

Кто назначает общеизвестные порты? Как не трудно догадаться, этим занимается IANA. Номера портов для определенных приложений регистрируются этой организацией и публикуются в документе RFC Assigned Numbers (присвоенные номера). Сокращенный список портов UDP из текущего документа RFC Assigned Numbers показан в таблице 9.1.

Таблица 9.1 Примеры общеизвестных портов UDP

Служба Порт/протокол Описание Echo 7/udp Посылка отправителю эхо-ответа на пользовательскую датаграмму Discard 9/udp Отмена пользовательской датаграммы Daytime 13/udp Отчет о времени дня в понятном формате Quote 17/udp Возврат сообщения quote of the day — цитата дня Chargen 19/udp Генератор символов Nameserver 53/udp Сервер имен доменов Bootps 67/udp Порт сервера для загрузки конфигурационной информации Bootpc 68/udp Порт клиента для получения конфигурационной информации TFTP 69/udp Порт протокола Trivial File Transfer Protocol SunRPC 111/udp Вызов удаленных процедур (Remote Procedure Call) компании Sun NTP 123/udp Протокол Network Time Protocol SNMP 161/udp Используется для получения сетевых запросов обслуживания SNMP-trap 162/udp Служит для получения отчетов о проблемах в сети

Несколько общеизвестных служб обеспечивает модули для тестирования, отладки и измерений. Например, echo (эхо) с портом 7, соответствуя своему имени, возвращает любую посланную на этот порт датаграмму. Служба Discard (отмена) порта 9, наоборот, удаляет из сети любую посланную на этот порт датаграмму. Character generator (генератор символов) отвечает на любое сообщение датаграммой, содержащей от 0 до 512 байт. Количество байт выбирается случайным образом.