В этом посте героически создаем петли и боремся с ними. К сожалению, пост получился длинноватым. Не уверен, что хоть кто-то пройдет весь путь до конца, но для меня лично законспектировать этот материал очень важно. Всегда не уверенно себя чувствовал в случаях, когда на сети твориться бардак при редистрибуции. В этом посте опишу несколько случаев кривой редистрибуции. Посмотрим как диагностировать такие проблемы и как устранять последствия.
Сегодня будет действовать по плану:
- Простая редистрибуция
- Провоцируем петли
- Делаем хорошо
В следующем посте рассмотрим
- Редистрибуция с фильтрами
- Фильтруем маршруты где это возможно
- 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.
Провоцируем петли
А теперь включим дополнительную точку редистрибуции из 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.
 |
| Ух...ё... Я научился выделять нужные куски... |
Наскоро сделанная анимация показывает процесс. Сначала анонс приходит со стороны 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 не было. Если пару тройку раз ребутнуть топологию, то каждый раз сходится все будет по-разному.
- Тюнить AD (per protocol/per neighbor/route)
- Фильтровать префиксы
- Фильтровать на основе тегов
Тюним 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
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
!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е работает крайне не оптимально, но трафик будет ходить.
Первым делом на каждом роутере на границе 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.
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.
Комментариев нет:
Отправить комментарий