Optimizing EIGRP Implementations — различия между версиями
imported>Artem |
imported>Artem (→Масштабируемость EIGRP в больших сетях) |
||
| Строка 3: | Строка 3: | ||
==Масштабируемость EIGRP в больших сетях== | ==Масштабируемость EIGRP в больших сетях== | ||
| − | Работа (operation) одной большой flat<ref name="flat">[http://en.wikipedia.org/wiki/Flat_network Flat network ], </ref> EIGRP | + | Работа (operation) одной большой flat<ref name="flat">[http://en.wikipedia.org/wiki/Flat_network Flat network ], </ref> EIGRP is normally not scalable. Некоторые issues, которые необходимо рассмотреть: |
| + | *Большие таблицы маршрутизации, которые должны быть обработаны. | ||
| + | *Из-за больших таблиц (маршрутизации, соседей) большие требования к памяти. | ||
| + | *Большие требования к полосе пропускания из-за большого числа обновлений маршрутизации, отправки множества запросов и ответов в пределах домена EIGRP (учитывая наличие медленных каналов и некоторого числа ошибок передачи). | ||
Сетевые администраторы должны понимать способы конструирования и настройки сетей EIGRP для развертывания эффективных масштабируемых сетей. | Сетевые администраторы должны понимать способы конструирования и настройки сетей EIGRP для развертывания эффективных масштабируемых сетей. | ||
Некоторые из многих факторов, влияющих на масштабируемость: | Некоторые из многих факторов, влияющих на масштабируемость: | ||
| − | *'''Объем информации о маршрутах'''. Если трафик маршрутизации между EIGRP-соседями потребляет полосу канала выше, чем необходимо для правильного функционирования маршрутизации, то маршрутизаторы медленнее реагируют на изменения в сети. | + | *'''Объем информации о маршрутах '''(amount of information exchanged between neighbor). Если трафик маршрутизации между EIGRP-соседями потребляет полосу канала выше, чем необходимо для правильного функционирования маршрутизации, то маршрутизаторы медленнее реагируют на изменения в сети. |
*'''Количество маршрутизаторов'''. Потребление ресурсов протоколом EIGRP при изменениях топологии сети прямо пропорционально количеству маршрутизаторов, которые должны изучить эти изменения. | *'''Количество маршрутизаторов'''. Потребление ресурсов протоколом EIGRP при изменениях топологии сети прямо пропорционально количеству маршрутизаторов, которые должны изучить эти изменения. | ||
| − | *'''Глубина топологии'''. Глубина топологии может влиять на время сходимости. Глубина топологии - это число hop-ов | + | *'''Глубина топологии''' (the topology's depth). Глубина топологии может влиять на время сходимости. Глубина топологии - это число hop-ов, через которые должна пройти информация для того, чтобы достигнуть все маршрутизаторы. |
| − | *'''Количество альтернативных маршрутов в сети'''. Сеть должна предоставлять альтернативные маршруты во избежание появления точек отказа. Однако, слишком большое количество резервных маршрутов может привести к проблемам сходимости, т.к. EIGRP использует запросы для | + | Например, multinational network без суммирования маршрутов, имею большую глубину (depth), что увеличивает время конвергенции. |
| + | |||
| + | Трехуровневая структура сети (см. [[Сетевые_модели]]) является наиболее рекомендуемой для любого окружения с IP-маршрутизацией. Между любыми двумя маршрутизаторами в сети должно быть не более семи hop-ов. Иначе время конвергенции при изменениях в сети вырастет из-за задержек распространения информации. | ||
| + | |||
| + | *'''Количество альтернативных маршрутов в сети'''. Сеть должна предоставлять альтернативные маршруты во избежание появления точек отказа. Однако, слишком большое количество резервных маршрутов может привести к проблемам сходимости, т.к. EIGRP использует запросы для обнаружения всех возможных маршрутов (вместо пропавших). Эта сложность создает идеальные условия для перехода маршрута в режим SIA (stuck in active - застрял в активном режиме) - ждущего ответы на запросы, отправленные им через множество альтернативных путей. | ||
| + | |||
| + | При внедрении протокола маршрутизации EIGRP должны быть решены некоторые проектировочные проблемы. Три основных: | ||
| + | *Размер топологической и таблицы маршрутизации, на которые влияет число соседей. | ||
| + | *Число изменений в сети. | ||
| + | *Загрузка WAN-каналов протоколом EIGRP. | ||
| + | |||
| + | Эти три главных фактора диктуют дизайн EIGRP, требуя ввода границ распространения запросов (использованием суммирования, редистрибуции и т.д.). Без определения границ, запросы будут распространяться через весь домен EIGRP, и очень скоро все маршрутизаторы будут вовлечены в расчёты DUAL, в результате чего вырастет использование п/п и CPU. Частые расчёты будут влиять на все таблицы, используемые маршрутизаторами, включая таблицы EIGRP и кэш процесса пренаправления (caches built during the forwarding process). | ||
==EIGRP-запросы и Stuck-in-Active== | ==EIGRP-запросы и Stuck-in-Active== | ||
Версия 13:23, 16 февраля 2012
EIGRP это масштабируемый протокол маршрутизации, гарантирующий, что даже при быстром росте сети, он будет работать эффективно и быстро подстраиваться под изменения. Данная статья описывает практические, особые для EIGRP, методы для реализации эффективной, масштабируемой корпоративной сети.
Содержание
Масштабируемость EIGRP в больших сетях
Работа (operation) одной большой flat<ref name="flat">Flat network , </ref> EIGRP is normally not scalable. Некоторые issues, которые необходимо рассмотреть:
- Большие таблицы маршрутизации, которые должны быть обработаны.
- Из-за больших таблиц (маршрутизации, соседей) большие требования к памяти.
- Большие требования к полосе пропускания из-за большого числа обновлений маршрутизации, отправки множества запросов и ответов в пределах домена EIGRP (учитывая наличие медленных каналов и некоторого числа ошибок передачи).
Сетевые администраторы должны понимать способы конструирования и настройки сетей EIGRP для развертывания эффективных масштабируемых сетей.
Некоторые из многих факторов, влияющих на масштабируемость:
- Объем информации о маршрутах (amount of information exchanged between neighbor). Если трафик маршрутизации между EIGRP-соседями потребляет полосу канала выше, чем необходимо для правильного функционирования маршрутизации, то маршрутизаторы медленнее реагируют на изменения в сети.
- Количество маршрутизаторов. Потребление ресурсов протоколом EIGRP при изменениях топологии сети прямо пропорционально количеству маршрутизаторов, которые должны изучить эти изменения.
- Глубина топологии (the topology's depth). Глубина топологии может влиять на время сходимости. Глубина топологии - это число hop-ов, через которые должна пройти информация для того, чтобы достигнуть все маршрутизаторы.
Например, multinational network без суммирования маршрутов, имею большую глубину (depth), что увеличивает время конвергенции.
Трехуровневая структура сети (см. Сетевые_модели) является наиболее рекомендуемой для любого окружения с IP-маршрутизацией. Между любыми двумя маршрутизаторами в сети должно быть не более семи hop-ов. Иначе время конвергенции при изменениях в сети вырастет из-за задержек распространения информации.
- Количество альтернативных маршрутов в сети. Сеть должна предоставлять альтернативные маршруты во избежание появления точек отказа. Однако, слишком большое количество резервных маршрутов может привести к проблемам сходимости, т.к. EIGRP использует запросы для обнаружения всех возможных маршрутов (вместо пропавших). Эта сложность создает идеальные условия для перехода маршрута в режим SIA (stuck in active - застрял в активном режиме) - ждущего ответы на запросы, отправленные им через множество альтернативных путей.
При внедрении протокола маршрутизации EIGRP должны быть решены некоторые проектировочные проблемы. Три основных:
- Размер топологической и таблицы маршрутизации, на которые влияет число соседей.
- Число изменений в сети.
- Загрузка WAN-каналов протоколом EIGRP.
Эти три главных фактора диктуют дизайн EIGRP, требуя ввода границ распространения запросов (использованием суммирования, редистрибуции и т.д.). Без определения границ, запросы будут распространяться через весь домен EIGRP, и очень скоро все маршрутизаторы будут вовлечены в расчёты DUAL, в результате чего вырастет использование п/п и CPU. Частые расчёты будут влиять на все таблицы, используемые маршрутизаторами, включая таблицы EIGRP и кэш процесса пренаправления (caches built during the forwarding process).
EIGRP-запросы и Stuck-in-Active
SIA соединения в EIGRP
Препятствие SIA связи
EIGRP Query Range
Limiting EIGRP Query Range
Limiting EIGRP Query Range
Limiting Query Range Using a Stub
Graceful Shutdown
Gracefull Shutdown (дословно: изящное выключение), использующее goodbay-сообщения, призвано улучшить сходимость EIGRP-сети. Gracefull shutdown предотвращает потерю пакетов при выключении маршрутизатора.
На рисунке показано, как маршрутизатор A использует B в качестве преемника для нескольких маршрутов. Маршрутизатор С - является возможным преемником для тех же маршрутов. В обычном режиме B не сообщает A о выключении EIGRP процесса. A вынужден ждать пока истечет hold-таймер, прежде чем он обнаружит изменения и отреагирует на них. Пакеты, посланные в этот период времени будут утеряны.
При использовании gracefull shutdown, маршрутизатор широковещательно рассылает goodbay-сообщения перед выключением EIGRP-процесса, информируя соседей о предстоящем изменении топологии. Эта функция позволяет EIGRP-соседям более эффективно синхронизироваться и пересмотреть соседские отношения.
Goodbay-сообщения поддерживаются IOS 12.3(2), 12.3(3)B, 12.3(2)T и более поздними. Goodbay-сообщение встраивается в hello-пакет. EIGRP посылает goodbay-сообщение устанавливая значения весовых коэффициентов K1 - K5 равными 255. При получении goodbay-сообщения маршрутизатор выводит следующее:
R1# *Mar 1 00:02:43.331: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.0.2 (FastEthernet0/0) is down: Interface Goodbye received
Маршрутизаторы Cisco, не поддерживающие goodbay-сообщения, не принимают во внимание значения коэффициентов K1-K5=255. В этом случае выводится сообщение о неправильном значении весовых коэффициентов (K-value mismatch). Но это не нарушает сетевые операции. Маршрутизатор закрывает сессию по истечении hold-таймера. Соседские отношения нормально возобновляются после запуска EIGRP на отправителе.
Примечания
<references />