Заметки к CCNP Route: редистрибуция IGP часть 2

Пришло время поговорит на тему редистрибуции маршрутной информации, а именно о тех случаях, когда требуется отказоустойчивость и в схему добавляются дополнительные маршрутизаторы, чтобы исключить единую точку отказа. Проблема заключается в том, что при определенных условиях маршруты, редистрибуции которых уже произведена могут “перетекать” обратно в оригинальный протокол маршрутизации. Cisco крайне отрицательно относится и всячески не рекомендует двухстороннюю редистрибуцию. В этом случае взамен следует создавать статические маршруты или маршруты по умолчанию.

Предотвращение петель с помощью увеличения метрик

Рассмотрим следующую схему:

Совершенно очевидно, что если метрики маршрутов перетекут обратно из OSPF в RIP, то hop count будет больше 4, а значит установив метрику в 5 мы сможем убедиться в том, что и RIP получит информацию о новых маршрутах и трафик до соседа не будет отправлен через OSPF AS. Так же дела обстоят и с OSPF. Допустим максимальная метрика в этой автономной системе составляет 200. Метрика в 201 при редистрибуции позволяет одновременно избежать петель и получать информацию о новых сетях в RIP AS. Стоит так же отметить, что OSPF предпочитает внутренние метрики над E1, а E1 над E2. О манипуляции метриками с помощью route map вы можете почитать тут.

Административная дистанция

Первым делом маршрутизатор исследует даже не метрику маршрута, а его административную дистанцию (AD). AD – это мера степени доверия к тому или иному источнику. Так маршруты с ужасной метрикой, но полученные от OSPF попадут в таблицу маршрутизации, не смотря на то, что есть маршрут от RIP с hop count = 1. AD – локальная величина и не анонсируется другим маршрутизаторам. AD подвергается тюнингу в том случае если вам это надо. В конфигурации процесса маршрутизации вы можете изменить ее командой distance.

Например у EIGRP внутренние маршруты обладают более низкой AD (90), чем внешние (170), что является своеобразным механизмом предотвращения петель. EIGRP вообще в этом плане классный парень и решает большинство возникающих с петлями проблем в настройке по умолчанию. Большинство статей в Интернетах, которые рассказывают о петлях в маршрутизации почему-то забывают, что внешние маршруты для EIGRP имеют огромную AD по сравнению с RIP и OSPF, что в состоянии помешать им попасть в таблицу маршрутизации.

Предотвращение образования петель с помощью route map

Как вы помните из прошлой части одной из особенностью route map была возможность тэгировать интересующие нас маршруты.

Далее на основе этих тэгов можно создавать запрещающие правила, не дающие маршрутом поступать обратно в ту область, из которой они были направлены.

Соберем стенд по схеме:

и посмотрим как обстоят дела на R3:

R3#sh ip route
--- опущено ---
     172.17.0.0/24 is subnetted, 2 subnets
O       172.17.1.0 [110/20] via 172.17.2.1, 00:12:52, FastEthernet0/0
C       172.17.2.0 is directly connected, FastEthernet0/0
     172.16.0.0/24 is subnetted, 2 subnets
O E2    172.16.1.0 [110/20] via 172.17.2.1, 00:12:52, FastEthernet0/0
C       172.16.2.0 is directly connected, FastEthernet0/1
O E2 192.168.4.0/24 [110/20] via 172.17.2.1, 00:12:52, FastEthernet0/0
     10.0.0.0/24 is subnetted, 4 subnets
O       10.0.2.0 [110/11] via 172.17.2.1, 00:12:52, FastEthernet0/0
O       10.0.3.0 [110/11] via 172.17.2.1, 00:12:53, FastEthernet0/0
O       10.0.1.0 [110/11] via 172.17.2.1, 00:12:53, FastEthernet0/0
O       10.0.4.0 [110/11] via 172.17.2.1, 00:12:53, FastEthernet0/0
O E2 192.168.1.0/24 [110/20] via 172.17.2.1, 00:12:53, FastEthernet0/0
O E2 192.168.2.0/24 [110/20] via 172.17.2.1, 00:12:54, FastEthernet0/0
O E2 192.168.3.0/24 [110/20] via 172.17.2.1, 00:12:54, FastEthernet0/0

Вы только посмотрите какое безобразие творится. R3 свято верит в то, что лучший путь для достижения 192.168.x.0/24 сетей за R4 – это R1>;R2>;R4:

R3#traceroute 192.168.1.1

Type escape sequence to abort.
Tracing the route to 192.168.1.1

  1 172.17.2.1 48 msec 16 msec 12 msec
  2 172.17.1.2 36 msec 20 msec 40 msec
  3 172.16.1.1 28 msec *  68 msec

Ну не месиво ли? :) Постараемся это исправить, добавив к маршрутам полученным из RIP метку “10”:

Rx(config)#route-map TAG-RIP
Rx(config-route-map)#set tag 10
Rx(config-route-map)#router ospf 1
Rx(config-router)#redistribute rip subnets route-map TAG-RIP

R3#sh ip route 192.168.1.0
Routing entry for 192.168.1.0/24
  Known via "ospf 1", distance 110, metric 20
  Tag 10, type extern 2, forward metric 10
  Last update from 172.17.1.2 on FastEthernet0/0, 00:00:24 ago
  Routing Descriptor Blocks:
  * 172.17.1.2, from 172.17.1.2, 00:00:24 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1
      Route tag 10 

И на основе этой метки запретим помещать маршруты в таблицу маршрутизации OSPF:

Rx(config)#route-map DENY-TAG deny 10
Rx(config-route-map)# match tag 10
Rx(config-route-map)#router ospf 1
Rx(config-router)#distribute-list route-map DENY-TAG in

В итоге R3 занятным путем больше не ходит:

R3#sh ip route
--- опущено ---
     172.17.0.0/24 is subnetted, 2 subnets
O       172.17.1.0 [110/20] via 172.17.2.1, 00:00:50, FastEthernet0/0
C       172.17.2.0 is directly connected, FastEthernet0/0
     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.1.0 [120/1] via 172.16.2.1, 00:00:15, FastEthernet0/1
C       172.16.2.0 is directly connected, FastEthernet0/1
R    192.168.4.0/24 [120/1] via 172.16.2.1, 00:00:15, FastEthernet0/1
     10.0.0.0/24 is subnetted, 4 subnets
O       10.0.2.0 [110/11] via 172.17.2.1, 00:00:50, FastEthernet0/0
O       10.0.3.0 [110/11] via 172.17.2.1, 00:00:51, FastEthernet0/0
O       10.0.1.0 [110/11] via 172.17.2.1, 00:00:51, FastEthernet0/0
O       10.0.4.0 [110/11] via 172.17.2.1, 00:00:51, FastEthernet0/0
R    192.168.1.0/24 [120/1] via 172.16.2.1, 00:00:17, FastEthernet0/1
R    192.168.2.0/24 [120/1] via 172.16.2.1, 00:00:18, FastEthernet0/1
R    192.168.3.0/24 [120/1] via 172.16.2.1, 00:00:18, FastEthernet0/1