Настройка EIGRP Classic Mode (часть 2)

Продолжаем заниматься нашим курсом ROUT. В прошлый раз мы закончили на том, что прошли базовую теорию по протоколу EIGRP, посмотрели, как он в Cisco включается, посмотрели, как настраиваются таймеры. И давайте сейчас это дело проверим на практике. Наши лабораторные стенды сейчас должны быть полностью настроены на базовое IP-шное взаимодействие. У нас все интерфейсы, которые прописаны в топологии, должны быть правильно и корректно прописаны. Плюс у нас сейчас есть DMVPN и плюс у нас сейчас есть RIP. И еще PPPOE. Если вдруг вы PPPOE или DMVPN удалили, ничего страшного. Сейчас мы на лету можем его поднять. Давайте RIP выключим, чтобы он нам не мешался, пока он нам не пригодится. Enable. No router rip.

Enable. Conf. No router rip. Enable. Conf. No router rip. И последнее. Enable. Conf. No router rip. Enable. Conf. No router rip. RIP выключили. И мы можем с вами настроить EIGRP. Надо ли шестёрку выключать? Пока не надо. Мы EIGRP для IPv6 ещё пока не проходили, как настраивается. Поэтому RIP шестой версии нам не мешает. Давайте договоримся, что мы будем включать EIGRP, и нам нужно будет убедиться, что все мы находимся в одной топологии. Поэтому нам придётся использовать одинаковый номер автономной системы, и я предлагаю использовать номер автономной системы 65000.

Не потому, что в EIGRP этот номер какой-то особенный, а исключительно потому, что в BGP номера автономных систем тоже есть. Они там другого размера, они там выделяются IANA, и вот там во множестве адресов автономных систем в совершенно никак не связанном с EIGRP протоколе BGP 65000 — это номер, который будет частным, там все номера с 65512 будут частными. Но у нас совершенно другой протокол, и в принципе мы можем использовать автономную систему с абсолютно любым номером, который захотим. Захотим единичку — пожалуйста, захотим 123 — пожалуйста. Но я предлагаю использовать 65000, просто потому что можем. Router EIGRP 65000. И дальше нам нужно будет включить EIGRP на тех интерфейсах, где мы хотим установить соседские отношения. В частности, у нас сейчас есть интерфейс, который с первого роутера смотрит на центральный.

Это интерфейс Ethernet 0/0.101. Вот у него есть какой-то IP-шник. Router EIGRP 65000. Мне надо на интерфейсе Ethernet 0/0.101 включить EIGRP. Для того чтобы это сделать, мне нужно будет прописать команду network. И дальше указать IP-шник с маской, которые зададут эталонный IP-шник и wildcard-маску. Для тех интерфейсов, для тех IP-шников на интерфейсах, на которых надо включить EIGRP. IP-шник, который висит на интерфейсе Ethernet 0/0.101, у нас будет 10.101...

Network 10... Дальше связь внутри 15-го комплекта с первого на второй — это первый роутер. И ещё первый роутер у меня смотрит на третий. Два интерфейса: между первым и вторым, между первым и третьим — на них включается EIGRP. Вот я на трёх интерфейсах включил EIGRP командой network. Вы тоже у себя включаете EIGRP на трёх интерфейсах: с первого роутера на центральный Core 1, с первого роутера на второй, с первого роутера на третий. У нас три интерфейса, на которых EIGRP должен работать. Равным образом на втором роутере делаем такие же действия: на втором роутере прописываем тот же самый номер автономной системы — router EIGRP 65000. Network 10.100.2.2, дальше 15-й комплект между первым и вторым, между вторым и четвёртым.

Видно, что у нас уже есть какое-то соседство, между первым и вторым роутерами включили EIGRP и там обнаружен сосед. Пробегают сообщения на консоль, точнее в системный журнал, который и на консоли по умолчанию тоже показывается. Причём обратите внимание: мы подключаемся на консоли. Если мы подключались через VTY, через Telnet или SSH, туда автоматически сообщения журнала не валятся. Для того чтобы получать сообщения, если вы подключаетесь удалённо, нужно писать команду terminal monitor, или потом соответственно terminal no monitor. Но тем не менее мы подключаемся на консоли, у нас валятся такие сообщения, и вот мы прописали EIGRP на трёх интерфейсах, и у нас действительно на одном из этих интерфейсов образовалось соседство. Равным образом мы можем на двух других роутерах тоже прописать связи по EIGRP, но я сделаю чуть попозже. У меня просто показывается до четырёх вкладок, и соответственно в двух вкладках у меня сейчас были центральные роутеры, поэтому на них надо настроить сначала.

Router EIGRP. На этом роутере я не хочу на 15 комплектах прописывать — этот IP-шник работает, этот IP-шник работает, этот IP-шник работает. Мне нужно будет, хотелось бы одной командой настроить EIGRP сразу на всех интерфейсах, которые смотрят на наши лабораторные комплекты. Я мог бы это сделать, если бы у меня, допустим, в настройках интерфейса можно было зайти на интерфейс, сказать «этот интерфейс работает в EIGRP» — тогда я мог бы сделать это командой interface range. Но в случае, если у меня есть команда network, я могу воспользоваться хитростью: network 10.101.0.0 по маске 0.0.255.255. Те интерфейсы, IP-шники которых начинаются на первые 16 бит 10.101, на них надо включить EIGRP. Включаю, и у нас обнаруживается пачка соседей. Сразу как только мы отправляем hello-пакет, сразу приходит ответный пакет, сразу проходят update-ы, сразу мы устанавливаем соседство, сразу соседей кормим маршрутами.

И вот я вижу, что некоторое количество соседей установилось. С восьмым комплектом какая-то у нас беда — там 8-й комплект и 9-й комплект перепутали IP-шники: то ли я перепутал, то ли он перепутал. У нас вот здесь валится, если вы 8-й и 9-й комплект — проверьте, пожалуйста, что у вас всё правильно, всё корректно. Показать на первом роутере настройки Ethernet 0/0.101 — легко: show run. Вот и весь конфиг, только номер комплекта. Что-то здесь у нас не то. Пакеты, которые приходят на нашем интерфейсе Ethernet 0/0.101, приходят из-под IP-шника, который с нами не в одной сети. Вот как раз я говорил, что если у вас primary IP-шники не совпадают, то соседство не будет установлено. У нас IP-шник 10.101.9.1 по 24-й маске, а пакеты приходят из-под IP-шника 10.101.8.1.

То ли я напутал с коммутацией, то ли почему-то у нас — такого быть по идее не должно, — но тем не менее почему-то у нас сосед приходит из-под IP-шника 10.101.8.1, хотя должен приходить из-под IP-шника 10.101.9.1. Давайте включу дебаг сообщений EIGRP. Мы их пока не проходили, но нам пригодятся потом. Debug EIGRP packet hello — я включаю отображение на экране каждый раз, когда у нас проходит hello-сообщение. Каждый раз, когда у нас проходит hello-сообщение, у нас на консоль вываливается информация. Из этого нас сейчас будет интересовать вот эта вещь.

Receive hello на интерфейсе 0/0.101 — пакеты приходят из-под IP-шника 10.101.8.1, хотя должны быть в сети 10.101.9.0. Если у вас 9-й комплект, проверьте, пожалуйста, что IP-шник у вас прописан верно. Если нет, то я сейчас тогда подключусь, проверю сам. Включил R2, и устанавливается сразу пачка соседств. Вижу, что 3, 4, 5, 6, 12, 11, 15 установились. На Core... Погодите, Дима. Смотрите, Core-роутеры — это вот Core 1, Core 2. У вас роутеры просто от 1, 2, 3, 4. Соответственно там 15-й комплект у меня, у вас будет какой-то другой комплект.

У вас на роутере 4 есть интерфейс 0/0.13 — это подозрительно, потому что на четвёртом роутере должен быть интерфейс либо 14, либо 24, скорее 24. На четвёртом роутере 14 не надо делать, и 34 там ещё есть. Проверьте по табличке топологии, у вас есть она на лабораторном комплекте — на каких роутерах какие интерфейсы должны быть. В принципе, если вы сделаете какие-то лишние интерфейсы, ничего плохого не будет. Но смотрите, здесь тоже какая-то проблема с 8-м и 9-м комплектом.

Когда включаю команду network 10.102.0.0 0.0.255.255, происходит следующее: я перебираю все свои интерфейсы, на которых у меня IP-шники попадают в этот диапазон, и на них включаю EIGRP. Как следствие, connected-сетки роутеров Core R1 и Core R2 попадают в анонс. Это сам Core присылает. Это не означает, что на восьмом интерфейсе есть, например, соседство. Но connected-сетка с этого интерфейса уходит в анонс. EIGRP-соседа там нету, но connected-сетка с этого интерфейса уходит в анонс. Вы включили EIGRP. Пока что ничего, кроме базовой настройки, мы не делали.

Давайте на всякий случай посмотрим, как мы можем подтюнить работу EIGRP в рамках того, что мы уже прошли. Router EIGRP 65000, запускаем и смотрим вопросиком, что здесь у нас есть. Auto-summary — как уже говорилось, если мы находимся в разрывных классовых сетях, это может привести к проблемам. Если у вас роутеры со старым IOS, по умолчанию на новых IOS вот эта штука выключена, на старых IOS она как раз включена. И если у вас сосед находится не в той же классовой сети, которую вы собираетесь ему анонсировать, то вы вместо того чтобы анонсировать сетку с маской, анонсируете всю классовую сеть целиком. Сделано это для совместимости со старыми IGRP-роутерами. Для того чтобы избежать проблем, вам нужно это в явном виде выключать, если у вас IOS 12.

Если вы хотите задать router ID, делается эта команда: EIGRP router ID. Он в принципе ни на что не влияет — если у вас несколько роутеров будут совпадать router ID, ничего плохого не случится и ничего плохого не произойдёт. Но если у вас есть несколько роутеров и они вбрасывают маршруты, взятые из каких-то других источников, то в этом случае router ID может какую-то роль сыграть, особенно если вы подключаетесь к такой штуке, как провайдерские VPN — L3 VPN. В этой ситуации лучше будет, если у вас router ID всё-таки будет назначаться уникальный, чтобы не было такого, что на двух роутерах router ID будет одинаковый. Проверить, какой у вас router ID, можно командой show ip protocols. Мы ещё запустим, посмотрим. Maximum paths — это сколько у вас можно одновременно маршрутов в таблицу маршрутизации вбросить. Если у вас есть четыре next hop, которые присылают вам один и тот же маршрут и у них так получилось, что действительно метрика абсолютно идентичная, то вы все четыре можете добавить в таблицу маршрутизации.

Если у вас есть четыре next hop, которые приходят к вам и говорят, что до сети можно добраться, и все четыре next hop проходят feasibility condition, но метрика у них будет разная, вы можете командой variance в настройке роутера поставить допустимое расхождение метрики между метрикой самого выгодного и не самого выгодного маршрута. Во сколько раз метрика невыгодного маршрута может отличаться от метрики выгодного, чтобы такой маршрут можно было добавить в таблицу. При этом, ещё раз напоминаю, только те маршруты, которые пришли от Feasible Successors, можно будет добавить. Если маршрут не прошёл Feasibility Condition, в таблицу мы его не добавляем ни при каких обстоятельствах. Traffic share будет указывать, что будет, если вы будете включать этот самый variance. По умолчанию он выключен, он равен единице, но если вы включаете допустимое расхождение в метриках, то traffic share позволит вам сказать, как между маршрутами с неравной стоимостью CEF следует балансировать трафик. Как мы помним, самой балансировкой EIGRP не занимается. EIGRP только вставляет в таблицу маршрутизации рекомендацию, как CEF следует эту балансировку выполнять.

И если вы вставляете несколько маршрутов с разной метрикой, по умолчанию они у вас будут добавляться все в таблицу маршрутизации, и по умолчанию CEF идёт инструкция: постарайся балансировать трафик между этими next hop-ами в той же пропорции, в которой соотносятся метрики. Чем больше метрика, тем меньше трафика посылаем. Вы можете это отключить. Вы можете сказать, что не надо балансировать трафик сообразно метрикам, надо поровну между всеми аплинками распределять трафик. И в принципе это даже неплохая идея. Давайте попробуем поставить traffic share и variance. У нас есть как минимум несколько маршрутов, которые будут известны из нескольких источников. И проверим, что действительно эта штука будет работать. Maximum paths. А вот maximum secondary paths — я, честно говоря, не знаю, мне такое раньше не встречалось. Это, видимо, на новых IOS штука появилась. Я, честно говоря, не видел её раньше.

Возможно, это ограничение на количество маршрутов, которые не такие же хорошие, как основной. Гипотетически могу предположить. У вас есть variance, которым вы говорите, что выбрасываете в таблицу маршрутизации самый выгодный маршрут и маршруты, которые от него в несколько раз отличаются. И вы можете сказать, сколько таких менее выгодных маршрутов можно будет вбросить — сделать дополнительное ограничение. В определённой ситуации, возможно, это будет даже интересно. Я считаю, что в принципе делать большой параметр maximum paths смысла особого не имеет. Надо будет какую-то очень специфическую сеть получить, чтобы maximum paths больше 4 вообще имел какое-то право на существование. Даже 4, на мой взгляд, это существенно больше, чем в реальной сети будет нужно. Включаем variance. Variance, допустим, 3.

Traffic share по умолчанию как раз учитывает балансировку между маршрутами с неравной стоимостью сообразно метрике. Но если мы скажем traffic share — вопрос, — то здесь нужно будет сказать, что либо мы балансируем по умолчанию сообразно метрикам, либо мы поровну балансируем трафик между всеми интерфейсами сообразно минимальной метрике, которая будет у вас в сети. На самом деле — просто трафик идёт одинаково через все next hop. Я ставлю по умолчанию. По умолчанию как раз балансировка идёт balanced. И посмотрим на то, что у нас таблица маршрутизации будет. Я в предположении, что у нас есть несколько вариантов добраться до удалённых сетей, которые будут иметь два разных next hop. Смотрю на таблицу маршрутизации. Show IP route EIGRP. Маршруты с неравной стоимостью — есть ли у нас такие? Эти с равной стоимостью. Эти с равной стоимостью. Что-то все маршруты с равной стоимостью.

Давайте чего-нибудь поанонсируем, чтобы у нас пришли маршруты, которые будут иметь неравную стоимость. У нас есть loopback. Если я правильно помню, на наших роутерах первом и втором loopback должны быть. Show run interface loopback 0. У нас вообще есть loopback? У нас нет loopback. Давайте сделаем loopback. Для IPv6 мы делали loopback, но я его не вижу в конфигурации. Только физические интерфейсы вижу, loopback не вижу. Enable, show run interface loopback 0.

Tunnel, tunnel, интерфейс, dialer. Не вижу loopback. Давайте сделаем loopback. На двух роутерах мы поставим loopback 10, номер комплекта, точка, номер роутера, точка, номер роутера. 10, допустим, 10.15 в моём случае, 1.1. 10, 15, 2, 2. Интерфейс loopback 0. IP адрес 10.15.1.1. 255, 255, 255.0. И роутер EIGRP 65000. Network 10.15.1.1. Включаем этот интерфейс в EIGRP.

Вы тоже у себя, пожалуйста, сделайте. И на втором тоже мы сейчас сделаем аналогичную штуку. Конфт. Интерфейс loopback 0. IP адрес 10.15.2.2. 255, 255, 255, 255. Роутер EIGRP 65000. Network 10.15.2.2. Сейчас я должен посмотреть. Случайно здесь нажал Enter. Не добавилась ли у меня случайно вся классовая сеть десятка? Do show run section. Добавилась вся классовая сеть десятка. No network 10.0.0.0. Я как раз говорил, что если вы не указываете wildcard маску, то поведение будет такое же, как в RIP.

Вы указываете IP-шник, и вместо неуказанной маски подставляется маска классовая. В случае с IP-шником 10.15.2.2 это соответствует классовой сети 10.0.0.0. И вот она, классовая сеть, добавилась в конфиг. Я надеюсь, что вы добавили свои лупбеки в табличку. Я на R2 сейчас смотрю, что у меня есть настроенная команда Variance. Я хочу увидеть несколько маршрутов, которые будут иметь неравную стоимость. Show IP route EIGRP. У них у всех стоимости равные. Ладно, сделаем неравную стоимость. Что нам стоит? Нам ничего не стоит. У нас есть замечательный инструмент, с помощью которого мы можем регулировать метрику. Метрика у маршрута зависит от нескольких параметров.

Во-первых, задержка. Во-вторых, bandwidth. В-третьих, reliability и load, которые не учитываются. И в-четвертых, возможно, какие-то дополнения к этой самой метрике, которые будут искусственно внесены. В нашем случае мы знаем, что если у нас есть маршруты, которые приходят к нам от центрального роутера, у них с вероятностью единицы все bandwidth будут равны 10 мегабитам, потому что сети зарождаются либо на лупбеках, либо на самих 10-мегабитных интерфейсах, и нигде более узких мест нет. Плюс есть delay, который на интерфейсах добавляется, и кумулятивный delay будет определять метрику. Если вы работаете с EIGRP и хотите искусственно поменять метрику для определённых маршрутов или для некоторых маршрутов, которые приходят на ваши роутеры, вы можете играть либо bandwidth, либо delay. Bandwidth вы должны будете указать на уровне интерфейса, что когда от соседа приходят какие-то маршруты, они приходят через интерфейс с определённым bandwidth, с определённой полосой пропускания.

Если маршрут, который приходит от соседа, будет иметь bandwidth больше, чем вы укажете на интерфейсе, то вы, тем самым занижая bandwidth на интерфейсе к соседу, будете влиять на метрику этих маршрутов, будете им искусственно увеличивать метрику, снижая самое узкое место в транзите до удалённой сети. Но если вы на интерфейсе задаёте delay, то тогда ко всем маршрутам, проходящим через этот интерфейс, будет добавляться то, что вы укажете на интерфейсе в качестве дополнительной задержки, и тогда все маршруты, приходящие через определённый интерфейс, будут иметь изменения в метрике. Мы как раз сейчас такой штукой и воспользуемся. Вообще есть рекомендация. Если вы хотите в EIGRP повлиять на метрику, влияйте на delay на интерфейсе. Не меняйте bandwidth, потому что то, что вы поменяете bandwidth, скажете, что у вас не 10-мегабитный интерфейс, а 5-мегабитный, по факту не обязательно повлияет на те маршруты, которые к вам будут приходить.

А если вы delay поставите больше или меньше, чем он у вас сейчас есть, то это повлияет на метрику совершенно точно. Интерфейс Ethernet 0.0.101.102. На этом роутере Core 2 я принимаю маршруты по 102-му интерфейсу. И я могу на интерфейсе сказать, что задержку на этом интерфейсе EIGRP должен брать не автоматически посчитанную, а какую-то другую. И задаётся этот самый delay как раз в циферке. Трёхбайтовое число, выраженное в десятках микросекунд. Оно не случайно такое. Фактически этот самый delay, который мы здесь укажем, он поедет в EIGRP в качестве свойств интерфейса. Изменение bandwidth заэффектит другие протоколы. Да. Bandwidth действительно будет влиять на EIGRP, на OSPF. Вряд ли у вас одновременно и OSPF, и EIGRP будут на интерфейсе.

Но тем не менее вероятность такая есть. А delay никто не смотрит, кроме EIGRP. Поэтому, если мы хотим изменить только EIGRP-шную метрику и больше ничего, то для этого идеально подходит delay. Сейчас у нас 10-мегабитный интерфейс. Задержка на нём, если мне память не изменяет, 10 миллисекунд. Давайте сделаем единичку. 10 микросекунд ставим задержку. И смотрим на то, что получилось. Сейчас у нас точно совершенно маршруты, которые будут приходить через интерфейс Ethernet 0.0.102, получат метрику меньше, чем мы видели раньше. Ой, не конфт. Show IP route EIGRP. Да, вот они. Метрика поехала. Метрика стала другая. В таблице маршрутизации мы видим, что у нас есть маршруты за 435 тысяч копеек и за 460 тысяч копеек. Оба маршрута добавлены в таблицу.

И между ними будет балансироваться трафик. Часть трафика пойдёт на Core 2, часть трафика пойдёт на роутер R1, чтобы потом выйти на Core R1. Мы таким нехитрым образом сказали, что трафик по факту следует балансировать. Забавный нюанс. Если бы мы изменили метрику на интерфейсе, который соединяет первый и второй роутеры, мы бы не добились балансировки, потому что там у нас не проходило бы условие feasibility condition, скорее всего, для таких маршрутов. А здесь они проходят условие feasibility condition. Оба добавляются в таблицу топологии, оба добавляются в таблицу маршрутизации. И мы видим, что действительно всё правильно, хорошо работает. Дальше. Если у нас будет балансироваться трафик между этими двумя next-hop'ами...

Давайте я закажу отображение. IP route 255, 255, 255, 255, 0. Если я закажу отображение маршрута 10.3.1.0, который у нас действительно балансируется, у него есть два next-hop'а с разной метрикой. И показывается, что есть один next-hop такой, и есть другой next-hop такой. И по каждому next-hop'у показывается суммарная задержка. В одном случае нетронутые 8000 микросекунд, и в другом случае тронутые 7010 микросекунд. Раньше у этих маршрутов был одинаковый delay, потому что количество прыжков между роутерами и все эти прыжки были одинаковые. Количество прыжков было тоже одинаковое, и задержка тоже была одинаковой. Поэтому метрики были тоже одинаковые. Сейчас мы на интерфейсе, который смотрит на центральный роутер Core 2, задержку занизили. Она была 1000 микросекунд, а стала 10 микросекунд.

И получилось, что мы суммарную метрику на маршрутах, которые приходят от Core 2, занизили на 990 копеек. Минимум bandwidth мы не трогали. Маршруты, которые приходили, они приходили с bandwidth 10 мегабит. Мы bandwidth не трогали, поэтому 10 мегабит осталось. А delay мы потрогали. И получили вот такую картинку. Traffic share count здесь должен показываться. Вот он. 240 и 227. Учитывая, что метрика 460 тысяч чуть-чуть побольше, чем метрика 435 тысяч с копейками, примерно эти два числа соотносятся друг к другу как 227 к 240. И EIGRP рекомендует пытаться балансировать трафик именно в такой пропорции. 227 к 240. Чуть-чуть побольше трафика посылать туда, где метрика меньше, чуть-чуть поменьше трафика посылать туда, где метрика больше. Но, естественно, CEF на это скажет, что вы что, с ума сошли?

Я не смогу вам такую точность, такую гранулярность обеспечить. Как в анекдоте. Глаза как у Брэда Питта, лицо как у Джорджа Клуни. Что получится, то получится. Он будет пытаться балансировать. Скорее всего, он на такое посмотрит и скажет, ребят, имейте совесть. Я могу побалансировать вам трафик 7 к 8, либо я могу побалансировать вам трафик поровну, один к одному. Можно сейчас взять и посмотреть на эту сетку, что нам скажет CEF, как он будет по факту балансировать трафик. Show IP CEF 10.3.1.0. Да, он будет балансировать поровну. У него 16 шнурков, 16 бакетов, и видно, что они чередуются. Половина смотрит на Ethernet 0.0.12, половина смотрит на Ethernet 0.0.102. По факту, то, что EIGRP говорит, постарайся побалансировать трафик в пропорции 227 к 240,

CEF говорит, ага, сейчас разбежался, и балансирует трафик поровну. Если бы он мог, он бы, конечно, попытался побалансировать трафик. Он бы сказал, да, никаких проблем, я вам побалансирую. Но у него просто 16 шнурков, и выделить такое количество шнурков под один next-hop и такое количество шнурков под другой next-hop, чтобы в итоге получилась балансировка ближе к этой дроби, чем один к одному, он уже просто не смог. У него 16 шнурков есть, он может часть из этих шнурков направить на одного, часть на другого. И как бы он ни играл, он ближе, чем один к одному, к этой дроби не приблизится. Поэтому балансирует поровну. Дальше. Задержкой поиграли. Что там ещё можно сделать? Настройки интерфейса.

И смотрим на возможные команды. Таймеры. С таймерами всё, в принципе, понятно. Я могу сейчас, например, сказать, что таймеры по умолчанию у меня будут на интерфейсах 5 и 15, потому что у меня достаточно быстрые интерфейсы все, они быстрее, чем полтора мегабита. Но есть таймеры, которые задаются на уровне интерфейса, есть таймеры, которые задаются на уровне всего роутера в целом. Это как минимум Active Timer. Можно Active Time сказать, что маршруты в состоянии stuck in active не должны оставаться слишком долго. В нормальной ситуации, когда мы послали query, мы ждём reply достаточно быстро. Если reply не пришёл за Active Time, то через половину Active Time мы отправляем stuck in active query. И на него ожидаем reply уже быстрее.

В любом случае, этот параметр Active Time по умолчанию 3 минуты. Если для вас stuck in active является проблемой, то вы можете его подкрутить. Опять же, наверное, нет смысла в современных сетях этим таймером заморачиваться, потому что есть замечательная штука, которая называется BFD. У нас, правда, в курсе она не рассматривается. Это bidirectional forwarding detection. Протокол, который использует свои отдельные, типа hello сообщения, которые отправляются существенно чаще, чем EIGRP-шные. И можно, используя протокол BFD, пинговать соседа. Если сосед пингуется, то мы говорим, что с ним всё хорошо, сессия с ним живая. Если BFD перестаёт отвечать, мы пытаемся отправлять ему пакеты, они не возвращаются обратно, то сосед немедленно считается трупом, и сессия с ним рвётся. BFD умеет работать с EIGRP, поэтому если вы захотите проверять живость соседа, то как раз имеет смысл делать это с его помощью.

Нет смысла заморачиваться с подстройкой таймеров EIGRP-шных. В большинстве ситуаций BFD вам даст лучший результат. Что тут можно сделать с VRF? Можно сказать, что у вас есть адресные семейства, и эти адресные семейства будут принадлежать определённым VRF. Можно будет сказать, что у вас есть провайдерский роутер, provider-edge роутер, который смотрит на разных клиентов, и он хочет по EIGRP принимать клиентские маршруты и складывать их в BGP. В этом случае, если у вас клиентов много, Вам как раз имеет смысл запустить один экземпляр EIGRP на всех и сказать, что этот один экземпляр, один процесс EIGRP будет просто в разных VRF дружиться с разными клиентами. В противном случае вам придется запускать по одному процессу EIGRP на каждого соседа, и вы очень скоро упретесь в лимит в количество источников маршрутной информации, которые могут зарегистрироваться для вброса маршрутов в таблицу, в RIB.

Как вы помните, их 32 штуки, причем два из них сразу заняты, static и connected. Поэтому у вас будет BGP одно место отжирать, у вас будет, скорее всего, служебный OSPF в провайдерской сети одно место отжирать, и по факту останется 28 источников маршрутной информации, которые могут быть какие-то еще. И если вы захотите от клиентов для оказания услуги L3 VPN принимать маршруты по EIGRP, то как раз очень удобно будет запустить один экземпляр, и он будет принимать все маршруты от разных клиентов в разных VRF. Про 16 я говорил про Maximum Path, если на экзамене будет Maximum Path, то надо говорить 16. По факту Maximum Path можно указать 32. Вы укажете, что 32 разных маршрута надо пытаться вставить в таблицу до одной и той же сети,

и дальше вы уткнетесь в то, что CEF либо сможет, либо не сможет вам такое количество вставить. 32 по факту. Если вдруг у вас будут одинаковые маршруты до одной и той же сети, одинаковые по метрике или чуть-чуть различающиеся по метрике не более чем Variance 1, то вы попытаетесь их поставить в таблицу все. А дальше вы уткнетесь в CEF, и CEF вам скажет, извините, у меня только 16 шнурков, так что он выберет из всех ваших 32 какие-то 16 случайных и будет на них балансировать трафик. А на оставшиеся не будет. На некоторых железках CEF будет обладать большим количеством шнурков, наши железки они с 16 шнурками, на некоторых железках у CEF будет 32 уже шнурка. Но на экзамене надо говорить, что 16 и всё. Maximum Path, никакие 32 вы там поставить право не имеете. Про редистрибуцию потом поговорим, административное расстояние потом.

Статических соседей прописывать можно только, если тем самым отключить мультикаст на интерфейсе. Если у нас сейчас мы пропишем neighbor и дальше какой-нибудь 10.15.24.4, интерфейс там будет Ethernet 0/24. Я прописываю neighbor на интерфейсе статическом, и у меня отваливается мультикаст. Static peer replaces мультикаст, соседство отваливается. И для того, чтобы оно обратно подключилось, мне на роутере R4 надо сделать ответное действие. Тоже прописать ручками соседа. Enable. Обратите внимание, peer termination received. Это сообщение, peer termination, иногда известно как сообщение goodbye. Это hello-пакет, у которого все k-values, эти самые k1, k2, k3, k4, k5, k6

поставлены в 255. Если сосед рвет соседство с нами, то он посылает такое сообщение нам, и мы понимаем, что несмотря на то, что у нас все хорошо, у нас hello-сообщения от соседа приходили вовремя, с нашей стороны никаких претензий нет, но мы понимаем, что сосед со своей стороны что-то такое сделал, что мешает нам продолжать работу. И до тех пор, пока мы не исправим эту проблему, соседство у нас не поднимется. EIGRP 65000, Neighbor 10.15.242, Ethernet 0/24. Статический сосед прописан, и я ожидаю, что соседство у нас установится. Такая штука, которая позволяет отключить мультикаст на интерфейсе.

Еще одна полезная штука — это команда shutdown. Я про нее не рассказывал ни на CCNA, ни на CCNP еще пока. И делает она следующее. Она выключает именно процесс маршрутизации EIGRP. При этом у вас железка остается живой. Зачем это бывает нужно? Если вы начинаете настраивать EIGRP, у вас, возможно, ваши команды по настройке повлекут за собой какие-то флаппинги, изменения. Если вы особенно начинаете там с редистрибуции косячить, вы хотите вбросить в EIGRP какие-то маршруты, и вы хотите настроить этот самый EIGRP, сначала сказать давайте редистрибутить, потом сказать, какие именно маршруты редистрибутим, прописать route-map. Вероятность того, что вы все сделаете с первого раза правильно, она может быть довольно небольшой. Поэтому, если вдруг вы подозреваете, что у вас в какой-то момент внутри вашей конфигурации будут какие-то несогласованные куски, лучше взять и выключить EIGRP, настроить

его правильно, прописать команды по редистрибуции, distribute-листам, offset-листам, политики всякие, а потом уже включить его, когда все настроено будет правильно. В этой ситуации получится, что вашу сетку не будет колбасить, пока вы там ее конфигурируете. Довольно полезная вещь, просто позволяет устаканить работу сети в тот момент, когда вы перевели железку в режим обслуживания и чего-то там с ней делаете. Естественно, это выключает маршрутизацию EIGRP, естественно, это отключает поток трафика через нее, но зато это происходит достаточно стабильно. Вы не просто говорите, мы выключаем все. Shutdown отправляет те самые peer termination сообщения соседям, у вас соседи выключают поток трафика через вас штатно, и до тех пор, пока у вас соседи трафик на вас посылают, вы этот трафик все еще форвардите. Но вы посылаете сообщение peer termination,

у вас соседи на вас трафик посылать перестают, и после этого вы можете делать с вашей сетью EIGRP все что угодно. Давайте я вам покажу еще одну штучку, и мы на этом пока лабу с IPv4 EIGRP в базовом варианте закончим. Хотел я показать вот что. Capture Ethernet 0/0. У нас EIGRP бегает, тут всякие Hello-сообщения, EIGRP. Видно хорошо, что Hello-пакеты бегают на мультикастовый адрес 224.0.0.10, но единственное, что у нас есть второй и четвертый роутеры, которые по идее должны посылать друг другу сообщения тоже Hello, но уже не мультикастом, а юникастом. Я рискну предположить, что эти два соседа будут использовать таймеры не 5-секундные, а 60-секундные.

Гипотеза у меня есть такая, надо подождать и проверить. EIGRP и IP Adder 10.15, .24, .2. Ну, пока таких сообщений просто не было. А четвертый? Четвертый тоже не было. Ну, ладно. Так, если я сейчас возьму и выключу EJRP на роутере, то есть все-таки EJRP не просто без фильтра, я иду в настройки роутера, enable, conft, роутер, EJRP 65000, shutdown. я выключаю именно процесс маршрутизации, я сейчас ожидаю увидеть как раз те самые пертерминейшны. Что-то я их не вижу.

Интернет, то есть сообщение есть, теперь терминейшн received. Подозрительно это. Так, и где же они? Hello, hello, hello. Так, 10.15 комплект, связь между первым и вторым, первый роутер. А, во, во, это просто показывается как обычное Hello сообщение. Смотрите, вот оно. В параметрах каждого сообщения мы передаем всякие разные свойства. То есть это у нас Hello пакеты идут. В обычном Hello сообщении мы передаем просто вот эти самые коэффициенты k-values, мы передаем параметр holdTime и, соответственно, больше ничего особо не передается. Ну, вот здесь

мы видим, что роутер пока работал, он посылал нормальные обычные Hello сообщения, в которых говорил, настроен я абсолютно штатно предсказуемо, bandwidth и delay учитываются в метрике, все остальное не учитывается. И holdTime 15, что через 15 секунд признаем соседа трупом. Дальше он рассказывал про то, какую версию у него используется. EJRP состоит из модулей и каждый модуль имеет свою версию. Ну, вот он рассказывал, что основная версия у него 23.0 EJRP релиз. И в следующем сообщении вот этом вот у нас пробегает сообщение вот это Peer Termination. Как видно, здесь ничего нового не добавляется. Вот эта штука ExpertInfo, это ее Вайр Шарк добавил. То есть никаких новых параметров здесь нету, за исключением того, что значение вместо 1,0,1,0,0,0 передается 255, 255, 255, 255. Кстати, хорошо видно, что CISC по факту, несмотря на то, что работает в классическом режиме, метрику передает расширенную. То есть,

K6 здесь появляется. И, соответственно, если мы сейчас посмотрим на апдейты какие-нибудь, есть апдейты? EGRP апдейты. Hello, hello, hello. Hello. Вот апдейты. Здесь будет видно, что используются широкие метрики. То есть, несмотря на то, что роутеры работают в классическом режиме, они, когда считают метрику, делают вид, что они посчитали метрику с помощью классического стиля, по факту передается метрика расширенная. Вот этот вот дилей, он передается в пикосекундах. Вот. Так что не верьте тому, что Cisco говорит, что в классическом режиме используются классические метрики. Нет. Используются широкие метрики везде и всегда. Просто Cisco прикидывается ветошью и прикидывается, что она работает с классическими метриками. Так. Ну чего. Я думаю, что на этом пока все. У нас осталось поработать с манипуляцией маршрутами.

Всякие разные там попридумывать суммарки. Посмотреть на то, как себя будет вести стаб. Кстати, не сделать ли нам какие-нибудь роутеры стабами? Давайте сделаем. Я сейчас возьму и роутер четвертый сделаю его стабом. То есть скажу, что на него не надо присылать query и, соответственно, он никогда не будет транзитным роутером. Сейчас роутер, например, R3, вот если посмотреть, enable show IP route. Вот. Он некоторые маршруты через EJRP пытается прогонять. Ну вот, например, вот 34.4. Он все маршруты пытается прогонять через четвертый, потому что первый роутер я сейчас выключил командой shutdown. Вот, прекрасный вариант. Сейчас из четырех роутеров, которые у меня есть на стенде, первый выключен, я ему сказал shutdown на EJRP, а на четвертом я сейчас собираюсь сделать стаб. И это приведет к тому,

что третий роутер окажется отрезанным от внешнего мира. Стаб роутер никому не пересылает чужие апдейты. Если приходит чужой апдейт, он его дальше не пересылает. И вот к чему это сейчас приведет. Роутер EJRP 65 тысяч. Так. Роутер EJRP 65 тысяч. Роутер 65 тысяч. EJRP с таба. Связь отваливается, подключение происходит. Подключаются, соответственно, второй, третий роутеры в качестве соседей. То есть соседи переустанавливаются, если вы объявляете роутер с табом. Но вот на роутере R3 сейчас у нас, несмотря на то, что соседство есть, SHOW EP Road видит только очень ограниченное количество маршрутов. То есть раньше он видел дофига маршрутов,

сейчас он видит только один несчастный вот этот вот 10-15-24-0. Что такое 10-15-24-0? Это маршрут между вторым и четвертым роутером. Этот маршрут был коннектед на роутере R4. Этот маршрут роутер R4 прислал, потому что он коннектед для него самого. это не транзитный маршрут. Все транзитные маршруты, которые третий получил через второй или через первый, соответственно, они не были переданы дальше. Стаб роутеры не пересылают транзитные маршруты, они пересылают только то, что к ним подключено напрямую. И вот, да, коннектед маршрут третий роутер, четвертый роутер прислал на трешку и все хорошо. Все остальное транзитное он тихо сожрал. При этом у самого четвертого, естественно, все эти маршруты есть. Show IP роутер. Вот они есть. Только он их не пересылает, потому что он считает себя стабом. Он считает себя нетранзитным роутером.

Если мы сейчас закажем отображение на третьем Show IP EJRP Neighbors, то мы здесь увидим, что сосед у нас есть и 10.15.34.4. Так, не понял. Neighbors Detail. Вот. Здесь мы увидим, что роутер R3 знает, с кем он дружит. Сосед у нас показан как стаб. В то же время, да, если мы посмотрим на нормальный какой-нибудь роутер, No Shutdown. На роутере R1 сделал и на R3 снова смотрю, что у нас получается. Show IP EJRP Neighbors Detail. Вот здесь нормальные роутеры такого флага не имеют. То есть, когда у нас стаб приходит и говорит, я стаб, роутер наш понимает, что ему надо не посылать к вайре и от него не надо ждать какие-то маршруты, которые он нам не захочет присылать.

Он присылает connected маршруты и он присылает маршруты, которые он нам сам просумировал. То есть, опять же, те маршруты, которые он сам придумал. Больше никакие не приходят. Давайте поговорим про IPv6. EJRP для IPv6 будет использовать тот же самый модуль, который использует и EJRP для IPv4. Потому что на самом деле выбор маршрута, установление соседства, проверка соседа на живость, алгоритм дуала и все остальное, они никак не зависят от того, какие маршруты у вас будут. Поэтому, соответственно, EJRP, да, он прекрасно работает как с IPv4 маршрутами, так с IPv6. Также он на самом деле прекрасно работает с протоколом IPX и в свое время он умел с ним работать. Потом этот модуль выпилили. Ну да, в любом случае, что для IPv4 маршрутов, что для IPv6, процедура выбора маршрута никак не отличается.

В любом случае, EJRP будет оперировать bandwidth, delay, reliability, load, hopcount и все остальное. Вот. Hopcount, что для IPv4, что для IPv6, сами понимаете, одинаковый. Bandwidth одинаковый, delay одинаковый. Ну и Cisco умышленно сделала синтаксис настройки EJRP для IPv6, очень похожим для IPv4, очень похожим на IPv4, как раз для того, чтобы не надо было учить какие-то отдельные команды, ну и в целом, да, чтобы было понятно, что один раз научились работать с IPv6, дальше уже все то же самое. При работе с IPv6, EJRP, нужно будет запустить экземпляр роутера, нужно будет сказать, соответственно, IPv6, роутер, EJRP, дальше номер автономной системы. Если у вас нету ни одного живого IPv4, IPшника, роутерайди у вас автоматически назначиться не сможет, надо будет его назначить ручками. И делается это команда EJRP роутерайди 0001.

На самом деле, просто роутерайди тоже прокатят. То есть, вот если вы забудете написать EJRP, просто напишите роутерайди, в справке такой команды нету, но она сработает и добавит вам целиком EJRP роутерайди все как полагается. Связано это с тем, что во всех остальных процессах динамической маршрутизации OSPF, EJRP, OSPF, BGP, где роутерайди требуется, он назначается просто роутерайди без дополнительных букв. Ну и поэтому некоторые люди просто запоминают одну команду, которая работает везде. Команды нету, больше нету, есть команда IPv6 EJRP на интерфейсе, ну, соответственно, EJRP и указываете номер. То есть, вот в нашем случае EJRP range мы указываем, что на этом интерфейсе, на этом интерфейсе и вот на двух других интерфейсах мы включаем EJRP с номером автономной системы 650001. Hello-пакеты EJRP для IPv6

и сами апдейты, ну и все остальные пакеты, которые EJRP будет использовать, для IPv6 будут использовать другой транспорт, поэтому они бегают абсолютно независимо от IPv4 пакетов и поэтому вы можете использовать отдельный номер автономной системы, который совпадает или не совпадает с тем, который вы использовали для IPv4. То есть, и таблицы топологии, и соседство, и пакеты, они все будут отдельные при работе с IPv6 EJRP. Когда у нас запускается IPv6 EJRP, он регистрируется в качестве протокола динамической маршрутизации, протокола, вбрасывающего маршруты в таблицу маршрутизации, show IPv6, только протокол, естественно. И, соответственно, вот здесь нам показывают, что EJRP действительно тут есть, запущен с номером автономки 650001, показываются компоненты, коэффициенты метрики, которые используются для вычисления формулы.

K6 тут не показывается, но он тоже равен нулю, потому что мы работаем в классическом режиме, и хотя CISCO и работает с wide-метриками, она прикидывается, что не знает ничего про них. И с wide-метриками используются только первые пять коэффициентов. K6 при этом равен нулю просто по определению. RouterID задали ручками. Это не IP-шник, это именно ID-шник, просто 32-битное число, которое записано в форме IP-адреса. Единица — это тоже число, и оно может быть записано в виде 32 бит и разбито на группы по 8 бит. Получается 0.0.0.1. Это не IP-шник. Он не обязан быть IP-шником. В некоторых ситуациях может быть удобно, если у вас RouterID числово совпадает с IP-шником, например, который на loopback-е висит, и этот же интерфейс анонсируется в EIGRP, или в OSPF, если у вас про OSPF или про BGP. Так что RouterID

числово совпадает с IP-шником, и этот IP-шник ещё и маршрутизируемый. Можно так сделать, если хотите, пожалуйста, сделайте. Но RouterID IP-шником быть не обязан. Тем более, он не обязан быть IP-шником, который принадлежит вам. Дальше. Я уже говорил, что изначально EIGRP предполагалось, что он может работать в multi-topology-режиме, MTR, Multi-Topology Routing. По факту, CISCO поддерживает только топологию с номером 0. Эта топология просто одна для любого типа трафика. И в этой топологии у EIGRP будут использоваться таймеры: Active Timer 3 минуты, внутренние маршруты 90, внешние 170. Это всё для вас уже более-менее знакомо. Variance по умолчанию единичка, так же, как в IPv4. HopCount по умолчанию, его нельзя поменять, это 100. И небольшое различие с IPv4 в EIGRP. Maximum paths изначально из коробки будет 16. EIGRP для IPv6 вбрасывает до 16 маршрутов

одинаковой стоимости. CEF, в свою очередь, позволяет балансировать трафик в IPv6 по 64 линкам. И поэтому балансировка там может быть достаточно гранулярной. Если вы 16 вбрасываете, то можно 16 разных линков ещё и не одинаковой производительности сделать. В то же время можно будет и увеличить это. Максимум, который есть, это 64 линка. Команды network больше нету. В IPv4 EIGRP показывает Routing for Networks. Здесь уже в явном виде говорится, на каких интерфейсах вы зашли и какие интерфейсы включили в EIGRP. В IPv4 EIGRP у вас пассивный интерфейс в явном виде перечислен. Указано, какие команды passive interface вы ввели. Здесь в настройке интерфейсов будет показано passive, если у вас есть интерфейс, который вы пометили как пассивный. show IP

EIGRP interfaces — show IPv6 EIGRP interfaces не показывает пассивные интерфейсы. Если интерфейс помечен как пассивный, то он будет отсутствовать в этом списке. В остальных случаях — выключен интерфейс или на интерфейсе не включили EIGRP — здесь всё достаточно очевидно. Каждый интерфейс, на котором вы включили EIGRP, будет показываться, сколько соседей на нём нашлось, среди всех соседей какое среднее время прохождения пакетов туда-обратно, среднее арифметическое будет считаться, и задолженности по пакетам. Здесь будут показываться, сколько пакетов стоит в очереди на отправку на этом интерфейсе и pending routes, сколько маршрутов из них. После того, как на интерфейсе включился EIGRP и сосед на вас тоже включил EIGRP, у вас обнаруживается соседство. Соседей можно посмотреть командой show IPv6 EIGRP Neighbors. Если соседа нет в списке, то либо сосед не включил на вас EIGRP,

либо вы на соседа не включили EIGRP, либо у вас не совпадают коэффициенты метрики, либо у вас не совпадают номера автономных систем, либо у вас трафик 88-го протокола не проходит. Других причин подружиться или не подружиться может и не быть. Здесь можно ещё, конечно, добавить, что у вас primary IP-шники из разных сетей. Если hello приходит от адреса, который не является принадлежащим основной сети, которая у вас connected в таблице маршрутизации за primary IP-шник на интерфейсе, то у вас соседство тоже не получится установить. Если два роутера, на одном вы указываете IP-шник 10.0.0.1 /24, на другом вы указываете 10.1.1.2 /24. Они не подружатся между собой. Даже несмотря на то, что hello-пакеты они посылать будут, даже если у вас secondary IP-шники

будут — вы на этом интерфейсе скажете, у нас primary 10.1.1.1 /24, это будет secondary. Они всё равно не подружатся, даже несмотря на то, что, казалось бы, друг друга пинговать они могут по этим IP-шникам, но они не праймеры, поэтому дружбы не будут. Еще одна проблема, которая может быть, это МТУ. В EGRP про это мало кто пишет, но да, МТУ должен совпадать для того, чтобы у вас соседство по факту установилось. Роутеры будут проверять это МТУ, если вдруг МТУ не совпадает, соседство не выйдет. Так, когда соседство установлено, начинаем проверять таблицу топологии, show IP, EGRP, топология показывает все-все-все маршруты, по умолчанию показываются только маршруты, которые проходят feasibility condition, можно ключ call links попросить показать вообще все. По каждому маршруту мы видим его состояние, либо passive, либо active,

видно саму сетку, видно feasible distance ее, видно next hop, то есть тот, кто прислал нам этот маршрут, и здесь всегда используется link local адреса, то есть вам для работы на интерфейсе достаточно иметь link local адрес. Это reported distance, это computed distance через соседа, ну, все довольно очевидно и предсказуемо, все то же самое, что было в IPv4, EGRP. И в таблицу маршрутизации маршруты вбрасываются, вот здесь показано, да, что у нас маршруты EGRP-шные будут иметь букву D, так же, как в IPv4, здесь показывается сетка, административное расстояние по умолчанию 90, метрика для classic mode EGRP-шной, будет равна метрики EGRP-шной и вот это, вот это у нас next hop. Опять же, можно заказать детальный вывод, здесь Cisco покажет кое-что про то, что она знает, что это маршрут EGRP-шной, пришел из EGRP 65 тысяч, первые штуки, показывает административное расстояние,

метрику и тип маршрута, но здесь уже, в отличие от EGRP, не показываются детали, bandwidth, delay, хотя на самом деле таблица маршрутизации про эти детали, конечно же, знает. Ну и здесь, если у вас будет несколько путей, как можно добраться до удаленной сети, здесь вот один будет, здесь другой, будет показано, в каком, в каких пропорциях идет между ними балансировка. Если у вас всего один маршрут, то, соответственно, балансировки там никакой нету, он балансируется просто сам, сам с собой. Если вдруг вы захотите что-то понастраивать, опять же, кастомное, что можно понастраивать? Variants, можно понастраивать пассив интерфейсы. Опять же, обычно указывается, что пассив интерфейс у вас будет дефолт, и дальше вы просто в явном виде указываете, какие интерфейсы пассивными быть не должны. Это более контролируемый способ, когда вы просто хотите безо всяких ощущений повключать EJRP, и он анонсировал бы правильные сетки. С EJRP это на самом деле

очень полезная вещь использовать как раз пассив интерфейс дефолт. Он достаточно неплохо в таком базовом режиме, когда вы просто говорите, давайте, повключаем везде, и дальше не дружим, где попало, дружим только там, где надо с соседями. Вот в этом режиме, да, EJRP может вам, ну, с минимальным количеством телодвижений сразу обеспечить работоспособность. если у вас какая-то более экзотическая сеть, и вы не хотите, чтобы все-все-все маршруты попадали в EJRP, вы можете рассмотреть вариант, при котором Network, ну, или EJRP классический, вы включаете только между роутерами, вот на интерфейсах транзитных. В случае с IPv6 на них даже IPшники вешать не надо, просто заходите, говорите, на этом интерфейсе работает EJRP для IPv6. А те интерфейсы, которые у вас пользовательские, вы на них EJRP не включаете. Это connected сетки, и вы с помощью какой-то политики перекладываете маршруты в EJRP. И эта будет штука называться редистрибуцией.

Про это мы сейчас в отдельном модуле будем говорить. Если вы хотите поиграть коэффициентами метрики, так же, как и в случае с EJRP для IPv4, есть команда metric, топология и коэффициенты метрики. И если, опять же, статического соседа прописываем, убеждаемся, что IPшник соседа у нас доступен, что это у нас link-local адрес будет, и link-local адрес известно, как на него добраться. Во фрейм рилей у нас должен быть статический маппинг, а в dmvpn у нас должен работать EJRP для IPv6. И показываем, через какой интерфейс мы на нем будем работать. Если вы прописываете статических соседей, то я уже показывал в IPv4, в IPv6 то же самое. На порту выключается обработчик мультикаста, мы перестаем отправлять hello-пакеты мультикастом, мы отправляем их только юникастом, и мы принимаем пакеты только юникастовые. То есть, даже те пакеты, которые в норме шли мультикастом, например,

апдейты, они начинают уже ходить юникастом. Если вы хотите, можно будет прописать настройки некоторые на интерфейсе, так же, как в случае с IPv4, и это таймеры, и это настройки аутентификации. С таймерами точно все то же самое, абсолютно. IP, hello-interval, IPv6, hello-interval. Дальше указываете, с какой автономной системой работы EGRP 650001, и число, это hello-interval, и hold-таймер. Можно, опять же, технически поставить hello-interval больше, чем hold-тайм, и у вас будут рваться соседи. То есть, вы отправляете hello-пакеты реже, чем ожидаете их получать, заставляете ожидать их получать. Вот пример. Давайте сейчас попробуем. enable show IP EGRP neighbors. Это IPv4 EGRP, ну, в IPv6 то же самое. И здесь у нас есть сосед, и этот сосед,

ну, например, 10, 15, 13, 1, сидит за интерфейсом Ethernet 0013. Conf-t interface 0.13 IP hello-interval, интервал, у нас будет больше, чем 15. Вот, например, EGRP 65000 20. То есть, я отправляю hello-пакеты раза 20 секунд, но при этом говорю, что сосед должен принимать мои hello-пакеты и ожидать, что они должны приходить раз в 15 секунд. И сейчас, вот прямо сейчас, в моменте, настройки у меня на самом деле изменились, и изменились одновременно, нет, не изменились, да, hello-interval у меня поставлен 20 секунд, а hold-таймер остался 15. И видно, что сосед признал меня трупом, потому что я давно ему ничего не присылал, и при этом через некоторое время я ему послал новый hello-пакет, и мы переустановили соседство.

И вот так вот оно будет флапать. То есть, я отправляю сообщение раза в 20 секунд, и в каждом сообщении говорю, через 15 секунд считай меня коммунистом. И видно хорошо, да, что здесь разница как раз между вот этими новыми соседствами разница как раз в 20 секунд. То есть, hello-сообщения идут раз в 20 секунд. Ну и, да, через 15 секунд после соседства сосед присылает нам пертерминейшн. Отведение это дело. Ctrl-A, no, IP, hello-интервал. То есть, не надо так делать, не надо выставлять hello-интервал больше, чем hold-таймер. Это вы ответственны за то, чтобы ваш hold-таймер был меньше, чем ваш hello-интервал. В противном случае в сообщениях, которые вы отправляете, вы говорите, что да, если через 20 секунд не вернусь, считайте меня коммунистом, и сами, через 15 секунд не вернусь, считайте меня коммунистом, сами возвращаетесь через 20. Так делать не надо, это плохая идея. С аутентификацией та же самая история, что и в IPv4. В настройке интерфейса пишем authentication,

mode, EJRP, номер автономки, и указывайте, что вы хотите подписывать ваше сообщение хешем MD5. И для того, чтобы показать, каким хешем от чего он должен считаться, вы указываете ключевую цепочку. Опять же, указывайте keychain, EJRP, keychain, EJRP 650001, и дальше название ключевой цепочки. В норме в ключевой цепочке у вас должен быть только один ключ, который актуальный, живой, нормальный, хороший, рабочий. Если вы хотите перейти на другой ключ, то, соответственно, вот с помощью перехлёста Accept Lifetime и Lifetime вы можете перейти на другой ключ без потери связности. При этом вы будете отправлять всегда один ключ, но принимать в некоторое время, вот это вот, переходное время, вы будете два ключа. То, что у соседа может быть настроен, соответственно, ключ, который вы ещё не используете или уже не используете, вот вы в течение некоторого времени будете принимать и тот ключ, который вы отправляете,

и тот ключ, который другой. Так, дебажить EJRP можно одинаково для IPv4, для IPv6, есть контекст дебаг EJRP, и, соответственно, там полезное это вот дебаг пакетов. Есть команда debug EJRP packets hello, которая дебажит все hello пакеты, что IPv4, что IPv6, она показывает, какие пакеты вы на каком интерфейсе отправляете и принимаете. И есть debug EJRP packets, вы можете указать, какой тип пакета вас интересует, чаще всего там интересуют нас либо hello пакеты, либо все, которые не hello. вот, и вы можете в явном виде сказать, что нас интересуют пакеты там update, query, reply, sea, query, sea, reply, но можно просто сказать, вот это вот debug EJRP packet terse, и это покажет только те пакеты, которые осмысленные, которые мясные, потому что в hello там идут обычные регулярные сообщения

я тебя вижу, и там особого мяса, конечно же, нету. Если вы дебажите hello, значит, что у вас проблема со связностью. Если у вас проблемы со связностью нету, но вы знаете, что есть проблема с каким-то мясом, что непонятно, кто кому какие маршруты присылает, то это вот как раз debug EJRP packets terse. В каждом пакете мы будем, соответственно, видеть, что там приходит, апдейты, acknowledge, acknowledge это формально hello пакет, но он такой, видно хорошо, что он необычный hello, несмотря на то, что код операции у него пятерка, он приходит unicast, и у него, соответственно, acknowledge number стоит не нулевой, поэтому debug EJRP packet terse показывает некоторые пакеты с кодом операции 5, но те, которые относятся к полезному, к мясу. Если мы отправляем апдейт, то мы ожидаем увидеть вот эти вот acknowledge, они будут для нас мясными пакетами, даже несмотря на то, что в них ничего ценного не передается. Вот. Здесь, правда, не видно, что именно будет передаваться. Если вдруг вам интересно,

то можно будет заставить циск, именно показывать сами апдейты, которые вы отправляете, но это уже прям совсем жесткий дебаг, чтобы посмотреть в самих апдейтах, какие маршруты уходят. Вот. Давайте попробуем это дело повключать и посмотреть, что IPv6 EJRP действительно будет включаться, работать. Ну, в принципе, мы это в CCN и делали, ну, на всякий случай тоже сделаем. Для нас потребуется... Ну, давайте, прямо вот внутри наших R1 и R2 у нас там есть уже... Так, у нас там есть уже IPv6 живой рабочий, только надо RIP выключить. Enable, ConfT, No, IPv6, router, RIP, CCNP. И на R2 то же самое. Выключаем router RIP.

Выключаем RIP и включаем EJRP для IPv6. Если у вас там нет живого IPv6, ничего страшного. IPv6 Unicast Routing и вы приходите к тому же, что и у всех остальных. На интерфейсе IPv6 Enable еще. Какие адреса можно брать? Пока что никакие адреса не нужны. IPv6 Enable на интерфейсе вас вполне удовлетворит. В IPv4 на транзитных интерфейсах мы вынуждены были ставить IPшники. И на этих интерфейсах, соответственно, IPшники попадали в анонс неизбежно. В IPv6 нам не нужны маршрутизируемые IPшники на транзитных интерфейсах. IPv6 дружит поверх link-local и, в принципе, этих link-local более чем достаточно для любых интерфейсах. Поэтому мы сейчас настроим связанность по IPv6 с, соответственно, link-local и сначала у нас будут работать все поверх link-local, а потом только мы добавим маршрутизируемые IPшники через лоббеки. IPv6 роутер.

Я вот не делал... Давайте сделаю прям полноценно. Если вдруг у вас это уже есть, ничего страшного. IPv6 Unicast роутинг интерфейс... Так, нет, рано. Роутер EGRP IPv6 дальше номер автономной системы. Я предлагаю использовать такой же 65 тысяч. А, IPv6 роутер EGRP, конечно, простите. Дальше. Сам процесс EGRP-шного роутера мы запустили. Роутер ID он себе какой-нибудь возьмет, потому что я точно знаю, что у меня IPv4 IP-шники на этой железке есть. Интерфейс range. Я не уверен, что он сейчас сможет это сделать, но попробовать можно. Ethernet 00.101 интерфейс в сторону... А, 102. В сторону центрального Core 2. Ethernet 00.12 это интерфейс, который смотрит в сторону моего роутера

R1. Ну да, он так не сожрет. Придется отдельно делать. IPv6 enable. IPv6 EGRP 65 тысяч. И отдельно на 12-ом субинтерфейсе IPv6 enable. IPv6 EGRP 65 тысяч. Вот это я сделал на втором роутере. Аналогичные действия сейчас сделаем на первом. IPv6 роутер EGRP 65 тысяч. IPv6 роутинг. Unicast роутинг. Так, интерфейс Ethernet 00.101 IPv6 enable. IPv6 EGRP 65 тысяч.

И на 12-й комплект. Вот сейчас на роутерах у нас на первом и втором включен EGRP. Соседство автоматически находится. Поверх этого самого соседства у нас уже можно было бы передавать IPv6 маршруты, если бы они были, потому что у нас сейчас нету ни одного маршрута, который можно было бы рассказать соседям. У нас нет IPv6 маршрутизируемых адресов. У нас есть loopback, если память не изменяет с IP-шниками, но эти loopback, соответственно, да, они пока не включены в EGRP. Ну и если я захочу на центральном роутере сделать аналогичное действие, то мне придется прям по-честному через все интерфейсы продираться и говорить, что на таком субинтерфейсе включая EGRP, на сиком интерфейсе включая EGRP, то есть это будет довольно долго и грустно, но делать нечего. Так, роутер R1.

Так, вот он. Интерфейс E0 0.101 IPv6 EGRP 65000 Так, IPv6 Unicast Routing IPv6 EGRP 65000 IPv6 Enable 1 2 2 3 4 4 1 0 3 1 0 0 Так, что такое, что не так?

1.0, pv6.egrp, pv6.enable. 1.2, pv6.enable. Вовлекательное дело, конечно, это 2.0, 2.1. Давайте я не буду на Core 2 включать, а то это будет очень долго. Так, 2.2, 3.0, 3.1, 3.2, 3.3.

Так, не надо было включать, ну ладно. Вот. На роутере R1 я включал кучу интерфейсов в egrp 65000 автономку, но соседство у меня пока не завелось. Я подозреваю, что это связано с тем, что IPv6 роутер egrp 65000 надо прописать. Да, то есть сам контекст роутера не был запущен. На интерфейсе было написано, что этот интерфейс должен участвовать в egrp в автономке 65000, но такого источника маршрутной информации в таблицу маршрутизации не было зарегистрировано. Вот когда я указал IPv6 роутер egrp 65000, процесс запустился и установил кучу соседских отношений. Вот видно, что на Ethernet 0.1 это второй комплект. Нет, это, да, второй. 0.3, 4.0, 2.3 комплект. То есть второй, третий, четвертый, пятый. Ну остальные так в риме не признаю.

Вот. Понятное дело, что у них, да, вот какие-то link local адреса, которые непонятны. И, то есть, да, адреса случайные, динамические. С одной стороны, как бы немножко жалко, что непонятно по внешнему виду IPшника, кому он принадлежит. С другой стороны, это основное свойство link local адресов, что неважно какие они, они случайные, динамические, у каждого разные. После того, как соседство установилось, давайте, не буду делать то же самое на Core 2, потому что я задолбаюсь просто. Вот. У нас есть соседство, у нас есть на роутере первом два соседа. Можем взять и анонсировать чего-нибудь в EJRP и обменяться боевыми маршрутами. Сейчас таблицам маршрутизации у нас IPv6 ничего нету. Show IPv6, Rode. Вот здесь пусто. FF0022.8. Это мультикаст. И, соответственно, он принимается центральным процессором, как будто бы адресован персонально вот этому роутеру.

На роутере 2 у нас, по идее, должен быть loopback. Show IPv6, Rode. Нет у loopback. Ну, прекрасно. Сейчас сделаем. Давайте сделаем на роутере R2 loopback. Conf.t. Interface loopback. 0. И пропишен на нем красивый IPшник. IPv6. IPv6. Адрес. FD номер комплекта. Двоеточие. Двоеточие. Номер роутера. В нашем случае роутер номер 2. И по 128-й маске мы его сделаем. И скажем, что этот адрес следует анонсировать в EJRP. IPv6. EJRP. 65 тысяч. Вот теперь на всех роутерах, которые у нас в автономной системе EJRP-шник, должен этот адрес появиться. Вы тоже, пожалуйста, анонсируйте. FD номер комплекта. Два двоеточия номер роутера. В нашем случае второй роутер, поэтому FD15 2.2.

IPv6. Роут. Вот они прибегают. Четвертый комплект. Первый роутер. Здесь я вижу, что был какой-то случайный IP-шник, который мы на RIP-е делали, когда дистрибуцию в RIP-е проверяли. Вот второй комплект. Это, судя по всему, тоже второй. Я так догадываюсь. Ну, вот мой. А, 11-й, 12-й, да. Присылайте свои лупбеки. Проверяйте, что наши лупбеки приходят к вам. И дальше после этого посмотрим, что можно будет сделать. Так, давайте попробуем обновить. Что IPv6 роутер. Ну, вот здесь видно, что пачка маршрутов есть. FD03, 04, 05, 11, 12, ну и 15-й мой. Из того, что мы не сделали, это аутентификация узлов. Что в IPv4, что в IPv6, она выглядит одинаково в Classic Mode. Нам нужно создать ключевую цепочку и убедиться, что эта цепочка действительно используется.

Если мы сейчас возьмем и скажем, что у нас есть, например, так, это Кура 1, что у нас есть, например, роутер, вот 3-й и 4-й. Они друг друга видят, друг другу отправляют hello-сообщение. Ну, мы хотим, чтобы канал между ними, если вдруг будет перехвачен злоумышленником, чтобы злоумышленник не смог вбросить левую маршрутную информацию. Я вам показывал, что в Вайршарке в апдейтах передается, и там все пакеты, которые передаются, они передаются в открытом виде. Если вдруг злоумышленник получает доступ к проводу, он получает возможность вбросить в этот провод любой скрафченный пакет, и в этом пакете он может сказать, что, например, Вася, Петя пересылают информацию о том, как устроен мир. И вот он в какой-нибудь апдейт, который будет передаваться, вполне может добавить какой-нибудь лишний маршрут. И поскольку EGRP работает только на основе DELT, то отправитель никогда не узнает, что в его апдейт было что-то дополнительное добавлено. Больше, в общем-то, особенно волноваться по поводу каких-то других вещей особо не стоит.

Ну, то есть, либо маршрут будет добавлен лишний, либо маршрут какой-то нужный будет из апдейта аккуратненько убран. Но в любом случае, соответственно, да, отправитель, отправив пакет и убедившись, что на него пришел акно, дальше успокоится и будет нормально, корректно работать. Но если вдруг с помощью такого скрафченного апдейта получится испортить таблицу маршрутизации на роутерах, то это может привести к очень неприятным последствиям. Поэтому вы должны будете убедиться, что пакеты, которые отправлялись роутерами, они были каким-то образом защищены. И самый простой способ защитить их – это защитить их паролем. Но пароль вкладывать не в открытом виде, естественно, чтобы любой желающий мог украсть, как это сделано, например, в RIP. Там можно взять и в открытом тексте, plaintextом пароль положить. А использовать хэши от пароля плюс содержимого пакета. Мы сделали пакет, посчитали хэш от него и пароля, сложили хэш в сам пакет. Передали пакет по сети. Если злоумышленник пароль не знает, он не сможет взять и подобрать на лету такой хэш,

чтобы подменить пакет, сделать вид, что пакет прошел с 14 номером, а вот злоумышленник взял и хитренько туда, быстренько вместо оригинального пакета подложил кривой, но еще и хэш там на лету тоже посчитал. Вот не зная пароль, так сделать не получится. Хэш МД 5. Если мы работаем в Classic Mode, то используется только хэш и МД 5. Нет, в курсе у нас оба. Просто для второго нужно использовать Named Mode. Так, давайте это сделаем. Нам потребуется ключевая цепочка и, соответственно, key... Продон, конф-т... Конф-т... Keychain... Ну, давайте я назову ее KC. Keychain... Не важно, какой пароль. Главное, с двух сторон одинаковый вы задайте. То есть сейчас наша задача сделать так, что между третьим и четвертым роутерами проверялся пароль, и он на обоих роутерах был одинаковый. Я предлагаю использовать маленькими буквами слово CISCO,

но это не обязательно. Если вам хочется другой пароль, пожалуйста, используйте другой. Ключевая цепочка, которая называется KC. Keychain... Соответственно, не Keychain, а Key1. Ключ номер 1. И здесь у нас KeyString. CISCO. Сделали ключевую цепочку KC. На ней ключ номер 1. У него ключевая строка CISCO. KC нет, это Keychain. Так. С этой ключевой цепочкой можно настраивать аутентификацию. Мы идем в интерфейс Ethernet 0.0.34. Связь между третьим и четвертым. Дальше IP Authentication. EJRP 65000. А, pardon. Authentication.

Где EJRP 65000. И здесь вот у нас варианты, как можно аутентификацию использовать. И здесь аж целый один вариант. Использовать аутентификацию по хэшам MD5. Мы сказали, что надо использовать аутентификацию. Нажали Enter. И связь у нас отвалилась. Потому что даже несмотря на то, что мы не указали, какую ключевую цепочку использовать, мы требуем, чтобы приходящие пакеты были с правильными хэшами. И, соответственно, у нас они пока с неправильными. Поэтому, да, связь немедленно разваливается. Ну и приклеиваем ключевую цепочку. IP Authentication. Keychain. EJRP 65000. И ключевая цепочка у нас называется KC. Keychain. Сейчас пакеты, которые отправляются, отправляются с указанием хэша от пароля Cisco.

Давайте попробую показать вам. Так, сейчас. Где оно есть-то? Это у нас четвертый роутер. Capture. Так вот, пошли пакеты. И можно будет увидеть, что пакеты у нас идут. Вот они идут. Их много. Всяких. Hello. И у них у всех вложения EJRP. Параметры. Так, это не тот роутер. Вот, 34. 34.4. Связь между третьим и четвертым. И вот у нас TLV дополнительная вложена с типом аутентификация. И мы говорим, аутентификация у нас будет с использованием MD5 хэша. Ключ номер один. Дайджест.

И вот дальше хэш от пакета плюс пароля. То есть в явном виде указывается номер ключа. И в явном виде указывается хэш от содержимого пакета и ключа. Теперь для того, чтобы все хорошо работало, нам нужно на роутере третьем сделать ответные действия. Enable. Conf.t. Дайте я немножко схалявлю. Do. Show. Run. Include. Section. Просто Section. Так. И на интерфейсе. Интерфейс E0. 0.34. Указываю, что у нас есть ключевая цепочка. И IP Authentication указываем в моде MD5.

Связь устанавливается. И во всех пакетах у нас будет передаваться ключ. Да, поднялось. Работает. Если мы хотим сменить ключ, в какой-то момент мы говорим: у нас есть время X, и мы должны будем сменить ключ. Мы добавляем новый ключ. Указываем, что приниматься он будет начиная с немножко времени до часа X. И ключу старому говорим, что он будет приниматься немножко позже часа X. Но отправляться будет строго до. И на обоих роутерах мы говорим, что у нас... Давайте покажу, как будет выглядеть процедура смены ключа. Заходим в ключевую цепочку. И здесь мы можем сделать Accept Lifetime. Accept Lifetime. Дальше указываем время, когда мы можем начать принимать этот ключ. Этот ключ принимается прямо сейчас, поэтому мы указываем, что там... Не важно, какое время. 0, 0, 0, 0, 0.

Дата 1 января 1970 года. 2000 года. Короче, заведомо дата в прошлом. И указываем, что этот ключ будет действовать до какого-то времени в будущем. Например, мы можем сказать, что у нас запланирован переход на новый ключ с 1 ноября. Мы указываем 0. А, это Accept Lifetime. 23 часа 55 минут 0, 0 секунд. В октябре у нас 31 день, 2018 года. Таким образом мы сказали, что у нас Accept Lifetime с какой-то даты в прошлом за 5 минут до часа X. А Send Lifetime мы указываем, что у нас с 0, 0, 0, 0, 0, 1 января 2000 года

по 0, 0, 0, 0, 0, 1 ноября 2018 года. Это мы указываем ровно до часа X. Ключ номер 2. Там делаем ответные действия. Говорим, что этот ключ будет посылаться Send Lifetime с 0, 0, 0, 0, 0, 1 ноября 2018. Этот ключ посылается с часа X. А принимается он немножко... Так, я неправильно сделал. Я здесь сделал, что принимается ключ за 5 минут до. На самом деле это неправильно. Приниматься он начинает немножко раньше часа X и Infinite. Номер 1 надо поправить.

Key 1. У него Accept Lifetime должен быть не такой. Должен быть 1 ноября. Так, я промахнулся. 1 ноября. 0, 0, 0, 0, 0, 5, 0, 0. Вот так. И Show Keychain. У нас показывается, что есть ключевая цепочка KC. Ключ номер 1 действует сейчас, но действовать он будет ещё до часа X плюс 5 минут. А прекращаем мы посылать его ровно в час X. Второй ключ начинает действовать незадолго до часа X. И начинаем посылать мы его ровно в час X. По сети, когда будут передаваться сообщения, в них будет указан в явном виде, какой ключ мы используем.

И поэтому будет явно понятно, какой ключ надо использовать для подсчёта хэша какого сообщения. Приходит какой-то пакет. Мы говорим: да, у нас два ключа, но в самом сообщении написано, что надо использовать ключ номер 1 или номер 2. И здесь мы сделали перехлёст в 5 минут, здесь 5 минут и здесь 5 минут. И это даёт нам некую толерантность к расхождению часов на двух железках. Если вы точно знаете, что у вас абсолютно точно часы синхронизированы, вы можете положиться на то, что send lifetime и accept lifetime у вас могут быть ровно в час X. Да, вопрос, где можно посмотреть, что аутентификация настроена. show IP EIGRP интерфейс ethernet 0.34. detail.

Интерфейс detail, наверное, да. Такая команда, немножко дурацкая. И здесь она. Указание, что authentication mode MD5, ключевая цепочка KC. Ещё одна штука, я уже говорил, что с помощью ключевых цепочек можно расшифровывать закодированные пароли. Conf t. У нас есть команда service password encryption. И если у нас есть какой-нибудь, например, юзер, username cisco, password cisco, do show run include user. Если у нас используется service password encryption, то все команды, которые содержат пароли, они кодируются. Эта семёрка означает, что используется метод кодирования обратимого cisco 7. У каждого пароля будет некая в кавычках соль.

И дальше здесь закодированный пароль, который просто глазками непонятно, что тут на самом деле закодировано слово cisco. Если мы работаем с ключевыми цепочками, мы можем сделать keychain какой-нибудь, не знаю, decode key1. И дальше keystring. Дальше копируем то, что у нас здесь есть. show keychain. Вуаля. Да, естественно, это сработает только с теми паролями, которые хранятся в исходном виде в конфигурации, либо закодированные методом cisco 7, потому что это обратимое шифрование. Если у вас закодировано как-то иначе, то есть в конфиге лежит пароль, предварённый либо пятёркой, либо четвёркой, то это необратимое шифрование. Это значит, что в конфиге хранится только хэш от пароля.

И, естественно, таким образом восстановить пароль не получится. Так, давайте перейдём к следующей теме, которая у нас есть. И если мне память не изменяет, это то ли named mode, то ли манипуляции. Сейчас на вскидку не вспомню, но обязательно сейчас посмотрим. Продолжение следует...