Дибров М.В. Маршрутизаторы

Подождите немного. Документ загружается.

8 Использование протокола EIGRP в масштабируемых сетях

Во многих случаях сетевые администраторы стремятся по возможности

создавать резервные каналы связи до удаленных подразделений, чтобы те

имели возможность работать при отключении основного канала связи. Быва-

ют случаи, когда такое решение может привести к проблемам в работе сети.

Так как в топологии не определяется направление движения служебно-

го трафика между маршрутизаторами, то движение трафика может идти от

регионального узла до удаленных узлов и возвращаться к региональному

узлу.

10.1.1.0/24



Q R

Рисунок 8.1 – Обработка изменений в топологии сети

На рисунке 8.1 изображена сеть передачи данных с резервными канала-

ми связи между центральным узлом и удаленными подразделениями. Каждый

удаленный маршрутизатор имеет два возможных пути до сети 10.1.1.0/24 че-

рез маршрутизаторы R1 или R2.

В такой топологии при запуске процесса запросов, каждый путь между

региональным и удаленным узлом получает двойной трафик в процессе схо-

димости из–за избыточности, заложенной в топологию сети.

Если маршрутизатор R2 теряет сеть 10.1.1.0/24, то начинается процесс

многократных запросов и ответов между региональными маршрутизаторами

R1 и R2 и удаленными маршрутизаторами R3, R4 и R5. Такое увеличение тра-

фика значительно усложняет процесс сходимости сети.

В сети с двумя региональными и тремя удаленными маршрутизаторами

эта проблема не является очень серьезной, но если маршрутизаторов значи-

тельно больше, данная проблема может парализовать работу всей сети.

Разберем детально процесс запросов для сети 10.1.1.0/24. В предлагае-

мом примере, сеть 10.1.1.0/24 всем другим маршрутизаторам анонсирует

маршрутизатор R2. Наилучший путь до 10.1.1.0/24 для маршрутизатора R1

151

проходит через Ethernet канал до R2. Удаленные маршрутизаторы R3, R4 и

R5 используют последовательные магистральные каналы связи и маршрути-

затор R2 как преемника для сети 10.1.1.0/24. Но в их таблицах маршрутиза-

ции имеется так же запись о вероятном преемнике для сети 10.1.1.0/24, кото-

рым является маршрутизатор R1.

Когда маршрутизатор R2 теряет маршрут до сети 10.1.1.0/24, то он по

алгоритму DUAL опрашивает всех своих соседей на предмет наличия марш-

рута до сети 10.1.1.0/24. Удаленные маршрутизаторы получив данный запрос,

автоматически начинают использовать маршрут к запрашиваемой сети через

маршрутизатор R1, и отвечают об этом маршрутизатору R2.

Маршрутизатор R2 получил три ответа из четырех и продолжает ожи-

дать ответ от маршрутизатора R1.

Когда маршрутизатор R1 получает от маршрутизатора R2 запрос на

сеть 10.1.1.0/24, не имея вероятного преемника но, зная, что есть путь к этой

сети через удаленные маршрутизаторы, начинает рассылать им запросы о

маршруте до этой сети.

Удаленные маршрутизаторы принимают данные запросы, но так как в

их таблицах топологии маршрутизатор R1 уже значится как преемник для

маршрута на сеть 10.1.1.0/24, им приходится вычеркивать его из таблиц топо-

логии и производить рассылку запросов на соседние маршрутизаторы, в дан-

ном случае R2.

Маршрутизатор R2 получает запросы от удаленных маршрутизаторов,

но не может им ответить, потому что сам ожидает ответ от маршрутизатора

R1. А маршрутизатор R1 в свою очередь не может ответить R2 пока не полу-

чит ответа от удаленных маршрутизаторов. Для сети 10.1.1.0/24 наступает си-

туация SIA.

Так как маршрутизатор R2 послал запрос первым, то его таймер SIA ис-

текает первым, теперь он может ответить удаленным маршрутизаторам о том,

что не существует маршрута до сети 10.1.1.0/24.

Удаленные маршрутизаторы отсылают на маршрутизатор R1 ответ о

том, что они не имеют маршрута до сети 10.1.1.0/24.

Описанный дизайн сети не плох, но в нем возможна генерация больших

объемов служебного трафика EIGRP. Поэтому необходимы методы уменьше-

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

8.1 Масштабируемость. Проблемы и решения

Вот перечень лишь немногих из огромного количества причин, которые

влияют на масштабируемость сетей:

– Объем трафика передаваемого между соседями. Появление новых

соседей и изменения топологии приводят к увеличению служебного трафика

протокола EIGRP.

152

– Количество маршрутизаторов. При изменении топологии объем ре-

сурсов, потребляемых протоколом EIGRP, зависит от количества маршрути-

заторов, которые будут непосредственно задействованы в происходящих из-

менениях.

– Глубина топологии. Глубина топологии может повлиять на время

сходимости. Глубиной является количество маршрутизаторов, на которое

должен разойтись запрос об изменении в топологии сети, чтобы достичь

маршрутизатора способного ответить на запрос.

– Количество альтернативных путей в сети. Сеть передачи данных

по возможности должна предоставлять альтернативные маршруты, которые

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

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

мы для сходимости протокола EIGRP, поскольку протокол EIGRP использует

механизм рассылки запросов для исследования всех возможных путей для за-

мены потерянного маршрута, что может приводить активную сеть в состоя-

ние SIA.

Должно быть проведено исследование, что бы определить объем ин-

формации необходимый удаленным маршрутизаторам, что бы достичь желае-

мого уровня распределения маршрутов.

Для достижения максимальной стабильности и масштабируемости, уда-

ленные маршрутизаторы могут использовать маршруты по умолчанию для

достижения ядра сети.

Если некоторые сети нуждаются в знании большего количества марш-

рутов, чтобы гарантировать оптимальный выбор, администратор сети должен

принять решение относительно того, принесет ли распространение дополни-

тельной маршрутной информации большую выгоду, чем расширение про-

пускной способности каналов связи, для достижения поставленной цели.

Когда администратор определит минимальный, набор требований к

сети, можно сделать EIGRP более масштабируемым. Два лучших пути сде-

лать это:

– Сконфигурировать суммарные маршруты на выходных интерфейсах

маршрутизаторов на уровне распределения.

– Сконфигурировать удаленные маршрутизаторы как тупиковые EIGRP

маршрутизаторы.

8.2 Использование суммарных маршрутов

Суммарные маршруты резко ограничивают количество запросов, огра-

ничивая количество маршрутизаторов знающих о конкретной подсети. Если

подсеть становится недоступна, запросы распространяются на всех соседей

маршрутизатора, который сделал этот запрос. Если маршрутизатор получив-

ший запрос знает резервный маршрут, он ответит на него и распространение

153

запросов о сети прекратиться. Распространить этот запрос дальше маршрути-

затор получивший его может только в том случае, если он знал точный, а не

суммарный маршрут на запрашиваемую сеть. Если маршрутизатор знает

только суммарный маршрут, то он сразу ответит о недостижимости через

него запрашиваемой сети, так как в таблице маршрутизации присутствует

только суммарный маршрут. Применение суммарных маршрутов резко сни-

жает служебный трафик протокола EIGRP при изменениях в топологии сети.

Применение суммарных маршрутов уменьшает шанс перехода сети в

состояние SIA, поскольку уменьшается количество маршрутизаторов знаю-

щих маршруты до конкретных подсетей, поэтому процесс рассылки запросов

с большей вероятностью прекратится до наступления SIA.

R2 R3

172 .16.0.0/16192.168 .1.0/24



172 .16.1.0/24

Q 172 .16.1.0/24Q 172.16.1.0/24

R 172 .16.1.0/24

Unreachable

R 172.16.1.0/24

Unreachable

r1# interface Serial 0

ip summary-address eigrp 200 172.16.0.0 255.255.0.0

S0 S1

Рисунок 8.2 – Применение суммарных для предотвращения

распространения запросов

На рисунке 8.2 маршрутизатор R1 отсылает только суммарный маршрут

на сеть 172.16.0.0/16 маршрутизатору R2. Если сеть 172.16.1.0/24 станет недо-

ступна, R2 получит запрос от R1 об этой сети. В таблице маршрутизации у R2

есть только запись на весь суммарный маршрут к сети 172.16.0.0/16, а кон-

кретной сети 172.16.1.0/24 в таблице маршрутизации нет, поэтому R2 ответит

о недостижимости сети 172.16.1.0/24.

Если для рассмотренной ранее сети (Рисунок 8.3) применить суммиро-

вание маршрутов на последовательных интерфейсах, то количество запросов

и ответов в сети значительно уменьшится.

В данном примере применение суммарных маршрутов предотвращает

распространение запросов о пропавшей сети 10.1.1.0/24 от удаленных марш-

рутизаторов, и предотвращает наступление SIA на маршрутизаторе R2.

При использовании суммарных маршрутов на выходных интерфейсах

маршрутизаторов R2 и R1, на удаленные маршрутизаторы распространяются

только маршруты на всю сеть 10.0.0.0/8.

Подсеть 10.1.1.0/24 неизвестна удаленным маршрутизаторам, поэтому

они на такой запрос могут ответить только, что им не известна сеть

10.1.1.0/24

154

10.1.1.0/24



Q R

10.0.0.0/810.0.0.0/8

Рисунок 8.3 – Обработка изменений в топологии сети с использованием

суммарных маршрутов

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

сети.

8.3 Использование тупиковых маршрутизаторов

Возможность создания тупиковых EIGRP маршрутизаторов появилась в

ОС Cisco IOS начиная с 12.0(7)T.

Использование тупиковых EIGRP маршрутизаторов улучшает стабиль-

ность сети, уменьшает использование вычислительных и сетевых ресурсов и

упрощает конфигурацию маршрутизаторов.

При использовании данной возможности, только удаленные маршрути-

заторы могут быть сконфигурированы как тупиковые.

Настройка удаленных маршрутизаторов как тупиковых EIGRP маршру-

тизаторов информирует вышестоящие маршрутизаторы о том, что посылать

им запросы не имеет смысла потому, что они не имеют нижестоящих соседей

и не могут знать альтернативных маршрутов.

Тупиковые маршрутизаторы могут иметь соседские отношения только с

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

тизаторов не запрещает им распространять маршруты о сетях непосредствен-

но подключенных к ним, или настроенные на них суммарные и статические

маршруты.

Топология «звезда» наилучшим образом подходит для создания тупи-

ковых маршрутизаторов. В данной топологии удаленный маршрутизатор весь

трафик, который не является локальным передает центральному маршрутиза-

тору. Удаленный маршрутизатор не должен знать таблицы маршрутизации

всей сети, ему достаточно знать маршрут на центральный маршрутизатор. В

топологии «звезда» размещение таблицы маршрутизации всей сети на уда-

155

ленном маршрутизаторе не имеет ни какой технической необходимости, так

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

Для настройки процесса маршрутизации EIGRP как тупикового приме-

няется команда eigrp stub, синтаксис команды приводится в примере 8.1

Пример 8.1 – Синтаксис команды eigrp stub

(config-router)#eigrp stub [receive-only | connected | static | summary |

redistributed]

(config-router)no eigrp stub [receive-only | connected | static | summary |

redistributed]

Описание параметров команды eigrp stub приводиться в таблице 8.1.

Таблица 8.1 – Параметры команды eigrp stub

Параметр Описание

receive-only Ограничивает функции маршрутизато-

ра только получением маршрутов от

других маршрутизаторов. Маршрути-

затор сконфигурированный, данной

командой не рассылает другим марш-

рутизаторам известные ему маршруты.

Любые другие опции при использова-

нии receive–only становятся недоступ-

ны, потому что они предусматривают

рассылку маршрутов во внешнюю

сеть.

connected Опция разрешает рассылку маршрутов

на сети, которые являются непосред-

ственно подключенными к данному

маршрутизатору. Эта опция включает-

ся по умолчанию при конфигурации

тупикового маршрутизатора и являет-

ся наиболее используемой.

static Даная опция позволяет маршрутизато-

ру производить рассылку статических

маршрутов из его таблицы маршрути-

зации. Для корректной работы марш-

рутизатора в данной конфигурации

необходимо присутствие команды re-

distribute static в настройках EIGRP

маршрутизатора

156

Продолжение таблицы 8.1

Параметр Описание

summary Опция позволяет рассылку суммарных

маршрутов. Суммарные маршруты мо-

гут быть настроены вручную при по-

мощи команды summary–address или

автоматически командой auto–sum-

mary. Опция summary включается ав-

томатически.

redistributed Опция позволяет рассылку маршрутов

полученную от других протоколов

маршрутизации. Для корректной рабо-

ты маршрутизатора в данной конфигу-

рации необходима настройка механиз-

мов перераспределения маршрутной

информации от других протоколов

маршрутизации

Команда eigrp stub может конфигурироваться с несколькими опциями,

которые могут использоваться в любой комбинации, за исключением receive-

only. Опция receive-only используется индивидуально.

При использовании технологии тупиковых маршрутизаторов на выше-

стоящих маршрутизаторах не могут автоматически создаваться суммарные

маршруты для тупиковых маршрутизаторов. В протоколе EIGRP администра-

тору сети, если это необходимо, приходиться вручную настраивать суммар-

ные маршруты для тупиковых маршрутизаторов.

10.1.1.0/24



Q R

Рисунок 8.4 – Обработка изменений в топологии сети с использованием

тупиковых маршрутизаторов

157

Использование тупиковых маршрутизаторов в удаленных офисах (Рису-

нок 8.4) позволяет центральным маршрутизаторам немедленно отвечать на

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

сторону удаленных маршрутизаторов. Таким образом, сокращается время

сходимости сети.

Использование тупиковых маршрутизаторов предотвращает проблему,

рассылки удаленными маршрутизаторами маршрутов от центральных марш-

рутизаторов другим маршрутизаторам находящимся в центральной части

сети.

8.4 Использование протокола EIGRP в современных условиях

В настоящее время в сетях передачи данных широкое распространение

получили высокоскоростные каналы передачи данных со скоростями 1Гбит/с

и выше. Также значительно изменился вид передаваемого трафика. Если

раньше это был в основном FTP трафик, трафик почтовых и WEB приложе-

ний, то в настоящее время все большую долю трафика в сетях передачи дан-

ных занимает трафик приложений реального времени, таких как IP-телефония

или видеоконференции.

Исходя из этого, значительно изменились требования к устойчивости и

времени сходимости сети. Если раньше время сходимости сети после произо-

шедших изменений равнявшееся нескольким секундам считалось хорошим, и

ни как не сказывалось на работе приложений, то в настоящее время подобные

задержки могут негативно сказаться на работе приложений реального време-

ни.

Для избегания подобных проблем используется ряд мер: использование

высокоскоростных каналов связи, резервирование каналов связи, а также вне-

сение изменений в работу маршрутизаторов и протоколов маршрутизации с

целью уменьшения времени сходимости сети при обнаружении изменений.

Для протокола EIGRP применяется два основных механизма уменьшения вре-

мени сходимости сети.

Это уменьшение Hello интервала до минимума равного 1 секунде. При-

менение данного механизма может показаться чересчур расточительным с

точки зрения использования пропускной способности каналов связи. Однако

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

дачи данных, при использовании высокоскоростных каналов связи незначи-

тельна.

Вторым методом уменьшения времени сходимости сети является

уменьшение времени реакции маршрутизатора на изменения в состоянии его

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

терфейса из состояния Up в Down и наоборот равно 2 секундам. Минималь-

158

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

мгновенная реакция. Время реакции на переход интерфейса между его состо-

яниями устанавливается независимо на каждом из интерфейсов при помощи

команды carrier-delay синтаксис команды приводится в примере 8.2

Пример 8.2 – Синтаксис команды carrier-delay

(config-if)#carrier-delay [seconds | msec milliseconds]

(config-if)#no carrier-delay [seconds | msec milliseconds]

Описание параметров команды carrier-delay приводиться в таблице 8.2.

Таблица 8.2 – Параметры команды carrier-delay

Параметр Описание

seconds Время реакции в секундах на измене-

ние состояния интерфейса. По умолча-

нию 2 секунды.

msec milliseconds Время реакции в миллисекундах на из-

менение состояния интерфейса. По

умолчанию 50 миллисекунд.

На рисунке 8.5 приводится пример настройки маршрутизаторов с целью

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

r1# interface GigabitEthernet 1

ip hello -interval eigrp 1

ip hold-time eigrp 3

carrier-delay msec 0

GI 1

GI 0

r2# interface GigabitEthernet 0

ip hello-interval eigrp 1

ip hold-time eigrp 3

carrier-delay msec 0

Рисунок 8.5 – Минимизация времени обнаружения изменений

в топологии мети

159

9 Протоколы маршрутизации по состоянию канала

В отличие от протоколов дистанционно-векторной маршрутизации, в

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

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

ным знанием топологии сети передачи данных, исходя из которой, они строят

таблицу маршрутизации.

Чтобы лучше понять различие между дистанционно-векторными алго-

ритмами Беллмана-Форда, алгоритмом DUAL, и алгоритмами маршрутизации

по состоянию канала, взглянем на рисунки 9.1 – 9.3.

СП1

СП2 СП3

СП4

СП7

СП5СП6

2522

Рисунок 9.1 – Представление топологии сети

алгоритмом Беллмана-Форда

На рисунке. 9.1 изображено представление топологии сети передачи

данных маршрутизатором R1, который использует один из вариантов дистан-

ционно-векторного алгоритма Беллмана-Форда. Маршрутизатор имеет ин-

формацию только о сетях получателях, показанных в виде сегментов Ethernet,

о том, как далеко и в каком направлении они находятся.

На рисунке. 9.2 изображено представление той же сети передачи дан-

ных маршрутизатором R1, но на этот раз маршрутизатор использует протокол

маршрутизации на основе алгоритма DUAL. Маршрутизатор знает о своих

непосредственных соседях, о том, насколько далеко и в каком направлении

они расположены, а также дистанции от соседей до всех известных сетей по-

лучателей.

160