В данной статье поговорим о EIGRP и обсудим принципы работы данного протокола. EIGRP является дистанционно-векторным протоколом, иногда говорят о его гибридности, но это не так. Почитайте начало статьи о OSPF и вы поймете почему EIGRP именно дистанционно-векторный протокол. EIGRP — усовершенствованный дистанционно-векторный протокол динамической маршрутизации, разработанный компанией Cisco. Начнем разбираться. Будем использовать следующую топологию:
Запустим EIGRP на vIOS1 и на vIOS2, посмотрим как передается информация между маршрутизаторами. Как только на маршрутизаторе активируется EIGRP, то маршрутизатор начинает отправлять Hello пакеты. Перечислим также другие типы сообщений, которые используются в EIGRP.
Также существуют SIA пакеты, но о них поговорим ниже.
Пакеты отправляются на multicast адрес 224.0.0.10 каждые 5 секунд (Hello Timer), Hold Timer равен 15 секунд = 3 hello-интервала, если в течении этого таймера ни один hello пакет не был получен от соседа, то сосед удаляется из списка соседей. Пакет выглядит так:
Пакет содержит в себе параметры коэффициентов (K1, K2, K3, K4, K5, K6), Таймер Hold Time и номер Autonomous System. Коэффициенты (K1, K2, K3, K4, K5, K6) используются при подсчете метрики и о них мы поговорим позже, как и о таймерах EIGRP. Сейчас важно поговорить о Autonomous System (AS). Для активации EIGRP, определенному процессу EIGRP необходимо присвоить номер, как и в OSPF. Но в отличии от OSPF, данный параметр нельзя выбирать случайно для каждого маршрутизатора, он должен совпадать у всех маршрутизаторов. Если маршрутизатор получит Hello-пакет с AS отличным, чем у него, то отношения соседства не будет.
Для того чтобы маршрутизаторы стали соседями должны выполняться такие условия:
Для того, чтобы маршрутизаторы стали EIGRP-соседями, у них не обязаны совпадать Hello и Hold time. Маршрутизатор использует значения таймеров, полученные от соседа. Если на одном из маршрутизаторов изменены Hello или Hold timer, то соседи этого маршрутизатора будут использовать эти значения. Для того, чтобы сам маршрутизатор использовал другие значения, необходимо изменить таймер на соответствующем интерфейсе соседа. После обмена Hello-пакетами, отправляется Update пакет, но он еще не содержит маршруты, там содержится флаг Init, который говорит маршрутизаторам о начале обмена информации о маршрутах. Данный пакет отправляется, непосредственно, на адрес маршрутизатора. После обмена такими сообщениями, каждый маршрутизатор рассылает Update пакет с маршрутами на мультикаст адрес 224.0.0.10:
Как видите в Update пакете не содержится какая-либо метрика, а только информация типа Bandwidth, Delay, MTU и т.д., получив данную информацию, маршрутизатор сам высчитывает метрику по коэффициентам K1-K6. Данные пакеты могут отправлятся как к конкретному маршрутизатору, так и мультикастовой расслыкой. В целом, есть три типа обновлений:
Установление соседства на уровне пакетов выглядит так:
Можно заметить, что помимо перечисленных нами Hello и Update, присутствуют также Hello (ACK) и количество равно количеству Update пакетов, отправленных на мультикастовый адрес. Все дело в протоколе RTP. Протокол RTP управляет процессом передачи пакетов EIGRP и обеспечивает:
Вот такие дела. Что мы имеем? Маршруты обменялись Update пакетами и теперь пришло время строить таблицу маршрутизации. Каждый update обрабатывается и подставляя данные ( Bandwidth, Delay и т.д ) в специальную формулу, вычисляется метрика:
Вот такая формула, выглядит устрашающе, но самое хорошее в ней, что ее можно не знать, просто знать что что-то такое существует. И еще одна приятная фишка в том, что по умолчанию коэффициенты EIGRP такие:
И формула превращается просто в metric = bandwidth + delay. Поэтому так важно, чтоб на всех маршрутизаторах коэффициенты были одинаковые, чтоб не было проблем из-за различных метрик на маршрутизаторах. Поговорим о данных в Update еще чуть более подробней.
Как сказали выше, по умолчанию используют bandwidth и delay. Остальные параметры редко, когда бывают нужны, но при помощи них возможна более тонкая настройка метрики. Таким образом, в Update пакете маршрутизатор передает маршрут и связанные с ним данные, саму метрику не передает. Маршрутизатор, получивший Update, по формуле вычисляет метрику и, в зависимости от метрик, принимает решение помещать маршрут в таблицу маршрутизации или нет. Также важно заметить, что маршрутизатор передает только те маршруты, которые сам использует. Посмотрим как же строиться таблица топологии.
Таблица топологии (topology table) — список маршрутов выученных от каждого соседа. В таблице топологии также хранится метрика, которую сообщает каждый сосед для каждого маршрута (AD) и метрика, которую локальный маршрутизатор будет использовать для того чтобы достигнуть маршрут через соседа (FD).
Надо пояснить, что такое AD и FD. Настроим EIGRP на всех наших маршрутизаторах. Также, чтоб избежать сложных чисел в метрике, изменим коэффициенты с K1 = 1 K2 = 0 K3 = 1 K4 = 0 K5 = 0 на K1 = 0 K2 = 0 K3 = 1 K4 = 0 K5 = 0. Тем самым, у нас будет формула 256*Delay и также мы получаем легкий способ манипуляцией метриками при помощи изменения параметра delay на интерфейсах. Учитывая, что на интерфейсах delay = 1 sec, то каждый линк, если пользоваться терминологией OSPF, стоит 256. Посмотрим какова таблица топологии на vIOS1:
Если взглянуть, например, на сеть — 192.168.5.0/24, можно заметить три пути через vIOS2, vIOS3 и vIOS4 с одинаковыми метриками. Для 192.168.5.0/24 FD по всем путям равно — 768, а AD — 512. Дадим определение из другой статьи и попытаемся объяснить:
Изучим данную строку из таблицы топологии на vIOS1. vIOS1 узнал о маршруте от vIOS4 (192.168.14.4). Так как vIOS1 отделяет от 192.168.5.0/24 три линка, то и метрика FD с нашими настройками будет равна 3*256=768. А AD — это метрика маршрута относительно маршрутизатора (vIOS4), который анонсировал данную сеть. AD — это метрика FD данного маршрута на vIOS4. Посмотрим на таблицу топологии на vIOS4:
AD на vIOS1 = FD на vIOS4. Немого запутанно, но постараемся объяснить логику работы. Маршрутизатор, который анонсирует маршрут, отправляет параметры (Bandwithd, Delay и т.д.) маршрута в Update сообщении без учета линка между маршртузатором, которому делается анонс. То есть, vIOS4 учитывает только параметры двух линков: vIOS4 Gi0/1 — vIOS5 Gi0/1 и vIOS5 Gi0/0 — VPC. Получив Update, vIOS1, подставляя полученные параметры в формулу, рассчитывает что? Правильно — AD =512. После берет параметры линка, откуда пришел маршрут, vIOS1 Gi0/2 — vIOS4 Gi0/2 и подставляет опять в формулу. Считает, получает число 256 и складывает с AD (512), получаем FD — 768. Вот такие дела! Но для чего весь этот ритуал?
А все для того, что создать специальное правило под названием Feasible condition, который является одним из средств по защите от образования петель и быстрой сходимости.
Дадим определения следующих терминов:
Чтоб объяснить как это все работает и показать тонкости, надо поменять некоторые метрики. Сделаем следующее, поменяем delay так, чтоб у нас были такие метрики линков:
Делается это при помощи команды delay на интерфейсе. Сейчас у нас как было сказано — delay = 1 и метрика равна 256. Посмотрим какие метрики у нас получаться для сети 192.168.5.0/24 на маршрутизаторе vIOS1:
Как мы видим лучший FD будет у маршрута через vIOS4, он и будет добавлен в общую таблицу маршрутизации, такой маршрут называется Successor:
Что будет с остальными двумя маршрутами — они будут проверены на условие FS (Feasible condition). Маршрут через vIOS3 проходит это условие AD (via vIOS3) = 768 < 1024 = FD (via vIOS1). Поэтому данный маршрут хоть и не будет добавлен в общую таблицу маршрутизации, он будет храниться в таблицы топологии:
Он не обладает метрикой лучшего маршрута, то есть не является Successor-ом, но играет роль запасного маршрута и, при потери Successor-а, сразу займет его место. Этим достигается очень быстрая сходимость протокола, но об этом по подробней позже. Такой маршрут называется Feasible successor. А что будет с третьим маршрутом? Ничего, он не удовлетворяет условию FC (1280 > 1024) и не будет учитываться в целях защиты от образования петли. Все маршруты, полученные через Update, но не прошедшие проверку FC, можно увидеть при помощи команда show ip eigrp topology all-links. Не совсем очевидно почему условие FS защищает от образования петель, сейчас попытаемся объяснить. Важно знать, что при изучении протокола EIGRP жизненно важно понимать принцип условия FC и цели для которых он используется. Рассмотрим немного видоизмененную топологию ( добавлен линк между vIOS2 и vIOS4), а также используем максимально примитивную метрику:
Маршрут до сети 192.168.5.0/24 будет таким с AD и FD:
Но vIOS4 получит обновление от vIOS2, где будет содержаться маршрут до сети 192.168.5.0/24 через vIOS2 с метрикой — AD=12, FD=15. Понятно, что Successor-ом он быть не может, если бы вдруг данный маршрут был бы выбран Feasible Successor-ом, то при падении Successor-а на vIOS4 и последующим выбором Successor-ом данного маршрута, произошла бы петля. Но FC не позволит установить данный маршрут в качестве FS так, как AD=12 > 10=FD. Маршрут на vIOS2 содержит в себе путь через vIOS4 и в любом случае в его AD входит также FD vIOS4. То есть, AD на vIOS2 содержит в себе следующие линки:
Таким образом, условие FС проверяет маршрут на наличие самого себя в данном маршруте. Только маршруты, которые удовлетворяют данному условию, могут гарантировать, что петли нет. Могут быть случаи, когда маршрут не создает петлю, но при этом и не удовлетворяет условию FC, мы его не будем использовать, в таких случае мы выбираем стабильность сети. Если вникнуть, то условие довольно простое и интуитивно понятное. Алгоритм, по которому выбирается лучшие маршруты в протоколе EIGRP, называется DUAL. Теперь рассмотрим протокол EIGRP на вопрос сходимости при потере основого маршрута. Вернемся к нашей старой большой топологии и представим, что vIOS4 пропал. В зависимости от того, как пропал vIOS4 поведение будет немного разным, но отличаться будет тем, когда сработает триггер. Если, например, мы отключим интерфейс Gi 0/2 на vIOS1, то vIOS1 сразу детектирует потерю соседа и начнет действовать, если же сосед пропадет без предупреждений, то сработает Hold Timer после того, как не получит Hello-пакеты в течении 15 секунд:
Привел таблицу маршрутизации и топологии еще раз для удобства так, как чтоб понять как будет действовать маршрутизатор по каждому маршруту необходимо знать в каком состоянии они находились до этого. Например, обсуждаемый нами ранее, маршрут 192.168.5.0/24 будет потерян, но в таблиции топологии у него был FS и поэтому как только произойдет детект потери основого маршрута, он займет место в таблице маршрутизации. Интересен вопрос, что будет с маршрутами без FS. Но немного матчасти:
Записи в таблице топологии могут находиться в двух состояниях: active и passive. Маршрут находится в состоянии passive, когда маршрут стабилен и не происходит поиск лучшего маршрута. В состоянии active — если выполняется поиск лучшего маршрута. Поиск маршрута выполняется, когда для сети назначения нет feasible successor. Маршрутизатор в поисках лучшего маршрута отправлят запрос (отправляет query packet) каждому соседнему маршрутизатору. Если у соседа есть маршрут к сети назначения, то он отвечает (отправляет reply packet), если маршрута нет — сосед отправляет запрос своим соседям. Маршрутизатор сравнивает все FD для достижения конкретной сети, выбирает маршрут с наименьшим FD и помещает его в таблицу маршрутизации. В таблице топологии может хранится 6 маршрутов к сети получателя (основной и запасные).
Маршруты, которые были утеряны и не имели FS, перейдут в состоянии Active и vIOS1 начнет распрашивать о них у оставшихся соседей. Делается это при помощи сообщений Query. vIOS1 отправит Query сообщения маршрутизаторам vIOS2 и vIOS3, где явно укажет какие маршруты ему необходимы — в нашем случае такими маршрутами будут 192.168.14.0/24, 192.168.45.0/24. Этим сообщением vIOS1 также сообщает маршрутизаторам, что маршруты через vIOS1 к этим сетям непригодны. Делается это при помощи указания в метрике данного маршрута параметра Delay:Infifnity, то есть метрика бесконечно большая. Как только маршрутизаторы получат такое сообщения, то удалят данные маршруты через vIOS1. Это технология называется Poison Reverse. Poison Reverse также используется при сообщениях Update, чуть позже расскажу об этом. После получения Query с запросом на маршруты 192.168.14.0/24, 192.168.45.0/24, vIOS2 и vIOS3 посмотрят, есть ли у них данные маршруты, которые они используют, если есть, то сразу отправят Reply с новыми метриками для данных маршрутов. vIOS2 и vIOS3 как мы знаем не потеряли свои маршруты, поэтому сразу отправят Reply. Если же у маршрутизатора, которого спрашивают также нет данного маршрута, то он перешлет Query дальше своим соседям и так далее. vIOS1 будет ждать Reply от vIOS2, vIOS3 и тут на сцену выходит Active Timer, который запустится как только Query будет отправлен:
Active Timer — интервал времени в течение которого маршрут может оставаться в состоянии active. Если таймер истечет до тех пор как будут получены все ответы от соседей (Reply), то маршрутизатор переводит маршрут в состояние stuck-in-active. Кроме того, разрываются отношения соседства с теми соседями, от которых не был получен ответ. По умолчанию данный таймер равен 3 минутам.
То есть, если в течении 3 минут не будет получен Reply, несмотря на Hello-пакеты, соседство будет разорвано и это очень плохо. Несмотря на то, что 3 минуты вроде вечность для таких протоколов, такие ситуации возможны при больших топологиях. Для защиты от ошибочного разрыва отношения соседства были придуманы специальные сообщения — SIA-Query и SIA-Reply.
Для улучшения реагирования маршрутизатора на состояние active маршрута, дополнительно введены два типа сообщений:
После 1,5 минуты, если не получен Reply на какой-либо Query, то отправляется SIA-Query, который не требует дать новый маршрут, а требует только отправить SIA-Reply, чтоб убедиться, что сосед в порядке, просто не может найти нужный маршрут.
Думаю о том, как маршрутизатор реагирует на потерю маршрута в случае, когда есть FS или нет, мы сказали достаточно. Только необходимо внести правки в следующее. Мы не совсем правильное дали определение для FD, метрику которую мы рассчитываем по формуле при первом получении маршрута или при дальнейшем изменения состояния маршрута, правильно было бы называть CD — Computed Distance.
FD — это наилучший показатель для данного маршрута, который когда-либо получался и именно он учавствует при проверке FC. Чаще всего, FD=CD лучшего маршрута, но давайте посмотрим как поменялся FD после обрыва сосесдства с vIOS4:
У нас больше нет маршрута с CD=1024, самый лучший маршрут через vIOS3 имеет CD=1536, но как видите FD=1024, который был зафисикрован при наличии маршрута через vIOS4. FD обновится только в том случае, когда данный маршрут перейдет в состояние Active. Пока не менялось состояние с Passive на Active, то и FD не поменяется. Обычные обновления на него не действуют. Еще одно замечание. Давайте проведем такой эксперимент: вернем соседство с vIOS4, CD через vIOS3= 1536, а через vIOS2 = 2048. Увеличим delay канала между vIOS1 и vIOS3 так, чтоб стало больше чем CD vIOS2:
Как видим CD через vIOS3=2304, но он остался FS так, как AD не поменялось и условие FC пройдено, как и раньше. Зададимся вопросом: Что будет при потери маршрута через vIOS2? Ожидаемый и логичный ответ, как нас учили — вместо него встанет FS, но нет! Так как существует еще маршрут через vIOS2 имеет CD = 2048 < 2304, то маршрут перейдет в состояние Active и заново пересчитает для него метрику и выберет лучший маршрут несмотря на то, что у него был резервный маршрут. Смотрим таблицу топологии и получаем:
Использоваться будет маршрут через vIOS2 и как заметили FD также поменялся из-за перехода маршрута в состояние Active. А маршрут через vIOS3 опять разделяет участь запасного.
Как и в RIP, в EIGRP используется правило Split Horizon — если маршрут достижим через определенный интерфейс, то в обновление, которое отправляется через этот интерфейс не включается этот маршрут.
Например, vIOS4 получив маршрут до сети 192.168.0.0/24 от vIOS1, не отправит данный маршрут в Update через интерфейс, к которому подключен vIOS1. Если быть наиболее точным, то представим, что vIOS1 начал рассказывать о сети 192.168.0.0/24. Отправил Update к vIOS4, vIOS4 получит его и по правило Split Horizon не должен отправлять его Update с этим маршрутом к vIOS1, но в действительности он отправит его с указанием бесконечной метрики. Как бы vIOS4 говорит vIOS1- «Не смей использовать маршрут до сети 192.168.0.0/24 через меня, я получил этот маршрут от тебя и если будешь использовать, то будет петля».
Poison Reverse — указание маршрута недостижым при помощи метрики при его потери. В EIGRP это делается при помощи параметра Delay. Мы указывали выше, как используется данная технология, когда vIOS1 терял связь c vIOS4. Из сказанного выше о Split Horizon можно сделать вывод, что технология Poison Reverse используется не только Query сообщениях, но и в Update. Также Poison Reverse может нарушать правило Split Horizon и отправлять Update с бесконечной метрикой с интерфейса, с которого получил данное обновление. Данные два правила вместе с условием FC обеспечивают протоколу EIGRP защиту от петель.
В качестве оптимизации работы, в протоколе ввели специальную роль для маршрутизаторов — Stub. Чем-то напоминает Stub зоны в OSPF, но здесь немного иной принцип работы. При настройке маршрутизатора в режиме stub, он сразу сообщает в Hello-пакетах своему соседу о своем stub статусе и, в зависимости от режима stub, может отправлять определенные типы маршрутов:
Опции команды eigrp stub:
Но главная фишка данной настройки в том, что, если маршрутизатор знает, что его сосед в роли Stub, то он ему не отправит Query для маршрутов, которые стали Active. Например, если настроим vIOS5 как Stub, то vIOS2-4 узнают об этом и при потери маршрутов не будут отравлять Query. Учитывая какие проблемы могут возникать при отсутствии Reply, то хорошо бы отправлять Query только туда, куда имеет смысл. Это важно в больших топологиях, где сходимость может быть сложным процессом. Поэтому, если есть маршрутизатор, который является конечным и к нему подключены только пользовательские сети (условно говоря у него только один сосед), то лучше задуматься о том, чтоб настроить его в качестве Stub.
О некоторых из мы говорили, если посмотреть вывод команды show ip eigrp neighbors, то увидим следующее:
Тут указаны таймеры, которые требуют пояснения. Если в ответ на отправку любого multicast-пакета, который требует подтверждения о получении, не было отправлено подтверждение (ACK), то будет передаваться unicast пакет соседу, который не отвечает. Если подтверждение не было получено и после того, как отправлено 16 unicast пакетов, то сосед считается неактивным.
На этом думаю закончить статью. Внизу полезный ссылки:
Запустим EIGRP на vIOS1 и на vIOS2, посмотрим как передается информация между маршрутизаторами. Как только на маршрутизаторе активируется EIGRP, то маршрутизатор начинает отправлять Hello пакеты. Перечислим также другие типы сообщений, которые используются в EIGRP.
- Hello — маршрутизаторы используют hello-пакеты для обнаружения соседей. Отправляются multicast пакеты и не требуют подтверждения о получении.
- Update — содержится информация об изменении маршрутов. Они отправляются только маршрутизаторам, которых касается обновление. Эти пакеты могут быть отправлены конкретному маршрутизатору (unicast) или группе маршрутизаторов (multicast). Получение update-пакета подтверждается отправкой ACK.
- Query — когда маршрутизатор выполняет подсчет маршрута и у него нет feasible successor, он отправляет query-пакет своим соседям для того чтобы определить нет ли feasible successor для этого destination у них. Обычно query-пакеты отправляются multicast, но могут быть и unicast. Получение query-пакета подтверждается отправкой ACK получателем пакета.
- Reply — маршрутизатор отправляет reply-пакет в ответ на query-пакет. Reply-пакеты отправляются unicast тому, кто отправил query-пакет. Получение reply-пакета подтверждается отправкой ACK.
- ACK — пакет, который подтверждает получение пакетов update, query, reply. ACK-пакеты отправляются unicast и содержат в себе acknowledgment number. Фактически это hello-пакеты, которые не передают данных. Используется негарантированная доставка.
Также существуют SIA пакеты, но о них поговорим ниже.
Пакеты отправляются на multicast адрес 224.0.0.10 каждые 5 секунд (Hello Timer), Hold Timer равен 15 секунд = 3 hello-интервала, если в течении этого таймера ни один hello пакет не был получен от соседа, то сосед удаляется из списка соседей. Пакет выглядит так:
Пакет содержит в себе параметры коэффициентов (K1, K2, K3, K4, K5, K6), Таймер Hold Time и номер Autonomous System. Коэффициенты (K1, K2, K3, K4, K5, K6) используются при подсчете метрики и о них мы поговорим позже, как и о таймерах EIGRP. Сейчас важно поговорить о Autonomous System (AS). Для активации EIGRP, определенному процессу EIGRP необходимо присвоить номер, как и в OSPF. Но в отличии от OSPF, данный параметр нельзя выбирать случайно для каждого маршрутизатора, он должен совпадать у всех маршрутизаторов. Если маршрутизатор получит Hello-пакет с AS отличным, чем у него, то отношения соседства не будет.
Для того чтобы маршрутизаторы стали соседями должны выполняться такие условия:
- маршрутизаторы должны пройти аутентификацию,
- маршрутизаторы должны быть в одной AS,
- отношения соседства должны устанавливаться на primary-адресах (когда приходит hello-пакет, маршрутизатор проверяет принадлежит ли адрес отправителя сети на primary-адресе интерфейса),
- должны совпадать значения K-коэффициентов.
Для того, чтобы маршрутизаторы стали EIGRP-соседями, у них не обязаны совпадать Hello и Hold time. Маршрутизатор использует значения таймеров, полученные от соседа. Если на одном из маршрутизаторов изменены Hello или Hold timer, то соседи этого маршрутизатора будут использовать эти значения. Для того, чтобы сам маршрутизатор использовал другие значения, необходимо изменить таймер на соответствующем интерфейсе соседа. После обмена Hello-пакетами, отправляется Update пакет, но он еще не содержит маршруты, там содержится флаг Init, который говорит маршрутизаторам о начале обмена информации о маршрутах. Данный пакет отправляется, непосредственно, на адрес маршрутизатора. После обмена такими сообщениями, каждый маршрутизатор рассылает Update пакет с маршрутами на мультикаст адрес 224.0.0.10:
Как видите в Update пакете не содержится какая-либо метрика, а только информация типа Bandwidth, Delay, MTU и т.д., получив данную информацию, маршрутизатор сам высчитывает метрику по коэффициентам K1-K6. Данные пакеты могут отправлятся как к конкретному маршрутизатору, так и мультикастовой расслыкой. В целом, есть три типа обновлений:
- Непериодические (Nonperiodic) — обновления отправляются не через регулярные интервалы времени, а при изменении топологии или метрики;
- Частичные (Partial) — в обновлениях передается не вся информация из таблицы маршрутизации, а только изменения;
- Ограниченные (Bounded) — обновления отправляются только задействованным маршрутизаторам.
Установление соседства на уровне пакетов выглядит так:
Можно заметить, что помимо перечисленных нами Hello и Update, присутствуют также Hello (ACK) и количество равно количеству Update пакетов, отправленных на мультикастовый адрес. Все дело в протоколе RTP. Протокол RTP управляет процессом передачи пакетов EIGRP и обеспечивает:
- Гарантированную доставку пакетов.
- Сохранение порядка пакетов.
Вот такие дела. Что мы имеем? Маршруты обменялись Update пакетами и теперь пришло время строить таблицу маршрутизации. Каждый update обрабатывается и подставляя данные ( Bandwidth, Delay и т.д ) в специальную формулу, вычисляется метрика:
Вот такая формула, выглядит устрашающе, но самое хорошее в ней, что ее можно не знать, просто знать что что-то такое существует. И еще одна приятная фишка в том, что по умолчанию коэффициенты EIGRP такие:
- K1 = 1
- K2 = 0
- K3 = 1
- K4 = 0
- K5 = 0
И формула превращается просто в metric = bandwidth + delay. Поэтому так важно, чтоб на всех маршрутизаторах коэффициенты были одинаковые, чтоб не было проблем из-за различных метрик на маршрутизаторах. Поговорим о данных в Update еще чуть более подробней.
- Bandwidth — выбирается и отправляется в Update минимальное значение среди bandwidth каналов ведущих к сети.
- Delay — Суммируется Delay всех каналов, ведущих к данной сети.
- Reliability — наихудший показатель надежности на всем пути, на основании keepalive
- Loading — наихудший показатель загрузки линка на всем пути, на основании packet rate и настроенной bandwidth на интерфейсе
- MTU — наименьшее MTU на всем пути. Несмотря, что он используется в Update, в самом расчете метрики он не учавствует.
Как сказали выше, по умолчанию используют bandwidth и delay. Остальные параметры редко, когда бывают нужны, но при помощи них возможна более тонкая настройка метрики. Таким образом, в Update пакете маршрутизатор передает маршрут и связанные с ним данные, саму метрику не передает. Маршрутизатор, получивший Update, по формуле вычисляет метрику и, в зависимости от метрик, принимает решение помещать маршрут в таблицу маршрутизации или нет. Также важно заметить, что маршрутизатор передает только те маршруты, которые сам использует. Посмотрим как же строиться таблица топологии.
Таблица топологии (topology table) — список маршрутов выученных от каждого соседа. В таблице топологии также хранится метрика, которую сообщает каждый сосед для каждого маршрута (AD) и метрика, которую локальный маршрутизатор будет использовать для того чтобы достигнуть маршрут через соседа (FD).
Надо пояснить, что такое AD и FD. Настроим EIGRP на всех наших маршрутизаторах. Также, чтоб избежать сложных чисел в метрике, изменим коэффициенты с K1 = 1 K2 = 0 K3 = 1 K4 = 0 K5 = 0 на K1 = 0 K2 = 0 K3 = 1 K4 = 0 K5 = 0. Тем самым, у нас будет формула 256*Delay и также мы получаем легкий способ манипуляцией метриками при помощи изменения параметра delay на интерфейсах. Учитывая, что на интерфейсах delay = 1 sec, то каждый линк, если пользоваться терминологией OSPF, стоит 256. Посмотрим какова таблица топологии на vIOS1:
vIOS1#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(192.168.1.1)
Codes: P — Passive, A — Active, U — Update, Q — Query, R — Reply,
r — reply Status, s — sia Status
P 192.168.3.0/24, 1 successors, FD is 512
via 192.168.13.3 (512/256), GigabitEthernet0/0
P 192.168.2.0/24, 1 successors, FD is 512
via 192.168.12.2 (512/256), GigabitEthernet0/3
P 192.168.25.0/24, 1 successors, FD is 512
via 192.168.12.2 (512/256), GigabitEthernet0/3
P 192.168.35.0/24, 1 successors, FD is 512
via 192.168.13.3 (512/256), GigabitEthernet0/0
P 192.168.12.0/24, 1 successors, FD is 256
via Connected, GigabitEthernet0/3
P 192.168.45.0/24, 1 successors, FD is 512
via 192.168.14.4 (512/256), GigabitEthernet0/2
P 192.168.0.0/24, 1 successors, FD is 256
via Connected, GigabitEthernet0/1
P 192.168.13.0/24, 1 successors, FD is 256
via Connected, GigabitEthernet0/0
P 192.168.14.0/24, 1 successors, FD is 256
via Connected, GigabitEthernet0/2
P 192.168.5.0/24, 3 successors, FD is 768
via 192.168.12.2 (768/512), GigabitEthernet0/3
via 192.168.13.3 (768/512), GigabitEthernet0/0
via 192.168.14.4 (768/512), GigabitEthernet0/2
Если взглянуть, например, на сеть — 192.168.5.0/24, можно заметить три пути через vIOS2, vIOS3 и vIOS4 с одинаковыми метриками. Для 192.168.5.0/24 FD по всем путям равно — 768, а AD — 512. Дадим определение из другой статьи и попытаемся объяснить:
- Advertised distance (AD), известная также как reported distance (RD) — стоимость расстояния между соседним маршрутизатором, который анонсирует маршрут, и сетью назначения.
- Feasible distance (FD) — стоимость расстояния от локального маршрутизатора до сети назначения = AD, которое анонсирует соседний маршрутизатор + стоимость расстояния между локальным маршрутизатором и соседним маршрутизатором.
P 192.168.5.0/24, 3 successors, FD is 768 via 192.168.14.4 (768/512), GigabitEthernet0/2
Изучим данную строку из таблицы топологии на vIOS1. vIOS1 узнал о маршруте от vIOS4 (192.168.14.4). Так как vIOS1 отделяет от 192.168.5.0/24 три линка, то и метрика FD с нашими настройками будет равна 3*256=768. А AD — это метрика маршрута относительно маршрутизатора (vIOS4), который анонсировал данную сеть. AD — это метрика FD данного маршрута на vIOS4. Посмотрим на таблицу топологии на vIOS4:
P 192.168.5.0/24, 1 successors, FD is 512 via 192.168.45.5 (512/256), GigabitEthernet0/1
AD на vIOS1 = FD на vIOS4. Немого запутанно, но постараемся объяснить логику работы. Маршрутизатор, который анонсирует маршрут, отправляет параметры (Bandwithd, Delay и т.д.) маршрута в Update сообщении без учета линка между маршртузатором, которому делается анонс. То есть, vIOS4 учитывает только параметры двух линков: vIOS4 Gi0/1 — vIOS5 Gi0/1 и vIOS5 Gi0/0 — VPC. Получив Update, vIOS1, подставляя полученные параметры в формулу, рассчитывает что? Правильно — AD =512. После берет параметры линка, откуда пришел маршрут, vIOS1 Gi0/2 — vIOS4 Gi0/2 и подставляет опять в формулу. Считает, получает число 256 и складывает с AD (512), получаем FD — 768. Вот такие дела! Но для чего весь этот ритуал?
А все для того, что создать специальное правило под названием Feasible condition, который является одним из средств по защите от образования петель и быстрой сходимости.
Дадим определения следующих терминов:
- Successor — соседний маршрутизатор с путем без петель и с наименьшей стоимостью пути к сети назначения.
- Feasible successor — резервный маршрутизатор с путем без петель (AD feasible successor должно быть меньше чем FD текущего маршрута successor).
- Feasible condition — AD feasible successor должно быть меньше, чем FD текущего маршрута successor.
Чтоб объяснить как это все работает и показать тонкости, надо поменять некоторые метрики. Сделаем следующее, поменяем delay так, чтоб у нас были такие метрики линков:
Делается это при помощи команды delay на интерфейсе. Сейчас у нас как было сказано — delay = 1 и метрика равна 256. Посмотрим какие метрики у нас получаться для сети 192.168.5.0/24 на маршрутизаторе vIOS1:
- Через vIOS2 — FD=2304, AD=1280
- Через vIOS4 — FD=1024, AD=768
- Через vIOS3 — FD=1536, AD=768
Как мы видим лучший FD будет у маршрута через vIOS4, он и будет добавлен в общую таблицу маршрутизации, такой маршрут называется Successor:
vIOS1#show ip route eigrp
Codes: L — local, C — connected, S — static, R — RIP, M — mobile, B — BGP
D — EIGRP, EX — EIGRP external, O — OSPF, IA — OSPF inter area
N1 — OSPF NSSA external type 1, N2 — OSPF NSSA external type 2
E1 — OSPF external type 1, E2 — OSPF external type 2
i — IS-IS, su — IS-IS summary, L1 — IS-IS level-1, L2 — IS-IS level-2
ia — IS-IS inter area, * — candidate default, U — per-user static route
o — ODR, P — periodic downloaded static route, H — NHRP, l — LISP
a — application route
+ — replicated route, % — next hop override, p — overrides from PfR
Gateway of last resort is not set
D 192.168.2.0/24 [90/512] via 192.168.12.2, 06:01:31, GigabitEthernet0/3
D 192.168.3.0/24 [90/1024] via 192.168.13.3, 06:01:28, GigabitEthernet0/0
D 192.168.5.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0/2
D 192.168.25.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0/2
D 192.168.35.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0/2
D 192.168.45.0/24 [90/768] via 192.168.14.4, 06:01:28, GigabitEthernet0/2
Что будет с остальными двумя маршрутами — они будут проверены на условие FS (Feasible condition). Маршрут через vIOS3 проходит это условие AD (via vIOS3) = 768 < 1024 = FD (via vIOS1). Поэтому данный маршрут хоть и не будет добавлен в общую таблицу маршрутизации, он будет храниться в таблицы топологии:
vIOS1#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(192.168.1.1)
Codes: P — Passive, A — Active, U — Update, Q — Query, R — Reply,
r — reply Status, s — sia Status
P 192.168.3.0/24, 1 successors, FD is 1024
via 192.168.13.3 (1024/256), GigabitEthernet0/0
P 192.168.2.0/24, 1 successors, FD is 1024
via 192.168.12.2 (1024/256), GigabitEthernet0/3
P 192.168.25.0/24, 1 successors, FD is 1024
via 192.168.14.4 (1024/768), GigabitEthernet0/2
via 192.168.13.3 (1536/768), GigabitEthernet0/0
P 192.168.35.0/24, 1 successors, FD is 1024
via 192.168.14.4 (1024/768), GigabitEthernet0/2
via 192.168.13.3 (1280/512), GigabitEthernet0/0
P 192.168.12.0/24, 1 successors, FD is 768
via Connected, GigabitEthernet0/3
P 192.168.45.0/24, 1 successors, FD is 768
via 192.168.14.4 (768/512), GigabitEthernet0/2
P 192.168.0.0/24, 1 successors, FD is 512
via Connected, GigabitEthernet0/1
P 192.168.13.0/24, 1 successors, FD is 768
via Connected, GigabitEthernet0/0
P 192.168.14.0/24, 1 successors, FD is 256
via Connected, GigabitEthernet0/2
P 192.168.5.0/24, 1 successors, FD is 1024
via 192.168.14.4 (1024/768), GigabitEthernet0/2
via 192.168.13.3 (1536/768), GigabitEthernet0/0
Он не обладает метрикой лучшего маршрута, то есть не является Successor-ом, но играет роль запасного маршрута и, при потери Successor-а, сразу займет его место. Этим достигается очень быстрая сходимость протокола, но об этом по подробней позже. Такой маршрут называется Feasible successor. А что будет с третьим маршрутом? Ничего, он не удовлетворяет условию FC (1280 > 1024) и не будет учитываться в целях защиты от образования петли. Все маршруты, полученные через Update, но не прошедшие проверку FC, можно увидеть при помощи команда show ip eigrp topology all-links. Не совсем очевидно почему условие FS защищает от образования петель, сейчас попытаемся объяснить. Важно знать, что при изучении протокола EIGRP жизненно важно понимать принцип условия FC и цели для которых он используется. Рассмотрим немного видоизмененную топологию ( добавлен линк между vIOS2 и vIOS4), а также используем максимально примитивную метрику:
Маршрут до сети 192.168.5.0/24 будет таким с AD и FD:
- vIOS4 — via vIOS5, AD=5, FD=10.
- vIOS1 — via vIOS4, AD=10, FD=11.
- vIOS3 — via vIOS1, AD=11, FD=12.
Но vIOS4 получит обновление от vIOS2, где будет содержаться маршрут до сети 192.168.5.0/24 через vIOS2 с метрикой — AD=12, FD=15. Понятно, что Successor-ом он быть не может, если бы вдруг данный маршрут был бы выбран Feasible Successor-ом, то при падении Successor-а на vIOS4 и последующим выбором Successor-ом данного маршрута, произошла бы петля. Но FC не позволит установить данный маршрут в качестве FS так, как AD=12 > 10=FD. Маршрут на vIOS2 содержит в себе путь через vIOS4 и в любом случае в его AD входит также FD vIOS4. То есть, AD на vIOS2 содержит в себе следующие линки:
12= AD на vIOS2 = Gi0/3 vIOS3 + Gi0/2 vIOS4 + Gi0/1 vIOS5 + eth0 VPC5, где Gi0/1 vIOS5 + eth0 VPC5 = FD = 10 — это и есть FD vIOS4 и невозможно, чтоб AD<FD был меньше.
Таким образом, условие FС проверяет маршрут на наличие самого себя в данном маршруте. Только маршруты, которые удовлетворяют данному условию, могут гарантировать, что петли нет. Могут быть случаи, когда маршрут не создает петлю, но при этом и не удовлетворяет условию FC, мы его не будем использовать, в таких случае мы выбираем стабильность сети. Если вникнуть, то условие довольно простое и интуитивно понятное. Алгоритм, по которому выбирается лучшие маршруты в протоколе EIGRP, называется DUAL. Теперь рассмотрим протокол EIGRP на вопрос сходимости при потере основого маршрута. Вернемся к нашей старой большой топологии и представим, что vIOS4 пропал. В зависимости от того, как пропал vIOS4 поведение будет немного разным, но отличаться будет тем, когда сработает триггер. Если, например, мы отключим интерфейс Gi 0/2 на vIOS1, то vIOS1 сразу детектирует потерю соседа и начнет действовать, если же сосед пропадет без предупреждений, то сработает Hold Timer после того, как не получит Hello-пакеты в течении 15 секунд:
D 192.168.2.0/24 [90/512] via 192.168.12.2, 06:01:31, GigabitEthernet0/3
D 192.168.3.0/24 [90/1024] via 192.168.13.3, 06:01:28, GigabitEthernet0/0
D 192.168.5.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0/2
D 192.168.25.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0/2
D 192.168.35.0/24 [90/1024] via 192.168.14.4, 06:01:28, GigabitEthernet0/2
D 192.168.45.0/24 [90/768] via 192.168.14.4, 06:01:28, GigabitEthernet0/2
P 192.168.3.0/24, 1 successors, FD is 1024
via 192.168.13.3 (1024/256), GigabitEthernet0/0
P 192.168.2.0/24, 1 successors, FD is 1024
via 192.168.12.2 (1024/256), GigabitEthernet0/3
P 192.168.25.0/24, 1 successors, FD is 1024
via 192.168.14.4 (1024/768), GigabitEthernet0/2
via 192.168.13.3 (1536/768), GigabitEthernet0/0
P 192.168.35.0/24, 1 successors, FD is 1024
via 192.168.14.4 (1024/768), GigabitEthernet0/2
via 192.168.13.3 (1280/512), GigabitEthernet0/0
P 192.168.12.0/24, 1 successors, FD is 768
via Connected, GigabitEthernet0/3
P 192.168.45.0/24, 1 successors, FD is 768
via 192.168.14.4 (768/512), GigabitEthernet0/2
P 192.168.0.0/24, 1 successors, FD is 512
via Connected, GigabitEthernet0/1
P 192.168.13.0/24, 1 successors, FD is 768
via Connected, GigabitEthernet0/0
P 192.168.14.0/24, 1 successors, FD is 256
via Connected, GigabitEthernet0/2
P 192.168.5.0/24, 1 successors, FD is 1024
via 192.168.14.4 (1024/768), GigabitEthernet0/2
via 192.168.13.3 (1536/768), GigabitEthernet0/0
Привел таблицу маршрутизации и топологии еще раз для удобства так, как чтоб понять как будет действовать маршрутизатор по каждому маршруту необходимо знать в каком состоянии они находились до этого. Например, обсуждаемый нами ранее, маршрут 192.168.5.0/24 будет потерян, но в таблиции топологии у него был FS и поэтому как только произойдет детект потери основого маршрута, он займет место в таблице маршрутизации. Интересен вопрос, что будет с маршрутами без FS. Но немного матчасти:
Записи в таблице топологии могут находиться в двух состояниях: active и passive. Маршрут находится в состоянии passive, когда маршрут стабилен и не происходит поиск лучшего маршрута. В состоянии active — если выполняется поиск лучшего маршрута. Поиск маршрута выполняется, когда для сети назначения нет feasible successor. Маршрутизатор в поисках лучшего маршрута отправлят запрос (отправляет query packet) каждому соседнему маршрутизатору. Если у соседа есть маршрут к сети назначения, то он отвечает (отправляет reply packet), если маршрута нет — сосед отправляет запрос своим соседям. Маршрутизатор сравнивает все FD для достижения конкретной сети, выбирает маршрут с наименьшим FD и помещает его в таблицу маршрутизации. В таблице топологии может хранится 6 маршрутов к сети получателя (основной и запасные).
Маршруты, которые были утеряны и не имели FS, перейдут в состоянии Active и vIOS1 начнет распрашивать о них у оставшихся соседей. Делается это при помощи сообщений Query. vIOS1 отправит Query сообщения маршрутизаторам vIOS2 и vIOS3, где явно укажет какие маршруты ему необходимы — в нашем случае такими маршрутами будут 192.168.14.0/24, 192.168.45.0/24. Этим сообщением vIOS1 также сообщает маршрутизаторам, что маршруты через vIOS1 к этим сетям непригодны. Делается это при помощи указания в метрике данного маршрута параметра Delay:Infifnity, то есть метрика бесконечно большая. Как только маршрутизаторы получат такое сообщения, то удалят данные маршруты через vIOS1. Это технология называется Poison Reverse. Poison Reverse также используется при сообщениях Update, чуть позже расскажу об этом. После получения Query с запросом на маршруты 192.168.14.0/24, 192.168.45.0/24, vIOS2 и vIOS3 посмотрят, есть ли у них данные маршруты, которые они используют, если есть, то сразу отправят Reply с новыми метриками для данных маршрутов. vIOS2 и vIOS3 как мы знаем не потеряли свои маршруты, поэтому сразу отправят Reply. Если же у маршрутизатора, которого спрашивают также нет данного маршрута, то он перешлет Query дальше своим соседям и так далее. vIOS1 будет ждать Reply от vIOS2, vIOS3 и тут на сцену выходит Active Timer, который запустится как только Query будет отправлен:
Active Timer — интервал времени в течение которого маршрут может оставаться в состоянии active. Если таймер истечет до тех пор как будут получены все ответы от соседей (Reply), то маршрутизатор переводит маршрут в состояние stuck-in-active. Кроме того, разрываются отношения соседства с теми соседями, от которых не был получен ответ. По умолчанию данный таймер равен 3 минутам.
То есть, если в течении 3 минут не будет получен Reply, несмотря на Hello-пакеты, соседство будет разорвано и это очень плохо. Несмотря на то, что 3 минуты вроде вечность для таких протоколов, такие ситуации возможны при больших топологиях. Для защиты от ошибочного разрыва отношения соседства были придуманы специальные сообщения — SIA-Query и SIA-Reply.
Для улучшения реагирования маршрутизатора на состояние active маршрута, дополнительно введены два типа сообщений:
- SIA-Query — Отправляется через 1,5 минут (по умолчанию) для того чтобы проверить статус непосредственно присоединенного маршрутизатора. Для того чтобы, если пропал маршрут, который находится за соседом (при этом связь с соседом нормальная), не сбрасывались отношения соседства с непосредственно присоединенным маршрутизатором. Не требует подтверждения о получении. После отправки трех сообщений и не получении ответа сосед считается в состоянии down и маршрут убирается из таблицы топологии.
- SIA-Reply — Отправляется в ответ на SIA-Query. Не требует подтверждения о получении.
После 1,5 минуты, если не получен Reply на какой-либо Query, то отправляется SIA-Query, который не требует дать новый маршрут, а требует только отправить SIA-Reply, чтоб убедиться, что сосед в порядке, просто не может найти нужный маршрут.
Думаю о том, как маршрутизатор реагирует на потерю маршрута в случае, когда есть FS или нет, мы сказали достаточно. Только необходимо внести правки в следующее. Мы не совсем правильное дали определение для FD, метрику которую мы рассчитываем по формуле при первом получении маршрута или при дальнейшем изменения состояния маршрута, правильно было бы называть CD — Computed Distance.
FD — это наилучший показатель для данного маршрута, который когда-либо получался и именно он учавствует при проверке FC. Чаще всего, FD=CD лучшего маршрута, но давайте посмотрим как поменялся FD после обрыва сосесдства с vIOS4:
P 192.168.5.0/24, 1 successors, FD is 1024
via 192.168.13.3 (1536/768), GigabitEthernet0/0
У нас больше нет маршрута с CD=1024, самый лучший маршрут через vIOS3 имеет CD=1536, но как видите FD=1024, который был зафисикрован при наличии маршрута через vIOS4. FD обновится только в том случае, когда данный маршрут перейдет в состояние Active. Пока не менялось состояние с Passive на Active, то и FD не поменяется. Обычные обновления на него не действуют. Еще одно замечание. Давайте проведем такой эксперимент: вернем соседство с vIOS4, CD через vIOS3= 1536, а через vIOS2 = 2048. Увеличим delay канала между vIOS1 и vIOS3 так, чтоб стало больше чем CD vIOS2:
P 192.168.5.0/24, 1 successors, FD is 1024
via 192.168.14.4 (1024/768), GigabitEthernet0/2
via 192.168.13.3 (2304/768), GigabitEthernet0/0
Как видим CD через vIOS3=2304, но он остался FS так, как AD не поменялось и условие FC пройдено, как и раньше. Зададимся вопросом: Что будет при потери маршрута через vIOS2? Ожидаемый и логичный ответ, как нас учили — вместо него встанет FS, но нет! Так как существует еще маршрут через vIOS2 имеет CD = 2048 < 2304, то маршрут перейдет в состояние Active и заново пересчитает для него метрику и выберет лучший маршрут несмотря на то, что у него был резервный маршрут. Смотрим таблицу топологии и получаем:
P 192.168.5.0/24, 1 successors, FD is 2048
via 192.168.12.2 (2048/1280), GigabitEthernet0/3
via 192.168.13.3 (2304/768), GigabitEthernet0/0
Использоваться будет маршрут через vIOS2 и как заметили FD также поменялся из-за перехода маршрута в состояние Active. А маршрут через vIOS3 опять разделяет участь запасного.
Правила Split Horizon и Poison Reverse в EIGRP
Как и в RIP, в EIGRP используется правило Split Horizon — если маршрут достижим через определенный интерфейс, то в обновление, которое отправляется через этот интерфейс не включается этот маршрут.
Например, vIOS4 получив маршрут до сети 192.168.0.0/24 от vIOS1, не отправит данный маршрут в Update через интерфейс, к которому подключен vIOS1. Если быть наиболее точным, то представим, что vIOS1 начал рассказывать о сети 192.168.0.0/24. Отправил Update к vIOS4, vIOS4 получит его и по правило Split Horizon не должен отправлять его Update с этим маршрутом к vIOS1, но в действительности он отправит его с указанием бесконечной метрики. Как бы vIOS4 говорит vIOS1- «Не смей использовать маршрут до сети 192.168.0.0/24 через меня, я получил этот маршрут от тебя и если будешь использовать, то будет петля».
Poison Reverse — указание маршрута недостижым при помощи метрики при его потери. В EIGRP это делается при помощи параметра Delay. Мы указывали выше, как используется данная технология, когда vIOS1 терял связь c vIOS4. Из сказанного выше о Split Horizon можно сделать вывод, что технология Poison Reverse используется не только Query сообщениях, но и в Update. Также Poison Reverse может нарушать правило Split Horizon и отправлять Update с бесконечной метрикой с интерфейса, с которого получил данное обновление. Данные два правила вместе с условием FC обеспечивают протоколу EIGRP защиту от петель.
Stub маршрутизаторы
В качестве оптимизации работы, в протоколе ввели специальную роль для маршрутизаторов — Stub. Чем-то напоминает Stub зоны в OSPF, но здесь немного иной принцип работы. При настройке маршрутизатора в режиме stub, он сразу сообщает в Hello-пакетах своему соседу о своем stub статусе и, в зависимости от режима stub, может отправлять определенные типы маршрутов:
vIOS5#eigrp stub [connected | leak-map | receive-only | redistributed | static | summary]
Опции команды eigrp stub:
- Без опций (по умолчанию) — connected и summary;
- connected — Разрешает stub маршрутизатору отправлять connected маршруты, но только для интерфейсов, адреса которых находятся в сетях, указанных командой network;
- leak-map — Allow dynamic prefixes based on the leak-map;
- receive-only — Запрещает stub маршрутизатору отправлять какие-либо маршруты;
- redistributed — Разрешает stub маршрутизатору отправлять redistributed маршруты;
- static — Разрешает stub маршрутизатору отправлять static маршруты, при том, что перераспределение статических маршрутов уже настроено;
- summary — Разрешает stub маршрутизатору отправлять суммарные маршруты (автоматически просуммированные или административно).
Но главная фишка данной настройки в том, что, если маршрутизатор знает, что его сосед в роли Stub, то он ему не отправит Query для маршрутов, которые стали Active. Например, если настроим vIOS5 как Stub, то vIOS2-4 узнают об этом и при потери маршрутов не будут отравлять Query. Учитывая какие проблемы могут возникать при отсутствии Reply, то хорошо бы отправлять Query только туда, куда имеет смысл. Это важно в больших топологиях, где сходимость может быть сложным процессом. Поэтому, если есть маршрутизатор, который является конечным и к нему подключены только пользовательские сети (условно говоря у него только один сосед), то лучше задуматься о том, чтоб настроить его в качестве Stub.
Пара слов о таймерах
О некоторых из мы говорили, если посмотреть вывод команды show ip eigrp neighbors, то увидим следующее:
vIOS1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.14.4 Gi0/2 11 00:48:43 23 138 0 168
0 192.168.12.2 Gi0/3 12 02:31:12 6 100 0 258
1 192.168.13.3 Gi0/0 10 2d13h 7 100 0 291
vIOS1#
Тут указаны таймеры, которые требуют пояснения. Если в ответ на отправку любого multicast-пакета, который требует подтверждения о получении, не было отправлено подтверждение (ACK), то будет передаваться unicast пакет соседу, который не отвечает. Если подтверждение не было получено и после того, как отправлено 16 unicast пакетов, то сосед считается неактивным.
- Smooth round-trip time (SRTT) — время между отправкой пакета соседу и получением подтверждения от него. Измеряется в миллисекундах. Формула вычисления проприетарная.
- Multicast Flow Timer — максимальное значение интервала в секундах, в течение которого маршрутизатор будет ждать ACK пакета после отправки EIGRP-пакета на multicast адрес, прежде чем переключиться на unicast отправку. Вычисляется на основании SRTT, сама формула вычисления проприетарная.
- Retransmission timeout (RTO) — интервал между отправкой unicast-пакетов. Вычисляется на основании SRTT, сама формула вычисления проприетарная.
На этом думаю закончить статью. Внизу полезный ссылки:
- cisconinja.wordpress.com/2009/09/18/eigrp-sia-query-and-sia-reply
- xgu.ru/wiki/EIGRP
- www.youtube.com/watch?v=FYUK7blhCZk — вебинар о EIGRP около 4 с половиной часов. Обязателен к просмотру)
- www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#anc9
