Сетевые маршруты что это

ISDN

Быстрое введение в ISDN:

Стоимость является важным фактором при выборе вашего решения. Далее перечислены все возможности от самого дешевого до самого дорогого варианта.

Адаптеры ISDN

Реализация ISDN во FreeBSD поддерживает только стандарт DSS1/Q.931 (или Евро-ISDN) при помощи пассивных адаптеров. Поддерживаются некоторые активные адаптеры, прошивки которых поддерживают также другие сигнальные протоколы; также сюда включена поддержка адаптеров ISDN Primary Rate (PRI).

Пакет программ isdn4bsd позволяет вам подключаться к другим маршрутизаторам ISDN при помощи IP поверх DHLC, либо при помощи синхронного PPP; либо при помощи PPP на уровне ядра с isppp, модифицированного драйвера sppp(4), или при помощи пользовательского ppp(8). При использовании пользовательского ppp(8) возможно использование двух и большего числа B-каналов ISDN. Также имеется приложение, работающее как автоответчик, и много утилит, таких, как программный модем на 300 Бод.

Во FreeBSD поддерживается все возрастающее число адаптеров ISDN для ПК, и сообщения показывают, что они успешно используются по всей Европе и других частях света.

Из пассивных адаптеров ISDN поддерживаются в основном те, которые сделаны на основе микросхем Infineon (бывший Siemens) ISAC/HSCX/IPAC ISDN, а также адаптеры ISDN с микросхемами от Cologne Chip (только для шины ISA), адаптеры PCI с микросхемами Winbond W6692, некоторые адаптеры с набором микросхем Tiger300/320/ISAC и несколько адаптеров, построенных на фирменных наборах микросхем, такие, как AVM Fritz!Card PCI V.1.0 и AVM Fritz!Card PnP.

На данный момент из активных адаптеров ISDN поддерживаются AVM B1 (ISA и PCI) адаптеры BRI и AVM T1 PCI адаптеры PRI.

Для обсуждения вопросов, связанных с установкой, настройкой и устранением неисправностей isdn4bsd, имеется список рассылки freebsd-isdn.

Терминальные адаптеры ISDN

Терминальные адаптеры (TA) для ISDN выполняют ту же роль, что и модемы для обычных телефонных линий.

Большинство TA используют стандартный набор AT-команд Hayes-модемов, и могут использоваться в качестве простой замены для модемов.

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

TA полностью полагаются на даемон PPP, который используете из-за его возможностей и стабильности соединения. Это позволяет вам при использовании FreeBSD легко заменить модем на ISDN, если у вас уже настроено соединение PPP. Однако, в тоже время любые проблемы, которые возникают с программой PPP, отражаются и здесь.

Если вы хотите максимальной надёжности, используйте PPP на уровне параметра ядра, а не пользовательский PPP.

Известно, что следующие TA работают с FreeBSD:

Большинство остальных TA, скорее всего, тоже будут работать, производители TA прилагают все усилия для обеспечения поддержки практически всего набора стандартных AT-команд модема.

Как и в случае модемов проблемой использования внешнего TA является потребность в хорошем последовательном адаптере на вашем компьютере.

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

TA, работающий со стандартным последовательным (асинхронным) портом PC, ограничивает вас скоростью 115.2 Кбит/с, хотя реально у вас соединение на скорости 128 Кбит/с. Чтобы использовать 128 Кбит/с, которые обеспечивает ISDN, полностью, вы должны подключить TA к синхронному последовательному адаптеру.

Не обманывайте себя, думая, что покупка встроенного TA поможет избежать проблемы синхронности/асинхронности. Встроенные TA просто уже имеют внутри стандартный последовательный порт PC. Все, что при этом достигается — это экономия дополнительных последовательного кабеля и электрической розетки.

Синхронный адаптер с TA по крайней мере так же быстр, как и отдельный маршрутизатор, а если он работает под управлением машины класса 386 с FreeBSD, то это гораздо более гибкое решение.

Выбор между использованием синхронного адаптера/TA или отдельного маршрутизатора в большей степени является религиозным вопросом. По этому поводу в списках рассылки была некоторая дискуссия. Рекомендуем поискать в архивах обсуждение полностью.

Отдельные мосты/маршрутизаторы ISDN

Мосты или маршрутизаторы ISDN не так уж специфичны для FreeBSD или для любой другой операционной системы. Для более подробного описания технологий маршрутизации и работы мостов, пожалуйста, обратитесь к справочникам по сетевым технологиям.

В контексте этого раздела термины маршрутизатор и сетевой мост будут использоваться как взаимозаменяемые.

Вместе с падением цен на простые мосты/маршрутизаторы ISDN, они становятся все более популярными. Маршрутизатор ISDN представляет собой маленькую коробочку, которая подключается непосредственно в вашу сеть Ethernet, и поддерживает связь с другим мостом/маршрутизатором. Всё программное обеспечение для работы по PPP и другим протоколам встроено в маршрутизатор.

Маршрутизатор обладает гораздо большей пропускной способностью, чем стандартный TA, так как он использует полное синхронное соединение ISDN.

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

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

Например, для соединения домашнего компьютера или сети подразделения к сети центрального офиса, может использоваться такая настройка:

Пример 1. Офис подразделения или домашняя сеть

Сеть построена в топологии общей шины на основе 10 base 2 Ethernet («thinnet» — «тонкий Ethernet»). Подключите маршрутизатор к сетевому кабелю с помощью трансивера AUI/10BT, если это нужно.

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

Пример 2. Центральный офис или другая локальная сеть

Сеть построена в топологии звезды на основе 10 Base T Ethernet («витая пара»).

Одним большим преимуществом большинства маршрутизаторов/мостов является то, что они позволяют иметь 2 отдельных независимых соединения PPP к 2 различным сайтам одновременно. Это не поддерживается в большинстве TA, кроме специальных (обычно дорогих) моделей, имеющих по два последовательных порта. Не путайте это с балансировкой нагрузки, MPP и так далее.

Это может оказаться весьма полезной особенностью, например, если у вас имеется постоянное ISDN-соединение в вашем офисе, и вы хотите им воспользоваться, но не хотите задействовать дополнительный канал ISDN на работе. Маршрутизатор, расположенный в офисе, может использовать выделенное соединение по каналу B (64 Кбит/с) для Интернет, и одновременно другой канал B для отдельного соединения для передачи данных. Второй канал B может использоваться для входящих, исходящих и динамически распределяемых соединений (MPP и так далее) совместно с первым каналом B для повышения пропускной способности.

Мост Ethernet также позволяет вам передавать больше, чем просто трафик IP. Вы сможете передавать IPX/SPX и любые другие протоколы, которые вы используете.

IP-план

Теперь нам было бы весьма кстати составить IP-план. Будем исходить из того, что на всех трёх точках мы будем использовать стандартную сеть с маской 24 бита (255.255.255.0) Это означает, что в них может быть 254 устройства.

В данный момент (вспомним нулевой выпуск) у нас в Москве использованы адреса 172.16.0.0-172.16.6.255. Предположим, что сеть может ещё увеличиться здесь, допустим, появится офис на Воробьёвых горах и зарезервируем ещё подсети до 172.16.15.0/24 включительно.
Все эти адреса: 172.16.0.0-172.16.15.255 — можно описать так: 172.16.0.0/20. Эта сеть (с префиксом /20) будет так называемой суперсетью, а операция объединения подсетей в суперсети называется суммированием подсетей (суммированием маршрутов, если быть точным, route summarization)

Очень наглядный IP-калькулятор. Я и сейчас им периодически пользуюсь, хотя со временем приходит интуитивное и логическое понимание соответствия между длиной маски и границами сети.

Теперь обратимся к Питеру. В данный момент в этом прекрасном городе у нас 2 точки и на каждой из них подсети /24. Допустим это будут 172.16.16.0/24 и 172.16.17.0/24. Зарезервируем адреса 172.16.18.0-172.16.23.255 для возможного расширения сети.

172.16.16.0-172.16.23.255 можно объединить в 172.16.16.0/21 — в общем-то исходя именно из этого мы и оставляем в резерв именно такой диапазон.

В Кемерово нам нет смысла оставлять такие огромные запасы /21, как в Питере (2048 адресов или 8 подсетей /24), или тем более /20, как в Москве (4096 или 16 подсетей /24). А вот 1024 адреса и 4 подсети /24, которым соответствует маска /22 вполне рационально.

Таким образом сеть 172.16.24.0/22 (адреса 172.16.24.0-172.16.27.255) будет у нас для Кемерово.

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

Это 8 команд и 8 записей в таблице. Но при этом пришедший на маршрутизатор пакет в любую из сетей 172.16.16.0/21 в любом случае будет отправлен на устройство с адресом 172.16.2.2.
Вместо этого мы поступим так:

ip route 172.16.16.0 255.255.248.0 172.16.2.2

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

Мы просто берём сеть с самой маленькой возможной маской — 30 (255.255.255.252) — это сеть на 4 адреса. Почему мы не можем взять сеть с ещё более узкой маской? Ну 32 (255.255.255.255) по понятными причинам — это вообще один единственный адрес, сеть 31 (255.255.255.254) — это уже 2 адреса, но один из них (первый) — это адрес сети, а второй (последний) — широковещательный. В итоге на адреса хостов у нас и не осталось ничего. Поэтому и берём маску 30 с 4 адресами и тогда как раз 2 адреса остаются на наши два маршрутизатора.

Вообще говоря, самой узкой маской для подсетей в cisco таки является /31. При определённых условиях их можно использовать на P-t-P-линках.
Что же касается маски /32, то такие подсети, которые суть один единственный хост используются для назначения адресов Loopback-интерфейсам.

Именно так мы и поступим. Для этого, собственно, в нулевой части мы и оставили сеть 172.16.2.0/24 — её мы будем дробить на мелкие сетки /30. Всего их получится 64 штуки, соответственно можно назначить их на 64 линка.

Здесь мы поступили так же, как и в предыдущем случае: сделали небольшой резерв для Питера, и резерв для Кемерово. Вообще резерв — это всегда очень хорошо о чём бы мы ни говорили. 😉

Таблица маршрутизации

Эту информацию маршрутизатор хранит в таблице маршрутизации. На картинке ниже показан ее упрощенный вид, в которой некоторые служебные столбцы удалены для простоты понимания.

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

Таблица маршрутизации Windows

Столбец шлюз, говорит что делать с пакетом, который вышел через заданный интерфейс. Для сетей, которые подключены напрямую к маршрутизатору D, в столбце шлюз, указывается «подсоединен», которое говорит о том, что сеть подключена непосредственно к маршрутизатору и передавать пакет нужно напрямую в эту сеть.

Таблица маршрутизации Linux

Только следующий шаг!

Часто возникает вопрос, что делать, если сеть для который пришел пакет находится не за одним маршрутизатором? Чтобы в неё попасть, нужно пройти не через один, а через несколько маршрутизаторов, что в этом случае нужно вносить в таблицу маршрутизации.

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

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

Таблицы маршрутизации#

Таблицы маршрутизации содержат набор правил (маршрутов), которые используются для направления сетевого трафика.

Каждая подсеть в VPC связана с таблицей маршрутизации.
При необходимости вы можете ассоциировать подсеть с произвольной таблицей маршрутизации, подсети без явной ассоциации будут автоматически связаны с основной таблицей.

Глоссарий#

Таблица маршрутизации — таблица маршрутизации, которую вы создаёте для своего VPC.

Основная таблица маршрутизации — таблица маршрутизации, которая автоматически добавляется при создании VPC. Она контролирует маршрутизацию всех подсетей VPC, которые не ассоциированы явно с одной из таблиц маршрутизации.

Распространение маршрутов — если включена, то маршруты ваших VPN-соединений будут динамически попадать в указанную таблицу маршрутизации.

Шлюз — стандартный шлюз в Интернет, VPN-соединение, экземпляр или сетевой интерфейс, куда следует отправлять трафик в рамках текущего правила.

Алгоритм выбора маршрута#

В облаке используется наиболее точный (приоритетный) маршрут, который соответствует сетевому трафику, в соответствии с общепринятыми правилами выбора лучшего маршрута:

Операции с таблицами маршрутизации#

Чтобы создать новую таблицу маршрутизации, перейдите в раздел Таблицы маршрутизаци и нажмите .
В открывшемся модальном окне выберите VPC, в котором необходимо создать таблицу маршрутизации, и ещё раз нажмите .

Назначить подсети таблицу маршрутизации#

Чтобы ассоциировать подсеть с произвольной таблицей маршрутизации, выберите таблицу и нажмите .
В открывшемся диалоговом окне выберите подсети, с которыми её следует ассоциировать, и нажмите .

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

Подсеть может быть связана только с одной таблицей маршрутизации в один момент времени, но вы можете назначить одну таблицу маршрутизации нескольким подсетям.

Эта операция изменяет маршрутизацию трафика в выбранных подсетях согласно правилам указанной или основной таблицы маршрутизации.

Вы можете явно ассоциировать основную таблицу маршрутизации с подсетью, даже если между ниму уже есть неявная ассоциация.

Выбрать основную таблицу маршрутизации#

В Облаке КРОК можно использовать несколько таблиц маршрутизации, но только одна из них будет основной.
Чтобы сделать выбранную таблицу маршрутизации основной, выберите таблицу из списка или перейдите на её страницу и нажмите Сделать таблицу основной.

Данная операция затрагивает правила маршрутизации всех подсетей без явных ассоциаций – все неявно ассоциированные подсети будут ссылаться на новую основную таблицу, – поэтому для применения изменений требуется дополнительное подтверждение.
Если вы уверены в необходимости сменить основную таблицу маршрутизации, в открывшемся модальном окне нажмите повторно Сделать таблицу основной.

Снять назначение таблицы маршрутизации#

Чтобы отменить ассоциацию таблицы маршрутизации с подсетью, выберите нужную таблицу в списке и нажмите .
В открывшемся модальном окне выберите подсеть, с которой необходимо отменить ассоциацию.
Одновременно можно выбрать несколько подсетей.
Те же действия можно проделать на вкладке Подсети на странице таблицы маршрутизации.

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

Удалить таблицу маршрутизации#

Вы можете удалить таблицу маршрутизации, если она не является основной и не назначена ни одной подсети.
Чтобы удалить таблицу маршрутизации, перейдите в одноимённый раздел и выберите нужную таблицу.
Затем нажмите и подтвердите действие.
Кроме того, таблицу маршрутизации можно удалить на вкладке Информация на её странице.

Работа с правилами маршрутизации#

Чтобы получить информацию о правилах маршрутизации, на странице таблицы маршрутизации перейдите на вкладку Маршруты.

Каждое правило имеет набор параметров:

Добавить правило маршрутизации#

Чтобы добавить правило маршрутизации, перейдите на страницу таблицы маршрутизации, в которую вы хотите его добавить, и откройте вкладку Маршруты.
Нажмите и укажите необходимые параметры.

Удалить правило маршрутизации#

Чтобы удалить правило маршрутизации, перейдите на страницу таблицы маршрутизации, из которой вы хотите его удалить, и откройте вкладку Маршруты.
Выберите удаляемый маршрут и нажмите .
Вы можете удалить несколько маршрутов сразу.

Информация о таблицах маршрутизации#

Общую информацию об имеющихся таблицах маршрутизации можно посмотреть в разделе Таблицы маршрутизации.
Для просмотра всех таблиц маршрутизации в проекте выберите Все VPC в фильтре VPC.
Для отображения таблиц маршрутизации конкретного VPC выберите нужный VPC в фильтре.

Для просмотра детальной информации о конкретной таблице маршрутизации перейдите в раздел Таблицы маршрутзации и выберите нужную таблицу из списка.
Для упрощения поиска таблицы маршрутизации вы можете в фильтре VPC выбрать VPC, в котором создана таблица, либо воспользоваться поиском.

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

На вкладке Информация приводятся данные о VPC, в котором создана таблица маршрутизации, количестве подсетей, которым она назначена, является ли таблица основной и устанавливаются ли в неё маршруты BGP, т.е. включена ли функция распространения маршрутов.
Здесь же вы можете сделать таблицу маршрутизации основной, либо .

На вкладке Маршруты отображаются данные о заданных маршрутах.
Здесь вы можете также или маршрут.

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

Предпочтения альтернативных и tie дубликестеров

Протокол Junos OS обеспечивает поддержку альтернативных предпочтений и связывания, а некоторые протоколы маршрутов, включая BGP и коммутаторы меток, используют эти дополнительные предпочтения. С помощью этих протоколов можно указать первичное предпочтение маршрута (включив утверждение в конфигурацию), а также вторичное предпочтение, которое будет использоваться в качестве tie configurationer (включив preference preference2 утверждение).

Чтобы использовать общую процедуру сравнения, Junos OS значение 1 в LocalPref Preference2 поле. Например, если LocalPref значение для маршрута 1 100, то Preference2 значение -101. Если LocalPref значение для маршрута 2 155, Preference2 то значение — -156. Маршрут 2 является предпочтительным, поскольку он имеет LocalPref большее значение и Preference2 меньшее значение.

Можно также пометить предпочтения маршрутов дополнительными сведениями об обвязке маршрута, указав цвет и цвет tie этомастере (включив в конфигурацию и утверждения tie эти параметры). Кроме того, утверждения являются еще более точно указанными значениями предпочтений, которые Junos OS используются, когда и утверждения не срывают галстук во время выбора color color2 color color2 preference preference2 маршрута.

В программном обеспечении для представления значения предпочтения маршрута используется значение 4-byte. При использовании значения предпочтения для выбора активного маршрута программное обеспечение сначала сравнивает значения предпочтения основного маршрута, выбирая маршрут с наименьшим значением. Если имеется связь и настроено вторичное предпочтение, программное обеспечение сравнивает значения вторичных предпочтений, выбирая маршрут с наименьшим значением. Значения вторичных предпочтений должны быть включены в набор значений, которые следует учитывать.

Команда Route Add для определения шлюза по умолчанию в Linux

Синтаксис показан ниже, если вы хотите добавить шлюз по умолчанию, используя команда добавления маршрута.

маршрут добавить по умолчанию gw IP шлюзаИнтерфейс

маршрут добавить по умолчанию gw 192.168.0.1 wlp3s0

То же самое можно сделать с помощью команды IP, показанной ниже:

добавить по умолчанию через 192.168.0.1

А вы хорошо знаете статическую маршрутизацию?

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

Оговорка. При написании топика я исхожу из того, что читатель знаком с концепцией маршрутизации, умеет делать статические маршруты и не считает слово «ARP» ругательным. Впрочем, даже бывалые связисты наверняка найдут тут что-то новое.
Все примеры были проверены на IOS линейки 15.2M. Поведение других ОС может различаться.
И никакого динамического роутинга тут не будет.

Мы работаем со следующей топологией:

Как появляется статический маршрут?

Для начала, выполним команду, которую знает каждый, и посмотрим дебагами, что произойдет:

R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3

IOS создал маршрут, и сразу послал arp запрос в поисках next hop, который у нас – 10.0.0.3. И сразу вопрос: откуда роутер узнал, что запрос надо слать в интерфейс Gi0/1? Наверняка кто-то скажет «из списка локальных интерфейсов», и жестоко ошибется. Маршрутизация так не работает. На самом деле, IOS сделал рекурсивный запрос к таблице маршрутизации, чтобы узнать, как добраться до next hop:

И вот он, наш Gi0/1. IOS узнает, что с рекурсивными запросами к RIB надо заканчивать, как только находит маршрут с флагом «directly connected». Но что если ему в ответ на изначальный запрос к 10.0.0.3 вернется вовсе не connected маршрут, а промежуточный, ссылающийся на другой next hop? Вернемся к этому чуть позже, а пока вспомним, что такое CEF.

Примерно во всей документации, ориентированной на начинающих, говорится, что каждый пакет перемещается в соответствии с таблицей маршрутизации. На самом деле на всех более-менее современных платформах это уже не так, ведь таблица маршрутизации (далее – RIB) вовсе не оптимизирована для быстрой передачи данных. Оценить масштаб бедствия позволяет эта таблица (хотя у process switching’а множество недостатков помимо неоптимальных запросов – например, постоянное переключение шедулера CPU между контекстами, что весьма затратно). CEF является серьезной оптимизацией. В современной реализации он строит две таблицы – FIB (Forwarding Information Base, таблица передачи пакетов, в основе нее – связный граф со страшным названием 256-way mtrie) и adjacency table (таблица соседств). Первая из них строится на основе таблицы маршрутизации и за один проход позволяет получить всю нужную информацию. Строится она заранее, еще до того, как появится первый соответствующий ей пакет.

Вернемся к нашему статическому маршруту. Вот запись в таблице маршрутизации:

Куда слать пакет? Где искать 10.0.0.3? Непонятно. Надо еще раз запросить таблицу маршрутизации, на этот раз по поводу 10.0.0.3, и, если надо, выполнить еще несколько итераций, пока не выясним connected интерфейс. И вот примерно таким образом мы фактически в несколько раз снижаем производительность маршрутизатора.

А вот что говорит CEF:

R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0
recursive via 10.0.0.3
attached to GigabitEthernet0/1

Просто и лаконично. Есть интерфейс, есть next hop, к которому надо слать пакет. Что там говорилось про adjacency table?

R00#show adjacency 10.0.0.3 detail
Protocol Interface Address
IP GigabitEthernet0/1 10.0.0.3(10)
0 packets, 0 bytes
epoch 0
sourced in sev-epoch 2
Encap length 14
0019AAD6AE1030E4DB1677910800
ARP

Смотрим свой mac адрес на gi0/1:

R00#show int gi0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is CN Gigabit Ethernet, address is 30e4.db16.7791 (bia 30e4.db16.7791)

Ага. Та страшная строка – всего лишь два мака, которые надо подставить в заголовок Ethernet на этапе инкапсуляции, и ethertype 0x0800, т.е. банальный IPv4. И в двух таблицах CEF есть абсолютно вся информация, какая нужна для успешной отправки пакета дальше по цепочке.

Если у кого-то возникнет вопрос, зачем железке держать сразу две таблицы вместо одной, то дам очевидный ответ: обычно у маршрутизатора мало интерфейсов (а заодно и соседей) и много маршрутов. Какой смысл тысячи раз дублировать одни и те же маки в FIB? Памяти много не бывает, особенно на аппаратных платформах, будь то новомодные ASR’ы или даже L3 свитчи линейки Catalyst. Все они задействуют CEF при передаче пакетов.

И кстати, вернемся на минутку к изначальному дебагу. Отключим CEF командой no ip cef (никогда так не делайте) и сравним результат:

Маршрут добавлен. Arp запроса не было. И правильно – зачем RIB сдался mac адрес? Если пустить пинг до, к примеру, 3.1.1.1, то скорее всего будет так:

Первый пакет отбрасывается, и роутер посылает arp запрос с целью узнать mac адрес 10.0.0.3, если он ранее не был известен. CEF же всегда заранее узнает mac адрес next hop’а.

С этим разобрались. Теперь вернемся к вопросу, что будет, если next hop статического маршрута вовсе не на directly connected интерфейсе. Поступим просто:

R00(config)#ip route 10.0.0.3 255.255.255.255 100.100.100.101

, где Gi0/2 имеет адрес 100.100.100.100/24.

R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0
recursive via 10.0.0.3
recursive via 100.100.100.101
recursive via 100.100.100.0/24
attached to GigabitEthernet0/2

R00(config)#no ip route 10.0.0.3 255.255.255.255 100.100.100.101
R00(config)#ip route 10.0.0.0 255.0.0.0 100.100.100.101

R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0
recursive via 10.0.0.3
attached to GigabitEthernet0/1

Сейчас наша таблица маршрутизации выглядит так:

Вроде хорошо. Новый маршрут на 100.100.100.101 не применяется для 10.0.0.3, так как его маска /8 намного короче, чем /24 у connected интерфейса. Но вдруг Gi0/1, содержавший next hop для 3.1.1.0/24, по какой-то непонятной причине ушел в down, и его connected маршрут пропал из RIB.

Вот что стало:

R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0
recursive via 10.0.0.3
recursive via 10.0.0.0/8
recursive via 100.100.100.101
recursive via 100.100.100.0/24
attached to GigabitEthernet0/2

Что делать? Указывать сразу в маршруте интерфейс. Пересоздадим маршрут:

R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3
R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3

Поднимаем Gi0/1. Смотрим, куда теперь ведет маршрут на 3.1.1.0/24:

Тут уже указан интерфейс. Поэтому не будет рекурсивных запросов к таблице маршрутизации. Проверяем FIB:

R00#show ip cef 3.1.1.0
3.1.1.0/24
nexthop 10.0.0.3 GigabitEthernet0/1

Да, никакого «recursive». А если снова погасить gi0/1? Маршрут исчез.

R00#show ip route 3.1.1.0
% Network not in table

R00#show ip cef 3.1.1.0
0.0.0.0/0
no route

И это притом, что маршрут до 10.0.0.3 все еще был:

R00#show ip cef 10.0.0.3
10.0.0.0/8
nexthop 100.100.100.101 GigabitEthernet0/2

А что будет, если путь к next hop даст маршрут по умолчанию, а маршрут на 3.1.1.0/24 не ссылается на интерфейс?

R00(config)#no ip route 10.0.0.0 255.0.0.0 100.100.100.101
R00(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.101
R00(config)#no ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3
R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3
R00#show ip route 3.1.1.0
% Network not in table
R00#show ip cef 3.1.1.0 detail
0.0.0.0/0, epoch 0, flags default route
recursive via 100.100.100.101
recursive via 100.100.100.0/24
attached to GigabitEthernet0/2

А что если в статическом маршруте указать интерфейс, но не указывать IP адрес следующего хопа? Ответ: в случае Ethernet, если на next hop не отключен proxy arp, связность не нарушится, но роутеру может ОЧЕНЬ поплохеть. Подробнее. Если сказать «ip route 3.1.1.0 255.255.255.0 gi0/1», то ничего особо страшного не случится, даже пару сотен записей в arp таблице любой роутер переварит (и существуют сценарии-workaround’ы, в которых оптимальным решением является именно такой костыль), но вот «ip route 0.0.0.0 0.0.0.0 gi0/1» на пограничном маршрутизаторе наверняка убьет его. Потому запомните общее правило: если создается статический маршрут с next hop’ом на Ethernet интерфейсе, то его IP адрес должен указываться всегда. Исключения – только когда вы очень хорошо представляете себе, что делаете, зачем делаете и почему нельзя сделать иначе.

И напоследок, сделаем одну очень нехорошую штуку.

R00(config)# ip route 3.1.1.0 255.255.255.0 10.0.0.3
R00(config)#ip route 10.0.0.3 255.255.255.255 3.1.1.1

Первый маршрут в порядке, сто раз протестирован. А вот второй странный – он ведет через первый. А первый теперь ссылается на второй, и у нас бесконечная рекурсия. Вот что произошло:

Добавилось успешно. Но затем в дебагах высветилось:

RT: recursion error routing 3.1.1.1 — probable routing loop
RT: recursion error routing 10.0.0.3 — probable routing loop

И появилась запись в лог с severity 3:

%IPRT-3-RIB_LOOP: Resolution loop formed by routes in RIB

Однако, RIB никакого криминала не видит:

Вывод – никогда так не делайте.

Почему статический маршрут может не попасть в таблицу маршрутизации?

R00# show ip route
C 10.0.0.0/24 is directly connected, GigabitEthernet0/1

Т.е. пока интерфейс Gi0/1 находится в состоянии up и имеет адрес из подсети 10.0.0.0/24, ни один статический маршрут на этот префикс в таблице маршрутизации не появится.

Еще есть вариант «разные источники маршрутов добавляют маршруты на один и тот же префикс с одинаковым AD». Поведение IOS в данном случае не документировано, общая рекомендация – «никогда так делайте».

Но посмотрим другие, менее очевидные примеры. Например, статические маршруты можно создать со словом «permanent», которое переводится как «постоянный», и тогда они будут всегда висеть в таблице маршрутизации. Правильно? Нет.

Добавляем его и смотрим:

R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent
R00#show ip cef 3.1.1.0
3.1.1.0/24
nexthop 10.0.0.3 GigabitEthernet0/1

Кладем Gi0/1, и видим:

R00#show ip cef 3.1.1.0
3.1.1.0/24
unresolved via 10.0.0.3

В RIB он есть, и другие протоколы маршрутизации могут его использовать:

А теперь, не поднимая Gi0/1:

R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent
R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent

Просто пересоздали его, ничего не меняя. И вот что произошло:

Постоянный, говорите? Нет. Есть один маленький нюанс: чтобы перманентный маршрут навеки вписался в таблицу маршрутизации, нужно, чтобы он хотя бы на долю секунды резолвился. Хотя какое еще «навеки»? Когда он остался висеть в воздухе без резолвящегося интерфейса, достаточно сказать «clear ip route *» или тем более «reload», чтобы он исчез из RIB.

Но продолжим. Сделаем вот так:

R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3
R00(config)#ip route 3.1.1.10 255.255.255.255 3.1.1.1

Вроде нормальные маршруты. Что произойдет? Со вторым – ровным счетом ничего.

Суть вот в чем. Допустим, есть маршрут на X.X.X.X через Y.Y.Y.Y. Мы добавляем маршрут на X1.X1.X1.X1 (этот префикс полностью покрывается X.X.X.X) через X2.X2.X2.X2 (а он тоже покрывается X.X.X.X). IOS делает закономерный вывод: второй маршрут не несет в себе никакой новой информации и совершенно бесполезен, поэтому его можно не устанавливать в RIB.

А теперь финт ушами.

Но все равно так делать не стоит.

Необходимо упомянуть и о еще одном важном моменте. Статический маршрут должен по идее исчезнуть из таблицы маршрутизации, как только он перестанет резолвиться. Но на практике есть множество ситуаций, когда next hop пропадает, но при этом статический маршрут на какое-то время остается. К примеру, когда next hop резолвится через маршрут, полученный от протокола динамической маршрутизации. Все дело в том, что процесс, отслеживающий наличие next hop в RIB, не всегда может получить уведомление об исчезновении маршрута, и он вынужден периодически (раз в 60 секунд по умолчанию) перепроверять, все ли хорошо. Это вызовет заметную задержку сходимости сети.

Поменять интервал проверки, к примеру, на 10 секунд можно с помощью команды:

Маршрут по умолчанию

Если маршрутизатор не знает куда отправить пакет, то такой пакет отбрасывается. Таким образом получается, что маршрутизатор должен знать маршруты ко всем подсетям в составной сети. На практике для крупных сетей, например для интернета это невозможно, поэтому используются следующие решения.

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

Предполагается что этот маршрутизатор лучше знает структуру сети, и способен найти маршрут в составной сети. Для обозначения маршрута по умолчанию, в таблице маршрутизации используются четыре нуля в адресе подсети и четыре нуля в маске (0.0.0.0, маска 0.0.0.0), а иногда также пишут default.

Ниже пример маршрута по умолчанию в таблице маршрутизации в операционной системе linux.