TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
8.17.4 Проблема выбора варианта
Рис. 8.24 показывает различия между Multi-exit Discriminator и Local Preference. Системы в АС 117 хотят достичь сети N автономной системы (АС) 433. АС 654 имеет два маршрута к точке назначения, и она объявила, что лучший из них — через маршрутизатор E. Однако АС 117 имеет внутренне назначенное локальное предпочтение для доступа к сети N через АС 119.
Рис. 8.24.
8.17.5 Применение объединения маршрутов
Целью объединения маршрутов является исключение ненужной информации из удаленных таблиц маршрутизации. Провайдер может объединить маршруты, сведения о которых получены от его клиентской автономной системы.
Как показано на рис. 8.25, маршрутизаторы BGP в автономных системах 650, 651 и 652 могут отчитаться о своих маршрутах, однако провайдер автономной системы 117 объединил их в один маршрут (элемент таблицы маршрутизации). Этот факт отражается атрибутом Atomic Aggregate.
Рис. 8.25. Объединение маршрутов
Отметим, что автономная система 652 может быть локальным провайдером и объединять маршруты своих клиентов, т.е. от удаленной системы может быть скрыто более одного маршрута. Каждый из объединяющих маршрутизаторов автономной системы будет пересылать трафик к точкам назначения своих клиентов на основе собственной таблицы маршрутизации.
8.17.6 Изолированные маршруты BGP
Маршрут исключается, если:
■ Он присутствует в списке изолированных маршрутов из сообщения об изменениях.
■ В изменениях приведен заменяющий маршрут.
■ Система BGP завершает такое соединение. Все маршруты через эту систему становятся недействительными.
8.18 Дополнительная литература
Маршрутизация настолько важна, что ей посвящены многие 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) (протокол
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.
Глава 9
Протокол UDP
9.1 Введение
После знакомства с физическим перемещением битов в носителе и маршрутизацией датаграмм в Интернете, настало время рассмотреть службы для приложений, связанные с пересылкой данных. Начнем с протокола пользовательских датаграмм (User Datagram Protocol — UDP). Это достаточно простой протокол, позволяющий приложениям обмениваться отдельными сообщениями.
Для каких целей используются эти службы? Существует множество приложений, построенных совершенно естественным способом поверх UDP. Так можно, например, реализовать простую систему просмотра базы данных. Кроме того, мы уже упоминали о системе DNS, сформированной на основе UDP (см. рис. 9.1).
Рис. 9.1. Вопрос и ответ DNS
Нагрузки по открытию и закрытию соединений при пересылке большого объема сообщений могут быть исключены благодаря передаче простых запросов и ответов. Кроме того, UDP служит прекрасной основой для конструирования средств мониторинга, отладки, обслуживания или тестирования.
UDP является первичной службой, пересылающей простые отдельные сообщения в IP для последующей передачи по сети. Поскольку IP не обеспечивает надежности пересылки, то нет и гарантий доставки сообщения. Если приложение пытается пересылать свои запросы в датаграммах UDP, но не получает ответов за разумный интервал времени, приложению следует повторно переслать данные.
Иногда это приводит к дублированию запросов на сервере. Если приложение включит в свое сообщение идентификатор транзакции, сервер сможет распознать дублирование и исключить дополнительную копию сообщения. За эти действия ответственно само приложение, а не UDP.
9.1.1 Широковещательные и многоадресные рассылки
Одним из преимуществ UDP является использование этого протокола для широковещательных и многоадресных рассылок из приложений. Например, широковещательная рассылка клиента BOOTP запрашивает инициализационные параметры.
9.2 Порты приложений
Что происходит после прибытия данных в хост назначения? Как выполняется их доставка в нужное приложение (процесс)?
На рис. 9.2 видно, что для каждого уровня существует идентификатор протокола, указывающий операции, выполняемые над данными. На втором уровне тип Ethernet X'08-00 в заголовке кадра показывает, что кадр нужно передать в IP. На третьем уровне поле протокола в заголовке IP указывает протокол четвертого уровня, куда нужно переслать данные (например, 6 для TCP или 17 для UDP).