Static route ip route: Configuring static IP routes

Содержание

Static routing — Gentoo Wiki

From Gentoo Wiki

Jump to:navigationJump to:search

Other languages:

English
русский

A route is a rule set in the kernel that is used to determine which physical network interface or gateway is needed in order to reach a particular network (or single host). There are many types of routed protocols; this article covers routing of the IP protocol in the Linux kernel.

Although IP routes are stored in the kernel, they are modifiable by userspace tools as described in the following examples.

1 Showing routes
2 Adding a static route
3 Adding a permanent static route
4 See also
5 External resources

Showing routes

Show the routing table with iproute2:

user $ip route

default via 192.168.1.1 dev wlan1 metric 1
192. 168.50.0/24 dev lan proto kernel scope link src 192.168.50.1
127.0.0.0/8 via 127.0.0.1 dev lo 
192.168.1.0/24 dev wlan1 proto kernel scope link src 192.168.1.1

Or show the routing table using sys-apps/net-tools:

user $netstat -rn

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.1.0     0.0.0.0         255.255.255.0   U     2000   0        0 wlan1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    2000   0        0 wlan1

Adding a static route

The IP address, subnet mask (CIDR), and gateway are necessary prerequisite information before adding a static route.

In this example the 10.10.10.0 network with a 255.255.255.0 subnet mask will be routed to the 192.168. 1.50 gateway. CIDR style netmasks are required when adding routes using commands from the sys-apps/iproute2 package (ip). The following example will add the 10.10.10.0/24 route:

root #ip route add 10.10.10.0/24 via 192.168.1.50

Show the routing table using the ip route command:

user $ip route

default via 192.168.1.1 dev wlan1 metric 1
10.10.10.0/24 dev wlan1 via 192.168.1.50 src 10.10.10.1
192.168.50.0/24 dev lan proto kernel scope link src 192.168.50.1
127.0.0.0/8 via 127.0.0.1 dev lo 
192.168.1.0/24 dev wlan1 proto kernel scope link src 192.168.1.1

Older systems may possibly only have the netstat or route commands (via sys-apps/net-tools) instead of ip used in the above example.

Adding the same static route as described above using the route command:

root #route add -net 10. 10.10.0 netmask 255.255.255.0 gw 192.168.1.50

Show routing table using netstat (sys-apps/net-tools):

user $netstat -rn

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.0      192.168.1.50    255.255.255.0   UG    0      0        0 wlan1
192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0 lan
192.168.1.0     0.0.0.0         255.255.255.0   U     2000   0        0 wlan1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.1     0.0.0.0         UG    2000   0        0 wlan1

The routing table is sorted from most specific routes to most general. This is how it is read by the routing process. Longest prefix match — means the the smallest network, or the network with the largest netmask, or the most specific route f.e. 255.255.255.255 is at first position in the routing table.

Adding a permanent static route

For users of the netifrc scripts (OpenRC’s standard network tools), permanent static routes can be added by opening a preferred text editor to /etc/conf.d/net and adjusting the file accordingly.

Reference the current routing table for help.

FILE /etc/conf.d/net

routes_wlan1="10.10.10.0/24 via 192.168.1.50
    default via 192.168.1.1"

With dhcpcd as network manager the static route goes into /etc/dhcpcd.conf instead.

Both statements above mean:

IP packets destined to the 10.10.10.0/24 network are send to 192.168.1.50.
IP packets destined to all 0.0.0.0/0 other networks are send to 192.168.1.1.

Note
0.0.0.0/0 means all other networks without a prefix (Subnet mask), the default route

The default route 0.0.0.0/0 is used if:

The host has no physical or logical IP interface in the target network segment.
The host has to send IP packets outside of its own IP network segment, and there is no specific route found in the routing table for target IP network.

External resources

Longest prefix match (on Wikipedia)
Gentoo Bug 5409326

А вы хорошо знаете статическую маршрутизацию? / Хабр

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

Оговорка. При написании топика я исхожу из того, что читатель знаком с концепцией маршрутизации, умеет делать статические маршруты и не считает слово «ARP» ругательным. Впрочем, даже бывалые связисты наверняка найдут тут что-то новое.

Все примеры были проверены на IOS линейки 15.2M. Поведение других ОС может различаться.

И никакого динамического роутинга тут не будет.

Мы работаем со следующей топологией:

Как появляется статический маршрут?

Для начала, выполним команду, которую знает каждый, и посмотрим дебагами, что произойдет:

R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3

IP-ST(default): updating same distance on 3.1.1.0/24
IP-ST(default):  3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state
IP-ST(default):  3.1.1.0/24 [1], 10.0.0.3 Path = 2 3 7
RT: updating static 3.1.1.0/24 (0x0):
    via 10.0.0.3
RT: add 3.1.1.0/24 via 10.0.0.3, static metric [1/0], add succeed, active state
IP ARP: creating incomplete entry for IP address: 10.0.0.3 interface GigabitEthernet0/1
IP ARP: sent req src 10.0.0.1 30e4.db16.7791,
                 dst 10. 0.0.3 0000.0000.0000 GigabitEthernet0/1
IP ARP: rcvd rep src 10.0.0.3 0019.aad6.ae10, dst 10.0.0.1 GigabitEthernet0/1

IOS создал маршрут, и сразу послал arp запрос в поисках next hop, который у нас – 10.0.0.3. И сразу вопрос: откуда роутер узнал, что запрос надо слать в интерфейс Gi0/1? Наверняка кто-то скажет «из списка локальных интерфейсов», и жестоко ошибется. Маршрутизация так не работает. На самом деле, IOS сделал рекурсивный запрос к таблице маршрутизации, чтобы узнать, как добраться до next hop:

R00#show ip route 10.0.0.3
Routing entry for 10.0.0.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0/1
      Route metric is 0, traffic share count is 1

И вот он, наш 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 (таблица соседств). Первая из них строится на основе таблицы маршрутизации и за один проход позволяет получить всю нужную информацию. Строится она заранее, еще до того, как появится первый соответствующий ей пакет.

Вернемся к нашему статическому маршруту. Вот запись в таблице маршрутизации:

R00#show ip route 3.1.1.0
Routing entry for 3.1.1.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.0.3
      Route metric is 0, traffic share count is 1

Куда слать пакет? Где искать 10.0.0.3? Непонятно. Надо еще раз запросить таблицу маршрутизации, на этот раз по поводу 10.0.0.3, и, если надо, выполнить еще несколько итераций, пока не выясним connected интерфейс. И вот примерно таким образом мы фактически в несколько раз снижаем производительность маршрутизатора.

А вот что говорит CEF:

R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0
  recursive via 10.0.0.3
    attached to GigabitEthernet0/1

Просто и лаконично. Есть интерфейс, есть next hop, к которому надо слать пакет. Что там говорилось про adjacency table?

R00#show adjacency 10.0.0.3 detail
Protocol Interface                 Address
IP       GigabitEthernet0/1        10.0.0.3(10)
                                   0 packets, 0 bytes
                                   epoch 0
                                   sourced in sev-epoch 2
                                   Encap length 14
                                   0019AAD6AE1030E4DB1677910800
                                   ARP

Обратим внимание на какую-то длинную последовательность в предпоследней строке. Что-то это напоминает… Смотрим mac 10.0.0.3:

R00#show arp | in 10.0.0.3
Internet  10.0.0.3                1   0019.aad6.ae10  ARPA   GigabitEthernet0/1

Смотрим свой mac адрес на gi0/1:

R00#show int gi0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is CN Gigabit Ethernet, address is 30e4.db16.7791 (bia 30e4.db16.7791)

Ага. Та страшная строка – всего лишь два мака, которые надо подставить в заголовок Ethernet на этапе инкапсуляции, и ethertype 0x0800, т.е. банальный IPv4. И в двух таблицах CEF есть абсолютно вся информация, какая нужна для успешной отправки пакета дальше по цепочке.

Если у кого-то возникнет вопрос, зачем железке держать сразу две таблицы вместо одной, то дам очевидный ответ: обычно у маршрутизатора мало интерфейсов (а заодно и соседей) и много маршрутов. Какой смысл тысячи раз дублировать одни и те же маки в FIB? Памяти много не бывает, особенно на аппаратных платформах, будь то новомодные ASR’ы или даже L3 свитчи линейки Catalyst. Все они задействуют CEF при передаче пакетов.

И кстати, вернемся на минутку к изначальному дебагу. Отключим CEF командой no ip cef (никогда так не делайте) и сравним результат:

IP-ST(default): updating same distance on 3.1.1.0/24
IP-ST(default):  3.1.1.0/24 [1], 10.0.0.100 Path = 8, no change, not active state
IP-ST(default):  3.1.1.0/24 [1], 10. 0.0.100 Path = 2 3 7
RT: updating static 3.1.1.0/24 (0x0):
    via 10.0.0.100
RT: add 3.1.1.0/24 via 10.0.0.100, static metric [1/0], add succeed, active state

Маршрут добавлен. Arp запроса не было. И правильно – зачем RIB сдался mac адрес? Если пустить пинг до, к примеру, 3.1.1.1, то скорее всего будет так:

R00#ping 3.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.1.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms

Первый пакет отбрасывается, и роутер посылает arp запрос с целью узнать mac адрес 10.0.0.3, если он ранее не был известен. CEF же всегда заранее узнает mac адрес next hop’а.

С этим разобрались. Теперь вернемся к вопросу, что будет, если next hop статического маршрута вовсе не на directly connected интерфейсе. Поступим просто:

R00(config)#ip route 10.0.0.3 255.255.255.255 100.100.100.101

, где Gi0/2 имеет адрес 100. 100.100.100/24.

R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0
  recursive via 10.0.0.3
    recursive via 100.100.100.101
      recursive via 100.100.100.0/24
        attached to GigabitEthernet0/2

Как все плохо-то… А что если у нас есть маршрут на целую суперсеть?

R00(config)#no ip route 10.0.0.3 255.255.255.255 100.100.100.101
R00(config)#ip route 10.0.0.0 255.0.0.0 100.100.100.101
R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0
  recursive via 10.0.0.3
    attached to GigabitEthernet0/1

Сейчас наша таблица маршрутизации выглядит так:

R00#show ip route
      10.0.0.0/8 is variably subnetted, 2 subnets, 3 masks
S        10.0.0.0/8 [1/0] via 100.100.100.101
C        10.0.0.0/24 is directly connected, GigabitEthernet0/1
L        10.0.0.1/32 is directly connected, GigabitEthernet0/1
      100.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        100.100.100.0/24 is directly connected, GigabitEthernet0/2
L        100. 100.100.100/32 is directly connected, GigabitEthernet0/2

Вроде хорошо. Новый маршрут на 100.100.100.101 не применяется для 10.0.0.3, так как его маска /8 намного короче, чем /24 у connected интерфейса. Но вдруг Gi0/1, содержавший next hop для 3.1.1.0/24, по какой-то непонятной причине ушел в down, и его connected маршрут пропал из RIB.

%LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
RT: interface GigabitEthernet0/1 removed from routing table
RT: del 10.0.0.0 via 0.0.0.0, connected metric [0/0]
RT: delete subnet route to 10.0.0.0/24
RT: del 10.0.0.1 via 0.0.0.0, connected metric [0/0]
RT: delete subnet route to 10.0.0.1/32
IP-ST(default):  updating GigabitEthernet0/1

Вот что стало:

R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0
  recursive via 10.0.0.3
    recursive via 10. 0.0.0/8
      recursive via 100.100.100.101
        recursive via 100.100.100.0/24
          attached to GigabitEthernet0/2

Ой. Теперь пакеты на сеть 3.1.1.0/24 идут куда-то не туда. Я не могу представить себе сценарий, когда ожидаемое поведение статического маршрута – переключение на другой интерфейс. Если за тем интерфейсом находится резервный путь, то все-таки надо создавать еще один статический маршрут…

Что делать? Указывать сразу в маршруте интерфейс. Пересоздадим маршрут:

R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3
R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3

Поднимаем Gi0/1. Смотрим, куда теперь ведет маршрут на 3.1.1.0/24:

R00#show ip route 3.1.1.0
Routing entry for 3.1.1.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.0.3, via GigabitEthernet0/1
      Route metric is 0, traffic share count is 1

Тут уже указан интерфейс. Поэтому не будет рекурсивных запросов к таблице маршрутизации. Проверяем FIB:

R00#show ip cef 3.1.1.0
3.1.1.0/24
  nexthop 10.0.0.3 GigabitEthernet0/1

Да, никакого «recursive». А если снова погасить gi0/1? Маршрут исчез.

R00#show ip route 3.1.1.0
% Network not in table
R00#show ip cef 3.1.1.0
0.0.0.0/0
  no route

И это притом, что маршрут до 10.0.0.3 все еще был:

R00#show ip cef 10.0.0.3
10.0.0.0/8
  nexthop 100.100.100.101 GigabitEthernet0/2

А что будет, если путь к next hop даст маршрут по умолчанию, а маршрут на 3.1.1.0/24 не ссылается на интерфейс?

R00(config)#no ip route 10.0.0.0 255.0.0.0 100.100.100.101
R00(config)#ip route 0.0.0.0 0.0.0.0 100.100.100.101
R00(config)#no ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3
R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3
R00#show ip route 3.1.1.0
% Network not in table
R00#show ip cef 3. 1.1.0 detail
0.0.0.0/0, epoch 0, flags default route
  recursive via 100.100.100.101
    recursive via 100.100.100.0/24
      attached to GigabitEthernet0/2

Обратите внимание, что первой строкой после «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 адрес должен указываться всегда. Исключения – только когда вы очень хорошо представляете себе, что делаете, зачем делаете и почему нельзя сделать иначе.

И напоследок, сделаем одну очень нехорошую штуку.

R00(config)# ip route 3.1.1.0 255.255.255.0 10.0.0.3
R00(config)#ip route 10.0.0.3 255.255.255.255 3.1.1.1

Первый маршрут в порядке, сто раз протестирован. А вот второй странный – он ведет через первый. А первый теперь ссылается на второй, и у нас бесконечная рекурсия. Вот что произошло:

IP-ST(default): updating same distance on 3.1.1.0/24
IP-ST(default):  3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state
IP-ST(default):  3.1.1.0/24 [1], 10.0.0.3 Path = 2 3 7
RT: updating static 3.1.1.0/24 (0x0):
    via 10.0.0.3
RT: add 3.1.1.0/24 via 10.0.0.3, static metric [1/0], add succeed, active state
IP-ST(default): updating same distance on 10.0.0.3/32
IP-ST(default):  10.0.0.3/32 [1], 3.1.1.1 Path = 8, no change, not active state
IP-ST(default):  10.0.0.3/32 [1], 3.1.1.1 Path = 2 3 7
RT: updating static 10.0.0.3/32 (0x0):
    via 3.1.1.1
RT: add 10.0.0.3/32 via 3.1.1.1, static metric [1/0], add succeed, active state

Добавилось успешно. Но затем в дебагах высветилось:

RT: recursion error routing 3.1.1.1 - probable routing loop
RT: recursion error routing 10.0.0.3 - probable routing loop

И появилась запись в лог с severity 3:

%IPRT-3-RIB_LOOP: Resolution loop formed by routes in RIB

R00#show ip cef 10.0.0.3 detail
10.0.0.3/32, epoch 0
  Adj source: IP adj out of GigabitEthernet0/1, addr 10.0.0.3 359503C0
   Dependent covered prefix type adjfib cover 10.0.0.0/24
  1 RR source [no flags]
  recursive via 3.1.1.1, unresolved
  recursive-looped
R00#show ip cef 3.1.1.0 detail
3.1.1.0/24, epoch 0, flags cover dependents
  Covered dependent prefixes: 1
    notify cover updated: 1
  recursive via 10.0.0.3, unresolved
  recursive-looped

Однако, RIB никакого криминала не видит:

Routing entry for 3.1.1.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.0.3
      Route metric is 0, traffic share count is 1
R00#show ip route 10. 0.0.3
Routing entry for 10.0.0.3/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 3.1.1.1
      Route metric is 0, traffic share count is 1

Вывод – никогда так не делайте.

Почему статический маршрут может не попасть в таблицу маршрутизации?

Любой сетевик должен сходу дать одно из объяснений, касающееся любого источника маршрутов в IOS: существует другой маршрут на тот же самый префикс, но с меньшим AD (все помнят Administrative Distance?). Маршрут, источник которого – “connected”, всегда имеет AD=0, и ни один другой источник маршрутов не может привнести ничего ниже, чем «1», даже статический маршрут с явным указанием интерфейса. Пример connected:

R00# show ip route
C        10.0.0.0/24 is directly connected, GigabitEthernet0/1

Т.е. пока интерфейс Gi0/1 находится в состоянии up и имеет адрес из подсети 10.0.0.0/24, ни один статический маршрут на этот префикс в таблице маршрутизации не появится.

Еще есть вариант «разные источники маршрутов добавляют маршруты на один и тот же префикс с одинаковым AD». Поведение IOS в данном случае не документировано, общая рекомендация – «никогда так делайте».

Но посмотрим другие, менее очевидные примеры. Например, статические маршруты можно создать со словом «permanent», которое переводится как «постоянный», и тогда они будут всегда висеть в таблице маршрутизации. Правильно? Нет.

Добавляем его и смотрим:

R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent
R00#show ip cef 3.1.1.0
3.1.1.0/24
  nexthop 10.0.0.3 GigabitEthernet0/1

Кладем Gi0/1, и видим:

R00#show ip cef 3.1.1.0
3.1.1.0/24
  unresolved via 10.0.0.3

В RIB он есть, и другие протоколы маршрутизации могут его использовать:

R00#show ip route 3.1.1.0
Routing entry for 3.1.1.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10. 0.0.3, permanent
      Route metric is 0, traffic share count is 1

А теперь, не поднимая Gi0/1:

R00(config)#no ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent
R00(config)#ip route 3.1.1.0 255.255.255.0 10.0.0.3 permanent

Просто пересоздали его, ничего не меняя. И вот что произошло:

IP-ST(default): updating same distance on 3.1.1.0/24
IP-ST(default):  3.1.1.0/24 [1], 10.0.0.3 Path = 8, no change, not active state
IP-ST(default): cannot delete, PERMANENT
R00#show ip route 3.1.1.0
% Network not in table
R00#show ip cef 3.1.1.0
0.0.0.0/0
  no route

Постоянный, говорите? Нет. Есть один маленький нюанс: чтобы перманентный маршрут навеки вписался в таблицу маршрутизации, нужно, чтобы он хотя бы на долю секунды резолвился. Хотя какое еще «навеки»? Когда он остался висеть в воздухе без резолвящегося интерфейса, достаточно сказать «clear ip route *» или тем более «reload», чтобы он исчез из RIB.

Но продолжим. Сделаем вот так:

R00(config)#ip route 3.1.1.0 255.255.255.0 Gi0/1 10.0.0.3
R00(config)#ip route 3.1.1.10 255.255.255.255 3.1.1.1

Вроде нормальные маршруты. Что произойдет? Со вторым – ровным счетом ничего.

IP-ST(default):  3.1.1.10/32 [1], 3.1.1.1 Path = 8, no change, not active state
IP-ST(default):  3.1.1.10/32 [1], 3.1.1.1 Path = 2 3 6 8, no change, not active state

Суть вот в чем. Допустим, есть маршрут на 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.

А теперь финт ушами.

R00(config)#no ip route 3.1.1.10 255.255.255.255 3.1.1.1
R00(config)#ip route 3.1.1.10 255.255.255.255 Gi0/1 3. 1.1.1
IP-ST(default): updating same distance on 3.1.1.10/32
IP-ST(default):  3.1.1.10/32 [1], GigabitEthernet0/1 Path = 1
RT: updating static 3.1.1.10/32 (0x0):
    via 3.1.1.1 Gi0/1
RT: network 3.0.0.0 is now variably masked
RT: add 3.1.1.10/32 via 3.1.1.1, static metric [1/0], add succeed, active state
IP ARP: creating incomplete entry for IP address: 3.1.1.1 interface GigabitEthernet0/1
IP ARP: sent req src 10.0.0.1 30e4.db16.7791,
                 dst 3.1.1.1 0000.0000.0000 GigabitEthernet0/1
R00#show ip cef 3.1.1.10
3.1.1.10/32
  nexthop 3.1.1.1 GigabitEthernet0/1

И вот это подводит нас к еще одному важному моменту. Указание интерфейса в статическом маршруте позволяет обойти многие проверки, так как статическому маршруту больше не требуется выполнять рекурсивные запросы к 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 секунд можно с помощью команды:

ip route static adjust-time 10

Настройка статических IP-маршрутов

Эта функция позволяет создавать статические маршруты (и нулевые маршруты), добавляя такие маршруты непосредственно в таблицу маршрутов. В этом разделе описывается, как добавить статические и нулевые маршруты в таблицу IP-маршрутов.

Типы статических маршрутов

Можно настроить следующие типы статических IP-маршрутов:


	ПРИМЕЧАНИЕ. На одном коммутаторе маршрутизации можно создать один нулевой маршрут к заданному месту назначения. Несколько нулевых маршрутов к одному и тому же месту назначения не поддерживаются.

Другие источники маршрутов в таблице маршрутизации

Таблица IP-маршрутов также может получать маршруты из следующих источников:

Сети с прямым подключением: для каждого IP-интерфейса создается один маршрут. При добавлении IP-интерфейса коммутатор маршрутизации автоматически создает маршрут для сети, в которой находится этот интерфейс.
RIP: если RIP включен, коммутатор маршрутизации может узнать о маршрутах из объявлений, которые другие маршрутизаторы RIP отправляют на коммутатор маршрутизации. Если маршрут RIP имеет меньшее административное расстояние, чем любые другие маршруты от разных источников к тому же месту назначения, коммутатор маршрутизации помещает маршрут в таблицу IP-маршрутов. См. Административное расстояние.
Маршрут по умолчанию: это специальный статический маршрут, который используется коммутатором маршрутизации, если другие маршруты к месту назначения недоступны. См. Настройка маршрута по умолчанию.

Параметры статического IP-маршрута

При настройке статического IP-маршрута необходимо указать следующие параметры:

IP-адрес и маска сети для сети или узла назначения маршрута.
Путь маршрута, который может быть одним из следующих:

Коммутатор маршрутизации также применяет значения по умолчанию для административного расстояния маршрута (Административное расстояние). В случае статических маршрутов это значение, которое коммутатор маршрутизации использует для сравнения статического маршрута с маршрутами из других источников маршрутов к тому же месту назначения перед помещением маршрута в таблицу IP-маршрутов.

Административное расстояние по умолчанию для статических IP-маршрутов равно 1, но может быть настроено на любое значение от 1 до 255.

Значения фиксированного административного расстояния гарантируют, что коммутатор маршрутизации всегда предпочитает статические IP-маршруты маршрутам от других источников к одному и тому же место назначения.

Состояния статических маршрутов следуют состояниям VLAN

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

Эта функция позволяет коммутатору маршрутизации адаптироваться к изменениям топологии сети.

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

Например, следующая команда настраивает статический маршрут к 207.95.7.0 (с сетевой маской 255.255.255.0), используя 207.95.6.157 в качестве IP-адреса маршрутизатора следующего перехода:

HP Switch(config)# ip route 207.95.7.0/24 207.95.6.15

Статический IP-маршрут указывает адрес назначения маршрута и IP-адрес маршрутизатора следующего перехода или интерфейс коммутатора маршрутизации, через который коммутатор маршрутизации может достичь пункта назначения. (Маршрут добавляется в таблицу IP-маршрутов коммутатора маршрутизации.)

В приведенном выше примере коммутатор маршрутизации «A» знает, что 207.95.6.157 доступен через порт A2, и предполагает, что локальные интерфейсы в этой подсети находятся на одном и том же порту. Коммутатор маршрутизации «A» делает вывод, что IP-интерфейс 207.95.7.188 также находится на порту A2. Программное обеспечение автоматически удаляет статический маршрут из таблицы маршрутов, если VLAN следующего перехода, используемая этим маршрутом, становится недоступной. Когда VLAN снова становится доступной, программное обеспечение автоматически повторно добавляет маршрут в таблицу маршрутов.

Настройка статического IP-маршрута

Синтаксис:

[no] ip route < IP-адрес назначения >/< длина маски > < IP-адрес следующего перехода |vlan 90 90 1-id < 7 90 >|reject|blackhole> [метрика < метрика >] [расстояние <1-255>] [значение тега < tagval >]
Позволяет добавлять и удалять записи таблицы статической маршрутизации. Запись маршрута идентифицируется пунктом назначения (IP-адрес/длина маски) и парой следующего перехода. Следующим переходом может быть IP-адрес шлюза, VLAN или ключевое слово «отклонить» или «черная дыра».
IP-адрес шлюза не обязательно должен быть доступен напрямую в одной из локальных подсетей. Если адрес шлюза недоступен напрямую, маршрут добавляется в таблицу маршрутизации, как только будет получен маршрут к адресу шлюза.
Форма команды no удаляет указанный маршрут для указанной пары следующего перехода назначения.

В следующем примере настраиваются два статических маршрута для доставки трафика и определяются два других нулевых маршрута, для которых трафик следует отбрасывать, а не пересылать.

Настройка статических маршрутов

HP Switch(config)# ip route 10.10.40.0/24 10.10.10.1

HP Switch(config)# ip route 10.10.50.128/27 10.10.10.1
HP Switch(config)# ip route 10.10.20.177/32 отклонить

HP Switch(config)# ip route 10. 10.30.0/24 blackhole

	Настраивает статические маршруты к двум различным сетевым адресатам, используя один и тот же IP-адрес маршрутизатора следующего перехода.
	Настраивает нулевой маршрут, чтобы отбрасывать трафик для устройства по адресу 10.50.10.177 и возвращать отправителю уведомление ICMP.
	Настраивает нулевой маршрут для отбрасывания трафика для сети 10.50.10.0 без уведомления отправителя ICMP.

`Просмотр информации о статическом маршруте`

Команда show ip route отображает текущую конфигурацию статического маршрута на коммутаторе маршрутизации. Отображение текущих настроенных статических маршрутов показывает конфигурацию, полученную из статических маршрутов, настроенных в предыдущих примерах.

Отображение текущих настроенных статических маршрутов

`Настройка маршрута по умолчанию`

Вы также можете назначить маршрут по умолчанию и ввести его в таблицу маршрутизации. Маршрут по умолчанию используется для всего трафика, сеть назначения которого недоступна через какую-либо другую запись в таблице IP-маршрутизации. Например, если 208.45.228.35 — это IP-адрес маршрутизатора вашего интернет-провайдера, весь нелокальный трафик можно направить на интернет-провайдера, введя следующую команду:

HP Switch(config)# ip route 0.0.0.0/0 208.45.228.35

`Статическая маршрутизация`

Вы могли заметить, что протоколы динамической маршрутизации получают всю славу. Поскольку мне нравится рутировать (маршрутизировать?) аутсайдеров, давайте поговорим о статических маршрутах!

Как вы помните, у маршрутизатора есть три метода изучения маршрута. Маршрут может отображаться в таблице маршрутизации, если он:

Подключен – напрямую подключен

Динамический — изучен через протокол маршрутизации

Статический — настроен человеком

Статический маршрут — это маршрут, который вручную вставляется в таблицу маршрутизации. Статические маршруты отображаются в таблице маршрутизации как S-маршруты и часто используются:

Когда есть только один путь к пункту назначения

В качестве резервного маршрута к пункту назначения

Статические маршруты создается в режиме глобальной конфигурации и требует префикса назначения и способа туда добраться. Например, предположим, что интерфейс Serial 1/1 нашего маршрутизатора с IP-адресом 192.168.1.5/30, имеет двухточечное соединение с Serial 2/2 другого маршрутизатора с IP-адресом 192.168.1.6/30. Нам сказали, что мы можем получить доступ к подсети 10.2.3.0/24 через соседний маршрутизатор. Чтобы настроить статический маршрут, введите следующую команду:

Router(config)#ip route 10.2.3.0 255.255.255.0 192.168.1.6

Обратите внимание, что адрес следующего перехода — это адрес нашего соседа (не наш). В случае последовательного канала «точка-точка» у вас также есть возможность использовать исходящий интерфейс, например:

Router(config)#ip route 10. 2.3.0 255.255.255.0 последовательный 1/1

Обратите внимание, что когда указана опция интерфейса, это наш интерфейс (а не соседний). Параметр интерфейса работает только с соединениями «точка-точка», такими как последовательные соединения, использующие HDLC или PPP. Параметр интерфейса , а не будет работать с многоточечными интерфейсами, такими как локальные сети, Frame Relay или ATM. Это связано с тем, что для многоточечных топологий требуется адрес уровня 2 (например, MAC, DLCI или VPI/VCI), и для решения этой проблемы необходимо иметь IP-адрес следующего перехода.

Если вы настроите статический маршрут с использованием исходящего интерфейса на канале с множественным доступом (таком как Ethernet или Frame Relay), вы не получите синтаксическую ошибку, но маршрутизация завершится ошибкой. Фактически, «отладка ip-пакета» покажет «сбой инкапсуляции» для пакетов, следующих по этому маршруту, что указывает на то, что маршрутизатор не смог создать заголовок кадра из-за отсутствия адреса назначения уровня 2. Вы должны использовать опцию «следующий переход» при настройке статического маршрута на носителе с множественным доступом.

Обратите внимание, что хотя они появляются в текущей конфигурации сразу после создания, по умолчанию статический маршрут будет вставлен в таблицу маршрутизации только в том случае, если маршрутизатор считает, что следующий переход действительно достижим. Другими словами, чтобы статический маршрут появился в таблице маршрутизации, интерфейс, используемый для достижения следующего перехода, должен быть «вверх/вверх».

Вопреки тому, что вы могли прочитать (в том числе в некоторой документации Cisco), административное расстояние (AD) по умолчанию для статического маршрута равно единице, независимо от того, используется ли следующий переход или исходящий интерфейс. По умолчанию единственное, что лучше статического маршрута, — это подключенный маршрут с нулевым AD.

Однако вы можете изменить AD статического маршрута. Предположим, что ваш маршрутизатор изучает маршрут к 10. 2.3.0/24 через OSPF, который имеет AD по умолчанию 110. Теперь предположим, что вы настроили статический маршрут к 10.2.3.0/24 с AD 250, например:

Router(config)#ip route 10.2.3.0 255.255.255.0 192.168.1.6 250

Если ссылка двухточечная, вы также можете сделать это следующим образом:

Router(config)#ip route 10.2.3.0 255.255.255.0 serial 1/1 250

Обратите внимание, что значение, следующее за следующим переходом или исходящим интерфейсом, является AD для статического маршрута. Так как при выборе маршрута выигрывает младшая AD, пока маршрут изучается OSPF, в таблице маршрутизации появится именно OSPF-маршрут (110 бит 250). Если маршрут OSPF недоступен, в таблице маршрутизации появится статический маршрут. Этот тип статического маршрута называется «плавающим» статическим маршрутом и иногда используется для резервных ссылок.

Вы также можете указать «метку» при настройке статического маршрута.

imacrosoft.ru