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

Давайте обсудим, как настраивается EIGRP в Cisco. Здесь я сразу должен сказать, что EIGRP в Cisco можно настраивать двумя разными способами. Это всё равно один и тот же протокол EIGRP, один и тот же модуль, один и тот же набор плагинов. Просто есть два независимых подхода к тому, как можно оформить конфигурацию EIGRP в running config. Один из них будет называться Classic Mode, а другой — Named Mode. Мы сейчас рассмотрим тот способ, который проходили на CCNA, — классический режим настройки EIGRP. Потом посмотрим на Named Mode отдельно. Для того чтобы включить EIGRP на Cisco, нужно запустить экземпляр router EIGRP. Как вы помните, это команда router EIGRP, дальше номер автономной системы. Или если у вас IPv6, это будет ipv6 router EIGRP. И вы приходите в контекст настройки роутера, в котором можно всякое разное сделать с экземпляром EIGRP.

Если мы говорим про IPv4 EIGRP, то вы должны будете включить EIGRP на интерфейсах. И делается это с помощью команды network. Эту команду мы видели уже в RIP. И я говорил, что команда network имела смысл в классовом мире. Когда у вас был роутер, на этом роутере был набор интерфейсов. На каждом интерфейсе висел IP-адрес, смотрящий в отдельную классовую сеть. И вы указывали в команде network классовую сетку. То, что вы указывали классовую сетку, однозначно показывало, что вам надо взять тот самый интерфейс, на котором IP-адрес входит в эту классовую сеть. Саму классовую сеть, ту, которую вы в команде network указали, которая была connected на этом интерфейсе, — включить в анонс. В классовом мире всё это хорошо работало. Проблемы начались, когда мир стал бесклассовым. Можно было в команде network указать классовую сетку, и она включала EIGRP уже на нескольких интерфейсах — на всех интерфейсах, IP-адреса которых попадали в классовую сеть.

В RIP до сих пор такое поведение есть. Но это откровенно неудобно, потому что нельзя, например, сказать: включи EIGRP на интерфейсе, на котором IP-адрес 10.0.0.1, но не включай EIGRP на интерфейсе, на котором IP-адрес 10.0.0.2. В EIGRP от такой проблемы было решено отойти. Отойти от неё решили путём опционального указания wildcard mask. Вы можете указать команду network с указанием IP-адреса без wildcard mask. Тогда это будет точно так же, как в RIP. Вы указываете классовую сеть, выбираете все IP-адреса на ваших интерфейсах, которые попадают в эту классовую сетку. На них вы начинаете включать EIGRP, и connected сетки с них включаете в анонс. Но делать так, естественно, не стоит, просто потому что, хотя это и возможно, это очень негибкое поведение.

Если вы уже включили всю классовую сетку в анонс — все интерфейсы, на которых IP-адреса попадают в классовую сетку, — то потом выцепить эти интерфейсы из EIGRP будет очень тяжело. Поэтому я рекомендую не использовать подход, где вы указываете просто IP-адрес с классовой маской. Я рекомендую указывать всегда рядом с IP-адресом сети маску. Эта маска будет в wildcard. Соответственно, она будет перевёрнута относительно нормальной прямой маски. И работает команда network сегодня именно так. Когда вы указываете network, IP-адрес и маску, система перебирает все интерфейсы, на которых у вас есть хотя бы какие-то IP-адреса, перебирает IP-адреса на этих интерфейсах, смотрит, какие из них попадают под это условие. Фактически это условие access list: у вас есть эталонный IP-адрес и wildcard маска. Если под это условие access list попадают какие-то интерфейсы, вы на них включаете EIGRP.

Connected сетки с них вы включаете в анонс. Очень частое заблуждение, что эта wildcard маска должна иметь какое-то отношение к тем маскам, которые висят на интерфейсах, и к тому, что попадёт в итоге в анонс. Ничего подобного. Wildcard маска не означает ничего, кроме того, чтобы перебрать правильные IP-адреса. Если вы хотите, вы можете указать wildcard маску 0.0.0.0 и указать в явном виде целиком тот IP-адрес, который должен висеть на интерфейсе — на том самом единственном интерфейсе, где этот IP-адрес висит, вы хотите включить EIGRP. Здесь у нас есть команда network 192.168.0.0 по маске 0.0.255.255. И есть три интерфейса FastEthernet 0/0, FastEthernet 0/1, 0/2, на которых IP-адреса 192.168.1.1, 2.1, 3.1. Все по 24-й маске. Все три IP-адреса попадают в 192.168.0.0 по маске 0.0.255.255. Под это условие access list и FastEthernet 0/0, и FastEthernet 0/1, и FastEthernet 0/2 попадают.

Поэтому на них на всех трёх включается EIGRP. На этих интерфейсах вы начинаете отправку Hello-пакетов, и connected сетки с этих интерфейсов вы включаете в таблицу топологии, включаете в анонс. Если вы отправляете Hello-пакеты, то вы отправляете их только с primary address. Если у вас два роутера, которые друг на друга смотрят, они будут Hello-пакеты отправлять друг другу — они должны отправлять Hello-пакеты из одной и той же сети. Отправляются Hello-пакеты с адресом источника primary address. Если вдруг у вас какая-то странная ситуация, где на интерфейсе роутера у вас два IP-адреса висит, и primary IP-адрес здесь, допустим, 10.0.0.1, и secondary IP-адрес к нему 10.0.1.1, а здесь наоборот — 10.0.1.2, и secondary к нему 10.0.0.2. Соседство не получится установить, потому что эти IP-адреса будут находиться в разных сетях, и они по факту не подружатся между собой.

Даже если, казалось бы, они друг друга пинговать могут — попинговать со стороны роутера 10.0.1.2 можно, потому что здесь secondary address такой есть, — но соседство не получится установить. Проверяется, что Hello-пакеты, которые приходят, приходят из-под правильных IP-адресов. Дальше. Вы указываете команду network, задаёте условия access list, на интерфейсах включается EIGRP, начинают отправляться Hello-пакеты, начинают анонсироваться сетки. Вы должны будете анонсировать сетки, в которых у вас сидят пользователи. Смысл EIGRP в том, что он на всех роутерах в таблицу маршрутизации занесёт те сети, в которых у вас сидят пользователи, в которых у вас находятся всякие серверы — где находятся фактически потребители трафика. Нет никакого особенного интереса в том, что роутеры EIGRP будут обмениваться между собой транзитными сетями. Транзитные сетки вообще не нужны в EIGRP, по большому счёту. Роутеры вынуждены ими обмениваться, потому что вынуждены обмениваться всем.

Но по факту вся ценность EIGRP заключается в обмене именно теми маршрутами, где у вас по факту сидят пользователи. И поэтому командой network вы должны будете включить в EIGRP те интерфейсы, где у вас по факту пользователи находятся. В нашем случае первая команда включает EIGRP здесь, здесь и здесь. Вторая команда network 10.0.0.1 по маске 0.0.0.0 говорит, что EIGRP надо включить на интерфейсах, у которых IP-адрес на 100% совпадает с 10.0.0.1. На все 32 бита он 10.0.0.1. Мы перебираем все наши интерфейсы. Здесь другой IP-адрес, здесь другой, здесь другой, а здесь — подходящий. В точности совпадает с нашим условием access list. IP-адрес был по 24-й или по 29-й, или по 30-й маске. Connected сетка с этого интерфейса под 29-й или по 30-й маске попадает в анонс. Ничего общего с тем, что здесь прописано 0.0.0.0, то есть аналог маски /32, в анонсе не будет.

В анонсе появится маска, которая висит на интерфейсе. Дальше. Если у вас есть secondary адреса на интерфейсе, и они находятся в другой сети, то они тоже попадут в анонс. Если у вас есть интерфейс, и вы на нём прописали IP-адрес такой-то, IP-адрес другой secondary, IP-адрес третий secondary, то в анонс будет включено всё, что есть. Более того, если у вас есть так называемые attached маршруты — ip route, и дальше вы указываете сетку, например 10.2.2.0 по маске 255.255.255.0, и вместо шлюза указываете интерфейс, допустим FastEthernet 0/0. В этом случае маршрут считается attached и фактически считается как connected на этом интерфейсе.

Для того чтобы распознать адреса в этой сети, вы будете слать ARP и будете пытаться нащупать конечных получателей прямо в этом интерфейсе. Если у вас есть такие attached маршруты, то они тоже попадают в анонс. Кстати, популярная ошибка — когда делают шлюз по умолчанию 0.0.0.0 0.0.0.0 и дальше указывают, допустим, FastEthernet 0/0. Attached маршрут на вообще все IP-адреса в мире. Тогда на все IP-адреса в мире вы перестаёте пользоваться шлюзом как таковым, вы начинаете слать ARP на всю сеть: у кого из вас такой IP-адрес, скажите свой MAC. Вы хотите, допустим, 8.8.8.8 нащупать — вы 8.8.8.8 начинаете ARP-ом прощупывать в интерфейсе FastEthernet 0/0. В большинстве ситуаций это работать не будет, но если у соседа-роутера, который является шлюзом, есть proxy ARP, он будет отвечать своим MAC-ом на запросы любых IP-адресов. Тогда, даже если вы неправильно пропишете дефолтный маршрут attached на интерфейсе, всё равно это по факту будет криво-косо работать.

До тех пор, пока у вас не переполнится ARP-кэш, потому что все IP-адреса в мире будут попадать в этот самый кэш. Connected и attached сетки на интерфейсах попадают в анонс. Если вдруг вы работаете с EIGRP и у вас что-то пошло не по плану, или вы просто хотите удостовериться, что всё идёт по плану, что всё хорошо работает, то алгоритм диагностики EIGRP будет состоять из следующих пунктов. Первое — проверяем, что у нас источник маршрутной информации в show ip protocols зарегистрирован, что EIGRP действительно согласен какие-то маршруты устанавливать в таблицу маршрутизации. Проверяем интерфейсы, на которых EIGRP завёлся. Проверяем соседей, которые на этих интерфейсах обнаружены. Проверяем маршруты, которые от этих соседей изучены. И проверяем маршруты в таблице маршрутизации, которые EIGRP в эту таблицу положил. Show ip protocols, я думаю, вы видели, как минимум на RIP, поэтому здесь для вас вряд ли что-то будет новое.

Здесь show ip protocols показывает настройку router EIGRP — краткие свойства этого процесса маршрутизации. Показано, с какими автономными системами EIGRP у нас запущен. Если у нас всего один экземпляр EIGRP, показывается тот самый единственный, который запущен. Если запущено несколько, то покажутся все. Вы не можете, кстати, на железке иметь больше чем 32 способа вброса маршрутной информации в таблицу. Один из способов всегда будет connected, другой, как правило, static. Оставшиеся 30 вы можете распределять между EIGRP и OSPF. Вы можете запустить, например, 30 автономок EIGRP, и тогда у вас будет один connected источник маршрутной информации, один static, и новые OSPF вы запустить не сможете. Вы можете сказать: окей, тогда мы убираем одну из 30 автономок EIGRP, у нас остаётся 29 автономок, у нас остаётся, например, один слот под OSPF.

Всего блоков в show ip protocols может быть до 32 штук. Вряд ли вы когда-то подойдёте к тому, чтобы это число потрогать на практике, чтобы действительно в продакшене вы упёрлись в лимит и больше маршрутных источников не получается завести. Это либо много автономок EIGRP, либо много экземпляров OSPF. RIP — один можно запустить только в IPv4. RIPng можно запустить несколько, но в RIPng больше ограничений. BGP тоже один можно запустить. Можно какой-нибудь ODR — протокол, который основан на цисковских CDP-сообщениях, и он тоже считается маршрутным источником. Всего есть лимит на 32 разных маршрутных источника. EIGRP 650001 в нашем случае — это один из них. Показывается, что у нас коэффициенты метрики не менялись.

Эти самые K1, K2, K3, K4, K5 по умолчанию 1, 0, 1, 0, 0. Cisco здесь прикидывается старой ветошью и говорит, что у неё только 5 коэффициентов метрики. На самом деле есть ещё K6, который она безусловно знает, безусловно обсчитывает, только не показывает. И K6 тоже равен нулю. Дальше. Показывается Router ID. Как уже говорилось, алгоритм следующий: если он задан вручную, то используется то, что задано вручную. Если вручную не задан, берётся самый большой IP-адрес с виртуальных интерфейсов, в частности с loopback-ов. И если на виртуальных интерфейсах никаких IP-адресов нет, то берётся самый большой IP-адрес с физических интерфейсов. Дальше показываются другие свойства. Active Timer — 3 минуты. Это как раз сколько времени маршрут имеет право сидеть в состоянии Active. Больше чем 3 минуты смысла нет держать, потому что если сосед не ответил за 3 минуты, то этот сосед либо должен был быть отдельно запрошен — не тупит ли он — с помощью SIA Query, SIA Reply, и тогда Active Timer продлится, либо от него перестанут приходить Hello-сообщения, и мы его прибьём.

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

EIGRP отдаёт пачку маршрутов, таблица маршрутизации эти маршруты принимает, отдаёт CEF, CEF пережёвывает. вставляет в свою таблицу ускорения и дальше балансирует трафик между этими маршрутами. Может быть по отдельным пакетам будет балансировка идти, может быть по IP-шнику получателя. Дальше. Максимум hopcount 100. Как раз я говорил, что в каждом маршруте среди компонентов метрики есть hopcount. И у вас есть ограничения на то, сколько hopcountов может пройти маршрут перед тем, как дойдет до нашего роутера. Метрика hopcount 100 будет считаться бесконечностью. Связано это с тем, что EIGRP, как любой другой дистанц-векторный протокол динамической маршрутизации, уязвим для подсчета на бесконечности. И у него может сложиться ситуация, при которой злой администратор возьмет и искусственно его настроит таким образом, что два роутера будут смотреть друг на друга

и один говорит: ты должен будешь отправлять трафик в удаленный мир, потому что ты ближе. А другой EIGRP роутер будет говорить: нет, ты ближе. Устроить искусственно такую ситуацию можно, хоть и очень-очень сложно, но теоретически можно. Поэтому если вдруг у нас получится, что один маршрутизатор говорит: я тебе посылаю какой-то маршрут, и он прибавляет hopcount к тому, что у него в таблице маршрутизации было, и дальше соседний роутер говорит: я тебе тоже посылаю этот маршрут, и я тебе тоже сообщаю, что через меня можно добраться до этой сети. Они друг другу будут пытаться кидать эти маршруты, как правило через транзитный третий. И в такой ситуации действительно этот самый hopcount пригодится. Сначала мы посылаем маршрут одному, потом другой посылает третьему, третий посылает первому. И каждый раз при прохождении маршрута через это кольцо hopcount увеличивается на 3. Так, metric variants. Это как раз насколько маршруты, прошедшие feasibility condition,

не самые выгодные, смотрящие в сторону feasible successors, но не установленные в таблицу маршрутизации, могут отличаться от самого выгодного маршрута, который в таблицу маршрутизации установлен, для того чтобы потенциально иметь возможность установиться в эту самую таблицу. Это множитель, который по умолчанию равен единице, что означает: только самые выгодные маршруты могут быть установлены в таблицу, то есть те маршруты, у которых метрика не больше, чем в один раз больше, чем метрика самого выгодного маршрута. Вы можете здесь поставить любое другое число, целое, от единицы до по-моему, 128. И если у вас есть маршрут хороший, есть маршрут, который тоже неплохой, но у него метрика отличается, например, в полтора раза, вы можете сказать: метрика у нас variance 2, и тогда маршруты, которые до двух раз более дорогие,

чем самый выгодный маршрут, тоже считаются хорошими, тоже устанавливаются в таблицу маршрутизации. Несмотря на то, что фича кажется очень хорошей, этот самый UCMP, Unequal Cost Multipath, с ней связано множество заморочек, поэтому ориентироваться на то, что EIGRP может такое сделать, и как следствие это включать, я бы не стал. Проблема в том, что в определенных ситуациях это будет приносить больше проблем, чем пользы, потому что если у вас есть интерфейс, который хороший, есть интерфейс, который похуже, но тоже без петли, очень редко на самом деле в реальной производственной сети предприятия будет задача пускать трафик по обоим маршрутам. Чаще всего вполне нормально будет, если вы будете посылать трафик по одному маршруту, и он будет нормально доходить до сети получателя. А если вдруг он дохнет, то есть всего один способ, как добраться до сети — это через другой аплинк, и он все равно должен выжить в случае отказа основного.

Поэтому смысла загружать оба аплинка на самом деле особо нет. У EIGRP в версиях до 12-го IOS была автоматическая агрегация маршрутов на границе классовых сетей. Такая же, как в RIP, который мы отключали командой no auto-summary. Если вы работаете с 12-м IOS, это, как правило, происходит на старых шеститысячниках. Если вы купили 6500 свич, и вы запустили на нем на старом супервизоре 12-й IOS, и вы включаете на нем EIGRP, то у вас будет суммаризация на границе классовых сетей. В 15-м IOS это по умолчанию выключено. Но если вы в 12-м IOS будете работать, то по умолчанию она работает. Это одно из различий 15-го и 12-го IOS, что автоматическую суммаризацию наконец отключили. До этого момента надо было ручками прописывать no auto-summary. Так, дальше. Routing for Networks — это какие команды network мы ввели.

Обратите внимание на то, что мы вводим в команде network маску wildcard, а в Routing for Networks показывается, что маска здесь будет прямая. И на самом деле это очень хороший пример того, что wildcard нужен для того, чтобы задать условие access-листа. И это условие access-листа будет перебирать все IP-шники, которые у вас висят на интерфейсах. Но на самом деле авторы протокола EIGRP не предполагали, что вы можете быть каким-то странным человеком и пытаться перебрать этим самым условием, например, IP-шники, которые будут четные, чтобы на четных IP-шниках включить EIGRP, а на нечетных не включать. Или наоборот. Они сказали, что в 99% случаев, когда вы используете эту самую команду network, вы wildcard будете указывать просто в явном виде, на каком одном единственном интерфейсе включить EIGRP, и в этом случае у вас маска будет 0.0.0.0, то есть аналог /32 маски. А если даже вы указываете не /32 маску,

а какую-то другую, то вы тем самым хотите накрыть EIGRP сразу целую пачку интерфейсов, у которых IP-шники на что-то общее начинаются. Чтобы потом, например, сказать, что во всех этих IP-шниках у вас сидят пользователи, и потом, когда вы наружу будете анонсировать эти сетки, чтобы вы схлопнули эту сетку, суммаризировали ее ручками, и наружу бы отправляли только одну большую целую сетку. Поэтому здесь этот /16, который мы ввели, такой сети в таблице топологии нету. В таблице топологии есть /24 сетки, которые мы включали на предыдущем слайде. Стоит у нас 2.168.1.1 по /24 маске, IP-шник висел, 2.1 IP-шник, 3.1 IP-шник висел. Connected сетки там 1.0 по /24 маске, 2.0 по /24 маске, 3.0 по /24 маске. Здесь показывается Routing for Networks, и уже wildcard маску здесь не пишут.

Забегая немножко вперед, вы не можете сделать разрывную wildcard маску там. Несмотря на то, что маска wildcard в принципе сделана специально перевернутая для того, чтобы иметь возможность в любой момент сказать: здесь мы хотим нолик, здесь хотим единичку, здесь хотим снова нолик, здесь хотим снова единичку. По факту, wildcard маска при настройке EIGRP не позволяет вам делать что-то отличное от сначала идут все нолики, потом все единички. И дублируется административное расстояние. Internal 90, External 170. В Routing Information Sources здесь показывается список соседей, то есть те Next Hop, которые в таблице маршрутизации будут поставлены по факту. Так, если мы проверили, что EIGRP у нас заведен, что Router ID у него не нулевой, что команды network правильно все отработали,

что коэффициенты метрики никто не менял, они по умолчанию 1, 0, 1, 0, 0, то вы говорите: вроде бы все в порядке. Дальше начинаем траблшутить интерфейсы. Show IP EIGRP Interfaces показывает, на каких интерфейсах EIGRP отсылает Hello Packet. Он не показывает пассивные интерфейсы, и он показывает только то, где отправляются Hello Packet. Если интерфейса нет, то интерфейс может быть выключен, может быть пассивным, или на нем первый IPшник не попадает под условия команды Network. То есть вы не включили EJRP на этом интерфейсе. Под действие команды Network должен попадать именно первый IP-адрес на интерфейсе, тот, который первичный праймари. Если у вас secondary IPшник попадает под действие команды Network, чудо не произойдет. На каждом интерфейсе показывается количество пиров, на каждом интерфейсе показывается очередь

на доставку данных, соответственно, сколько пакетов мы собираемся отправить на этом интерфейсе в ближайшем будущем. То есть у нас уже есть какие-то данные, которые мы собираемся отправить, но мы их копим для того, чтобы в одном апдейте, например, отправить. Так, если secondary не попадает под Network, он будет анонсироваться. Но если праймари не попадает под Network, то на этом интерфейсе не включается EJRP. так, да, здесь вот количество пакетов, которые мы собираемся отправить, очередь на отправку. Дальше показывается, сколько среднее время прохождения пакетов туда-обратно. Показывается, сколько маршрутов в этом интерфейсе предстоит отправить в ближайших апдейтах. То есть, если у нас есть какой-то интерфейс на этом интерфейсе,

мы собираемся отправить в ближайшее время апдейт. Вот мы накопили какие-то маршруты, которые мы хотим отправить, и собираемся их запулить. Вот здесь показывается, сколько их есть. По-хорошему, конечно, вот в этой колонке у вас всегда должны быть нули. Это означает, что если какие-то маршруты у вас зародились, вы немедленно их и отправляете. Так, дальше. Среднее SRTT это среди всех пиров, которые обнаружены на интерфейсе. Вы считаете SRTT и средне арифметическое берете и показываете здесь на интерфейсе. Дальше. После того, как интерфейс у вас включился, он не пассивный, вы отправляете туда hello-пакеты, вы ожидаете, что на этом интерфейсе у вас будут устанавливаться соседства. Show IP EGRP Neighbors показывает на то, какие соседства у вас есть, и показывает, соответственно, что если вдруг вы ожидаете, что сосед есть, а его по факту нету, ну, в общем, у вас есть какой-то механизм для разрешения этой проблемы.

Какие проблемы могут быть? Если не совпадают номера автономок, если не совпадают primary сетки, то есть вы отправляете hello-пакеты из под primary IP-шника, если у вас не совпадают primary IP-шники, сети primary IP-шников, EGRP не подружатся. Очевидно, не совпадение коэффициентов метрики. Если у вас EGRP не разрешает прием протокола 88, то, соответственно, тоже соседство не установится. Напоминаю, что аксесс-листами вы можете фильтровать трафик. Если у вас висит аксесс-лист на вход, то вы фильтруете любой трафик, даже тот, который предназначен для самого роутера. А вот если у вас висит аксесс-лист на выход, то трафик самого роутера под выходной аксесс-лист не попадает. Поэтому на выход аксесс-листы можно вешать сколько угодно, EGRP все равно работать будет. А вот на вход, если вы повесите, то EGRP может развалиться, если вы забудете его в явном виде включить. Ну и понятное дело, да, что если вы на интерфейсе

не включили EGRP, то сосед там не найдется. Поэтому, да. Вот. шоу-эпи EGRP показывает список установленных соседств. Показывается первая колоночка это хэндл, вот буковка Х, это просто порядковый номер соседа. Дальше айпишник соседа, интерфейс, на котором он нашелся. Холд таймер, через сколько мы признаем соседа трупом. Аптайм, как давно мы с ним дружим. СРТТ, смуз-раунд-трип-тайм в миллисекундах, сколько с именно этим соседом среднее время прохождения пакетов туда-обратно. Когда вы отправляете мультикастовый апдейт, вы ожидаете, что вам все соседи должны прислать подтверждение этого апдейта. И, соответственно, вы знаете, сколько времени до каждого соседа в среднем проходят пакеты. На основании этого времени для каждого отдельного соседа вы вычисляете ретрансмиссион тайм-аут, за сколько вы ожидаете получать acknowledge именно от него. Может быть такое,

что у вас на интерфейсе одновременно есть соседи, которые быстро отвечают и медленно отвечают. Вот вы отправляете мультикастовый апдейт, и дальше вы говорите, от быстрых соседей мы ожидаем acknowledge сразу. Если они сразу не отвечают, мы им сразу начинаем переотправлять юникастом. А медленные соседи, у них может быть, соответственно, внутренняя сложность с ответами, и мы согласны подождать их подольше. Вот у них ретрансмиссион тайм-аут будет больше. Циска не раскрывает формулу, как считается РТО, но обычно, да, там достаточно хорошо она считается, и ретрансмитов, как называется, лишних ретрансмитов, да, вот у Циски встречать, встретить можно крайне редко. Кьюкаунт это размер очереди на отправку именно этому соседу. То есть, если у нас есть сосед, и мы собираемся ему что-то отправить, но не отправляем, потому что, например, либо не успели еще, либо потому что мы начинаем ему

отправлять пакеты, которые он не подтвердил, и у нас уже накопился какой-то бэклог из еще дополнительных пакетов, которые надо ему отправить. Вот в этой ситуации соответственно показывается, сколько у этого соседа будет задолженность перед вами по приему пакетов. Кьюкаунт, ну, очередь, размер очереди. И Sequence Number это показывается, какие, какой последний номер пакета мы от него получили. Так. После того, как с соседом соседство все-таки установлено, он начинает кормить нас апдейтами, эти апдейты попадают в таблицу топологии, ну, содержимые их. И Show IP EJRP Topology показывает маршруты, которыми нас накормили соседи. По умолчанию показывает только маршруты, которые удовлетворяют feasibility condition. Если хотите, можете показать вообще все, чем вас накормили соседи с ключом либо All Links, либо Detail. В IPv4 Detail,

в IPv6 только All Links Detail там нет. И показывается, что в IP EJRP Topology вот сначала легенда, буковка P означает с маршрутом все хорошо, A означает все плохо. U мы отправили на этот пакет Update, ну, редко можно бы встретить. Q мы отправили на этот маршрут запрос кому-то, и вот мы висим и ждем, ждем, ждем, что он вернется. И R мы отправили на этот пакет Reply. По факту вы встретить можете только вот эти вот два. То есть легенда показывает возможные варианты, как это выглядело на старых-старых версиях EOS. Вот ничего сегодня вы по факту другого не увидите, кроме как Passive и Active. Дальше показываются маршруты, которые у нас есть. те маршруты, которые в нашей топологии присутствуют. По умолчанию, если мы не манипулируем маршрутами никак, у всех роутеров таблицы топологии должны быть

одинаковые. Поэтому, если какую-то сетку надо рассказать соседям, то она у вас в таблице топологии должна быть, даже если она у вас connected. И вот здесь показывается, что сетка 10.000 по 24 маске у нас connected на роутере R2. Напоминаю, тут топология была вот такая. вот три маршрута на одном и это был R1. И здесь вот у нас R2. R2 показывает, есть connect от сетка транзитная между двумя роутерами R1 и R2. У нее тоже считается feasible distance, самая выгодная метрика за всю историю наблюдений, потому что у интерфейса, которым мы в эту сетку смотрим, есть bandwidth, есть delay, есть load, есть reliability. То есть мы можем вектор, как мы эту сетку знаем, точно так же запихнуть в формулу и получить вот этот самый feasible distance. Ну, естественно, что эту сетку мы в таблицу маршрутизации поставить не сможем, потому что там она уже занята. У нативного EJRP маршрута административное расстояние 90, а у connected маршрута административное расстояние 0. Поэтому

мы вытеснить EJRP маршрутом connected маршрут конечно же не сможем. Но тем не менее, если бы захотели, мы бы могли бы наверное это сделать и тогда бы у нас метрика этого маршрута была бы как раз 28160. Дальше показывается про маршруты, которые все-таки уже EJRP, которые получены от соседа 1001. Вот сетка 001020. По каждому маршруту у нас есть один feasible successor. Пардон. FD, feasible distance, показывается, сколько эта сетка стоит на нас через него. У него эта сетка стоит 28160 копеек, через него на нас эта сетка стоит 28416 копеек. И поскольку эта сетка никогда не становилась хуже, нам известно, то feasible distance у нас вот как раз такая же, как она прямо сейчас у нас и стоит через него. Физи был distance может уменьшаться, если вдруг нам сетка сначала стоила много, а теперь она стоит мало.

Ну вот она не может увеличиваться. Даже если вдруг текущий successor стоит дорого, потому что мы когда-то сетку знали хорошо, а сейчас настолько хорошо не знаем, сейчас знаем плохо, но все равно еще как бы вот successor живой и удовлетворяет условия feasibility condition. То есть может быть такое, что метрика через текущего successor, самая выгодная метрика, она будет больше, чем feasible distance, потому что сейчас мы не знаем настолько же выгодно эту сетку, как знали когда-то. Ну вот да, в нашем случае feasible distance равна метрике successor. И по каждой из трех сеток показывается, что метрика там везде одинаковая, 28316. И учитывая, что это гигабитный интерфейс, мы можем сейчас попытаться просто, так сказать, реверснуть эту метрику и попытаться понять, откуда она взялась. 28316. Мы знаем, что интерфейс там гигабитный, поэтому с очень большой вероятностью мы можем предположить, что мы знаем соседа через гигабит, и дальше сосед

в эту сетку смотрит либо там гигабитным, либо 100-мегабитным интерфейсом. Для начала нам надо вот это вот 28416 разделить на 256. 256. Как вы помните, там метрика 10 в седьмой степени, разделенная на bandwidth, плюс delay, и, соответственно, все это дело умноженное на 256. Поэтому делим метрику на 256, минус 256, получаем 30, нет, 20. 14 минус 6, 8, 281. Так, минус 256, это еще единица, 1, 3, 11 минус 6, 5, 1356, 1256. У меня с математикой все плохо. Так, и это 5. правильно я посчитал?

Да, правильно. Нет, неправильно, 1356. Вот, и, соответственно, да, получается 5, 2, 5, 5, 5, 6, 30. Что-то не складывается. Дайте, калькулятор запущу. Да, с калькулятором посчитал, у меня с математикой все, что-то как-то плохо сейчас, 111 получается. Давайте проверим. 256 умножить на 111. Это 256, 256, 256, 256, 6, 1, 1 в уме, 6, 12, 14, 8, 2, 28, 1000, 14, 16. Да, все правильно, 111. То есть, у нас вот этот вот компонент, он будет равен 111. У меня есть такая гипотеза, что 10 в седьмой степени, это либо 10, либо 100, а соответственно,

delay, это вот все остальное. Вот у меня есть такое предположение, что вот эта штука, это скорее всего 100, а вот эта штука, это скорее всего 11. Если мы знаем, что на соседе эта сетка стоила 28 160 копеек, то мы можем посчитать, какие параметры были у него, какие параметры были у нас. 28 160 и 28 316 отличаются друг от друга, вот как раз на 256. То есть, у него вот этот компонент весь был 110, а у нас стал 111. Дилей у нас вырос на единичку. То есть, скорее всего, как раз вот интерфейс, которым мы смотрим на соседа, гигабит 0,0, имеет задержку 1 десяток микросекунд. Вот. А соответственно, вот эта вот вся часть, это 100. 10 в седьмой степени, разделенная на какой-то bandwidth, получается 100. Ну, соответственно, bandwidth будет 10 в пятой степени. Это 100 мегабит в секунду. Bandwidth 10 в пятой степени. Ну, или 10 мегабит. Вот.

Вот такая вот метрика. Сосед заявлял нам, что знает сетку за 10 мегабит, за 10 микросекунд. Мы узнали этот апдейт через гигабит 0,0, через гигабитный интерфейс. Ой, простите, не 10, 100 мегабит. Здесь 100. Да. 100 мегабит. Сосед заявил, что знает сетку за 100 мегабит, за 10 микросекунд. Мы знаем соседа через гигабит за 1 микросекунду. Складываем задержки, получаем 11 микросекунд. Берем наименьшую bandwidth, получаем те же самые 100 мегабит и получаем вот как раз суммарную метрику 28416. После того, как в таблицу маршрутизации мы пытаемся вставить все маршруты, они у нас попадают туда с буковкой D 122, 168, 1, 0, 2, 0, 3, 0, по 24 маске с метрикой в таблице маршрутизации, равной метрике EGRP-шный computer distance.

В классическом режиме метрика здесь как раз совпадает. То есть то, что в таблице маршрутизации мы видим, это как раз EGRP-шная метрика и будет. Здесь показывается NextHop и показывается для упрощения lookup сразу интерфейс, через который мы будем выходить. Сделано это на случай, если вдруг мы будем отключать Ceph, чтобы за один проход сразу найти самый выгодный маршрут и сразу получить выходной интерфейс и канальный адрес, через который мы будем его знать. Вот это вот, сколько маршрутов таблицы маршрутизации уже держится. Если захотим, мы можем посмотреть show IP-road, опять же, свойства этого маршрута. Увидим там, откуда маршрут взялся, из какого протокола, из какой автономки, административное расстояние 90, ну вот оно 90 и есть. Метрику EGRP-шную это, соответственно, computer distance, тип маршрута нормальный, хороший внутренний маршрут. И вот это вот, это указывается вектор,

в какую сторону мы соседа будем знать. Вот получили вектор от 10.001 с next hop-ом 10.001. Метрику посчитали 28416. Суммарная задержка 110 мкс, 100 мегабит в секунду, как раз, как я посчитал. Reliability полноценная, загрузка минимальная, hop-count единичка, минимальный MTO 1500 байт. Ну, то есть, да, в таблице маршрутизации, на самом деле, кое-какие следы у EGRP будут. Если вы потом будете брать, например, из EGRP перекладывать маршруты в другой EIGRP, то по факту получатель EIGRP будет забирать данные из таблицы маршрутизации, а не напрямую из другого экземпляра EIGRP. Помните табличку, которую я показывал? В RIP, как редистрибуция выглядит, что у нас есть роутер, у него есть отдельные процессы. И здесь, например, RIP, а здесь EIGRP. И для того, чтобы из таблицы маршрутизации

что-то достать, RIP будет работать именно с таблицей маршрутизации. Если он говорит, я хочу перекладывать маршруты из EIGRP в RIP, он не идёт напрямую в EIGRP, он идёт в таблицу маршрутизации, говорит, дайте мне маршруты EIGRP-шные из 65000 001 автономки. Популярное заблуждение, что RIP забирается в процесс EIGRP. Нет, ничего подобного. RIP забирается в таблицу маршрутизации, говорит, дайте мне, пожалуйста, те маршруты, которые удовлетворяют нашему условию. И маршруты, по ним видно, откуда они пришли в таблице, и видно все свойства. Если вдруг мы скажем, дайте нам, пожалуйста, только, например, внешние маршруты, только внутренние маршруты, мы в таблице маршрутизации все эти свойства будем по факту видеть. Таблица маршрутизации несёт в себе дополнительную информацию, не только ту, которую мы видим в show IP route просто, но и дополнительную информацию, которую маршрутный источник решил туда положить. И мы можем фильтровать маршруты

на основании всяких свойств. Если вдруг у нас будет два роутера EIGRP запущено на одной железке, второй роутер EIGRP, который будет не RIP, а EIGRP, он опять же не будет лезть в память первого процесса EIGRP, он полезет в таблицу маршрутизации и заберёт всё это для того, чтобы переложить этот вектор метрик в новый протокол из таблицы маршрутизации. Там всё это есть. Именно поэтому, когда мы говорим, что мы будем фильтровать с помощью distribute-list, на выходе из таблицы маршрутизации, на выходе, мы будем эту самую фильтрацию вешать. Но до этого сейчас дойдём чуть дальше. EIGRP может накормить таблицу маршрутизации несколькими маршрутами, и дальше между этими маршрутами будет CEF балансировать трафик. Я про это уже говорил. EIGRP может добавлять в таблицу маршрутизации

маршруты одинаковые или не одинаковые, если мы задаём параметр variance. И тем самым мы задаём мультипликатор, во сколько раз не самый выгодный маршрут по метрике может отличаться от самого выгодного, чтобы его всё ещё можно было добавить в таблицу. При этом любые маршруты, которые мы добавляем в таблицу, обязаны удовлетворять условию feasibility condition. То есть в таблицу маршрутизации могут попасть next hop только feasible successors. Вы можете добавить в таблицу маршрутизации до 32 маршрутов, но на экзамене надо будет говорить, что 16. То есть все актуальные платформы по факту позволяют задать 32 маршрута. Максимум paths 32. Что-то хотел сказать умное. Ладно, забыл. Если у вас метрики будут различаться значительно, вы задаёте variance побольше, и у вас есть несколько маршрутов, которые действительно сильно отличаются друг от друга по метрике,

то вы можете балансировать трафик между ними в некоторой пропорции. Опять же, в таблице маршрутизации видно, в какой пропорции трафик может балансироваться. За балансировку пропорциональную будет отвечать CEF. EIGRP ничего для этого не делает. Он просто сообщает, что некоторые маршруты в таблицу маршрутизации попадут, и будет рекомендовать, в какой пропорции надо трафик между ними балансировать. Он может сказать, что трафик к share должен быть какой-нибудь, 117 к 253. Но, естественно, CEF никогда не сможет такую балансировку обеспечить, поэтому то, что по факту балансировка какая будет, это уже не проблема EIGRP. Он говорит, я тебе сообщаю, что есть маршруты, у этих маршрутов метрики друг к другу относятся как, не знаю, 115 к 93, пожалуйста, соблюди эту балансировку. А CEF на это возьмёт, положит толстый болт и скажет 115 к 93, это почти одинаково. Я буду балансировать

трафик один к одному, ты даже не заметишь. Если у вас есть сеть, и, как уже говорилось, EIGRP в этой сети запущен для того, чтобы пользователи могли обмениваться пакетами, то нужно, чтобы на всех роутерах, на всех-всех-всех роутерах, все-все-все маршруты до всех-всех-всех пользовательских сеток были проставлены. Мы можем это сделать несколькими способами. Первый способ — мы можем включить EIGRP на интерфейсах, которые смотрят на пользователей, но в этом случае мы в этот интерфейс начинаем отправлять Hello-пакеты. Если мы даже используем аутентификацию, мы подписываем наши пакеты цифровой подписью, всё равно получается, что пользователь видит, что приходят какие-то Hello-пакеты от роутера, ну нафига это надо. Это гипотетически даёт возможность злоумышленнику посмотреть на то,

какие MD5-хэши там получаются, если мы подписываем пакеты хэшами, или если вдруг мы вообще забудем подписать хэшами пакеты, то даёт возможность злоумышленнику подружиться с нами и вбросить какие-то левые маршруты в таблицы маршрутизации. Мы этого не хотим. И в большинстве ситуаций мы хотим сделать так, чтобы интерфейс, который смотрит на пользователя, чтобы connected-маршрут с него попал в анонс, но чтобы на этом интерфейсе мы по EIGRP не дружили с кем попало. Один из способов это сделать — это как раз включить EIGRP на интерфейсе, но объявить интерфейс пассивным. И делается это командой passive interface. В отличие от RIP, в котором мы перестаём отправлять анонсы на интерфейсе, но мы принимаем анонсы на этом интерфейсе, в EIGRP мы перестаём отправлять Hello-пакеты, как следствие не устанавливаем соседство. И как следствие на неустановленном соседстве мы ничего не принимаем лишнего. Поэтому в RIP нужно было дополнительно защищаться,

объявив пассивный интерфейс, для того, чтобы не отправлять лишние апдейты в сеть. И плюс ещё access-листом закрываться от входящих апдейтов. Здесь достаточно просто объявить интерфейс пассивным, и этого более чем достаточно. Это решает все задачи, которые у нас тут есть. Connected-сетки всё равно попадают в таблицу топологии, но Hello-пакеты не отправляются, соседство не устанавливается, и взломать нас таким образом не получится. Опять же, можно перечислить явно пассивные интерфейсы, можно объявить пассивными все интерфейсы, passive interface default, а потом перечислить те интерфейсы, на которых вы хотите дружить с соседними роутерами. Сабинтерфейсы, да, конечно. Здесь просто название интерфейса указывается, passive interface, FastEthernet 0.0.1, 0.2 и так далее. То есть то название интерфейса, на котором у вас висит IP-адрес, с которого вы собирались отправлять Hello-пакеты. Удобно как раз на роутерах, которые вас смотрят на конечных пользователей,

включать сразу passive interface default и просто в явном виде говорить, на каких интерфейсах у вас будут аплинки, на каких интерфейсах по факту будет происходить дружба с соседними роутерами. Это один из способов. Второй способ, на самом деле, есть другой, который предполагает, что вы EJRP включаете только на транзитных линках, а на пользовательских сетях вы EJRP не включаете. И дополнительно вы потом занимаетесь редистрибуцией. То есть если у вас есть роутер, у него есть несколько сеток с пользователями. Есть транзитный интерфейс, который смотрит в сторону остального мира. Можно EJRP включить везде и потом на этих четырех интерфейсах сказать, не отправляем ничего, не принимаем ничего. Или альтернативный вариант. Можно не включать EJRP на пользовательских интерфейсах, сказать, что EJRP мы включаем только на транзитном линке, а вот connected сетки с этих интерфейсов редистрибутить в EJRP, ну, про это мы поговорим чуть дальше. Результат получится плюс-минус километр похожий.

То есть что так, что так, все остальные роутеры в топологии будут знать про то, какие маршруты у нас есть в сети. Ну, соответственно, маршруты будут разные. В одном случае это будут нативные EJRPшные интернал маршруты, в другом случае это будут редистрибутанты экстернал маршруты. Ну, да, оба варианта имеют право на жизнь. Если у вас есть интерфейс, в котором нет мультикаста или есть неполная связность, в принципе бывают разные среды. В курсе по роутингу предполагается в первую очередь, что под NBMI интерфейсами мы подразумеваем фрейм релей, но еще образцово показательный пример интерфейсов, в котором с мультикастом могут быть проблемы, это DMVPN. В DMVPN между сполками напрямую трафик не ходит. Поэтому если вам нужно будет, чтобы сполки друг к другу посылали пакеты, вам нужно будет IP-шники этих сполков прописать вручную. Ну и, соответственно, да, вот если вы хотите,

вы можете прописать IP-шники соседей на интерфейсе. Делается это в настройке роутера EGRP, то есть вы переходите в контекст роутера и говорите «Нейбор с IP-шником таким-то сидит за интерфейсом таким-то». Если вы это делаете, у вас интерфейс перестает отправлять мультикаст вообще. То есть как только вы указываете на интерфейсе соседа статического, интерфейс переходит в юникастовый режим, мультикаст перестает отправляться, входящий мультикаст начинает игнорироваться, то есть hello-сообщение от соседей, которые таким же образом не настроили вас, вы обрабатывать не будете. И вы должны будете прописать всех соседей в явном виде. До каждого соседа вы будете брать характеристики связи следующие. То есть delay, задержка сервизации у вас будет примерно такая же, как и на интерфейсе.

А вот bandwidth до соседа у SPF будет придумывать каждый раз отдельно. Он будет брать его 1 кбит в секунду. То есть помните, да, что у нас табличка соседей заполняется в тот момент, когда устанавливается соседство. И мы, если устанавливаем соседство на интерфейсе, то конкретно до этого соседа вектор заполняется со свойств интерфейса, которым мы его видим. Вот если вы прописываете в NBMA среде статических соседей, то у вас bandwidth получается такой вот, минимальный. Вы можете подкрутить этот bandwidth, если захотите, но да, по умолчанию он вот такой. Кроме того, можно будет подкрутить компоненты метрики. По умолчанию, я думаю, что вы уже помните, K1, K2, K3, K4, K5 у нас показываются, что они есть. Плюс на самом деле есть еще дополнительно K6. В классическом режиме циска прикидывается

старый древний циск из 93-го года, в который никакого K6 еще не было. Поэтому если вы работаете в классическом режиме, то у вас K6 по определению предполагается равный нулю. И если вы пытаетесь подружить циску, которая находится в классическом режиме, с циской, которая находится в неклассическом режиме, то вот вы должны будете в том другом режиме, который мы с вами еще не проходили, K6 ручками задать нулем. Ну, или оставить по умолчанию, по крайней мере. Если вы ручками его меняете, то не менять ручками из нуля. Дальше. Вы должны будете указать команду metric, waits, и дальше задать шесть цифр. Первая цифра – это type of service. EJRP изначально создавался с гениальной идеей сделать разные таблицы маршрутизации, разные вообще экземпляры протокола EJRP для трафика с разными типами. Можно было бы сказать, например, что голосовой трафик у нас обрабатывается по одной таблице, а там торренты обрабатываются по другой таблице,

а что-нибудь еще обрабатывается по третьей таблице. Вот можно было разные типы трафика выделить и держать отдельную топологию для каждого типа трафика. Называлось все это мультитопологи роутинг. Но по факту эта штука не взлетела, и по факту вы не можете работать ни с какой другой топологией, кроме как топология для type of service равной нулю. То есть вы указываете метрик, weights, дальше число 0, ничего другого циска не приемлет, и дальше 5 коэффициентов вот этих вот, K1, K2, K3, K4, K5. Они должны совпадать на всех маршрутизаторах в автономной системе. То есть для того, чтобы все маршрутизаторы вычисляли метрику однотипно, чтобы все соседи вычисляли метрику однотипно, на самом деле более важно. Но, соответственно, да, если у вас сосед А дружит с Б, они должны вычислять метрику однотипно, Б дружит с С, они должны вычислять метрику однотипно, С дружит с Д, они должны вычислять метрику однотипно. Получается, что все маршрутизаторы в автономной системе обязаны иметь коэффициенты метрики одинаковые.

Ну и вот, да, по умолчанию 1, 0, 1, 0, 0. Если вы хотите, вы можете покрутить эти коэффициенты, но, опять же, K2, K4 и K5 строгать нельзя, потому что они будут заставлять влиять на погоду, на метрику, как... Они будут оказывать на метрику непредсказуемое влияние. А вот K1 и K3, они по умолчанию равны единице, и их можно покрутить. Единственный способ, которым имеет смысл их крутить, это поставить K1 в 0. То есть вы его ставите в 0, и тогда у вас остается только K3, и тогда ваша метрика превращается в delay, умноженный на 256. Она получается фактически, как, ну, что-то напоминающее RIP. Просто, да, сравнивается не количество прыжков между роутерами, а суммарная задержка по маршруту между двумя роутерами, между двумя частями сети.

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

которые друг на друга смотрят интерфейсом, то вы на одной стороне можете задать одни таймеры, на другой стороне можете задать другие таймеры. Они не проверяются. Они не просто не обязаны совпадать на соседних роутерах, они даже на вашем роутере могут быть не согласованы. То есть, можно задать таймер hello больше, чем hold timer. И вы говорите, отправляем сообщение раз в 10 секунд, но через 5 секунд заставляем признавать нас трупом. Делать так не надо, но гипотетически, как бы, вы можете захотеть такое сделать. Вот как, например, здесь. IP hello interval, IP hold time. Мы указываем hello interval 15 секунд и hold time 10 секунд. Вот, мы устанавливаем соседство, после чего сосед у нас говорит, я не вижу от тебя последнее сообщение, присылает нам peer termination, что вы у него протухли, после чего вы посылаете ему сообщение, он с вами дружит заново, после чего через 5 секунд снова присылает вам, что вас считает трупом. Ну, да. То есть, сделать так можно, но не нужно.

Да, hold time вы передаете в каждом hello сообщении. То есть, так же, как CDP, например, устроен, вы отсылаете сообщение и вы говорите, через столько-то признавай меня трупом, если я ничего нового не пришлю. Вот. Дальше. Есть таймеры, которые можно задать на уровне всего роутера в целом. Это таймер active time. Сколько времени проводить в состоянии active? По умолчанию 3 минуты, вот можно его подкрутить. Ну, и в реальности вряд ли вам придется с этим иметь дело, опять же, потому что по факту в большинстве случаев вы будете обнаруживать падение соседа раньше, чем у вас этот active time кончится. есть два таймера, которые указывают на поведение, если у вас есть два роутера, в смысле, если у вас роутер и у него есть два супервизора. Ну, как правило, это на толстых роутерах 7600, 7200 серии или на свечах 6500, опять же,

4500. У них есть, соответственно, шасси и на этом шасси стоят два супервизора и каждый из этих супервизоров держит отдельный экземпляр EGRP. И в ситуации, когда у вас один супервизор, например, дохнет, можно взять и быстро переключиться на второй. И вот эта вот штука перескакивания с одного сдохшего супервизора или собирающегося сдохнуть, например, потому что он собирается перезагружаться, вот перескакивание перескакивания с одного на другой будет называться graceful restart или нон сейчас Да, non-stop forwarding. Да, смысл в том, что да, у нас есть один супервизор, он хочет закончить свою работу и передать свое управление линейными картами другому супервизору. И вот в определенных ситуациях вы можете сказать, что да, один супервизор у нас уже не работает, а второй еще не работает. И в некоторое время

требуется для того, чтобы линейным картам дать возможность подождать второй супервизор, который будет подниматься и как сказать не надо соседям, которые не будут видеть от нас hello сообщение, рвать с нами соседство. NSF это non-stop forwarding перескакивание между супервизорами, когда у нас один супервизор есть и второй супервизор есть. И graceful restart это тоже в принципе очень похожая штука, при которой мы посылаем фактически сообщение соседу, что сейчас с нами что-то будет происходить, пожалуйста, не надо рвать с нами соединение, не надо рвать с нами сессию, потому что, даже несмотря на то, что мы hello сообщение может быть присылать и не будем, потому что присылает их супервизор, по факту линейные карты маршрутами накормлены, и трафик не дезраптится от того, что супервизор у нас перезагружается. Трафик как ходил, так и ходит. На цехе все маршруты находятся в актуальном состоянии, поэтому,

да, вот оба эти таймера будут задавать поведение при перескакивании с одного супервизора на другой. Если у вас на железке нету двух супервизоров, то либо эти таймеры вы не можете назначить вовсе, либо они просто ничего не означают. Дальше. Еще одна штука, которую можно будет сделать, это аутентификация. Если мы работаем в классическом режиме, то можно работать в одном из двух вариантов. Либо не использовать аутентификацию вовсе, либо использовать аутентификацию по MD5. То есть мы подписываем наше сообщение и указываем, соответственно, хэш от пароля плюс содержимого этого сообщения. Аутентификация включается на уровне интерфейса, и вы можете иметь пароли, которыми подписываются сообщения. Для того, чтобы подписывать сообщение, используются так называемые ключевые цепочки или ключевые комплекты Keychain. Каждый ключевой комплект будет состоять из нескольких ключей, и у каждого ключа

есть номер, пароль и срок жизни. Вот если у вас есть ключевая цепочка, вы можете сказать, что подписываем сообщение с помощью этой ключевой цепочки. И дальше надо будет выбрать, какой ключ использовать. Cisco будет выбирать для того, чтобы отправлять сообщение, ключ, который будет действителен, у которого срок жизни еще актуален, и у которого будет минимальный номер. То есть, если есть в нашей ситуации вот ключ номер один, ключ номер два, и у них у обоих заданный Accept Lifetime, Send Lifetime, здесь и здесь, и оба они, в принципе, еще нормальные, актуальные, живые, но пароли у них разные. Вот в одном ключе пароль один, у другого другой. Надо будет выбрать, каким паролем мы подписываем сообщение. И, соответственно, выбирается ключ для отправки сообщения с минимальным номером. Приниматься при этом ключи будут любые. То есть, если мы принимаем сообщение, в нем будет написано, каким ключом, в смысле, ключом с каким номером

оно было подписано, и мы в таблице, в своей цепочке будем смотреть, есть ли у нас ключ с таким номером, увидим там пароль и попытаемся расшифровать этим паролем, действительно ли подпись правильная. Ключевые цепочки будут создаваться следующим образом. Мы заходим в конфег, в keychain, дальше даем название ключевой цепочки, переходим в контекст keychain, дальше указываем номер ключа, переходим в контекст настройка ключа внутри ключевой цепочки и дальше задаем, обязательно надо задать keystring, это просто парольная строка, и можно, если захотите, задать параметр, когда можно отправлять этот ключ, когда можно принимать этот ключ. Соответственно, задается send lifetime и accept lifetime, и дальше вы указываете время дата, время дата. Можно вместо какого-то времени и даты сказать infinite, то есть неограниченно долго принимать ключ можно.

Как, если вы захотите настраивать вот эти самые accept lifetime и send lifetime, их имеет смысл настраивать? Вот. Если у вас есть какая-то текущая дата, вот, например, сегодня у нас 20, какое там, 6-е, 25-е, 26-е, 25-е, 25-е, 10-е, 2018-е. В нормальной ситуации, ну, у вас уже 26-е, да, в нормальной ситуации мы не хотим использовать несколько ключевых, несколько ключей на ключевой цепочке. Мы не хотим, чтобы у нас можно было отправлять там такой ключ, а может, и какой ключ, можно пятый, можно десятый. Мы хотим, чтобы у нас всегда был один и тот же ключ. Если у нас все стабильно работает, мы прописываем ключ номер, допустим, один, говорим, что у нас просто ключевая строка циска 1, 2, 3, то есть мы создаем ключевую цепочку из вот этих вот трех параметров и все, на этом мы успокаиваемся. Но, в какой-то момент мы хотим поменять ключ. Мы хотим сказать,

у нас есть роутер, и этот роутер работает с паролем, который, например, утек, скомпрометирован. И мы хотим перейти на новый пароль. И вот мы хотим сделать это ровно в полночь 26-го, 10-го, 2018-го. Вот для того, чтобы это сделать, нам нужно будет сказать, наш роутер ровно в полночь должен начать посылать ключ с другим номером. Поэтому мы создаем ключ номер 2, прописываем новый пароль, прописываем send lifetime в полночь, там, здесь написано 1 января 2018-го, на самом деле, вот 26-го, 10-го, 2018-го мы отправляем такой ключ и прописываем, что дальше он будет работать неограниченно долго, пока нам не надоест. Но, соответственно, первый ключ надо перестать отправлять в полночь первого числа, в полночь 26-го числа. Мы на первом ключе прописываем send lifetime 0-0-0, такую же дату, а, пардон, пардон, пардон, send lifetime, какую-то дату в прошлом и дальше указываем, что вот до

0-0-0, 26-го, 10-го, 2018-го. фактически, если взять, нарисовать временную ось, вот это вот, типа, сейчас, прямо сейчас, в моменте, вот мы сейчас сидим и настраиваем нашу железку, вот это вот, это время x, когда у нас должен состояться переход с одного ключа на другой, мы говорим, вот с сейчас по время x должен работать ключ номер 1 и, соответственно, дальше должен работать ключ номер 2. Это про send lifetime. но, если мы скажем, что вот до определенного времени мы посылаем один ключ, а дальше немедленно мы начинаем посылать другой ключ, может сложиться ситуация, что время на соседе будет немножко отличаться. Поэтому, если он у себя пропишет accept lifetime, вот ровно 0-0, до 0-0, 26-го, 10-го, 2018-го у нас принимается один ключ, а с 0-0, 26-го, 18-го у нас принимается другой ключ, у нас есть шанс того, что время наше не совпадет. И может такое случиться,

что наше время будет расходиться там типа минут на 2. И в течение этих двух минут у нас не будут проходить сообщения, потому что они будут подписаны одним ключом, а расшифровываться будут другим. И вот для того, чтобы сказать, что у нас в течение некоторого времени есть переходный период, у нас принимается ключ номер 1 с небольшим нахлестом на ключ номер 2. Вот. И, соответственно, ключ номер 2 принимается тоже с небольшим захлестом на ключ номер 1. Поэтому, когда мы прописываем Accept Lifetime, мы прописываем, что ключ номер 1 принимается с прямо сейчас до там типа вот 5 минут 26-го числа с вот этим вот перехлестом типа в 5 минут. Это старый ключ. А новый ключ принимается с 5-ти минутом нахлестом что с 24-х часов 55-ти минут 25-го 10-го. Ну, то есть он начинает работать

чуть раньше, чем мы начинаем посылать новый ключ. Что если сосед вдруг будет у него немножко время идти раньше, у него часы идут быстрее, он нам начнет присылать ключ этот раньше, и мы его уже будем принимать. И вот вот эта вот дельта, она как раз позволяет небольшому расхождению в часах не повлиять на то, что у вас сосед будет рваться. Кто-то один начнет посылать пакеты с новым ключом раньше, кто-то чуть позже, но в любом случае hello сообщения смогут быть прочитаны. Даже несмотря на то, что у вас получится, что в какой-то момент отправляется один ключ, а принимаются два, ну вот либо старый, либо новый приниматься все-таки будут. Ну да, в ситуации, когда оба ключа в принципе вы принимаете, это не страшно. То есть к вам придет какой-то ключ, и вы говорите вот ключ номер один, в нем написано, что это ключ номер один или ключ номер два, прекрасно, вот имя расшифровываем. Но в ситуации, когда у вас send lifetime почему-то сделан так, что два ключа одновременно можно отправлять, вот в этом случае

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

Дальше. Если у вас что-то не получается, то ShowIP EJRP Interfaces Detail покажет свойства аутентификации на интерфейсе. То есть, вот ShowIP EJRP Interfaces, дальше вы указываете Detail и какой интерфейс вас интересует. Вот эта вот штука показывается, если вы просто заказываете ShowIP EJRP Interfaces. Здесь ничего интересного нет. А дальше начинается интересное. Вот эта вот штука. HelloInterval Какой таймер? Какой hold time? Включили ли вы Split Horizon или не включили? Сколько пакетов отправили? Сколько Hello отправили? То есть, вот эти вот Packetized это полезные пакеты с мясом. Hello, понятное дело, никакого мяса не несут. Они просто нужны для того, чтобы соседа нащупать. А вот вот эта вот штука это вот сколько мяса отправлялось. Сколько отправлялось мультикастов подтвержденных? Сколько отправлялось юникастов подтвержденных

и неподтвержденных? Сколько отправлялось повторных пакетов? То есть, вот мы юникастом чего-то отправили и не получили подтверждение. Мы вынуждены были ретрансмиссию сделать. И, соответственно, один раз мы получили пакет с неправильным номером. То есть, вроде бы все было хорошо, но ожидали там пакет с номером 11, а пришел 12, а потом только 11. для EJRP это нехорошо. Ну и вот самая последняя строчка показывает, что у нас на интерфейсе EJRP работает и ключевая цепочка там будет Keychain. Можно посмотреть на саму ключевую цепочку Keychain и посмотреть, какие там пароли. То есть, вот прям там plaintextом все будет видно. Show Keychain показывает вам вот это вот. Кстати, есть лайфхак. Вы знаете, что есть такая штука, как сервис Password Encryption, которая позволяет закодировать в конфиге пароли. Вот те, которые заданы ключевым словом Password, чтобы они в конфиге в открытом тексте не светились, чтобы если вам кто-то через плечо заглядывает,

когда вы Showrun делаете, он бы не увидел, что у вас пароль 12345. Как будет в известном фильме. 12345. Какой дурацкий пароль, такой только на чемоданах делают. Сменизи пароль на мои чемоданы. Да, вот. Ну и да, и вы можете, если захотите, расшифровать прямо средствами самой ЦИСКи, вот этот вот самый сервис ЦИСКа 7 закодированный пароль, вы можете сделать ключевую цепочку, скормить ей закодированный пароль, а потом сделать Showkey Chain, и она вам раскодирует ключ, который был закодирован с помощью ЦИСКа 7 кодирования. Ну или, если у вас есть доступ к браузеру, к интернету, то можно, конечно, в интернете раскодировать, это проще. Ну иногда просто бывает так, что вы находитесь в чистом поле, никакого интернета нет, перед вами ЦИСК, и там с нее надо вытащить пароль. Вот таким вот образом это можно сделать. Так, если у вас есть живой ключ, который прямо сейчас можно использовать,

Showkey Chain покажет вам это, то есть вот в нашем случае видно, что есть ключ номер один, который с паролем ЦИСКа 1, 2, 3, у него Accept Lifetime и Send Lifetime заданы, но показывается, что сейчас вот они не работают, то есть ни отправлять, принимать этот ключ мы уже не будем. А вот ключ номер 2 показывается, что сейчас он действителен, и мы сейчас будем его отправлять, сейчас будем его ожидать в входящих сообщениях. В принципе, в этот момент уже ключ номер 1 можно удалить. переход состоялся, переход состоялся, все, теперь вы принимать его в любом случае не будете. Так, я думаю, что, наверное, пока что мы можем сделать небольшую паузу и дальше надо позаниматься, попробовать все это дело потыкать вживую, потому что мы с вами прошли достаточно много всякой штуки, надо поднять EJRP в ЦИСКе, убедиться, что EJRP для IP4 заводится, ну и дальше уже поговорить про IPv6. Поэтому сегодня я предлагаю завершить

наши студии, сделать лабу и к IPv6 перейти уже в следующей части.