Редистрибуция маршрутов (route redistribution) – особая и горячо любимая экзаменационная тема Cisco. Свойства технологий таковы, что помимо хорошо известных нам петель маршрутизации (routing loops) в пределах одного домена/зоны существуют также петли между несколькими зонами в случае использования OSPF, а также петли между доменами в случае редистрибуции маршрутов из домена с одним протоколом маршрутизации в домен с другим.
![](https://habrastorage.org/r/w1560/storage/habraeffect/13/b1/13b129100430e0dfd71597f5001edce5.png)
Я не нашел определения им ни в одном стандарте, потому буду называть их 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.
![](https://habrastorage.org/r/w1560/storage/habraeffect/8e/a0/8ea054030462f3b813b6396f9056fb2d.png)
До тех пор, пока в 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.
![](https://habrastorage.org/r/w1560/storage/habraeffect/a4/a1/a4a11dcb0ce42dd4084cebc24f640a3e.png)
Так выглядит таблица AD для разных источников информации о маршрутах:
Обратите внимание на различные AD для внешних и внутренних маршрутов EIGRP. Этот протокол прекрасен! Проектируя его, Cisco уже позаботилась о защите от образования таких петель, и по умолчанию внешние EIGRP маршруты имеют AD равную 170.
В этом случае поведение роутеров в EIGRP домене будет таковым:
![](https://habrastorage.org/r/w1560/storage/habraeffect/8d/59/8d59b7edd77c6352da9ed29cda498b5e.png)
Потому инженеры, обслуживающие 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, и не анонсировать их в домен-источник.
![](https://habrastorage.org/r/w1560/storage/habraeffect/06/b9/06b9eec74fb4c2de09fa077c80ebbee0.png)
Это можно сделать при помощи «тэгирования» маршрутов. При инжектировании в домен, первый ASBR присваивает маршруту метку. Второй ASBR, при инжектировании маршрутов в домен-источник, отфильтровывает «помеченные» маршруты и не анонсирует их.
Конфигурирование решения выглядит так:
Конфигурация ASBR 1:
Конфигурация ASBR 2:
По завершению конфигурации, маршруты с меткой 100, будут отфильтровываться ASBR 2 при редистрибуции в домен OSPF. И снова, inter-domain routing loops побеждены.
![](https://habrastorage.org/storage/habraeffect/13/b1/13b129100430e0dfd71597f5001edce5.png)
Я не нашел определения им ни в одном стандарте, потому буду называть их 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.
![](https://habrastorage.org/storage/habraeffect/8e/a0/8ea054030462f3b813b6396f9056fb2d.png)
До тех пор, пока в 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.
![](https://habrastorage.org/storage/habraeffect/a4/a1/a4a11dcb0ce42dd4084cebc24f640a3e.png)
Так выглядит таблица 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 домене будет таковым:
![](https://habrastorage.org/storage/habraeffect/8d/59/8d59b7edd77c6352da9ed29cda498b5e.png)
Потому инженеры, обслуживающие 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, и не анонсировать их в домен-источник.
![](https://habrastorage.org/storage/habraeffect/06/b9/06b9eec74fb4c2de09fa077c80ebbee0.png)
Это можно сделать при помощи «тэгирования» маршрутов. При инжектировании в домен, первый 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 побеждены.