воскресенье, 24 сентября 2017 г.

CCNP Route "Full Scale" Лаба: Боримся с петлями


В этом посте героически создаем петли и боремся с ними. К сожалению, пост получился длинноватым. Не уверен, что хоть кто-то пройдет весь путь до конца, но для меня лично законспектировать этот материал очень важно. Всегда не уверенно себя чувствовал в случаях, когда на сети твориться бардак при редистрибуции. В этом посте опишу несколько случаев кривой редистрибуции. Посмотрим как диагностировать такие проблемы и как устранять последствия.
Все посты про CCNP Route лабу.

Сегодня будет действовать по плану:
  • Простая редистрибуция
  • Провоцируем петли 
  • Делаем хорошо
В следующем посте рассмотрим
  • Редистрибуция с фильтрами
  • Фильтруем маршруты где это возможно
И это покроет всего два пунка из основного плана:
  • Routing loops
  • Advanced redistribution with filtering 

Simple redistribution

На самом деле я уже её настраивал, но потом решил убрать. Тонул в выводе sh ip route. Добавляем для каждого протокола нужные строки.

router eigrp 90
 redistribute rip metric 1000 200 255 1 1500

router rip
 redistribute eigrp 90 metric 5

router ospf 110
 redistribute eigrp 90 subnets metric-type 1

Таким образом, получаем примерно такую схему. К слову, все офсет листы и прочие манипуляции метриками я убрал для чистоты результата.



Для начала я выключил два верхних маршрутизатора. Посмотрим как обстоят дела с единственной точкой редистрибуции, а потом посмотрим, что произойдет после добавления второй.



Со стороны роутера R5.

OSPF просматривается полностью.

  

Первый вывод - адреса управления. Понятно, что 10.0.10.1 нет, он пока не включен. Второй вывод - все анонсируемые сети. Третий - все линковые адреса.

С  EIGRP тоже все должно быть в порядке.


Первая пачка адресов представляют из себя адреса в сети управления. Первого и второго адресов нет по причине выключенных маршрутизаторов. А вот 10.0.30.6 нет, потому что Е6 находится в режиме stub receive-only. Далее идут сети, которые анонсируют E3, E4, E5 и Е7. Далее все линковые подсети. Тут можно заметить, что сеть 10.30.13.0/30 есть, даже не смотря на то, что линк по идее должен лежать. Это особенность IOU, здесь линк все равно находится в up/up... Ну что ж поделать, везде допущения. Я выделил те сети, которые по идее приходить не должны.

Ну и про свой родной RIP R5 знает во всех подробностях. Снова подсветил те сети, которые приходят из-за особенностей IOU.


Остальные подопытные, а именно E7 и O3 тоже на данный момент неплохо ориентируются в сети.

Провоцируем петли

А теперь включим дополнительную точку редистрибуции из RIP в EIGRP B4-E1-R1.

 

Итак, нужно немного времени чтобы RIP сошелся, после чего можно понаблюдать за изменившейся ситуацией, со стороны все того же R5, скажем.

OSPF выглядит следующим образом. К слову, вместо include нужно использовать команду section. Теперь у нас потенциально по нескольку строк на маршрут и простой include их просто отрежет.


Ситуация в общем-то не сильно поменялась... что странно. Давайте посмотрим как там дела в EIGRP.


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

Давайте разбираться, почему в OSPF такая странная ситуация - весь трафик идет через нижний маршрутизатор (E3-R2), как будто верхний маршрутизатор (B4-E1-R1) и не редистрибуцирует вовсе. Идем не него и посмотрим что он знает про первую OSPF подсеть 10.0.10.2/32.


Вот это поворот! B4-E1-R1 знает про эту подсеть из RIPа. Т.е. E3-R2 взял машруты из EIGRP и засунул в RIP, а B4-E1-R1 получив их через RIP посчитал более приоритетными. Ну и как порядочный роутер, он ещё взял и проредистрибуцировал их в EIGRP домен ещё разок.


На первом шаге к E3-R2 приходит информацию от его EIGRP соседей об OSPF сетях, в том числи и о 10.0.10.2. Он редистрибуцирует эти подсети на втором шаге в RIP домен. R5, скажем, получая такой анонс передает его своим соседям. На третьей стрелке он рассказывает о 10.0.10.2 своему соседу B4-E1-R1. А тот эти маршруты редистрибуцирует назад в EIGRP.

Ниже видно, что EIGRP процесс на B4-E1-R1 знает про 10.0.10.2.

Ух...ё... Я научился выделять нужные куски...
А знает он о том, что сеть эту он узнал от RIP соседа 10.20.15.2 и была эта подсеть редистрибуцирована. Внешним протоколом для 10.0.10.2 является RIP. Вторая информация про эту сеть пришла от E4-O2 c адресом 10.30.14.2. Тот получил эту подсеть из OSPF.

Наскоро сделанная анимация показывает процесс. Сначала анонс приходит со стороны OSPF, E4-O2 добавляет его в EIGRP и отправляет двум своим соседям. Нижний маршрутизатор E3-R2 переносит знания в RIP, после чего B4-E1-R1 снова добавляет OSPF сети в EIGRP и рассылает анонс двум своим соседям. И финальная пунктирная линия - апдейт, которого нет...


В выводе выше видно, что к B4-E1-R1 не приходит никакой информациии о 10.0.10.2 от E3-R2. Почему так? Split-horizon. В EIGRP оно звучит так: If the currently best route for a prefix lists a particular outgoing interface, Split Horizon causes EIGRP to not include that prefix in the Update sent out that same interface. То есть, сообщения Update для префиксов не отсылаются в интерфейсы, если эти интерфейсы являются исходящими для этих префиксов. И на E3-R2 это прекрасно видно.



Хотя, если не интерфейсе в сторону B4-E1-R1 выключить это правило командой no ip split-horizon eigrp 90, то ничего не поменяется. Тут как-то мне непонятно...

В любом случае, мы имеем петлю маршрутизации. В выводе выше можно заметить, что для сети 10.0.10.2 трафик будет балансироваться. Часть трафика пойдет по верхнему пути через 10.30.34.2 и дойдет до адресата, а часть уйдет на 10.30.13.1. У того лучший маршрут на 10.0.10.2 приходит со стороны RIP. А у маршрутизаторов в RIP сети лучший маршрут указывает на E3-R2. И понеслась... В итоге трассировка будет выглядит идеально.



Получилось так из-за AD. E3-R2 редистрибуцирует сети в RIP, роутеры в нем анонсируют эти сети на B4-E1-R1. У того есть выбор - маршруты из EIGRP домена с AD 170 или сети из RIP с AD 120. Выбор очевиден - в таблицу маршрутизации добавляются маршруты из RIP. Не стоит забывать, что B4-E1-R1 является точкой редиситрибуции. Ну и он честно добавляет эти маршруты назад в EIGRP. Эта информация разлетается по EIGRP сети. Так получилось, что метрика на E3-R2 оказалось одинаковой для двух анонсов пришедших от B4-E1-R1 и от E4-O2. Поэтому он выполняет балансировку. Стоит отметить, что метрика от B4-E1-R1 могла оказаться и меньше. А вот E4-O2 повезло больше, он не добавит "плохой" редистрибуцированный маршрут на B4-E1-R1, потому что у него есть прямой выход в OSPF, а у того AD 110, что меньше чему у External EIGRP (170).

Все это я попытался изобразить на картинке ниже.
Тут у нас два моральных выбора.
B4-E1-R1 - RIP AD120 vs ExtEIGRP AD 170
E4-O2 - OSPF AD110 vs ExtEIGRP AD170
а вот E3-R2 легче, он на AD не полагается, а просто сравнивает метрики у маршрутов пришедших от предыдущих двух.
Из всего этого можно сделать вывод, что все плохо между RIP и EIGRP, а вот на стыке EIGRP-OSPF проблем вроде возникнуть не должно. Именно поэтому можно включить B5-E2-O1 - второй маршрутизатора на стыке с OSPF. По идее, ситуация ухудшится не должна.

Ниже видно, что для префикса 10.0.10.1 ситуация даже лучше. R5, например, получил анонс об этой сети от обоих маршрутизаторов R1 и R2. Почему так? Видимо сейчас анонсы из EIGRP были редистрибуцированы в RIP практически одновременно на двух точках. В итоге, из RIP ничего подозрительного не прилетело и диллемы AD не было. Если пару тройку раз ребутнуть топологию, то каждый раз сходится все будет по-разному.


В общем, с этим надо что-то делать. Курс CCNP Route предлагает нам три подхода:
  1. Тюнить AD (per protocol/per neighbor/route)
  2. Фильтровать префиксы
  3. Фильтровать на основе тегов
Применим каждый из способов поочередно.

Тюним AD per protocol

Проблема в том, что AD у RIP меньше, чем AD у External EIGRP. 120 против 170. Решением проблемы может стать увеличение AD у RIP до 171 и выше. Второй вариант - занижать внешнюю AD у EIGRP до 119 и ниже. Но мне это не очень нравится. Выберем первый вариант.

К слову,
AD в RIP один на все маршруты,
в EIGRP - разный на внешние и внутренние маршруты,
в OSPF - один на всех, но можно настроить разный для внешних, inter- и intra-area маршрутов.

Итак, завышаем AD у RIP на B4-E1-R1 и E3-R2.

E3-R2(config)#router rip
E3-R2(config-router)#distance 200


B4-E1-R1(config)#router rip
B4-E1-R1(config-router)#distance 200 

Далее, нужно немножко подождать. После чего убеждаемся, что 10.0.10.2 теперь доступен не через RIP сеть, а по-нормальному - через EIGRP.


Как результат, в RIP домене трафик теперь нормально распределяется по двум пограничным роутерам.


Возвращаем все назад для следующего теста.

Тюним AD per neighbor / per route

В таком подходе добавляется некая гибкость. Мы можем указать какую AD ставить на маршруты пришедшие от определенного соседа. Можем пойти дальше и указать AD на определенные маршруты, которые пришли от соседа. Пойдем вторым путем.

Создаем ACL, которым выбираем только 10.0.10.2/32

B4-E1-R1(config)#ip access-list standard MATCH_O2_MGMT
B4-E1-R1(config-std-nacl)#permit 10.0.10.2 0.0.0.0

В RIP, как мы помним, нет соседства. Поэтому в команде distance мы указываем источник пришедшей информации. В нашем случае, B4-E1-R1 получает ложную информацию от R3 (10.20.13.2), R4 (10.20.14.2) и R5 (10.20.15.2). Именно их адреса и указываем.

B4-E1-R1(config)#router rip
B4-E1-R1(config-router)#distance 200 10.20.15.2 0.0.0.0 MATCH_O2_MGMT
B4-E1-R1(config-router)#distance 200 10.20.14.2 0.0.0.0 MATCH_O2_MGMT
B4-E1-R1(config-router)#distance 200 10.20.13.2 0.0.0.0 MATCH_O2_MGMT


Итак, ситуация на R5 должна поменяться. Трафик должен балансироваться для 10.0.10.2/32. Так оно и есть.


Фильтруем префиксы

Смысл довольно прост, но практически на любой сети выливается в довольно внушительный конфиг. Возьмем для примера все ту же парочку B4-E1-R1 и E3-R2. Они оба занимаются переносом маршрутов (устал писать слово редистрибуция...) из одной сети в другую. Возьмем уже знакомый префикс 10.0.10.2/32. Оба маршрутизатора этот префикс добавляют в RIP из EIGRP. Но вот B4-E1-R1 может в определенных обстоятельствах добавить его назад в EIGRP, что вызывает петлю. Для того чтобы избежать это, на обоих роутерах мы можем написать по route-map, который запрещает определенные префиксы редистрибуцировать обратно.

Обкатаем идею на 10.0.10.2/32. Повторюсь, идея в том, чтобы разрешить распространение этого префикса в направлении от EIGRP в RIP и запретить обратный путь. Замечу, что это никак не решит проблему в RIP домене. То есть B4-E1-R1 так и не будет распространять маршруты в RIP домен из EIGRP. Как мы уже рассмотрели, причиной тому - AD. Однако внутри EIGRP проблема решится, трафик не будет "колцеваться".

Как вы, возможно, помните, на E3-R2 существовал маршрут, который вел на B4-E1-R1, который далее вел в RIP. Можете посмотреть его ниже, он в составе трех маршрутов.


Помним, что путь этот заведомо ложный. Запретим 10.30.13.1 (B4-E1-R1) так делать. Конечно, мы должны прописать сюда все подсети, которые выходят из EIGRP в RIP, но мы ограничимся только 10.0.10.2/32.

ACL у нас уже есть. Далее пишем простой router-map, запрещаем все, что входит в ACL  MATCH_O2_MGMT и разрешаем все остальное. Далее добавляем ключ router-map в redistribute rip и EIGRP процессе.

ip access-list standard MATCH_O2_MGMT
 permit 10.0.10.2

route-map PREVENT_O2_MGMT deny 10
 match ip address MATCH_O2_MGMT
!
route-map PREVENT_O2_MGMT permit 20
!
router eigrp 90
 redistribute rip metric 1000 200 255 1 1500 route-map PREVENT_O2_MGMT


Ситуация в RIP домене ну никак не изменится, а вот на E3-R2 "кольцевой" маршрут пропал. Да, маршрутизация в RIPе работает крайне не оптимально, но трафик будет ходить.

Фильтруем по тегам

Прошлый способ всем хорош, но в реальной сети (да и в лабе) ну уж очень громоздкий. Нам по хорошему нужно описать в ACL все сети из OSPF и EIGRP, чтобы запретить их "обратный анонс". Вот было бы здорово вешать какие-то указатели при редистрибуции и учитывать их при обратной редистрибуции... Этим и займемся.

Первым делом на каждом роутере на границе EIGRP и RIP нужно написать по два простых route-map. Первым из них мы будем маркировать тегом 300 все те маршруты, которые добавились в RIP.

route-map TAG_EIGRP_TO_RIP permit 10
 set tag 300


Вторым - блокировать распространение таких маршрутов обратно в EIGRP.

route-map BLOCK_RIP_TO_EIGRP deny 10
 match tag 300
!
route-map BLOCK_RIP_TO_EIGRP permit 20


Первый вешаем на RIP процесс, второй на EIGRP.

router eigrp 90
 redistribute rip metric 1000 200 255 1 1500 route-map BLOCK_RIP_TO_EIGRP
!
router rip
 redistribute eigrp 90 metric 5 route-map TAG_EIGRP_TO_RIP


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

Пожалуй, последний конфиг я оставлю в лабе. Добавлю аналогичные строки и на стык EIGRP-OSPF, там тоже не так все гладко было. ) А для того, чтобы оптимизировать маршрутизацию в RIP, изменим AD на 200.

Комментариев нет:

Отправить комментарий