Протокол обмена управляющими сообщениями ICMP Протоколы обмена маршрутной информацией

Кафедра информационно-коммуникационные технологии

КУРСОВАЯ РАБОТА

«Протокол обмена управляющими сообщениями – ICMP. Протоколы обмена маршрутной информацией»

по дисциплине «Основы построения объединенных сетей»

Введение

Протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol, ICMP), позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми машрутизатор столкнулся при передаче какого-либо IP-пакета от данного конечного узла.

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

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

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

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

 дистанционно-векторный алгоритм (Distance Vector Algorithms, DVA),

 алгоритм состояния связей (Link State Algorithms, LSA).

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

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

Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP.

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

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

Протоколом, основанным на алгоритме состояния связей, в стеке TCP/IP является протокол OSPF.

Протокол BGP разработан компаниями IBM и CISCO. Главная цель BGP – сократить транзитный трафик.

BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации.

Протокол
ICMP

Общая характеристика протокола

Протокол ICMP играет в сети вспомогательную роль. Спецификация этого протокола содержится в RFC 792.

Существует ряд ситуаций, когда протокол IP не может доставить пакет адресату, например, когда истекает время жизни пакета, когда в таблице маршрутизации отсутствует маршрут к заданному в пакете адресу назначения, когда пакет не проходит проверку по контрольной сумме и т.д. Протокол IP не предпринимает средств для гарантированной доставки данных. Это свойство «необязательности» протокола IP компенсируется протоколами более высокого уровня, например TCP на транспортном уровне.

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

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

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

Формат сообщений

Существует несколько типов сообщений ICMP. Каждый тип сообщения имеет свой формат, при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (TYPE), 8-битного поля кода (CODE), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (CHECKSUM). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку. Это делается для того, чтобы узел-отправитель смог более точно проанализировать причину ошибки, так как все протоколы прикладного уровня стека TCP/IP содержат наиболее важную информацию для анализа в первых 64 битах своих сообщений.

Все типы ICMP-сообщений могут быть разделены на 2 класса:

· диагностические сообщения

· информационные сообщения типа запрос / ответ

ICMP-сообщение инкапсулируется в поле данных IP-пакета (рис 1).

ICMP-сообщение

Заголовок ICMP состоит из 8 байт; поля заголовка перечислены ниже:

· Тип
(размером 1 байт) содержит код, определяющий тип сообщения. Основные типы перечислены в таблице 1.

· Код
(размером 1 байт) более тонко дифференцирует тип ошибки.

· Контрольная сумма
, подсчитанная для всего ICMP-сообщения, занимает 2 байта.

Заголовок также включает поле из 4 байт, содержимое которого зависит от значений полей типа и кода. В сообщениях типа запрос / ответ это поле содержит 2-байтовые подполя идентификатора
и порядкового номера
. Числа из этих подполей дублируются из сообщения-запроса в сообщение-ответ. Идентификатор позволяет узлу-получателю сообщения определить, какому приложению направлен этот ответ, а порядковый номер используется приложением, чтобы связать ответ с соответствующим запросом. В сообщениях об ошибке это поле не используется и заполняется нулями.

Таблица 1. Возможные значения поля типа

Значение	Тип сообщения
0	Эхо-ответ (Echo Replay)
3	Узел назначения недостижим (Destination Unreachable)
4	Подавление источника (Source Quench)
5	Перенаправление маршрута (Redirect)
8	Эхо-запрос (Echo Request)
11	Истечение времени дейтаграммы (Time Exceeded for a Datagram)
12	Проблема с параметром пакета (Parameter Problem on a Datagram)
13	Запрос отметки времени (Timestamp Request)
14	Ответ отметки времени (Timestamp Replay)
17	Запрос маски (Address Mask Request)
18	Ответ маски (Address Mask Replay)

Каждый тип ошибки может быть более точно охарактеризован кодом ошибки. Например, в таблице 2 приведены коды для сообщения о недостижимости узла назначения (ошибка типа 3 из табл. 1). Эти коды, которые могут быть указаны в сообщении этого типа, позволяют выделить множество различных причин данной ситуации.

Таблица 2. Коды, детализирующие причину ошибки о недостижимости

Код	Причина
0	Сеть недостижима
1	Узел недостижим
2	Протокол недостижим
3	Порт недостижим
4	Требуется фрагментация, а бит DF установлен
5	Ошибка в маршруте, заданном источником
6	Сеть назначения неизвестна
7	Узел назначения неизвестен
8	Узел-источник изолирован
9	Взаимодействие с сетью назначения административно запрещено
10	Взаимодействие с узлом назначения административно запрещено
11	Сеть недостижима для заданного класса сервиса
12	Узел недостижим для заданного класса сервиса

Маршрутизатор, обнаруживший по какой-либо причине, что он не может передать IP-пакет далее по сети, должен отправить ICMP-сообщение узлу-источнику, и только потом отбросить пакет. Кроме причины ошибки, ICMP-сообщение включает также заголовок недоставленного пакета и его первые 64 бита поля данных.

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

Недостижимость протокола и порта означают отсутствие реализации какого-либо протокола прикладного уровня в узле назначения или же отсутствие открытого порта протоколов UDP или TCP в узле назначения.

Ошибка фрагментации возникает тогда, когда отправитель послал в сеть пакет с признаком DF, запрещающим фрагментацию, а маршрутизатор столкнулся с необходимостью передачи этого пакета в сеть со значением MTU меньшим, чем размер пакета.

Перенаправление маршрута

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

Для корректировки поведения компьютеров маршрутизатор может использовать сообщение протокола ICMP, называемое «Перенаправление маршрута» (Redirect).

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

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

В сообщении «Перенаправление маршрута» маршрутизатор помещает IP-адрес маршрутизатора, которым нужно пользоваться в дальнейшем, и заголовок исходного пакета с первыми 64 битами его поля данных. Из заголовка пакета узел узнает, для какой сети необходимо пользоваться указанным маршрутизатором.

Пример:

Предположим, таблица маршрутов в начале выглядит следующим образом:

Таблица 3.

Таблица маршрутов в начале работы.
Адрес назначения	Вид маршрутизации	Шлюз	Интерфейс
127. 0. 0	прямая	пусто	lo0
128. 6. 4	прямая	пусто	pe1
default	косвенная	128. 6. 4. 27	pe0

Эта таблица содержит запись о локальной IP-сети 128.6.4 и маршрут по умолчанию, указывающий шлюз 128.6.4.27. Допустим, что существует шлюз 128.6.4.30, который является лучшим путем доступа к IP-сети 128.6.7.

Предположим, что нужно посылать IP-пакеты по IP – адресу 128.6.7.23. Первый IP-пакет пойдет на шлюз по умолчанию, так как это единственный подходящий маршрут, описанный в таблице. Однако шлюз 128.6.4.27 знает, что существует лучший маршрут, проходящий через шлюз 128.6.4.30. В этом случае шлюз 128.6.4.27 возвращает сообщение перенаправления, где указывает, что IP-пакеты для узла 128.6.7.23 должны посылаться через шлюз 128.6.4.30.

Модуль IP на машине-отправителе должен добавить запись в таблицу маршрутов:

Таблица 4.

Новая запись в таблице маршрутов.
Адрес назначения	Вид маршрутизации	Шлюз	Интерфейс
128. 6. 7. 23	косвенная	128. 6. 4. 30	pe0

Все последующие IP-пакеты для узла 128.6.7.23 будут посланы прямо через указанный шлюз.

Анализ применимости протокола
ICMP при переходе с набора протоколов IP v4 на набор IP v6

На первый взгляд, новый протокол обладает рядом существенных преимуществ перед IPv4. Однако до сих пор скорость его внедрения продолжает оставаться низкой. По данным Форума IPv6, только семь из 21 крупнейших интернет-провайдеров предпринимают шаги, необходимые для полноценного перехода к использованию новой технологии.

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

В спецификации RFC 1726 представлен набор функций, основными среди них являются:

· масштабируемость: идентификация и определение адресов как минимум 1012
конечных систем и 109
индивидуальных сетей;

· топологическая гибкость: архитектура маршрутизации и протокол должны работать в сетях с различной топологией;

· преемственность: обеспечение чёткого плана перехода от существующей версии IPv4;

· независимость от среды передачи: работа среди множества сетей с различными средами передачи данных со скоростями до сотен гигабит в секунду;

· автоматическое конфигурирование хостов и маршрутизаторов;

· безопасность на сетевом уровне;

· мобильность: обеспечение работы с мобильными пользователями, сетями и межсетевыми системами;

· расширяемость: возможность дальнейшего развития в соответствии с новыми потребностями.

В результате реализации заявленных функций важнейшие инновации IPv6 состоят в следующем:

· упрощен стандартный заголовок IP-пакета;

· изменено представление необязательных полей заголовка;

· расширено адресное пространство;

· улучшена поддержка иерархической адресации, агрегирования маршрутов и автоматического конфигурирования адресов;

· введены механизмы аутентификации и шифрования на уровне IP-пакетов;

· введены метки потоков данных.

Протокол IP v6 предполагает также значительные улучшения при работе в локальной сети. Единый протокол NDP (Neighbor Discovery Protocol – протокол распознавания соседей) заменяет применяемые в IP v4 протоколы ARP, ICMP и значительно расширяет их функциональные возможности. Вместо использующихся в протоколе ARP широковещательных пакетов канального уровня используются групповые сообщения (multicast), то есть адресованные всем членам подсети, притом, не на канальном, а на сетевом уровне, что должно значительно снизить широковещательный трафик, являющийся бичом локальных сетей Ethernet. Усовершенствованы функции протокола ICMP, облегчая работу разных подсетей в одном физическом сегменте. Включен механизм распознавания неисправных маршрутизаторов, что позволяет повысить устойчивость к сбоям оборудования.

IPv6 и DNS

Еще одна проблема, связанная с внедрением IPv6, – ее несовместимость с DNS, которая используется сегодня в Интернете. Существование DNS (Domain Name System) избавляет рядового пользователя от необходимости задумываться о числовых IP-адресах. Она позволяет присваивать любому IP-адресу символьное имя (домен). Преобразование символьного имени в числовое и наоборот осуществляется DNS-серверами. На них содержится информация о каждом домене. Она представлена в виде ресурсных записей, каждая из которых принадлежит конкретному доменному имени и содержит ряд сведений о нем, в том числе его IP-адрес. До начала внедрения IPv6 существовало 20 типов таких записей. Они относились к 32-разрядным IP-адресам (так называемые записи «A»), что делало DNS и IPv6 несовместимыми.

Однако затем был определен новый тип ресурсной записи «AAAA», который служит для хранения 128-битного IPv6-адреса. Сам адрес определен в информационной части этой записи и в виде имени представляется в специально созданном домене ip6.int. Это имя выглядит как набор символов, разделенных точками, и заканчивается суффиксом ip6.int.

Клиент, направляющий с устройства запросы на DNS-сервер, должен уметь распознавать записи как об адресах IPv4, так и об адресах IPv6. Получив запрос, DNS-сервер определяет тип ресурсной записи (A или AAAA) и отправляет ее устройству. Распознав запись, устройство выбирает для передачи данных либо протокол IPv4, либо протокол IPv6.

При этом, когда IPv4-совместимый адрес назначается какому-либо узлу, в DNS создается две ресурсных записи: AAAA и A. Первая отображает этот адрес в 128-битном формате, а вторая – в 32-битном. Это позволяет устройствам, использующим только протокол IPv6, получать IPv6-адреса, а узлам, работающим только на IPv4 – IPv4 адреса.

Одним словом, для полной совместимости с IPv6 DNS требует серьезной перестройки.

Внедрение набора протоколов

IP

v

6 и его преимущества перед

IP

v

4

При рассмотрении возможностей, предоставляемые новым протоколом, может возникнуть вопрос, а зачем он все-таки нужен? Большинство функций либо уже имеются в IP v4, либо могут быть реализованы путем доработки соответствующих протоколов. Так, автоматическое выделение адресов производится при помощи протокола DHCP, адресный барьер преодолевается при помощи протокола NAT и т.д. и т.п. Однако разработка всех необходимых заплаток для протокола IP v4 потребовала бы затраты не меньших (а то и больших) усилий, чем создание нового протокола «с чистого листа». Разумеется, лист был не совсем чистым, поскольку вопросы совместимости и совместной работы обоих протоколов имелись в виду с самого начала проектирования. В конце концов Интернет все равно пришла бы к кризису дефицита адресов, так что заблаговременная разработка и постепенное внедрение протокола IP v6 были более чем уместны.

Для реализации перехода на новый протокол образовалась неформальная некоммерческая организация 6bone, включающая в себя более 100 организаций, в основном, сетевых провайдеров и университетов. Главная задача организации – создание инфраструктуры, позволяющей транспортировку пакетов стандарта IP v6 по всей сети Интернет. Как и существующая сегодня инфраструктура IP v4, она будет состоять из большого количества провайдеров и локальных сетей, объединенных в единую Сеть. В настоящее время в состав 6bone входят представители 41 страны, от США, Англии и Японии и до Камеруна и Казахстана.

Необходимость создания такой инфраструктуры объясняется прежде всего тем, что без широкомасштабного тестирования и готовой инфраструктуры (или ее подобия) коммерческие провайдеры (и потребители, занимающиеся, в отличие от университетов, не исследованиями, а бизнесом) вряд ли будут охотно внедрять новый протокол. Таким образом, задачей сети 6bone не является организация параллельной инфраструктуры, а скорее тестирование и отработка методик взаимодействия клиент-провайдер.

Итоги:

1. Базовый набор протоколов IP v6 охватывает функции набора протоколов IP v4

2. Базовый набор протоколов IP v6 расширяет функции набора протоколов IP v4 (в том числе ICMP, которые охватывается единым протоколом NDP).

3. Тестирование и внедрение IP v6 требует значительных усилий и затрат.

Протоколы обмена маршрутной информацией

Общая характеристика протоколов обмена маршрутной информацией

 дистанционно-векторный алгоритм (Distance Vector Algorithms, DVA),

 алгоритм состояния связей (Link State Algorithms, LSA).

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

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

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

Протоколом, основанным на алгоритме состояния связей, в стеке TCP/IP является протокол OSPF.

Дистанционно-векторный протокол RIP

Протокол RIP (Routing Information Protocol) маршрутизации предназначен для сравнительно небольших и относительно однородных сетей (алгоритм Белмана-Форда). Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фирмы Ксерокс и реализует те же принципы, что и программа маршрутизации routed, используемая в ОC UNIX (4BSD). Маршрут здесь характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан.

Протокол RIP представляет собой один из старейших протоколов обмена маршрутной информацией, однако он до сих пор чрезвычайно распространен в вычислительных сетях. Помимо версии RIP для сетей TCP/IP, существует также версия RIP для сетей IPX/SPX компании Novell.

В этом протоколе все сети имеют номера (способ образования номера зависит от используемого в сети протокола сетевого уровня), а все маршрутизаторы – идентификаторы. Протокол RIP широко использует понятие «вектор расстояний». Вектор расстояний представляет собой набор пар чисел, являющихся номерами сетей и расстояниями до них в хопах.

Описания этих маршрутов хранится в специальной таблице, называемой маршрутной. Таблица маршрутизации RIP содержит по записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя:

· IP-адрес места назначения.

· Метрика маршрута (от 1 до 15; число шагов до места назначения).

· IP-адрес ближайшего маршрутизатора (gateway) по пути к месту назначения.

· Таймеры маршрута.

Первым двум полям записи мы обязаны появлению термина вектор расстояния
(место назначение – направление; метрика – модуль вектора). Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте, или произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице. Протокол RIP должен быть способен обрабатывать три типа ошибок:

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

Для подавления нестабильностей RIP должен использовать малое значение максимально возможного числа шагов (<16).

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

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

В RIP сообщения инкапсулируются в udp-дейтограммы, при этом передача осуществляется через порт 520. В качестве метрики RIP использует число шагов до цели. Если между отправителем и приемником расположено три маршрутизатора (gateway), считается, что между ними 4 шага. Такой вид метрики не учитывает различий в пропускной способности или загруженности отдельных сегментов сети. Применение вектора расстояния не может гарантировать оптимальность выбора маршрута, ведь, например, два шага по сегментам сети ethernet обеспечат большую пропускную способность, чем один шаг через последовательный канал на основе интерфейса RS-232.

Маршрут по умолчанию имеет адрес 0.0.0.0 (это верно и для других протоколов маршрутизации). Каждому маршруту ставится в соответствие таймер тайм-аута и «сборщика мусора». Тайм-аут-таймер сбрасывается каждый раз, когда маршрут инициализируется или корректируется. Если со времени последней коррекции прошло 3 минуты или получено сообщение о том, что вектор расстояния равен 16, маршрут считается закрытым. Но запись о нем не стирается, пока не истечет время «уборки мусора» (2 мин). При появлении эквивалентного маршрута переключения на него не происходит, таким образом, блокируется возможность осцилляции между двумя или более равноценными маршрутами. Формат сообщения протокола RIP имеет вид, показанный на рис. 4.4.11.2. Поле команда определяет выбор согласно следующей таблице:

Таблица 5. Значения кодов поля команда

Команда	Значение
1	Запрос на получение частичной или полной маршрутной информации;
2	Отклик, содержащий информацию о расстояниях из маршрутной таблицы отправителя;
3	Включение режима трассировки (устарело);
4	Выключение режима трассировки (устарело);
5–6	Зарезервированы для внутренних целей sun microsystem.

Поле версия для RIP равно 1 (для RIP-2 двум). Поле набор протоколов сети i определяет набор протоколов, которые используются в соответствующей сети (для Интернет это поле имеет значение 2). Поле расстояние до сети i содержит целое число шагов (от 1 до 15) до данной сети. В одном сообщении может присутствовать информация о 25 маршрутах. При реализации RIP можно выделить следующие режимы:

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

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

Получен отклик. Проводится коррекция таблицы маршрутизации (удаление, исправление, добавление).

Рис. 2. Формат сообщения RIP.

Протокол состояния связей OSPF

Протокол OSPF (Open Shortest Path Firs)
является достаточно современной реализацией алгоритма состояния связей (он принят в 1991 году) и обладает многими особенностями, ориентированными на применение в больших гетерогенных сетях.

Протокол OSPF вычисляет маршруты в IP-сетях, сохраняя при этом другие протоколы обмена маршрутной информацией.

Непосредственно связанные (то есть достижимые без использования промежуточных маршрутизаторов) маршрутизаторы называются «соседями». Каждый маршрутизатор хранит информацию о том, в каком состоянии по его мнению находится сосед. Маршрутизатор полагается на соседние маршрутизаторы и передает им пакеты данных только в том случае, если он уверен, что они полностью работоспособны. Для выяснения состояния связей маршрутизаторы-соседи достаточно часто обмениваются короткими сообщениями HELLO.

Для распространения по сети данных о состоянии связей, маршрутизаторы обмениваются сообщениями другого типа. Эти сообщения называются router links advertisement
– объявление о связях маршрутизатора (точнее, о состоянии связей). OSPF-маршрутизаторы обмениваются не только своими, но и чужими объявлениями о связях, получая в конце-концов информацию о состоянии всех связей сети. Эта информация и образует граф связей сети, который, естественно, один и тот же для всех маршрутизаторов сети.

Кроме информации о соседях, маршрутизатор в своем объявлении перечисляет IP-подсети, с которыми он связан непосредственно, поэтому после получения информации о графе связей сети, вычисление маршрута до каждой сети производится непосредственно по этому графу по алгоритму Дэйкстры. Более точно, маршрутизатор вычисляет путь не до конкретной сети, а до маршрутизатора, к которому эта сеть подключена. Каждый маршрутизатор имеет уникальный идентификатор, который передается в объявлении о состояниях связей. Такой подход дает возможность не тратить IP-адреса на связи типа «точка-точка» между маршрутизаторами, к которым не подключены рабочие станции.

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

Описанный подход приводит к результату, который не может быть достигнут при использовании протокола RIP или других дистанционно-векторных алгоритмов. RIP предполагает, что все подсети определенной IP-сети имеют один и тот же размер, то есть, что все они могут потенциально иметь одинаковое число IP-узлов, адреса которых не перекрываются. Более того, классическая реализация RIP требует, чтобы выделенные линии «точка-точка» имели IP-адрес, что приводит к дополнительным затратам IP-адресов.

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

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

Например, если рабочая группа ответвляется от главной сети, то она имеет адрес главной сети наряду с более специфическим адресом, определяемым маской подсети. При выборе маршрута к хосту в подсети этой рабочей группы маршрутизатор найдет два пути, один для главной сети и один для рабочей группы. Так как последний более специфичен, то он и будет выбран. Этот механизм является обобщением понятия «маршрут по умолчанию», используемого во многих сетях.

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

В протоколе OSPF подсети делятся на три категории:

 «хост-сеть», представляющая собой подсеть из одного адреса,

 «тупиковая сеть», которая представляет собой подсеть, подключенную только к одному маршрутизатору,

 «транзитная сеть», которая представляет собой подсеть, подключенную к более чем одному маршрутизатору.

Транзитная сеть является для протокола OSPF особым случаем. В транзитной сети несколько маршрутизаторов являются взаимно и одновременно достижимыми. В широковещательных локальных сетях, таких как Ethernet или Token Ring, маршрутизатор может послать одно сообщение, которое получат все его соседи. Это уменьшает нагрузку на маршрутизатор, когда он посылает сообщения для определения существования связи или обновленные объявления о соседях. Однако, если каждый маршрутизатор будет перечислять всех своих соседей в своих объявлениях о соседях, то объявления займут много места в памяти маршрутизатора. При определении пути по адресам транзитной подсети может обнаружиться много избыточных маршрутов к различным маршрутизаторам. На вычисление, проверку и отбраковку этих маршрутов уйдет много времени.

Когда маршрутизатор начинает работать в первый раз (то есть инсталлируется), он пытается синхронизировать свою базу данных со всеми маршрутизаторами транзитной локальной сети, которые по определению имеют идентичные базы данных. Для упрощения и оптимизации этого процесса в протоколе OSPF используется понятие «выделенного» маршрутизатора, который выполняет две функции.

Во-первых, выделенный маршрутизатор и его резервный «напарник» являются единственными маршрутизаторами, с которыми новый маршрутизатор будет синхронизировать свою базу. Синхронизировав базу с выделенным маршрутизатором, новый маршрутизатор будет синхронизирован со всеми маршрутизаторами данной локальной сети.

Во-вторых, выделенный маршрутизатор делает объявление о сетевых связях,
перечисляя своих соседей по подсети. Другие маршрутизаторы просто объявляют о своей связи с выделенным маршрутизатором. Это делает объявления о связях (которых много) более краткими, размером с объявление о связях отдельной сети.

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

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

Интерфейсы, к которым подключены локальные сети, называются широковещательными (broadcast) интерфейсами,
так как они могут использовать широковещательные возможности локальных сетей для обмена сигнальной информацией между маршрутизаторами. Интерфейсы, к которым подключены глобальные сети, не поддерживающие широковещание, но обеспечивающие доступ ко многим узлам через одну точку входа, например сети Х.25 или frame relay, называются нешироковещательными интерфейсами с множественным доступом или NBMA (non-broadcast multi-access).
Они рассматриваются аналогично широковещательным интерфейсам за исключением того, что широковещательная рассылка эмулируется путем посылки сообщения каждому соседу. Так как обнаружение соседей не является автоматическим, как в широковещательных сетях, NBMA-соседи должны задаваться при конфигурировании вручную. Как на широковещательных, так и на NBMA-интерфейсах могут быть заданы приоритеты маршрутизаторов для того, чтобы они могли выбрать выделенный маршрутизатор.

Интерфейсы «точка-точка», подобные PPP, несколько отличаются от традиционной IP-модели. Хотя они и могут иметь IP-адреса и подмаски, но необходимости в этом нет.

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

Число, используемое в качестве метрики пути, может быть назначено произвольным образом по желанию администратора. Но по умолчанию в качестве метрики используется время передачи бита в 10-ти наносекундных единицах (10 Мб/с Ethernet'у назначается значение 10, а линии 56 Кб/с – число 1785). Вычисляемая протоколом OSPF метрика пути представляет собой сумму метрик всех проходимых в пути связей; это очень грубая оценка задержки пути. Если маршрутизатор обнаруживает более, чем один путь к удаленной подсети, то он использует путь с наименьшей стоимостью пути.

В протоколе OSPF используется несколько временных параметров, и среди них наиболее важными являются интервал сообщения HELLO и интервал отказа маршрутизатора
(router dead interval).

HELLO – это сообщение, которым обмениваются соседние, то есть непосредственно связанные маршрутизаторы подсети, с целью установить состояние линии связи и состояние маршрутизатора-соседа. В сообщении HELLO маршрутизатор передает свои рабочие параметры и говорит о том, кого он рассматривает в качестве своих ближайших соседей. Маршрутизаторы с разными рабочими параметрами игнорируют сообщения HELLO друг друга, поэтому неверно сконфигурированные маршрутизаторы не будут влиять на работу сети. Каждый маршрутизатор шлет сообщение HELLO каждому своему соседу по крайней мере один раз на протяжении интервала HELLO. Если интервал отказа маршрутизатора истекает без получения сообщения HELLO от соседа, то считается, что сосед неработоспособен, и распространяется новое объявление о сетевых связях, чтобы в сети произошел пересчет маршрутов.

Протокол
BGP

Протокол BGP разработан компаниями IBM и CISCO. Главная цель BGP – сократить транзитный трафик.

Задача внешней маршрутизации

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

Рассматриваемый на этом уровне, Интернет представляет собой множество автономных систем, произвольным образом соединенных между собой (рис. 3). Внутреннее строение автономных систем скрыто, известны только адреса IP-сетей, составляющих АС.

Рис. 3. Автономные системы

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

зных автономных систем, выделенный канал типа «точка-точка» между двумя маршрутизаторами и т.п. Часто сама связующая сеть не принадлежит ни к одной автономной системе, в таком случае она называется демилитаризованной зоной (DMZ).

В зависимости от своего расположения в общей структуре Интернет автономная система может быть тупиковой (stub) – имеющей связь только с одной АС (АС7 на рис. 7.1.1), – или многопортовой (multihomed), т.е. имеющей связи с несколькими АС. Если административная политика автономной системы позволяет передавать через свои сети транзитный трафик других АС, то такую автономную систему можно назвать транзитной (transit).

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

Задачей этого пункта является обсуждение протокола обмена маршрутной информацией между пограничными маршрутизаторами.

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

Например, рассмотрим систему маршрутизаторов, аналогичную графу автономных систем, изображенному на рис. 7.1.1. Алгоритм SPF гарантирует, что если узел (1) вычислил маршрут в узел (6) как (1) – (3) – (5) – (6), то узел (3) также будет использовать маршрут (3) – (5) – (6). Это происходит потому, что все узлы одинаково интерпретируют метрики связей и используют одни и те же математические процедуры для вычисления маршрутов. Однако если применять протокол состояния связей на уровне автономных систем может произойти следующее: АС1 установила, что оптимальный маршрут по соображениям пропускной способности сетей в АС6 выглядит 1–3–5–6. Но АС3 считает, что выгодней добираться в АС6 по маршруту 3–1–2–4–6, так как АС5 дорого берет за передачу транзитного трафика. В итоге, из-за того, что у каждой АС свое понятие метрики, то есть качества маршрута, происходит зацикливание.

Казалось бы, дистанционно-векторный подход мог бы решить проблему: АС3, не желающая использовать АС5 для транзита в АС6, просто не прислала бы в АС1 элемент вектора расстояний для АС6, следовательно первая система никогда не узнала бы о маршруте 1–3–5–6. Но с другой стороны при использовании дистанционно-векторного подхода получателю вектора расстояний неизвестно описание маршрута на всей его протяженности. Рассмотрим другую политическую ситуацию на примере того же рис. 7.1.1: АС1 получает от АС3 вектор АС6=2 и направляет свой трафик в АС6 через АС3, не подозревая, что на этом маршруте располагается АС5, которая находится с АС1 в состоянии войны и, естественно, не пропускает транзитный трафик от и для АС1. В результате АС1, установив внешне безобидный маршрут в АС6, осталась без связи с этой автономной системой. Если бы АС1 получила полное описание маршрута, то она несомненно бы выбрала альтернативный вариант 1–2–4–6, однако в дистанционно-векторных протоколах такая информация не передается.

Для решения задачи внешней маршрутизации был разработан протокол BGP (Border Gateway Protocol). Используемая в настоящий момент версия этого протокола имеет номер 4, соответствующий стандарт – RFC-1771, 1772.

Общая схема работы BGP такова. BGP-маршрутизаторы соседних АС, решившие обмениваться маршрутной информацией, устанавливают между собой соединения по протоколу BGP и становятся BGP-соседями (BGP-peers).

Далее BGP использует подход под названием path vector, являющийся развитием дистанционно-векторного подхода. BGP-соседи рассылают (анонсируют, advertise) друг другу векторы путей (path vectors). Вектор путей, в отличие от вектора расстояний, содержит не просто адрес сети и расстояние до нее, а адрес сети и список атрибутов (path attributes), описывающих различные характеристики маршрута от маршрутизатора-отправителя в указанную сеть. В дальнейшем для краткости мы будем называть набор данных, состоящих из адреса сети и атрибутов пути до этой сети, маршрутом в данную сеть.

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

Например, наиболее важным атрибутом маршрута является AS_PATH – список номеров автономных систем, через которые должна пройти дейтаграмма на пути в указанную сеть. Атрибут AS_PATH можно использовать для:

обнаружения циклов – если номер одной и той же АС встречается в AS_PATH дважды;

вычисления метрики маршрута – метрикой в данном случае является число АС, которые нужно пересечь;

применения маршрутной политики – если AS_PATH содержит номера политически неприемлемых АС, то данный маршрут исключается из рассмотрения.

Анонсируя какой-нибудь маршрут, BGP-маршрутизатор добавляет в AS_PATH номер своей автономной системы.

Внутренний BGP, маршрутные серверы и атрибут NEXT_HOP

Очевидно, что BGP-маршрутизаторы, находящиеся в одной АС, также должны обмениваться между собой маршрутной информацией. Это необходимо для согласованного отбора внешних маршрутов в соответствии с политикой данной АС и для передачи транзитных маршрутов через автономную систему. Такой обмен производится также по протоколу BGP, который в этом случае часто называется IBGP (Internal BGP), (соответственно, протокол обмена маршрутами между маршрутзаторами разных АС обозначается EBGP – External BGP).

Отличие IBGP от EBGP состоит в том, что при объявлении маршрута BGP-соседу, находящемуся в той же самой АС, маршрутизатор не должен добавлять в AS_PATH номер своей автономной системы. Действительно, если номер АС будет добавлен, и сосед анонсирует этот маршрут далее (опять с добавлением номера той же АС), то одна и та же АС будет перечислена AS_PATH дважды, что расценивается как цикл.

Это очевидное правило влечет за собой интересное следствие: чтобы не возникло циклов, маршрутизатор не может анонсировать по IBGP маршрут, полученный также по IBGP, поскольку нет способов определить зацикливание при объявлении BGP-маршрутов внутри одной АС.

Следствием этого следствия является необходимость полного графа IBGP-соединений между пограничными маршрутизаторами одной автономной системы: то есть каждая пара маршрутизаторов должна устанавливать между собой соединение по протоколу IBGP. При этом возникает проблема большого числа соединений (порядка N2, где N-число BGP-маршрутизаторов в АС). Для уменьшения числа соединений применяются различные решения: разбиение АС на конфедерации (подсистемы), применение серверов маршрутной информации и др.

Сервер маршрутной информации (аналог выделенного маршрутизатора в OSPF), обслуживающий группу BGP-маршрутизаторов, работает очень просто: он принимает маршрут от одного участника группы и рассылает его всем остальным. Таким образом, участникам группы нет необходимости устанавливать BGP-соединения попарно; вместо этого каждый участник устанавливает одно соединение с сервером. Группой маршрутизаторов могут быть, например, все BGP-маршрутизаторы данной АС, однако маршрутные серверы могут применяться для уменьшения числа соединений также и на внешних BGP-соединениях – в случае, когда в одной физической сети находится много BGP-маршрутизаторов из различных АС (например, в точке обмена трафиком между провайдерами, рис. 4).

Рис. 4. Точка обмена трафиком (Internet Exchange Point)

A-E – пограничные BGP-маршрутизаторы, АС1-АС5 – сети автономных систем, RS – сервер маршрутной информации.

Следует особо отметить, что сервер маршрутной информации обслуживает только анонсы маршрутов, а не сам трафик по этим маршрутам. Например (рис 7.2.1), маршрутизатор А анонсирует серверу RS маршруты в сети АС1. Маршрутизатор E получает информацию об этих маршрутах от сервера RS, но при этом в таблице маршрутов узла Е следующим маршрутизатором на пути в АС1 значится узел А, что абсолютно разумно, поскольку эти узлы могут передавать данные друг другу непосредственно. Исключение маршрутного сервера из маршрута производится путем установки значения атрибута NEXT_HOP: анонсируя маршруты в сеть АС1, сервер RS указывает NEXT_HOP=A. Таким образом, маршрутизатор (например, Е), получивший и принявший к использованию такой маршрут, будет пересылать данные, предназначенные для АС1, непосредственно маршрутизатору А.

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

Во-вторых, очевидно, что сервер маршрутной информации не является маршрутизатором. То есть в общем случае узел, на котором работает модуль BGP, – не обязательно маршрутизатор. В технических документах этот факт подчеркивается тем, что для обозначения BGP-узла используется термин BGP-speaker (не router).

Атрибуты пути (Path Attributes)

Ниже перечислены все атрибуты пути, определенные для протокола BGP.

ORIGIN

ORIGIN
(тип 1) – обязательный атрибут, указывающий источник информации о маршруте:

0 – IGP (информация о достижимости сети получена от протокола внутренней маршрутизации или введена администратором),

1 – EGP (информация о достижимости сети импортирована из устаревшего протокола EGP),

2 – INCOMPLETE (информация получена другим образом, например, RIP->OSPF->BGP или BGP->OSPF->BGP).

Атрибут ORIGIN вставляется маршрутизатором, который генерирует информацию о маршруте, и при последующем анонсировании маршрута другими маршрутизаторами не изменяется. Атрибут фактически определяет надежность источника информации о маршруте (наиболее надежный ORIGIN=0).

AS_PATH

AS_PATH
(тип 2) – обязательный атрибут, содержащий список автономных систем, через которые должна пройти дейтаграмма на пути в указанную в маршруте сеть. AS_PATH представляет собой чередование сегментов двух типов: AS_SEQUENCE – упорядоченный список АС, и AS_SET – множество АС (последнее может возникнуть при агрегировании нескольких маршрутов со схожими, но не одинаковыми AS_PATH в один общий маршрут).

Каждый BGP-узел при анонсировании маршрута (за исключением IBGP-соединений) добавляет в AS_PATH номер своей АС. Возможно (в зависимости от политики) дополнительно добавляются номера других АС.

NEXT_HOP

NEXT_HOP
(тип 3) – обязательный атрибут, указывающий адрес следующего BGP-маршрутизатора на пути в заявленную сеть (см. обсуждение в п. 7.2); может совпадать или не совпадать с адресом BGP-узла, анонсирующего маршрут. Указанный в NEXT_HOP маршрутизатор должен быть достижим для получателя данного маршрута. При передаче маршрута по IBGP NEXT_HOP не меняется.

MULTI_EXIT_DISC

MULTI_EXIT_DISC
(тип 4) – необязательный атрибут, представляющий собой приоритет использования объявляющего маршрутизатора для достижения через него анонсируемой сети, то есть фактически это метрика маршрута с точки зрения анонсирующего маршрут BGP-узла. Имеет смысл не само значение а разница значений, когда несколько маршрутизаторов одной АС объявляют о достижимости через себя одной и той же сети, предоставляя таким образом получателям несколько вариантов маршрутов в одну сеть. При прочих равных условиях
дейтаграммы в объявляемую сеть будут посылаться через маршрутизатор, заявивший меньшее значение MULTI_EXIT_DISC.

Атрибут сохраняется при последующих объявлениях маршрута по IBGP, но не по EBGP.

LOCAL_PREF

LOCAL_PREF
(тип 5) – необязательный атрибут, устанавливающий для данной АС приоритет данного маршрута среди всех маршрутов к заявленной сети, известных внутри АС. Атрибут вычисляется каждым пограничным маршрутизатором для каждого присланного ему по EBGP маршрута и потом распространяется вместе с этим маршрутом по IBGP в пределах данной АС. Способ вычисления значения атрибута определяется политикой приема маршрутов (по умолчанию берется во внимание только длина AS_PATH). LOCAL_PREF используется для согласованного между маршрутизаторами одной АС выбора маршрута из нескольких вариантов.

Атрибуты агрегирования

ATOMIC_AGGREGATE
(тип 6) и AGGREGATOR
(тип 7) – необязательные атрибуты, связанные с операциями агрегирования (объединения) нескольких маршрутов в один.

Примеры маршрутизации

Пример маршрутизации по алгоритму
RIP

На рисунке 3 приведен пример сети, состоящей из шести маршрутизаторов, имеющих идентификаторы от 1 до 6, и из шести сетей от A до F, образованных прямыми связями типа «точка-точка».

Рисунок 3. Обмен маршрутной информацией по протоколу RIP

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

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

Для адаптации к изменению состояния связей и оборудования с каждой записью таблицы маршрутизации связан таймер. Если за время тайм-аута не придет новое сообщение, подтверждающее этот маршрут, то он удаляется из маршрутной таблицы.

При использовании протокола RIP работает эвристический алгоритм динамического программирования Беллмана-Форда, и решение, найденное с его помощью является не оптимальным, а близким к оптимальному. Преимуществом протокола RIP является его вычислительная простота, а недостатками – увеличение трафика при периодической рассылке широковещательных пакетов и неоптимальность найденного маршрута.

На рисунке 4 показан случай неустойчивой работы сети по протоколу RIP при изменении конфигурации – отказе линии связи маршрутизатора M1 с сетью 1. При работоспособном состоянии этой связи в таблице маршрутов каждого маршрутизатора есть запись о сети с номером 1 и соответствующим расстоянием до нее.

Рисунок 4. Пример неустойчивой работы сети при использовании протокола RIP

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

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

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

Пример маршрутизации по алгоритму OSPF

Представим себе один день из жизни транзитной локальной сети. Пусть у нас имеется сеть Ethernet, в которой есть три маршрутизатора – Джон, Фред и Роб (имена членов рабочей группы Internet, разработавшей протокол OSPF). Эти маршрутизаторы связаны с сетями в других городах с помощью выделенных линий.

Пусть произошло восстановление сетевого питания после сбоя. Маршрутизаторы и компьютеры перезагружаются и начинают работать по сети Ethernet. После того, как маршрутизаторы обнаруживают, что порты Ethernet работают нормально, они начинают генерировать сообщения HELLO, которые говорят о их присутствии в сети и их конфигурации. Однако маршрутизация пакетов начинает осуществляться не сразу – сначала маршрутизаторы должны синхронизировать свои маршрутные базы (рисунок 5).

Рисунок 5. Гипотетическая сеть с OSPF маршрутизаторами

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

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

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

Базы данных теперь синхронизированы с выделенным маршрутизатором, которым является Джон. Джон суммирует свою базу данных с каждой базой данных своих соседей – базами Фреда, Роба и Джеффа – индивидуально. В каждой синхронизирующейся паре объявления, найденные только в какой-либо одной базе, копируются в другую. Выделенный маршрутизатор, Джон, распространяет новые объявления среди других маршрутизаторов своей локальной сети. Например, объявления Мило и Робина передаются Джону Робом, а Джон в свою очередь передает их Фреду и Джеффри. Обмен информацией между базами продолжается некоторое время, и пока он не завершится, маршрутизаторы не будут считать себя работоспособными. После этого они себя таковыми считают, потому что имеют всю доступную информацию о сети.

Посмотрим теперь, как Робин вычисляет маршрут через сеть. Две из связей, присоединенных к его портам, представляют линии T-1, а одна – линию 56 Кб/c. Робин сначала обнаруживает двух соседей – Роба с метрикой 65 и Мило с метрикой 1785. Из объявления о связях Роба Робин обнаружил наилучший путь к Мило со стоимостью 130, поэтому он отверг непосредственный путь к Мило, поскольку он связан с большей задержкой, так как проходит через линии с меньшей пропускной способностью. Робин также обнаруживает транзитную локальную сеть с выделенным маршрутизатором Джоном. Из объявлений о связях Джона Робин узнает о пути к Фреду и, наконец, узнает о пути к маршрутизаторам Келли и Джеффу и к их тупиковым сетям.

После того, как маршрутизаторы полностью входят в рабочий режим, интенсивность обмена сообщениями резко падает. Обычно они посылают сообщение HELLO по своим подсетям каждые 10 секунд и делают объявления о состоянии связей каждые 30 минут (если обнаруживаются изменения в состоянии связей, то объявление передается, естественно, немедленно). Обновленные объявления о связях служат гарантией того, что маршрутизатор работает в сети. Старые объявления удаляются из базы через определенное время.

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

Практический пример работы с
BGP-сетью

Имеем следующую BGP-сеть

Рисунок 6.

Если AS связана с двумя ISP через EBGP, IBGP должен использоваться между роутерами внутри данной AS для лучшего управления маршрутами.

Рассмотрим AS100, имеющую два EBGP соединения (роутеры «A» и «B») с внешним миром (роутеры «C» и «D»). «A» и «B» общаются между собой по IBGP.

Между роутерами «A-F», «A-B» и «B-F» этой AS также используется OSPF (протокол семейства IGP).

Приведенная ниже конфигурация роутеров – предварительная, поскольку она не полная. Это сделано для того, чтобы продемонстрировать методы BGP исправления ошибок.

! Router A

hostname RouterA

!

interface loopback 0

ip address 203.250.13.41 255.255.255.0

!

interface ethernet 0

ip address 203.250.14.1 255.255.255.0

!

interface serial 0

ip address 128.213.63.1 255.255.255.252

!

router ospf 10

network 203.250.0.0 0.0.255.255 area 0

router bgp 100

network 203.250.13.0 mask 255.255.255.0

network 203.250.14.0 mask 255.255.255.0

neighbor 128.213.63.2 update-source loopback 0

! Router B

!

hostname RouterB

!

interface serial 0

ip address 203.250.15.2 255.255.255.252

!

inetrface serial 1

ip address 192.208.10.6 255.255.255.252

!

router ospf 10

network 203.250.0.0 0.0.255.255 area 0

!

router bgp 100

network 203.250.15.0

neighbor 192.208.10.5 remote-as 300

neighbor 203.250.15.1 remote-as 100

! Router C

hostname RouterC

!

interface loopback 0

ip address 128.213.63.130 255.255.255.192

!

interface serial 2/0

ip address 128.213.63.5 255.255.255.252

!

interface serial 2/1

ip address 128.213.63.2 255.255.255.252

!

router bgp 200

network 128.213.0.0

neighbor 128.213.63.1 remote-as 100

neighbor 128.213.63.6 remote-as 400

! Router D

hostname RouterD

!

interface loopback 0

ip address 192.208.10.174 255.255.255.192

!

interface serial 0/0

ip address 192.208.10.5 255.255.255.252

!

interface serail 0/1 (ERROR: здесь и строчка ниже в оригинале – с опечаткой)

ip address 192.208.10.2 255.255.255.252

!

router bgp 300

network 192.208.10.0

neighbor 192.208.10.1 remote-as 500

neighbor 192.208.10.6 remote-as 100

! Router E

hostname RouterE

!

interface loopback 0

ip address 200.200.10.1 255.255.255.0

!

interface serial 0

ip address 195.211.10.2 255.255.255.252

!

interface serial 1

ip address 128.213.63.6 255.255.255.252

!

router bgp 400

network 200.200.10.0

neighbor 128.213.63.5 remote-as 200

neighbor 195.211.10.1 remote-as 500

! Router F

!

hostname RouterF

!

interface ethernet 0

ip address 203.250.14.2 255.255.255.0

!

interface serial 1

ip address 203.250.15.1 255.255.255.252

!

router ospf 10

network 203.250.0.0 0.0.255.255 area 0

! Router G

hostname RouterG

!

interface loopback 0

ip address 195.211.10.174 255.255.255.192

!

interface serial 0

ip address 192.208.10.0 255.255.255.252

!

interface serial 1

ip address 195.211.10.1 255.255.255.252

!

router bgp 500

network 195.211.10.0

neighbor 192.208.10.2 remote-as 300

neighbor 195.211.10.2 remote-as 400

Определение состояния
BGP

Предположим, что (см. рисунок 6) связь между роутерами «B» и «D» испортилась. Выполним на роутере «B» команду show ip bgp:

RouterB

#

show

ip

bgp

table version is 4, local router ID is 203.250.15.2

Status codes: s suppesed, d damped, h history, * valid, > best, i internal

Origin codes: i – IGP, e – EGP,? – incomplete

Network Next Hop Metric LocPrf Weight Path

*i128.213.0.0 128.213.63.2 0 100 0 200 i

*i192.208.10.0 128.213.63.2 100 0 200 400 500 300 i

*i195.211.10.0 128.213.63.2 100 0 200 400 500 i

*i200.200.10.0 128.213.63.2 100 0 200 400 i

*>i203.250.13.0 203.250.13.41 0 100 0 i

*>i203.250.14.0 203.250.13.41 0 100 0 i

*> 203.250.15.0 0.0.0.0 0 32768 i

Символ «i» в начале строки означает, что о данном маршруте стало известно от IBGP peer'а.

Символ «i» в конце строки означает, что информация о данном пути пришла от IGP.

Первая строка читается так:

Информация о доступности сети 128.213.0.0 получена через AS_path 200, и для того, чтобы с данного роутера достичь этой сети, в качестве Next hop'а следует использовать 128.213.63.2.

Замечание: любой маршрут, который сгенерирован на данном роутере (см. 203.250.15.0) имеет next hop = 0.0.0.0.

Символ «>» означает, что BGP выбрал данный маршрут, как лучший. Процесс выбора наилучшего маршрута описан выше в главе «Summary of the BGP Path Selection Process». BGP всегда выбирает только один маршрут, как лучший. После чего он записывает этот маршрут в IP routong table и анонсирует этот путь другим BGP peer'ам.

Заметим, что next hop attribute 128.213.63.2, имеющий место для части маршрутов, унаследован от EBGP.

Теперь проверим IP routing table на роутере «B»:

Заметим, что ни один BGP маршрут не появился в IP routing table. Это произошло потому, что в данной конфигурации мы имеем одну проблему: маршруты к некоторым сетям, содержащиеся в BGP route table на «B», имеют next hop = 128.213.63.2, который недоступен с «B».

Адрес 128.213.63.2 недоступен потому, что в таблице маршрутизации на «B» отсутствует запись о том, как достичь данный адрес через IGP (в данном случае, через OSPF). Итак, роутер «B» не знает о 128.213.63.0 из OSPF.

Исправление проблемы
Next Hop

В данном примере проблема с next hop может быть решена двумя способами:

*
Использованием на роутере «A» команды «next-hop-self» для изменения значения next hop между роутерами «A» и «B».

*
На роутере «A» настроить OSPF _на интерфейсе_ Serial 0, указав его как passive. В этом случае роутер «B» будет знать, каким образом достичь next hop 128.213.63.2.

Итак, следующая конфигурация роутера «A» устанавливает OSPF на Serial 0 и делает его passive:

! Router A

hostname RouterA

!

interface loopback 0

ip address 203.250.13.41 255.255.255.0

!

interface ethernet 0

ip address 203.250.14.1 255.255.255.0

!

interface serial 0

ip address 128.213.63.1 255.255.255.252

!

router ospf 10

passive-interface serial 0

network 203.250.0.0 0.0.255.255 area 0

network 128.213.0.0 0.0.255.255 area 0

!

router bgp 100

network 203.250.13.0 mask 255.255.255.0

network 203.250.14.0 mask 255.255.255.0

neighbor 128.213.63.2 remote-as 200

neighbor 203.250.15.2 remote-as 100

neighbor 203.250.15.2 update-source loopback 0

Теперь, BGP таблица соседей на роутере «B» будет содержать следующие маршруты:

RouterB# show ip bgp

table version is 4, local router ID is 203.250.15.2

Status codes: s suppesed, d damped, h history, * valid, > best, i internal

Origin codes: i – IGP, e – EGP,? – incomplete

Network Next Hop Metric LocPrf Weight Path

*>i128.213.0.0 128.213.63.2 0 100 0 200 i

*>i192.208.10.0 128.213.63.2 100 0 200 400 500 300 i

*>i195.211.10.0 128.213.63.2 100 0 200 400 500 i

*>i200.200.10.0 128.213.63.2 100 0 200 400 i

*>i203.250.13.0 203.250.13.41 0 100 0 i

*>i203.250.14.0 203.250.13.41 0 100 0 i

*> 203.250.15.0 0.0.0.0 0 32768 i

Как видно, символ «>» появился у всех записей о маршрутах, и это означает, что BGP удовлетворен наличием достижимого next hop'а в этих записях.

Теперь IP Routing Table на роутере «B» будет выглядеть по-другому:

Пока что мы добились лишь того, что сеть 128.213.63.0 стала доступной по OSPF. Заметим, что BGP записи все еще не появились в IP routing table.

Проблема заключается в синхронизации: BGP не синхронизован с IGP, поэтому маршруты BGP не передались в IP routing table, и соответственно данные маршруты не включены в передаваемые далее BGP update.

Роутер «F» не знает о сетях 192.208.10.0, 195.211.10.0 потому что BGP маршруты все еще не redistributed into OSPF.

Выключение синхронизации

Если ввести команду конфигурации «no synchronisation» на роутере «B», и потом проверите таблицу IP маршрутизации на нем же, то выведутся следующие маршруты:

RouterB# show ip route

Codes: C – connected, S – static, I – IGRP, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

E1 – OSPF external type 1, E2 – OSPF external type 2, E – EGP

i – IS-IS, L1 – IS-IS level-1, L2 – IS-IS level-2, * – candidate

default

Gateway of last resort not set

B 200.200.10.0 [200/0] via 128.213.63.2, 00:01:07

B 195.211.10.0 [200/0] via 128.213.63.2, 00:01:07

B 192.208.10.0 [200/0] via 128.213.63.2, 00:01:07

203.250.13.0 is variably subnetted, 2 subnets, 2 masks

O 203.250.13.41 255.255.255.255

[110/75] via 203.250.15.1, 00:12:37, Serial 0

B 203.250.13.0 255.255.255.0 [200/0] via 203.250.13.41, 00:01:08

203.250.15.0 255.255.255.252 is subnetted, 1 subnets

C 203.250.15.0 255.255.255.252 is directly connected, Serial 0

O 203.250.14.0 [110/74 via 203.250.15.1, 00:12:37, Serial 0

128.213.0.0 is is variably subnetted, 2 subnets, 2 masks

B 128.213.0.0 255.255.0.0 [200/0] via 128.213.63.2, 00:01:08

O 128.213.63.0 255.255.255.252

[110/138] via 203.250.15.1, 00:12:37, Serial 0

Итак, таблица маршрутизации на первый взгляд правильная, но достичь указанные в ней сети не представляется возможным из-за того, что роутер «F», расположенный на пути к ним, не знает маршрутов к этим сетям. Это видно в результатах выполнения команды show ip route на «F»:

RouterF# show ip route

Codes: C – connected, S – static, I – IGRP, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

E1 – OSPF external type 1, E2 – OSPF external type 2, E – EGP

i – IS-IS, L1 – IS-IS level-1, L2 – IS-IS level-2, * – candidate

default

Gateway of last resort not set

203.250.13.0 255.255.255.255 is subnetted, 1 subnets

O 203.250.13.41 [110/11] via 203.250.14.1, 00:14:15

203.250.15.0 255.255.255.252 is subnetted, 1 subnets

C 203.250.15.0 is directly connected, Serial1

C 203.250.14.0 is directly connected, Ethernet0

128.213.0.0 255.255.255.252 is subnetted, 1 subnets

O 128.213.63.0 [110/74] via 203.250.14.1, 00:14:15, Ethernet0

Если пакеты, пришедшие из сети, роутеры которой обмениваются маршрутами по BGP, попадут на роутер «F», они будут утеряны. Таким образом, выключение синхронизации не решает эту проблему. Мы видим, что OSPF необходимо сделать перераспределение своих маршрутов в BGP на роутере «A»; таким образом, роутер «F» узнает о BGP маршрутах.

Ре-аннонсирование OSPF

Итак, следующая конфигурация роутера «A» модифицированна таким образом, что BGP маршруты передаются (redistributed) в OSPF:

! Router A

hostname RouterA

!

interface loopback 0

ip address 203.250.13.41 255.255.255.0

!

interface ethernet 0

ip address 203.250.14.1 255.255.255.0

!

interface serial 0

ip address 128.213.63.1 255.255.255.252

!

router ospf 10

redistribute bgp 100 metric 2000 subnets

passive-interface serial0

network 203.250.0.0 0.0.255.255 area 0

network 128.213.0.0 0.0.255.255 area 0

!

router bgp 100

network 203.250.0.0 mask 255.255.0.0

neighbor 128.213.63.2 remote-as 200

neighbor 203.250.15.2 remote-as 100

neighbor 203.250.15.2 update-source loopback 0

Теперь IP routing table будет выглядеть следующим образом:

RouterB# show ip route

Codes: C – connected, S – static, I – IGRP, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

E1 – OSPF external type 1, E2 – OSPF external type 2, E – EGP

i – IS-IS, L1 – IS-IS level-1, L2 – IS-IS level-2, * – candidate default

Gateway of last resort not set

O E2 200.200.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0

O E2 195.211.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0

O E2 192.208.10.0 [110/2000] via 203.250.15.1, 00:00:14, Serial0

203.250.13.0 is variably subnetted, 2 subnets, 2 masks

O 203.250.13.41 255.255.255.255

[110/75] via 203.250.15.1, 00:00:15, Serial0

O E2 203.250.13.0 255.255.255.0

[110/2000] via 203.250.15.1, 00:00:15, Serial0

203.250.15.0 255.255.255.252 is subnetted, 2 subnets

C 203.250.15.8 is directly connected, Loopbackl

C 203.250.15.0 is directly connected, Serial0

O 203.250.14.0 [110/74] via 203.250.15.1, 00:00:15, Serial0

128.213.0.0 is variably subnetted, 2 subnets, 2 masks

O E2 128.213.0.0 255.255.0.0 [110/2000] via 203.250.15.1, 00:00:l5, Serial0

O 128.213.63.0 255.255.255.252

[110/138] via 203.250.15.1, 00:00:16, Serial0

Теперь записи о BGP маршрутах пропали, поскольку OSPF имеет лучшее значение Administrative Distance (110), чем IBGP (200).

Отключение синхронизации на роутере «A» означает, что роутер «A» анонсирует маршруты к сети 203.250.15.0; Это требуется потому, что роутер «A» не синхронизован с OSPF из-за mask differences. По той же самой причине, синхронизация должна быть отключена на роутере «B», чтобы этот роутер мог анонсировать сеть 203.250.13.0.

Необходимо добавить, что OSPF должен быть включен на интерфейсе Serial 1 роутера «B» и быть passive, таким образом роутер «A» узнает о next hop 192.208.10.5 через IGP.

Итак, новые конфигурации роутеров «A» и «B»:

! Router A

hostname RouterA

!

interface loopback 0

ip address 203.250.13.41 255.255.255.0

!

interface ethernet 0

ip address 203.250.14.1 255.255.255.0

!

interface serial 0

ip address 128.213.63.1 255.255.255.252

!

router ospf 10

redistribute bgp 100 metric 2000 subnets

passive-interface serial 0

network 203.250.0.0 0.0.255.255 area 0

network 128.213.0.0 0.0.255.255 area 0

!

router bgp 100

no synchronization

network 203.250.13.0 mask 255.255.255.0

network 203.250.14.0 mask 255.255.255.0

neighbor 128.213.63.2 remote-as 200

neighbor 203.250.15.2 remote-as 100

neighbor 203.250.15.2 update-source loopback 0

Конфигурация роутера «B»:

! Router B

hostname RouterB

!

interface serial 0

ip address 203.250.15.2 255.255.255.252

!

interface serial 1

ip address 192.208.10.6 255.255.255.252

!

router ospf 10

redistribute bgp 100 metric 1000 subnets

passive-interface serial 1

network 203.250.0.0 0.0.255.255 area 0

network 192.208.0.0 0.0.255.255 area 0

!

router bgp 100

network 203.250.15.0

neighbor 192.208.10.5 remote-as 300

neighbor 203.250.13.41 remote-as 100

Теперь поднимем Serial 1 на роутере «B» и получим такую таблицу BGP маршрутизации на роутере «A»:

RouterA# show ip bgp

table version is 117, local router ID is 203.250.13.41

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal

Origin codes: i – IGP, e – EGP,? – incomplete

Network Next Hop Metric LocPrf Weight Path

*> 128.213.0.0 128.213.63.2 0 100 0 200 i

*>i192.208.10.0 192.208.10.5 0 100 0 300 i

*>i195.211.10.0 192.208.10.5 100 0 300 500 i

* 128.213.63.2 0 200 400 500 i

*> 203.250.13.0 0.0.0.0 0 32768 i

*> 203.250.14.0 0.0.0.0 0 32768 i

*>i203.250.15.0 203.250.15.2 0 100 0 i

Результаты выполнения команды show ip route на роутере «A»:

RouterA# show ip route

Codes: C – connected, S – static, I – IGRP, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

E1 – OSPF external type 1, E2 – OSPF external type 2, E – EGP

i – IS-IS, L1 – IS-IS level-1, L2 – IS-IS level-2, * – candidate default

Gateway of last resort not set

192.208.10.0 is variably subnetted, 2 subnets, 2 masks

O E2 192.208.10.0 255.255.255.0

[110/1000] via 203.250.14.2, 00:41:25, Ethernet0

O 192.208.10 4 255.255.255.252

[110/138] via 203.250.14.2, 00:41:25, Ethernet0

C 203.250.13.0 is directly connected, Loopback0

203.250.15.0 is variably subnetted, 3 subnets, 3 masks

O 203.250.15.10 255.255.255.255

[110/75] via 203.250.14.2, 00:41:25, Ethernet0

O 203.250.15.0 255.255.255.252

[110/74] via 203.250.14.2, 00:41:25, Ethernet0

B 203.250.15.0 255.255.255.0 [200/0] via 203.250.15.2, 00:41:25

C 203.250.14.0 is directly connected, Ethernet0

128.213.0.0 is variably subnetted, 2 subnets, 2 masks

B 128.213.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:41:26

C 128.213.63.0 255.255.255.252 is directly connected, Serial0

B* 200.200.0.0 255.255.0.0 [20/0] via 128.213.63.2, 00:02:38

Результаты выполнения команды show ip bgp на роутере «B»:

RouterB# show ip bgp

table version is 12, local router ID is 203.250.15.2

Status codes: s suppressed, d damped, h history, * valid, > best, i – internal

Origin codes: i – IGP, e – EGP,? – incomplete

Network Next Hop Metric LocPrf Weight Path

*>i128.213.0.0 128.213.63.2 0 100 0 200 i

* 192.208.10.5 0 300 500 400 200 i

*> 195.208.10.0 192.208.10.5 0 0 300 i

*> 195.211.10.0 192.208.10.5 0 300 500 i

*>i200.200.10.0 128.213.63.2 100 0 200 400 i

*> 192.208.10.5 0 300 500 400 i

*>i203.250.13.0 203.250.13.41 0 100 0 i

*>i203.250.14.0 203.250.13.41 0 100 0 i

*> 203.250.15.0 0.0.0.0 0 32768

i

Литература

1. Олифер В.Г., Олифер Н.А., «Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов», СПб: Питер, 2007.

2. Компьютерные сети. Э. Таненбаум, – СПб: Питер, 2002.

3. Олифер В.Г., Олифер Н.А., «Введение в IP-сети». Электронный учебник.

Слов:	11388
Символов:	93954
Размер:	183.50 Кб.

Название реферата: Протокол обмена управляющими сообщениями ICMP Протоколы обмена маршрутной информацией