Лабораторная работа по EIGRP Named Mode

Давайте посмотрим, как настраивается EIGRP в именованном режиме. Если у нас есть роутер, на котором уже есть какой-то классический режим, то мы на этом роутере будем видеть всякие режимы конфигурации EIGRP, частично раскиданные в конфиге по контексту роутера EIGRP, частично раскиданные по интерфейсам. Как, например, на моем роутере R1. Enable, show, run. Я вижу, что у меня здесь есть настройки EIGRP. Я вижу настройки EIGRP. IPv6 EIGRP. В настройке интерфейс Ethernet 0012. Вижу здесь EIGRP, IPv6 EIGRP.

И EIGRP 65-тысячный. Тут EIGRP 65-тысячный. Здесь. Это все в разных местах конфига. Мне очень сложно сразу при одном взгляде на эту железку понять, что из конфига относится к EIGRP. Где-то, возможно, есть еще какие-то куски, которые я не увидел. И мне нельзя одной командой сказать «а ну-ка покажи мне все, что касается EIGRP на этом устройстве». Для того чтобы перевести настройку EIGRP для IPv4 и настройку EIGRP для IPv6 в именованный режим, можно воспользоваться на этом роутере командой Upgrade CLI. Conf t. Router EIGRP 65000. EIGRP Upgrade CLI. CCNP, раз так на слайдах было. И система спрашивает, действительно ли я хочу перейти из классического режима в именованный режим.

Я согласен с тем, что я действительно хочу перейти. Система просто сожрала конфигурацию и обновила все в том виде, в котором оно было. Все те же самые фичи остались. Единственное, что изменилось, это представление конфигурации в конфиге. Show run. Здесь уже в настройках интерфейса ничего не осталось, относящегося к EIGRP. В настройке... Да, IPv4 не осталось. IPv6 пока еще есть. Все, что касалось IPv4, переехало сюда. У нас есть некоторое количество команд network, которые были. И все. То же самое можно сделать с IPv6. Он тоже раскидан по разным частям конфига. Conf t. Сейчас IPv6 router. EIGRP 65000.

Если я сейчас попытаюсь тот же самый экземпляр задать, система ругнется, скажет, что такое уже есть. Поэтому надо сделать другой — CCNP, не знаю, v6. Собак страшный. Есть. И система опять же в IPv6 тоже пробежалась по конфигу, собрала все детали конфига из разных частей и сложила их все в одно место. Show run. Видите, да? Здесь раньше было IPv6 EIGRP. Здесь оно перестало быть. Здесь тоже было IPv6 EIGRP. Сейчас его тут нет. Но зато у нас появился новый контекст. EIGRP CCNPv6. В котором рассказывается, что у нас на всех интерфейсах по умолчанию EIGRP не работает. Действие команды, в кавычках, Network 0.0.0.0, которой здесь нет, но тем не менее которая по умолчанию в EIGRP в именованном режиме есть, оно таким образом отменяется.

А дальше мы говорим: на интерфейсе Ethernet 0.0.101 мы хотим включить EIGRP в явном виде. На 0.0.12 мы хотим включить EIGRP в явном виде. И плюс, если мы будем прописывать какие-то summary address или прочее, они опять же на этих интерфейсах будут прописываться. Если мы захотим включить стаб, опять же все это здесь будет прописываться. С таким именованным режимом довольно удобно работать. Единственное, если действительно у вас был IPv4 и IPv6, то придется неизбежно сказать, что мы хотим соединить и IPv4, и IPv6 именованный режим в одном экземпляре. Просто потому что неудобно, когда у вас два именованных экземпляра. Один для одной автономной системы, другой для другой. Намного удобнее, когда это все в одном месте лежит. Если у вас такое произошло, вы можете сказать: у нас есть содержимое роутера EIGRP CCNPv6. Мы его тупо копируем, целиком копипастим и говорим:

Conf t. No router EIGRP CCNPv6. Router EIGRP CCNP просто. А, router EIGRP CCNP просто. И дальше копипастим все то, что там было. Естественно, связь у нас рвется. Естественно, что трафик при этом перестает ходить через роутер на то время, пока мы перекидываем конфигурацию из одного именованного контекста в другой. Но тем не менее, да. Теперь у нас все в одном месте лежит. Show run. Она действительно все в одном месте. Все, что касается EIGRP. Часть относится к IPv4, часть относится к IPv6. С такой штукой намного удобнее работать. Опять же, никакие детали конфига не уходят в другие части, если мы говорим про EIGRP.

Если у нас что-то происходит, имеющее отношение к EIGRP, то оно все сидит в контексте роутера EIGRP. Это действительно очень удобно. Если говорить про другие операционные системы Cisco, то, например, аналогичная концепция есть в Cisco IOS XR. Там тоже операционная система написана с нуля. И там тоже все процессы, которые будут самостоятельные, автономные, они тоже все будут иметь примерно такую же структуру. Запускаем EIGRP — все настройки EIGRP будут храниться в одном месте. Запускаем BGP — все настройки BGP хранятся в одном месте. Если вы работали с Juniper, там та же самая история: у вас нет такого, что часть конфига хранится там, часть здесь, часть тут, а часть вообще надо иметь в виду, что она дефолтная. Здесь Cisco явно вдохновлялась Juniper, когда придумывала этот самый именованный режим. Дальше. Если мы хотим с нуля сконфигурировать именованный режим, то надо просто повторить ту структуру, которая здесь есть.

Запустить именованный экземпляр, запустить Address Family с номером автономной системы, сказать команду Network в IPv4, не использовать команду Network в IPv6, потому что ее нету. Использовать что-то типа AF Interface Default, и там в нем, скорее всего, сказать shutdown. И дальше на тех интерфейсах, которые вы хотите в явном виде включить, использовать no shutdown. Еще бы rename был. На самом деле он есть, но настолько неудобный в использовании, что можно считать, что его нет. Да. Давайте попробуем с нуля настроить EIGRP на каком-нибудь нашем роутере. У нас есть R2. Enable. Show run. Сейчас посмотрю, попытаюсь понять, насколько будет тяжело переписать с нуля конфигурацию. Так, на loopback IPv6. На Ethernet 0.12.

0.102. И пачка команд Network. Окей, давайте попробуем переписать с нуля. Conf t. No router EIGRP 65000. Никогда не делайте так в реальном мире, потому что в реальном мире вы будете с Cisco, скорее всего, работать по какому-то протоколу удаленного управления. Если вы убьете протокол динамической маршрутизации, который притаскивает маршруты, с помощью которых вы этой Cisco управляли, то вы потеряете управление. Поэтому такое можно делать только с консоли. Вы, если хотите, можете попробовать сделать с нуля, потому что вам это может быть полезно. Вы отработаете эти команды, они у вас останутся на кончиках пальцев. Поэтому, если хотите — а я думаю, что вы должны хотеть — вы можете это сделать. У вас сейчас есть такая возможность. Удалили IPv6.

No IPv6 router EIGRP. Что-то он в IPv4 EIGRP не потерял соседей. Странно. Дальше настраиваем с нуля. Router EIGRP CCNP. Address Family IPv4. Если память не изменяет, можно не писать Unicast. Можно сразу писать Autonomous System. Да. Autonomous System 65000. И если вдруг захотите с VRF, то можно запустить отдельный контекст, отдельное адресное семейство для того чтобы выполнять таблицу VRF какого-то не дефолтного, не global. И здесь мы прописываем network. Мне проще прописать network 0.0.0.0, чтобы потом в default interface просто прибить все эти интерфейсы, чем повторно вписывать те network'и, которые были у нас здесь.

Понятное дело, что если бы я действительно апгрейдил CLI, то она бы все эти команды network у меня скопипастила. Мне проще сказать так. Включаем EIGRP для IPv4 на всех интерфейсах. У нас нашлись EIGRP-соседи на двух интерфейсах. На 10.15, на 12-м VLAN'е и на 102-м VLAN'е. Можно будет сказать: network, AF interface default, shutdown. Мы выключаем EIGRP на всех интерфейсах. У нас отваливается один сосед. Затем мы заходим в AF interface Ethernet 0.0.12. Говорим no shutdown. Аналогично AF interface Ethernet 0.0.102. No shutdown. У меня еще на втором роутере должен быть 24-й.

AF interface 24-й. No shutdown. На всех интерфейсах, где я ожидал увидеть соседей, я прописал no shutdown. Конфигурация do show run section EIGRP. Покажет, что у нас получилось с EIGRP. Такой контекст EIGRP. В команде network мы говорим: включаем EIGRP на всех интерфейсах. Действие команды AF interface default переопределяет действие команды, выключает EIGRP на всех интерфейсах. Но действие команды AF interface no shutdown переопределяет действие команды shutdown. Поэтому по факту на тех интерфейсах, где мы хотим EIGRP увидеть, мы указываем команду no shutdown. И на этом интерфейсе EIGRP начинает работать. Немножко дурацкая концепция, но тем не менее вы можете не использовать ее.

Вы можете командами network включать EIGRP только на тех интерфейсах, где вам это будет нужно. Но мне кажется, что эта команда network максимально дурацкая. И опять же, она задает условия access list, которые переопределяют IP-шники на интерфейсах, которые попадают в это условие, на которых включается и так далее. На мой взгляд, no shutdown в настройке AF interface более говорящая. Понятное дело, что если вам не нравится такой кривой концепт, то вы можете использовать старый подход, при котором вы network'ами все включаете. Мне больше нравится network 0.0.0.0 и AF interface default shutdown. В IPv6 по умолчанию действует именно концепция network 0.0.0.0 и AF interface default shutdown. Поэтому приучайтесь, наверное, еще и к этому, что в IPv6 Named Mode ведет себя именно таким образом, как мы сейчас настроили в IPv4. Дальше. Если у нас есть соседи, которые присылают нам какие-то маршруты, мы можем с этими маршрутами что-нибудь делать. Мы можем эти маршруты фильтровать, можем эти маршруты редистрибутить куда-нибудь.

Можем в EIGRP какие-то новые маршруты вбрасывать. И опять же, можно это делать с помощью как классического, так и именованного режима. В принципе, в именованном режиме это даже красивее делается. Но надо будет помнить, что в именованном режиме все настройки по манипуляции маршрутами мы будем делать не на уровне интерфейсов, а на уровне топологии. Мы выходим из контекста AF interface. Мы находимся в приглашении к вводу, которое показывает, где мы сейчас. Config router намекает на то, что мы в именованном режиме роутера EIGRP. И дальше AF — это адресное семейство, Address Family. И здесь мы говорим AF topology base. Просто topology base. И здесь в настройке topology base можно всякое разное сделать.

Обратите внимание, в настройке самого адресного семейства можно сделать некоторые вещи. Можно показать, какие дефолтные метрики будут, можно показать максимум префикс. И больше ничего особенного. Таймеры можно задать. Всякие команды по манипуляции маршрутами, по вбросу маршрутов, по редистрибуции, по, например, offset-листам — можно добавлять или удалять к компонентам метрики разные числа, чтобы у вас получалось возможным манипулировать маршрутами, что от одного из соседей маршруты будут более приоритетны, чем у другого, невзирая на саму метрику, которую он нам присылает. Все это делается в настройке топологии. Можно будет в некоторых случаях даже сказать, что кое-какие настройки будут применимы только для отдельной топологии, но применительно именно к интерфейсу.

Для этого вы будете переходить в контекст topology interface. Я даже забыл, что там есть. Topology interface. Да, можно будет таймеры для конкретного адресного семейства, для конкретного интерфейса поменять в отдельную топологию. Но проще это делать в AF interface. Давайте попробуем настроить фильтрацию маршрутов. У нас сейчас есть на нашем роутере... Show run. У нас сейчас есть loopback. Loopback замечательный. На нем есть 10.15.2.2 IP-шник, то есть 10 — номер комплекта, 2.2.

Если я сейчас правильно понимаю... Show EIGRP address family IPv4 interfaces... Да, этот loopback у нас не включен в EIGRP. Убедитесь, пожалуйста, что у вас тоже он не включен, что на вашем роутере loopback отсутствует в списке интерфейсов в команде show EIGRP address family IPv4 interfaces. В принципе, если вы не помните эту команду, show IPv4 interfaces тоже работает. Show IPv4 interfaces. Видите, да? Это одна и та же команда. Дает одинаковый вывод, идентичный. Здесь мы видим, что loopback нет. Как следствие, IP-шник с loopback мы не анонсируем нашим соседям. Хочется, чтобы эти loopback у нас все-таки протаскивались. Поэтому мы сейчас сделаем следующую штуку. У нас этот IP-шник будет редистрибутиться. У нас есть connected маршрут.

И мы сейчас возьмем все connected маршруты, пропустим их через route-map и по некоторому правилу вбросим в таблицу топологии EIGRP. Даже не через route-map, наверное, а через distribute-листы. Нам нужно будет сделать либо access list, либо prefix list, который будет разрешать IP-шную сеть с этого самого loopback и не разрешать все остальное. У меня сетка на loopback 10.15.2.2 по 32-й маске. Я сейчас напишу такой prefix list, который будет говорить «да» только на эту сетку. IP prefix list. Permit 10.15.2.2. Я здесь хочу пропускать только один единственный префикс, один единственный маршрут.

Поэтому я здесь не указываю ограничение длины маски. Мне нужно сказать только на одну единственную сетку 10.15.2.2 именно по маске 32-й, что я такую сеть разрешаю. Поэтому я здесь указываю просто Enter и не даю дополнительных ограничений. Если бы я хотел с prefix list'ом отобрать все маршруты, которые попадают под какой-то критерий, и критерий на маску мне нужно было бы задать, тогда да. Тогда я бы мог сказать «дай-ка мне, пожалуйста, все дочерние сетки по отношению к этой родительской сетке, которые попадают под определённые условия». Но здесь я не указываю ничего, и мне нужно только на одну единственную сетку сказать 10.15.2.2 по 32-й маске Permit. И затем я иду в настройку router EIGRP CCNP. Указываю Address Family. IPv4 Autonomous System 65000. И здесь мне нужно Topology Base.

Сейчас я возьму маршруты Connected и анонсирую их в таблицу Topology EIGRP. Redistribute. Redistribute Connected. Но я анонсирую вообще все Connected маршруты, что на самом деле нежелательно, и я не хочу, чтобы все сетки Connected попадали в анонс, поэтому я указываю Distribute List. Distribute List. Здесь можно задать либо Access List, либо Prefix List, либо Route Map. С Route Map мы уже работали. Prefix List. Дальше система спрашивает, на вход или на выход мы хотим повесить фильтрацию. Здесь речь идет про фильтрацию в направлении в сторону таблицы маршрутизации или из таблицы маршрутизации. Если мы занимаемся редистрибуцией из таблицы маршрутизации в EIGRP, то у нас исходящие апдейты из таблицы маршрутизации в сторону EIGRP.

Поэтому мы говорим Out и дальше указываем, откуда забираем маршруты. В нашем случае Connected. Маршруты будут в таблице маршрутизации, помеченные как Connected. Так, забыл сам Prefix List задать. Prefix List. Out. Не понял. Что-то я не понял, где задается название Access List. Distribute List. Out. Prefix. А, Prefix. Не Prefix List, а Prefix. Да.

Prefix. Обратите внимание, я здесь написал Prefix List, и система это восприняла как именованный Access List. То есть это не совпадало ни с числом, ни с другим числом, ни со словом Gateway, ни со словом Prefix, ни со словом Route Map. Поэтому она сказала: это просто какое-то имя, которое называет именованный Access List. И она взяла слово Prefix List, командное слово, и попыталась его трактовать как название именованного Access List. Нужно было назвать Prefix. Back. Здесь мы можем, если захотим, указать, что апдейты, которые к нам приходят, надо фильтровать дополнительно по IP-адресу, откуда они пришли. Но для Connected маршрутов это не очень актуально, поэтому здесь мы говорим Out. Out.

В Distribute List надо удалить строчку, потому что он её вставил в первый раз. Сделал. Do, show, run. Topology Base, redistribute connected, distribute list, Prefix, loopback out connected. Команда, которую я ввел. Distribute List говорит, что когда мы работаем с маршрутами, которые идут в сторону таблицы маршрутизации или из таблицы маршрутизации, мы их прогоняем через какие-то фильтры. Дальше мы указываем, что за тип фильтра используем. Это не слово названия Access List, это не номер Access List, это слово Prefix.

И поэтому дальше мы указываем название Prefix List. Prefix List у нас называется loopback. Out намекает на то, что мы из таблицы маршрутизации на выход выдаем маршруты, и маршруты будут Connected типа. Если на выходе из таблицы маршрутизации в наш EIGRP будут попадать маршруты типа Connected, они будут проверяться по Prefix List loopback. И в Prefix List loopback единственный маршрут, который разрешается, это как раз тот, который у нас есть. Show EIGRP. IPv4. Unicast. Здесь надо найти мой маршрут. 10.15.24.0 Connected. 15.15.1.1.

Очень долго будут искать. Topology. 10.15.2.2 по 32-й маске. Ух ты, а он не попал под вброс. Почему он не попал под вброс? Show Prefix List. 10.15.2.2 по 32-й маске. Show Prefix List. По 32-й маске. Show IPv4.

10.15.2.2. Directly Connected. Для маршрутов Connected не надо вписывать дефолтную метрику, потому что забираются свойства этого маршрута с интерфейса. Я как раз хотел сделать, чтобы у нас Connected сетка с этого loopback дистрибутилась в EIGRP. То есть вот настройка EIGRP, здесь мы на loopback ничего не включали, но мы взяли redistribute connected и сказали, что Connected маршруты мы прогоняем через Distribute List Prefix loopback.

И вообще-то говоря я ожидаю, что здесь должно появиться. EIGRP. Address Family. IPv4. Autonomous System 65000. И соответственно Topology. Так, он не дистрибутится. Почему он не дистрибутится? Подозрительно как-то.

Так, 1 килобит, задержка 0. Я здесь метрики от балды поставил. Понятное дело, что у реального интерфейса конечно же MTU в единицу быть не может, равно как не может быть loading, reliability и 0. Но я просто поставил их какие попало. Не понимаю, где-то видимо ошибся, где — понять не могу.

Вроде Distribute List убрал, redistribute connected сделал, сетка определённо Connected на loopback. Не понимаю. Давайте тогда на секундочку это дело отложим, я разберусь с этим чуть попозже и потом вам расскажу. Давайте пока сделаем loopback, а stub-ы как раз нам здесь не помешали бы. Были бы дистрибученные маршруты. IP. Вот статика есть какая-нибудь? Даже и статики нету. Так, у нас есть роутер R3. У этого роутера R3...

Enable, show ip eigrp neighbors. Есть два соседа: сосед 4 и сосед 1. Сейчас на этот роутер приходят апдейты, сейчас на этот роутер приходят Query. И сейчас этот роутер вынужден отвечать своими Reply в сторону соседей, когда к нему приходят запросы. И чтобы найти эти Reply, он должен высасывать из пальца — он должен опрашивать всех своих соседей, спрашивать, действительно ли такая сетка где-то там в сети присутствует. Если мы хотим сократить количество этих Reply, сократить количество запросов, просто чтобы служебный трафик EIGRP слишком много не занимал, то мы можем объявить роутер stub-ом и тем самым сказать: этот роутер не будет транзитным для по крайней мере некоторого трафика. Причем в некоторых ситуациях роутер конечно же транзитным быть должен. Но если мы говорим про типичный сценарий использования EIGRP, то он должен быть транзитным только для тех клиентов, которые к нему непосредственно подключены.

Вот те сетки, которые у него Connected, на которых EIGRP штатно включился — они должны быть анонсированы своим соседям, и тогда трафик именно этих сетей должен проходить через этот роутер. Все роутеры в топологии должны знать, что до этих сетей надо добираться именно через нас. И также если вы занимаетесь суммаризацией — тоже это опять же в большинстве ситуаций связано как раз с тем, что вы имеете некоторое количество сетей. Классический сценарий: у вас есть Distribution блок, в этом Distribution блоке пачка Access свитчей. Они, как правило, тупые, трафик внутри блокируется на некоторых линках, но главное, чтобы он дошел до Distribution свитчей. А Distribution свитчи — у них есть уже SVI, и на этих SVI работает маршрутизация, там же работает какой-нибудь условный HSRP или VRRP. И дальше во всю остальную сеть каждый Distribution блок уже отправляет трафик с помощью протокола, и там уже работает чистая маршрутизация.

И для того чтобы не рассказывать, что у меня есть VLAN такой, VLAN сякой, VLAN 5, VLAN 10, как правило Distribution блоку выделяется просто одна большая сеть. И дальше внутри Distribution блока эти сетки пилятся на кусочки. Но для того чтобы сократить количество записей в таблице маршрутизации, наружу анонсируется только суммарная сетка. Если вы порождаете суммарные сетки внутри филиального какого-то роутера для того, чтобы анонсировать наружу именно большую суммарную сетку, то эти суммарки тоже отправляются нормально, и по ним как раз тоже всё будет хорошо. Если вдруг вы будете анонсировать такую сеть, то естественно трафик именно через вас должен ходить до этих адресов. Query вам присылать на эту сеть бесполезно, потому что вы будете сами на Query отвечать — вы будете рассказывать про то, что сетка у вас действительно есть.

И если вдруг к вам Query будет приходить, то вы сразу будете отвечать Reply, что да, всё хорошо, у вас эта сетка точно живая. Если кто-то будет присылать вам Query по каким-то другим вопросам, по тем сеткам, которые на вас не должны быть, то вы будете сразу отвечать Reply, что у вас этой сетки нет и быть не может, потому что вы не транзитный роутер. Поэтому да, в некоторых ситуациях stub-ы действительно ускоряют работу EIGRP. Давайте попробуем это сделать. У нас сейчас есть роутер 3, он работает в, если мне не изменяет память, классическом режиме. Show run EIGRP. Да, он работает в классическом режиме. И мы сейчас этот роутер объявим stub-ом. Он сейчас таковым не является. Заходим conf t, router EIGRP. И указываем eigrp stub. Просто нажать Enter, и тогда вы будете анонсировать Connected сетки и Summary.

Вот такая одна команда без ничего делает именно следующее: она заставляет вас проставить флаг, чтобы анонсировать Connected сетки и Summary. И соответственно, если вы ничего не указываете, Connected и Summary маршруты действительно анонсируются, и больше ничего. Соседи видят, что вы анонсируете. Если вы посмотрите, например, на роутер 4 — show ip eigrp neighbors — Connected и Summary сетки на роутере 4 будет видно, что он согласен анонсировать, а больше он ничего не анонсирует. Никакие транзитные маршруты stub-роутер пересылать не будет. Если вдруг роутер 3, будучи stub-ом, попытается redistribute что-то из таблицы маршрутизации в таблицу топологии EIGRP, то такие маршруты не уйдут дальше.

Если вдруг вы хотите заставить ваш роутер 3 анонсировать какие-то маршруты, то вам нужно будет в команде eigrp stub добавить указание, какие именно сети вы будете анонсировать. Там по умолчанию дистрибученные сетки не показываются. Здесь есть выбор, что вы хотите анонсировать. Redistribute — и тут как раз то, что вы берёте сетки из таблицы маршрутизации и вбрасываете их в EIGRP. Если вы будете указывать redistribute, вам надо будет не забыть указать Connected и Summary в явном виде, если они вам нужны. В большинстве ситуаций будут нужны. Для статических маршрутов, которые redistribute в EIGRP, есть особая штука — eigrp stub static. Это как раз указание на то, что вы допускаете redistribute статических маршрутов внутри EIGRP. Казалось бы, redistribute должна бы покрывать их, но нет. Верхний redistribute — это именно про то, что все нормальные маршруты кроме статических. А redistribute статических маршрутов — это вот это.

Давайте попробуем прописать и Connected, и Summary, и Redistribute, и Static. То есть мы вбрасываем в EIGRP маршруты и Connected, и Summary, и Redistribute, и Static — вообще все, которые только можно. Связь поднимается. Теперь нам надо где-то статические маршруты взять и redistribute их. Сделаем такой статический маршрут: ip route 10.номер_комплекта.номер_роутера.номер_роутера 255.255.255.0 0.0.0.0. Я сделал статический маршрут, который смотрит в 0.0.0.0. И у меня есть команда redistribute static в настройках роутера, которая берёт все статические маршруты и вбрасывает их в EIGRP.

Поскольку это роутер — EIGRP stub, и в команде stub есть redistribute и static, то соответственно такие маршруты действительно анонсируются соседям. И на, например, четвёртом роутере show ip route 10.15.3.3 будут показываться свойства этого маршрута, показывается next hop, который у нас есть. Да, если в таблице маршрутизации посмотреть, будет видно, что этот маршрут для EIGRP внешний, у него тип External и административное расстояние 170. И здесь всё остальное нам уже привычно.

Так, здесь будет работать интересно. Prefix List. Permit. 10.15.3.3 по 32-й маске. Router. EIGRP 65000. Distribute List. Prefix. Static. Так, это у нас Static. Маршруты, которые статические, прогоняем через Distribute List, через Prefix List, для того чтобы всё, на что Prefix List сказал «да», мы бы действительно вбросили в EIGRP, а всё остальное не вбросили. У нас пока статический маршрут только один, поэтому с ним всё просто.

Вот гипотетически соседство пересинхронизировалось и в таблице маршрутизации такой маршрут всё ещё есть. При этом если я сделаю ещё какой-нибудь другой статический маршрут, например .33, то он в таблицу EIGRP уже не вбросится. Topology. 10.15.3.33 по 32-й маске. Вот такого маршрута в таблице нет. Вот такой пример, как можно фильтровать маршруты из таблицы маршрутизации и выборочно вбрасывать их в EIGRP. Можно делать это с помощью Route Map — Route Map-ом можно на уровне команды redistribute вбрасывать маршруты и заодно там метрики проставлять, и всякие свойства типа тегов, и всё остальное.

Но здесь у нас такой простенький вариант, когда мы просто говорим redistribute static и дальше Distribute List-ом говорим, что это простенький вариант, который будет брать наши маршруты и вбрасывать их в EIGRP с помощью фильтрации по обычному Prefix List без Route Map. Здесь видно, что у нас есть теги — метки, с помощью которых мы маршруты можем раскрасить. Видно, что в EIGRP у нас этот маршрут взялся из статической маршрутизации. Метрика у статических маршрутов была 0. Для статических маршрутов номер автономной системы не применим, поэтому там тоже 0. Это вот эти три блока показывают про то, кто нарисовал такой маршрут. И видно, что метрика у этого маршрута вот такая хорошая: что на роутере-отправителя 10-гигабитный интерфейс, задержка 0 микросекунд суммарная, абсолютно ненадёжный интерфейс — я его таким сделал.

Минимальная загрузка, и MTU тут 1500. Что если мы захотим какие-то пакеты выбрасывать, такие пакеты должны быть не больше 1500 байт размером. Со stub-ами посмотрели, с дистрибуцией посмотрели. Непонятно, почему у меня на R2 не завелась дистрибуция, то есть казалось бы, всё вроде точно так же делали. Непонятно. Давайте покажу конфиг роутера EIGRP, который сейчас у меня в итоге получился. Show run section EIGRP. Вот команда Distribute List говорит, что все маршруты, которые статически приходят из таблицы маршрутизации и уходят в нашу топологию EIGRP, мы прогоняем через Prefix List, который называется static. То, что статические маршруты из таблицы маршрутизации должны к нам приходить, указывает вот эта команда redistribute static.

И те маршруты, которые дистрибучены из статики, будут действительно анонсироваться нашим соседям, потому что у нас есть команда eigrp stub с ключом redistribute и static. Если не будет слова static, то эти маршруты не пройдут в сторону соседей, потому что по ним видно, что они были redistribute из статики.