Маршрутизация (в Cisco Packet Tracer )
Вложения
 | ee.rar (10.1 Кб, 34 просмотров) |
Маршрутизация Cisco Packet Tracer
Доброго времени суток, форумчане 🙂 Поставил 2 сервера, DHCP выдает ip адреса, но не могу.
Маршрутизация Cisco Packet Tracer
построил схемку, назначил адреса, как видно на прикреплённом документе. прописываю маршруты.
Маршрутизация Cisco Packet Tracer
Создал схему, прописал адреса и задал таблицу маршрутизации, но когда пингую возникает такая.
смотрел что pc0 не проводит трейс на этих роутерах
Добавлено через 9 минут
может я маршрут не прописал
и еще когда я буду делать маршрут для роутера 1 то мне какой айпи брать? я просто первый раз в ней работаю
Добавлено через 2 минуты
как вы мне посоветовали он сейчас выдает %Invalid next hop address (it’s this router)
для роутера 1 достаточно вот такого маршрута
ip route 0.0.0.0 0.0.0.0 192.168.10.3
Добавлено через 1 минуту
«пишет же вам %Inconsistent address and mask
ip route 192.168.10.0 255.255.255.0 192.168.13.1 вот так надо, а вы не верно адрес сети указываете»
Добавлено через 55 минут
он роутер даже не пингует
Добавлено через 30 секунд
просто прописываю в роутере айпишник который в пк задавал и он его не пингует
а как прописать это?
Добавлено через 1 минуту
просто я ведь вроде указывал для каждого маршрутизатора айпи
Вложения
| ee.rar (10.7 Кб, 13 просмотров) |
тоесть там 192.168.13.2 надо ставить
Добавлено через 1 минуту
сейчас исправлю где надо айпишники
Вложения
| ee.rar (10.7 Кб, 5 просмотров) |
Вложения
| ee.rar (10.7 Кб, 23 просмотров) |
а что там именно исправить надо? что удалить
Добавлено через 41 минуту
всмысле в разных сетях как это исправить?
Добавлено через 1 минуту
у меня роутер 2 соединяется с пк fa0/0 я изза этого прописал туда айипи адрес
Добавлено через 1 час 46 минут
и тогда как и какие fastethernet удалять?
Добавлено через 11 часов 22 минуты
тоесть надо просто поменять айпи пк на 192.168.10.1?
Статическая маршрутизация Cisco Packet Tracer
Здравствуйте. Помогите пожалуйста, разобраться, что неправильно настроено в моей топологии (с PC 1.
Статическая маршрутизация в Cisco Packet Tracer
помогите пожалуйста с заданием, не могу самостоятельно разобраться. заранее спасибо
Маршрутизация в эмуляторе cisco packet tracer
помогите,нужно настроить маршрутизацию по всем 4 подсетям. я настроила между 1 и 3, 2 и 3, 3 и 4.
Cisco CLI Error: % Inconsistent address and mask
When does this error appear?
What does this error mean?
This error indicates that the network address specified in the command is not a valid network address for the subnet mask specified.
The basic format of the ip route command as follows:
| ip | route | 192.168.1.0 | 255.255.255.0 | 10.0.0.1 |
| network address | subnet mask | next hop |
The network address parameter must be a valid network address when combined with the subnet mask parameter. When entering the ip route command on a Cisco router, if we see the error message «% Inconsistent address and mask» it indicates to us that the combination of the network address parameter and the subnet mask paramter is incorrect.
Example 1 (Mistake or typo when entering the network address):
| ip | route | 10.8.1. 1 | 255.255.255.0 | 172.20.100.98 |
| network address | subnet mask | next hop |
| ip | route | 10.8.1. 0 | 255.255.255.0 | 172.20.100.98 |
| network address | subnet mask | next hop |
With the correct network address paramer, the router accepts the command:
Example 2 (Mistake or typo when entering the subnet mask):
With the correct subnet mask paramer, the router accepts the command:
Conclusion
The error message «% Inconsistent address and mask» may appear while attempting to add a static route on a Cisco router. This error message indicates that the combination of the network address and subnet mask parameters does not define a valid network address. If you receive this error message while configuring a static route on a Cisco router, check the network address and subnet mask parameters in the command that you have entered. There is a mistake or typo in either the network address or subnet mask parameter such that the network address as entered is actually a host address.
Настройка сети cisco
Вложения
| lab3.rar (13.4 Кб, 12 просмотров) |
Настройка сети с оборудивания Cisco, в Cisco Packet Tracer
Добрий день. Помогите настроить сеть. Есть физическая топология, есть разпределени между собой.
Настройка сети в Cisco
Помогите пожалуйста адекватно настроить
Cisco. Базовая настройка сети
Всем привет. нужна ваша помощь. Я в cisco мало что понимаю. Кому не лень помогите составить эту.
Добавлено через 3 минуты
Извеняюсь r1(config)#ip route 192.168.2.1 255.255.255.0 s 2/0
ты идешь не в адрес хоста, а в адрес сети
Вложения
 | !lab3.zip (16.4 Кб, 30 просмотров) |
Настройка сети на Cisco AIR-AP1242AG
Добрый день, первый раз настраиваю циску, такой вопрос: есть Cisco AIR-AP1242AG и сеть.
Настройка сети в Cisco Packet Tracer
Как настроить что бы ПК6 пинговался например с ПК5 но не пингвался с ПК2. А ПК5 пинговался с ПК2.
Cisco Packet Tracer: настройка сети
Народ, доброго дня, помогите. Поставлена задача настроить сеть, состоящую из трех роутеров.
А вы хорошо знаете статическую маршрутизацию?
Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации 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 секунд можно с помощью команды:
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Cisco: Настройка статических маршрутов
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Статические сетевые маршруты
IOS позволяет назначать отдельные статические маршруты с помощью команды глобальной конфигурации ip route. Каждая команда ip route определяет пункт назначения, который может быть сопоставлен, обычно с идентификатором подсети и маской. Команда также перечисляет инструкции пересылки, обычно перечисляя либо исходящий интерфейс, либо IP-адрес маршрутизатора следующего перехода. Затем IOS берет эту информацию и добавляет этот маршрут в таблицу IP-маршрутизации.
Статический маршрут считается сетевым, когда пункт назначения, указанный в команде ip route, определяет подсеть или всю сеть класса A, B или C. Напротив, маршрут по умолчанию соответствует всем IP-адресам назначения, а маршрут хоста соответствует одному IP-адресу (то есть адресу одного хоста).
В качестве примера сетевого маршрута рассмотрим рисунок 1. На рисунке показаны только детали, относящиеся к статическому сетевому маршруту на R1 для подсети назначения 172.16.2.0/24, которая находится справа. Чтобы создать этот статический сетевой маршрут на R1, R1 настроит идентификатор и маску подсети, а также либо исходящий интерфейс R1 (S0/0/0), либо R2 в качестве IP-адреса маршрутизатора следующего перехода (172.16.4.2).
В примере 1 показана конфигурация двух примеров статических маршрутов. В частности, он показывает маршруты на маршрутизаторе R1 на рисунке 2 для двух подсетей в правой части рисунка.
Пример 1 Добавление статических маршрутов в R1
В двух примерах команд ip route показаны два разных стиля инструкций пересылки. Первая команда показывает подсеть 172.16.2.0, маска 255.255.255.0, которая находится в локальной сети рядом с маршрутизатором R2. Эта же первая команда перечисляет интерфейс S0 / 0/0 маршрутизатора R1 как исходящий интерфейс. Этот маршрут в основном гласит: Чтобы отправить пакеты в подсеть с маршрутизатора R2, отправьте их через мой собственный локальный интерфейс S0/0/0 (который подключается к R2).
Второй маршрут имеет такую же логику, за исключением использования различных инструкций пересылки. Вместо того, чтобы ссылаться на исходящий интерфейс R1, он вместо этого перечисляет IP-адрес соседнего маршрутизатора на WAN-канале в качестве маршрутизатора следующего прыжка. Этот маршрут в основном говорит следующее:чтобы отправить пакеты в подсеть с маршрут.
В примере 2 эти два маршрута перечислены с помощью статической команды show ip route. Эта команда выводит подробную информацию не только о статических маршрутах, но также приводит некоторые статистические данные обо всех маршрутах IPv4. Например, в этом примере показаны две строки для двух статических маршрутов, настроенных в примере 2, но статистика утверждает, что этот маршрутизатор имеет маршруты для восьми подсетей.
IOS динамически добавляет и удаляет эти статические маршруты с течением времени в зависимости от того, работает исходящий интерфейс или нет. Например, в этом случае, если интерфейс R1 S0/0/0 выходит из строя, R1 удаляет статический маршрут к 172.16.2.0/24 из таблицы маршрутизации IPv4. Позже, когда интерфейс снова открывается, IOS добавляет маршрут обратно в таблицу маршрутизации.
Обратите внимание, что большинство сайтов используют протокол динамической маршрутизации для изучения всех маршрутов к удаленным подсетям, а не статические маршруты. Однако если протокол динамической маршрутизации не используется, сетевому администратору необходимо настроить статические маршруты для каждой подсети на каждом маршрутизаторе. Например, если бы маршрутизаторы имели только конфигурацию, показанную в примерах до сих пор, ПК А (из рис. 2) не смог бы получать пакеты обратно от ПК В, потому что маршрутизатор R2 не имеет маршрута для подсети ПК А. R2 понадобятся статические маршруты для других подсетей, как и R3.
Статические маршруты хоста
Ранее в этой лекции маршрут хоста определялся как маршрут к одному адресу хоста. Для настройки такого статического маршрута команда ip route использует IP-адрес плюс маску 255.255.255.255, чтобы логика сопоставления соответствовала только этому одному адресу.
Обратите внимание, что эти два маршрута перекрываются: пакет, отправленный в 10.1.1.9, который поступает на маршрутизатор, будет соответствовать обоим маршрутам. Когда это происходит, маршрутизаторы используют наиболее конкретный маршрут (то есть маршрут с наибольшей длиной префикса). Таким образом, пакет, отправленный на 10.1.1.9, будет перенаправлен на маршрутизатор следующего прыжка 10.9.9.9, а пакеты, отправленные в другие пункты назначения в подсети 10.1.1.0/24, будут отправлены на маршрутизатор следующего прыжка 10.2.2.2.
Плавающие статические маршруты
Затем рассмотрим случай, когда статический маршрут конкурирует с другими статическими маршрутами или маршрутами, изученными протоколом маршрутизации. То есть команда ip route определяет маршрут к подсети, но маршрутизатор также знает другие статические или динамически изученные маршруты для достижения этой же подсети. В этих случаях маршрутизатор должен сначала решить, какой источник маршрутизации имеет лучшее административное расстояние, а чем меньше, тем лучше, а затем использовать маршрут, полученный от лучшего источника.
Чтобы увидеть, как это работает, рассмотрим пример, проиллюстрированный на рисунке 3, который показывает другую конструкцию, чем в предыдущих примерах, на этот раз с филиалом с двумя каналами WAN: одним очень быстрым каналом Gigabit Ethernet и одним довольно медленным (но дешево) Т1. В этом проекте сеть Open Shortest Path First Version 2 (OSPFv2) по первичному каналу, изучая маршрут для подсети 172.16.2.0/24. R1 также определяет статический маршрут по резервному каналу к той же самой подсети, поэтому R1 должен выбрать, использовать ли статический маршрут или маршрут, полученный с помощью OSPF.
Сетевая диаграмма показывает интерфейс G0 / 0 маршрутизатора R1, который подключен к маршрутизатору R2 через ethernet через облако MPLS. Интерфейс S0 / 0 / 1 R1 соединен с маршрутизатором R3 по последовательной линии. R2 и R3 соединены в ядре облака корпоративной сети, имеющего подсеть 172.16.2.0/24. Маршрутизатор R1 достигает подсети либо по OSPF v1 по основному каналу, либо по статическому маршруту по резервному каналу.
По умолчанию IOS отдает предпочтение статическим маршрутам, чем маршрутам, изученным OSPF. По умолчанию IOS предоставляет статическим маршрутам административное расстояние 1, а маршрутам OSPF-административное расстояние 110. Используя эти значения по умолчанию на рисунке 3, R1 будет использовать T1 для достижения подсети 172.16.2.0 / 24 в этом случае, что не является удачным решением. Вместо этого сетевой администратор предпочитает использовать маршруты, изученные OSPF, по гораздо более быстрому основному каналу и использовать статический маршрут по резервному каналу только по мере необходимости, когда основной канал выходит из строя.
Чтобы отдавать предпочтение маршрутам OSPF, в конфигурации необходимо изменить настройки административного расстояния и использовать то, что многие сетевики называют плавающим статическим маршрутом. Плавающий статический маршрут перемещается в таблицу IP-маршрутизации или перемещается из нее в зависимости от того, существует ли в настоящее время лучший (меньший) маршрут административного расстояния, полученный протоколом маршрутизации. По сути, маршрутизатор игнорирует статический маршрут в то время, когда известен лучший маршрут протокола маршрутизации.
Наконец, обратите внимание, что хотя команда show ip route перечисляет административное расстояние большинства маршрутов в виде первого из двух чисел в двух скобках, команда show ip route subnet явно указывает административное расстояние. В примере 3 показан образец, соответствующий этому последнему примеру.
Статические маршруты по умолчанию
Когда маршрутизатор пытается маршрутизировать пакет, он может не совпадать с IP-адресом назначения пакета ни с одним маршрутом. Когда это происходит, маршрутизатор обычно просто отбрасывает пакет.
Маршрутизаторы могут быть сконфигурированы таким образом, чтобы они использовали либо статически настроенный, либо динамически изучаемый маршрут по умолчанию. Маршрут по умолчанию соответствует всем пакетам, так что, если пакет не соответствует какому-либо другому более конкретному маршруту в таблице маршрутизации, маршрутизатор может, по крайней мере, переслать пакет на основе маршрута по умолчанию.
IOS позволяет настроить статический маршрут по умолчанию, используя специальные значения для полей подсети и маски в команде ip route: 0.0.0.0 и 0.0.0.0. Например, команда ip route 0.0.0.0 0.0.0.0 S0/0/1 создает статический маршрут по умолчанию на маршрутизаторе B1-маршрут, который соответствует всем IP-пакетам-и отправляет эти пакеты через интерфейс S0/0/1.
В примере 4 показан пример статического маршрута по умолчанию с использованием маршрутизатора R2 с рисунка 1. Ранее на этом рисунке вместе с примером 3 был показан маршрутизатор R1 со статическими маршрутами к двум подсетям в правой части рисунка. Пример 4 завершает настройку статических IP-маршрутов путем настройки R2 в правой части рисунка 1 со статическим маршрутом по умолчанию для маршрутизации пакетов обратно к маршрутизаторам в левой части рисунка.
Вывод команды show ip route содержит несколько новых и интересных фактов. Во-первых, он перечисляет маршрут с кодом S, что означает статический, но также со знаком *, что означает, что это кандидат в маршрут по умолчанию. Маршрутизатор может узнать о нескольких маршрутах по умолчанию, и затем маршрутизатор должен выбрать, какой из них использовать; * означает, что это, по крайней мере, кандидат на то, чтобы стать маршрутом по умолчанию. Чуть выше «шлюз последней надежды» относится к выбранному маршруту по умолчанию, который в данном случае является только что настроенным статическим маршрутом с исходящим интерфейсом S0/0/1.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
