CCNP Route "Full Scale" Лаба: Первый взгляд

Всем привет. Думал я тут думал и решил попытаться собрать Full Scale топологию для подготовки к CCNP Route. Что-то подобное я уже делал, когда готовился к CCNP Switch. Более того, была у меня топология по динамической маршрутизации, о которой рассказывал в этом посте.

Сегодня первый взгляд на blueprint, выбор тем, которые нуждаются в практических навыках и первый вариант топологии.

В каком-то из постов уже упоминал, что я стараюсь делать большие лабы, в которых все технологии переплетаются и составляют одну большую топологию (Full Scale). Во-первых, в результате планирования развивается этот самый навык планирования. Во-вторых, я стремлюсь как-то оправдать топологию и пытаться придумать ситуации использования различных технологий в реальной жизни. В-третьих, на таких топологиях очень легко настроив одно поломать другое и это открывает безграничные возможности по траблшутингу. Прям как в жизни. )

Все посты по CCNP Route лабе.

Blueprint

Итак, первым делом я смотрю на blueprint. С этим небольшим документом надо бы поработать. Обычно я выделяю цветом темы для того чтобы узнать потом, где я почерпнул информацию и куда стоит обращаться для повторения. Если выделено "желтеньким", значит при повторении я бы обратился к Official Certification Guide, если "голубеньким" - cisco.com, например. Далее нужно вычеркнуть все темы, которые напрямую не нуждаются в лабораторке.

В итоге, я много чего повычеркивал. В основном я убрал пункты, где от кандидата требуется умение объяснить что-то или умение описать какую либо тему. Например, под нож попал пункт 3.17 Describe RIPng. Я хотел опубликовать тут полный список, но лучше дам ссылку на PDFку, а то как-то длинно получилось.

Список довольно внушительный и с ним не очень удобно работать. Я бы немного переработал его. В итоге получаем что-то похожее на список ниже.

General

• IPv6 (ND, SLAAC, DHCP)
• Static routing
• Default routing
• Loop Prevention (Tagging,filtering,Split-Horizon, Poisoning)
• DHCP server
• DHCP Relay
• NAT (static, dynamic, PAT)
• IP SLA (Tracking objects)
• PBR
• Summarization (auto, manual)
• Redistribution and Filtering (distribute lists, prefix list, poute maps)
• Routing loops 
• uRPF

RIP(ng)

• Basic configuration
• IPv6

OSPF

• Authentification
• ABR/ASBR
• Virtual Link
• Stub,NSSA, Tottally stubs...
• IPv6
• Metric tuning
• Passive interface

EIGRP

• Classic vs Named
• Authentification
• Stubs
• Load balancing (equal, unequal)
• Metric tuning
• IPv6
• Passive interface

BGP

• Internal vs External
• IPv4
• IPv6 (over IPv6, over IPv4)
• Path Attributes tunning
• Weight
• Local Preference
• MED
• AS Path
• Peer Groups

Operation

• AAA configuration
• Password encription
• Lines
• ACL (standard, extended, time-based)
• TFPT, SCP, HTTP...
• SNMPv2/v3
• Logging
• Debugging (conditional debugs)
• NTP (master,client,peer, authentification)
• NetFlow (v5, v9)

Nice-to-have

• VRF Lite
• GRE
• PPPoE (PAP,CHAP)
• OSPF (PtP, MtP, nonbroadcast...)

Все в принципе ясно и понятно. Какие- то пункты взяты из blueprint'a, но большинство из них перефразированны. От себя я добавил только "routing loops". В blueprint'e явно такая тема не указана, однако я в последнее время очень заинтересовался ей. Хочу и на лабе попробовать воссоздать пару типичных случаев с петлями.

Ну и я добавил раздел Nice-to-have, где собрал то, что я собираюсь добавить в топологию опционально. Ну, а если не получиться, то особо не буду переживать.

Топология 

Как я уже упоминал, у меня есть большая топология, которую я делал для лабораторки по динамической маршрутизации. Я собираюсь частично опираться на эту топологию и добавить недостающие части. Картинка ниже.

Первое, что бросается в глаза, это IS-IS, конечно же. Его, к сожалению, нет в нынешнем CCNP и его придется выкинуть. Так же мне не нравится кусок с EIGRP, с тремя роутерами особо не разгуляешься. OSPF часть хороша, её я уже воссоздавал в лабе по Juniper. Там я придумал пару улучшений, их и добавим сюда. BGP часть на первый взгляд выглядит нормально. Тут же у нас есть и MPLS L3VPN кусок, но и его придется выкинуть. 

Перед тем как начать рисовать топологии нужно дать себе установку особо не распылятся. Классические IOS образы хоть и легче тех же vMXов, но в количестве устройств я все же ограничен. Поэтому топология должна быть необходимой и достаточной.

На место "корного" протокола я, пожалуй, выберу EIGRP. Во-первых, это не очень типично, на мой взгляд. А, во-вторых, я хочу попробовать спровоцировать петлю маршрутизации. Я собираюсь добавить маршруты из RIP в EIGRP, а затем из EIGRP редистрибуцировать эти маршруты в OSPF, в результате может возникнуть ситуация, когда трафик из EIGRP домена пойдет через OSPF домен, а не в RIP напрямую. Картинка ниже.

Если не совсем корректно указать метрику при редистрибуции из OSPF в EIGRP и никак не фильровать маршруты, то роутер внутри EIGRP домена может начать слать трафик в RIP домен через OSPF.

Меня иногда спрашивают, как я придумываю топологии, ответ простой - долго. ) Надо просто начать рисовать и все, раза с 10 должно получится что-то приемлимое. Ниже, например, первый вариант топологии, где я напрочь забыл про BGP...

Пример неудачной топологии

OSPF часть, ясное дело, нормальная. А вот с EIGRP и RIP все так себе. Слишком запутанно, как минимум.

Не буду утомлять бесконечными вариантами и ниже можно увидеть результат работы. Полагаю, что в результате работы придется менять топологию. Возможно сильно. )

Лучше открыть в новой вкладке

IP План

Больше всего пришлось повозиться с IP планом. Для IPv4 схема уже отточена, а вот в IPv6 я себя до сих пор не чувствую комфортно. В каждом домене маршрутизации на схеме можно заметить информацию по адресации. Попробуем расшифровать ей. Возьмем для примера RIP.

Что это вообще значит?

MGMT

Итак, каждый роутер в RIP домене будет иметь Management адрес на своем loopback 2 интерфейсе. Выделяться они будут по следующему принципу.

R3 получит адрес 10.0.20.3/32, R4  - 10.0.20.4/32 и т.д. Т.е. вместо X подставляем цифру из имени роутера.

В случае граничных роутеров, я планирую использовать несколько loopback'ов. Например, B4/E1/R1 будет иметь три адреса, которые будут использоваться для BGP, EIGRP и RIP соответственно. Так или иначе, на loopback 2 у него будет адрес 10.0.20.1/32. 

Такая схема позволит идентифицировать местоположение роутера.

NETs

Каждый роутер имеет некую подсеть, которую он будет анонсировать в тот или иной протокол маршрутизации. Я планирую использовать loopback 10 для этих целей. В случае RIP домена, каждый роутер получит сеть в зависимости от своего имени. R1 - 10.21.0.0/16, R2 - 10.22.0.0/16 и т.д.

LINKs

Линковые адреса я тоже хочу выделить в отдельную легко узнаваемую подсеть. Все линки внутри RIP домена будет находится в 10.10.2.0/24 подсети, которую я буду разбивать на /30. 

IPv6 NETs

Вот тут уже интереснее. Я представляю, что вся наша AS64500 имеет префикс 2001:A::/48. Для наглядности полный адрес сети ниже. 

2001:000A:0000:0000:0000:0000:0000:0000/48

Далее мы вольны нарезать эту подсеть на /64 подсети и использовать их как захотим.

Так вот, каждый роутер получит свою подсеть на lo11 которую он будет анонсировать через тот или иной протокол маршрутизации. В случае с RIP, R2 получит 2001:A:0:2002::/64, R3 - 2001:A:0:2003::/64 и т.д.

Опять же, ниже для наглядности полный адрес сети для R2 и R3. Я выделил жирным часть, которая отвечает за разбиение на подсети.

2001:000A:0000:0000:2002:0000:0000:0000/64

2001:000A:0000:0000:2003:0000:0000:0000/64

IPv6 LINKs

С линковыми (PtP) адресами в IPv6 все не просто. С одной стороны, можно использовать все те же /64. IPv4 прошлое не дает мне спокойно вот так вот расходывать такое огромное количество адресов. Поэтому я решил использовать что-то вроде /126 или /127. Есть парочка RFC на эту тему, лично я решил использовать /127, потому что у нас более нет broadcast'a как такового.

Линковые адреса я решил разбить по-хитрому, благо IPv6 позволяет многое запихать в адрес.

Итак 2001:A:0:20AZ::A(B)/127 означает, что в случае линка R1-R2 мы назначим пару адресов соответственно

2001:A:0:2012::A

2001:A:0:2012::B

Что даст нам понимание того из какого домена линк (20XX - значит RIP) и между какими девайсами (XX12 - R1 и R2). Первый роутер получит адрес с A на конце, второй с B. Полные адреса ниже.

2001:000A:0000:2012:0000:0000:0000:000A

2001:000A:0000:2012:0000:0000:0000:000B

Честно говоря, не уверен, что такой IP план сработает, будет вносить изменения по мере углубления в конфигурацию. 

Результат

Такая вот топология позволит по моим прикидкам покрыть большую часть плана, который я приводил выше. Во всяком случае, темы про протоколы маршрутизации (RIP, OSPF, EIGRP, BGP) откатать получится точно.

Все темы из раздела Operation тоже можно покрыть без труда, не буду сильно засорять ими схему. Буду настраивать уже по месту. Видимо придется поднять сервер для SCP, SNMP, NetFlow, AAA. Подключим его куда-нибудь... не имеет особого значения. Скорее всего со стороны O8, потому что мой внутренний сервер уже имеет IP 192.168.0.100.

В качестве NTP серверов я планирую использовать центральные EIGRP маршрутизаторы со сложными именами (к слову, мне такая идея понравилась). Между ними настроим пиринг, а все остальные устройства будут выступать в роли клиентов. ACLки и аутентицикацию также настроим.

Большие вопросы возникают в секции Nice-to-have. Если VRF Lite и GRE настроить реально, то вот PPP навряд ли, уж очень не хочется поднимать реальный PPP концентратор. Думаю, обойдемся простой настройкой без подтверждения работоспособности. Что касается GRE, то предполагаемые вход и выход из туннеля я отметил на схеме. VRF Lite будет настраивать по месту.

Наибольшее количество вопросов возникает в секции General. Большую часть удастся покрыть без труда, а вот темы ниже требуют отдельного обдумывания.

• IPv6 (ND, SLAAC, DHCP)
• DHCP server
• DHCP Relay
• NAT (static, dynamic, PAT)
• IP SLA (Tracking objects)
• PBR
• uRPF

Последние три, вероятно, опять же будем настраивать по месту. Выберем пару участков, включим uRPF, настроим IP SLA и поменяем роутинг с помощью PBR.

NAT тоже выглядит реально. Как и в случае с лабой по динамической маршрутизации, будем натить в сторону BGP домена на граничных маршрутизаторах.

Для IPv6 и DHCP придется использовать клиентское оборудование. Предполагаю запустить DHCP сервера на E3/R2 и E4/02. E5 и E6 будут релеями. На них же попытаемся обкатать функционал ND, SLAAC и DHCP для IPv6.

Пока что все. Да, забыл упомянуть, что я таки собираюсь моделировать все это не EVE-NG. И причина по сути одна - файл топологии в IOU для такой лабы будет выглядеть слишком сложно. Уж лучше пользоваться drug and drop подходом в UNL EVE-NG.

Засим откланиваюсь, если у вас есть какие-то комментарии по топологии, то я буду рад их обсудить.