Редистрибуция маршрутов (route redistribution) – особая и горячо любимая экзаменационная тема Cisco. Свойства технологий таковы, что помимо хорошо известных нам петель маршрутизации (routing loops) в пределах одного домена/зоны существуют также петли между несколькими зонами в случае использования OSPF, а также петли между доменами в случае редистрибуции маршрутов из домена с одним протоколом маршрутизации в домен с другим.
Я не нашел определения им ни в одном стандарте, потому буду называть их inter-domain routing loops. До недавнего времени эта особенность была обязательным элементом CCIE Lab Exam, но после обновления CCNP стала частью курса Route.
Суть вопроса в том, что на границе двух доменов, во избежание образования single point of failure, может и должно существовать минимум два роутера. Но тогда маршрут, инжектированный в OSPF домен одним Autonomous System Boarder Router (ASBR), добирается до второго, и он инжектирует его обратно, в EIGRP домен, образуя в лучшем случае «длинный маршрут», а в худшем – петлю маршрутизации.
Существует три способа предотвратить образование такой петли:
Метод заключается в том, чтобы анонсировать в соответствующий домен маршрут с высоким значением метрики, заведомо большим, чем максимальная метрика внутренних маршрутов. Тогда, имея два одинаковых маршрута с разными метриками, маршрутизатор установит в таблицу маршутизации тот, что будет иметь меньшую метрику – по концепции, внутренний.
Недостаток метода заключается в том, что эту самую «заведомо большую метрику» мы выбираем самостоятельно. И если по какой-то причине в домене появится маршрут с большей внутренней метрикой, возникнет та самая петля, от которой мы пытаемся избавиться.
На иллюстрации показан пример использование этого метода, при котором EIGRP маршруты анонсируются в OFPS домен с метрикой 41026560, в то время как маршруты OSPF домена анонсируются в домен EIGRP с метрикой 500.
До тех пор, пока в OSPF домене не будет внутренних метрик выше 500, а в EIGRP домене – выше 41026560, метод будет работать. После – нет. Самое сложное, конечно, заметить этот момент.
Метрику при редистрибуции маршрутов можно устанавливать при помощи default metric:
После этого все маршруты, которые инжектируются в EIGRP из OSPF домена, получают метрику, исходя из значений четырех из пяти заданных параметров:
Bandwidth: 1500
Delay: 10
Reliability: 255
Load: 1
MTU: 1500
Если же мы ходим разрешить редистрибуцию только части маршрутов, нужно использовать route map:
Administrative Distance (AD) – значение, которое определяет, какой источник информации о маршруте имеет приоритет, если маршрут анонсирован из нескольких таких источников. При получении маршрута, перед тем, как сравнивать метрики, роутер смотрит значение AD. Если оно меньше – маршрут будет установлен в таблицу маршрутизации, даже если его метрика больше.
Наша цель – заставить роутер выбирать внутренний маршрут. Помимо ненадежной метрики, это можно делать и манипулируя значениями AD.
Так выглядит таблица AD для разных источников информации о маршрутах:
Обратите внимание на различные AD для внешних и внутренних маршрутов EIGRP. Этот протокол прекрасен! Проектируя его, Cisco уже позаботилась о защите от образования таких петель, и по умолчанию внешние EIGRP маршруты имеют AD равную 170.
В этом случае поведение роутеров в EIGRP домене будет таковым:
Потому инженеры, обслуживающие EIGRP домен, могут и вовсе забыть об этой проблеме – она уже решена за них.
В случае соседства с EIGRP инженерам OSPF домена тоже не о чем беспокоиться – механизм AD защищает и их сеть. Когда маршрут OSPF пройдет сквозь зону EIGRP и вернется ко второму ASBR, он будет инжектирован (фу-ты, слово-то какое, но уж извините – ничего лучше в голову не приходит) в OSPF домен как External EIGRP маршрут с AD равной 170. Об этой же маршруте ASBR знает по OSPF протоколу (он входит в обе зоны одновременно), а AD для OSPF равна 110. Потому в таблицу маршрутизации будет установлен внутренний OSPF маршрут, и петля образовываться не будет.
Если же нужно указать AD императивно (соседство с RIP доменом, например), в OSPF это можно сделать так:
Теперь все внешние маршруты, которые инжектируются в OSPF домен из RIP, будут иметь AD равную 150, что больше, чем внутренняя AD для OSPF. Образование петли предотвращено.
Суть метода сводится к тому, чтобы отфильтровывать на втором ASBR маршруты, которые инжектирует в домен первый ASBR, и не анонсировать их в домен-источник.
Это можно сделать при помощи «тэгирования» маршрутов. При инжектировании в домен, первый ASBR присваивает маршруту метку. Второй ASBR, при инжектировании маршрутов в домен-источник, отфильтровывает «помеченные» маршруты и не анонсирует их.
Конфигурирование решения выглядит так:
Конфигурация ASBR 1:
Конфигурация ASBR 2:
По завершению конфигурации, маршруты с меткой 100, будут отфильтровываться ASBR 2 при редистрибуции в домен OSPF. И снова, inter-domain routing loops побеждены.
Я не нашел определения им ни в одном стандарте, потому буду называть их inter-domain routing loops. До недавнего времени эта особенность была обязательным элементом CCIE Lab Exam, но после обновления CCNP стала частью курса Route.
Суть вопроса в том, что на границе двух доменов, во избежание образования single point of failure, может и должно существовать минимум два роутера. Но тогда маршрут, инжектированный в OSPF домен одним Autonomous System Boarder Router (ASBR), добирается до второго, и он инжектирует его обратно, в EIGRP домен, образуя в лучшем случае «длинный маршрут», а в худшем – петлю маршрутизации.
Существует три способа предотвратить образование такой петли:
- С помощью большей метрики
- С помощью Administrative Distance
- С помощью фильтрации маршрутов
Метод большей метрики
Метод заключается в том, чтобы анонсировать в соответствующий домен маршрут с высоким значением метрики, заведомо большим, чем максимальная метрика внутренних маршрутов. Тогда, имея два одинаковых маршрута с разными метриками, маршрутизатор установит в таблицу маршутизации тот, что будет иметь меньшую метрику – по концепции, внутренний.
Недостаток метода заключается в том, что эту самую «заведомо большую метрику» мы выбираем самостоятельно. И если по какой-то причине в домене появится маршрут с большей внутренней метрикой, возникнет та самая петля, от которой мы пытаемся избавиться.
На иллюстрации показан пример использование этого метода, при котором EIGRP маршруты анонсируются в OFPS домен с метрикой 41026560, в то время как маршруты OSPF домена анонсируются в домен EIGRP с метрикой 500.
До тех пор, пока в OSPF домене не будет внутренних метрик выше 500, а в EIGRP домене – выше 41026560, метод будет работать. После – нет. Самое сложное, конечно, заметить этот момент.
Метрику при редистрибуции маршрутов можно устанавливать при помощи default metric:
router eigrp 1
default-metric 1500 10 255 1 1500
redistribute ospf 1После этого все маршруты, которые инжектируются в EIGRP из OSPF домена, получают метрику, исходя из значений четырех из пяти заданных параметров:
Bandwidth: 1500
Delay: 10
Reliability: 255
Load: 1
MTU: 1500
Если же мы ходим разрешить редистрибуцию только части маршрутов, нужно использовать route map:
ip prefix-list match-ospf seq 5 permit 172.16.102.0/23 ge 25 le 26
ip prefix-list match-ospf seq 10 permit 172.16.106.0/23 ge 29 le 30
!
route-map set-metric permit 10
match ip address prefix-list match-ospf
set metric 100 4444 255 1 1500
!
router eigrp 1
redistribute ospf 1 route-map set-metricМетод Administrative Distance
Administrative Distance (AD) – значение, которое определяет, какой источник информации о маршруте имеет приоритет, если маршрут анонсирован из нескольких таких источников. При получении маршрута, перед тем, как сравнивать метрики, роутер смотрит значение AD. Если оно меньше – маршрут будет установлен в таблицу маршрутизации, даже если его метрика больше.
Наша цель – заставить роутер выбирать внутренний маршрут. Помимо ненадежной метрики, это можно делать и манипулируя значениями AD.
Так выглядит таблица AD для разных источников информации о маршрутах:
| Connected | 0 |
| Static | 1 |
| EIGRP summary route | 5 |
| eBGP | 20 |
| EIGRP (internal) | 90 |
| IGRP | 100 |
| OSPF | 110 |
| IS-IS | 115 |
| RIP | 120 |
| On-Demand Routing (ODR) | 160 |
| EIGRP (external) | 170 |
| iBGP | 200 |
| Unreachable | 255 |
В этом случае поведение роутеров в EIGRP домене будет таковым:
Потому инженеры, обслуживающие EIGRP домен, могут и вовсе забыть об этой проблеме – она уже решена за них.
В случае соседства с EIGRP инженерам OSPF домена тоже не о чем беспокоиться – механизм AD защищает и их сеть. Когда маршрут OSPF пройдет сквозь зону EIGRP и вернется ко второму ASBR, он будет инжектирован (фу-ты, слово-то какое, но уж извините – ничего лучше в голову не приходит) в OSPF домен как External EIGRP маршрут с AD равной 170. Об этой же маршруте ASBR знает по OSPF протоколу (он входит в обе зоны одновременно), а AD для OSPF равна 110. Потому в таблицу маршрутизации будет установлен внутренний OSPF маршрут, и петля образовываться не будет.
Если же нужно указать AD императивно (соседство с RIP доменом, например), в OSPF это можно сделать так:
router ospf 1
distance ospf external 150
redistribute ripТеперь все внешние маршруты, которые инжектируются в OSPF домен из RIP, будут иметь AD равную 150, что больше, чем внутренняя AD для OSPF. Образование петли предотвращено.
Метод фильтрации маршрутов
Суть метода сводится к тому, чтобы отфильтровывать на втором ASBR маршруты, которые инжектирует в домен первый ASBR, и не анонсировать их в домен-источник.
Это можно сделать при помощи «тэгирования» маршрутов. При инжектировании в домен, первый ASBR присваивает маршруту метку. Второй ASBR, при инжектировании маршрутов в домен-источник, отфильтровывает «помеченные» маршруты и не анонсирует их.
Конфигурирование решения выглядит так:
Конфигурация ASBR 1:
route-map set-tag-100 permit 10
set tag 100
!
router ospf 1
redistribute eigrp 1 subnets route-map set-tag-100Конфигурация ASBR 2:
route-map stop-tag-100 deny 10
match tag 100
route-map stop-tag-100 permit 20
!
router eigrp 1
redistribute ospf 2 metric 1000 200 255 1 1500 route-map stop-tag-100
no auto-summaryПо завершению конфигурации, маршруты с меткой 100, будут отфильтровываться ASBR 2 при редистрибуции в домен OSPF. И снова, inter-domain routing loops побеждены.
