Настройка EIGRP Named Mode

Поговорим дальше про наш материал курса Route. Обсудили мы с вами работу EIGRP в классическом режиме. Это режим, который Cisco предложила использовать для настройки EIGRP, который наследует принципы настройки от протокола IGRP. Cisco делает роутеры очень давно. И начала она делать роутеры ещё тогда, когда сетевое железо было предназначено для работы в классовом режиме. И для работы в классовом режиме был протокол IGRP, который конкурировал с RIP первой версии. Конкурировал неплохо, все были счастливы. Потом появился бесклассовый режим. Стало необходимо использовать продвинутый протокол динамической маршрутизации. Cisco сделала Enhanced IGRP, или IGRP второй версии. И мы его знаем сегодня как EIGRP. Но для того, чтобы обеспечить совместимость со старыми устройствами, со старыми IGRP-шными устройствами, Cisco сделала настройку EIGRP исключительно похожей на настройку IGRP.

Все концепции настройки остались точно те же. Во-первых, осталась та же самая дурацкая команда network. Во-вторых, всё, что мы с вами настраиваем, настраивается в разных местах. Что-то настраивается на интерфейсе, что-то настраивается в контексте роутера, что-то настраивается где-то абстрактно в отдельных кусках конфига. Поэтому когда мы смотрим на конфиг EIGRP, мы вынуждены собирать этот конфиг для того, чтобы полностью понять, как железка в EIGRP работает, в разных местах. Настройки на интерфейсах, настройки в контексте роутера, настройки ещё непонятно где. Некоторое время оно так проработало и до сих пор до наших дней дожило. И на CCNA рассказывают только про этот классический режим, тот, который используется для совместимости с IGRP. Но вообще-то у Cisco довольно давно есть EIGRP, который называется EIGRP Named Mode. Сам протокол — RTP, DUAL, обмен маршрутами — всё там точно то же самое. Это один и тот же движок, который будет обмениваться маршрутами,

который будет управлять таблицей топологии, который будет фильтровать, редистрибутить. Всё это делает один и тот же процесс. Но этот процесс нужно настраивать. И настраивать его можно либо в классическом режиме, так как мы это уже умеем делать, либо в новом режиме, в кавычках «новом», потому что этому режиму уже довольно много лет. Он называется Named Mode. В чём смысл этого Named Mode? Вместо того, чтобы настраивать EIGRP в разных кусках конфига, можно его настроить в одном месте. У вас есть блок, который отвечает за маршрутизацию. В этом блоке есть контекст роутера EIGRP. И в этом контексте роутера EIGRP всё, что необходимо для настройки EIGRP, будет храниться. Эта штука намного более удобная. В принципе, это только вопрос именно удобства использования. Это не добавляет каких-то принципиально новых фич. Сам движок, ещё раз повторю, остаётся тот же самый. Некоторые вещи, однако, можно сделать только в Named Mode, потому что, как я уже сказал, это более новый режим.

И когда появляются более новые фичи, нужно внедрить команды в configure terminal. Естественно, в новом режиме, в Named Mode. И если Cisco будет достаточно заинтересована, она может добавить эти команды и в старый, классический режим. Существуют некоторые штуки, которые можно сделать только в новом режиме. Cisco поленилась в старый классический режим их добавлять. Например, это касается продвинутой криптографии. EIGRP может для подписывания сообщений использовать не только хэш MD5. Мы с вами закончили предыдущее занятие как раз на том, что можно подписывать сообщения хэшами. Но в случае с Named Mode эти хэши могут быть продвинутыми. Они могут быть SHA-256. Вы не можете настроить SHA-256 в EIGRP в классическом режиме, а в Named Mode можете. Просто потому, что эта фича уже новая, и когда она появилась, инженеры-программисты могли добавить её только в одно место или в оба режима — и классический, и новый.

Они поленились, сделали только в новом. Давайте разберём, как это всё будет выглядеть. Named Mode будет объединять в себе и настройку EIGRP для IPv4, и настройку для IPv6. Как уже было сказано, EIGRP сам не зависит от того, какие маршруты вы в него вбрасываете для репликации. Он что для IPv4, что для IPv6 будет передавать сообщение «у меня есть вот такая сетка», и дальше всё, что происходит, уже не будет зависеть от этой сетки. Будет зависеть только от свойств, с которыми известна эта сеть. От bandwidth, delay, reliability, load и всего остального. И это не зависит от того, IPv4 у вас маршрут или нет. Если вы передаёте IPv4-маршрут, говорите: я знаю его с вот таким bandwidth, вот таким delay. И вы передаёте IPv6-маршрут, и говорите: я его знаю с вот таким bandwidth, таким delay. Для EIGRP по сути разницы нет, как его обрабатывать, как выбирать наилучший маршрут, как фильтровать маршруты, как редистрибутить их, как суммировать.

Поэтому фактически можно говорить, что у нас работает единый блок, который называется модуль IGRP2, который не зависит от конкретного сетевого протокола. И к нему есть, как в конструкторе, плагины. Один из плагинов — это EIGRP для IPv4, и другой плагин — это EIGRP для IPv6. Это именно возможность передавать маршрут определённого типа, или ещё иногда называют address family. В Named Mode мы действительно работаем в одном, в кавычках, процессе EIGRP, хотя на самом деле процессы будут разные. И в рамках этого процесса мы просто настраиваем адресное семейство. Говорим: у нас есть адресное семейство IPv4, и даём конфигурацию IPv4-адресов. Есть адресное семейство IPv6, оно будет посвящено именно IPv6. И всё это в единой логике, в одном и том же месте настраивается. Если вы хотите посмотреть, как у вас EIGRP работает, вы просто говорите: покажи мне секцию EIGRP в конфиге.

И он вам целиком всё выдаёт, что касается именно только EIGRP, для IPv4 или для IPv6, не суть важно. Named Mode — это фактически просто другой способ конфигурации. При этом функции, которые в EIGRP работают, они все те же самые остались. Что классический режим, что именованный режим — настраивает одно и то же. Просто настраивает это с помощью разных команд. Named Mode — он более логичный, более согласованный способ, потому что он уже не тянет за собой все эти legacy, архаичные вещи, которые были специфичны для IGRP. Там уже есть какие-то более новые фичи, которые просто в классическом режиме решили не делать, решили сэкономить усилия. Вы можете взять и перевести конфиг классического режима в Named Mode. Есть просто командочка, которая говорит: собери мне всю конфигурацию, которая в классическом режиме сейчас есть, и сделай из неё конфигурацию Named Mode.

Это очень удобная вещь, если у вас в сети Cisco используется с EIGRP, работает она неплохо и сбоев на моей памяти никогда не давала. Я думаю, что ошибиться там с её использованием очень сложно. Помимо того, что в Named Mode у вас Cisco начинает конфигурироваться по-новому, она перестаёт прикидываться, что работает в режиме типа IGRP. Она уже перестаёт скрывать то, что использует коэффициент к метрике K6. Любые Cisco сегодня передают в апдейтах коэффициент K6. Любые Cisco сегодня передают wide-метрики. Но если вы будете работать в классическом режиме, вы будете видеть, как будто используете метрики всё-таки классические, а не широкие. В Named Mode Cisco уже перестаёт прикидываться, что она старая, и говорит: я действительно передаю широкие метрики, всё честно. И из того, что в Named Mode можно сделать отличного от классического режима, это как раз включить аутентификацию SHA.

Вот пример того, как выглядит блок конфигурации классического режима слева. У нас есть настройки интерфейса. На этом интерфейсе есть какие-то фичи, характерные для самого интерфейса. Например, IP-адрес висит. У нас есть IP-адрес, IPv6-адрес, IPv6 enable. Плюс мы на этом интерфейсе даём какие-то настройки, характерные для EIGRP. Например, IP summary address прописывается там. Например, таймеры прописываются на интерфейсе. Например, пароли прописываются на интерфейсе. Если всё это прописывать на интерфейсе, то мы должны будем помнить, что у нас EIGRP прописан на интерфейсе тут, прописан на интерфейсе здесь, прописан там. Мы в конфигурации должны будем знать, в каких конкретно свойствах интерфейса мы где что прописали. Прописываем summary address, прописываем включение split horizon, прописываем включение всяких ещё вещей на туннельном интерфейсе.

Судя по всему, у нас как раз DMVPN, и мы говорим: нам нужно выключить split horizon здесь, split horizon здесь. Конфигурация по факту раскидана будет по многим местам running config. Причём есть ещё отдельный блок, отвечающий за EIGRP IPv4, отдельный блок, отвечающий за EIGRP IPv6. В некоторых случаях конфигурация EIGRP для IPv4 и для IPv6 будет различаться не то чтобы сильно, но всё-таки различия есть. Такое бывает. Если мы хотим использовать именованный режим, то у нас всё будет храниться в одном месте. Контекст будет называться router EIGRP, так же как для IPv4, но дальше указывается имя. Почему называется Named Mode? Потому что процесс EIGRP получает уже не номер автономной системы, а имя. Мы говорим, например: у нас есть имя CCNP, имя процесса EIGRP. Дальше в рамках этого процесса мы запускаем отдельный модуль, посвящённый IPv4, и отдельный модуль, посвящённый IPv6.

Контекст будет address-family ipv4 unicast — это адресное семейство IPv4 unicast, autonomous-system, дальше даём номер автономной системы. То, что мы запускали с вами — 65 тысяч. Отдельно для IPv6. Пакеты, которые будут бегать, они будут бегать совершенно независимо от IPv4, поэтому для адресного семейства IPv6 unicast мы прописываем свой номер автономной системы. Он может быть таким же, как и в IPv4, или другим — они никак не связаны напрямую между собой. Дальше внутри каждого контекста мы прописываем все те свойства, которые раньше прописывались в настройке роутера. Здесь у нас был EIGRP router-id, мы его здесь прописываем — EIGRP router-id. Мы прописывали passive-interface default. Здесь с passive-interface конфигурация чуть-чуть поменялась. Все настройки, которые характерны для интерфейса, будут находиться в контексте AF-interface. Например, здесь у нас был в настройке интерфейса EIGRP IP summary address для IPv4.

Оно переехало в AF-interface — субконтекст контекста address-family ipv4 unicast. Вот у нас address-family ipv4 unicast. Субконтекст AF-interface GigabitEthernet 0/0. И здесь прописывается summary address. Здесь же прописывается passive-interface, если мы хотим сказать, что этот интерфейс должен быть пассивным. Или, если он не должен быть пассивным, то мы указываем no passive-interface, а passive-interface прописываем в AF-interface default. Это вообще все интерфейсы. Почему address-family ipv4 unicast? Потому что это действительно unicast-овый трафик для IPv4. Мы с мультикастом здесь не работаем. Мультикастовая таблица, если вдруг вам это интересно, она будет использоваться для того, чтобы понимать, где находятся источники мультикастового маршрутизируемого трафика. Если у вас есть большая маршрутизируемая сеть, какие-нибудь роутеры между собой связаны каким-то хитрым образом, и у вас где-то появляется источник мультикастового трафика,

он начинает вещать мультикаст, роутер начинает мультикаст маршрутизировать по всем частям сети. И вам нужно будет принимать решение, откуда вы принимаете мультикастовый трафик. Например, одна копия мультикастового трафика прошла так, другая — вот так. Вам нужно будет иметь в таблице маршрутизации указание, где брать источник. Источник — это юникастовый IP-адрес, но он вещает мультикастовый трафик. Поэтому таблица ipv4 multicast будет хранить на самом деле юникастовые IP-адреса, но использоваться она будет только для проверки мультикастового трафика. Мы с вами это сейчас не трогаем никоим образом. Мы просто говорим, что работаем с юникастовыми таблицами. Это IPv4 unicast и IPv6 unicast. Вот это «unicast» — это не про то, что мы с соседями будем юникастом обмениваться, это про то, какую таблицу маршрутизации наш EIGRP в итоге будет пополнять.

У роутера на самом деле много таблиц маршрутизации. Есть таблица для IPv4, есть таблица для IPv6, юникастовый, мультикастовый трафик. Есть ещё отдельная именно мультикастовая таблица для пополнения… Короче, куда девать мультикаст? Как в IPv4 у нас есть юникастовая таблица, которая показывает, куда направлять юникастовый трафик, так есть такая же таблица для мультикаста — куда направлять мультикастовый трафик. Она совсем по-другому выглядит, не так, как в юникасте, там совсем другие концепции используются. Но тем не менее это всё равно таблица маршрутизации, и тоже её можно с помощью хитрых механизмов пополнять. Поэтому здесь мы работаем с таблицей IPv4 для обычного юникастового трафика. Здесь мы работаем с IPv6 для обычного юникастового трафика. Дальше. Все настройки, которые у нас есть, хранятся в контексте AF-interface,

если они относились к интерфейсу. У нас здесь был интерфейс GigabitEthernet 0/0, у него был IP summary address для IPv4. Здесь мы говорим: GigabitEthernet 0/0, summary address. Дальше указываем сетку. Если в классическом режиме здесь был совершенно дурацкий синтаксис — мы указывали IP summary address, дальше EIGRP 1, с какой автономной системой мы работаем. А чаще всего один интерфейс у вас в одну и ту же автономную систему смотрел, поэтому эта штука на самом деле была абсолютно бесполезной в большинстве ситуаций. И потом указывался IP-адрес сети и маска для агрегатной сети, то есть во что мы склеиваем кучу мелочёвки, если вдруг у нас эта мелочёвка есть. Здесь в настройке AF-interface прописывается уже просто логичная команда summary address 10.0.0.0/24. Она стала логичной, стала компактной, и запомнить её на самом деле намного проще. Если вы с Named Mode работаете, и читать конфиг намного удобнее, и по первому взгляду просто понимать, про что идёт речь, тоже можно легко.

Это просто новый способ конфигурировать железку, конфигурировать EIGRP, при котором у вас всё хранится в одном месте. У этого режима есть ряд особенностей. Особенности заключаются в том, что поведение железки в части конфигурации, то есть дефолтные значения, у Named Mode немножко отличаются от дефолтных значений для классического режима. Если вы включаете Named Mode, то в части IPv6 особенно будут очень интересные особенности. Мы сейчас их разберём. В Named Mode будет некоторое количество контекстов, и эти контексты нужно будет запомнить. В самом глобальном контексте фактически вы можете только сослаться на какие-то совсем общие значения. Вы, например, можете в контексте самого роутера сказать, что router-id у вас для всех адресных семейств будет один и тот же.

Если вы запускаете адресное семейство IPv4, адресное семейство IPv6, у них будет одинаковый router-id, если вы зададите его в глобальном контексте EIGRP Named Mode. Если вы хотите работать с каким-то конкретным сетевым протоколом, то есть IPv4 или IPv6 — вот хороший пример: вы хотите сказать, что в IPv4 наш роутер должен быть stub, то это как раз удобно делать в контексте адресного семейства. Вряд ли вы захотите, чтобы некоторые настройки применялись ко всем адресным семействам одновременно. Либо они могут, в принципе, теоретически даже не применяться. Некоторые вещи вы не можете указать в адресном семействе IPv6, которые относятся к IPv4. Если вы хотите сказать, что всё, что относится к нашему роутеру, исключительно к IPv4-семейству, мы хотим сделать — это всё как раз в контексте address-family. Можно запустить address-family IPv4, address-family IPv6.

И, если захотите, IPv4 с VRF каким-нибудь, VRF client1. Дальше. Внутри адресного семейства можно сделать какие-то настройки: можно сказать, что мы будем stub, можно сказать, что у нас router-id будет какой-то отдельный, если мы хотим на разных адресных семействах иметь разный router-id. Можно и перейти в контекст AF-interface. Есть AF-интерфейсы, те, которые отвечают за физические интерфейсы: GigabitEthernet 0, Tunnel 0. И есть такой виртуальный интерфейс, который называется AF-default. Если вы пропишете что-то в AF-default, то оно будет применяться ко всем интерфейсам, если только в настройке конкретного интерфейса не будет в явном виде прописано что-то, отменяющее действие того, что прописано в AF-interface default. Здесь применяются настройки, которые именно для конкретного характерного интерфейса: summary address, таймеры, пароли, явки.

Всё здесь как раз хранится. И есть ещё субконтексты, относящиеся к address-family. В address-family есть субконтексты AF-interface и есть субконтексты, отвечающие за манипуляции с маршрутами. Если вдруг мы захотим какие-то вещи типа редистрибуции сделать или что-то ещё, как-то поиздеваться над маршрутами, то это делается в контексте топологии. Вы не увидите в настройке адресного семейства IPv4 или IPv6 команды redistribute. Надо перейти в контекст топологии, сказать, что нас интересует topology base, и там уже с маршрутами мы будем работать. Опять же, это красивая идея у Cisco была — сделать так называемый MTR, Multi-Topology Routing, который отличал маршруты для трафика разных классов, чтобы можно было, например, ту же телефонию отпускать по отдельной таблице. Можно было сказать: у нас есть таблица main,

в этой глобальной таблице мы говорим просто про обычный unicast-трафик, но этого обычного unicast-трафика может быть несколько разных типов: голосовой трафик, видеотрафик, трафик управления. Они могут ходить по разным таблицам маршрутизации. Всё это не взлетело, и у нас есть только topology default. Как настраивается EIGRP? Если мы говорим, что у нас есть IPv4 EIGRP, то нужна команда network. Казалось бы, первое, от чего стоило бы отказаться, — это команда network. Но в Named Mode от неё решили не отказываться, и это очень печально. Заходим в контекст router EIGRP, переходим в субконтекст address-family ipv4 unicast, указываем номер автономной системы и указываем команду network. Тем самым включаем EIGRP на интерфейсах. Работает всё точно так же.

Можно указать network 192.168.0.1 с маской 0.0.0.0. Или, аналогичная концепция есть и в Classic Mode, вы можете указать network просто 0.0.0.0 и тем самым включить EIGRP на вообще всех интерфейсах. Команда опасная, но в простых сетях, в принципе, можно её использовать. Только не забыть passive-interface выставить и закрыться, чтобы вас потом не хакнули. И тем самым вы включаете EIGRP на всех интерфейсах, все connected-сетки у вас попадают в анонс. И всеми сетками начинаете обмениваться. Если у вас есть желание сказать, что вы включаете EIGRP на всех интерфейсах командой network 0.0.0.0, но по факту EIGRP не на всех интерфейсах вам нужен, не на всех интерфейсах вы хотите, чтобы EIGRP включался и анонсировал сетки в таблицу топологии,

то вы можете на конкретном интерфейсе сказать shutdown. Например, мы можем сказать shutdown на GigabitEthernet 0/0 интерфейсе, тогда на этом интерфейсе EIGRP включаться не будет, несмотря на то, что network 0.0.0.0 нам говорит, что это нужно сделать. В EIGRP в Classic Mode мы не могли сказать, что интерфейс попадает под действие команды network, но он нам не нравится, мы не хотим там на самом деле EIGRP включать. Здесь можно: вы можете сказать network 0.0.0.0, типа включи на всех, а потом сказать на конкретном интерфейсе — нет, на этом не включай. Или можно сказать AF-interface default, команду shutdown, тогда у вас на всех интерфейсах EIGRP по факту не включается, несмотря на действие команды network 0.0.0.0. Но вам же всё-таки надо, чтобы EIGRP где-то включился. Вы заходите на интерфейс GigabitEthernet 0/0 и говорите: тут мы хотим включить EIGRP, или здесь мы тоже хотим включить EIGRP. В настройке AF-interface говорите no shutdown. В чём смысл этой штуки? Казалось бы, немножко грязная какая-то история, что мы сначала включаем, потом выключаем, потом анти-выключаем.

Смысл вот в чём. У нас есть два аплинка, как правило, на роутере и куча интерфейсов логических или физических, которые смотрят на клиентов. Мы на этих всех клиентских интерфейсах можем не хотеть включать EIGRP, а можем хотеть. Если мы хотим на всех интерфейсах действительно включить EIGRP, то Network 0.0.0.0 нам будет довольно полезно. Если мы по факту хотим управлять EIGRP на уровне отдельного интерфейса, просто зайти на интерфейс и сказать, на этом интерфейсе работаем, на этом интерфейсе работаем, на всех остальных не работаем, то такой хак, при котором мы объявляем Network 0.0.0.0, а потом все интерфейсы shutdown, он на самом деле позволяет нам довольно гибко управлять поведением EIGRP на каждом отдельном интерфейсе. Просто заходим и говорим, на этом интерфейсе no shutdown, на этом интерфейсе no shutdown. Не интерфейс сам физически no shutdown, а EIGRP на этом интерфейсе no shutdown. И у нас получается, на этом EIGRP включили, на этом EIGRP включили, а дальше, например, connected-сетки редистрибутнули в EIGRP, у нас получились внешние маршруты,

и с этими внешними маршрутами уже довольно просто можно будет работать. Ещё одна штука, которую можно на AF-интерфейс прописывать — это настройки аутентификации. Если у вас есть классический режим, то в классическом режиме мы должны были входить отдельно на каждый интерфейс, где у нас были соседи, и говорить, с тобой мы должны дружить по хэшам MD5, и ключевая цепочка должна быть такая. Потом заходили на другой интерфейс, говорили, с тобой мы должны дружить по MD5, ключевая цепочка здесь будет такая. На каждом интерфейсе вы должны были отдельно две команды — IP authentication EIGRP mode — прописывать именно отдельно на каждом интерфейсе. Здесь можно просто сказать, что на любом интерфейсе, который у нас работает в EIGRP, мы прописываем стандартные настройки, что мы хотим использовать authentication mode, что мы хотим использовать ключевую цепочку. И за счёт того, что есть ключевые цепочки, переход на новый ключ будет осуществляться без особых проблем.

Мы заранее планируем момент, когда у нас происходит смена ключей, мы заранее прописываем на все роутеры новые ключевые цепочки. У нас все роутеры просто в час X по заранее запрограммированным конфигурациям переходят на новые ключи. Это не то что мы, если бы должны были прямо именно пароль в явном виде прописывать на всех роутерах, — не то что мы на одном роутере прописали, у нас связь отвалилась. Нет, здесь как раз очень удобно, что за счёт ключевых цепочек мы можем действительно на всех роутерах одновременно сказать, что пароль по умолчанию у нас везде вот такой, а сменяться этот пароль будет по умолчанию тогда-то. В IPv6 аналог команды Network 0.0.0.0 действует по умолчанию. Запомните, пожалуйста, этот момент. Это очень важный момент. По умолчанию EIGRP в именованном режиме автоматически включает EIGRP на всех интерфейсах, где у вас есть IPv6. У вас есть интерфейс, на котором вы включили IPv6 enable. Поздравляю, на нём работает EIGRP.

Поэтому этот хак, где мы в AF-интерфейс заходим, в AF-интерфейс default и делаем shutdown, — в IPv6 это фактически обязательное явление. Мы, если на каком-то интерфейсе не хотим использовать EIGRP, мы должны будем сказать на этом интерфейсе либо shutdown в явном виде, либо в AF-интерфейс default прописать shutdown, что на всех интерфейсах IPv6 EIGRP не должен работать. А потом уже включать отдельно на тех интерфейсах, где нам действительно это будет нужно. Это важный момент. Это важный момент на экзамене. Это важный момент в жизни, если вдруг вы будете с EIGRP в named mode работать. Просто появление IPv6 на интерфейсе у вас вызывает попадание connected-сети из этого интерфейса в анонс. Почему это так по умолчанию сделано? Именно потому, что, во-первых, в именованном режиме вы можете использовать аутентификацию по умолчанию. Поэтому, если вы это делаете в соответствии с рекомендованными практиками, то, что у вас EIGRP где-то включится и даже, возможно, начнёт посылать hello-пакеты, это не вызовет проблему.

Потому что даже если злоумышленник захочет с вами подружиться, он к вам придёт и скажет, я тебе тоже хочу ответные hello-пакеты посылать, он не знает пароля, поэтому он с вами соседские отношения не установит. И плюс на транзитных интерфейсах у вас обычно IPv6 маршрутизируемых адресов нет, у вас там только link-local. Поэтому то, что link-local где-то на транзитном интерфейсе появляется — ну и фиг бы с ним. Ну и появился. Ничего нового в анонс всё равно не попадёт. Поэтому поведение по умолчанию именно такое, что EIGRP по умолчанию работает на всех IPv6 интерфейсах, как будто мы прописали команду Network 0.0.0.0. Команды network в IPv6 нет. Если вы не хотите работать по умолчанию на всех интерфейсах, выключайте все интерфейсы в AF-interface default. Что можно ещё сделать в AF-interface? Прописать shutdown, no shutdown — понятно. Аутентификацию — понятно, на слайде есть. Passive-interface — естественно, если вы включаете по умолчанию EIGRP на всех интерфейсах, вы захотите passive-interface прописать в AF-interface default.

Split Horizon и Next-Hop-Self для DMVPN будет очень полезно. Summary address и hello-interval, hold time — это мы проходили, аналог команд, который был в классическом режиме. Здесь сами команды довольно говорящие. Понятно, что они делают. Удобно всё это прописывать в AF-interface default. Один раз прописали, и дальше просто говорите, на этом интерфейсе работаем, на этом интерфейсе работаем, и всё. Когда EIGRP в именованном режиме у вас запускается, он регистрируется в качестве источника маршрутной информации, и show IP protocols покажет, что у нас в IPv4 таблицу маршрутизации вбрасывает свои данные протокол EIGRP с автономной системой 650001. Если у нас такая автономная система. Дальше показывается: EIGRP IPv4, работающий в именованном режиме с именем экземпляра CCNP.

Адресное семейство IPv4 с автономкой 650001. Здесь уже Cisco перестаёт прикидываться, что она тупая дура из начала 90-х. Она уже говорит, что действительно K6 у меня есть. В классическом режиме, если вы используете EIGRP, то там в выводе показывается только K1, K2, K3, K4, K5. K6 там нет, и он предполагается по умолчанию 0. Вы не можете его поменять в классическом режиме. Здесь вы можете его поменять, и он будет влиять на расширенные параметры — на джиттер и энергию, если таковые будут передаваться в метрике. Дальше. Поскольку K1, K2, K3, K4, K5, K6 используются с широкими метриками — wide metric — у нас эти метрики будут достаточно большие. EIGRP-шная computed distance, или EIGRP-шная метрика маршрута, получается 8-байтовая.

А в таблицу маршрутизации 8-байтовая метрика не влезет. Когда у нас EIGRP взял, получил маршрут от соседа, посчитал computed distance через этого соседа, выяснил, что он хороший, дальше у него возникает вопрос — надо бы его в RIB добавить, в таблицу маршрутизации. Но computed distance у него 8-байтовая, а в таблицу маршрутизации влезет что-то только 4-байтовое. Поэтому надо каким-то образом из 8-байтового значения получить 4-байтовое. И по умолчанию делается очень просто. У вас есть делитель, на который надо разделить метрику, чтобы она влезла в таблицу маршрутизации. Учитывая, что при каких-то более-менее разумных значениях K1, K2, K3, K4, K5, особенно со значением по умолчанию, метрика сильно большой получиться не может. Метрика будет в любом случае меньше, если мне память не изменяет, двойки в 48-й степени.

Получается, что если вы разделите её на 128, она у вас почти всегда будет влезать в таблицу маршрутизации, в 32 бита. И какие-то катастрофически большие метрики будут получаться только в случае, если у вас все интерфейсы очень медленные, а задержки на них максимально большие. В реальности вы будете работать с интерфейсами, которые достаточно быстрые, и задержки на которых будут достаточно маленькие, поэтому в подавляющем большинстве ситуаций метрика всё-таки будет влезать в 32 бита. Но после того, как вы делите на 128, она тем более будет влезать в 32 бита и проблем вызывать не будет. Характерные метрики для EIGRP в именованном режиме будут порядка сотен миллионов. Они редко будут переходить за миллиард. В классическом режиме, когда мы работали с классическими метриками, у нас характерные метрики были десятки, сотни тысяч. Для совсем быстрых интерфейсов там можно было исчисляться тысячами метрики.

Здесь они уже исчисляются миллионами. Но тем не менее всё равно получается, что миллион в таблицу маршрутизации с 32-битной метрикой влезть вполне может. Так, дальше. Router ID. Здесь всё понятно. Я уже говорил про Router ID в EIGRP. Уникальным он требуется, что прям обязательно-обязательно был уникален, только для ASBR. Если вы вкладываете в EIGRP какие-то внешние маршруты, для остальных роутеров он не играет никакой особой роли. Хорошо, если он у вас уникальный. Если вдруг он не уникальный на разных роутерах, но они не являются ASBR-ами, на это можно забить. Это не OSPF, где действительно требуется уникальность. И дальше рассказывается про топологию 0. Это просто обычная нормальная топология, обычная нормальная таблица маршрутизации, с которой мы и будем работать. В этой топологии мы назначаем таймер Active Timer — по умолчанию как раз 3 минуты, 180 секунд.

Административное расстояние, если вдруг надо будет, — внутреннее 90, внешнее 170. Как вы понимаете, значения по умолчанию. В таблицу маршрутизации вбрасываем до 4 маршрутов. Все маршруты будут одинаковые. И прямо сейчас у нас в таблицу маршрутизации EIGRP вбросил один маршрут. Автоматическое суммирование сетей можно, конечно, включить, но по умолчанию всё-таки оно выключено. И routing for networks вам показывает по привычке, какие команды network вы используете. Здесь уже не показывается, на каких интерфейсах EIGRP вы включили, на каких нет. Но для этого есть отдельная команда. Show IP protocols немножко потерял в информативности. Ну, не больно-то и хотелось, как говорится. После того как вы запустили EIGRP в именованном режиме, вы можете работать как с привычными вам командами, которые покажут списки соседей. Например, show IP EIGRP interfaces, show IPv6 EIGRP interfaces. Они тоже работают. Или вы можете использовать новый синтаксис, который будет специально предназначен для того, чтобы подчеркнуть, что EIGRP он один, он большой,

а дальше у него есть подмодуль — адресное семейство IPv4 или адресное семейство IPv6. Команды дают абсолютно идентичный вывод. Но единственное, что если у вас работает в именованном режиме EIGRP, то чуть-чуть меняется первая строчка с легендой. Раньше она показывала EIGRP IPv4 в скобочках AS 650001, а сейчас она меняется, показывает вам именованный экземпляр, и номер автономки показывают уже в конце. Сам вывод при этом абсолютно идентичен. У нас здесь есть интерфейсы, здесь у нас есть пиры, с которыми мы на этих интерфейсах подружились, усреднённое время туда-обратно. Всё то же самое. Равным образом можно посмотреть на нейборов, которые у нас установились. Номер нейбора, IP-шник, интерфейс, hold time, uptime. Среднее время туда-обратно, retransmission timeout, queue count. Всё абсолютно идентично. В таблице топологии EIGRP будет держать всё то же самое,

потому что таблица топологии не зависит от того, как вы настраиваете вашу Cisco. Она одна. И в легенде показывается название экземпляра. Если вдруг вы захотите, вы можете посмотреть детальную информацию про какой-то конкретный маршрут: show EIGRP address-family IPv4 topology, и дальше вы указываете, какой конкретный маршрут вас интересует. И здесь будет немножко интересно. Интересно будет в том, что Cisco перестаёт прикидываться старой. Она уже начинает работать по-честному. Она начинает показывать именно те широкие метрики, которые она действительно посчитала. И показывается, что метрика у нас будет вот такая большая. Это computed distance, это у нас reported distance. И здесь видите — 327 миллионов против 450 с копейками миллионов. Bandwidth в широких метриках передаётся, естественно, в килобитах.

Задержка передаётся в пикосекундах. Уже не в десятках микросекунд, а в пикосекундах. И она становится такой большой. Это — раз, два, три — 6 миллиардов пикосекунд. Это на самом деле 6 миллисекунд. Reliability полная. Она не изменилась. Load тоже минимальная, она тоже не изменилась. MTU не изменилась, hop count тоже не изменился. И originating router показывается — Router ID того, кто нам такой маршрут прислал. Обратите внимание на синтаксис. В старом синтаксисе можно использовать команды show IP EIGRP topology. Если вдруг хотели все маршруты, включая non-successors, указывали дополнительный ключик all-links. В новом синтаксисе указываем show EIGRP, дальше указываем address-family — либо IPv4, либо IPv6 — и потом topology all-links.

Это одна и та же команда. Просто у нее два разных режима, два разных способа ее вбивания, в зависимости от того, что для вас будет важнее. Если для вас важнее, что это IPv4, и у него есть EGRP, или IPv6, и у него есть EGRP, то вы используете старый синтаксис. Если вы хотите сказать, что EGRP один, а дальше у него есть подмодуль, который работает с IPv4, подмодуль, который работает с IPv6, то вы можете использовать новый синтаксис. В зависимости от того, что вы считаете более логичным или к чему вы привыкли. Обе команды будут работать. По поводу того, что Cisco может вам сконвертировать старый конфиг Classic Mode в Named Mode. Очень полезная штука, потому что она позволяет переконвертировать конфиг без прерывания работы. У вас работает Cisco, через нее ходит боевой трафик. Если вы начнете ее выводить из обращения, убивать старый конфиг, набивать конфиг заново с нуля, то у вас трафик через нее ходить перестанет. Но вы можете сказать замечательную штуку.

В настройке роутера команда EGRP upgrade CLI CCNP, здесь название экземпляра, которое у вас будет. Вот конфиг роутера в Classic Mode. У вас был старый режим настройки, вы в него зашли, сказали EGRP upgrade CLI, даете новое название. И она берет старую классическую настройку, которая была запущена с роутера EGRP 650001, и переделывает, переколбашивает вам конфигурацию так, чтобы у вас получился именованный экземпляр. Роутер EGRP CCNP. Вас спрашивают, точно ли вы хотите это сделать. Вы говорите, да, хорошо, система запускается. И показывается, что у нас все хорошо, у нас действительно конфигурация поменялась. Делаем show running config с секцией, например, EGRP. И видим, что классический режим ушел. Вместо него появился новый режим EGRP CCNP.

Все команды, которые у вас там были в настройке, они сохранились. Команды network сохранились, команды по редистрибуции сохранились. Все настройки из интерфейсов переехали в настройки AF interface. Все настройки, которые были посвящены стабам, не стабам, они соответственно здесь тоже переехали. В адресное семейство IPv4 нам показывается, что EGRP, stub, summary, connected, static. Такая конфигурация там была в IPv4 в классическом роутере. Оно переехало в именованный экземпляр, в автономку для IPv4. Штука замечательная. Единственное, что нельзя с ее помощью сконвертировать в один контекст и IPv4, и IPv6. Если у вас есть железка, на ней запущен IPv4 роутер EGRP и IPv6, у вас два разных получается контекста. Вы можете сказать, давайте сконвертируем IPv4 в CCNP.

А IPv6 вы можете сказать, давайте сконвертируем в CCNP v6. И потом просто сказать, что мы должны будем чем-то пожертвовать, мы прибьем CCNP v6, а всю конфигурацию AF, адресное семейство IPv6 Unicast, просто скопипастим в контекст CCNP. Не получится взять и в один именованный экземпляр запихать и то, и другое. Но тем не менее даже это лучше, чем ничего. По поводу киллер-фичи Named Mode — когда вы будете книжку читать, вам будут рекомендовать Named Mode в первую очередь из-за нее. Это использование криптографической аутентификации или хэшей SHA. Вы будете использовать пароли прямо в явном виде на интерфейсе. Получится, что у вас будет два инстанса в Named Mode. Да, будет два инстанса. И что? Раньше было два инстанса, и сейчас будет два инстанса. Если вам хочется один инстанс, то надо будет взять и скопипастить конфиг одного инстанса в другой.

Они друг другу не противоречат. По поводу SHA-256. Если вы будете использовать его, то вы должны будете использовать пароли, прописанные в явном виде. Нельзя будет использовать ключевые цепочки. Это значит, что обмен ключами, если вдруг смена ключей, она будет происходить не так легко. Вы должны будете прописать в настройке интерфейса команду Authentication Mode. Дальше указываете такую штуку. HMAC SHA-256, что вы будете подписывать сообщение с помощью Hashed Message Authentication Code. Выбираете SHA-256 и указываете просто пароль в явном виде. И соответственно, если вы это делаете, у вас связь разваливается. Потом с другой стороны то же самое делаете, связь поднимается. С ключевыми цепочками сделать это не получится. Поскольку EGRP в каждом сообщении, которое подписано паролем, будет передавать номер ключа,

то соответственно, если вы используете эту штуку, то номер ключа подписывается нулевой. Вы отсылаете сообщение, говорите, у меня номер ключа 0 и хэш от содержимого пакета плюс пароль от CCK123. Сказать, что я рекомендую использовать SHA-256, не могу, именно потому что процедура обновления ключа будет обязательно Disruptive. Вы обязательно будете терять связь с соседним роутером, только если вы прям одновременно не нажмете Enter на обоих роутерах и не обменяетесь ключами одновременно. Но если вы в AF interface Default прописываете эти новые ключи, то у вас по-любому связь развалится. С ключевыми цепочками было бы круче, но далеко не все можно сделать с помощью ключевых цепочек, к сожалению. Вот такой замечательный режим. Я рекомендую вам им пользоваться. Если вы хотите, вы можете использовать Named Mode с обычной аутентификацией с помощью MD5.

Это хороший способ. Плюс он позволяет довольно гибко настраивать интерфейсы, и все эти настройки будут храниться в одном месте. Не надо будет бегать по конфигу, по отдельным контекстам, понимать, где у нас какие настройки относятся к EGRP, какие не относятся. И если вдруг вы захотите удалить настройки EGRP, то Named Mode будет удалить намного проще. Потому что, если у вас Classic Mode, вы можете сказать No router EGRP 65000.01, но у вас хвосты в настройке интерфейсов все равно останутся. В Named Mode мы просто говорим, удали нам контекст EGRP, и все. И у нас вся конфигурация уходит из таблицы. Вот такая штука.