Steinkäfer
среда, 21 сентября 2016 г.
Коммутация и маршрутизация на коммутаторах CISCO
Скомпилировано себе на память из нескольких источников. Основные источники:
http://twistedminds.ru/
http://xgu.ru/
CAM (Content Addressable Memory)
Enter 0 to disable aging Aging time in secon
SWG(config)#mac address-table static d8cb.8a9c.ffe8 vlan 19 interface gigabitEthernet3/1
SWG_PoE_4510#sh mac address-table count
MAC Entries for all vlans:
Dynamic Unicast Address Count: 656
Static Unicast Address (User-defined) Count: 0
Static Unicast Address (System-defined) Count: 9
Total Unicast MAC Addresses In Use: 665
Total Unicast MAC Addresses Available: 55000
Multicast MAC Address Count: 41
Total Multicast MAC Addresses Available: 32768
SWG_PoE_4510#traceroute mac d8cb.8a9c.ffe8 001d.71dd.69c1
Source d8cb.8a9c.ffe8 found on SWG_PoE_4510
1 SWG_PoE_4510 (10.100.10.254) : Gi3/1 => Te6/1
2 SWT1_PLK (10.100.18.89) : Gi1/1/3 => Gi1/0/24
Destination 001d.71dd.69c1 found on SWT1_PLK
Layer 2 trace completed
TCAM (Ternary Content-Addressable Memory)
Операционная система Cisco IOS обладает двумя автономными компонентами по работе с TCAM:
Switch(config)# access-list 100 permit ip host 1.1.1.1 host 2.2.2.2
ARP таблица
ARP таблица хранит соответствие IP-адреса с MAC-адресом, чтобы обеспечить передачу IP-данных на уровне 2 домена широковещательной рассылки. Например, узел B должен отправить данные в узел A, но в его кэше ARP отсутствует MAC-адрес узла A. Узел B генерирует широковещательное сообщение для всех узлов, принадлежащих домену широковещательной рассылки, чтобы получить MAC-адрес, соответствующий IP-адресу узла A. ARP-запрос получают все узлы домена широковещательной рассылки, но ответ, содержащий требуемый MAC-адрес, отправляется только из узла А.
Процесс коммутации/маршрутизации в MLS
Пакет забирается с одной из входящих очередей и происходит исследование L2 и L3 адресов получателей. Решение о том куда направить пакет происходит на основании CAM и FIB таблиц. Решение о том как отправить пакет (и отправлять ли вообще) принимается на основании ACL и QOS политик. Стоит отметить, что поиск по CAM, FIB, QOS, ACL происходит одновременно.
Cisco Express Forwarding (CEF)
Cisco Express Forwarding (CEF) — технология высокоскоростной маршрутизации/коммутации пакетов, использующаяся в маршрутизаторах и коммутаторах третьего уровня фирмы Cisco Systems, и позволяющая добиться более быстрой и эффективной обработки транзитного трафика.
Функционал, который поддерживает CEF:
Forwarding Information Base (FIB)
Посмотреть информацию о данных, расположенных в FIB таблицы можно с помощью команды:
SWG_PoE_4510#sh ip cef
Prefix Next Hop Interface
0.0.0.0/0 no route
0.0.0.0/8 drop
0.0.0.0/32 receive
10.0.0.20/30 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.4/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.5/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.6/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.7/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.8/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.9/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.10/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.11/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
10.10.10.12/32 10.100.0.170 Vlan704
10.100.0.173 Vlan711
Cisco Express Forwarding
Материал из Xgu.ru
 |
| Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. |
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
Cisco Express Forwarding (CEF) — технология высокоскоростной маршрутизации/коммутации пакетов, использующаяся в маршрутизаторах и коммутаторах третьего уровня фирмы Cisco Systems, и позволяющая добиться более быстрой и эффективной обработки транзитного трафика.
Функционал, который поддерживает CEF:
CEF не работает в следующих случаях:
Содержание
[править] FIB
Вывод и параметры команд, которые относятся к CEF, могут отличаться в зависимости от версии IOS и модели оборудования.
Но, как правило, команды просмотра начинаются на show cef, show ip cef, show adjacency
[править] Adjacency Table
Строка CA0111480008CA00114800080800 читается следующим образом:
[править] CEF epoch
В FIB и adjacency table есть понятие версии, которая называется epoch. Диапазон значений epoch от 0 до 255.
Значение epoch увеличивается, при инициации перестроения таблицы. Это можно сделать вручную, очистив информацию CEF.
На практике epoch используется, например, при переключении между supervisor engine в технологии NSF:
[править] Просмотр значения epoch для FIB
Например, текущее значение epoch равно 0:
При корректной работе, значение epoch для всех префиксов должно быть равным этому глобальному значению. Отображение значения epoch для конкретного префикса на примере маршрута по умолчанию:
Когда в FIB добавляется новая запись, то значение epoch для нее устанавливается равным текущему глобальному значению. То есть, значение epoch не увеличивается, когда добавляется какой-то префикс в FIB:
[править] Обновление значения epoch для FIB
С помощью команды clear cef table ipv4 можно вручную обновить FIB и, соответственно, изменится значение epoch(в некоторых IOS также может быть команда clear ip cef epoch full):
[править] Просмотр значения epoch для adjacency table
Суммарная информация об adjacency table отображает и значение epoch:
В текущей таблице adjacency есть 4 записи со значением epoch 3, которое соответствует глобальной версии таблицы. И одна запись со значением 2.
Также в суммарной информации видно, что одна запись в состоянии incomplete: 1 incomplete adjacency. Посмотрим более подробную информацию о записях в таблице adjacency:
В более подробном выводе можно увидеть значение epoch для каждой записи в adjacency table. А также теперь мы видим у какой записи значение epoch 2:
Эта запись находится в состоянии incomplete, так как не известно какой MAC-адрес соответствует next-hop 10.0.12.10.
[править] Обновление значения epoch для adjacency table
[править] Информация о таблице CEF
[править] Просмотр информации
Очистить Cisco Express Forwarding adjacency table:
На коммутаторе (hardware Layer 3-switching adjacency node):
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Про CEF (Cisco Express Forwarding)
высокоскоростная маршрутизация и коммутация
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Вы знаете, что коммутаторы 2 уровня будут переключать только кадры Ethernet в пределах VLAN, и, если мы хотим, мы можем фильтровать трафик на основе уровня 2 (например, с защитой портов). Многоуровневый коммутатор может делать то же самое, но он также способен маршрутизировать между VLAN и фильтровать на уровне 3 или 4 с помощью списков доступа.
Переадресация на уровне 2 основана на конечном MAC-адресе. Наш коммутатор изучает исходные MAC-адреса на входящих кадрах и строит таблицу MAC-адресов. Всякий раз, когда фрейм Ethernet входит в один из наших интерфейсов, мы проверяем таблицу MAC-адресов, чтобы найти конечный MAC-адрес, и отправляем его в правильный интерфейс.
Переадресация на уровне 3 основана на IP-адресе назначения. Переадресация происходит, когда коммутатор получает IP-пакет, где исходный IP-адрес находится в другой подсети, чем конечный IP-адрес.
Когда наш многоуровневый коммутатор получает IP пакет со своим собственным MAC адресом в качестве назначения в заголовке Ethernet есть две возможности:
В те не далекие времена коммутация производилась на аппаратной скорости, а маршрутизация-на программной. В настоящее время как коммутация, так и маршрутизация выполняются на аппаратной скорости. В оставшейся части этой статьи вы узнаете почему.
Давайте рассмотрим разницу между обработкой кадров Ethernet и IP-пакетов:
Жизнь коммутатора уровня 2 проста
Там нет никакого изменения кадра Ethernet!
Теперь давайте посмотрим, что происходит, когда получает IP-пакет многоуровневый коммутатор:
В приведенном выше примере компьютер А посылает IP-пакет к компьютеру В. Обратите внимание, что они находятся в разных подсетях, поэтому нам придется его маршрутизировать. Когда наш многоуровневый коммутатор получит IP-пакет, вот что произойдет:
Многоуровневый коммутатор проверит таблицу маршрутизации, заметит, что 192.168.20 /24 напрямую подключен, и произойдет следующее:
Как вы можете видеть, имеется довольно много шагов, связанных с маршрутизацией IP-пакетов.
Когда мы рассматриваем многоуровневый коммутатор возникает «разделение обязанностей». Мы должны построить таблицу для MAC-адресов, заполнить таблицу маршрутизации, ARP-запросы, проверить, соответствует ли IP-пакет списку доступа и т. д. И нам нужно переслать наши IP-пакеты. Эти задачи разделены между «плоскостью управления» и «плоскостью данных». Ниже приведен пример:
Плоскость управления отвечает за обмен информацией о маршрутизации с использованием протоколов маршрутизации, построение таблицы маршрутизации и таблицы ARP. Плоскость данных отвечает за фактическую пересылку IP-пакетов. Таблица маршрутизации не очень подходит для быстрой переадресации, потому что мы имеем дело с рекурсивной маршрутизацией.
Что такое рекурсивная маршрутизация?
Давайте рассмотрим пример:
В приведенном выше примере у нас есть три маршрутизатора. У R3 есть loopback интерфейс, к которому мы хотим получить доступ из R1. Будем использовать статические маршруты для достижения поставленной цели:
Первый статический маршрут предназначен для достижения интерфейса loopback0 R3 и указывает на интерфейс FastEthernet0/0 R3. Второй статический маршрут необходим для достижения сети 192.168.23.0/24.
Всякий раз, когда R1 хочет достичь 3.3.3.0/ 24, мы должны выполнить 3 поиска:
R1 должен проверить таблицу маршрутизации 3 раза, прежде чем он будет знать, куда отправлять свой трафик. Звучит не очень эффективно, верно? Выполнение нескольких поисков для достижения определенной сети называется рекурсивной маршрутизацией.
Большую часть времени все входящие и исходящие IP-пакеты будут обрабатываться и пересылаться плоскостью данных, но есть некоторые исключения, давайте сначала рассмотрим картинку ниже:
Большая часть IP-пакетов может быть передана плоскостью данных. Однако есть некоторые «специальные» IP-пакеты, которые не могут быть переданы плоскостью данных немедленно, и они отправляются на плоскость управления, вот некоторые примеры:
Плоскость управления может пересылать исходящие IP-пакеты на плоскость данных или использовать свой собственный механизм пересылки для определения исходящего интерфейса и следующего IP-адреса прыжка. Примером этого является маршрутизация на основе локальной политики.
Наш многоуровневый коммутатор выполняет больше шагов для пересылки пакетов, чем коммутаторы уровня 2, поэтому теоретически он должен работать медленнее, верно?
Одна из причин, по которой многоуровневые коммутаторы могут передавать кадры и пакеты на wirespeed, заключается в том, что в плате данных используется специальное оборудование, называемое ASICs.
Такая информация, как MAC-адреса, таблица маршрутизации или списки доступа, хранится в этих ASIC. Таблицы хранятся в content-addressable memory (Cam) и ternary content addressable memory (TCAM).
Таблица CAM используется для хранения информации уровня 2, например:
Поиск таблицы происходит быстро! Всякий раз, когда коммутатор получает кадр Ethernet, он будет использовать алгоритм хэширования для создания «ключа» для целевого MAC-адреса + VLAN, и он будет сравнивать этот хэш с уже хэшированной информацией в таблице CAM. Таким образом, он может быстро искать информацию в таблице CAM.
Поскольку существует 3 значения, мы называем его троичным. Так почему же существует 2 типа таблиц?
Когда мы ищем MAC-адрес, нам всегда требуется точное совпадение. Нам нужен точный MAC-адрес, если мы хотим переслать кадр Ethernet. Таблица MAC-адресов хранится в таблице CAM.
Всякий раз, когда нам нужно сопоставить IP-пакет с таблицей маршрутизации или списком доступа, нам не всегда нужно точное соответствие. Например, IP-пакет с адресом назначения 192.168.20.44 будет соответствовать:
По этой причине такая информация, как таблица маршрутизации, хранится в таблице TCAM. Мы можем решить, должны ли совпадать все или некоторые биты.
Пример таблицы TCAM
Если мы хотим сопоставить IP-адрес 192.168.10.22, многоуровневый коммутатор сначала посмотрит, есть ли «самое полное совпадение«. Там ничего нет, что соответствовало бы полностью 192.168.10.22/32, поэтому мы продолжим сравнение на не полное соответствие. В этом случае есть запись, которая соответствует 192.168.10.0/24. Приведенный выше пример относится к поиску таблиц маршрутизации, спискам доступа, а также к качеству обслуживания, спискам доступа VLAN и многим другим.
Теперь вы знаете все шаги, которые должен выполнять многоуровневый коммутатор, когда он должен пересылать IP-пакеты, плоскость управления/данных и, что мы используем разные таблицы, хранящиеся в специальном оборудовании, называемом ASIC. Давайте подробнее рассмотрим фактическую «пересылку» IP-пакетов.
Существуют различные методы коммутации для пересылки IP-пакетов. Вот различные варианты коммутации:
Все пакеты проверяются процессором, и все решения о пересылке принимаются в программном обеспечении. очень медленно!
Первый пакет в потоке проверяется процессором; решение о пересылке кэшируется аппаратно для следующих пакетов в том же потоке. Это более быстрый метод.
Таблица пересылки, созданная в аппаратном обеспечении заранее. Все пакеты будут коммутироваться с использованием оборудования. Это самый быстрый метод, но есть некоторые ограничения. Многоуровневые коммутаторы и маршрутизаторы используют CEF.
При использовании процессорной коммутации маршрутизатор удалит заголовок каждого кадра Ethernet, ищет IP-адрес назначения в таблице маршрутизации для каждого IP-пакета, а затем пересылает кадр Ethernet с переписанными MAC-адресами и CRC на исходящий интерфейс. Все делается в программном обеспечении, так что это очень трудоемкий процесс.
Быстрая коммутация более эффективна, потому что она будет искать первый IP-пакет, но будет хранить решение о переадресации в кэше быстрой коммутации. Когда маршрутизаторы получают кадры Ethernet, несущие IP-пакеты в том же потоке, он может использовать информацию в кэше, чтобы переслать их к правильному исходящему интерфейсу.
По умолчанию для маршрутизаторов используется CEF (Cisco Express Forwarding):
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
А вы хорошо знаете статическую маршрутизацию?
Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации 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 секунд можно с помощью команды:
