вторник, 29 августа 2017 г.

CCNP Route "Full Scale" Лаба: Базовая маршрутизация


Наконец-то дело дошло до серьезного.

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

Тут вас должно привлечь строка 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 пока разобрались.

OSPF


В рамках CCNP Router нам предлагается освоить 3 способа конфигурирования OSPF.
  • С помощью команды network (самый больной...)
  • С помощью включения OSPF прям на интерфейсах
  • С помощью address-family объединив IPv4 и IPv6 настройку в одну структуру.
Сегодня займемся первыми двумя, а в "advanced" части смигрируемся на address-family стиль.

Типовым конфигом для 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
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

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
*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
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

На О7 мы не должны увидить никаких маршрутов в другие области, только лишь одинокий маршрут на 0.0.0.0.

 

NSSA

О8 у нас находится в NSSA области, а это значит, что в такой области мы не увидим внешних маршрутов (как в stub), но роутеры в такой области имеют возможность добавлять внешние маршруты с помощью специального 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
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

 

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

Аналогично с 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

E6(config)#router eigrp 90
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

ip route 103.0.0.0 255.255.248.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 101.0.0.1 remote-as 64501
 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#
*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
E3-R2(config)#router rip
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

Пока в этом направлении все гладко. Развлекаться будем потом.


EIGRP -> OSPF

B5-E2-O1(config)#router ospf 110
B5-E2-O1(config-router)#redistribute eigrp 90 subnets
E4-O2(config)#router ospf 110
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

E4-O2(config)#router eigrp 90
E4-O2(config-router)# redistribute ospf 110 metric 1000 200 255 1 1500

EIGRP домен видит OSPF маршруты.

Итого

На этом с базовой маршрутизацией все. В итоге ничего не фильтровали, редистрибуцировали "с плеча". Разбираться будем потом. Симулируем рабочие будни... ). На самом деле нет, не мой это подход.

К слову, дополнительно настроил
line console 0
exec-timeout 0 0
на каждом маршрутизаторе. Устал каждый раз логиниться.

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

Комментариев нет:

Отправить комментарий