Наконец-то дело дошло до серьезного.
4. Routing
- Configure RIP domain (IPv4)
- Configure basic OSPFv2 (areas, passive interfaces, Virtual links)
- Configure EIGRP for IPv4 (Stub routing, passive interfaces)
- Configure basic redistribution
- Configure basic BGP
Все посты по CCNP Route.
Я решил действовать немного иначе. Сначала сделать базовую конфигурацию каждого протокола, посмотреть что получится, а потом постепенно добавлять "фичи". Решил не описывать детально конфигурацию каждого устройства, не к чему это. Лучше подсвечу некоторые моменты, на которые я натолкнулся.
RIP
Самый дремучий протокол из всех представленных. К слову, второй версии на самом деле нет в blueprint'e, есть только RIPng. Вторая версия поддерживает бесклассовую маршрутизацию. Не устанавливает отношения соседства. Использует hop-count в качестве метрики и периодические рассылки маршрутной информации.
Типичный конфиг будет выглядеть примерно следующий образом. Набор интерфейсов, само собой, для каждого роутера разный, а вот все остальное - под копирку.
router rip
version 2
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
no passive-interface Ethernet0/2
network 10.0.0.0
version 2
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
no passive-interface Ethernet0/2
network 10.0.0.0
Тут вас должно привлечь строка network 10.0.0.0. Дело в том, что RIPv2 хоть и является бесклассовым протоколом, но вот команды network эти изменения не коснулись...
Мало того, что у нас нет возможности дописать wildcard маску, так ещё и подсеть (10.24.0.0) в конфиге "округляется" до классовой (10.0.0.0).
На представленном R4 такой подход особых проблем не принесет, а вот, скажем, B4/E1/R1 в таком случае добавит в RIP все сети, которые начинаются с 10. А именно следующие...
Как известно, RIPv2 по умолчанию автосуммирует подсети. Я специально не стал писать no auto-summary, для того чтобы посмотреть что же получиться. Все мы знаем, что автосуммаризация это плохо. Для начала проверим включена ли она вообще.
Видно, что RIP будет пытаться суммаризовать подсети. Значит ли это, в нашем случае, что каждый роутер проссумирует свои подсети до классовой 10.0.0.0/8 и передаст такой анонс соседям?
Если кратко то нет, в нашей топологии RIP будет работать так, как нам надо и без команды no auto-summary. Ниже видно, что у В4/Е1/R1 нет никаких маршрутов типа 10.0.0.0/8.
Почему, потому что RIP будет сумировать подсети только "at major network boundaries". А это где? Допустим, у нас есть классовая сеть 10.0.0.0/8, которую мы анонсируем в RIPv2. Это одна "major" сеть. А вот, для примера, другая "major" сеть - 11.0.0.0/8. А вот пару примеров из другого класса - 172.16.0.0/16 и 172.30.0.0/16.
Корректно RIPv2 будет работать до той поры, пока линковые и анонсиремые подсети будут находится в одной классовой подсети. В нашем случае это 10.0.0.0/8. Проверить это можно двумя способами. В первом способе можно анонсировать в RIP какую-то другую классовую подсеть и она должна проссумироваться. Во втором способе можно временно сменить линковую подсеть между парой роутеров. Я выбрал второй способ, потому что он наглядней.
Сменим линовую подсеть между R4 и B4/E1/R1 на 11.0.0.0/30 и добавим её в RIP. Таким образом мы создадим тот самый major network bounary.
ЧТД. На B4/E1/R1 теперь виден анонс на классовую подсеть 10.0.0.0/8 от R4, у которого теперь адрес 11.0.0.2.
Так что в некоторых случаях отсутствие команды no auto summary не превращает вашу таблицу маршрутизации в бесполезный набор строк. Вот, например, в моем случае, все работает и так. Хотя я бы, конечно, рекомендовал прописывать no auto summary и не выпендриваться. Что я и сделаю на всех роутерах RIP. Ну и плюс нужно откатить все изменения назад.
Я все думал, какие бы придумать ситуации, чтобы применить фильтрование маршрутов. Одна из таких ситуаций - RIPv2. Как я уже говорил, RIPv2 по факту не входит в топики, поэтому я не буду дожидаться следующие части и отфильтрую весь мусор, который B4/E1/R1 и E2/R2 тащат в RIP домен (спойлер - идея была плохой...). А тащат они прилично. Посмотрите ниже сколько ненужных маршрутов знает R3. "Наши" маршруты, напомню, начинаются с 10.0.20. и 10.2Х.
Создаем по префикс-листу на B4/E1/R1 и E2/R2.
ip prefix-list RIP_OUT permit 10.0.20.0/24 ge 32 le 32
ip prefix-list RIP_OUT permit 10.21.0.0/16
ip prefix-list RIP_OUT permit 10.22.0.0/16
ip prefix-list RIP_OUT permit 10.23.0.0/16
ip prefix-list RIP_OUT permit 10.24.0.0/16
ip prefix-list RIP_OUT permit 10.25.0.0/16
ip prefix-list RIP_OUT permit 10.20.0.0/16 ge 30 le 30
Первой строкой разрешаем только подсети, которые начинаются с 10.20.0. и имеют префикс /32, т.е. все адреса на loopback интерфейсах, которые должны быть в RIP.
Затем разрешаем сети с 10.21.0.0/16 по 10.25.0.0/16. Почему так много, ведь у нашей парочки только 10.21. и 10.22.? Ответ простой, в нашей топологии большая часть связности проходит через эти два узла. Т.е. R3 про сеть 10.25, которая находится за R5, узнает от B4/E1/R1 и E2/R2. Если не прописать эту сеть в префикс лист, то R3 про 10.25. никогда не узнает.
В последней строке разрешаем все префиксы, которые начинаются на 10.20 и имеют /30 в значении маски, все линковые подсети в RIP домене, короче говоря.
Последним действием применяем созданные префикс-листы на RIP в направлении OUT.
B4-E1-R1(config)#router rip
B4-E1-R1(config-router)#distribute-list prefix RIP_OUT out
E1-R2(config)#router rip
E3-R2(config-router)#distribute-list prefix RIP_OUT out
Таким образом, эти два роутера будут пропускать только нужные подсети и отбрасывать все остальное. На R3 теперь все красиво.
Внимание вопрос. Коллеги, у меня уже давно есть вопрос, ответ на который я пока так и не нашел. Поделитесь, если кто-то в курсе. Чуть выше я написал следующую строку в префикс-листе.
ip prefix-list RIP_OUT permit 10.0.20.0/24 ge 32 le 32
Это должно разрешать все подсети, которые начинаются на 10.0.20. и иметь /32 в префиксе.
Однако IOS пишет следующее в running config
ip prefix-list RIP_OUT seq 5 permit 10.0.20.0/24 ge 32
Что должно принимать все сети, которые начинаются с 10.0.20. и которые имеют префикс в диапазоне от 24 до 32.
Почему так?
На этом будем считать, что с RIP пока разобрались.
В рамках CCNP Router нам предлагается освоить 3 способа конфигурирования OSPF.
Типовым конфигом для OSPF будет считать следующие строки. Я привожу пример первого типа конфигурации (с помощью network) для роутера О6. Само собой router-id для каждого роутера будет свой, как и набор no passive-interface и строк network.
router ospf 110
router-id 10.0.10.6
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
no passive-interface Ethernet0/2
network 10.0.10.0 0.0.0.255 area 1
network 10.10.36.0 0.0.0.255 area 1
network 10.10.46.0 0.0.0.255 area 1
network 10.10.69.0 0.0.0.255 area 4
network 10.16.0.0 0.0.0.255 area 1
В первой строке network мы определяем area для loopback'a управления. Во второй строке - линк между О3 и О6, далее линки О4-О6 и О6-О9 (в area 4). Последней строкой анонсируем подсеть 10.16.0.0, она накаждом роутере разная.
Короче говоря, такой подход к конфигурированию протоколов маршрутизации я считаю болью. Особенно после долгого общения с Juniper и IOS-XR. Именно поэтому Cisco предлагает второй подход, где область OSPF можно назначать прям на интерфейсе. Ниже пример все того же O6, но включение OSPF на интерфейсах вынесено на... интерфейсы.
interface Loopback1
description MGMT
ip ospf 110 area 1
!
interface Loopback10
description NET
ip ospf 110 area 1
!
interface Ethernet0/0
ip ospf 110 area 1
!
interface Ethernet0/1
ip ospf 110 area 1
!
interface Ethernet0/2
ip ospf 110 area 4
!
router ospf 110
router-id 10.0.10.6
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
no passive-interface Ethernet0/2
Короче говоря, так на много удобнее. Однако когда я настраивал OSPF домен, я решил пойти по сложному пути и настраивал все через network. Только О6 настроен иначе. Во-первых, возможно подход с network даст мне немного поводов для траблшутинга. А, во-вторых, все равно все это мы потом смигрируем на adrress-family конфигурацию.
Сейчас весь OSPF домен имеет базовую настройку. Далее нужно настроить типы зон, настроить виртуальный линк и посмотреть как там разошлись LSA. Может быть сравним выхлоп с прошлой лабой по Juniper, не стоит упускать такую возможность. Хотя нет, лучше вынести это в отдельный пост. Уж очень интересная тема, потому как поведение этих двух вендоров несколько разнится в области OSPF.
Видно, что RIP будет пытаться суммаризовать подсети. Значит ли это, в нашем случае, что каждый роутер проссумирует свои подсети до классовой 10.0.0.0/8 и передаст такой анонс соседям?
Если кратко то нет, в нашей топологии RIP будет работать так, как нам надо и без команды no auto-summary. Ниже видно, что у В4/Е1/R1 нет никаких маршрутов типа 10.0.0.0/8.
Почему, потому что RIP будет сумировать подсети только "at major network boundaries". А это где? Допустим, у нас есть классовая сеть 10.0.0.0/8, которую мы анонсируем в RIPv2. Это одна "major" сеть. А вот, для примера, другая "major" сеть - 11.0.0.0/8. А вот пару примеров из другого класса - 172.16.0.0/16 и 172.30.0.0/16.
Корректно RIPv2 будет работать до той поры, пока линковые и анонсиремые подсети будут находится в одной классовой подсети. В нашем случае это 10.0.0.0/8. Проверить это можно двумя способами. В первом способе можно анонсировать в RIP какую-то другую классовую подсеть и она должна проссумироваться. Во втором способе можно временно сменить линковую подсеть между парой роутеров. Я выбрал второй способ, потому что он наглядней.
Сменим линовую подсеть между R4 и B4/E1/R1 на 11.0.0.0/30 и добавим её в RIP. Таким образом мы создадим тот самый major network bounary.
ЧТД. На B4/E1/R1 теперь виден анонс на классовую подсеть 10.0.0.0/8 от R4, у которого теперь адрес 11.0.0.2.
Так что в некоторых случаях отсутствие команды no auto summary не превращает вашу таблицу маршрутизации в бесполезный набор строк. Вот, например, в моем случае, все работает и так. Хотя я бы, конечно, рекомендовал прописывать no auto summary и не выпендриваться. Что я и сделаю на всех роутерах RIP. Ну и плюс нужно откатить все изменения назад.
Я все думал, какие бы придумать ситуации, чтобы применить фильтрование маршрутов. Одна из таких ситуаций - RIPv2. Как я уже говорил, RIPv2 по факту не входит в топики, поэтому я не буду дожидаться следующие части и отфильтрую весь мусор, который B4/E1/R1 и E2/R2 тащат в RIP домен (спойлер - идея была плохой...). А тащат они прилично. Посмотрите ниже сколько ненужных маршрутов знает R3. "Наши" маршруты, напомню, начинаются с 10.0.20. и 10.2Х.
Создаем по префикс-листу на B4/E1/R1 и E2/R2.
ip prefix-list RIP_OUT permit 10.0.20.0/24 ge 32 le 32
ip prefix-list RIP_OUT permit 10.21.0.0/16
ip prefix-list RIP_OUT permit 10.22.0.0/16
ip prefix-list RIP_OUT permit 10.23.0.0/16
ip prefix-list RIP_OUT permit 10.24.0.0/16
ip prefix-list RIP_OUT permit 10.25.0.0/16
ip prefix-list RIP_OUT permit 10.20.0.0/16 ge 30 le 30
Первой строкой разрешаем только подсети, которые начинаются с 10.20.0. и имеют префикс /32, т.е. все адреса на loopback интерфейсах, которые должны быть в RIP.
Затем разрешаем сети с 10.21.0.0/16 по 10.25.0.0/16. Почему так много, ведь у нашей парочки только 10.21. и 10.22.? Ответ простой, в нашей топологии большая часть связности проходит через эти два узла. Т.е. R3 про сеть 10.25, которая находится за R5, узнает от B4/E1/R1 и E2/R2. Если не прописать эту сеть в префикс лист, то R3 про 10.25. никогда не узнает.
В последней строке разрешаем все префиксы, которые начинаются на 10.20 и имеют /30 в значении маски, все линковые подсети в RIP домене, короче говоря.
Последним действием применяем созданные префикс-листы на RIP в направлении OUT.
B4-E1-R1(config)#router rip
B4-E1-R1(config-router)#distribute-list prefix RIP_OUT out
E1-R2(config)#router rip
E3-R2(config-router)#distribute-list prefix RIP_OUT out
Таким образом, эти два роутера будут пропускать только нужные подсети и отбрасывать все остальное. На R3 теперь все красиво.
Внимание вопрос. Коллеги, у меня уже давно есть вопрос, ответ на который я пока так и не нашел. Поделитесь, если кто-то в курсе. Чуть выше я написал следующую строку в префикс-листе.
ip prefix-list RIP_OUT permit 10.0.20.0/24 ge 32 le 32
Это должно разрешать все подсети, которые начинаются на 10.0.20. и иметь /32 в префиксе.
Однако IOS пишет следующее в running config
ip prefix-list RIP_OUT seq 5 permit 10.0.20.0/24 ge 32
Что должно принимать все сети, которые начинаются с 10.0.20. и которые имеют префикс в диапазоне от 24 до 32.
Почему так?
На этом будем считать, что с RIP пока разобрались.
OSPF
В рамках CCNP Router нам предлагается освоить 3 способа конфигурирования OSPF.
- С помощью команды network (самый больной...)
- С помощью включения OSPF прям на интерфейсах
- С помощью address-family объединив IPv4 и IPv6 настройку в одну структуру.
Типовым конфигом для OSPF будет считать следующие строки. Я привожу пример первого типа конфигурации (с помощью network) для роутера О6. Само собой router-id для каждого роутера будет свой, как и набор no passive-interface и строк network.
router ospf 110
router-id 10.0.10.6
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
no passive-interface Ethernet0/2
network 10.0.10.0 0.0.0.255 area 1
network 10.10.36.0 0.0.0.255 area 1
network 10.10.46.0 0.0.0.255 area 1
network 10.10.69.0 0.0.0.255 area 4
network 10.16.0.0 0.0.0.255 area 1
В первой строке network мы определяем area для loopback'a управления. Во второй строке - линк между О3 и О6, далее линки О4-О6 и О6-О9 (в area 4). Последней строкой анонсируем подсеть 10.16.0.0, она накаждом роутере разная.
Короче говоря, такой подход к конфигурированию протоколов маршрутизации я считаю болью. Особенно после долгого общения с Juniper и IOS-XR. Именно поэтому Cisco предлагает второй подход, где область OSPF можно назначать прям на интерфейсе. Ниже пример все того же O6, но включение OSPF на интерфейсах вынесено на... интерфейсы.
interface Loopback1
description MGMT
ip ospf 110 area 1
!
interface Loopback10
description NET
ip ospf 110 area 1
!
interface Ethernet0/0
ip ospf 110 area 1
!
interface Ethernet0/1
ip ospf 110 area 1
!
interface Ethernet0/2
ip ospf 110 area 4
!
router ospf 110
router-id 10.0.10.6
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
no passive-interface Ethernet0/2
Короче говоря, так на много удобнее. Однако когда я настраивал OSPF домен, я решил пойти по сложному пути и настраивал все через network. Только О6 настроен иначе. Во-первых, возможно подход с network даст мне немного поводов для траблшутинга. А, во-вторых, все равно все это мы потом смигрируем на adrress-family конфигурацию.
Сейчас весь OSPF домен имеет базовую настройку. Далее нужно настроить типы зон, настроить виртуальный линк и посмотреть как там разошлись LSA. Может быть сравним выхлоп с прошлой лабой по Juniper, не стоит упускать такую возможность. Хотя нет, лучше вынести это в отдельный пост. Уж очень интересная тема, потому как поведение этих двух вендоров несколько разнится в области OSPF.
Virtual link
Как известно, в классическом OSPF (да-да, есть и такие реализации (RFC3609), где можно и по другому) каждая non-backbone область должна иметь связность с backbone областью. В нашей топологии это условие выполняется для всех зон, кроме area 4. По этой причине, O9 имеет очень скудные знания о сети.
Поможем О9 добраться до backbone области и найти своих друзей! Для этого надо немного "растянуть" нулевую область от О3 в сторону О6.
 |
| Открыл для себя GIF-анимацию |
O3(config)#router ospf 110
O3(config-router)#area 1 virtual-link 10.0.10.6
O3(config-router)#area 1 virtual-link 10.0.10.6
O6(config)#router ospf 110
O6(config-router)#area 1 virtual-link 10.0.10.3
После таких манипуляций, O9 сможет найти дорогу к своим друзьям.
Теперь можно настроить типы областей.
Stub area
Пара команд на O6 и О9.
O6(config)#router ospf 110
O6(config-router)#area 4 stub
*Aug 28 06:03:50.926: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.9 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
O6(config-router)#area 4 stub
*Aug 28 06:03:50.926: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.9 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
O9(config)#router ospf 110
O9(config-router)#area 4 stub
*Aug 28 06:04:04.254: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.6 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
O9(config-router)#area 4 stub
*Aug 28 06:04:04.254: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.6 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Aug 28 06:04:06.746: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.6 on Ethernet0/0 from LOADING to FULL, Loading Done
Потеряли соседство из-за разности флагов, но потом все быстро восстановили. Пока что на О9 никаких изменений мы не увидим, потому что в Stub область не передаются лишь внешние маршруты, а у нас их пока нет...
Tottaly stub
Тут все просто, отличается только ключом no-summary на роутере со стороны backbone области. С другой стороны можно применять команду без этого дополнительного ключа.
O4(config)#router ospf 110
O4(config-router)#area 2 stub no-summary
*Aug 28 06:09:23.177: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.7 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
O4(config-router)#area 2 stub no-summary
*Aug 28 06:09:23.177: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.7 on Ethernet0/2 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
O7(config)#router ospf 110
O7(config-router)#area 2 stub
*Aug 28 06:09:41.009: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.4 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Aug 28 06:09:41.620: %SYS-5-CONFIG_I: Configured from console by netadm on console
*Aug 28 06:09:43.038: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.4 on Ethernet0/0 from LOADING to FULL, Loading Done
O7(config-router)#area 2 stub
*Aug 28 06:09:41.009: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.4 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Aug 28 06:09:41.620: %SYS-5-CONFIG_I: Configured from console by netadm on console
*Aug 28 06:09:43.038: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.4 on Ethernet0/0 from LOADING to FULL, Loading Done
На О7 мы не должны увидить никаких маршрутов в другие области, только лишь одинокий маршрут на 0.0.0.0.
NSSA
О8 у нас находится в NSSA области, а это значит, что в такой области мы не увидим внешних маршрутов (как в stub), но роутеры в такой области имеют возможность добавлять внешние маршруты с помощью специального LSA Type 7.
На O5 и О8 даем одинаковую команду area 3 nnsa. На О8 такая команда тоже необходима, ему надо дать понять, что ему придется генерировать LSA Type 7 в случае необходимости.
На O5 и О8 даем одинаковую команду area 3 nnsa. На О8 такая команда тоже необходима, ему надо дать понять, что ему придется генерировать LSA Type 7 в случае необходимости.
Есть и ещё одна тонкость. На ABR нужно несколько расширить команду до area 3 nssa default-information-originate. В противном случае в NSSA области не появится маршрут 0.0.0.0 и из этой зоны не получится достучатся до внешнего мира. Почему-то этот момент в литературе часто опускается. Автоматического 0.0.0.0 роута как в stub области сгенерированно не будет
O5(config)#router ospf 110
O5(config-router)#area 3 nssa default-information-originate
*Aug 28 06:23:02.927: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.8 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
O5(config-router)#area 3 nssa default-information-originate
*Aug 28 06:23:02.927: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.8 on Ethernet0/1 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
O8(config)#router ospf 110
O8(config-router)#area 3 nssa
*Aug 28 06:23:20.669: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.5 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Aug 28 06:23:24.471: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.5 on Ethernet0/0 from LOADING to FULL, Loading Done
O8(config-router)#area 3 nssa
*Aug 28 06:23:20.669: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.5 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
*Aug 28 06:23:24.471: %OSPF-5-ADJCHG: Process 110, Nbr 10.0.10.5 on Ethernet0/0 from LOADING to FULL, Loading Done
Tottally NSSA
После таких манипуляций на О8 мы пока что ничего не увидим, кроме появившегося маршрута по умолчанию. Так как мы тут "крутим циски", настроим проприетарную Tottaly NSSA. В таком случае, О8 получит только маршрут на 0.0.0.0, но по прежнему будет иметь возможность ипортировать внешние маршруты.
Для этого потреюутся изменения только со стороны O5. Вместо
area 3 nssa default-information-originate
дадим инструкцию
area 3 nssa no-summary
Примечательно, что default-information-originate с ключом no-summary уже не нужен. Маршрут на нули появится и так. IOS достаточно умен, чтобы понять, что нам нужен маршрут по умолчанию, когда в область не доходят даже маршруты других зон, но достаточно глуп, чтобы добавить маршрут 0.0.0.0 в простую NSSA область. Не исключаю, что за этим поведением есть какая-то логика. В любом случае, на О8 теперь полный аскетизм, я бы сказал тотальный.
EIGRP
Нам предлагается освоить два подхода
- Классический, что с той самой командой network
- Named, где все удобно и красиво вроде как.
На named конфигурацию мы будем мигрировать чуть позже, а сейчас немного страдания с командой network. Конфиг типовой, взглянем на E3-R2.
router eigrp 90
network 10.0.30.0 0.0.0.255
network 10.30.0.0 0.0.255.255
network 10.33.0.0 0.0.0.255
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
no passive-interface Ethernet0/2
no passive-interface Serial2/0.100
no passive-interface Serial2/1.100
no passive-interface Serial2/2.100
eigrp router-id 10.0.30.3
network 10.0.30.0 0.0.0.255
network 10.30.0.0 0.0.255.255
network 10.33.0.0 0.0.0.255
passive-interface default
no passive-interface Ethernet0/0
no passive-interface Ethernet0/1
no passive-interface Ethernet0/2
no passive-interface Serial2/0.100
no passive-interface Serial2/1.100
no passive-interface Serial2/2.100
eigrp router-id 10.0.30.3
Аналогично с OSPF и RIP указываем набор no passive-interface и несколько команд network. В нашем примере, первая добавляет в процесс все management loopback интерфейсы. Вторая - все линковые подсети и третья - специфичную для каждого устройства подсеть на Lo30.
Обратите внимание как задается RID, не просто, а через ключ "eigrp"... Почему так, не ясно. Мы же и так находимся под EIGRP процессом...
Хочу заметить, что в старой литературе в список обязательных команд входит и no auto-summary. В новых версиях IOS это не актуально, а вот на старых ещё как. Поведение этой команды схоже с аналогичной в RIPv2. На экзамене я все равно бы рекомендовал её прописывать "на всякий пожарный".
Базовый EIGRP на этом настроен, остались только тупиковые участки. Напомню, что это не совсем похожий на OSPF концепт. Здесь мы в первую очередь ограничиваем то, что анонсируют наши тупиковые устройства, а не то, что до них доходит. Ну и ограничиваем область рассылки Query сообщений, конечно же. В сторону тупиковых роутоеров их слать нет никакой необходимости, ведь они не пересылают информацию полученную от EIGRP соседей другим соседям.
На выбор у нас несколько ключей
- connected - stub роутер анонсирует подключенные подсети
- summary - stub роутер пересылает свои суммарные маршруты (автоматические или настроенные руками)
- static - анонсирует статические маршруты, если настроена соответсвующая редистрибуция
- redistributed - анонсирует маршруты, которые были нактроены соотвествующей командой
- recieve-only - ничего не анонсирует
- leak-map - если кратко, то позволяет анонсировать некоторые префиксы даже stub роутеру
По умолчанию, применяются connected и summary.
Пусть E5 в нашей топологии будeт "обычными" stub роутером (connected и summary), а E6 будет находится в режиме recieve-only. Таким образом, сеть между E5 и E6 будет доступна только через E5. E7 вообще не будем трогать.
Глянем, что E3-R2 знает про эту подсеть 10.30.56.0/30.
Если кратко, E3-R2 знает про все возможные пути. В таблицу маршрутизации, к слову, пойдет первый, но об этом потом. Итак, настраиваем E5 и E6.
E5(config)#router eigrp 90
E5(config-router)#eigrp stub
E5(config-router)#eigrp stub
E6(config)#router eigrp 90
E6(config-router)#eigrp stub receive-only
После чего, E3-R2 более не узнает про то, что до 10.30.56.0/30 можно добраться через E6.
E6(config-router)#eigrp stub receive-only
После чего, E3-R2 более не узнает про то, что до 10.30.56.0/30 можно добраться через E6.
В выводе E3-R2 видно, как роутеры заявляют о себе. В сторону E5 и E6 больше не будут отправляться query (Suppressing queries).
Можно переходить к BGP.
BGP
B1, B2 и B3 настраиваем пока что "под копирку". Пример B1 ниже
router bgp 64503
bgp log-neighbor-changes
network 103.0.0.0 mask 255.255.248.0
network 120.0.0.0 mask 255.255.255.0
neighbor 101.10.10.1 remote-as 64501
neighbor 102.10.10.1 remote-as 64502
bgp log-neighbor-changes
network 103.0.0.0 mask 255.255.248.0
network 120.0.0.0 mask 255.255.255.0
neighbor 101.10.10.1 remote-as 64501
neighbor 102.10.10.1 remote-as 64502
ip route 103.0.0.0 255.255.248.0 Null0
ip route 120.0.0.0 255.255.255.0 Null0
ip route 120.0.0.0 255.255.255.0 Null0
Пара соседей, пара анонсов, пара маршрутов в Null. Ничего необычного.
На B4/E1/R1 и B5/E2/O1 конфиг чуть другой, потому как здесь нам нужно настроить и iBGP.
Просто конфиг типа
router bgp 64500
bgp log-neighbor-changes
network 100.0.0.0 mask 255.255.252.0
neighbor 10.0.30.2 remote-as 64500
neighbor 101.10.10.5 remote-as 64501
ни к чему хорошему не приведет. Внешние сессии поднимутся, а вот iBGP сессия будет находится в Idle. нам понадобятся две дополнительные команды
neighbor 10.0.30.2 update-source Loopback3
neighbor 10.0.30.2 next-hop-self
Первая позволит установить сессию между loopback (а не линковыми адресами), а вторая проинструктировать менять атрибут next-hop и подставлять туда свой адрес. Иначе, наш iBGP сосед будет видеть в качестве next-hop'а внешний адрес провайдера.
Проверяем, как видно B5-E2-O1получает 4 префикса от iBGP соседа.
Ну и next-hop подставляется
Стоит упомянуть про такую команду как ebgp-multihop. Она применяется в случаях, когда eBGP сессия поднимается между loopback интерфейсами или в случаях, когда eBGP сессия поднимается между не directly connected узлами. Она просто увеличивает TTL в BGP пакетах. Нам она не нужна, потому что в случае iBGP TTL в пакетах и так большой, а все eBGP сессии у нас подняты на линковых адресах.
С одной стороны, с точки зрения жизни, такой подход вполне имеет место быть, но не правильно этот момент проигнорировать в лабе. Поэтому, давайте поднимем сессию между B2 и B3 на loopback адресах. Выглядеть это будет так, соответсвенно.
neighbor 102.0.0.1 remote-as 64502
neighbor 102.0.0.1 ebgp-multihop
neighbor 102.0.0.1 ebgp-multihop
neighbor 101.0.0.1 remote-as 64501
neighbor 101.0.0.1 ebgp-multihop
neighbor 101.0.0.1 ebgp-multihop
Однако так сессия не поднимется, ведь B2 пока что не знает как добраться до 102.0.0.1, а B3 до 101.0.0.1. Нужна статика... и через некоторое время сессия обязательно поднимется.
B2(config)#ip route 102.0.0.1 255.255.255.255 101.102.0.2
B3(config)#ip route 101.0.0.1 255.255.255.255 101.102.0.1
B3(config)#ip route 101.0.0.1 255.255.255.255 101.102.0.1
B3#
*Aug 28 08:54:04.762: %BGP-5-ADJCHANGE: neighbor 101.0.0.1 Up
*Aug 28 08:54:04.762: %BGP-5-ADJCHANGE: neighbor 101.0.0.1 Up
Теперь все ок.
С BGP на этом пока все.
Redestribution
У нас три домена для редистрибуции и несколько точек их соприкосновения.
- RIP <-> EIGRP на B4/E1/R1, E3/R2
- OSPF <-> EIGRP на B5/E2/O1, E4/O2
- Плюс у нас есть внешние маршруты со стороны E7 и О8.
Пока что делаем все втупую.
EIGRP -> RIP
B4-E1-R1(config)#router rip
B4-E1-R1(config-router)#redistribute eigrp 90 metric 5
B4-E1-R1(config-router)#redistribute eigrp 90 metric 5
E3-R2(config)#router rip
E3-R2(config-router)#redistribute eigrp 90 metric 5
E3-R2(config-router)#redistribute eigrp 90 metric 5
После чего в RIPе ничего не появится, потому что мы же сами фильтруем все исходящие анонсы префикс листом RIP_OUT... черт...
Примерно в этом моменте я понял, на сколько RIP старый и не гибкий протокол. Вдумайтесь, я всего лишь хочу заставить анонсировать его те подсети, которые я хочу. А в итоге, он анонсирует в RIP кусок EIGRP сети, причем я эту EIGRP сеть ещё и редистрицурию в него. Единственное решение, которе мне приходит в голову - фильровать уже на R3, R4 и R5 с помощью route-map. Но RIP не поддерживает этот функционал...
В итоге, в RIP домене получается какая-то каша. Все сети EIGRP доступны, но часть из них с метрикой 5, что значит, что они были редистрибуцированы. А вот часть с другими метриками, это значит, что они появились в RIP нативно. Например, 10.0.30.1/32.
Разрулить эту проблему красиво я пока не смог. Если у кого-то есть идеи, прошу.
К слову, ключ metric обязателен, иначе всем префиксам будет проставлен infinite metric равная 16.
RIP -> EIGRP
E3-R2(config)#router eigrp 90
E3-R2(config-router)#redistribute rip metric 1000 200 255 1 1500
B4-E1-R1(config)#router eigrp 90
B4-E1-R1(config-router)#redistribute rip metric 1000 200 255 1 1500
B4-E1-R1(config-router)#redistribute rip metric 1000 200 255 1 1500
Пока в этом направлении все гладко. Развлекаться будем потом.
EIGRP -> OSPF
B5-E2-O1(config)#router ospf 110
B5-E2-O1(config-router)#redistribute eigrp 90 subnets
B5-E2-O1(config-router)#redistribute eigrp 90 subnets
E4-O2(config)#router ospf 110
E4-O2(config-router)#redistribute eigrp 90 subnets
E4-O2(config-router)#redistribute eigrp 90 subnets
Во-первых, по умолчанию будет выбран тип E2 (стоимость по пути остается неизменной).
Во-вторых, при редистрибуции в OSPF из любого протокола отличного от BGP, будет выставлена стоимость равная 20. Для BGP стоимость равна 1.
В-третьих, без ключа subnets будут редистрибуцированны только классовые сети (и тут невыносимая архаичность...).
После этого show ip route становится уже сложно воспринимать, а сеть-то у нас всего ничего. К тому же, не очень удобно фильровать вывод в классичкеском IOS.
В любом случае, сейчас нас интересует только то, что какие-то там маршруты появились.
В любом случае, сейчас нас интересует только то, что какие-то там маршруты появились.
OSPF -> EIGRP
B5-E2-O1(config)#router eigrp 90
B5-E2-O1(config-router)#redistribute ospf 110 metric 1000 200 255 1 1500
B5-E2-O1(config-router)#redistribute ospf 110 metric 1000 200 255 1 1500
E4-O2(config)#router eigrp 90
E4-O2(config-router)# redistribute ospf 110 metric 1000 200 255 1 1500
E4-O2(config-router)# redistribute ospf 110 metric 1000 200 255 1 1500
EIGRP домен видит OSPF маршруты.
Итого
На этом с базовой маршрутизацией все. В итоге ничего не фильтровали, редистрибуцировали "с плеча". Разбираться будем потом. Симулируем рабочие будни... ). На самом деле нет, не мой это подход.
К слову, дополнительно настроил
line console 0
exec-timeout 0 0
на каждом маршрутизаторе. Устал каждый раз логиниться.
на каждом маршрутизаторе. Устал каждый раз логиниться.
Комментариев нет:
Отправить комментарий