В этой статье мы рассмотрим концепцию статических маршрутов. Для этого мы будем использовать заведомо проблемный сценарий для демонстрации условий, при которых желательно указывать интерфейс через который достижим адрес следующего хопа (Next Hop Address), когда вы конфигурируете статический маршрут.
Введение в статичскую маршрутизацию
Статический маршруты используются по ряду причин и чаще всего, когда не существует динамического маршрута к определенному месту назначения или когда включение динамического протокола маршрутизации не выполнимо. По умолчанию статические маршруты имеют административную дистанцию равную 1, что дает им преимущество над маршрутами изученными из динамических протоколов маршрутизации.
Когда вы увеличиваете административную дистанцию в значение большем чем значение динамического протокола маршрутизации, статический маршрут будет работать только в случае, когда пропадет динамическая маршрутизация. Например, маршруты изученные из динамического протокола 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 3/3 192.168.20.1
Проблема
Теперь рассмотрим небольшой проблемный сценарий. В данной сетевой диаграмме, существует два статических маршрута к одному и тому же месту назначения (172.31.10.0/24). Один маршрут является “плавающим” маршрутом. Это резервный путь к целевой сети. Проблема в данном сценарии в том, что плавающий маршрут никогда не инсталлируется не таблицу маршрутизации, когда основной канал падает.
R1 имеет маршрут по умолчанию который указывает на маршрутизатор сервис провайдера (ISP) для доступа в Интернет. R1 также имеет два канала к R2. T1 это основной канал, а 56К это резервный канал. На R1 настроен статический маршрут в сторону сети 172.31.10.0/24, который указывает на IP адрес интерфейса Serial0 маршрутизатора R2 (10.10.10.2) в качестве следующего хопа. R1 также имеет плавающий маршрут для сети 172.31.10.0/24 который указывает на IP адрес интерфейса Serial1 роутера R2 (192.168.20.2). Административная дистанция для такого плавающего статического маршрута установлена в значение 250. Задача, сделать так, чтобы пакеты ходили по 56К каналу в обоих направлениях только в случае падения основного канала.
Конфигурация R1
hostname R1 ! ip subnet-zero ! interface Serial3/0 description ISP Link ip address 192.168.10.1 255.255.255.252 clockrate 64000 ! interface Serial3/2 description Primary Link to R2 ip address 10.10.10.1 255.255.255.252 ! interface Serial3/3 description Backup Link to R2 ip address 192.168.20.1 255.255.255.252 clockrate 64000 ! ip classless !---Это маршрут по умолчнию на ISP router ip route 0.0.0.0 0.0.0.0 Serial3/0!---Это основной маршрут к 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 выглядит следующим образом:
R1#show ip route Gateway of last resort is 0.0.0.0 to network 0.0.0.010.0.0.0/30 is subnetted, 1 subnets C 10.10.10.0 is directly connected, Serial3/2 192.168.10.0/30 is subnetted, 1 subnets C 192.168.10.0 is directly connected, Serial3/0 192.168.20.0/30 is subnetted, 1 subnets C 192.168.20.0 is directly connected, Serial3/3 !--- Основной статический маршруи к LAN через канал T1. 172.31.0.0/24 is subnetted, 1 subnets S 172.31.10.0 [1/0] via 10.10.10.2 !--- Статический маршрут по умолчнию в Internet. S* 0.0.0.0/0 is directly connected, Serial3/0
Конфигурация R2
hostname R2 ip subnet-zero ! interface Ethernet0 description Local LAN ip address 172.31.10.2 255.255.255.0 ! interface Serial0 description Primary Link to R1 ip address 10.10.10.2 255.255.255.252 clockrate 56000 ! interface Serial1 description Backup Link to R1 ip address 192.168.20.2 255.255.255.252 ! ip classless!--- Это основной маршрут по умолчнию. 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.
R2#show ip route Gateway of last resort is 10.10.10.1 to network 0.0.0.0172.31.0.0/24 is subnetted, 1 subnets C 172.31.10.0 is directly connected, Ethernet0 192.168.20.0/30 is subnetted, 1 subnets C 192.168.20.0 is directly connected, Serial1 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.10.10.0/30 is directly connected, Serial0 !--- Это основной маршрут по умолчнию. S* 0.0.0.0/0 [1/0] via 10.10.10.1
R2#traceroute 192.168.10.2Type escape sequence to abort. Tracing the route to 192.168.10.2 1 10.10.10.1 16 msec 20 msec 16 msec 2 192.168.10.2 32 msec * 32 msec
R2 посылает ICMP пакеты к Internet хосту 192.168.30.1 с адресом отправителя 172.31.10.2.
R2#ping 192.168.30.1 source 172.31.10.2 Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
Если мы опускаем интерфейс Serial3/2 на R1, то мы ожидаем, что R1 инсталирует плавающий статический маршрут к сети 172.31.10.0, а R2 инсталирует плавающий статический маршрут для 0.0.0.0 через 192.168.20.1. И по идее трафик будет ходить по 56К каналу.
Выполним указанный тест и посмотрим так ли это на самом деле:
R1#show ip interface brief Interface IP-Address OK? Method Status Protocol Serial3/0 192.168.10.1 YES manual up up Serial3/2 10.10.10.1 YES manual up up Serial3/3 192.168.20.1 YES manual up upR1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int s3/2 R1(config-if)#shut R1(config-if)#end 2d21h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/2, changed state to down 2d21h: %LINK-5-CHANGED: Interface Serial3/2, changed state to administratively down R1#show ip interface brief Interface IP-Address OK? Method Status Protocol Serial3/0 192.168.10.1 YES manual up& up Serial3/2 10.10.10.1 YES manual administratively down down Serial3/3 192.168.20.1 YES manual up up
Взглянем на таблицы маршрутизации обоих роутеров.
R1#show ip route Gateway of last resort is 0.0.0.0 to network 0.0.0.0192.168.10.0/30 is subnetted, 1 subnets C 192.168.10.0 is directly connected, Serial3/0 192.168.20.0/30 is subnetted, 1 subnets C 192.168.20.0 is directly connected, Serial3/3 !--- Статический маршрут через канал T1 остался в таблице маршрутизации. !--- Это не то, что мы ожидали увидеть, когда выключали Serial 3/2 172.31.0.0/24 is subnetted, 1 subnets S 172.31.10.0 [1/0] via 10.10.10.2 !--- Маршрут по умолчнию в Интерент. S* 0.0.0.0/0 is directly connected, Serial3/0
На маршрутизаторе R2 все павильно.
R2#show ip route Gateway of last resort is 192.168.20.1 to network 0.0.0.0172.31.0.0/24 is subnetted, 1 subnets C 172.31.10.0 is directly connected, Ethernet0 192.168.20.0/30 is subnetted, 1 subnets C 192.168.20.0 is directly connected, Serial1 S* 0.0.0.0/0 [250/0] via 192.168.20.1
Однако теперь более не возможно пинговать внешний хост 192.168.20.1, поскольку R1 пытается послать ICMP ответы через Serial3/2 который выключен.
R2#ping 192.168.30.1 source 172.31.10.2 Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Итак плавающий статический маршрут не был инсталлирован на R1 и основной маршрут все еще находиться в таблице маршрутизации R1, даже хотя интерфейс Serial3/2 лежит.
Причина этого поведения в том, что статические маршруты являются рекурсивными по природе. У вас всегда статический маршрут будет храниться в таблице маршрутизации до тех пор пока у вас есть маршрут на следующий хоп. В данном случае, 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 роутер. Поэтому 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 адрес следующего хопа. Это позволит инсталлировать плавающий маршрут, когда упадет интерфейс Serial3/2.
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 Serial3/2 10.10.10.2 R1(config)#ip route 172.31.10.0 255.255.255.0 Serial3/3 192.168.20.2 250
Статический маршрут к сети 172.31.10.0 через 10.10.10.2 будет находиться в таблице маршрутизации только, если 10.10.10.2 будет виден через интерфейс Serial3/2. Если данное условие не выполняется, статический маршрут через 10.10.10.2 удаляется их таблицы и взамен инсталлируется плавающий маршрут через Serial 3/3 и следующий хоп 192.168.20.2.
По материалам: cisco.com
One Comment