Изучаем компьютерные сети. Динамическая маршрутизация

Динамическая маршрутизация разделяет протоколы на два больших класса – IGP и EGP.
IGP-протоколы работают внутри одной автономной системы. Динамическая маршрутизация это такая система, которая находится под контролем какого-то одного администратора. Проще говоря, IGP-протоколы – это протоколы, которые работают внутри организации.
Одна организация. В ней будет работать протокол динамической маршрутизации класса IGP. В другой организации также под контролем системного администратора находится сеть соответственно в этой локальной сети также будет работать протокол IGP.
Протоколы EGP работают между локальными сетями, примером такого протокола является Интернет. Если две организации соединены между собой с помощью Интернета, то в Интернете работает протокол внешнего шлюза, то есть протокол EGP находится под контролем не одной такой организации, не только одного администратора, а под контролем множества различных организаций, контролирующих Интернет. А внутри организации будет работать протокол IGP.

На примере покажем настройки динамической маршрутизации в созданной компьютерной сети

Подключаемся к роутеру (каждому) и выполняем указанные ниже команды по удалению статических маршрутов. Вводим команды:

— enabled
— conf ter
— no ip route 192.168.2.0 255.255.255.0

Эта последовательность команд удаляет из таблицы маршрутизации все маршруты. Посмотреть их наличие можно с помощью команды «do show ip route». В общем, все статические маршруты удалены, в результате теперь ПК не сможет добраться до других ПК из других подсетей.
Теперь можно приступить к настройке роутера и включить протокол динамической маршрутизации. Цифра обозначает номер автономной системы (номер экземпляра). таких экземпляров можно сделать несколько, но в большинстве случаев этого не требуется. Единственное, номер экземпляра должен совпадать на всех роутерах.
-router eigrp1

Нужно сказать роутеру о том, о каких сетях он должен «рассказывать» соседу. В данном случае нужно «рассказать». Нужно, чтобы роутер своим соседям рассказывал о подключенной к ней сети.
Делается это следующей последовательностью команд:
-router eigrp1
-network 192.168.1.0 0.0.0.255
-network 10.0.1.0 0.0.0.255

Последней командой роутер анонсирует подключенную к нему сеть (обведённой на рисунке красным кружком) другим роутерам (обведённым фиолетовым прямоугольником). Маска подсети в этом случае должна быть перевёрнутой (0 вместо 1 и 1 вместо 0).
Кроме того, что нужно рассказать о подключенной к роутеру сети, ещё нужно рассказать о другой сети, по которой роутер подключается к соседнему маршрутизатору. Иначе динамическая маршрутизация работать не будет. Для этого прописывается следующая команда.

Настройка по EGRP завершена. Роутер готов получать и отправлять маршруты. Теперь необходимо настроить соседний роутер.
Делается то же самое. Включается протокол динамической маршрутизации с тем же самым номером (на всех роутерах сети номер должен быть одинаков). В противном случае роутеры не будут обмениваться маршрутами. В случае второго роутера анонсируется сразу 3 сети.
-router eigrp1
-network 192.168.1.0 0.0.0.255
-network 10.0.1.0 0.0.0.255
— network 10.0.2.0 0.0.0.255

То же самое нужно проделать и на остальных роутерах. Проверить прописывание всех маршрутов следующей командой:
-do show ip route
Все установленные динамические маршруты обозначены буквой D.
Как получается, что все маршруты после всех этих настроек прописались? Имеется два роутера. Первым шагом, когда был прописан router eigrp 1 и когда в анонс была объявлена служебная сеть два роутера, стали обмениваться hello-пакетами. Первый роутер послал пакет другому роутеру и другой роутер первому роутеру тоже послал пакет, в котором каждый из маршрутизаторов сам себя анонсирует. Такой процесс называется установлением соседства. С помощью hello-пакетов оба роутера обнаружились, установили соседство и подружились. Вот он – пример установления соседства.
Когда было объявлено о сети 10.0.1.0, роутер сразу стал слать hello-пакеты. Но другой роутер ещё не был сконфигурирован, он молчал, соседство не устанавливалось. Как только был настроен другой роутер, объявили на нём сеть 10.0.1.0, другой роутер также начал посылать hello-пакеты, они увидели друг друга и установили соседство. Номер автономной системы совпадал и ничего не препятствовало маршрутизаторам подружиться между собой. В результате процесса обмена hello-пакетами они подружились, а информация об их «дружбе» попала в таблицу соседей. Что же это за neighbor-table. Вызывается она следующей командой
-router eigrp1
— show ip eigrp neighbors

В таблице показываются, какой с каким соседним роутером установлена связь. Здесь показано, что у крайнего слева роутера «дружба» установлена с показанным на рисунке ниже соседом. Также указан интерфейс, через который выполняется связь.

Итак, роутеры обменялись hello-пакетами, установили соседство. Информация об этом попала в таблицу соседей. После этого маршрутизаторы начинают друг другу «рассказывать» какие сети они знают. Какие у них есть сети. Один роутер формирует update-пакет и посылает другому роутеру список сетей, которые он «знает». Другой роутер отвечает АСК-пакетом, о том, что он получил информацию. После получения update-пакета в таблице маршрутизации (вызываются командой show-ip-route) были видны анонсированные сети.
На схеме выше больше двух роутеров. Соответственно, крайний справа роутер рассказал о своей сети и передал информацию соседнему роутеру. Второй справа роутер знает о своей сети и ещё о сети 192.168.4.0, о которой ему рассказал крайний справа роутер. Второй справа роутер рассказал второму слева роутеру о 3-й и 4-й сетях. А второй слева роутер рассказал первому слева роутеру рассказал update-пакетом о своей сети и о том, как добраться до 3-й и 4-й сети. Первый роутер формирует таблицу маршрутизации и понимает, что через «соседа» можно подключаться.
Также имеется ещё одна таблица – таблица топологии. Маршрут, который один роутер получает от другого роутера не сразу попадает в таблицу маршрутизации, а сначала попадает в таблицу топологии. а для чего? Маршрут в той же сети может прийти сразу от нескольких роутеров, и они попадают в таблицу топологии, а дальше роутер решает, какой из маршрутов наиболее лучший. И тогда уже лучший маршрут successor попадает в таблицу маршрутизации.
Как посмотреть таблицу топологии. С помощью команд:
-router eigrp1
-show ip topology

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

Если вдруг пропадёт одна connected-сетка, то роутер пошлёт такой же update-пакет, втором будет указано, что сеть потеряна. И тогда все остальные роутеры из своей таблицы маршрутизации выкинут потерянную сетку. Если сеть будет возвращена, то через какое-то время update-пакетом сеть будет возвращена.

Теперь рассмотрим понятие passive-interface.

Что такое passive-interface и зачем он нужен? При рассылке EIGRP-пакетов роутер посылает пакет на коммутатор, поскольку не знает, что это за устройство: switch или роутер. Его задача – рассказать всем о сетях, которые он знает. Это поведение бывает небезопасным. Почему небезопасно? Из-за злоумышленников, которые вместо коммутатора смогут поставить свой вредоносный роутер, который также будет посылать EIGRP-пакеты, он их будет принимать, а в этих пакетах от вредоносного роутера в пакетах будет информация о ложных маршрутах. и в результате, если маршрутов будет много, они будут какие-то неправильные соответственно сеть работать перестанет. И чтобы от такого защититься, нужно использовать passive-interface. Это такой интерфейс, за которым заведомо никогда не будет других роутеров. Если интерфейс будет сконфигурирован как passive, роутер не будет реагировать на EIGRP-пакеты по этому интерфейсу.

Если сейчас этот интерфейс сделать как passive и поставить какой-то вредоносный роутер, который попытается установить соседство с находящимся в сети роутером и послать ему какой-то пакет, какую-то неправильную маршрутную информацию, она будет проигнорирована роутером.

Хорошей тактикой в реальных сетях является установка passive-интерфейсов из тех интерфейсов, которые смотрят на конечных абонентов. Если имеется один роутер, который смотрит на другой какой-то роутер, а другими портами он смотрит на абонентов, то мы знаем, что там роутера быть не может, то мы ставим там passive-interface для защиты. Для этого необходимо перейти в настройки роутера и прописать последовательность команд.
-router eigrp1
-passive
-passive-interface
-passive-interface fa0/0

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

Теперь на некоторых из интерфейсов (смотрящих на другие роутеры) необходимо отменить пассивность. Делается это командой «no passive-interface fa8/0» (вместо fa8/0 прописывается название нужного порта)
Анонс сети. Сети анонсировались командой network. Дело в том, что система ранее работала с классовыми сетями. То есть маска подсети такая не использовалась, и анонсировалась без маски. Роутер соответственно смотрел, к какому классу сети она относится этот адрес и анонсировал всю классовую сеть. Если нам такое поведение не нужно, то хорошей практикой будет вручную переводить протокол EIGRP на работу с бесклассовыми сетями, на работу с маской переменной длины.
-router eigrp1
-network 192.168.2.0 0.0.255.255

Для того, чтобы выключить режим работы с классовыми сетями, нужно написать указанную ниже команду в контексте редактирования экземпляра EIGRP 1.
-no auto-summary

И это является хорошей практикой. Прежде чем анонсировать сети если мы работаем EIGRP, то обязательно нужно ввести эту команду, иначе в некоторых версиях она может игнорировать маску и анонсировать всю классовую сеть. И это может привести к дополнительным проблемам.

Диагностика сети. Вводим следующую команду:
-show ip protocols
Эта команда показывает конфигурацию динамических протоколов. Показывает, что работает протокол динамической маршрутизации с таким названием (Routing Protocol is “eigrp 1”).
Если, к примеру. пользователь забыл, номер экземпляра, он может ввести эту команду, и посмотреть его. Также он показывает количество маршрутов, показывает сети, которые он анонсирует:
Routing for networks
10.0.1.0/24
10.0.2.0/24
192.168.0.0/16
Показаны пассивные интерфейсы^
Passive Interface(s):
FastEthernet9/0
FastEthernet6/0

В общем, с помощью этой команды можно посмотреть суммарную статистику. Был бы запущен ещё какой-нибудь протокол, к примеру, OSPF, то можно было бы увидеть информацию подобного рода и по OSPF.
Следующая надпись показывает, сколько hello-пакетов было доставлено и получено.
Hellos sent/received 1271/962
Следующая надпись показывает, с какой частотой будут запускаться самим роутером все hello-пакеты:
-ip hellow-interval eigrp 1 10

Их можно регулировать. То есть для этого нужно зайти на какой-то интерфейс и прописать команду (рисунок ниже) для запуска hello-пакетов с частотой каждый 10 секунд.
-ip hold-timer eigrp 1 30
В большинстве сценариев это не требуется. Но если пользователь хочет, например, ускорить реакцию сети на какие-то изменения, к примеру, нужно ускорить реакцию на появление новой сети (анонсированной с помощью маски), то в команде (рисунок ниже) вместо 10 ставится 2, роутер будет чаще посылать hello-пакеты, и роутеры быстрее узнают о появлении новой сети.
Но при этом это повышает нагрузку на сеть (чем больше роутеров, чем чаще они генерируют пакеты, тем больше будет нагружена сеть служебным траффиком. Это уже не полезный траффик будет для пользователей – это служебный траффик будет, обеспечивающий работу сети. И большого количества маршрутизаторов не желательно. Также если какой-то роутер сломался (сгорел) и нужно, чтобы соседние роутеры быстрее узнали о том, что роутера больше нет, и что сети, до которых через него можно было добраться, больше недоступны, то в вышеприведенной команде значение делается меньше, чтобы роутеры понимали, что сосед «погиб» и подключенные к нему сети больше недоступны. При этом hold timer должен быть больше, чем hello-интервал.
Можно также включить вывод отладочной информации (на английском языке). Это называется debug, который может показать, что происходит с пакетами, которые передаются по сети. В данном случае нас интересуют пакеты, относящиеся к EIGRP. Выводится информация следующим образом.
Показаны hello-пакеты. Предоставлена информация о том, что в настоящее время происходит с пакетами. Для остановки вывода отладочной информации нужно прописать «undebug all» — все отладочные сообщения будут отключены. Следует отметить, что отладочные команды нужно запускать очень осторожно, поскольку они сильно нагружают процессор устройства и включение такого debug может привести к тому, что устройство попросту повиснет, поскольку центральный процессор будет выводить в консоль debug и ещё он будет пытаться выполнять там множество операций по маршрутизации траффика. И в результате процессорная очередь будет расписана на годы вперёд и устройство повиснет. Даже при включении вывод debug и сохранили конфигурацию, после перезагрузки debug не показывается потому, что он не сохраняется.

Метрика и балансировка траффика

Почему роутер из двух маршрутов выбирает какой-то один? Дело в том, что есть такое понятие, как метрика. Это число, которое показывает, насколько маршрут плох или хорош. В данном случае роутер видит, что метрика через верхний роутер меньше, чем метрика через прямое подключение (нижний маршрутизатор). А если она меньше, то она лучше и траффик всегда направляется по пути с меньшей метрикой.
К примеру, роутеру пришло два маршрута и он выяснил, что их метрика для верхнего маршрута лучше, чем метрика до нижнего, в результате чего он принял решение и в таблицу маршрутизации записал маршрут с наименьшей метрикой.

А почему у верхнего маршрута метрика меньше, чем у нижнего? Метрика берётся не просто так, а она высчитывается по формуле и в этой формуле присутствует множество различных параметров в том числе и скорость интерфейса. Когда роутер посчитал, он понял, что нижний маршрут – 10 Мбит, и когда он посчитал проходящий через 10 Мбитный канал маршрут, он насчитал указанное на рисунке ниже число (рисунок взят из таблицы топологии).
Затем роутер посчитал маршрут через верхний маршрутизатор и увидел, что там 100 Мбитный канал, а поскольку скорость прохождения траффика там будет выше, метрика будет ниже, этот маршрут будет лучше, быстрее и эффективнее. Поэтому трафик будет направлен по 100 Мбитному каналу. Если вдруг этот маршрут «погибнет», то тогда ему не останется ничего другого как направлять этот траффик по 10 Мбитному каналу и в таблице маршрутизации можно будет увидеть прохождение траффика по плохому нижнему каналу, поскольку других вариантов просто нет. Но когда есть лучший маршрут с меньшей метрикой, то он будет непосредственно направляться по маршруту с наименьшей метрикой.
Теперь пришла очередь рассмотреть такие понятия, как successor и feasible successor.
Successor это тот маршрут который наиболее выгоден в настоящий момент времени. По данной таблице топологии successor до 3-й сети является указанный на рисунке ниже маршрут (через верхний роутер-successor). Этот маршрут вбрасывается в таблицу маршрутизации и становится ем маршрутом, через который будет проходить траффик.
Feasible successor это запасной маршрут, который также находится в таблице топологии, но будет использован в том случае, если «упадёт» основной successor.
Команда show-ip-eigrp-topology показывает только successor и feasible successor. Но бывает не только successor и feasible successor, но и другие маршруты, к примеру, маршруты с другими маршрутизаторами с совсем плохой метрикой. Эти маршруты невозможно увидеть по указанной на рисунке ниже команде, а только successor и feasible successor.

Для того, чтобы увидеть и худшие маршруты, которые не соответствуют метке successor и feasible successor, необходимо прописать указанную на рисунке ниже.
Дополнительные маршруты, которые не соответствуют метке successor и feasible successor, использовались в случае, если бы «погибли» successor и feasible successor. Тогда бы другие маршруты были бы использованы при их наличии. Кроме того, что имеется первое число метрики (показано на рисунке ниже) имеется ещё и находящееся рядом второе число, которое также показывает метрику, но первое число показывает то, как метрику считает маршрутизатор, а второе число как эту метрику посчитал соседний роутер и прислал число.

Нужно понимать, что в update-пакетах, роутер присылает не только маршруты до удалённых сетей, не только рассказывает другому роутеру о том, что он «знает» как добраться до сети, но они ещё дают информацию о метрике. В общем, один роутер рассказывает другому о том, как добраться до сети 4.0.

Затем роутер, получив update-пакет, сам считает метрику, по которой он может добраться до сети и к присланной соседом метрике он добавляет ещё и свою стоимость пути. Так и получается конечная метрика.

Последовательность получения метрики. предположим. что роутер видит, что 4-я сеть у него «connected». Нужно рассчитать метрику. Предположим, что метрика равна 1.
Отмеченный на рисунке ниже красным квадратом роутер рассказывает об этом соседнему роутеру и этот роутер также считает, как добраться до 4-й сети. Он видит, что до своего соседа можно добраться с метрикой равной 1 и к этой 1 он прибавляет то число, за которое сеть 4.0 знает отмеченный красным квадратом роутер.

В итоге этот роутер знает, как добраться до 4-й сети за две единицы. Он информацию о двух единицах посылает следующему (отмеченному на рисунке) роутеру.
Следующий роутер измеряет трассу до предыдущего роутера и тоже получает единицу.

К этой единице он прибавит число, которое ему прислал предыдущий роутер.

То есть он ему прислал две единицы. Теперь отмеченный красным роутер знает, как добраться до 4-й сети за три единицы. То есть у него своя единица (на промежутке 10.0.2.1 – 10.0.2.2), плюс единица (промежуток 10.0.3.1 – 10.0.3.2) и плюс ещё одна единица (порт 192.168.4.1 – коммутатор).
Далее этот роутер следующему роутеру «рассказывает» о том, что он «знает» как добраться до 4-й сети за три единицы. В результате роутер меряет трассу, прибавляет свою единицу и единицы отмеченных красным на рисунке ниже единиц.

В итоге получается четыре единицы, за которые роутер сможет добраться до сети 4.0. Но единица – это понятие условное. На самом деле метрика указывается в виде указанных ниже чисел.
Таким образом по цепочке меряется метрика.
В данный момент видно, что согласно таблице маршрутизации, в качестве successor выбран верхний роутер, поскольку трасса до него более быстрая, чем прямая 10-Мегабитная трасса. Роутер с портом 10.0.2.2 стал feasible successor.

Теперь нужно представить ситуацию, что было бы, если бы, если бы трасса между портами 10.0.2.1 – 10.0.2.2 было не 10-, а 100-Мегабитная. Как бы пошёл траффик от этого роутера. В качестве successor выбран был бы прямой маршрут.

Потому, что маршрут напрямую гораздо дешевле, у него метрика меньше, чем у маршрута, где есть какие-то другие маршрутизаторы. Дело в том, что у устройства у маршрутизатора он работает с какой-то конечной скоростью. У него есть задержки на интерфейсы, у него есть процессор, выполняющий маршрутизацию. Поэтому пакет, который роутер выпустит напрямую, дойдёт быстрее, чем пакет, который был бы выпущен и проходил бы через верхний роутер. При условии, что все каналы одинаковы и 100-Мегабитные. Когда нижний маршрут сделали 10-Мегабитным, то несмотря на то, что в цепочке встречаются ещё одно устройство, все равно оно быстрее, чем 10-Мегабитное соединение.
Теперь следует рассмотреть, как рассчитывается метрика. Ниже стандартная формула расчёта метрики.
Метрика = (107/min bandwidth в Кбайт) *256+(задержка1*100+ задержка2*100…) *256

Величина minimum bandwidth. К примеру роутеру R1 нужно добраться до сети, находящейся за спиной у роутера R4. И ему нужно решить, как пускать траффик: толи пускать по верхней сети, то ли по нижней. И он (R1) начинает рассчитывать эту метрику. Метрика, которая будет наименьшей, и будет использоваться. minimum bandwidth минимальная пропускная способность и самое узкое место трассы.

И R1 будет об этом знать. Ведь роутер R4 рассказывает соседнему, а тот рассказывается всем по цепочке. Поэтому R1 и знает, что имеется 10-Мегабит.

Кроме того, что учитывается минимальная скорость, ещё учитывается сумма задержек на интерфейс. У интерфейсов роутеров есть определённая задержка. Это время, за которое в буфер попадают какие-то данные и выходят. Буфер есть не только у коммутаторов, но и у роутеров также. ТО есть у нас как бы интерфейсы идут с какой-то конечной скоростью. У сетевого оборудования Cisco скорость измеряется в миллисекундах и микросекундах. На примере показана задержка в миллисекундах. То есть при расчётах метрики, когда R1 рассчитывает метрику, он учитывает скорость и учитывает задержку на интерфейс. А когда он это все посчитает, он получит конечное число. Давайте сейчас определим, как пойдёт траффик через верхнюю трассу или через нижнюю. Рассчитаем по формуле с помощью калькулятора в инженерном режиме. Подставляя в указанную выше формулу значения, получаем метрику по верхней трассе 2 816 000 и по нижней трассе 1 587 200. Весь свой траффик роутер направит через нижнюю трассу.
Имеется также и более сложная формула расчетов метрики.
Так, в формулу можно добавить показатели надёжности интерфейсов reability, показатель загрузки интерфейса. Такое присутствие в протоколе EIGRP использовать не рекомендуется. Почему оно по умолчанию не включено? Потому, что расчёт метрики по дефолту (по умолчанию) более надёжен. К примеру, скорость 100 МБ не изменится, и задержка на интерфейсах есть, на конечные она нужна производителям, и она также не изменится. И метрика она будет всегда стабильна.

А вот загрузка она «плавает». В один промежуток времени загрузка интерфейса одна в другой промежуток времени загрузка интерфейса другая. В результате метрика будет всё время «плавать». И траффик будет направляться то по верхней, то по нижней трассе. Ну, казалось бы, ничего страшного, поменялась загрузка на интерфейс (кто-то торрент начал качать) пошли по нижней трассе. Здесь нагрузка повысилась пошли по верхней трассе. Это нехорошо. Дело в том, что каждый раз со сменой метрики будет происходить пересчёт топологии. В результате чего на какой-то момент доступа к сети «за спиной» R4 вообще не будет. То есть пользователь, находящийся «за спиной» R1 из этой сети обращается к серверу, находящемуся за спиной R4 на какое-то время, каждый раз у нас меняется метрика, каждый раз на какое-то незначительное время будет пропадать доступ, пока будет идти пересчёт топологии. Каждый раз, когда будет приниматься решение, по какой трассе идти траффику, каждый раз пользователь будет терять доступ. Поэтому нежелательно использовать показатель надёжности и особенно загрузки на интерфейсах при расчётах метрики. Будет постоянно прыгать из трассы на трассу, будет постоянно терять доступ к сетевым ресурсам и ни к чему хорошему это не приведёт. Поэтому лучше всегда пользоваться стандартной настройкой по умолчанию, когда в формуле вместо четырёх параметров учитывается только два: минимальная пропускная способность, то есть скорость и сумму задержек интерфейсов по всей длине трассы.
Надёжность основана на keepalive-пакетах. К прмеру, от R2 до R3 отправился пакет keepalive-пакет, для проверки состояния R3. Если R3 в течение определённого времени отвечает, то такое соединение является наиболее надёжным. Если же R3 «умер», то в зависимости от того, насколько часто «отвечал» роутер, трасса станет менее надёжной. Если R3 на протяжении всего месяца отвечал один раз, то такая трасса будет наименее надёжной, если же он отвечал безотказно, то наиболее надёжной.
Показатели надёжности в одном из роутеров. К примеру, в роутере Router3 нужно посмотреть эти параметры.
-show int eth4/0

В данном случае надёжность максимальна (измеряется значением от 1 до 255).
reliability 255/255

Показатели задержки (в микросекундах).
DLY 1000 usec

Еще имеются коэффициенты, добавляемые в формулу расчёта метрики. Ниже показаны коэффициенты по умолчанию (в только что купленном роутере).
К1=К3=1; К2=К4=К5=0
При смене этих коэффициентов метрика получится больше. Ниже показана формула рассчёта метрики с учётом вышеуказанных коэффициентов.
Metric = [K1B+ ((K2 B) /(256 L)) + K3D],

В этой формуле учитывается два дополнительных параметра, которые не рекомендуется включать (загрузка на интерфейс, надёжность). В общем, данная формула предназначена для расчёта метрики при нестандартных ситуациях, когда коэффициенты изменены системным администратором и когда учитывается два дополнительных параметра загрузка на интерфейс и надёжность.

Может так случиться, что обе трассы будут с одинаковой метрикой. Тогда произойдет балансировка траффика, когда один пакет пойдёт по одному пути, другой по-другому. И так по очереди.
Отметим, что балансировку траффика можно выполнять и на трассах с неравной стоимостью (метрикой). Балансировку траффика по трассах с неравной стоимостью можно сделать только в EIGRP. Включаем балансировку траффика.
-enabled
-conf ter
— variance 6

Число 6 показывает, во сколько раз маршрут с большей метрикой хуже, чем с меньшей. Если плохой маршрут будет хуже не более чем в 6 раз, то балансировка будет выполняться. Но если больше, то балансировка выполняться не будет. Кстати, балансировку траффика можно выполнять только между successor и feasible successor. Как определить, стал маршрут feasible successor или не стал. Только из таблицы топологии. В итоге получается, что чётные пакеты идут по одной трассе, а нечётные по другой. Эту логику можно изменить. Чтобы большая часть пакетов шла по трассе с лучшей метрикой, а другая (меньшая часть) шла по маршруту с меньшей метрикой. Делается это командой, указанной на рисунке ниже.
-traffic share balanced

В результате, чем лучше метрика у маршрута, тем больше будут на него направляться пакеты. Указанная ниже команда указывает на необходимость направлять весь траффик только по маршруту с наименьшей метрикой.
-traffic share min

Также нужно обратить внимание на указанную на рисунке ниже команду
-metric maximum-hops<1-255>
По умолчанию, если роутер поймёт, что ему добраться до 4-й сети необходимо через определённое 100 роутеров, то он признает эту сеть недоступной. Она слишком далеко, необходимо слишком много next-hop сделать для того, чтобы до неё добраться. По умолчанию он эту сеть признает недействительной. Такое поведение по умолчанию можно изменить, если прописать указанную выше команду и написать число. К примеру. если указать число 255, то сеть будет признаваться недостижимой, если она будет находиться через 256 роутеров. Либо можно сделать так, чтобы сеть была признана недостижимой, если имеется больше двух роутеров.

Теперь что касается количества маршрутов, по которым будет проходить балансировка. В данном случае их было только два. Если имеется их большое количество, то роутер будет выполнять балансировку траффика хоть по трассам равной, хоть неравной стоимости только по четырём маршрутам. В этом можно убедиться только задав команду show ip protocol
Максимум балансировка будет выполняться по четырём маршрутам. Можно изменить это поведение и сказать, что нужно балансировать траффик по маршрутам большего количества. Делается это указанной ниже командой.
Правило split-horizon. Если роутер Router 3 узнал о 2-й сети через свой интерфейс, то он не будет по этому интерфейсу рассказывать о том, что он «знает» эту сеть. Он об этом расскажет по другому интерфейсу. Но по интерфейсу, по которому он узнал об этой сети он рассказывать не будет. Делается это во избежание образования петель маршрутизации. Следует отметить, что в таблице топологии при показе маршрутов второе число должно быть меньше первого. Тогда не будет петель маршрутизации.
Что произойдёт, если, к примеру, 1-я сеть перестанет быть доступной. В этом случае Router 0 будет пытаться найти маршрут до потерянной сети. Он будет пытаться выяснить, а можно ли добраться до сети через какие-то другие маршрутизаторы. Было рассмотрено несколько типов пакетов (hello, update и так далее). Существует ещё 4 типа пакетов: Queries, Replies, SIA-Queries и SIA-Replies. Когда у роутера «отваливается» сеть, он пытается выяснить, можно ли добраться до потерянной сети через другие маршрутизаторы. Для этого он генерирует пакет, который называется Queries и посылает его на соседний роутер, у которого спрашивает, о возможности добраться до 1-й (потерянной) сети. Router3 формирует такой же Queries-пакет и посылает Router4 (соседу) о возможности добраться до потерянной сети. Сосед «знает» как добраться до 1-й сети и формирует Reply-пакет и отправляет его на соседний роутер, а тот – на Router0. В результате с помощью Reply-пакета роутер теперь будет знать, что потерянная сеть достижима через Router4. В результате Router0 перестраивает свою таблицу маршрутизации. Существует также такое состояние, такое состояние, которое называется Stuck-in-Active. И может случиться такое, что Router0 спрашивает у соседнего роутера (Router3) о возможности добраться до 1-й сети, тот в свою очередь спрашивает у Router4. Router4 знает, формирует Reply-пакет, который теряется по пути и не доходит до Router0. Роутер не сможет добраться до 1-й сети, поскольку Reply-пакет потерян. Чтобы такого не было, существует ещё одна группа пакетов, которая называется SIA-Queries и SIA-Replies.
Router 0 «спрашивает» у соседнего роутера Router 3 обычным Query-пакетом о возможности добраться до 1-й сети. Router 3 спрашивает у Router 4 о возможности добраться до 1-й сети. Router 4 формирует Reply-пакет, который теряется по дороге. Тогда Router 0 считает до 2 минут 50 секунд и направляет SIA-Query и повторно спрашивает у Router 3 о 1-й сети. Router 3 в ответ направляет SIA-Reply, ссылаясь на задержку Router 4. Тогда Router0 увеличивает таймер. Теперь он знает, что нужно немного подождать, чтобы «подстроиться» под задержку других роутеров. Router3 в свою очередь также направляет на Router4 SIA-Query и спрашивает у Router 4. Router 4 с помощью SIA-Reply повторно отвечает о маршруте доступа к 1-й сети. А также повторно отправляет Reply.
Касательно таймеров каждый роутер ждет 3 минуты ответа от вышестоящего роутера. Если проходит 2 минуты и 55 секунд и ответа так и не было, то отправляется уже SIA-Query для того, чтобы напомнить о своём запросе. Если ответ так и не приходит, то сеть считается потерянной навсегда и происходит изменение топологии. То есть роутер признаёт тот факт, что он не может добраться до той сети, которую он потерял и больше не совершает никаких попыток до неё добраться и выкидывает её из таблицы маршрутизации.
Существует такое понятие, как stub-роутер. Если сконфигурировать роутер ка stub, то он не будет ни у кого спрашивать, как добраться до сети, если он её потерял. И у него никто не будет спрашивать на предмет доступа к сетям. Предположим, что Router5 может добраться до 1-й сети через Интернет.
Получается, что Router0 может добраться до 1-й сети по прямому проводу, либо через цепочку роутеров (Router3-Router5) и затем через Интернет. В итоге он всё равно доберётся до 1-й сети. Если прямой доступ к 1-й сети отключается, то Router0 начинает «спрашивать», как добраться до 1-й сети.

В результате Router5 «отвечает» reply-пакетами о возможности доступа до 1-й сети через Интернет.
В итоге Router0 меняет свою таблицу маршруизации и начинает весь траффик направлять на Router5. Но в некоторых случаях такая ситуация может стать нежелательной (ведь за Интернет-траффик нужно платить). Мы хотим, чтобы роутер мог через Интернет «добираться» до 1-й сети, но не хотим, чтобы другие роутеры «добирались» до сети через Интернет. Если нам такая ситуация не желательна, то можно сконфигурировать конечный роутер Router5 как stub. Делается это указанной на рисунке ниже командой.
-eigrp1 stub
После ввода этой команды конечный роутер станет как stub. Даже несмотря на то, что он знает, как добраться до 1-й сети (в данном случае через Интернет), он не будет об этом рассказывать другим. И при этом он не будет отвечать на Query-запросы, первоначально сформированные Router0, и вообще не будет опрашиваться, а первая сетка будет безвозвратно потеряна. Такая ситуация используется на практике. Допустим, имеется два основных и один филиальный дата-центр. И два основных дата-центра соединены между собой и обмениваются траффиком. Вдруг связь между двумя дата-центрами прерывается. а если не настроить stub-роутер, то может произойти ситуация, когда трафик из одного дата-центра пойдёт через дорогие и медленные каналы филиала. То есть весь траффик от одного дата-центра пойдёт через филиал до другого. Произойдёт перегрузка канала с меньшим пропуском, да ещё и огромный счёт за Интернет. Поэтом у и настраивается stub. Если вдруг прямая связь от одного дата-центра до другого вдруг «упадёт», чтобы маршрут не был построен через филиальный дата-центр с медленными Интернет-каналами. И кроме того, это сможет увеличить скорость сходимости сети. При потере сети Router0 уже не будет опрашивать Router5, будет быстрее признавать 1-ю сеть с оборванным каналом потерянной навсегда и быстрее перестраивать топологию.
В команде настройки роутера в качестве stub имеется несколько дополнительных подкоманд.
connected – Если у роутера спросят, есть ли у него какая-то сеть, то он будет «рассказывать» только о тех сетях, которые непосредственно подключены к нему. А о тех сетях, о которых он узнал от других соседей, он рассказывать не будет.
receive-only запретит роутеру вообще рассказывать о каких-либо сетях. Он будет только получать пакеты.
distributer будет разрешать рассказывать роутеру о тех маршрутах, которые он получил из других протоколов динамической маршрутизации. Может быть такая ситуация, при которой в таблицу маршрутизации Router5 попадают маршруты не только из той сети, в которой он «живёт» но и из внешнего источника, из каких-то других протоколов динамической маршрутизации. Эта команда redistributed будет разрешать «рассказывать» роутеру об этих сетях.
static будет разрешено рассказывать о маршрутах, которые были написаны вручную.
summary Будет разрешено рассказывать о суммированных маршрутах.

Работа в NMBA-сетях

Что такое NBMA-сети. Все знают, что Ethernet это протокол, работающий на канальном уровне OSI и мы знаем, что есть МАС-адреса, адресация по МАС-адресам и так далее. Но есть и другие протоколы канального уровня, в данном случае FrameRelay это протокол канального уровня. Обычно такое протокол канального уровня работает по Serial Link-ам.

В данном случае адресация уже не по МАС-адресам, а по адресам, по-другому выглядящим на данном уровне. Какое отличие Ethernet от протокола FrameRelay. Framerelay протокол, образующий NBMA сети, в которых нет broadcast и multicast. То есть в Ethernet можно было отправить какой-то кадр, мы бы поставили адрес FFFFFFFF и этот кард дошёл бы сразу до всех этих роутеров либо до какой-то группы участников (multicast-адрес). В MBMA-сетях такого нет. Невозможно взять какой-то кадр и отправить сразу на всех участников. Также невозможно использовать multicast и направить какой-то кадр группе. Для того, чтоб ы отправить какой-то кадр нужно отдельно отправлять на каждый из изображённый на рисунке выше роутеров. Из-за того, что невозможно направить такой мультикастовый кадр, не будет работать система автоматического обнаружения соседей. Для того, чтобы каждый роутер подружился со своими соседями, необходима вручную прописывать IP-адресацию соседей и их канальную адресацию. То есть на роутере необходимо на только сеть анонсировать, но и ещё вручную прописать сеть соседа, с которым нужно «подружиться». В последней строке необходимо ещё указать канальный адрес соседа. И так необходимо прописывать для связи с каждым роутером.
-enabled
-conf ter
-router eigrp1
-network 192.168.0.2 0.0.255.255
-neighbor 192.168.0.3 serial2

В NBMA сети может быть ситуация, когда R2 «смотрит» на R4, а на R3 не смотрит. Либо R3 «смотрит» на R2, а на R4 «не смотрит»
Для того, чтобы сеть работала необходимо отключить split Horizon. Чтобы R1 узнав, к примеру, про сеть с роутером R4, смог рассказать о ней маршрутизаторам R2 и R3. Если же на R1 будет включён split-horizon этот роутер, получив информацию о R4-сети, уже не сможет о ней рассказать другим роутерам (R2, R3).
Как можно работать с NBMA. Можно создать субинтерфейсы. Это когда один физический интерфейс разделяется на три логических интерфейса. В результате на один и тот же физический интерфейс можно «повесить» несколько ІР-адресов из разных подсетей.

В результате возникает связь типа «point-to-point» каждый смотрит на каждого. Один участник с одной стороны, и один с другой.
Аутентификация по ключевым цепочкам

Такая операция делается для безопасности. Без аутентификации два роутера «видят» друг друга и устанавливают между собой связь. Но может случиться такое, что внутри сети появится какой-то недобросовестный сотрудник со знанием сетевых технологий, который захочет навредить сети. Возьмёт какой-то роутер, подключит его к другому роутеру, passive-интерфейс не будет там сконфигурирован, роутер злоумышленника установит связь с роутером сети и тот сбросит ему имеющуюся у него таблицу маршрутизации с абсолютно «левыми» маршрутами. Затем, к примеру, роутер может указать, что выход в Интернет через него. И тогда все роутеры перечитают топологию, допустим, маршрут до Интернета сбросят с лучшей метрикой. Пересчитается топология, пересчитают роутеры свои маршруты и будут выходить в Интернет, через роутер злоумышленника. Понятно, что роутер злоумышленника никакого выхода в Интернет на самом деле не имеет и сеть работать перестанет. Чтобы такого не было, и чтобы никто посторонний не мог внедриться в сеть предприятия со своим маршрутизатором у EIGRP-протокола имеется защита аутентификация по ключевым цепочкам.
Ниже представлен пример настройки аутентификации.
Выполняется синхронизация времени
-enabled
-conf ter
-do show clock
-clock set ? (По подсказкам вводится текущее время)
-show clock

Установка первого ключа MYCHAIN
-enabled
-conf ter
-key chain MYCHAIN
Установка первого ключа и его пароля
-key 1
key-string cisco
Установка времени его принятия/отправки соседу и время, когда перестанут его принимать/отправлять.
-key 1
-key-string cisco
-accept-lifetime 18:00 aug 31 2015 18:00:00 sep 2 2015

Тоже самое проделывается и для другого ключа.

-key 2
key-string cisco
accept-lifetime 18:00 aug 31 2015 18:00:00 sep 2 2015

Таких ключей можно сделать любое количество.

Теперь можно перейти к настройке интерфейса, которым роутер смотрит на соседа.
-int fa0/1
ip authentification mode eigrp 1 md5
ip authentification key-chain eigrp 1 MYCHAIN

Включил