EIGRP для IPv4

Начнем мы с EGRP для IPv4. На самом деле EGRP умеет маршрутизировать и IPv6, но настройка там практически та же самая, что для IPv4, поэтому мы расскажем ее отдельным модулем, но это будет достаточно компактный модуль, надо заметить. А EGRP для IPv4 мы сейчас рассмотрим достаточно детально, потому что многие концепции, которые будут работать здесь, будут работать и в IPv6 тоже. Если мы хотим включить EGRP на устройстве, то нам понадобится некоторым образом проверить, непротиворечиво ли мы настроены с соседними устройствами. Начнем мы с того, что EGRP проверяет, что соседние устройства, с которыми гипотетически нам придется работать, настроены той же самой командой людей, что и наш роутер. И для этого будет использоваться так называемый номер автономной системы. Это абсолютно произвольное число, и оно должно совпадать на всех роутерах,

которые будут пытаться гипотетически дружить между собой. Если номер автономной системы на соседних роутерах не совпадает, то они не смогут установить соседство, не смогут обменяться маршрутами, и взаимодействие будет невозможным. Поэтому мы просто должны выбрать некое число, которое будет на всех роутерах одинаковое. Оно будет называться номер автономной системы. Здесь в качестве примера выбрано число 650001. Никакой конкретной причины, почему это число было бы лучше, чем другое, нет. Но выбрано оно было по достаточно дурацкому принципу, что в другом протоколе, никакого отношения к EGRP не имеющем, протоколе BGP, этот номер принадлежит диапазону так называемых частных автономных систем. Для EGRP это абсолютно никакого отношения не имеет. В EGRP мы можем выбирать абсолютно любой номер, который захотим. Выбран был именно такой. Если вдруг, гипотетически, вы используете и BGP, и EGRP, вы, конечно же, можете взять и выбрать в качестве номера автономной системы EGRP

такой же номер, как и вы используете в BGP. Можете это сделать, а можете и не делать. Далее. После того, как мы выбрали некий номер автономной системы, который у нас будет одинаковый на всех роутерах, нам нужно будет запустить сам процесс динамической маршрутизации EGRP. Делается это с помощью команды router, дальше EGRP, и тот самый номер, который мы выбрали. Эта команда делает два действия. Первое действие — запускается сам процесс, у нас запускается сам движок EGRP. А второй момент — у нас приглашение к вводу меняется, становится config-router, и мы внутри этого контекста config-router можем настраивать работу нашего экземпляра EGRP. В принципе, если захотите, вы можете на одном роутере запустить 2, 3, 5, 10 разных контекстов EGRP с разными автономками, но делать это приходится очень и очень редко, поэтому по факту вам этого делать не придется никогда.

В этой ситуации вы всегда будете работать с роутером EGRP с одной и той же автономкой. Дальше. Внутри этого контекста можно будет сделать много всяких разных штук, но основная штука, которая нас будет интересовать, это включить работу EGRP на некоторых интерфейсах. По умолчанию, когда вы запускаете процесс EGRP, он просто повисает в вакууме, но дальше нам нужно будет сказать, что на некоторых интерфейсах мы хотим по EGRP работать. Например, у нас здесь есть на роутере R1 интерфейс FastEthernet 0.0, FastEthernet 0.1, FastEthernet 0.2, которые смотрят во внутреннюю сеть. Например, у нас здесь Distribution Switch стоит, у него отдельные VLAN. Это именно физические интерфейсы, которые смотрят в отдельные сети. Может быть, субинтерфейсы будут. FastEthernet 0.0.1, 0.0.2 и так далее. Для нас не важно. Для нас важно, что есть три логических интерфейса IP, на которых висят IP-адреса,

и мы хотим на этих логических интерфейсах включить работу протокола EGRP. Мы хотим это сделать, потому что EGRP при включении на интерфейсе делает два действия. Во-первых, начинается на интерфейсе обмен Hello-пакетами с попыткой установить соседство. А во-вторых, все connected-сетки на этих интерфейсах попадают в таблицу топологии. Причем важно то, что если вы включаете EGRP на этом интерфейсе FastEthernet 0.0, то connected-сетка, какая здесь есть — там IP-адрес висит 192.168.1.1, допустим, с /24 маской — значит, сетка 192.168.1.0/24 попадет в таблицу EGRP. EGRP сможет обменяться этой сетью с остальными роутерами. Важно, что попадет в таблицу, в анонс, именно connected-сетка. Если у вас здесь есть 192.168.3.0 с /25 маской, значит, попадет в анонс именно 192.168.3.0/25.

То, что на интерфейсе висит, то и попадет в анонс. Если у вас на интерфейсе несколько IP-адресов из разных сетей, все они попадут в анонс. Connected-сетки все, которые есть, они все попадают в анонс. Включается EGRP на интерфейсе с использованием очень странной конструкции. Странная она по следующей причине. Когда-то давным-давно, в очень далекой галактике, на цисках были доступны протоколы динамической маршрутизации RIP и IGRP. Делалось это примерно в 92-м году. В 92-м году у нас был RIP, у нас был IGRP, и для того, чтобы включить динамическую маршрутизацию на интерфейсе, Cisco сказала: классовый мир, никаких бесклассовых сетей на тот момент еще не было, классовый мир, чтобы нам включить динамическую маршрутизацию на интерфейсе, мы использовали бы команду network. И в RIP до сих пор эта команда network есть, которая указывает классовую сеть. Соответственно, вы указываете network, пробел, классовый IP-адрес,

и тот самый единственный интерфейс, который имеет IP-адрес из этой классовой сети, на нем включается IGRP. Но в бесклассовом мире этот механизм уже не очень хорошо работает. Поэтому для обеспечения обратной совместимости с теми самыми древними конфигурациями команда network на современных роутерах тоже есть, вы можете сказать network и дальше указать классовый IP-адрес. Например, network, дальше 192.168.0.0. Этим самым вы указываете классовую сеть, и тот самый интерфейс, на котором есть IP-адрес из этой классовой сети, на нем включается IGRP. Этот механизм есть, он работает, вы указываете только классовый IP-адрес, больше ничего, и неважно, какой именно IP-адрес висит на интерфейсе,

с какой маской он висит, он проверяется только на совпадение с классовой сетью. Но этот механизм не очень удобен тем, что если у вас, например, есть интерфейс с IP-адресом 10.0.0.1, и есть какие-то другие интерфейсы, которые попадают в ту же самую классовую сеть, например, здесь рядом есть 10.0.1.1 с /24 маской, и мы на нем не хотим включать IGRP, то с помощью такого механизма, как в RIP, когда мы указываем просто network и дальше классовый IP-адрес, мы не можем достаточно гранулярно указывать, на каких интерфейсах мы хотим включать маршрутизацию, на каких не хотим. Поэтому в Cisco появился дополнительный механизм, когда вы можете рядом с IP-адресом сети указать условия access-листа. Вы задаете с помощью обратной маски, с помощью wildcard-маски, условия access-листа, которые отбирают IP-адреса на интерфейсах,

и если ваш IP-адрес на интерфейсе попадает в этот самый access-лист, то на нем включается IGRP, на этом интерфейсе. Давайте сотру всё со слайда. Вы можете сделать примерно следующее. Сказать, например, network 192.168.0.0 по маске 0.0.255.255. Этим самым вы указываете, что все интерфейсы, на которых IP-адреса начинаются на 192.168, должны включить IGRP на себе. Тем самым одной командой вы включаете IGRP вот здесь, здесь и здесь. Потому что все эти интерфейсы имеют IP-адреса, начинающиеся на 192.168. То, что здесь маски какие-то, /24, это абсолютно неважно. Всё равно мы включаем IGRP на интерфейсе. А как только на интерфейсе мы включаем IGRP, connected-сетки с них попадают в таблицу, и на интерфейсах начинается обмен Hello-пакетами. Команда network задает условия access-листа

и никоим образом не маску, которая у вас висит на интерфейсе. Для того чтобы подчеркнуть, что это никоим образом не маска и никакого отношения к маске сети эта штука не имеет, она как раз перевернутая. Здесь задается wildcard-маска, и мы видим: 0, 0, 255, 255. Вторая строчка, network 10.0.0.1 по маске 0.0.0.0, задает такое условие access-листа, которое ловит только IP-адрес 10.0.0.1. У нас такой интерфейс 10.0.0.1, вот он. На нем включается IGRP, connected-сетка с него попадает в таблицу топологии, и на интерфейсе начинается обмен Hello-пакетами. На интерфейсе, который связывает роутер 1 и роутер 2, мы IGRP включили, чтобы там соседство установилось. Нам там connected-сетка в анонсе не очень интересна. А на интерфейсах FastEthernet 0.1 и 0.2 мы IGRP включили для того, чтобы сетки 192.168.1.0, 2.0 и 3.0 вошли в анонс, и для того, чтобы R2

в свою таблицу эти сетки поставил, чтобы R1 смог рассказать про них роутеру R2. Такой механизм позволяет вам включить IGRP на интерфейсах в IPv4. Механизм абсолютно дурацкий. Дурацкий он потому, что команда network на самом деле никакого отношения к сетям не имеет. Она задает условия access-листа, которые отлавливают IP-адреса на интерфейсах. Причем если IP-адресов несколько, проверяется только самый первый. И дальше connected-сетки с этих интерфейсов попадают в анонс. Эти connected-сетки никоим образом не обязаны соответствовать маске, которую вы задали в команде network. Когда-то давным-давно, в очень далекой галактике, команда network имела смысл. Она называлась говорящим образом, и она задавала классовую сеть, в которой находился ровно один интерфейс, который смотрел в нужную сетку, на котором вы включали IGRP. На одном интерфейсе вы включали IGRP. Та самая команда network задавала и фактически сетку,

которая попадет в анонс, потому что она точно была той самой классовой. И она однозначно задавала интерфейс, на котором надо было включить обмен Hello-пакетами. В бесклассовом мире команда network никакого отношения к network не имеет. Она задает условия access-листа. Это достаточно важный момент, поэтому если вдруг он вам не совсем понятен, то имеет смысл эту тему изучить подробнее. Дальше. Как только вы включили IGRP с двух сторон на интерфейсе, которым два роутера соединены между собой, IGRP должен установить соседские отношения. После того, как IGRP установил соседские отношения, он обменивается маршрутами, которые попали в анонс, и устанавливает самые выгодные маршруты в таблице маршрутизации. Если что-то пошло не по плану, у нас есть алгоритм, как проверять, что это не работает, по какому пути мы следуем для того, чтобы найти проблему.

Самое первое — мы проверяем то, откуда на том роутере, на котором не хватает каких-то маршрутов, берутся маршруты в таблице маршрутизации. Есть команда, которая показывает все способы пополнения таблицы маршрутизации, и эту команду имеет смысл выполнить. Самое первое — для того чтобы посмотреть, вообще IGRP у вас работает, не работает, запустился, не запустился. Затем, после того как вы проверили, что сам процесс IGRP работает, проверяем, на каких интерфейсах IGRP завелся. Если на всех интерфейсах, которые вы ожидаете, IGRP есть, дальше переходим к следующему этапу — проверяем соседство. Установил ли IGRP соседство на тех интерфейсах, на которых вы его включили. Затем проверяем в таблице топологии, попали ли все connected-сетки на интерфейсах, на которых вы IGRP включили. И наконец проверяем таблицу маршрутизации, что после того как таблица топологии синхронизировалась, все самые выгодные маршруты действительно удалось поставить в таблицу. Если все маршруты, которые вы ожидали увидеть в таблице, есть, IGRP свое отработал, большой молодец.

Первая команда, которая у нас здесь будет, это как раз про источники маршрутной информации. IGRP будет одним из таких источников, и мы можем посмотреть, что будет касаться IGRP в таблице маршрутизации, с помощью команды show IP protocols. Это не сама таблица маршрутизации, это именно указание на то, из какого источника в таблице маршрутизации могут поступать какие-то изменения. И про IGRP здесь будут рассказывать всякие страшные и ужасные вещи. Нас здесь будут интересовать в первую очередь вот эта штука. Это как раз номер автономной системы. На соседних роутерах он обязан совпадать. Если он не совпадает, дружба не получится. Во-вторых, эти самые коэффициенты метрики, k1, k2, k3, k4, k5, значения их надо будет запомнить, то, что их 5 штук, надо будет тоже запомнить: 1, 0, 1, 0, 0. Такие значения указывают на то, что вас интересует только bandwidth и delay при вычислении computed distance. Дальше. Показывается, какие команды network вы включили.

То есть 10.0.0.1/32 и 192.168.0.0/16. Обратите внимание, мы в команде network задаем wildcard-маски, а здесь они обратно в нормальные маски преобразовались. Эта штука очень часто путает администраторов, но да, в команде network мы задаем условия access-листа. И в этом условии access-листа мы не можем делать разрывные wildcard-маски. Мы должны делать такие wildcard-маски, у которых сначала идут нули, а потом единицы. И здесь показывают routing for networks — какие команды network мы задали, с уже обратно переделанными в прямой вид масками, которые мы здесь видим. Эта штука не обязана совпадать с теми масками, которые у вас по факту висят на интерфейсе. Она просто декларирует, какие команды network вы ввели. После того как EGRP у вас включился,

команду network мы на нем увидели, номер автономной системы мы увидели, дальше проверяем следующие шаги. Следующий шаг будет проверить, на каких интерфейсах EGRP завелся. Есть две команды, которыми мы можем это сделать. Одна из них имеет так называемый старый синтаксис, другая — новый синтаксис. По большому счету делают они абсолютно одно и то же. Вывод будет одинаковый. Можно на уровне CCNA выучить только старый синтаксис — show IP EGRP interfaces. Эта команда покажет список всех интерфейсов, на которых у нас EGRP работает. Здесь у нас будет FastEthernet 0.1, FastEthernet 0.2, FastEthernet 0.3. Это те интерфейсы, где мы нашли IP-адреса, которые попадают под access-листы, заданные командой network. На каждом интерфейсе показывается, сколько у нас соседей обнаружено, и всякая разная информация, которая нас сейчас не сильно интересует. Всё это нас сейчас не интересует вообще. На курсе по роутингу начнет интересовать. Дальше.

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

с какими соседями вам удалось подружиться. Подружиться будет нужно для того, чтобы обменяться маршрутами. Если вы этого не сделали, если у вас не установилось соседство, то маршрутами обменяться не получится. И некоторые причины, почему может быть не устанавливается соседство. Это либо несовпадение автономных систем. Если с одной стороны мы декларируем, например, автономную систему 65000.01, а с другой стороны 65000.02, дружба не выйдет. Несовпадение коэффициентов метрики. Та самая формула, которая будет вычисляться, она должна вычисляться на всех роутерах одинаково. И при установлении соседства роутер проверяет, что метрики считаются в одной и той же логике. Если вдруг два роутера считают метрику в разной логике, одному больше нравится bandwidth, другому больше нравится delay, то метрика у них совпадать не будет. И дружба в этом случае тоже не получится. Может быть такое, что у вас access-лист запрещает протокол 88.

Это не TCP, это не UDP, это тот самый RTP, Reliable Transport Protocol. И у вас может быть access-лист, который на интерфейсе висит. Access-лист на интерфейсе не препятствует отправке трафика самого роутера, но препятствует приёму трафика самого роутера. Поэтому, если у вас на вход висит access-лист, который блокирует 88-й протокол, блокирует EIGRP, то он не сможет установить соседство. Обратите внимание, это не TCP и не UDP. Поэтому access-лист, если вдруг он гипотетически выглядит как permit TCP any any, permit UDP any any, он EIGRP не разрешает при этом. Может быть такое, что вы недовключили EIGRP на интерфейсах, взяли и забыли на интерфейсе включить EIGRP, и у вас два роутера, которые друг на друга смотрят, на одном вы EIGRP включили, а на другом забыли. В этом случае логично, что связи не будет. И ещё один момент.

Если вы настраиваете связь между двумя роутерами, у них основные IP-адреса, которые используются, должны быть в одной и той же сети. И если есть другие какие-то IP-адреса, они тоже все должны быть в одной и той же сети. Например, у вас здесь IP-адрес 10.0.0.1 с маской /24, то с другой стороны должен быть, например, 10.0.0.2 с маской /24. Если вы скажете, да, у меня такой IP-адрес есть, но он не первичный, а первичный — 192.168.1.0, у вас связи не получится. Несмотря на то, что есть IP-адреса в одной и той же сети, несмотря на то, что мы можем попинговать с узла 10.0.0.1 узел 10.0.0.2, и пинговаться будет, EIGRP установить соседство не сможет. И ещё один нюанс. Должны совпадать MTU. Если у вас MTU не совпадают на двух роутерах, то связи тоже не будет. В табличке show EIGRP neighbors показываются IP-адреса соседей, показываются интерфейсы, на которых они обнаружились, показывается hold time.

Как уже было сказано, по умолчанию hold time 15 секунд, и каждые 5 секунд приходит новый hello-пакет и заставляет нас считать заново от 15 до 0. Соответственно, это выглядит как 15, 14, 13, 12, 11, 10. Приходит новый пакет, мы начинаем заново считать 15, 14, 13, 12, 11, 10. Таймеры не обязаны совпадать. Если вы хотите, вы можете сделать два роутера с абсолютно разными таймерами. Это не проблема. Так же, как и в протоколе CDP, таймер hold time вы будете указывать в исходящих пакетах от вас. Вы отправляете соседу hello-пакет и говорите: я в течение следующих 15 секунд обещаю тебе прислать следующий hello-пакет. По факту присылаете следующий через 5. Поэтому, в принципе, вы можете потерять до 3 пакетов. Это не вызовет пропадание соседства из списка соседей. Показывается uptime. Показывается среднее время прохождения пакетов туда-обратно.

Smooth round trip time. На основании этого SRTT, среднего времени прохождения пакетов туда-обратно, вычисляется время, которое должен ваш роутер ждать, если вы отправили какое-то сообщение соседу, а он вам ничего не ответил. RTO — это retransmission timeout. Если у вас среднее время прохождения туда-обратно пакетов 1 миллисекунда, то через 100 миллисекунд вы переотправляете соседу сообщение, которое вы ему отправили, а он вам это не подтвердил. RTP — Reliable Transport Protocol. Он как раз делает так, что сообщения, по крайней мере некоторые, доставляются надёжно. И надёжная доставка сообщений предполагает, что если вы что-то отправили, а сосед это не подтвердил, то вы это переотправляете. В результате того, что у нас соседство устанавливается, в таблицу топологии попадают маршруты. Show IP EIGRP topology, или есть новый синтаксис, который вряд ли вас будут на экзамене проверять,

она показывает список маршрутов. По умолчанию показываются только те маршруты, которые удовлетворяют feasibility condition. Те маршруты, которые гипотетически тоже есть, но они не прошли это условие, потому что гипотетически могут содержать петлю через вас, эта команда не показывает. Но если очень сильно хочется, можно показать с ключиком all links. Show IP EIGRP topology all links. Показывается на роутере R2, что роутер 1 ему прислал маршруты. 192.168.1.0, 0.0 и 2.0. И по каждому маршруту показывается, через какой интерфейс этот маршрут виден, показывается reported distance, то есть какую метрику до этого маршрута знает сосед. И какую метрику мы знаем через этого соседа до указанной сети. 28 416. Метрика, которую знаем мы,

всегда строго больше, чем метрика, которую знает наш сосед. Дальше. Самая выгодная метрика за каждую сеть считается отдельно. И FD, feasible distance, для 192.168.0.0 с маской /24 — 28 416. Это наша метрика, которую мы сами видели когда-то на нашем роутере. За всю историю наблюдений она вот такая была. Судя по тому, что она совпадает с текущим computed distance, это означает, что у нас никогда наша метрика хуже не становилась. Потому что feasible distance уменьшиться может, если у нас метрика улучшилась. А ухудшиться feasible distance не может. Она всегда самая маленькая за всю историю. Судя по тому, что она сейчас совпадает с нашим computed distance, у нас прямо сейчас самая маленькая метрика за всю историю наблюдений. По каждому маршруту эта feasible distance считается отдельно. 28 416 для этой сети, 28 416 для этой сети, 28 416 для этой сети. Кроме того, в одну из сетей мы можем доставить трафик,

даже не используя пересылку соседу. Например, в сеть 10.0.0.0 EIGRP тоже про неё знает, тоже про неё рассказывает. В анонс попадают connected-подсетки с интерфейсов. Он говорит: это та самая сетка, которая попала в анонс, потому что она connected на интерфейсе GigabitEthernet 0/0, где у нас работает EIGRP. Для такой сети feasible distance тоже считается. Потому что мы знаем сетку через интерфейс. На этом интерфейсе есть bandwidth, есть delay. Их тоже можно подставить в формулу. И здесь feasible distance нам скажут, что по формуле 281 160 — это наша метрика до этой сети. Понятное дело, в таблицу маршрутизации такой маршрут поставить не получится из таблицы топологии. Там уже будет занято. Но, по крайней мере, рассказать про эту сеть мы сможем. И именно таблица топологии реплицируется между всеми роутерами. В результате таблица маршрутизации у нас пополняется маршрутами. На R2 показывается, что есть 192.168.1.0, 2.0, 3.0.

Маршруты, полученные по EIGRP, показываются буквой D. И вы можете это посмотреть с помощью команды show ip route. Если хотите, можете добавить show ip route eigrp для того, чтобы не смотреть маршруты, не полученные по EIGRP. Это такой простенький способ фильтрации. Показывается по каждому маршруту метрика, та самая computed distance. Показывается next hop, кто нам прислал такой маршрут. И показывается число — это административное расстояние. Чем оно меньше, тем лучше. Это индекс доверия к этому конкретному маршруту. Если у нас есть маршруты, полученные из разных источников, в таблицу маршрутизации сможет добавиться тот маршрут до одной и той же сети, который имеет административное расстояние меньше. У EIGRP административное расстояние 90, у OSPF, например, 110, у RIP 120, у connected маршрутов 0, у static единичка. Если есть вдруг и static маршрут, и EIGRP-маршрут,

Cisco будет верить статику. При условии, что это одна и та же сеть. Что IP-адрес сети одинаковый и маска одинаковая. Если маски разные, если IP-адреса разные, то добавится в таблицу маршрутизации и тот, и другой маршрут. В таблице маршрутизации Cisco добавляет маршрут и показывает нам, что вроде маршрут есть, и ничего специального с ним не происходит. На самом деле в таблицу маршрутизации Cisco добавляет не просто маршрут, а ещё и краткую пометку, откуда он прибежал. И мы можем заказать show ip route для некоторой сети, которая известна через EIGRP. И здесь будет показано, во-первых, что это EIGRP-маршрут, во-вторых, показано, из какого экземпляра EIGRP этот маршрут прибежал. Показывается административное расстояние, то самое 90, и метрика 28 416. Показывается тип маршрута в EIGRP. Мы это не проходили, но EIGRP-маршруты бывают нормальные и внешние. И здесь показывается нормальный маршрут.

Показывается, кто прислал такой маршрут, кто является next hop для такого маршрута. В нормальной ситуации кто прислал, тот и next hop. И показываются компоненты этого маршрута, на основании которых получилась метрика 28 416. Эта штука была посчитана на основе суммарной задержки 110 микросекунд, минимальной полосы пропускания, которая до удалённой сети будет 100 тысяч килобит в секунду, или 100 мегабит. И тут всякие другие показатели тоже есть, но они в формуле не участвуют. Мы можем посчитать и проверить, что должно получиться 28 416. 110 микросекунд — это 11 десятков микросекунд. Это у нас delay. Дальше. Минимальная полоса пропускания.

100 тысяч килобит в секунду. Соответственно, 10 в седьмой степени, делённое на 10 в пятой степени, на 100 тысяч — это у нас 100. Берём, складываем одно с другим и получаем 11 плюс 100 — это 111. Это мы умножаем на 256 и получаем 28 416.

Соответственно, 111 умножить на 256. 6 на 256: получаем 6. 1 на 256: 5 плюс 6 — 11, 1 в уме. 2 плюс 5 — 7. Плюс 6 — 13. Плюс 1 в уме — 14. Дальше 2 плюс 5 — 7. Плюс 1 в уме — 8. И двоечка. 28 416. Ровно то самое, что получилось. Я сначала не обратил внимания. 110 микросекунд оно показывает. Это 11 десятков микросекунд. И минимальная полоса 100 мегабит в секунду — это 100 тысяч килобит в секунду. 10 в седьмой степени, делённое на 100 тысяч, на 10 в пятой, даёт нам просто 100. 11 десятков микросекунд плюс 100 — этот самый Scaled Bandwidth. Подставляем в формулу, умножаем на 256, получаем 28 416. Если у нас есть один маршрут, который самый выгодный, то его в таблицу маршрутизации добавляем.

Если у вас есть два маршрута, один выгодный, другой менее выгодный, то мы добавляем в таблицу маршрутизации только один. Но если вы хотите, вы можете воспользоваться уникальной фичей, которая есть в EIGRP, которая называется Unequal Cost Multipath или Unequal Cost Load Balancing, UCLB. Вы можете задать мультипликатор, который позволяет определенное расхождение в метрике для маршрутов, которые вы все сможете добавить в таблицу маршрутизации. И выгодный, и невыгодный. Соответственно, чтобы они просто не были слишком сильно невыгодны. И кроме того, ни при каких условиях EIGRP не будет добавлять маршруты, которые не удовлетворят условию feasibility condition. Поэтому гипотетически в таблицу маршрутизации могут быть добавлены только маршруты до feasible successors. По умолчанию вы можете добавить до 4 маршрутов, но это можно переопределить. Можно будет указать maximum paths и задать, сколько этих маршрутов вы хотите. Но по умолчанию до 4 маршрутов,

и этого более чем достаточно. Я вам не рекомендую использовать Unequal Cost Load Balancing. Он приводит к не очень интересным последствиям часто. Но если у вас есть маршруты, которые не очень сильно отличаются между собой по метрике, в принципе, можно их будет даже и разрешить. Самый маленький мультипликатор, который вы можете задать, это будет двоечка. Это число, которое целочисленно, и оно указывает, во сколько раз метрика менее выгодного маршрута может отличаться от метрики самого выгодного маршрута, чтобы вы все еще допустили этот маршрут в таблицу маршрутизации. Если, например, у нас есть маршрут за 28416 копеек и за 28672 копейки, видно, что это практически одинаковые метрики, что они не сильно отличаются между собой. Их, в принципе, можно добавить в таблицу маршрутизации оба. И в этом случае мы в config router указываем variance 2, и у нас и тот, и другой маршрут действительно добавляются в таблицу маршрутизации.

Если вы захотите, вы можете даже сказать, что трафика до маршрутов, по маршрутам, которые идут до одной и той же сети, но с сильно разными метриками, можно отправлять разное количество. Вы можете сказать, что, допустим, если у вас один маршрут имеет метрику 10 тысяч, а другой маршрут метрику 20 тысяч, то трафик будет между ними балансироваться в пропорции 2 к 1. На тот, который 10 тысяч, будет идти в два раза больше трафика, чем до того, который 20 тысяч. Гипотетически это можно сделать, а практически я вам это делать не рекомендую. Мы на курсе по роутингу разберемся, во-первых, как это работает, а во-вторых, почему этого делать не нужно. Команда variance она есть, она позволяет вам добавить маршруты, которые различаются по цене, но, соответственно, она позволяет задать мультипликатор, во сколько раз маршруты могут отличаться по цене. Если вдруг у вас есть несколько маршрутов, которые имеют одинаковую стоимость, самую выгодную,

роутер EIGRP добавит их все. Они считаются, что различаются друг от друга ровно в один раз. И этот самый мультипликатор variance 1 указывает на то, что у вас можно добавить несколько маршрутов с одинаковой стоимостью. Так. У EIGRP есть одна особенность. Особенность заключается в том, что некоторые механизмы в нем все еще основаны на классовой его природе. EIGRP — это протокол, который специально сделан обратно совместимым с IGRP. IGRP был протокол классовый. И EIGRP, когда работает в, назовем это, режиме совместимости с IGRP, он должен себя вести, как будто он тоже протокол классовый. Он должен делать так, что в сторону классового соседа

будут посылаться только классовые маршруты. Делает это EIGRP следующим образом. Если у вас старый IOS, он по умолчанию себя ведет таким образом. Он на границе между классовыми сетями включает автосуммирование сетей до классовой. Фишка будет вот в чем. Если у вас есть, например, где-нибудь роутер R1, он классовый роутер. У него есть с одной стороны классовая сеть, с другой стороны тоже классовая сеть. Он в этом случае говорит, что я целиком всю классовую сетку вижу вот тут. И он вам будет посылать всю классовую сеть 10.0.0.0. Если мы со своей стороны тоже хотим сказать, что у нас есть тоже какая-то сеть, то у нас тоже она вся должна быть классовая. Не может быть такого, чтобы у нас один кусочек классовой сети и другой кусочек классовой сети был с разных сторон классового роутера. Он так просто работать не сможет. Но если у вас EIGRP старых версий, то есть IOS до 12-го включительно,

то в этом случае он на границе между классовыми сетями пытался прикинуться классовым. Если у вас здесь, например, на роутере R1 был интерфейс, который имел IP-адрес 10.0.1.1, к примеру, с 24-й маской, вообще-то говоря, сеть 10.0.1.0 с 24-й маской явно бесклассовая. Но если мы перекладывали информацию про эту сеть соседу, который находится в другой классовой сети, то вместо того, чтобы рассказывать про именно эту сетку из таблицы топологии, посылается автосуммированный маршрут классовый 10.0.0.0 с 8-й маской. В сторону соседа идет не та сеть, которая у нас в таблице топологии, а та, которую мы сами придумали на основе того маршрута, который у нас там был. Оно складывается до классовых сетей, и соседу посылается только вся классовая сеть целиком. Приводит это к очень интересным последствиям, если у вас в вашей сети используется одна и та же классовая сеть,

разрезанная на части, и в бесклассовом мире кусочки этой самой классовой сети используются в разных местах. Так называемые discontinuous classful networks. Например, на роутере R3 у нас используется сетка 10.0.2.0 с 24-й маской. Это тоже десятка. И, соответственно, R3, если мы используем старый IOS, тоже будет посылать 10.0.0.0 с 8-й маской, для того чтобы быть обратно совместимым с IGRP. И получится в такой ситуации, что роутер R2 получает указание, что вся сетка 10.0.0.0 доступна с одной стороны, вся сетка 10.0.0.0 доступна с другой стороны. Поэтому он говорит: в такой ситуации я буду балансировать трафик, буду часть трафика посылать налево, часть направо, добавлю оба маршрута в таблицу маршрутизации. В итоге, если мы хотим посылать трафик на IP-адрес, например, 10.0.1.1, то часть трафика пойдет куда надо, а часть трафика пойдет куда не надо. Этот механизм очень много крови выпил администраторам,

поэтому если вы работаете с EIGRP на старых IOS, а, например, на каталистах шеститысячниках практически все варианты IOS будут старые, то имейте в виду, что EIGRP там себя вел таким похабным образом. Эту штуку можно выключить. Команда будет очень простая. В настройке роутера указываем no auto-summary. Если вы это делаете, то EIGRP перестает себя так вести. Более того, в 15-х IOS эта команда уже используется по умолчанию, там EIGRP ничего не придумывает, он отсылает все сети в том виде, в котором они должны быть. Но на старых IOS эта штука была. И это очень частое явление, когда человек начинает рассказывать, что у меня был там шеститысячник каталист, и я хотел на нем включить EIGRP. Можно просто сразу даже не продолжать. Сразу понятно, человек нарвался на автосуммирование. Поэтому no auto-summary — команда, которую на старых IOS надо вводить автоматически, просто не дожидаясь того, пока вы наступите на эти грабли.

Дальше. Про пассивные интерфейсы. Если у вас есть роутер EIGRP, вы в нем сказали no auto-summary, тем самым сказав, что сети надо посылать такие, которые есть, ничего там не придумывая. И вы разметили все свои интерфейсы, на которых вы хотите работать. Указали, что EIGRP должен работать на интерфейсах, которые смотрят в сторону пользователей, и на интерфейсах, которые смотрят на соседние роутеры. На соседние роутеры, потому что мы там дружим, а на пользователей, потому что мы про эти сетки хотим соседним роутерам рассказать. Что касается пассивных интерфейсов, мы можем некоторые интерфейсы объявить пассивными и тем самым сказать, что на этих интерфейсах не нужно отправлять hello-пакеты. Connected-сетки интерфейсов все равно в анонс попадают, но тем не менее hello-пакеты на таком интерфейсе не отправляются. Эта штука очень удобная, если у вас есть интерфейсы,

которые смотрят на конечных пользователей. Там, где соседство ни с кем в принципе не предполагается. Там мы hello-пакеты отправлять не будем, как следствие дружить ни с кем не будем на этом интерфейсе. А connected-сетки с таких интерфейсов, которые вы разметили как пассивные, они в анонс все равно добавляться будут в любом случае. Вы можете в явном виде сказать passive-interface такой, passive-interface такой, passive-interface пятый, passive-interface десятый. Но если у вас, например, distribution switch, на котором терминируется сразу целая пачка VLAN-ов, это может быть очень неудобно. У вас там, скорее всего, интерфейсов, которыми вы смотрите на внешний мир, на внешних соседей, будет не так много. Например, два таких интерфейса будет. И вы на двух интерфейсах хотите включить EIGRP, а на всех остальных вы хотите включить EIGRP, но в пассивном режиме. В этом случае как раз есть смысл воспользоваться командой passive-interface default, которая скажет, что пассивными интерфейсами будут вообще все.

А те два интерфейса, на которых нам все-таки нужно устанавливать соседство, они не должны быть пассивными, и мы их в явном виде указываем no passive-interface, там, GigabitEthernet 0/0. Эта штука очень и очень полезная, и она настоятельно рекомендуется к использованию. На тех интерфейсах, которые смотрят напрямую на пользователей, там, где нет установленного соседства, и там быть не должно, интерфейсы можно и нужно помечать как пассивные. На экзамене, скорее всего, будет вопрос, почему два роутера EIGRP не дружат между собой. И вроде бы все хорошо, но вроде как-то дружбы нет. И один из вариантов ответа, почему такое может быть, это как раз то, что интерфейс со стороны одного из роутеров, поверх которого будет происходить попытка подружиться, он размечен как пассивный. Так, давайте попробуем это все дело понастраивать и посмотрим, как это все выглядит в реальном мире. Да, вот наши роутеры. Мы сейчас будем настраивать связь нашего маленького роутера и центрального.

У меня и мой маленький роутер, и центральный открыты, и сейчас мы будем обеспечивать их связность. Первым делом я предлагаю их переименовать. conf t, hostname R08, просто для того, чтобы потом не запутаться, где какую железку мы настраиваем. И затем мы должны будем на роутере включить интерфейс, которым наш маленький роутер смотрит на центральный. Это будет интерфейс Ethernet 0/1. Интерфейсы на роутерах находятся в выключенном состоянии, поэтому их надо включить. No shutdown. И затем нужно будет повесить на них IP-адрес. Это интерфейс Ethernet 0/1, который с маленького роутера смотрит на центральный. Я предлагаю сделать там адресацию вида IP address 10.100. Номер комплекта, в моем случае 8. И еще раз номер комплекта 8.

И маска 255.255.255.0. У вас будет, соответственно, 10.100.1.1, 10.100.2.2 и так далее. Затем со стороны центрального роутера мне нужно будет сделать ответные действия. Я сейчас это сделаю. Enable. Conf t. Hostname CoreR. Interface Ethernet 0/0. Это интерфейс в сторону первого комплекта. IP address 10.100.1.100. И no shutdown. Так. Второй комплект. Промахнулся. No shutdown. И восьмой комплект. Ethernet 1/3, по-моему, там.

Это у нас будет вот так. Таким образом я разметил три интерфейса. Я их включил и повесил на них IP-шники 10.100. Номер комплекта .100. На каждый отдельный маленький роутер у центрального есть отдельный шланг с IP-сетью 10.100, чего-то там. 0 по 24 маске. У самого центрального роутера все IP-шники заканчиваются на 100. У маленьких наших роутеров IP-шники заканчиваются на их номер. Давайте проверим, что связь у нас действительно есть. Do ping 10.100.8.100. В моем случае 8.100. У вас будет там 1.100, 2.100 и так далее. Как видно, связь есть. Со стороны моего маленького роутера я на интерфейсе Ethernet 0.1 интерфейс включил, повесил IP-адрес 10.100, номер комплекта, номер комплекта и убедился, что ping 10.100, номер комплекта, 100.

Это обеспечивает нам базовую связность. Как только у нас появился IP-адрес на интерфейсе, у нас появилась connected-подсетка. Это connected-подсетка 10.100.8.0 по 24 маске. Но если мы хотим обеспечить связность между вообще всеми роутерами, нам нужно будет запустить динамическую маршрутизацию на наших роутерах. И для этого мы запускаем router EIGRP. Я предлагаю использовать номер автономной системы такой же, как у нас был на слайдах. 65001. Вы у себя тоже запускаете router EIGRP 65001. Затем, если у нас есть интерфейс, на котором EIGRP работает, это у нас должен быть Ethernet 0.1, то мы должны будем задать команду network, которая задаст условия access list, в которую попадёт 10.10.8.8 в моём случае, или там 10.10.1.1 в вашем, 10.10.2.2, 10.10.3.3, какой он там будет.

Я хочу сделать так, чтобы никакой другой интерфейс, кроме действительно того, который имеет IP-шник 10.10.8.8, не включился в EIGRP. Я указываю 10.100.8.8 по маске 0.0.0.0. Если указать команду network и только один IP-шник сказать без маски, то тогда будет предполагаться, что вы используете классовую сеть. Роутер посмотрит, какие IP-шники на интерфейсах попадают в классовую сетку, которую вы указали, и повключает на них EIGRP. Connected-подсетки с них включит в анонс, и на этих интерфейсах начнут посылать hello-пакеты. Но я указываю, что мне интересно 10.10.8.8 по маске 0.0.0.0. Интерфейс с точно IP-шником 10.10.8.8 без каких-либо отклонений я хочу включить в EIGRP и connected-подсетку с него включить в анонс. Эта команда в моём случае — включить EIGRP в автономную систему 65001 на том интерфейсе, на котором IP-шник строго 10.10.8.8 — она приведёт меня к желаемому результату.

Со стороны центрального роутера, понятное дело, надо сделать что-то очень похожее. Router EIGRP 65001. Указываем network. Network. И дальше у меня есть как минимум три интерфейса, которые должны попасть в анонс. Я очень ленюсь, я не хочу вводить отдельно 10.10.1.100 по маске 0.0.0.0, отдельно 10.10.2.100 по маске 0.0.0.0, отдельно 10.10.8.100 по маске 0.0.0.0. Я не хочу по 24 маске всё это задавать, я хочу сказать: меня интересуют все интерфейсы, IP-шники на которых начинаются на 10.100. Если я включу одной командой EIGRP на всех трёх интерфейсах, это будет на самом деле довольно здорово. И для того, чтобы это сделать, я указываю 10.100.0.0, пишу эталонный IP-шник, который меня будет интересовать, и дальше 0.0.255.255.

Wildcard-маска, указывающая на то, что в эталонном IP-шнике нас интересуют первые два октета. Со стороны наших роутеров уже все настройки были сделаны, поэтому как только на центральном роутере была ответная команда network дана, пробегают два новых соседства. Одно соседство с IP-шником 10.10.1.1, другое соседство с IP-шником 10.10.8.8. Можно посмотреть, что на маленьком роутере тоже пробежало сообщение, что у нас обнаружилось новое соседство с таким адресом на таком интерфейсе. И как следствие мы сейчас можем посмотреть, что в итоге получилось, когда мы установили такое соседство. Show IP protocols. Первым делом смотрим на то, как у нас работают протоколы динамической маршрутизации. Здесь мы видим блок, посвящённый протоколу EIGRP.

Видим, что у нас EIGRP запущен с номером автономной системы 65001. Видим коэффициенты метрики, те самые K1, K2, K3, K4, K5. Видим, что они находятся в значении по умолчанию. 1, 0, 1, 0, 0. Видим maximum paths. Сколько маршрутов может максимум EIGRP до одной и той же сети добавить в таблицу маршрутизации? До одной и той же сети, подчеркну. По умолчанию все эти маршруты должны быть одинаковые, поэтому мультипликатор variance задан в единицу. Мы можем добавить маршруты точно такие же, как и самый выгодный маршрут. Если мы поставим variance, например, 2, то в таблицу маршрутизации может быть добавлено до 4 маршрутов, у которых метрика отличается не более чем в 2 раза от самого выгодного. Автоматическое суммирование классовых сетей выключено. Дальше команду network мы задали, в моём случае, 10.10.8.8 по 32 маске.

И Routing Information Sources — это какие соседи присылали нам какие-нибудь маршруты. Видим, что EIGRP вроде бы работает, показывается, что здесь оно есть, все настройки, которые мы задавали, соответствуют тому, что мы здесь видим. Дальше можем посмотреть show ip eigrp interfaces. На каких интерфейсах EIGRP зажёгся. Здесь напомню, что показываются те интерфейсы, на которых самый первый IP-шник попал под действие команды network, за исключением пассивных. Видим, что Ethernet 0.1 действительно у нас в списке есть. На нём обнаружился даже один peer. Эти циферки нас сейчас не сильно интересуют, на курсе по роутингу будут интересовать, а здесь нет. Show ip eigrp neighbors. Сейчас посмотрим, что там у нас за сосед обнаружился. Сосед с номером 0. Эта буква H — это Handle, своего рода уникальный идентификатор.

IP-адрес соседа 10.10.8.100. Интерфейс, на котором он работает, Ethernet 0.1. Hold time 14 секунд. Uptime, как давно завёлся, 2 минуты 57 секунд назад. Среднее время прохождения пакетов туда-обратно 3 миллисекунды. Retransmission timeout для такого smooth round-trip time характерный — 100 миллисекунд. Если мы за 100 миллисекунд не обнаружили ответа на наше сообщение, то мы переотправим это этому соседу. Q-count и sequence number нас сейчас не интересуют. Видим, что соседство установлено. Можем посмотреть, что сосед нам наприсылал. Show ip eigrp topology. Можно запросить вообще всё. В нашем случае у нас сосед только один, поэтому нехороших соседей, которые посылают нам дорогие маршруты, здесь просто не будет, поэтому можно не писать. И видим, что три маршрута к нам пришли. Эти маршруты 10.10.2.0, 10.10.8.0, 10.10.1.0.

Все по 24-м маскам. Нигде в команде network мы 24-ю маску не писали. Мы писали либо маску 0.0.0.0, либо маску 0.0.255.255. Это эквивалент 32-й и 16-й маски. Но в анонс добавляется только connected-подсетка. 24-я сетка в анонсе висит, потому что она висит на интерфейсе. Нигде ни 32-х, ни 16-х масок тут нет. Показывается по каждой сети, что с сетью всё хорошо. Буковка P, если мы в легенде посмотрим, означает слово passive. Вообще говоря, пассивный во многих культурах означает, что это какой-то нехороший, что-то с ним не то происходит. Но на самом деле в случае с EIGRP быть пассивным — это хорошо. Пассивный маршрут означает, что с этим маршрутом сейчас ничего плохого не происходит. И можно сидеть на попе ровно и ждать у моря погоды. Если что-то произойдёт, в этом случае маршрут перейдёт в фазу активный. И это означает, что с маршрутом всё плохо.

Надо активно сидеть и пытаться разобраться, как добраться до этой сети. Если мы видим, что маршрут активный, тем более, что он очень долго активный, это прямо явный признак того, что что-то пошло не по плану. Дальше. Напротив каждой сети мы видим, откуда этот маршрут взялся. Этот маршрут прибежал от соседа, этот маршрут прибежал от соседа. А этот маршрут 10.10.8.0 в моём случае — это connected-маршрут, который я сам добавил в таблицу топологии для того, чтобы реплицировать этот маршрут на все остальные роутеры. Поэтому маршруты в таблицах топологии у всех роутеров одинаковые. А дальше указания, откуда они взялись и какие у них там метрики — это всё будет разное. Что касается нашего маршрута, который у нас connected, у него feasible distance, самая маленькая метрика наша за всю историю наблюдения, будет 281 600 копеек. 281 600 — это означает, что у нас 10-мегабитный линк. И 10-мегабитный линк — это 1000 копеечек.

И затем, если мне память не изменяет, 10 миллисекунд задержки. Это 1000 — другая компонента delay. И у нас 1000 одна плюс 1000 другая даёт 2000. И 281 600 — это как раз характерное значение для 10-мегабитных интерфейсов. Что касается маршрутов, которые приходят от соседа, наш feasible distance — 307 200. Это значит, что нам сосед прислал маршрут, а мы к этому маршруту добавили ещё к вектору, который прислал сосед, добавили вектор, как мы знаем, до соседа. И получается, что у нас метрика по факту получилась 307 200. Сосед при этом заявил те самые 281 600. Здесь можно заметить, что 281 600 здесь и 281 600 здесь. Судя по всему, это connected-подсетка прямо на нашем роутере-соседе, на центральном роутере Core R.

И действительно, там эти сетки попадают в анонс, потому что они непосредственно к нему подключённые. Это не второй и не первый комплект присылают мне эти сети. Это центральный роутер говорит: я знаю, как добраться до этих сетей, и я могу рассказать про это всем остальным соседям. Давайте добавим к этим трём сетям ещё каких-нибудь сеток, которые уже наши роутеры будут вбрасывать в топологию. И эти сети будут фактически эмулировать пользователей, которые у нас есть на нашем роутере. Роутеры нужны для того, чтобы пользовательский трафик форвардить, не для того, чтобы просто наблюдать, какие маршруты там прикольные бегают. Поэтому для того, чтобы это проэмулировать, мы сделаем новый интерфейс. Интерфейс будет называться loopback. И дадим ему номер. Это будет номер 0. На этом интерфейсе loopback мы повесим IP-адрес. IP-адрес 10.200.

Номер комплекта, номер комплекта. В моём случае 8.8. Маска будет 255.255.255. В принципе, всё равно, какая здесь маска. Допустим, 0. И затем мы указываем, что этот интерфейс у нас смотрит как бы на пользователей. Понятное дело, что воображаемый интерфейс loopback на пользователей может смотреть крайне редко, но гипотетически это мог бы быть интерфейс, например, Ethernet. Мы могли на этот интерфейс повесить IP-шники. И дальше сказать, что мы хотим этот интерфейс включить в анонс EIGRP, чтобы connected-подсетку с него анонсировать нашим соседям. У нас таким, в кавычках, пользовательским интерфейсом будет интерфейс loopback. Да, пользователей в нём нет. Ну и что? Router EIGRP 65001. Переходим в контекст работы с роутером. Указываем network 10.200.

Номер комплекта, номер комплекта, по маске 0.0.0.0. И тем самым мы включили в анонс свежесозданный loopback, и у нас в нашей таблице топологии должны появиться сетки 10.200, чего-то там. Проверяем, что это действительно так. Show ip eigrp topology. Вот они, две наши сеточки 10.200. Одна из них моя connected, другая пришла от первого комплекта. Видно хорошо, что метрики, которые приходят, сильно отличаются от тех метрик, которые у нас были. 281 600 и 307 200. Этот маршрут явно сильно дальше, чем сетка 10.100.2.0, например, 10.100.1.0. Про 10.100 рассказывает центральный роутер, а про 10.200 рассказывает роутер R1. Поэтому роутер соседа заявляет, что знает эту сетку за 409 600.

А я знаю эту сетку за 435 200 копеек. В таблице маршрутизации сейчас все эти сетки должны будут добавиться. Show ip route. Вот они есть. Если вдруг мне захочется, я могу отфильтровать вывод, показав только EIGRP-шные маршруты. И вот их там целых три штуки. 10.10.1.0, 10.10.2.0 и 10.200.1.0. Маршрутов меньше, чем в таблице топологии, потому что некоторые маршруты из таблицы топологии в таблицу маршрутизации не попадают. Там уже занято. Например, там connected-маршрут будет. Но connected-маршрут имеет административное расстояние 0, а EIGRP имеет административное расстояние 90. Поэтому, естественно, EIGRP-маршрут просто не может попасть в таких условиях. В таблице маршрутизации там уже занято connected-маршрутом. Но эти 10.100, 10.200 — это маршруты вполне живые, нормальные, рабочие. И мы можем их попингать, например. Ping 10.200.1.1. Я могу даже адрес source указать.

10.200.8.8. И вот оно пингается. EIGRP таким образом построил маршруты от всех роутеров до всех роутеров, синхронизировал таблицы топологии — более строго — на всех роутерах. И поэтому трафик до 10.200.1.1 и 10.200.8.8 на всех роутерах может дойти до назначения. Если мы хотим сказать, что этот интерфейс 10.200.8.8 действительно смотрит на пользователей, нам по-хорошему нужно было бы ещё сказать router EIGRP 65001, что это passive-interface. Loopback 0. Это сейчас ни на что не повлияет, потому что мы всё равно не сможем увидеть, как на loopback не отправляются hello-пакеты, потому что loopback — интерфейс воображаемый, и туда в любом случае ничего не отправляется.

Если бы это был физический интерфейс, допустим, мегабитный или 100-мегабитный, то мы бы в Wireshark могли бы увидеть, что без этой команды hello-пакеты отправляются, а с этой командой hello-пакеты не отправляются. И в списке интерфейсов, на которых включён EIGRP, этот loopback сейчас проявляться не будет. Show ip eigrp interfaces. Показывается только не пассивный интерфейс, а в нашем случае Ethernet 0.1. И show ip protocols покажет тоже, что loopback он пассивный. Вот здесь она. Таким образом EIGRP настраивается, таким образом EIGRP может синхронизировать таблицы топологии и облегчить жизнь администраторам сети, которые в случае со статической маршрутизацией должны были бы прописывать все маршруты ручками.

А так они просто включили протокол обмена маршрутной информацией, и роутеры сами все новые маршруты рассказали своим соседям, информацию от своих соседей приняли и построили кратчайшим способом маршруты, как лучше всего добраться до удалённой сети, и добавили их в таблицу маршрутизации. Очень удобная штука, рекомендуется к использованию. EIGRP, как уже было сказано, один из самых быстрых протоколов динамической маршрутизации, которые есть в распоряжении сетевого администратора. Если у вас не очень большая сеть, если эта сеть целиком построена на оборудовании Cisco, если вы не планируете добавлять новые маршрутизаторы других вендоров к вашей сети, то EIGRP, в принципе, очень неплохой вариант для динамической маршрутизации. Он позволяет в определённых ситуациях действительно быстро перестраивать маршруты. Он очень здорово работает с другими вендорскими технологиями Cisco. Например, есть такая штука DMVPN. Мы про неё чуть-чуть будем говорить в конце курса.

EIGRP поверх DMVPN очень здорово работает за счёт того, что он дистанс-векторный. И, например, OSPF поверх DMVPN работает намного хуже. Но принципиальный недостаток EIGRP — это то, что он vendor-lock, что вы пожизненно обязуетесь работать с оборудованием Cisco. Если вы предпочитаете не быть настолько завязанным на конкретного производителя, на конкретного вендора, особенно в условиях тренда на импортозамещение, то, возможно, имеет смысл посмотреть на какие-нибудь другие протоколы. На этом про EIGRP для IPv4 всё. Спасибо за субтитματα. Спасибо за субтитры Алексею Doct Exercise! Уже международgrowth – это vamos основных оборудовениемícia по какой-то,

марш wow, так и субтитры конечно же не понимали. Извините так. Vill 인ерт. Нет. Хорошо. Одно. Рakat парш at the appropriate и лучшеMedしょ.