Что является характеристикой статического маршрута по умолчанию
Маршрутизация
Статический маршрут по умолчанию
Возможно, что целевой IP-адрес пакета будет соответствовать нескольким маршрутам в таблице маршрутизации.
Самое точное соответствие
Например, предположим, что у нас есть следующие два статических маршрута в таблице маршрутизации:
172.16.0.0/ 24 is subnetted, 3 subnets
S 172.16.1.0 is directly connected, Serial0/0/0 and
S 172.16.0.0/16 is directly connected, Serial0/0/1
Примечание: Этот процесс является одинаковым для всех маршрутов в таблице маршрутизации, включая статические маршруты, маршруты, изученные из протокола маршрутизации и маршруты из непосредственно соединенных сетей. Процесс поиска в таблице маршрутизации будет объяснен более подробно в позднее.
Статический маршрут по умолчанию соответствует всем пакетам
Статический маршрут по умолчанию является маршрутом, который будет соответствовать всем пакетам. Статические маршруты по умолчанию используются:
Когда у маршрутизатора есть только один другой маршрутизатор, с которым он соединен. Это условие известно как тупиковый маршрутизатор.
Конфигурирование статического маршрута по умолчанию
Синтаксис для статического маршрута по умолчанию подобен любому другому статическому маршруту, за исключением того, что сетевой адрес 0.0.0.0 и маска подсети 0.0.0.0:
Router(config)#ip route 0.0.0.0 0.0.0.0 [exit-interface | ip-address ]
Сетевой адрес и маску 0.0.0.0 0.0.0.0 называют маршрутом «нулевой четверки».
R1 является тупиковым маршрутизатором. Он соединен только с R2. В настоящий момент у R1 есть три статических маршрута, которые используются, чтобы достигнуть всех удаленных сетей в нашей топологии. У всех трех статических маршрутов интерфейс выхода Serial 0/0/0 при передаче пакетов к маршрутизатору следующего транзитного участка R2.
Три статических маршрута на R1:
ip route 172.16.1.0 255.255.255.0 serial 0/0/0
ip route 192.168.1.0 255.255.255.0 serial 0/0/0
ip route 192.168.2.0 255.255.255.0 serial 0/0/0
R1 является идеальным кандидатом, чтобы заменить все его статические маршруты единственный маршрутом по умолчанию. Во-первых, удалите три статических маршрута:
R1(config)#no ip route 172.16.1.0 255.255.255.0 serial 0/0/0
R1(config)#no ip route 192.168.1.0 255.255.255.0 serial 0/0/0
R1(config)#no ip route 192.168.2.0 255.255.255.0 serial 0/0/0
Затем, сконфигурируйте единственный статический маршрут по умолчанию, используя тот же самый Последовательный интерфейс выхода 0/0/0, как и три предыдущих статических маршрута:
R1(config)#ip route 0.0.0.0 0.0.0.0 serial 0/0/0
Статическая маршрутизация
2.1. Основы статической маршрутизации
Маршруты к удаленным сетям могут быть сконфигурированы для каждого маршрутизатора вручную администратором (статическая маршрутизация) или созданы с помощью маршрутизирующих протоколов (динамическая маршрутизация).
Статические маршруты полностью определены администратором, поэтому они более безопасны, требуют меньше вычислительных ресурсов и более узкую полосу пропускания по сравнению с динамическими маршрутами. Однако сети, использующие статическую маршрутизацию, плохо масштабируемы, при изменении топологии требуется внесение изменений администратором в конфигурацию, что может приводить к ошибкам. Поэтому статическая маршрутизация используется либо в малых сетях, либо в комбинации с протоколами динамической маршрутизации на отдельных участках сети. Статические маршруты, по сравнению с динамическими, характеризуются более высоким приоритетом, поскольку административное расстояние AD = 1 (см. табл. 1.1).
Статическая маршрутизация также используется при формировании суммарных(объединенных) маршрутов, что сокращает количество записей в таблице маршрутизации (см. курс «Основы построения сетей пакетной коммутации»).
2.2. Конфигурирование статической маршрутизации
Чтобы сконфигурировать статическую маршрутизацию администратор должен задать маршруты ко всем возможным сетям назначения, которые не присоединены непосредственно к данному маршрутизатору. Например, из маршрутизатора R-A ( рис. 2.1), к которому прямо присоединены две сети ( Сеть 1, Сеть 4), необходимо проложить маршруты к четырем оставшимся сетям (из шести представленных на схеме). К маршрутизатору R-Bпрямо присоединены 3 сети ( Сеть 2, Сеть 4, Сеть 5), поэтому из него следует проложить 3 маршрута к оставшимся сетям.
Адрес входного интерфейса следующего маршрутизатора (следующего перехода) на пути к адресату иногда называют шлюзом. Например, для пакетов, попавших в маршрутизатор R-В, шлюзами будут:
Ниже приведен пример конфигурирования статической маршрутизации для Cisco-маршрутизатора R-В, когда используется адрес следующего перехода. Маршрутизатор R-В непосредственно связан с сетями 192.168.20.0, 200.4.4.0 и 200.5.5.0, поэтому статические маршруты нужно создать для остальных трех сетей, которые прямо не присоединены к R-В.
Аналогично конфигурируются остальные маршрутизаторы.
Для ускорения процесса маршрутизации вместо адреса следующего перехода ( next hop ) можно задать идентификатор выходного интерфейса маршрутизатора и тем самым избежать рекурсивной обработки маршрута. При этом формируется прямо присоединенный статический маршрут. В процессе конфигурирования предварительно нужно удалить все ранее созданные статические маршруты по команде no ip route :
Ниже приведен пример конфигурирования маршрутизатора R-B ( рис. 2.1) с использованием выходного интерфейса:
Что является характеристикой статического маршрута по умолчанию
Маршрутизация в Windows
Маршрутизация – это процесс передачи IP-трафика адресатам в сети, то есть процесс передачи пакетов от хоста-источника к хосту-адресату через промежуточные маршрутизаторы. Изучая эту статью предполагается что вы изучили материал основы компьютерных сетей.
Изучим как работает маршрутизация в Windows, что бы понять как она работает, а не просто прочитать и забыть, вам необходимо несколько виртуальных машин, а именно:
Учтите, что при настройке виртуальных машин, в настройках сети нужно указать «Внутренняя сеть» и задать одинаковое имя сети для всех машин.
Если вы не поленитесь и установите три виртуальные машины, а так же изучите этот материал до конца, то у вас будет практическое понимание работы сети в операционных системах семейства Windows.
Для простоты передачи данных хост-источник и маршрутизатор принимают решения о передаче пакетов на основе своих таблиц IP-маршрутизации. Записи таблицы создаются при помощи:
По сути, таблица маршрутизации – это база данных, которая хранится в памяти всех IP-узлов. Цель таблицы IP-маршрутизации это предоставление IP-адреса назначения для каждого передаваемого пакета для следующего перехода в сети.
Пример маршрутизации в Windows
Допустим, у нас есть три узла:
Хост XP имеет один сетевой адаптер (интерфейс) с IP-адресом 192.168.0.2 и маской подсети 255.255.255.0. Маршрутизатор Server1 имеет два интерфейса с IP-адресами 192.168.0.1 и 192.168.1.1 и масками подсети 255.255.255.0. Маршрутизатор Server2 также имеет 2 сетевых адаптера с IPадресами 192.168.1.2 и 192.168.2.1 и масками подсети 255.255.255.0. Таким образом, мы имеем 3 сети: сеть с IP-адресом 192.168.0.0 (Net 1), сеть с IP-адресом 192.168.1.0 (Net 2), сеть с IP-адресом 192.168.2.0 (Net 3).
Таблица маршрутизации
Таблица маршрутизации по умолчанию создается на узле автоматически с помощью программного обеспечения стека TCP/IP.
При настройке сетевого подключения на хосте XP были статически заданы IP-адрес 192.168.0.2 и маска подсети 255.255.255.0, основной шлюз задан не был. Программное обеспечение стека TCP/IP автоматически создало таблицу маршрутизации по умолчанию.
Таблица маршрутизации содержит для каждой записи следующие поля: Сетевой адрес (Network Destination), Маска сети (Netmask), Адрес шлюза (Gateway), Интерфейс (Interface) и Метрика (Metric). Разберем каждое поле подробнее.
Сетевой адрес. Поле определяет диапазон IP-адресов достижимых с использованием данной таблицы.
Маска сети. Битовая маска, которая служит для определения значащих разрядов в поле Сетевой адрес. Маска состоит из непрерывных единиц и нулей, отображается в десятичном коде. Поля Сетевой адрес и Маска определяют один или несколько IP-адрес.
Адрес шлюза. В этом поле содержаться IP-адрес, по которому должен быть направлен пакет, если он соответствует данной записи таблицы маршрутизации.
Интерфейс. Данное поле содержит адрес логического или физического интерфейса, используемого для продвижения пакетов, соответствующих данной записи таблицы маршрутизации.
Метрика. Используется для выбора маршрута, в случае если имеется несколько записей, которые соответствуют одному адресу назначения с одной и той же маской, то есть в случае если одного адресата можно достичь разными путями, через разные маршруты. При этом, чем меньше значение метрики тем короче маршрут.
На начальном этапе работы (т.е. с таблицами маршрутизации по умолчанию) маршрутизатор (хост) знает только, как достичь сетей, с которыми он соединен непосредственно. Пути в другие сети могут быть «выяснены» следующими способами:
Рассмотрим каждый из способов по порядку.
Статическая маршрутизация
Статические маршруты задаются вручную. Плюс статических маршрутов в том, что они не требуют рассылки широковещательных пакетов с маршрутной информацией, которые занимают полосу пропускания сети.
Минус статических маршрутов состоит в том, что при изменении топологии сети администратор должен вручную изменить все статические маршруты, что довольно трудоемко, в случае если сеть имеет сложную структуру с большим количеством узлов.
Второй минус заключается в том, что при отказе какого-либо канала статический маршрут перестанет работать, даже если будут доступны другие каналы передачи данных, так как для них не задан статический маршрут.
Но вернемся к нашему примеру. Наша задача, имя исходные данные, установить соединения между хостом XP и Server2 который находится в сети Net3, то есть нужно что бы проходил пинг на 192.168.2.1.
Начнем выполнять на хосте XP команды ping постепенно удаляясь от самого хоста. Выполните в Командной строке команды ping для адресов 192.168.0.2, 192.168.0.1, 192.168.1.1.
Мы видим, что команды ping по адресу собственного интерфейса хоста XP и по адресу ближайшего интерфейса соседнего маршрутизатора Server1 выполняются успешно.
Однако при попытке получить ответ от второго интерфейса маршрутизатора Server1 выводится сообщение «Заданный узел недоступен» или «Превышен интервал ожидания для запроса».
Это связано с тем, что в таблице маршрутизации по умолчанию хоста XP имеются записи о маршруте к хосту 192.168.0.2 и о маршруте к сети 192.168.0.0, к которой относится интерфейс маршрутизатора Server1 с адресом 192.168.0.1. Но в ней нет записей ни о маршруте к узлу 192.168.1.1, ни о маршруте к сети 192.168.1.0.
Добавим в таблицу маршрутизации XP запись о маршруте к сети 192.168.1.0. Для этого введем команду route add с необходимыми параметрами:
route add [адресат] [mask маска] [шлюз] [metric метрика] [if интерфейс]
Параметры команды имеют следующие значения:
Индекс интерфейса можно определить из секции Список интерфейсов (Interface List) выходных данных команды route print.
Теперь, зная индекс физического интерфейса, на хосте добавьте нужный маршрут, выполнив следующую команду:
route add 192.168.1.0 mask 255.255.255.0 192.168.0.1 metric 2 if 0x2
Данная команда сообщает хосту XP о том, что для того, чтобы достичь сети 192.168.1.0 с маской 255.255.255.0, необходимо использовать шлюз 192.168.0.1 и интерфейс с индексом 0x2, причем сеть 192.168.1.0 находится на расстоянии двух транзитных участка от хоста XP.
Выполним пинг на 192.168.1.1 и убедимся, что связь есть.
Продолжим пинговать серверы, теперь проверьте отклик от второго маршрутизатора, присоединенного к сети Net2 (Server2). Он имеет IP-адрес 192.168.1.2.
Получаем сообщение «Превышен интервал ожидания запроса». В данном случае это означает что наш хост XP знает как отправлять данные адресату, но он не получает ответа.
Это происходит по тому, что хост Server2 не имеет информации о маршруте до хоста 192.168.0.1 и до сети 192.168.0.0 соответственно, поэтому он не может отправить ответ.
Для этого необходимо выполнить команду route add с соответствующими параметрами, однако сначала необходимо узнать индекс интерфейса с адресом 192.168.1.2.
На Server2 выполним команду route print и посмотрим индекс первого физического интерфейса. Далее, с помощью команды route add добавьте на Server2 маршрут до сети Net1, аналогично тому, как мы добавляли маршрут хосту XP.
В моем случае это команда:
route add 192.168.0.0 mask 255.255.255.0 192.168.1.1 metric 2 if 0x10003
0x10003 — это индекс физического интерфейса сервера 2.
Индекс физического интерфейса может быть разным, обязательно обращайте на него внимание.
После того, как удостоверитесь в наличии связи между узлами XP и Server2, выполните команду ping 192.168.2.1, т.е. проверьте наличие маршрута узла XP до сети Net3 (192.168.2.1 – IP-адрес маршрутизатора Server2 в сети Net3).
Вместо ответа вы получите сообщение «Заданный узел недоступен». С этой проблемой мы сталкивались еще в самом начале лабораторной работы, машина XP не знает путей до сети 192.168.2.0.
Добавьте в таблицу маршрутизации хоста XP запись о маршруте к сети 192.168.2.0. Это можно сделать путем ввода в командной строке хоста XP команды route add с соответствующими параметрами:
route add 192.168.2.0 mask 255.255.255.0 192.168.0.1 metric 3 if 0x2
Я не буду подробно описывать как полностью настроить статическую маршрутизацию между узлами, думаю что суть ясна. Если у вас появились вопросы — задавайте их в комментариях.
Маршрутизация по умолчанию
Второй способ настройки маршрутизации в Windows — то маршрутизация по умолчанию.
Для маршрутизации по умолчанию необходимо задать на всех узлах сети маршруты по умолчанию.
Для добавления такого маршрута на хосте XP выполните следующую команду:
route add 0.0.0.0 mask 0.0.0.0 192.168.0.1 metric 2 if 0x10003
Это так называемый маршрут по умолчанию.
Проверьте работоспособность с помощью команды ping.
Динамическая маршрутизация, протокол RIP
Протокол RIP (Routing Information Protocol или Протокол передачи маршрутной информации) является одним из самых распространенных протоколов динамической маршрутизации.
Его суть заключается в том, что маршрутизатор использующий RIP передает во все подключенные к нему сети содержимое своей таблицы маршрутизации и получает от соседних маршрутизаторов их таблицы.
Есть две версии протокола RIP. Версия 1 не поддерживает маски, поэтому между сетями распространяется только информация о сетях и расстояниях до них. При этом для корректной работы RIP на всех интерфейсах всех маршрутизаторов составной сети должна быть задана одна и та же маска.
Протокол RIP полностью поддерживается только серверной операционной системой, тогда как клиентская операционная система (например, Windows XP) поддерживает только прием маршрутной информации от других маршрутизаторов сети, а сама передавать маршрутную информацию не может.
Настраивать RIP можно двумя способами:
Рассмотрим настройку в режиме командной строки с помощью утилиты netsh.
Netsh – это утилита командной строки и средство выполнения сценариев для сетевых компонентов операционных систем семейства Windows (начиная с Windows 2000).
Введите в командной строке команду netsh, после появления netsh> введите знак вопроса и нажмите Enter, появиться справка по команде.
Введите последовательно команды:
Вы увидите, что среди доступных команд этого контекста есть команда add interface, позволяющая настроить RIP на заданном интерфейсе. Простейший вариант этой команды – add interface «Имя интерфейса».
Настроим RIP на Server1. Но сначала нужно выключит брандмауэр.
Теперь в оснастке «Маршрутизация и удаленный доступ» в контекстном меню пункта SERVER1 (локально) выберите пункт «Настроить и включить Маршрутизация ЛВС
маршрутизацию и удаленный доступ».
В появившемся окне мастера нажмите «Далее». 
На следующем этапе выберите «Особая конфигурация» и нажмите «Далее». 
После чего нужно выбрать «Маршрутизация ЛВС» и завершить работу мастера. 
То же самое нужно выполнить на Server2.
Настройка через оснастку
В контекстном меню вкладки «Общие» (SERVER1 –> IP-маршрутизация –> Общие) нужно выбрать пункт «Новый протокол маршрутизации».
Затем выделяем строку «RIP версии 2 для IP». 
В контекстном меню появившейся вкладки «RIP» выберите «Новый интерфейс». Выделите строку «Подключение по локальной сети» и нажмите ОК. 
Перед вами появиться окно. 
В появившемся окне необходимо задать следующие настройки:
Оставьте оставшиеся настройки по умолчанию и нажмите ОК.
Далее необходимо выполнить эти действия для второго сетевого интерфейса.
После выполните те же действия для Sever2.
Проверьте, с помощью команды ping, работу сети.
Поздравляю! Маршрутизация в Windows изучена.
Обучаю HTML, CSS, PHP. Создаю и продвигаю сайты, скрипты и программы. Занимаюсь информационной безопасностью. Рассмотрю различные виды сотрудничества.
А вы хорошо знаете статическую маршрутизацию?
Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.
Оговорка. При написании топика я исхожу из того, что читатель знаком с концепцией маршрутизации, умеет делать статические маршруты и не считает слово «ARP» ругательным. Впрочем, даже бывалые связисты наверняка найдут тут что-то новое.
Все примеры были проверены на IOS линейки 15.2M. Поведение других ОС может различаться.
И никакого динамического роутинга тут не будет.
Мы работаем со следующей топологией: 
Как появляется статический маршрут?
Для начала, выполним команду, которую знает каждый, и посмотрим дебагами, что произойдет:
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:
Просто и лаконично. Есть интерфейс, есть next hop, к которому надо слать пакет. Что там говорилось про adjacency table?
Обратим внимание на какую-то длинную последовательность в предпоследней строке. Что-то это напоминает… Смотрим mac 10.0.0.3:
Смотрим свой mac адрес на gi0/1:
Ага. Та страшная строка – всего лишь два мака, которые надо подставить в заголовок 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 интерфейсе. Поступим просто:
, где Gi0/2 имеет адрес 100.100.100.100/24.
Как все плохо-то… А что если у нас есть маршрут на целую суперсеть?
Сейчас наша таблица маршрутизации выглядит так:
Вроде хорошо. Новый маршрут на 100.100.100.101 не применяется для 10.0.0.3, так как его маска /8 намного короче, чем /24 у connected интерфейса. Но вдруг Gi0/1, содержавший next hop для 3.1.1.0/24, по какой-то непонятной причине ушел в down, и его connected маршрут пропал из RIB.
Ой. Теперь пакеты на сеть 3.1.1.0/24 идут куда-то не туда. Я не могу представить себе сценарий, когда ожидаемое поведение статического маршрута – переключение на другой интерфейс. Если за тем интерфейсом находится резервный путь, то все-таки надо создавать еще один статический маршрут…
Что делать? Указывать сразу в маршруте интерфейс. Пересоздадим маршрут:
Поднимаем Gi0/1. Смотрим, куда теперь ведет маршрут на 3.1.1.0/24:
Тут уже указан интерфейс. Поэтому не будет рекурсивных запросов к таблице маршрутизации. Проверяем FIB:
Да, никакого «recursive». А если снова погасить gi0/1? Маршрут исчез.
И это притом, что маршрут до 10.0.0.3 все еще был:
А что будет, если путь к next hop даст маршрут по умолчанию, а маршрут на 3.1.1.0/24 не ссылается на интерфейс?
Обратите внимание, что первой строкой после «show ip cef» идет «0.0.0.0/0», а не «3.1.1.0/24». Несмотря на то, что next hop формально есть, по факту все итерации опроса таблицы маршрутизации (кроме первой) игнорируют маршрут по умолчанию, что логично, иначе любой запрос к таблице маршрутизации почти всегда бы резолвился (под «резолвиться» понимается нахождение интерфейса, в который нужно отправить пакет). Поэтому наш статический маршрут отсутствует, но пакеты все равно улетают к Gi0/2. Вроде бы все то же самое, что и без явного указания интерфейса? Не совсем. Допустим, протоколу маршрутизации сказали «redistribute static». Если статический маршрут пропал, то анонс тоже отзывается. А если нет, то маршрутизатор продолжит говорить всем «туда идти через меня», и это почти наверняка обернется L3 кольцом для префикса 3.1.1.0/24, который мог бы быть доступен откуда-нибудь еще. Но стоп, мы договаривались не трогать динамический роутинг…
А что если в статическом маршруте указать интерфейс, но не указывать 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 адрес должен указываться всегда. Исключения – только когда вы очень хорошо представляете себе, что делаете, зачем делаете и почему нельзя сделать иначе.
И напоследок, сделаем одну очень нехорошую штуку.
Первый маршрут в порядке, сто раз протестирован. А вот второй странный – он ведет через первый. А первый теперь ссылается на второй, и у нас бесконечная рекурсия. Вот что произошло:
Добавилось успешно. Но затем в дебагах высветилось:
И появилась запись в лог с severity 3:
Однако, RIB никакого криминала не видит:
Вывод – никогда так не делайте.
Почему статический маршрут может не попасть в таблицу маршрутизации?
Любой сетевик должен сходу дать одно из объяснений, касающееся любого источника маршрутов в IOS: существует другой маршрут на тот же самый префикс, но с меньшим AD (все помнят Administrative Distance?). Маршрут, источник которого – “connected”, всегда имеет AD=0, и ни один другой источник маршрутов не может привнести ничего ниже, чем «1», даже статический маршрут с явным указанием интерфейса. Пример connected:
Т.е. пока интерфейс Gi0/1 находится в состоянии up и имеет адрес из подсети 10.0.0.0/24, ни один статический маршрут на этот префикс в таблице маршрутизации не появится.
Еще есть вариант «разные источники маршрутов добавляют маршруты на один и тот же префикс с одинаковым AD». Поведение IOS в данном случае не документировано, общая рекомендация – «никогда так делайте».
Но посмотрим другие, менее очевидные примеры. Например, статические маршруты можно создать со словом «permanent», которое переводится как «постоянный», и тогда они будут всегда висеть в таблице маршрутизации. Правильно? Нет.
Добавляем его и смотрим:
Кладем Gi0/1, и видим:
В RIB он есть, и другие протоколы маршрутизации могут его использовать:
А теперь, не поднимая Gi0/1:
Просто пересоздали его, ничего не меняя. И вот что произошло:
Постоянный, говорите? Нет. Есть один маленький нюанс: чтобы перманентный маршрут навеки вписался в таблицу маршрутизации, нужно, чтобы он хотя бы на долю секунды резолвился. Хотя какое еще «навеки»? Когда он остался висеть в воздухе без резолвящегося интерфейса, достаточно сказать «clear ip route *» или тем более «reload», чтобы он исчез из RIB.
Но продолжим. Сделаем вот так:
Вроде нормальные маршруты. Что произойдет? Со вторым – ровным счетом ничего.
Суть вот в чем. Допустим, есть маршрут на 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.
А теперь финт ушами.
И вот это подводит нас к еще одному важному моменту. Указание интерфейса в статическом маршруте позволяет обойти многие проверки, так как статическому маршруту больше не требуется выполнять рекурсивные запросы к RIB в поисках пути до next hop, и при своем добавлении он не заденет триггеры на других маршрутах. Но это не отменяет главного требования: next hop обязан резолвиться в конкретный интерфейс, а тот интерфейс обязан быть в up. Тот факт, что рекурсивных запросов к RIB больше не будет, означает, что указанный IP адрес next hop’а находится прямо за интерфейсом, и наверняка отзовется на arp запрос (с точки зрения роутера). Если у соседнего по Gi0/1 роутера включен proxy arp, то он в ответ на arp запрос наверняка вернет свой mac адрес, и всё будет хорошо. Разве что лишняя запись в arp таблице…
Но все равно так делать не стоит.
Необходимо упомянуть и о еще одном важном моменте. Статический маршрут должен по идее исчезнуть из таблицы маршрутизации, как только он перестанет резолвиться. Но на практике есть множество ситуаций, когда next hop пропадает, но при этом статический маршрут на какое-то время остается. К примеру, когда next hop резолвится через маршрут, полученный от протокола динамической маршрутизации. Все дело в том, что процесс, отслеживающий наличие next hop в RIB, не всегда может получить уведомление об исчезновении маршрута, и он вынужден периодически (раз в 60 секунд по умолчанию) перепроверять, все ли хорошо. Это вызовет заметную задержку сходимости сети.
Поменять интервал проверки, к примеру, на 10 секунд можно с помощью команды: