» » Концепция работы статических маршрутов

Лаборатория Сетей Cisco
 
 
 

Концепция работы статических маршрутов

Автор: HunSolo от 2-07-2013, 23:56, посмотрело: 8882

1 В этой статье мы рассмотрим концепцию статических маршрутов. Для этого мы будем использовать заведомо проблемный сценарий для демонстрации условий, при которых желательно указывать интерфейс через который достижим адрес следующего хопа (Next Hop Address), когда вы конфигурируете статический маршрут.

Введние в статичскую маршрутизацию


Статический маршруты используются по ряду причин и чаще всего, когда не существует динамического маршрута к определенному месту назначения или когда включение динамического протокола маршрутизации не выполнимо. По умолчанию статические маршруты имеют административную дистанцию равную 1, что дает им преимущество над маршрутами изученными из динамических протоколов маршрутизации. Что такое административная дистанция и как она влияет на выбор маршрута, читайте в статье “Административная Дистанция”, опубликованной ранее на CicsoLab.RU.

Когда вы увеличиваете административную дистанцию в значение большем чем значение динамического протокола маршрутизации, статический маршрут будет работать только в случае, когда пропадет динамическая маршрутизация. Например, маршруты изученные из динамического протокола IGRP имеют административную дистанцию по умолчанию 100. Для того, чтобы конфигурировать статический маршрут, который будет перекрыт IGRP маршрутом, укажите административную дистанцию больше 100. Такой вид статической маршрутизации называется “плавающей”. Такой маршрут инсталлируется в таблицу маршрутизации только, когда более предпочтительный маршрут исчезнет оттуда. Например,

ip route 172.31.10.0 255.255.255.0 10.10.10.2 101


Обратите внимание, что административная дистанция 255, рассматривается как недостижимая и статический маршрут с административной дистанцией 255 никогда не будет введен в таблицу маршрутизации.

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

ip route 0.0.0.0 0.0.0.0 Ethernet0


В такой конфигурации маршрутизатор выполняет ARP запросы на интерфейсе Ethernet0 для каждого узла, который попадает в маршрут по умолчанию, потому что маршрутизатор рассматривает все эти узлы как напрямую подсоединенные к этому интерфейсу.

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

Указание числового следующего хопа (next hop) для маршрута, предотвратит выполнение ARP запросов на каждый адрес. Однако, если интерфейс за которым лежит next hop упадет, а числовое значение следующего хопа достижимо через рекурсивный маршрут, вы должный указать и IP адрес следующего хопа и интерфейс через который данный next hop может быть найден. Например,

ip route 0.0.0.0 0.0.0.0 Serial 0/0 192.168.20.1


Проблема статических маршрутов


Теперь рассмотрим небольшой проблемный сценарий. В данной сетевой диаграмме, существует два статических маршрута к одному и тому же месту назначения (172.31.10.0/24). Один маршрут является “плавающим” маршрутом. Это резервный путь к целевой сети. Проблема в данном сценарии в том, что плавающий маршрут никогда не инсталлируется не таблицу маршрутизации, когда основной канал падает.
Концепция работы статических маршрутов


R1 имеет маршрут по умолчанию который указывает на маршрутизатор сервис провайдера (ISP) для доступа в Интернет. R1 также имеет два канала к R2. T1 (Serial0/0) это основной канал, а s0/1 это резервный канал. На R1 настроен статический маршрут в сторону сети 172.31.10.0/24, который указывает на IP адрес интерфейса Serial0 маршрутизатора R2 (10.10.10.2) в качестве следующего хопа. R1 также имеет плавающий маршрут для сети 172.31.10.0/24 который указывает на IP адрес интерфейса Serial0/1 роутера R2 (192.168.20.2). Административная дистанция для такого плавающего статического маршрута установлена в значение 250. Задача, сделать так, чтобы пакеты ходили по 56К каналу в обоих направлениях только в случае падения основного канала.

Конфигурация R1
interface Serial0/0
 description Primary Link to R2
 ip address 10.10.10.1 255.255.255.252
 clock rate 2000000
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/1
 description Backup Link to R2
 ip address 192.168.20.1 255.255.255.252
 clock rate 2000000
!
interface Serial0/2
 no ip address
 shutdown
 clock rate 2000000
!
interface Serial0/3
 description ISP Link
 ip address 192.168.10.1 255.255.255.252
 clock rate 2000000
!
ip forward-protocol nd
!---Это маршрут по умолчнию на ISP router
ip route 0.0.0.0 0.0.0.0 Serial0/3

!---Это основной маршрут к LAN.
ip route 172.31.10.0 255.255.255.0 10.10.10.2

!---Это плавающий маршрут к LAN.
ip route 172.31.10.0 255.255.255.0 192.168.20.2 250

Таблица маршрутизации на R1 выглядит следующим образом:
Концепция работы статических маршрутов


Основной статический маршрут к LAN 172.31.0.0/24 идет через канал T1 10.10.10.2. Маршрут по умолчанию 0.0.0.0/0 смотрим на интерфейс Serial0/3

Конфигурация R2
interface Serial0/0
 description Primary Link to R1
 ip address 10.10.10.2 255.255.255.252
 clock rate 2000000
!
interface FastEthernet0/1
 description Local LAN
 ip address 172.31.10.2 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/1
 description Backup Link to R1
 ip address 192.168.20.2 255.255.255.252
 clock rate 2000000
!
ip forward-protocol nd

!--- Это основной маршрут по умолчнию.
ip route 0.0.0.0 0.0.0.0 10.10.10.1

!--- Это плавающий маршрут по умолчнию, используется если канал T1 неисправен.
ip route 0.0.0.0 0.0.0.0 192.168.20.1 250

R2 имеет маршрут по умолчанию инсталлированный через 10.10.10.1, и когда вы используете команду traceroute от R2 к ISP, пакеты ходят по каналу T1.
Концепция работы статических маршрутов


Трассировка к 192.168.10.2 выглядит следующим образом
Концепция работы статических маршрутов


R2 посылает ICMP пакеты к Internet хосту 192.168.30.1 с адресом отправителя 172.31.10.2.
Концепция работы статических маршрутов


Если мы опускаем интерфейс Serial0/0 на R1, то мы ожидаем, что R1 инсталирует плавающий статический маршрут к сети 172.31.10.0, а R2 инсталирует плавающий статический маршрут для 0.0.0.0 через 192.168.20.1. И по идее трафик будет ходить по 56К каналу. Выполним указанный тест и посмотрим так ли это на самом деле:
R1(config)#int serial0/0
R1(config-if)#shut

Концепция работы статических маршрутов


Взглянем на таблицы маршрутизации обоих роутеров.
Концепция работы статических маршрутов


Заметим, что статический маршрут 172.31.0.0/24 через канал T1 (10.10.10.2) остался в таблице маршрутизации. Это не то, что мы ожидали увидеть, когда выключали Serial 0/0. На маршрутизаторе R2 все правильно
Концепция работы статических маршрутов
.

Однако теперь более не возможно пинговать внешний хост 192.168.30.1, поскольку R1 пытается послать ICMP ответы через Serial0/0 который выключен.
Концепция работы статических маршрутов


Итак плавающий статический маршрут не был инсталлирован на R1 и основной маршрут все еще находиться в таблице маршрутизации R1, даже хотя интерфейс Serial0/0 лежит.
Причина этого поведения в том, что статические маршруты являются рекурсивными по природе. У вас всегда статический маршрут будет храниться в таблице маршрутизации до тех пор пока у вас есть маршрут на следующий хоп. В данном случае, R1 думает, что он может получить 10.10.10.2 через 192.168.10.2, потому, что 192.168.10.2 это следующий хоп для 0.0.0.0 0.0.0.0. Маршрут на следующий хоп может быть более специфичным, менее специфичным или маршрутом по умолчанию. В этом сценарии вы думаете, что поскольку линк упал, у вас не должно быит маршрута для 10.10.10.2, но если вы посмотрите на таблицу маршрутизации R1, вы увидите, что существует статический маршрут по умолчанию, указывающий на ISP роутер R3. Поэтому R1 думает, что он может достичь next hop (10.10.10.2) для сети 172.31.10.0/24, через свой маршрут по умолчанию и статический маршрут 172.31.10.0/24 через 10.10.10.2 остается в таблице маршрутизации, тем самым предотвращаю инсталляцию плавающего маршрута.

Для того, чтобы предотвратить данную проблему вы должны указать интерфейс через который может быть найден следующий хоп. Тогда плавающий маршрут будет инсталлироваться только в случае, когда IP адрес next-hop будет достижим через указный интерфейс. Решение, заключается в удалении старого статического маршрута к сети 172.31.10.0 и добавлении нового, но на этот раз указываем интерфейс, через который достижим IP адрес следующего хопа. Это позволит инсталлировать плавающий маршрут, когда упадет интерфейс Serial0/0.

R1(config)#no ip route 172.31.10.0 255.255.255.0 10.10.10.2
R1(config)#no ip route 172.31.10.0 255.255.255.0 192.168.20.2 250
R1(config)#ip route 172.31.10.0 255.255.255.0 Serial0/0 10.10.10.2
R1(config)#ip route 172.31.10.0 255.255.255.0 Serial0/1 192.168.20.2 250


Теперь снова роняем линк Serial0/0 и смотрим, что получилось
Концепция работы статических маршрутов


Статический маршрут к сети 172.31.10.0 через 10.10.10.2 будет находиться в таблице маршрутизации только, если 10.10.10.2 будет виден через интерфейс Serial0/0. Если данное условие не выполняется, статический маршрут через 10.10.10.2 удаляется их таблицы и взамен инсталлируется плавающий маршрут через Serial 0/1 и следующий хоп 192.168.20.2.

Концепция работы статических маршрутов




Категория: Маршрутизация

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.
<
  • 0 комментариев
  • 0 публикаций
  • ICQ:
31 июля 2014 14:13

Александр

Цитата
  • Группа: Гости
  • Регистрация: --
  • Статус:
 
Эх, уже надеялся что нашел то что надо. но не тут то было. так работает если физически выдергивать кабель или ложить порт ... но если где- на промежуточных комутаторах пропадает линк, то маршруты не меняются !

и так проблема решена :) есть такое чудо на цисках как ip sla ... вот с егопомощью все решается :) мож кому помогу, вкратце: (взято с хабра)
Задаем параметры «пинговалики»
ip sla {#}
icmp-echo {ip} [source-interface {int}]
Запускаем пинговалку
ip sla schedule {#} start now life forever
Настраиваем «переключатель» (track), от которого будет зависеть маршрут
track {#} ip sla {#} reachability
Настраиваем маршрут по умолчанию с трекингом
ip route 0.0.0.0 0.0.0.0 {next-hop} track {#}


Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Вопрос:
Семьдесят одежек И все без застежек
Ответ:*
Введите два слова, показанных на изображении: *