Динамическая маршрутизация. Протоколы и работа.
Содержание:
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
Ну, вот мы провели шапошное знакомство с OSPF, теперь поговорим об еще одном не менее интересном протоколе. Зачем нам этот EIGRP?
-> Он прост в конфигурации;
-> Быстрая перестройка топологии на заранее просчитанный маршрут;
-> Меньше нагружает маршрутизатор (если сравнивать с OSPF);
-> Маршруты суммируются на любом роутере в сетке (в OSPF только на ABR\ASBR);
-> Балансировка трафика в т.ч. на неравноценных маршрутах (OSPF же умеет только в равноценные).
Давайте теперь вникать в теорию работы данного протокола. Для начала, учтем, что каждый EIGRP-процесс обслуживает три таблицы:
1) Таблицу соседей (neighbor table), то есть информацию о непосредственно подключенных к искомому маршрутизаторах, которые участвуют в обмене маршрутами. Посмотреть её можно командой show ip eigrp neighbors.
2) Таблицу топологии сети (topology table), в которой содержится информация о сетевой топологии, полученная от других маршрутизаторов. Её можно посмотреть по команде show ip eigrp topology.
3) Ну и, конечно, таблицу маршрутизации (routing table), следуя которой роутер принимает решения о перенаправлении пакетов. Взглянуть на неё мы можем по команде show ip route.
Идем дальше. Еще одна важная часть этого балета - метрика. Что это такое? Некое число, которое отражает различные характеристики маршрута (или их совокупность), которое служит для объективной оценки качества того или иного маршрута. Характеристики могут быть очень разными, от количества роутеров на данном маршруте до суммарной загрузки интерфейсов на нем (или её средним арифметическим).
О метрике EIGRP:
Итак, формула подсчета метрики:
bw - это не просто Bandwidth, пропускная способность, а 10000000/самая маленькая пропускная способность по дороге маршрута в килобитах) * 256;
delay - это не просто задержка, а сумма всех задержек по маршруту в десятках микросекунд * 256
delay в командах show interface, show ip eigrp topology и прочих показывается в микросекундах;
K1-K5 - это коэффициенты для включения определенных параметров в формулу.
Страх и ужас, да? Но фактически работают только параметры bw и delay, а коэффициенты K1 и K3=1, остальные нулю. В итоге мы просто складываем эти два числа. Но не забываем, что считаются он по своим формулам.
Метрика считается по худшему показателю пропускной способности по всей длине маршрута.
Если K5=0, то используется следующая формула: Metric = (K1 * bw + (K2 * bw) / (256 — load) + (K3 * delay)
Теперь пора определиться с терминами, которые будут применяться в рамках обсуждения протокола EIGRP.
Каждый маршрут здесь характеризуется двумя значениями - Feasible Distance и Advertised Distance (также встречается характеристика Reported Distance, но это тождественные вещи). Каждое из этих значений является метрикой, то есть стоимостью маршрута (больше значит хуже), но с разных точек отсчета. FD - от искомого роутера до точки назначения, а AD - от его соседа, "рассказавшего" о маршруте, до той же точки назначения. Чуть ниже разберемся, зачем нужны об этих параметра, если фактически AD включен в FD.
Для каждой подсети о которой знает EIGRP существует роутер Successor, через который проходит лучший по метрике маршрут к этой подсети. Также подсети не возбраняется иметь нейборов с альтернативными маршрутами в качестве резерва, эти соседи зовутся Feasible Successor. Вообще говоря, EIGRP - единственный протокол маршрутизации, который держит запасной маршрут уже в полуактивном состоянии, и как только основной раут через successor'а падает, то сразу актуализируется резервный. Да, в OSPF почти также, но сабмаршруты в нем "сырые" и перед запуском их еще нужно обработать алгоритмом SPF. Условием назначения роутера в качестве feasible successor является то, что значение его AD меньше FD successor'а данного маршрута (да-да, AD нам именно для этого и нужно). Данное правило позволяет избежать колец маршрутизации.
Чердак еще не снесло? Тогда давайте попробуем осознать всё на более-менее живом примере:
И как бы всё у нас классно, R1 справедливо считает, что R2 - это Successor подсетки 192.168.2.0/24. Чтобы стать для FS для этой подсети, роутеру R4 нужно, чтобы его AD была меньше FD для данного маршрута.
FD=((10000000/1544)*256)+(2100*256)=2195456
ADR4=((10000000/100000)*256)+(100*256)=51200
Хотя с его точки зрения это FD, т.е. метрика от него до искомой сети. Отлично AD у R4 меньше, чем FD маршрута и он получает статус FS. Всё просто ооооочень просто. Смотрим дальше. Маршрутизатор R3 анонсит сетку 192.168.1.0/24 своему соседу R1, а тот в свою очередь рассказывает о ней своим нейборам - R2 и R4. Но R4, к примеру, понятия не имеет, что R2 знает об этой подсети, и решает рассказать ему о ней. В свою очередь R2 передает информацию, что он имеет доступ до подсети 192.168.1.0/24 с маршрутом через R4 дальше - на R1. R1 проверяет значение FD маршрута, а также ADR2 (которая будет явно больше, чем FD) и шлет того лесом с его новаторскими идеями. Описанная ситуация маловероятно, но некоторые факторы могу привести к её возникновению, например, отключение механизма "расщепления горизонта" (split-horizon).
А мы пока вернемся к более реальным ситуациям. Представим, что R4 подключен к сети 192.168.2.0/24 не через FastEthernet, а посредством 56k модема (задержка dialup-ного соединения будет 20000 usec), тогда стоить маршрут будет ((10000000/56)*256)+(2000*256)=46226176, а это явно больше, чем FD для этого маршрута, поэтому R4 статуса Feasible Successor не получит. Но EIGRP не будет совсем забивать болт на этот маршрут, просто времени на переключение займет больше.
Маршрутизаторы не будут обмениваться раутами с кем угодно, для начала между ними должно возникнуть соседство. Включаем процесс командой router eigrp с указанием номера автономной системы (AS), а дальше командой network скажем, какие интерфейсы будут в этом участвовать, а также информацию о каких сетях мы будем распространять. После этого на выбранные интерфейсы полетят Hello-пакеты с мальтикастным адресом назначения 224.0.0.10 (по дефолту для Ethernet это каждые 5 секунд). Все роутеры с активным процессом EIGRP получают данные пакеты, а далее они будут делать следующее:
> Сверяется адрес Hello-пакета с адресом интерфейса на который пришел этот пакет. Происходит проверка, из одной ли они подсети.
> Происходит сверка полученных K - коэффициентов, использующихся при подсчете метрик, со своими. Очевидно, что при их несовпадении метрики будут высчитываться по-разному, а это просто недопустимо.
> Проверка номера AS, автономной системы.
> Дополнительно, если выставлена аутентификация, происходит проверка её типа и ключей.
Если нашему получателю всё нравится, то он добавляет отправителя в список своих соседей, после чего посылает ему юникастом update-пакет, в котором содержится список всех известных ему маршрутов, т.н. full-update. По факту получения пакета отправитель сделает тоже самое. Для обмена маршрутами EIGRP использует протокол Reliable Transport Protocol (RTP, только не путайте аббревиатуру с Real-time Transport Protocol, из области ip-телефонии), которому требуется подтверждение о доставке. Так что получивший update-пакет роутер отвечает на это ack-пакетом (сокр. acknowledgement - подтверждение). Отлично, маршрутизаторы сдружились и стали нейборами, дальше что? В продолжение своей плодотворной дружбы они так и будут слать hello-пакеты, подтверждая, что с ними всё в порядке и они на связи. При изменении же топологии полетят урезнанные update-пакеты, содержащие только информацию об изменениях (partial update).
Но обратимся к нашей схеме с модемом.
Вот R2 потерял связь с 192.168.2.0/24. До этой подсети у него нет FS, отсутствует резервный маршрут. Но он же ответственный роутер, и EIGRP хочет восстановить связь, поэтому начнется рассылка специальных query-пакетов соседям, не знают ли они о запасном маршруте, а те не найдя информации у себя, обратятся к своим соседям, и т.д. И вот пакет попадает к R4, которого осеняет - маршрут есть! Тот самый, модемный. Он пакует информацию в reply-пакет и отправляет соседу кинувшему ему query-запрос, а дальше всё происходит по цепочке. Да, это дольше, чем простое переключение на Feasible Successor, но иногда результат важнее - связь с подсетью возобновлена.
Как можно догадаться, падение какого-либо интерфейса в сети вызывает этакий широковещательный шторм в миниатюре. И чем больше сеть, тем больше ресурсов потребуется для всех этих ответов-приветов. А представим, что роутеры на нашей схеме являются лишь частью крупной распределенной сети, некоторые узлы которой висят на плохих каналах связи и находятся от того же R2 за тысячи километров. Так вот, если роутер отправил query соседу, то он обязан дождаться от него reply. И неважно, что там будет в ответе, но придти он обязан. Если даже роутер уже получил решение проблемы, он все равно должен дождаться ответов на все свои запросы, а до тех пор этот маршрут он в продакшн не отправит. А запросы где-то далеко, бродят за полярным кругом. В итоге маршрут застывает в состоянии stuck-in-active.
Ну, а раз такое дело, то поговорим о состояниях маршрута в EIGRP: active\passive route. Казалось бы, "active" должно означать, что всё активно и вроде как хорошо. Но тут всё наоборот. Как раз таки в состоянии "passive" у нас всё тихо и спокойно, а в "active" роутер судорожно ищет живой маршрут до отвалившейся сети - броадкастит query-запросами и ждет от соседей reply'ев. А теперь о stuck-in-active - это пограничное состояние, которое может продолжаться до трёх минут, роутер "застревает" в активном состоянии, ожидая реплаев. Через эти три минуты роутер разрывает отношения с не ответившим соседом и запускает маршрут через R4.
За эти три минуты сетевого инженера может хватить удар. Как ему выжить? Выхода два: суммирование маршрутов и так называемая stub-конфигурация.
Как уже говорилось, производить суммирование маршрутов можно на любом роутере. Но давайте проиллюстрируем это. Допустим всё к тому же R2 подключены подсети из 192.168.0.0/24 до 192.168.7.0/24, а мы это дело суммируем в 192.168.0.0/21 (если забыли логику процесса, то курим матчасть). Роутер анонсирует этот суммарный маршрут, а остальные знают, что source address начинающийся на 192.168.0.0~192.168.7.0 это туда. А если отвалится одна из подсетей? Роутер разошлет query-запросы с адресом пропавшей сети (пусть это будет 192.168.5.0/24), но соседи не будут передавать их дальше, а вышлют реплаи, мол "друже, ты ку-ку? это же твоя подсеть, сам разбирайся".
Теперь затронем второй вариант решения. Stub-конфигурация. В нашем случае stub означает “конец пути” или “тупик” в контексте EIGRP. Т.е. для попадания в подсеть, которая с роутером не directly connected (подключена не напрямую) нужно идти назад, возвращаться. Сконфигурированный как stub роутер не будет слать трафик между подсетями, которые стали ему известны благодаря EIGRP (т.е., отмеченными в show ip route буквой D). Соседи также не будут слать ему query-пакеты. Где применяется такой конфиг? В топологиях hub-and-spoke, например, в особенности с избыточными линками.
Представим такую картину. Слева у нас будут филиалы, справа головной офис и сервера и прочее. Для отказоустойчивости у нас подняты избыточные линки и запущен EIGRP на дефолтном конфиге:
Теперь ситуация. R1 теряет связь с R4, а R5 теряет LAN. Трафик из подсети маршрутизатора R1 в подсеть головного офиса пойдет по маршруту R1->R5->R2(или R3)->R4. Будет ли это эффективно? Конечно же нет! Окажутся в печальном положении сетки не только за R1, но и за R2 (или R3) в связи с увеличением трафика и связанных с этим следствий. Stub существует именно для этого. За маршрутизаторами в филиалах нет других маршрутизаторов со своими подсетями, это как раз и есть "конец дороги", дальше мы можем только вернуться назад. Поэтому конфигурить их нужно именно как стабы, благодаря чему мы избавимся от таких вот кривых маршрутов из примера, а также от флуда query-пакетами при потере маршрута.
Существует несколько режимов работы роутера в качестве stub, настраивается эта прелесть по команде eigrp stub:
При дефолтных настройках, если просто сказать роутеру, что он eigrp stub, включатся режимы сonnected и summary. Для нас представляет интерес режим receive-only, в котором роутер не производит анонсирования известных ему сетей, а только слушает, что говорят ему соседи. Это похоже на команду passive interface в протоколе RIP, но в случае с EIGRP она полностью отключит протокол на выбранном интерфейсе, что не даст установить соседства в принципе.
О чем мы не поговорили и что хотелось бы в ближайшее время обсудить?
• Настройка аутентификации соседей в EIGRP;
• Принципы graceful shutdown;
• Балансировка нагрузки.
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
Протокол EIGRP
Ну, вот мы провели шапошное знакомство с OSPF, теперь поговорим об еще одном не менее интересном протоколе. Зачем нам этот EIGRP?
-> Он прост в конфигурации;
-> Быстрая перестройка топологии на заранее просчитанный маршрут;
-> Меньше нагружает маршрутизатор (если сравнивать с OSPF);
-> Маршруты суммируются на любом роутере в сетке (в OSPF только на ABR\ASBR);
-> Балансировка трафика в т.ч. на неравноценных маршрутах (OSPF же умеет только в равноценные).
Давайте теперь вникать в теорию работы данного протокола. Для начала, учтем, что каждый EIGRP-процесс обслуживает три таблицы:
1) Таблицу соседей (neighbor table), то есть информацию о непосредственно подключенных к искомому маршрутизаторах, которые участвуют в обмене маршрутами. Посмотреть её можно командой show ip eigrp neighbors.
2) Таблицу топологии сети (topology table), в которой содержится информация о сетевой топологии, полученная от других маршрутизаторов. Её можно посмотреть по команде show ip eigrp topology.
3) Ну и, конечно, таблицу маршрутизации (routing table), следуя которой роутер принимает решения о перенаправлении пакетов. Взглянуть на неё мы можем по команде show ip route.
Идем дальше. Еще одна важная часть этого балета - метрика. Что это такое? Некое число, которое отражает различные характеристики маршрута (или их совокупность), которое служит для объективной оценки качества того или иного маршрута. Характеристики могут быть очень разными, от количества роутеров на данном маршруте до суммарной загрузки интерфейсов на нем (или её средним арифметическим).
О метрике EIGRP:
Цитата: Jeremy Cioara
У меня создалось впечатление, что создатели EIGRP, окинув критическим взглядом свое творение, решили, что все слишком просто и хорошо работает. И тогда они придумали формулу метрики, что бы все сказали “ВАУ, это действительно сложно и профессионально выглядит.
Итак, формула подсчета метрики:
EIGRP: (K1 * bw + (K2 * bw) / (256 — load) + K3 * delay) * (K5 / (reliability + K4))bw - это не просто Bandwidth, пропускная способность, а 10000000/самая маленькая пропускная способность по дороге маршрута в килобитах) * 256;
delay - это не просто задержка, а сумма всех задержек по маршруту в десятках микросекунд * 256
delay в командах show interface, show ip eigrp topology и прочих показывается в микросекундах;
K1-K5 - это коэффициенты для включения определенных параметров в формулу.
Страх и ужас, да? Но фактически работают только параметры bw и delay, а коэффициенты K1 и K3=1, остальные нулю. В итоге мы просто складываем эти два числа. Но не забываем, что считаются он по своим формулам.
Метрика считается по худшему показателю пропускной способности по всей длине маршрута.
Если K5=0, то используется следующая формула: Metric = (K1 * bw + (K2 * bw) / (256 — load) + (K3 * delay)
Цитата: О связи параметра MTU с EIGRP
Часто встречаются упоминания об их связи, но фактически в итоговой формуле параметр MTU вообще не упоминается, но при обмене маршрутами он передается в общей информации. Фактически он принимается в расчет только в очень специфических случаях, к примеру, если роутер должен отбросить один из маршрутов, равнозначных по остальным характеристикам. Но, в эти моменты нужно вникать и покурить соответствующие темы.
Теперь пора определиться с терминами, которые будут применяться в рамках обсуждения протокола EIGRP.
Каждый маршрут здесь характеризуется двумя значениями - Feasible Distance и Advertised Distance (также встречается характеристика Reported Distance, но это тождественные вещи). Каждое из этих значений является метрикой, то есть стоимостью маршрута (больше значит хуже), но с разных точек отсчета. FD - от искомого роутера до точки назначения, а AD - от его соседа, "рассказавшего" о маршруте, до той же точки назначения. Чуть ниже разберемся, зачем нужны об этих параметра, если фактически AD включен в FD.
Для каждой подсети о которой знает EIGRP существует роутер Successor, через который проходит лучший по метрике маршрут к этой подсети. Также подсети не возбраняется иметь нейборов с альтернативными маршрутами в качестве резерва, эти соседи зовутся Feasible Successor. Вообще говоря, EIGRP - единственный протокол маршрутизации, который держит запасной маршрут уже в полуактивном состоянии, и как только основной раут через successor'а падает, то сразу актуализируется резервный. Да, в OSPF почти также, но сабмаршруты в нем "сырые" и перед запуском их еще нужно обработать алгоритмом SPF. Условием назначения роутера в качестве feasible successor является то, что значение его AD меньше FD successor'а данного маршрута (да-да, AD нам именно для этого и нужно). Данное правило позволяет избежать колец маршрутизации.
Чердак еще не снесло? Тогда давайте попробуем осознать всё на более-менее живом примере:
И как бы всё у нас классно, R1 справедливо считает, что R2 - это Successor подсетки 192.168.2.0/24. Чтобы стать для FS для этой подсети, роутеру R4 нужно, чтобы его AD была меньше FD для данного маршрута.
FD=((10000000/1544)*256)+(2100*256)=2195456
ADR4=((10000000/100000)*256)+(100*256)=51200
Хотя с его точки зрения это FD, т.е. метрика от него до искомой сети. Отлично AD у R4 меньше, чем FD маршрута и он получает статус FS. Всё просто ооооочень просто. Смотрим дальше. Маршрутизатор R3 анонсит сетку 192.168.1.0/24 своему соседу R1, а тот в свою очередь рассказывает о ней своим нейборам - R2 и R4. Но R4, к примеру, понятия не имеет, что R2 знает об этой подсети, и решает рассказать ему о ней. В свою очередь R2 передает информацию, что он имеет доступ до подсети 192.168.1.0/24 с маршрутом через R4 дальше - на R1. R1 проверяет значение FD маршрута, а также ADR2 (которая будет явно больше, чем FD) и шлет того лесом с его новаторскими идеями. Описанная ситуация маловероятно, но некоторые факторы могу привести к её возникновению, например, отключение механизма "расщепления горизонта" (split-horizon).
А мы пока вернемся к более реальным ситуациям. Представим, что R4 подключен к сети 192.168.2.0/24 не через FastEthernet, а посредством 56k модема (задержка dialup-ного соединения будет 20000 usec), тогда стоить маршрут будет ((10000000/56)*256)+(2000*256)=46226176, а это явно больше, чем FD для этого маршрута, поэтому R4 статуса Feasible Successor не получит. Но EIGRP не будет совсем забивать болт на этот маршрут, просто времени на переключение займет больше.
Соседство
Маршрутизаторы не будут обмениваться раутами с кем угодно, для начала между ними должно возникнуть соседство. Включаем процесс командой router eigrp с указанием номера автономной системы (AS), а дальше командой network скажем, какие интерфейсы будут в этом участвовать, а также информацию о каких сетях мы будем распространять. После этого на выбранные интерфейсы полетят Hello-пакеты с мальтикастным адресом назначения 224.0.0.10 (по дефолту для Ethernet это каждые 5 секунд). Все роутеры с активным процессом EIGRP получают данные пакеты, а далее они будут делать следующее:
> Сверяется адрес Hello-пакета с адресом интерфейса на который пришел этот пакет. Происходит проверка, из одной ли они подсети.
> Происходит сверка полученных K - коэффициентов, использующихся при подсчете метрик, со своими. Очевидно, что при их несовпадении метрики будут высчитываться по-разному, а это просто недопустимо.
> Проверка номера AS, автономной системы.
> Дополнительно, если выставлена аутентификация, происходит проверка её типа и ключей.
Если нашему получателю всё нравится, то он добавляет отправителя в список своих соседей, после чего посылает ему юникастом update-пакет, в котором содержится список всех известных ему маршрутов, т.н. full-update. По факту получения пакета отправитель сделает тоже самое. Для обмена маршрутами EIGRP использует протокол Reliable Transport Protocol (RTP, только не путайте аббревиатуру с Real-time Transport Protocol, из области ip-телефонии), которому требуется подтверждение о доставке. Так что получивший update-пакет роутер отвечает на это ack-пакетом (сокр. acknowledgement - подтверждение). Отлично, маршрутизаторы сдружились и стали нейборами, дальше что? В продолжение своей плодотворной дружбы они так и будут слать hello-пакеты, подтверждая, что с ними всё в порядке и они на связи. При изменении же топологии полетят урезнанные update-пакеты, содержащие только информацию об изменениях (partial update).
Но обратимся к нашей схеме с модемом.
Вот R2 потерял связь с 192.168.2.0/24. До этой подсети у него нет FS, отсутствует резервный маршрут. Но он же ответственный роутер, и EIGRP хочет восстановить связь, поэтому начнется рассылка специальных query-пакетов соседям, не знают ли они о запасном маршруте, а те не найдя информации у себя, обратятся к своим соседям, и т.д. И вот пакет попадает к R4, которого осеняет - маршрут есть! Тот самый, модемный. Он пакует информацию в reply-пакет и отправляет соседу кинувшему ему query-запрос, а дальше всё происходит по цепочке. Да, это дольше, чем простое переключение на Feasible Successor, но иногда результат важнее - связь с подсетью возобновлена.
Как можно догадаться, падение какого-либо интерфейса в сети вызывает этакий широковещательный шторм в миниатюре. И чем больше сеть, тем больше ресурсов потребуется для всех этих ответов-приветов. А представим, что роутеры на нашей схеме являются лишь частью крупной распределенной сети, некоторые узлы которой висят на плохих каналах связи и находятся от того же R2 за тысячи километров. Так вот, если роутер отправил query соседу, то он обязан дождаться от него reply. И неважно, что там будет в ответе, но придти он обязан. Если даже роутер уже получил решение проблемы, он все равно должен дождаться ответов на все свои запросы, а до тех пор этот маршрут он в продакшн не отправит. А запросы где-то далеко, бродят за полярным кругом. В итоге маршрут застывает в состоянии stuck-in-active.
Ну, а раз такое дело, то поговорим о состояниях маршрута в EIGRP: active\passive route. Казалось бы, "active" должно означать, что всё активно и вроде как хорошо. Но тут всё наоборот. Как раз таки в состоянии "passive" у нас всё тихо и спокойно, а в "active" роутер судорожно ищет живой маршрут до отвалившейся сети - броадкастит query-запросами и ждет от соседей reply'ев. А теперь о stuck-in-active - это пограничное состояние, которое может продолжаться до трёх минут, роутер "застревает" в активном состоянии, ожидая реплаев. Через эти три минуты роутер разрывает отношения с не ответившим соседом и запускает маршрут через R4.
За эти три минуты сетевого инженера может хватить удар. Как ему выжить? Выхода два: суммирование маршрутов и так называемая stub-конфигурация.
Как уже говорилось, производить суммирование маршрутов можно на любом роутере. Но давайте проиллюстрируем это. Допустим всё к тому же R2 подключены подсети из 192.168.0.0/24 до 192.168.7.0/24, а мы это дело суммируем в 192.168.0.0/21 (если забыли логику процесса, то курим матчасть). Роутер анонсирует этот суммарный маршрут, а остальные знают, что source address начинающийся на 192.168.0.0~192.168.7.0 это туда. А если отвалится одна из подсетей? Роутер разошлет query-запросы с адресом пропавшей сети (пусть это будет 192.168.5.0/24), но соседи не будут передавать их дальше, а вышлют реплаи, мол "друже, ты ку-ку? это же твоя подсеть, сам разбирайся".
Теперь затронем второй вариант решения. Stub-конфигурация. В нашем случае stub означает “конец пути” или “тупик” в контексте EIGRP. Т.е. для попадания в подсеть, которая с роутером не directly connected (подключена не напрямую) нужно идти назад, возвращаться. Сконфигурированный как stub роутер не будет слать трафик между подсетями, которые стали ему известны благодаря EIGRP (т.е., отмеченными в show ip route буквой D). Соседи также не будут слать ему query-пакеты. Где применяется такой конфиг? В топологиях hub-and-spoke, например, в особенности с избыточными линками.
Представим такую картину. Слева у нас будут филиалы, справа головной офис и сервера и прочее. Для отказоустойчивости у нас подняты избыточные линки и запущен EIGRP на дефолтном конфиге:
Теперь ситуация. R1 теряет связь с R4, а R5 теряет LAN. Трафик из подсети маршрутизатора R1 в подсеть головного офиса пойдет по маршруту R1->R5->R2(или R3)->R4. Будет ли это эффективно? Конечно же нет! Окажутся в печальном положении сетки не только за R1, но и за R2 (или R3) в связи с увеличением трафика и связанных с этим следствий. Stub существует именно для этого. За маршрутизаторами в филиалах нет других маршрутизаторов со своими подсетями, это как раз и есть "конец дороги", дальше мы можем только вернуться назад. Поэтому конфигурить их нужно именно как стабы, благодаря чему мы избавимся от таких вот кривых маршрутов из примера, а также от флуда query-пакетами при потере маршрута.
Существует несколько режимов работы роутера в качестве stub, настраивается эта прелесть по команде eigrp stub:
R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP as receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routesПри дефолтных настройках, если просто сказать роутеру, что он eigrp stub, включатся режимы сonnected и summary. Для нас представляет интерес режим receive-only, в котором роутер не производит анонсирования известных ему сетей, а только слушает, что говорят ему соседи. Это похоже на команду passive interface в протоколе RIP, но в случае с EIGRP она полностью отключит протокол на выбранном интерфейсе, что не даст установить соседства в принципе.
О чем мы не поговорили и что хотелось бы в ближайшее время обсудить?
• Настройка аутентификации соседей в EIGRP;
• Принципы graceful shutdown;
• Балансировка нагрузки.
Динамическая маршрутизация. Первое знакомство.
Теория протоколов динамической маршрутизации
Протокол OSPF
Практика OSPF
Проверка работоспособности OSPF
Протокол EIGRP
Практика EIGRP
Настройка передачи маршрутов между различными протоколами
Разбор практических задач
