Что такое рекурсивный статический маршрут
Рекурсивная маршрутизация в MikroTik через шлюзы назначемые DHCP
Наиболее часто задаваемый мне вопрос по использованию рекурсивной маршрутизации звучит так: «Что делать, если основной провайдер назначает нам ip-адрес через dhcp, при этом часто изменяется шлюз по-умолчанию?».
Warning! материалы и схемы в данной статье упрощены до примитивизма с целью дать общее понятие о методе решения проблемы. Без углубления в частности.
Для чего нужна рекурсивная маршрутизация? Для мониторинга наличия интернета за шлюзом провайдера. Ведь нередко случается, что маршрутизатор провайдера прекрасно отвечает на эхо-запросы, но [ап]линк в глобальную сеть у провайдера о какой-то причине пропал.
Рекурсивная маршрутизация позволяет оценить наличие доступа в Интернет через выбранного провайдера и принять решение о маршрутизации трафика.
Однако, дело в том, что использование рекурсивной маршрутизации предполагает наличие прибитого гвоздями прямое явное указание IP-адреса шлюза среди параметров создаваемого маршрута. Указание в качестве шлюза имени broadcast-интерфейса является неправильным и во многих случаях просто не работает, т.к. требует наличия proxy-arp со стороны провайдера. А еще, вместо провайдера proxy-arp может включить ваш сосед про провайдерскому свитчу и попытаться перехватить таким образом ваш трафик, устроив классический MITM!
Магия рекурсивной маршрутизации прячется за параметрами «scope» и «target-scope». Чтобы маршрут работал как рекурсивный, его «target-scope» должен быть больше или равен значению «scope» у статического маршрута на который он ссылается рекурсивно, а указанный в маршруте шлюз лежал вне прямой досягаемости через один из интерфейсов.
Рассмотрим простейшую схему Active/Backup. Наш маршрутизатор выполнятет NAT и подключен к двум провайдерам посредством интерфейсов Ether1-isp1 и Ether2-isp2. Основной провайдер (ISP-1) раздаёт своим клиентам IP-адреса посредством протокола DHCP и никак иначе. Второй провайдер предоставляет нам статический IP-адрес, но значительно меньшую скорость.
Переключение на запасного (ISP-2) должно происходить тогда, когда доступ в Интернет через основного провайдера становится невозможным.
Изюминкой от провайдера для подобной схемы является периодическая произвольная смена не только IP-адреса клиента, но и default-gateway.
До версии 6.39 мне приходилось видеть весьма изощренные костыли в различных комбинациях sheduler, netwatch и тому подобных механизмов.
Начиная с версии 6.39 разработчики RouterOS пошли навстречу таким пользователям и создали возможность вызывать специальный скрипт при срабатывании dhcp-клиента на устройстве.
Собственно решение состоит из двух частей:
Создадим резервный маршрут через «ISP-2» со значением «distance» больше, чем у будущего основного. В данном примере я использовал «distance=2»:
Далее, для того, чтобы получать от провайдера «ISP-1» маршрут по-умолчанию, но прямо его не использовать, существует специальное значение «distance=255». Маршрут с таким значением distance попадет в системную таблицу маршрутизации, но никогда не станет активным.
Такой маршрут нужен нам только для чтения присланных провайдером параметров и внедрением их в настройки рекурсивных маршрутов посредством скрипта.
Первая строка должна (и будет!) указывать на настоящий шлюз в сети провайдера лишь после того, как провайдер выдаст параметры по dhcp и они будут обработаны посредством dhcp-client script:
Теперь, при получении от провайдера «ISP-1» IP-адреса для использования в качестве шлюза по-умолчанию, он будет внесен в маршрутную пару вместо «127.0.0.1».
Вторая строка, где указан маршрут до 0.0.0.0/0, собственно и осуществляет всю магию. Указанный там в качестве шлюза узел 8.8.4.4 будет проверяться на отклик опцией «check-gateway=ping» именно через сеть ISP-1. В случае если узел 8.8.4.4 не ответит дважды на эхо-запросы в течение 20 секунд, маршрутизатор будет считать связь с Интернетом через этот маршрут (ISP-1) недоступной. Новые соединения в этом случае будут направлены через запасного провайдера ISP-2.
Если всё сделано правильно, то в окне winbox /ip->routes около маршрута до 8.8.4.4 будет видно слова «resursive via. ». Это значит маршрут построился именно как рекурсивный.
В завершении, исключительно для примера — скрин окна винбокса:
Рекурсивная маршрутизация в MikroTik
Принцип работы рекурсивной маршрутизации в MikroTik и что такое scope и target-scope
Рекурсивная маршрутизация
Данная реализация поведения маршрутизации появилась из-за того, что в протоколе BGP при распространении маршрутов полученных через eBGP в iBGP next-hop по умолчанию, не меняется. Но не будем о BGP, а будем о простом.
Давайте начнём с простого, ниже я привёл таблицу маршрутизации простого маршрутизатора без каких либо излишек.
Смотря на таблицу маршрутизации выше, ответьте на вопрос. Какой шлюз будет выбран для отправки пакета на адрес 8.8.8.8?
Я более чем уверен, что вы абсолютно правильно определили шлюз как 10.11.100.254 в маршруте 0.0.0.0/0 по номером ноль.
А теперь попробуйте ответить на следующий вопрос. Какой интерфейс будет выбран для отправки пакета на адрес 8.8.8.8? Почувствуйте разницу, в первом вопросе я спрашивал про шлюз, а в данном вопросе про интерфейс.
И вы скорее всего все ответите, что ether1 и будете правы, но вопрос почему именно так.
Задача маршрутизатора, определить не шлюз, а интерфейс выхода, так как маршрутизатору надо будет понять как передать до шлюза пакет, если тип ethernet, то необходимо будет выяснить с помощью arp mac адрес шлюза, если это какой-то тип инкапсуляции, то пакет надо обернуть в данный тип инкапсуляции и отправить, на адрес пира.
Я не могу, вам показать fullview таблицу маршрутизации, так как она бы банально заняла огромное место на данной странице.
И так представьте у себя в голове таблицу маршрутизации в 700000 маршрутов. Представили?!
Я намеренно проигнорирую такие вещи как Кеш таблицы маршрутизации. (Представим, что его нет.)
Перед маршрутизатором стоит задача, отправить пакет на адрес 8.8.8.8
В данном процесс поиска, есть одно тонкое место, при повторном поиске маршрута, уже до адреса шлюза 5.5.5.1 маршрутизатор проходит опять всю таблицу маршрутизации. Вам не кажется, что это немного излишне? Строго говоря адрес шлюза должен быть в непосредственно присоединенной сети к маршрутизатору! Так может следующий поиск осуществлять только среди connected маршрутов? да это было бы идеально. Но так как я уже написал выше, в протоколе BGP при передачи маршрута из eBGP в iBGP адрес шлюза не меняется, то шлюз уже не может быть connected. И что же делать?
Scope
В linux, а так как RouterOS основан на Linux, то также и в RouterOS введено такое понятие как scope маршрута и target-scope
У любого маршрута есть, свой scope и target-scope.
Теперь давайте смотря на таблицу маршрутизации выше, попробуем ответить на вопрос. Какой интерфейс будет выбран для отправки пакета на адрес 8.8.8.8?
Значения Scope
Значение вы можете править руками, как для scope так и для target-scope. В случае с динамической маршрутизацией вы можете scope или target-scope указать с помощью фильтров маршрутизации, но вам необходимо знать, что есть предустановленные значения.
Все типы маршрутов, кроме на iBGP, основаны на состоянии интерфейса, ну возможно eBGP немного сбоку стоит, так как по умолчанию он требует прямой связности с пиром, хотя это обходится с помощью multihop. А iBGP у него target-scope = 30, так как адрес шлюза не меняется, и нужен ещё один какой-то протокол, который бы сообщил как достичь сети nexthop-a. Например статический маршрут или зачастую ospf.
Но мы можем использовать во благо, данное поведение, чтобы узнавать наличие интернета за провайдером, без использования скриптов. Понятно, что только пинг и без дополнительный параметров малоэффективен, но это лучше чем нечего.
И так давайте переделаем дефолтный маршрут, и адрес шлюза укажем не наш шлюза, а например 8.8.8.8
Создадим маршрут до 8.8.8.8 через шлюз нашего провайдера.
Создали, маршрут но маршрут по умолчанию, до сих пор не активен. Так как маршрутизатор всё также не смогу найти, маршрут до 8.8.8.8, так как target-scope дефолтного маршрута равен 10, и именно среди таких scope будет производится поиск до адреса 8.8.8.8. Нам необхоидимо установить scope маршрута 8.8.8.8, так чтобы он попадал под поиск, а это значит установить scope либо 10 или меньше. Сделаем.
И наблюдаем, то что поднялся рекурсивный маршрут. gateway-status=8.8.8.8 recursive via 10.11.100.254
Теперь давайте ещё раз ответим на вопрос, только изменим адрес назначения. Какой интерфейс будет выбран для отправки пакета на адрес 4.4.4.4?
А теперь мы можем сделать следующее, мы можем указать, использовать check-gateway и тем самым проверять доступность 8.8.8,8, и если будут недоступны, маршрут умрёт, и станет активным какой-нибудь другой маршрут с худшей дистанцией, например через LTE интерфейс.
Вы можете сделать рекурсивно, друг за другом, но это не имеет значение не в каких целях.
Одними 8.8.8.8 сыт не будешь
Да конечно, если упадёт 8.8.8.8, то мало не поздоровиться, будете переделывать. Можно поступить следующим образом.
Например взять три хоста высокой доступности 1.1.1.1, 8.8.8.8 и 77.88.8.8, можете любые свои, главное чтобы они действительно максимально всегда были доступны.
Создать три маршрута, через нашего провайдера. Таким образом
Далее создать три дефолтных рекурсивных маршрута, разной дистанцией.
В итоге, у вас будет такая картина в Winbox.
Если от 77.88.8.8 перестанет приходить ответы icmp, но при этом 8.8.8.8 будет приходить, то маршрут через шлюз 77.88.8.8 выпадет из процесса маршрутизации и его место займет следующий дефолтный маршрут по дистанции.
Часто слышу вопрос, а как сделать так, чтобы можно сделать через PPPoE рекурсивный маршрут? Тут всё дело в понимании, как таковой адрес шлюза не используется, кроме как в ethernet сетях, так как в ethernet нам нужен его mac адрес, в любых типах инкапсуляции в том числе и PPPoE адрес шлюза не используется, в виду того, что маршрутизатору просто надо запихнуть пакет в другой протокол и отправить на другую сторону.
Естественно мы можем этим воспользоваться.
Создайте отдельный PPP Profile и укажите абсолютно любой IP адрес в поле remote-address, главное чтобы этот адрес не пересекался с вашими внутренними сетями. Далее укажите этот профиль в настройках вашего PPPoE клиента, и вы можете использовать указанный адрес в поле remote-address, как адрес шлюза, для настройки рекурсивной маршрутизации.
ОДЕССКАЯ НАЦИОНАЛЬНАЯ АКАДЕМИЯ СВЯЗИ
Им. А.С. ПОПОВА
КАФЕДРА СЕТЕЙ СВЯЗИ
МЕТОДИЧЕСКИЕ УКАЗАНИЯ
К ЛАБОРАТОРНОЙ РАБОТЕ № 1.3
“ Методы маршрутизации в сетях связи”
образовательно-профессиональной программы подготовки бакалавров
по направлению высшего образования
Одесса –2015
Цель работы
1.1 Анализ функционирования IP-сети на базе статической маршрутизации.
1.2 Приобретение практических навыковконфигурирования статической маршрутизации в IP-сети.
План работы
Часть 1: Настройка топологии и инициализация устройств.
Часть 2: Настройка базовых параметров устройств и проверка подключений.
Часть 3: Настройка статических маршрутов:
• Настройка рекурсивных статических маршрутов.
• Настройка напрямую подключенных статических маршрутов.
• Настройка маршрута по умолчанию.
Часть 4: Тестирование корректности работы сети
Ключевые положения
Маршрутизатор использует таблицу маршрутизации для определения маршрута следования пакетов. Таблица маршрутизации содержит набор маршрутов, которые описывают, какой шлюз или интерфейс использует маршрутизатор для достижения указанной сети. Первоначально таблица маршрутизации содержит информацию только о сетях, непосредственно подсоединенных к интерфейсам маршрутизатора. Маршруты к удаленным сетям должны быть указаны либо администратором, либо добавлены с помощью протокола маршрутизации.
Статическая маршрутизация – вид маршрутизации, при котором маршруты указываются в явном виде при конфигурировании маршрутизатора. Маршрутизация при этом осуществляется без участия каких-либо протоколов маршрутизации.
При задании статического маршрута указывается:
— IP-адрес и маска сети, к которой маршрутизируется трафик;
— IP-адрес узла (шлюза), который отвечает за дальнейшую маршрутизацию или интерфейс данного маршрутизатора, на который следует направить трафик;
— метрика (опционально) маршрута. При наличии нескольких маршрутов к одной и той же сети маршрутизаторы выбирают маршрут с минимальной метрикой.
Достоинства статической маршрутизации:
— легкость отладки и конфигурирования в малых сетях;
— отсутствие дополнительных накладных расходов (из-за отсутствия служебного трафика протоколов маршрутизации);
— мгновенная готовность (не требуется интервал для конфигурирования/подстройки) ;
— низкая нагрузка на процессор маршрутизатора;
— предсказуемость в каждый момент времени.
Недостатки статической маршрутизации:
— плохая масштабируемость сети. Добавление (N+1)-ой сети потребует сделать 2*(N+1)-записей о маршрутах, причем, у большинства маршрутизаторов таблица маршрутов будет различной. При N 3-4 процесс конфигурирования становится весьма трудоемким;
— низкая устойчивость в ситуациях, когда обрыв происходит между устройствами второго уровня и порт маршрутизатора не получает статус down;
— отсутствие возможности динамической балансировки нагрузки;
— необходимость в ведении отдельной документации по маршрутам, проблема синхронизации документации реальных маршрутов.
В данной лабораторной работе необходимо вручную настроить статические маршруты к указанным удаленным сетям. Необходимо также настроить статический маршрут по умолчанию (Default route). Маршрут по умолчанию является одним из видов статического маршрута, который указывает, куда направлять пакеты, если таблица маршрутизации не содержит путь к сети назначения.
Эта лабораторная работа обеспечивает минимальную помощь, предоставляющую фактические команды IОС Cisco, необходимые для настройки статической маршрутизации.
Тем не менее, все необходимые команды приведены в Приложении А. Проверьте свои знания, пытаясь настроить устройства, не обращаясь к приложению.
3 Ключевые вопросы
3.1 Дайте определение статической маршрутизации.
3.2 Каковы преимущества статической маршрутизации по сравнению с динамической?
3.3 В чем особенность маршрута Default route?
3.4 Укажите недостатки статической маршрутизации.
3.5 Какая информация содержится в таблице маршрутизации при базовой настройке маршрутизатора?
3.6 Как настроить рекурсивный статический маршрут?
3.7 Как настроить маршрут по умолчанию?
3.8 Как просмотреть таблицу маршрутизации?
3.9 Что такое «метрика» маршрута?
3.10 Укажите синтаксис команды конфигурирования статического маршрута directly connected.
3.11 Как просмотреть состояние интерфейса маршрутизатора?
4 Домашнее задание
4.1 Выучите, пользуясь рекомендованной литературой, а также данным методическим руководством, ключевые особенности метода статической маршрутизации.
4.3 Составьте план выполнения лабораторной работы, руководствуясь п.5.
5 Лабораторное задание
Часть 3: настройка статических маршрутов
Шаг 1: Настройка рекурсивного статического маршрута.
В рекурсивном статическом маршруте указывается IP- адрес следующего перехода. Так как указан только следующий хоп, маршрутизатор должен выполнять несколько операций поиска в таблице маршрутизации перед пересылкой пакетов.
Чтобы настроить рекурсивные статические маршруты, используйте следующий синтаксис :
Router(config)#ip route network-address subnet-mask ip-address,
a. На маршрутизаторе R1 настроить статический маршрут к сети 172.16.Х.0/25 с использованием IP- адреса Serial 0/0/0-интерфейса маршрутизатора R2 в качестве адреса следующего перехода.
б. Просмотрите таблицу маршрутизации маршрутизатора R1для проверки новой записи статического маршрута.
Как выглядит запись нового маршрута в таблице маршрутизации?
Есть ли связь хоста PC-1 с хостом PC- 2?
Результаты работы, проделанной в п. б, отразите в протоколе.
Примечание: Результат выполнения командыping должен быть неудачным.
с. На маршрутизаторе R1 конфигурируйте рекурсивные статические маршруты к сетям 172.16.Х.196/30 и 172.16.Х.128/26.
d. Проверьте связи и результаты отразите в протоколе.
Шаг 2: Настройка напрямую подключенного (directly connected) статического маршрута.
В статическом маршруте directly connected указывается параметр выходного интерфейса данного маршрутизатора, что позволяет ему принять решение о пересылке пакета с однократным обращением к таблице маршрутизации.
Статический маршрут типа directly connected обычно используется в соединениях типа «точка-точка», где указывают последовательный интерфейс.
Чтобы настроить статические маршруты directly connected, используется следующий синтаксис:
Router(config)#ip route network-address subnet-mask exit-intf,
a. На маршрутизаторе R2 настроить статические маршруты к удаленным сетям 172.16.0.0/24 и 172.16.Х.128/26 с использованием идентификатора соответствующего интерфейса в качестве выходного.
б. Просмотрите таблицу маршрутизации R2 для проверки новых записей статических маршрутов.
Как эти новые маршруты отражены в таблице маршрутизации?
с. Пошлите команду ping от PC-2 к хосту PC- 3
Есть ли связь PC-2 с хостом PC- 3? Результаты выполнения работы в пп. б, с отразите в протоколе.
Примечание: Возможно понадобится отключить брандмауэры PC для выполнения команды ping между PC.
Содержание протокола
В протоколе должны быть отражены название данной работы, ее цель, результаты выполнения домашнего задания, резуульаты выполнения лабораторного задания, выводы по резульатам проделанной работы.
Литература
7.1 Олифер В.Г., Олифер Н.А. Компьютерные сети. – С.Пб.: Питер, 2005.
Приложение A: Команды конфигурирования
Настройка IP параметров интерфейса s0/0/1 маршрутизатора R2 для варианта 1
R2(config)#interface s0/0/1
R2(config-if)#ip address 172.16.1.198 255.255.255.252
R2(config-if)#clock rate 128000
R2(config-if)#no shutdown
ОДЕССКАЯ НАЦИОНАЛЬНАЯ АКАДЕМИЯ СВЯЗИ
Им. А.С. ПОПОВА
КАФЕДРА СЕТЕЙ СВЯЗИ
МЕТОДИЧЕСКИЕ УКАЗАНИЯ
К ЛАБОРАТОРНОЙ РАБОТЕ № 1.3
“ Методы маршрутизации в сетях связи”
образовательно-профессиональной программы подготовки бакалавров
по направлению высшего образования
Одесса –2015
Цель работы
1.1 Анализ функционирования IP-сети на базе статической маршрутизации.
1.2 Приобретение практических навыковконфигурирования статической маршрутизации в IP-сети.
План работы
Часть 1: Настройка топологии и инициализация устройств.
Часть 2: Настройка базовых параметров устройств и проверка подключений.
Часть 3: Настройка статических маршрутов:
• Настройка рекурсивных статических маршрутов.
• Настройка напрямую подключенных статических маршрутов.
• Настройка маршрута по умолчанию.
Часть 4: Тестирование корректности работы сети
Ключевые положения
Маршрутизатор использует таблицу маршрутизации для определения маршрута следования пакетов. Таблица маршрутизации содержит набор маршрутов, которые описывают, какой шлюз или интерфейс использует маршрутизатор для достижения указанной сети. Первоначально таблица маршрутизации содержит информацию только о сетях, непосредственно подсоединенных к интерфейсам маршрутизатора. Маршруты к удаленным сетям должны быть указаны либо администратором, либо добавлены с помощью протокола маршрутизации.
Статическая маршрутизация – вид маршрутизации, при котором маршруты указываются в явном виде при конфигурировании маршрутизатора. Маршрутизация при этом осуществляется без участия каких-либо протоколов маршрутизации.
При задании статического маршрута указывается:
— IP-адрес и маска сети, к которой маршрутизируется трафик;
— IP-адрес узла (шлюза), который отвечает за дальнейшую маршрутизацию или интерфейс данного маршрутизатора, на который следует направить трафик;
— метрика (опционально) маршрута. При наличии нескольких маршрутов к одной и той же сети маршрутизаторы выбирают маршрут с минимальной метрикой.
Достоинства статической маршрутизации:
— легкость отладки и конфигурирования в малых сетях;
— отсутствие дополнительных накладных расходов (из-за отсутствия служебного трафика протоколов маршрутизации);
— мгновенная готовность (не требуется интервал для конфигурирования/подстройки) ;
— низкая нагрузка на процессор маршрутизатора;
— предсказуемость в каждый момент времени.
Недостатки статической маршрутизации:
— плохая масштабируемость сети. Добавление (N+1)-ой сети потребует сделать 2*(N+1)-записей о маршрутах, причем, у большинства маршрутизаторов таблица маршрутов будет различной. При N 3-4 процесс конфигурирования становится весьма трудоемким;
— низкая устойчивость в ситуациях, когда обрыв происходит между устройствами второго уровня и порт маршрутизатора не получает статус down;
— отсутствие возможности динамической балансировки нагрузки;
— необходимость в ведении отдельной документации по маршрутам, проблема синхронизации документации реальных маршрутов.
В данной лабораторной работе необходимо вручную настроить статические маршруты к указанным удаленным сетям. Необходимо также настроить статический маршрут по умолчанию (Default route). Маршрут по умолчанию является одним из видов статического маршрута, который указывает, куда направлять пакеты, если таблица маршрутизации не содержит путь к сети назначения.
Эта лабораторная работа обеспечивает минимальную помощь, предоставляющую фактические команды IОС Cisco, необходимые для настройки статической маршрутизации.
Тем не менее, все необходимые команды приведены в Приложении А. Проверьте свои знания, пытаясь настроить устройства, не обращаясь к приложению.
3 Ключевые вопросы
3.1 Дайте определение статической маршрутизации.
3.2 Каковы преимущества статической маршрутизации по сравнению с динамической?
3.3 В чем особенность маршрута Default route?
3.4 Укажите недостатки статической маршрутизации.
3.5 Какая информация содержится в таблице маршрутизации при базовой настройке маршрутизатора?
3.6 Как настроить рекурсивный статический маршрут?
3.7 Как настроить маршрут по умолчанию?
3.8 Как просмотреть таблицу маршрутизации?
3.9 Что такое «метрика» маршрута?
3.10 Укажите синтаксис команды конфигурирования статического маршрута directly connected.
3.11 Как просмотреть состояние интерфейса маршрутизатора?
4 Домашнее задание
4.1 Выучите, пользуясь рекомендованной литературой, а также данным методическим руководством, ключевые особенности метода статической маршрутизации.
4.3 Составьте план выполнения лабораторной работы, руководствуясь п.5.
А вы хорошо знаете статическую маршрутизацию?
Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации 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 секунд можно с помощью команды: