(5 оценок, среднее: 4,80 из 5)
Загрузка...
Учебная работа. Курсовая работа: Протокол обмена управляющими сообщениями 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. Любой тип сообщения имеет собственный формат, при всем этом они все начинаются с общих 3-х полей: 8-битного целого числа, обозначающего тип сообщения (TYPE), 8-битного поля кода (CODE), который конкретизирует предназначение сообщения, и 16-битного поля контрольной суммы (CHECKSUM). Не считая того, сообщение ICMP постоянно содержит заголовок и 1-ые 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-сообщение включает также заголовок недоставленного пакета и его 1-ые 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. 1-ый 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
На 1-ый взор, новейший протокол владеет рядом существенных преимуществ перед IPv4. Но до сего времени скорость его внедрения продолжает оставаться низкой. По данным Форума IPv6, лишь семь из 21 огромнейших веб-провайдеров решают шаги, нужные для настоящего перехода к использованию новейшей технологии.
Нужно исходить из того, что IPv6 является новейшей версией старенького протокола, разработанной таковым образом, чтоб обеспечить сопоставимость и «мягенький» переход, не приуроченный к определенной дате и не требующий одновременных действий всех участников. По неким прогнозам, совместное существование 2-ух протоколов будет длиться до 10 и наиболее лет.
В спецификации RFC 1726 представлен набор функций, главными посреди их являются:
· масштабируемость: идентификация и определение адресов как минимум 1012
конечных систем и 109
личных сетей;
· топологическая упругость: архитектура маршрутизации и протокол должны работать в сетях с различной топологией;
· преемственность: обеспечение чёткого плана перехода от имеющейся версии IPv4;
· независимость от среды передачи: работа посреди огромного количества сетей с разными средами передачи данных со скоростями до сотен гигабит в секунду;
· автоматическое конфигурирование хостов и маршрутизаторов;
· сохранность на сетевом уровне;
· мобильность: обеспечение работы с мобильными юзерами, сетями и межсетевыми системами;
· расширяемость: возможность предстоящего развития в согласовании с новенькими потребностями.
В итоге реализации заявленных функций важные инновации IPv6 состоят в последующем:
· упрощен обычный заголовок IP-пакета;
· изменено место;
· усовершенствована поддержка иерархической адресации, агрегирования маршрутов и автоматического конфигурирования адресов;
· введены механизмы аутентификации и шифрования на уровне IP-пакетов;
· введены метки потоков данных.
протокол IP v6 подразумевает также значимые улучшения при работе в локальной сети. Единый протокол NDP (Neighbor Discovery Protocol – протокол определения соседей) подменяет используемые в IP v4 протоколы ARP, ICMP и существенно расширяет их многофункциональные способности. Заместо использующихся в протоколе ARP широковещательных пакетов канального уровня употребляются групповые сообщения (multicast), другими словами адресованные всем членам сабсети, притом, не на канальном, а на сетевом уровне, что обязано существенно понизить широковещательный трафик, являющийся бичом локальных сетей Ethernet. Улучшены функции протокола ICMP, облегчая работу различных субсетей в одном физическом секторе. Включен механизм определения неисправных маршрутизаторов, что дозволяет повысить устойчивость к сбоям оборудования.
Еще одна неувязка, сплетенная с внедрением 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. 1-ая показывает этот адресок в 128-битном формате, а 2-ая – в 32-битном. Это дозволяет устройствам, использующим лишь протокол IPv6, получать IPv6-адреса, а узлам, работающим лишь на IPv4 – IPv4 адреса.
Одним словом, для полной сопоставимости с IPv6 DNS просит суровой перестройки.
При рассмотрении способностей, предоставляемые новеньким протоколом, может появиться вопросец, а для чего он все-же нужен? Большая часть функций или уже имеются в IP v4, или могут быть реализованы методом доработки соответственных протоколов. Так, автоматическое выделение адресов делается с помощью протокола DHCP, адресный барьер преодолевается с помощью протокола NAT и т.д. и т.п. Но разработка всех нужных заплаток для протокола IP v4 востребовала бы Издержки не наименьших (а то и огромных) усилий, чем создание новейшего протокола «с незапятнанного листа». Очевидно, лист был не совершенно незапятнанным, так как вопросцы сопоставимости и совместной работы обоих протоколов имелись в виду с самого начала проектирования. В конце концов веб все равно пришла бы к кризису недостатка адресов, так что преждевременная разработка и постепенное внедрение протокола IP v6 были наиболее чем уместны.
Для реализации перехода на новейший протокол образовалась неформальная некоммерческая организация 6bone, включающая в себя наиболее 100 организаций, в главном, сетевых провайдеров и институтов. Основная задачка организации – создание инфраструктуры, позволяющей транспортировку пакетов эталона IP v6 по всей сети веб. Как и существующая сейчас инфраструктура IP v4, она будет состоять из огромного количества провайдеров и локальных сетей, объединенных в единую сеть. В истинное время в состав 6bone входят представители 41 страны, от США
Итоги:
1. Базисный набор протоколов IP v6 обхватывает функции набора протоколов IP v4
2. Базисный набор протоколов IP v6 расширяет функции набора протоколов IP v4 (в том числе ICMP, которые охватывается единым протоколом NDP).
3. Тестирование и внедрение IP v6 просит значимых усилий и издержек.
Протоколы обмена маршрутной информацией
Общая черта протоколов обмена маршрутной информацией
Все протоколы обмена маршрутной информацией стека TCP/IP относятся к классу адаптивных протоколов, которые в свою очередь делятся на две группы, любая из которых связана с одним из последующих типов алгоритмов:
дистанционно-векторный метод (Distance Vector Algorithms, DVA),
метод состояния связей (Link State Algorithms, LSA).
В методах
любой маршрутизатор временами и широковещательно рассылает по сети вектор расстояний от себя до всех узнаваемых ему сетей. Под расстоянием обычно понимается число промежных маршрутизаторов через которые пакет должен пройти до этого, чем попадет в подобающую сеть. Может употребляться и иная метрика, учитывающая не только лишь число перевалочных пт, да и время прохождения пакетов по связи меж примыкающими маршрутизаторами. Получив вектор от примыкающего маршрутизатора, любой маршрутизатор добавляет к нему информацию о узнаваемых ему остальных сетях, о которых он вызнал конкретно (если они подключены к его портам) либо из подобных объявлений остальных маршрутизаторов, а потом опять рассылает новое информацию о имеющихся в интерсети сетях и о расстоянии до их через примыкающие маршрутизаторы.
Дистанционно-векторные методы отлично работают лишь в маленьких сетях. В огромных сетях они засоряют полосы связи интенсивным широковещательным трафиком, к тому же конфигурации конфигурации могут отрабатываться по этому методу не постоянно корректно, потому что маршрутизаторы не имеют четкого представления о топологии связей в сети, а располагают лишь обобщенной информацией – вектором дистанций, к тому же приобретенной через посредников. Работа маршрутизатора в согласовании с дистанционно-векторным протоколом припоминает работу моста, потому что четкой топологической картины сети таковой маршрутизатор не имеет.
Более всераспространенным протоколом, основанным на дистанционно-векторном методе, является протокол RIP.
обеспечивают любой маршрутизатор информацией, достаточной для построения четкого графа связей сети. Все маршрутизаторы работают на основании схожих графов, что делает процесс маршрутизации наиболее устойчивым к изменениям конфигурации. Широковещательная рассылка употребляется тут лишь при конфигурациях состояния связей, что происходит в надежных сетях не так нередко.
Для того, чтоб осознать, в котором состоянии находятся полосы связи, присоединенные к его портам, маршрутизатор временами обменивается маленькими пакетами со своими наиблежайшими соседями. Этот трафик также широковещательный, но он циркулирует лишь меж соседями и потому не так засоряет сеть.
Протоколом, основанным на методе состояния связей, в стеке TCP/IP является протокол OSPF.
Дистанционно-векторный протокол RIP
Протокол RIP (Routing Information Protocol) маршрутизации предназначен для сравнимо маленьких и относительно однородных сетей (метод Белмана-Форда). протокол разработан в институте Калифорнии (Беркли), базируется на разработках компании Ксерокс и реализует те же принципы, что и программка маршрутизации routed, применяемая в ОC unix (4BSD). Маршрут тут характеризуется вектором расстояния до места предназначения. Предполагается, что любой маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан.
протокол RIP представляет собой один из наистарейших протоколов обмена маршрутной информацией, но он до сего времени очень всераспространен в вычислительных сетях. Кроме версии RIP для сетей TCP/IP, существует также версия RIP для сетей IPX/SPX компании Novell.
В этом протоколе все сети имеют номера (метод образования номера зависит от применяемого в сети протокола сетевого уровня), а все маршрутизаторы – идентификаторы. протокол RIP обширно употребляет понятие «вектор расстояний». Вектор расстояний представляет собой набор пар чисел, являющихся номерами сетей и расстояниями до их в хопах.
Описания этих маршрутов хранится в специальной таблице, именуемой маршрутной. Таблица маршрутизации RIP содержит по записи на каждую обслуживаемую машинку (на любой маршрут). Запись обязана включать в себя:
·
·
·
·
Первым двум полям записи мы должны возникновению термина
(пространство предназначение – направление; метрика – модуль вектора). Временами (раз в 30 сек) любой маршрутизатор отправляет широковещательно копию собственной маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан конкретно. Маршрутизатор-получатель просматривает таблицу. Если в таблице находится новейший путь либо сообщение о наиболее маленьком маршруте, либо произошли конфигурации длин пути, эти конфигурации фиксируются получателем в собственной маршрутной таблице. протокол RIP должен быть способен обрабатывать три типа ошибок:
Циклические маршруты. Потому что в протоколе нет устройств выявления замкнутых маршрутов, нужно или слепо веровать партнерам, или принимать конструктивные меры для блокировки таковой способности.
Для угнетения непостоянностей RIP должен употреблять маленькое
Неспешное распространение маршрутной инфы по сети делает задачи при оживленном изменении маршрутной ситуации (система не поспевает за переменами). Маленькое предельное
Несоответствие маршрутной таблицы настоящей ситуации приемлимо не только лишь для RIP, но типично для всех протоколов, базирующихся на векторе расстояния, где информационные сообщения актуализации несут внутри себя лишь пары кодов: адресок места предназначение и расстояние до него.
В RIP сообщения инкапсулируются в udp-дейтограммы, при всем этом передача осуществляется через порт 520. В качестве метрики RIP употребляет число шагов до цели. Если меж отправителем и приемником размещено три маршрутизатора (gateway), считается, что меж ними 4 шага. Таковой вид метрики не учитывает различий в пропускной возможности либо загруженности отдельных частей сети. Применение вектора расстояния не может гарантировать оптимальность выбора маршрута, ведь, к примеру, два шага по секторам сети ethernet обеспечат огромную пропускную способность, чем один шаг через поочередный канал на базе интерфейса RS-232.
Маршрут по дефлоту имеет адресок 0.0.0.0 (это правильно и для остальных протоколов маршрутизации). Любому маршруту ставится в соответствие таймер тайм-аута и «собирателя мусора». Тайм-аут-таймер сбрасывается всякий раз, когда маршрут инициализируется либо корректируется. Если со времени крайней корректировки прошло 3 минутки либо получено сообщение о том, что вектор расстояния равен 16, маршрут считается закрытым. Но запись о нем не стирается, пока не истечет время «уборки мусора» (2 мин). При возникновении эквивалентного маршрута переключения на него не происходит, таковым образом, блокируется возможность осцилляции меж 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
протокол
является довольно современной реализацией метода состояния связей (он принят в 1991 году) и владеет почти всеми чертами, нацеленными на применение в огромных гетерогенных сетях.
протокол OSPF вычисляет маршруты в IP-сетях, сохраняя при всем этом остальные протоколы обмена маршрутной информацией.
Конкретно связанные (другими словами достижимые без использования промежных маршрутизаторов) маршрутизаторы именуются «соседями». Любой маршрутизатор хранит информацию о том, в котором состоянии по его воззрению находится сосед. Маршрутизатор полагается на примыкающие маршрутизаторы и передает им пакеты данных лишь в том случае, если он уверен, что они стопроцентно работоспособны. Для выяснения состояния связей маршрутизаторы-соседи довольно нередко обмениваются маленькими сообщениями HELLO.
Для распространения по сети данных о состоянии связей, маршрутизаторы обмениваются сообщениями другого типа. Эти сообщения именуются
– объявление о связях маршрутизатора (поточнее, о состоянии связей). OSPF-маршрутизаторы обмениваются не только лишь своими, да и чужими объявлениями о связях, получая в конце-концов информацию о состоянии всех связей сети. Эта информация и образует граф связей сети, который, естественно, один и этот же для всех маршрутизаторов сети.
Не считая инфы о соседях, маршрутизатор в собственном объявлении перечисляет IP-подсети, с которыми он связан конкретно, потому опосля получения инфы о графе связей сети, вычисление маршрута до каждой сети делается конкретно по этому графу по методу Дэйкстры. Наиболее буквально, маршрутизатор вычисляет путь не до определенной сети, а до маршрутизатора, к которому эта сеть подключена. Любой маршрутизатор имеет неповторимый идентификатор, который передается в объявлении о состояниях связей. Таковой подход дает возможность не растрачивать IP-адреса на связи типа «точка-точка» меж маршрутизаторами, к которым не подключены рабочие станции.
Маршрутизатор вычисляет лучший маршрут до каждой адресуемой сети, но запоминает лишь 1-ый промежный маршрутизатор из всякого маршрута. Таковым образом, результатом вычислений хороших маршрутов является перечень строк, в каких указывается номер сети и идентификатор маршрутизатора, которому необходимо переслать пакет для данной сети. Обозначенный перечень маршрутов и является маршрутной таблицей, но вычислен он на основании полной инфы о графе связей сети, а не частичной инфы, как в протоколе RIP.
Описанный подход приводит к результату, который не быть может достигнут при использовании протокола RIP либо остальных дистанционно-векторных алгоритмов. RIP подразумевает, что все сабсети определенной IP-сети имеют один и этот же размер, другими словами, что они все могут потенциально иметь однообразное число IP-узлов, адреса которых не перекрываются. Наиболее того, традиционная реализация RIP просит, чтоб выделенные полосы «точка-точка» имели IP-адресок, что приводит к доп затратам IP-адресов.
В OSPF такие требования отсутствуют: сети могут иметь различное число хостов и могут перекрываться. Под перекрытием понимается наличие нескольких маршрутов к одной и той же сети. В этом случае адресок сети в пришедшем пакете может совпасть с адресом сети, присвоенным нескольким портам.
Если адресок принадлежит нескольким подсетям в базе данных маршрутов, то продвигающий пакет маршрутизатор употребляет более специфичный маршрут, другими словами адресок сабсети, имеющей наиболее длинноватую маску.
к примеру, если рабочая группа ответвляется от главной сети, то она имеет адресок главной сети вместе с наиболее специфичным адресом, определяемым маской сабсети. При выбирании маршрута к хосту в сабсети данной рабочей группы маршрутизатор отыщет два пути, один для главной сети и один для рабочей группы. Потому что крайний наиболее специфичен, то он и будет избран. Этот механизм является обобщением понятия «маршрут по дефлоту», применяемого в почти всех сетях.
Внедрение субсетей с разным количеством хостов является полностью естественным. к примеру, если в здании либо кампусе на любом этаже имеются локальные сети, и на неких этажах компов больше, чем на остальных, то админ может избрать размеры субсетей, отражающие ожидаемые требования всякого этажа, а не надлежащие размеру большей сабсети.
В протоколе OSPF сабсети делятся на три группы:
«хост-сеть», представляющая собой сабсеть из 1-го адреса,
«тупиковая сеть», которая представляет собой сабсеть, присоединенную лишь к одному маршрутизатору,
«транзитная сеть», которая представляет собой сабсеть, присоединенную к наиболее чем одному маршрутизатору.
Транзитная сеть является для протокола OSPF особенным случаем. В транзитной сети несколько маршрутизаторов являются взаимно и сразу достижимыми. В широковещательных локальных сетях, таковых как Ethernet либо Token Ring, маршрутизатор может отправить одно сообщение, которое получат все его соседи. Это уменьшает нагрузку на маршрутизатор, когда он отправляет сообщения для определения существования связи либо освеженные объявления о соседях. Но, если любой маршрутизатор будет перечислять всех собственных соседей в собственных объявлениях о соседях, то объявления займут много места в памяти маршрутизатора. При определении пути по адресам транзитной сабсети может обнаружиться много лишних маршрутов к разным маршрутизаторам. На вычисление, проверку и отбраковку этих маршрутов уйдет много времени.
Когда маршрутизатор начинает работать впервой (другими словами инсталлируется), он пробует синхронизировать свою базу данных со всеми маршрутизаторами транзитной локальной сети, которые по определению имеют схожие базы данных. Для упрощения и оптимизации этого процесса в протоколе OSPF употребляется понятие «выделенного» маршрутизатора, который делает две функции.
Во-1-х, выделенный маршрутизатор и его запасный «напарник» являются единственными маршрутизаторами, с которыми новейший маршрутизатор будет синхронизировать свою базу. Синхронизировав базу с выделенным маршрутизатором, новейший маршрутизатор будет синхронизирован со всеми маршрутизаторами данной локальной сети.
Во-2-х, выделенный маршрутизатор делает
перечисляя собственных соседей по сабсети. Остальные маршрутизаторы просто объявляют о собственной связи с выделенным маршрутизатором. Это делает объявления о связях (которых много) наиболее короткими, размером с объявление о связях отдельной сети.
Для начала работы маршрутизатора OSPF нужен минимум инфы – IP-конфигурация (IP-адреса и маски субсетей), некая информация по дефлоту (default) и команда на включение. Для почти всех сетей информация по дефлоту очень похожа. В то же время протокол OSPF предугадывает высшую степень программируемости.
интерфейс OSPF (порт маршрутизатора, поддерживающего протокол OSPF) является обобщением сабсети IP. Подобно сабсети IP, интерфейс OSPF имеет IP-адрес и маску сабсети. Если один порт OSPF поддерживает наиболее чем одну сабсеть, протокол OSPF разглядывает эти сабсети так, как если б они были на различных физических интерфейсах, и вычисляет маршруты соответственно.
Интерфейсы, к которым подключены локальные сети, именуются
потому что они могут употреблять широковещательные способности локальных сетей для обмена сигнальной информацией меж маршрутизаторами. Интерфейсы, к которым подключены глобальные сети, не поддерживающие широковещание, но обеспечивающие доступ ко почти всем узлам через одну точку входа, к примеру сети Х.25 либо frame relay, именуются нешироковещательными интерфейсами с множественным доступом либо
Они рассматриваются аналогично широковещательным интерфейсам кроме того, что широковещательная рассылка эмулируется методом посылки сообщения любому другу. Потому что обнаружение соседей не является автоматическим, как в широковещательных сетях, NBMA-соседи должны задаваться при конфигурировании вручную. Как на широковещательных, так и на NBMA-интерфейсах могут быть заданы ценности маршрутизаторов для того, чтоб они могли избрать выделенный маршрутизатор.
Интерфейсы «точка-точка», подобные PPP, несколько различаются от классической IP-модели. Хотя они и могут иметь IP-адреса и подмаски, но необходимости в этом нет.
В обычных сетях довольно найти, что пункт предназначения достижим и отыскать маршрут, который будет удовлетворительным. В сложных сетях обычно имеется несколько вероятных маршрутов. Время от времени хотелось бы иметь способности по установлению доп критериев для выбора пути: к примеру, меньшая задержка, наибольшая пропускная способность либо меньшая стоимость (в сетях с оплатой за пакет). По сиим причинам протокол OSPF дозволяет сетевому админу назначать любому интерфейсу определенное число, называемое
чтоб оказать необходимое воздействие на выбор маршрута.
Число, применяемое в качестве метрики пути, быть может назначено произвольным образом по желанию админа. Но по дефлоту в качестве метрики употребляется время передачи бита в 10-ти наносекундных единицах (10 Мб/с Ethernet’у назначается один путь к удаленной сабсети, то он употребляет путь с меньшей
В протоколе OSPF употребляется несколько временных характеристик, и посреди их более необходимыми являются интервал сообщения HELLO и
(
HELLO – это сообщение, которым обмениваются примыкающие, другими словами конкретно связанные маршрутизаторы сабсети, с целью установить состояние полосы связи и состояние маршрутизатора-соседа. В сообщении HELLO маршрутизатор передает свои рабочие характеристики и гласит о том, кого он разглядывает в качестве собственных ближайших соседей. Маршрутизаторы с различными рабочими параметрами игнорируют сообщения HELLO друг друга, потому ошибочно сконфигурированные маршрутизаторы не будут влиять на работу сети. Любой маршрутизатор шлет сообщение HELLO любому собственному другу по последней мере один раз в протяжении интервала HELLO. Если интервал отказа маршрутизатора исходит без получения сообщения HELLO от соседа, то считается, что сосед неработоспособен, и распространяется новое объявление о сетевых связях, чтоб в сети произошел пересчет маршрутов.
протокол
BGP
Протокол BGP разработан компаниями IBM и CISCO. Основная цель BGP – уменьшить транзитный трафик.
BGP различается от RIP и OSPF тем, что употребляет TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются вместе и пересылают средством TCP полные таблицы маршрутизации.
задачка наружной маршрутизации
В прошлых главах мы разглядели протоколы маршрутизации, работающие снутри автономных систем. задачка последующего уровня – построение маршрутов меж сетями, принадлежащими различным автономным системам.
Рассматриваемый на этом уровне, веб представляет собой огромное количество автономных систем, произвольным образом соединенных меж собой (рис. 3). Внутреннее строение автономных систем укрыто, известны лишь адреса IP-сетей, составляющих АС.
Рис. 3. Автономные системы
Автономные системы соединяются при помощи пограничных маршрутизаторов. Связи меж маршрутизаторами могут иметь разную физическую природу: к примеру, это быть может сеть Ethernet, к которой подключено сходу несколько пограничных маршрутизаторов различных автономных систем, выделенный канал типа «точка-точка» меж 2-мя маршрутизаторами и т.п. Нередко сама связывающая сеть не принадлежит ни к одной автономной системе, в таком случае она именуется демилитаризованной зоной (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-ая система никогда не выяснила бы о маршруте 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-маршрутизаторов, работает весьма просто: он воспринимает маршрут от 1-го участника группы и рассылает его всем остальным. Таковым образом, участникам группы нет необходимости устанавливать BGP-соединения попарно; заместо этого любой участник устанавливает одно соединение с сервером. Группой маршрутизаторов могут быть, к примеру, все BGP-маршрутизаторы данной АС, но маршрутные серверы могут применяться для уменьшения числа соединений также и на наружных BGP-соединениях – в случае, когда в одной физической сети находится много BGP-маршрутизаторов из разных АС (к примеру, в точке обмена трафиком меж провайдерами, рис. 4).
Рис. 4. Точка обмена трафиком (Internet Exchange
A-E – пограничные BGP-маршрутизаторы, АС1-АС5 – сети автономных систем, RS – маршрутной инфы.
Следует особо отметить, что маршрутной инфы обслуживает лишь новости маршрутов, а не сам трафик по сиим маршрутам. к примеру (рис 7.2.1), маршрутизатор А анонсирует серверу RS маршруты в сети АС1. Маршрутизатор E получает информацию о этих маршрутах от сервера RS, но при всем этом в таблице маршрутов узла Е последующим маршрутизатором на пути в АС1 числится узел А, что полностью уместно, так как эти узлы могут передавать данные друг другу конкретно. Исключение маршрутного сервера из маршрута делается методом установки значения атрибута NEXT_HOP: анонсируя маршруты в сеть АС1, RS показывает NEXT_HOP=A. Таковым образом, маршрутизатор (к примеру, Е), получивший и принявший к использованию таковой маршрут, будет пересылать данные, созданные для АС1, конкретно маршрутизатору А.
Из вышесказанного можно создать два принципиальных вывода. Во-1-х, узел, обозначенный как NEXT_HOP, должен быть достижим, другими словами в таблице маршрутов маршрутизатора, принявшего маршрут с сиим атрибутом, обязана быть запись о узле NEXT_HOP либо его сети. Если таковой записи нет, то маршрутизатор должен забраковать приобретенный маршрут, поэтому что он не понимает, как отправлять дейтаграммы к узлу NEXT_HOP.
Во-2-х, разумеется, что маршрутной инфы не является маршрутизатором. Другими словами в общем случае узел, на котором работает модуль 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 представляет собой чередование частей 2-ух типов: 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-узла. Имеет смысл не само одной АС объявляют о достижимости через себя одной и той же сети, предоставляя таковым образом получателям несколько вариантов маршрутов в одну сеть. При
дейтаграммы в объявляемую сеть будут посылаться через маршрутизатор, заявивший наименьшее
Атрибут сохраняется при следующих объявлениях маршрута по IBGP, но не по EBGP.
LOCAL_PREF
LOCAL_PREF
(тип 5) – необязательный атрибут, устанавливающий для данной АС Ценность данного маршрута посреди всех маршрутов к заявленной сети, узнаваемых снутри АС. Атрибут рассчитывается каждым пограничным маршрутизатором для всякого присланного ему по EBGP маршрута и позже распространяется совместно с сиим маршрутом по IBGP в границах данной АС. метод вычисления значения атрибута определяется политикой приема маршрутов (по дефлоту берется во внимание лишь длина AS_PATH). LOCAL_PREF употребляется для согласованного меж маршрутизаторами одной АС выбора маршрута из нескольких вариантов.
Атрибуты агрегирования
ATOMIC_AGGREGATE
(тип 6) и AGGREGATOR
(тип 7) – необязательные атрибуты, связанные с операциями агрегирования (объединения) нескольких маршрутов в один.
Примеры маршрутизации
Пример маршрутизации по методу
RIP
На рисунке 3 приведен пример сети, состоящей из 6 маршрутизаторов, имеющих идентификаторы от 1 до 6, и из 6 сетей от A до F, образованных прямыми связями типа «точка-точка».
Набросок 3. Обмен маршрутной информацией по протоколу RIP
На рисунке приведена исходная информация, содержащаяся в топологической базе маршрутизатора 2, также информация в данной же базе опосля 2-ух итераций обмена маршрутными пакетами протокола RIP. Опосля определенного числа итераций маршрутизатор 2 будет знать о расстояниях до всех сетей интерсети, при этом у него быть может несколько других вариантов отправки пакета к сети предназначения. Пусть в нашем примере сетью предназначения является сеть D.
По мере необходимости выслать пакет в сеть D маршрутизатор просматривает свою базу данных маршрутов и выбирает порт, имеющий меньшее расстояния до сети предназначения (в данном случае порт, связывающий его с маршрутизатором 3).
Для адаптации к изменению состояния связей и оборудования с каждой записью таблицы маршрутизации связан таймер. Если за время тайм-аута не придет новое сообщение, подтверждающее этот маршрут, то он удаляется из маршрутной таблицы.
При использовании протокола RIP работает эвристический метод динамического программирования Беллмана-Форда, и решение, отысканное с его помощью является не хорошим, а близким к хорошему. Преимуществом протокола RIP является его вычислительная простота, а недочетами – повышение трафика при повторяющейся рассылке широковещательных пакетов и неоптимальность отысканного маршрута.
На рисунке 4 показан вариант неуравновешенной работы сети по протоколу RIP при изменении конфигурации – отказе полосы связи маршрутизатора M1 с сетью 1. При работоспособном состоянии данной связи в таблице маршрутов всякого маршрутизатора есть запись о сети с номером 1 и подходящим расстоянием до нее.
Набросок 4. Пример неуравновешенной работы сети при использовании протокола RIP
При обрыве связи с сетью 1 маршрутизатор М1 отмечает, что расстояние до данной сети приняло время от маршрутизатора М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. Робин поначалу обнаруживает 2-ух соседей – Роба с метрикой 65 и Мило с метрикой 1785. Из объявления о связях Роба Робин нашел лучший путь к Мило со стоимостью 130, потому он отторг конкретный путь к Мило, так как он связан с большей задержкой, потому что проходит через полосы с наименьшей пропускной способностью. Робин также обнаруживает транзитную локальную сеть с выделенным маршрутизатором Джоном. Из объявлений о связях Джона Робин выяснит о пути к Фреду и, в конце концов, выяснит о пути к маршрутизаторам Келли и Джеффу и к их тупиковым сетям.
Опосля того, как маршрутизаторы стопроцентно входят в рабочий режим, интенсивность обмена сообщениями резко падает. Обычно они отправляют сообщение HELLO по своим подсетям любые 10 секунд и делают объявления о состоянии связей любые 30 минут (если обнаруживаются конфигурации в состоянии связей, то объявление передается, естественно, немедля). Освеженные объявления о связях служат гарантией того, что маршрутизатор работает в сети. Старенькые объявления удаляются из базы через определенное время.
Представим, но, что какая-либо выделенная линия сети отказала. Присоединенные к ней маршрутизаторы распространяют свои объявления, в каких они уже не упоминают друг друга. Эта информация распространяется по сети, включая маршрутизаторы транзитной локальной сети. Любой маршрутизатор в сети пересчитывает свои маршруты, находя, быть может, новейшие пути для восстановления утраченного взаимодействия.
Практический пример работы с
BGP-сетью
Имеем последующую BGP-сеть
Набросок 6.
Если AS связана с 2-мя ISP через EBGP, IBGP должен употребляться меж роутерами снутри данной AS для наилучшего управления маршрутами.
Разглядим AS100, имеющую два EBGP соединения (роутеры «A» и «B») с наружным миром (роутеры «C» и «D»). «A» и «B» разговаривают меж собой по IBGP.
Меж роутерами «A-F», «A-B» и «B-F» данной AS также употребляется OSPF (протокол семейства IGP).
Приведенная ниже конфигурация роутеров – подготовительная, так как она не полная. Это изготовлено для того, чтоб показать способы BGP исправления ошибок.
Определение состояния
BGP
Представим, что (см. набросок 6) связь меж роутерами «B» и «D» испортилась. Выполним на роутере «B» команду show ip bgp:
знак «i» сначала строчки значит, что о данном маршруте сделалось понятно от IBGP peer’а.
знак «i» в конце строчки значит, что информация о данном пути пришла от IGP.
1-ая строчка читается так:
информация о доступности сети 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 быть может решена 2-мя методами:
*
Внедрением на роутере «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:
сейчас, BGP таблица соседей на роутере «B» будет содержать последующие маршруты:
Как видно, знак «>» возник у всех записей о маршрутах, и это значит, что 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 маршрутизации на нем же, то выведутся последующие маршруты:
Итак, таблица маршрутизации на 1-ый взор верная, но достигнуть обозначенные в ней сети не представляется вероятным из-за того, что роутер «F», расположенный на пути к ним, не понимает маршрутов к сиим сетям. Это видно в результатах выполнения команды show ip route на «F»:
Если пакеты, пришедшие из сети, роутеры которой обмениваются маршрутами по BGP, попадут на роутер «F», они будут утеряны. Таковым образом, выключение синхронизации не решает эту делему. Мы лицезреем, что OSPF нужно создать перераспределение собственных маршрутов в BGP на роутере «A»; таковым образом, роутер «F» выяснит о BGP маршрутах.
Ре-аннонсирование OSPF
Итак, последующая конфигурация роутера «A» модифицированна таковым образом, что BGP маршруты передаются (redistributed) в OSPF:
сейчас IP routing table будет смотреться последующим образом:
сейчас записи о BGP маршрутах пропали, так как OSPF имеет наилучшее
Отключение синхронизации на роутере «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»:
Конфигурация роутера «B»:
сейчас поднимем Serial 1 на роутере «B» и получим такую таблицу BGP маршрутизации на роутере «A»:
Результаты выполнения команды show ip route на роутере «A»:
Результаты выполнения команды show ip bgp на роутере «B»:
Литература
1. Олифер В.Г., Олифер Н.А., «Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов», СПб: Питер, 2007.
2. Компьютерные сети. Э. Таненбаум, – СПб: Питер, 2002.
3. Олифер В.Г., Олифер Н.А., «Введение в IP-сети». электрический учебник.
]]>