Т.к. RIPа (который v2) в темах нет, пост должен быть не очень большой. Но, учитывая тот факт, что RIPng ничем особо не отличается от второй версии, пост все же должен быть.
Будем действовать в рамках следующего плана для каждого протокола маршрутизации.
- Configure authentication (plain-text, MD5)
- Metris
- Load balancing (equal, unequal)
- Configure Summarization
После того как разберем все IGP протоколы, перейдем к
- Routing loops
- Advanced redistribution with filtering
- VRF Lite
- GRE Tunneling
Сегодня RIP.
Authentication
RIPv2 поддерживает как plain-text, так и md5. Пусть по сценарию, B4-E1-R1 требует md5 от всех своих пиров, а на E3-R2 настроен plain-text.
Первое, что стоит сделать, это создать key chain. Пока не буду заморачиваться с временем жизни и ротацией, ведь у нас ещё не настроен NTP. Создадим просто один ключ.
B4-E1-R1(config)#key chain KEYS_FOR_RIP
B4-E1-R1(config-keychain)#key 1
B4-E1-R1(config-keychain-key)#key-string SUPERSECRETKEY1
B4-E1-R1(config-keychain)#key 1
B4-E1-R1(config-keychain-key)#key-string SUPERSECRETKEY1
Далее на всех интерфейсах в сторону RIP домена настраиваем саму аутентификацию. По умолчанию, выбран plain-text.
B4-E1-R1#sh cdp neighbors | include ^R
R5.route.ccnp Eth 1/2 157 R Linux Uni Eth 0/0
R4.route.ccnp Eth 1/1 137 R Linux Uni Eth 0/0
R3.route.ccnp Eth 1/0 148 R Linux Uni Eth 0/0
R5.route.ccnp Eth 1/2 157 R Linux Uni Eth 0/0
R4.route.ccnp Eth 1/1 137 R Linux Uni Eth 0/0
R3.route.ccnp Eth 1/0 148 R Linux Uni Eth 0/0
B4-E1-R1(config)#int range e1/0-2
B4-E1-R1(config-if-range)#ip rip authentication key-chain KEYS_FOR_RIP
B4-E1-R1(config-if-range)#ip rip authentication mode md5
B4-E1-R1(config-if-range)#ip rip authentication key-chain KEYS_FOR_RIP
B4-E1-R1(config-if-range)#ip rip authentication mode md5
После чего отношения соседства маршруты от B4-E1-R1 перестанут приходить на R3, R4 и R5.
На B4-E1-R1 можно увидеть, что на интерфейсах настроен соответствующий key-chain.
На E3-R2 настроим plain-text. Уж не знаю, что нас заставило, но все же. Принцип такой-же. Создаем key chain и прописываем конфиг на интерфейсы. Команду ip rip authentication mode md5 опускаем. По умолчанию применится ip rip authentication mode text.
E3-R2(config)#key chain KEYS_FOR_RIP
E3-R2(config-keychain)# key 1
E3-R2(config-keychain-key)#key-string SUPERSECRETKEY2
E3-R2(config-keychain)# key 1
E3-R2(config-keychain-key)#key-string SUPERSECRETKEY2
E3-R2(config)#int range e1/0-2
E3-R2(config-if-range)#ip rip authentication key-chain KEYS_FOR_RIP
После чего всему RIP домену станет одиноко...
На R3, R4 и R5 создаем по паре key chain'ов. Первый прописываем в e0/0 интерфейс с типом md5, второй - в e0/1. Конфиг одинаковый для всех трех роутеров.
key chain TO_B4-E1-R1
key 1
key-string SUPERSECRETKEY1
!
key chain TO_E3-R2
!
key chain TO_E3-R2
key 1
key-string SUPERSECRETKEY2
!
!
int e0/0
ip rip authentication key-chain TO_B4-E1-R1
ip rip authentication mode md5
ip rip authentication key-chain TO_B4-E1-R1
ip rip authentication mode md5
int e0/1
ip rip authentication key-chain TO_E3-R2
end
Проверить все это не так легко. Ну, во-первых, конечно же должны появиться маршруты, это ясно. Но мы включим debug.
Взглянем на подопытного R5. Ясно, что добраться до своих "хабов" 10.0.20.1 и 10.0.20.2 ему будет стоить один хоп. Интересней ситуация обстоит с 10.0.20.3 (R3).
Как видно до 10.0.20.1 можно добраться отправив трафик на 10.20.15.1. А мы знаем, что это линк между R1 и R5. Аналогичная ситуация и с 10.0.20.2. А вот добраться до R3 стоит 2 хопа и сделать это можно двумя способами - через 10.0.20.1 и через 10.0.20.2, отправив пакеты на 10.20.15.1 и 10.20.25.2 соответственно.
В расширенной версии чуть больше информации. Видно, что маршрут пришел из RIPа с AD 120 и метрикой 2. Также видно, что активных путей у нас два. Астериск (он же "звездочка") показывает каким маршрутом будет отправлен "новый" трафик. Так как трафик будет балансироваться, положение этой звездочки будет меняться per flow.
Можно отправить пару трейсов чтобы увидеть актуальные пути.
Для теста отключим на время балансировку на R5.
R5(config)#router rip
R5(config-router)#maximum-paths 1
После чего, в таблице маршрутизации останется по одному маршруту.
Ну с балансировкой как-бы все.
Допустим R1, который на самом деле B4/E1/R1, сильно занят в EIGRP и BGP и мы не очень хотим, чтобы он утруждался ещё и RIP трафиком. Давайте немного модифицируем метрику, ухудшим её на пару единиц. Будем использовать простой инструмент - offset list.
Сначала определяем трафик для которого увеличим анонсируемую метрику. Это все lo адреса в RIPе - 10.0.20.Х, а так же все линковые и анонсируемые подсети.
B4-E1-R1#sh access-lists RIP_APPEND_TWO
Standard IP access list RIP_APPEND_TWO
10 permit ip 10.0.20.0 0.0.0.255 any
20 permit ip 10.20.0.0 0.0.255.255 any
30 permit ip 10.21.0.0 0.0.255.255 any
40 permit ip 10.22.0.0 0.0.255.255 any
50 permit ip 10.23.0.0 0.0.255.255 any
60 permit ip 10.24.0.0 0.0.255.255 any
70 permit ip 10.25.0.0 0.0.255.255 any
80 permit ip 10.26.0.0 0.0.255.255 any
90 permit ip 10.27.0.0 0.0.255.255 any
100 permit ip 10.28.0.0 0.0.255.255 any
110 permit ip 10.29.0.0 0.0.255.255 any
Затем увеличиваем метрику на 2 на всех анонсах в RIP домен.
B4-E1-R1(config)#router rip
B4-E1-R1(config-router)#offset-list RIP_APPEND_TWO out 2
Давайте глянем как изменилась ситуация со стороны R5. Сначала то, что было "до".
На lo адреса 1 и 2 маршруты идут напрямую на R1 и R2. Ну просто потому что никто кроме них не может анонсировать лучшую метрику. До R3 и R4 трафик балансируется, потому что они равноудалены от R5 на два хопа.
R 10.0.20.1/32 [120/1] via 10.20.15.1, 00:00:16, Ethernet0/0
R 10.0.20.2/32 [120/1] via 10.20.25.1, 00:00:26, Ethernet0/1
R 10.0.20.3/32 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:16, Ethernet0/0
R 10.0.20.4/32 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:16, Ethernet0/0
На линковые адреса все тоже распределялось логично. Если третий октет начинается с "1", значит эта сеть ближе к R2. Аналогично и про R2. А вот сеть 10.20.34.0 равноудалена от R5.
ip rip authentication key-chain TO_E3-R2
end
Проверить все это не так легко. Ну, во-первых, конечно же должны появиться маршруты, это ясно. Но мы включим debug.
Metrics
В RIP очень простая метрика - hop-count. Когда маршрутизатор анонсирует маршрут, его изначальная стоимость равна нулю (seed metric). Далее, каждый следующий маршрутизатор добавляет единицу при пересылке этого маршрута соседям. Все довольно просто.Взглянем на подопытного R5. Ясно, что добраться до своих "хабов" 10.0.20.1 и 10.0.20.2 ему будет стоить один хоп. Интересней ситуация обстоит с 10.0.20.3 (R3).
Как видно до 10.0.20.1 можно добраться отправив трафик на 10.20.15.1. А мы знаем, что это линк между R1 и R5. Аналогичная ситуация и с 10.0.20.2. А вот добраться до R3 стоит 2 хопа и сделать это можно двумя способами - через 10.0.20.1 и через 10.0.20.2, отправив пакеты на 10.20.15.1 и 10.20.25.2 соответственно.
В расширенной версии чуть больше информации. Видно, что маршрут пришел из RIPа с AD 120 и метрикой 2. Также видно, что активных путей у нас два. Астериск (он же "звездочка") показывает каким маршрутом будет отправлен "новый" трафик. Так как трафик будет балансироваться, положение этой звездочки будет меняться per flow.
Load balancing
RIP поддерживает только equal cost load balancing. На самом деле, мы уже видели пример балансировки выше. За максимальное количество путей отвечает параметр maximum-paths. Он может принимать значения от 1 до 32, а по умолчанию равен 4. Текущее значение этого параметра можно посмотреть в show ip routeДля теста отключим на время балансировку на R5.
R5(config)#router rip
R5(config-router)#maximum-paths 1
После чего, в таблице маршрутизации останется по одному маршруту.
Ну с балансировкой как-бы все.
Metric tunnig
Допустим R1, который на самом деле B4/E1/R1, сильно занят в EIGRP и BGP и мы не очень хотим, чтобы он утруждался ещё и RIP трафиком. Давайте немного модифицируем метрику, ухудшим её на пару единиц. Будем использовать простой инструмент - offset list.
Сначала определяем трафик для которого увеличим анонсируемую метрику. Это все lo адреса в RIPе - 10.0.20.Х, а так же все линковые и анонсируемые подсети.
B4-E1-R1#sh access-lists RIP_APPEND_TWO
Standard IP access list RIP_APPEND_TWO
10 permit ip 10.0.20.0 0.0.0.255 any
20 permit ip 10.20.0.0 0.0.255.255 any
30 permit ip 10.21.0.0 0.0.255.255 any
40 permit ip 10.22.0.0 0.0.255.255 any
50 permit ip 10.23.0.0 0.0.255.255 any
60 permit ip 10.24.0.0 0.0.255.255 any
70 permit ip 10.25.0.0 0.0.255.255 any
80 permit ip 10.26.0.0 0.0.255.255 any
90 permit ip 10.27.0.0 0.0.255.255 any
100 permit ip 10.28.0.0 0.0.255.255 any
110 permit ip 10.29.0.0 0.0.255.255 any
Затем увеличиваем метрику на 2 на всех анонсах в RIP домен.
B4-E1-R1(config)#router rip
B4-E1-R1(config-router)#offset-list RIP_APPEND_TWO out 2
Давайте глянем как изменилась ситуация со стороны R5. Сначала то, что было "до".
На lo адреса 1 и 2 маршруты идут напрямую на R1 и R2. Ну просто потому что никто кроме них не может анонсировать лучшую метрику. До R3 и R4 трафик балансируется, потому что они равноудалены от R5 на два хопа.
R 10.0.20.1/32 [120/1] via 10.20.15.1, 00:00:16, Ethernet0/0
R 10.0.20.2/32 [120/1] via 10.20.25.1, 00:00:26, Ethernet0/1
R 10.0.20.3/32 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:16, Ethernet0/0
R 10.0.20.4/32 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:16, Ethernet0/0
На линковые адреса все тоже распределялось логично. Если третий октет начинается с "1", значит эта сеть ближе к R2. Аналогично и про R2. А вот сеть 10.20.34.0 равноудалена от R5.
R 10.20.13.0/30 [120/1] via 10.20.15.1, 00:00:13, Ethernet0/0
R 10.20.14.0/30 [120/1] via 10.20.15.1, 00:00:13, Ethernet0/0
R 10.20.23.0/30 [120/1] via 10.20.25.1, 00:00:26, Ethernet0/1
R 10.20.24.0/30 [120/1] via 10.20.25.1, 00:00:26, Ethernet0/1
R 10.20.34.0/30 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:13, Ethernet0/0
На анонсируемые сети трафик ходит примерно так же как и на lo.
R 10.21.0.0/16 [120/1] via 10.20.15.1, 00:00:13, Ethernet0/0
R 10.22.0.0/16 [120/1] via 10.20.25.1, 00:00:26, Ethernet0/1
R 10.23.0.0/16 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:13, Ethernet0/0
R 10.24.0.0/16 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:13, Ethernet0/0
А вот в состоянии "после" ситуация меняется. Наша задача - пустить как можно больше трафика через R2.
На lo адрес R1 трафик по прежнему идет напрямую. Ведь только он анонсирует его, хоть и с метрикой 3 на данный момент. Все остальное идет на R2, потому что он имеет лучшую метрику.
R 10.0.20.1/32 [120/3] via 10.20.15.1, 00:00:21, Ethernet0/0
R 10.0.20.2/32 [120/1] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.0.20.3/32 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.0.20.4/32 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
Линковые подсети на себя полностью забрал R2.
R 10.20.13.0/30 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.20.14.0/30 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.20.23.0/30 [120/1] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.20.24.0/30 [120/1] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.20.34.0/30 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
Анонсируемые подсети распределились аналогично lo.
R 10.21.0.0/16 [120/3] via 10.20.15.1, 00:00:21, Ethernet0/0
R 10.22.0.0/16 [120/1] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.23.0.0/16 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.24.0.0/16 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
Сеть в RIP домене не особо требует суммаризации, но мы постараемся. На /32 сети лупбеков у всех "споков" есть доступ только через R1 и R2. Выше видно как распределяется трафик. Можно проссумировать все эти маршруты на R1 и R2 до 10.0.20.0/29. Таким образом, к слову, вообще весь трафик этих подсетей на Lo пойдет через R2, даже на 10.0.20.1. Мы посмотрим чуть ниже, почему это плохая идея... )
На R1 и R2 конфигурация проста. На всех интерфейсах в сторону "споков" настраиваем
E3-R2(config)#int range e1/0-2
E3-R2(config-if-range)#ip summary-address rip 10.0.20.0 255.255.255.248
B4-E1-R1(config)#int range e1/0-2
B4-E1-R1(config-if-range)#ip summary-address rip 10.0.20.0 255.255.255.248
Теперь весь трафик от R3, R4 и R5 на management лупбеки пойдет через R2.
На самом деле, идея это достаточно глупая, потому что мы потеряем связность от R2 до management loopback интерфейса на R1, потому что прямого линка между R1 и R2 внутри RIPа нет. R1 и R2 общаются через свои "споки". Да, дизайн так себе, зато получилось немного "подебажить". С такой суммаризацией будет творится странное.
Давайте разберемся, раз представился такой шанс. Я редуцировал сеть до трех роутеров (R1, R5, R2) и убрал все редистрибуции. Остался только анонс суммарного маршрута на R1 и R2 и offset-list. На начальном этапе интерфейсы между маршрутизаторами выключены.
1. Включаем интерфейс R1 - R5 и debug ip rip events, debug ip rip database на обоих роутерах. На этом этапе особо ничего не происходит. R5 получает суммарный маршрут от R1.
2. Включаем линк R2 - R5. Тут происходит интересное.
R5 не отправляет маршрут 10.0.20.0/29 в сторону R2. Как видно ниже, на R2 эта подсеть не пришла.
Почему так? Единственное, что я могу придумать - split horizon. От R2 к R5 приходит суммарная сеть 10.0.20.0/29. Согласно split horizon правилу, эту сеть не нужно анонсировать обратно в сторону R2. Хорошо звучит? Вполне себе, на R5 даже маршрут на 10.0.20.0/29 теперь смотрит в сторону R2, потому что у него метрика лучше.
3. А теперь посмотрим на R1. Как видно, 10.0.20.0/29 маршрут пришел от R5. Почему split horizon не сработал в этом случае?
На самом деле сработал, просто не совсем так как ожидалось. Тут нам поможет UML диаграмма.
1. R1 отправляет анонс 10.0.20.0/29 с метрикой 3, потому что у нас настроен offset-list.
2. R5 этот маршрут добавляет в свою таблицу, потому как это единсвтенный маршрут в эту сеть.
3. R5 генерирует апдейт в сторону R1, в котором не анонсирует эту 10.0.20.0/29 сеть. Вот он, split horizon.
4. Теперь к R5 приходит анонс от R2, но с лучшей метрикой равной 1. Старая запись из таблицы удаляется и туда вставляется новая.
5. Когда R5 генерирует апдейт для R2, он не включает туда сеть 10.0.20.0/29, потому что R2 только что о ней рассказал (split horizon).
6. Приходит время генерировать очередное сообщение для R1. Т.к. 10.0.20.0/29 с метрикой 1 (в таблице маршрутизации) и 10.0.20.0/29 с метрикой 3 (из анонса R1) это разные записи, R5 добавляет в анонс 10.0.20.0/29 с метрикой 2. К первоначальной метрике 1 была добавляена ещё единица.
7. R1 успешно добавляет этот маршрут в свою таблицу маршрутизации...
Поможет нам в таком случае только удаление offset-list'a, что сделает анонсы одинаковыми. Ну или нормальный дизайн. ) В любом случае, суммаризацию я уберу.
Ну и венцом суммаризации был бы маршрут на 0.0.0.0/0. Но его настройку я перенесу в топик routing loops, потому что анонс "втупую" маршрутов 0.0.0.0/0 на R1 и R2 ни к чему хорошему не приведет. Этот же маршрут в нули уйдет в EIGRP и понеслась... разберем эту ситуацию потом.
R 10.20.14.0/30 [120/1] via 10.20.15.1, 00:00:13, Ethernet0/0
R 10.20.23.0/30 [120/1] via 10.20.25.1, 00:00:26, Ethernet0/1
R 10.20.24.0/30 [120/1] via 10.20.25.1, 00:00:26, Ethernet0/1
R 10.20.34.0/30 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:13, Ethernet0/0
На анонсируемые сети трафик ходит примерно так же как и на lo.
R 10.21.0.0/16 [120/1] via 10.20.15.1, 00:00:13, Ethernet0/0
R 10.22.0.0/16 [120/1] via 10.20.25.1, 00:00:26, Ethernet0/1
R 10.23.0.0/16 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:13, Ethernet0/0
R 10.24.0.0/16 [120/2] via 10.20.25.1, 00:00:26, Ethernet0/1
[120/2] via 10.20.15.1, 00:00:13, Ethernet0/0
А вот в состоянии "после" ситуация меняется. Наша задача - пустить как можно больше трафика через R2.
На lo адрес R1 трафик по прежнему идет напрямую. Ведь только он анонсирует его, хоть и с метрикой 3 на данный момент. Все остальное идет на R2, потому что он имеет лучшую метрику.
R 10.0.20.1/32 [120/3] via 10.20.15.1, 00:00:21, Ethernet0/0
R 10.0.20.2/32 [120/1] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.0.20.3/32 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.0.20.4/32 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
Линковые подсети на себя полностью забрал R2.
R 10.20.13.0/30 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.20.14.0/30 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.20.23.0/30 [120/1] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.20.24.0/30 [120/1] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.20.34.0/30 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
Анонсируемые подсети распределились аналогично lo.
R 10.21.0.0/16 [120/3] via 10.20.15.1, 00:00:21, Ethernet0/0
R 10.22.0.0/16 [120/1] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.23.0.0/16 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
R 10.24.0.0/16 [120/2] via 10.20.25.1, 00:00:07, Ethernet0/1
Summarization
Сеть в RIP домене не особо требует суммаризации, но мы постараемся. На /32 сети лупбеков у всех "споков" есть доступ только через R1 и R2. Выше видно как распределяется трафик. Можно проссумировать все эти маршруты на R1 и R2 до 10.0.20.0/29. Таким образом, к слову, вообще весь трафик этих подсетей на Lo пойдет через R2, даже на 10.0.20.1. Мы посмотрим чуть ниже, почему это плохая идея... )
На R1 и R2 конфигурация проста. На всех интерфейсах в сторону "споков" настраиваем
E3-R2(config)#int range e1/0-2
E3-R2(config-if-range)#ip summary-address rip 10.0.20.0 255.255.255.248
B4-E1-R1(config)#int range e1/0-2
B4-E1-R1(config-if-range)#ip summary-address rip 10.0.20.0 255.255.255.248
Теперь весь трафик от R3, R4 и R5 на management лупбеки пойдет через R2.
На самом деле, идея это достаточно глупая, потому что мы потеряем связность от R2 до management loopback интерфейса на R1, потому что прямого линка между R1 и R2 внутри RIPа нет. R1 и R2 общаются через свои "споки". Да, дизайн так себе, зато получилось немного "подебажить". С такой суммаризацией будет творится странное.
Немного траблшутинга
Давайте разберемся, раз представился такой шанс. Я редуцировал сеть до трех роутеров (R1, R5, R2) и убрал все редистрибуции. Остался только анонс суммарного маршрута на R1 и R2 и offset-list. На начальном этапе интерфейсы между маршрутизаторами выключены.
1. Включаем интерфейс R1 - R5 и debug ip rip events, debug ip rip database на обоих роутерах. На этом этапе особо ничего не происходит. R5 получает суммарный маршрут от R1.
2. Включаем линк R2 - R5. Тут происходит интересное.
R5 не отправляет маршрут 10.0.20.0/29 в сторону R2. Как видно ниже, на R2 эта подсеть не пришла.
Почему так? Единственное, что я могу придумать - split horizon. От R2 к R5 приходит суммарная сеть 10.0.20.0/29. Согласно split horizon правилу, эту сеть не нужно анонсировать обратно в сторону R2. Хорошо звучит? Вполне себе, на R5 даже маршрут на 10.0.20.0/29 теперь смотрит в сторону R2, потому что у него метрика лучше.
3. А теперь посмотрим на R1. Как видно, 10.0.20.0/29 маршрут пришел от R5. Почему split horizon не сработал в этом случае?
На самом деле сработал, просто не совсем так как ожидалось. Тут нам поможет UML диаграмма.
1. R1 отправляет анонс 10.0.20.0/29 с метрикой 3, потому что у нас настроен offset-list.
2. R5 этот маршрут добавляет в свою таблицу, потому как это единсвтенный маршрут в эту сеть.
3. R5 генерирует апдейт в сторону R1, в котором не анонсирует эту 10.0.20.0/29 сеть. Вот он, split horizon.
4. Теперь к R5 приходит анонс от R2, но с лучшей метрикой равной 1. Старая запись из таблицы удаляется и туда вставляется новая.
5. Когда R5 генерирует апдейт для R2, он не включает туда сеть 10.0.20.0/29, потому что R2 только что о ней рассказал (split horizon).
6. Приходит время генерировать очередное сообщение для R1. Т.к. 10.0.20.0/29 с метрикой 1 (в таблице маршрутизации) и 10.0.20.0/29 с метрикой 3 (из анонса R1) это разные записи, R5 добавляет в анонс 10.0.20.0/29 с метрикой 2. К первоначальной метрике 1 была добавляена ещё единица.
7. R1 успешно добавляет этот маршрут в свою таблицу маршрутизации...
Поможет нам в таком случае только удаление offset-list'a, что сделает анонсы одинаковыми. Ну или нормальный дизайн. ) В любом случае, суммаризацию я уберу.
Ну и венцом суммаризации был бы маршрут на 0.0.0.0/0. Но его настройку я перенесу в топик routing loops, потому что анонс "втупую" маршрутов 0.0.0.0/0 на R1 и R2 ни к чему хорошему не приведет. Этот же маршрут в нули уйдет в EIGRP и понеслась... разберем эту ситуацию потом.
Комментариев нет:
Отправить комментарий