BNKT0P Feb 25 2020 at 19:44

Создание отказоустойчивой ИТ инфраструктуры. Часть 4. Внедрение коммутаторов Cisco 3850 для межсетевой маршрутизации

29 min

22K

Lenvendo corporate blogVirtualization*Network technologies*System administration*

Tutorial

Статья предназначена для ознакомления с процессом внедрения коммутаторов третьего уровня в существующую сетевую инфраструктуру, и в основном адресована сетевым администраторам и инженерам. В ней рассказывается про настройку стека из двух коммутаторов Cisco 3850, и их использование для организации более эффективной и отказоустойчивой маршрутизации трафика между внутренними сетями.

Вводная часть

После публикации третьей статьи, в которой шла речь о настройке внутренней и внешней маршрутизации с использованием виртуальных маршрутизаторов VyOS, в комментариях к ней прозвучало утверждение, что приведённая схема сети некорректна, так как она с большим потоком трафика может не справиться, а также что на уже работающей инфраструктуре вынести L3 на другое оборудование может быть проблематично.

По большому счёту, это утверждение является в основном своём посыле верным – по своей структуре и составу такая сеть больше подходит для офиса небольших размеров, чем для нашего датацентра, и нужно изначально проектировать сети грамотно, закладывая в них достаточную ёмкость и способность обработать повышенные объёмы трафика при подключении дополнительных сетевых абонентов.

Но к сожалению, не всегда получается делать всё правильно и красиво, так как зачастую приходится руководствоваться не только техническими соображениями и правилами, но и "политической" ситуацией, когда лицо, принимающее решения, может отдавать более низкий приоритет технической стороне проекта, находясь, например, в рамках строго ограниченного бюджета. В результате, так и появляются сетевые схемы, созданные не совсем по правилам, но это не означает, что всё плохо и они не будут работать как надо.

Чтобы не быть голословным, можно просто привести пример из реального практического опыта.
Один виртуальный маршрутизатор на базе VyOS с 2 vCPU и 1 Gb vRAM, вполне справлялся с трафиком от 20 (двадцати) железных хостов, на которых работало примерно 220 виртуальных машин.
Этот маршрутизатор обслуживал:

межсетевой трафик от 5 внутренних сетей;
основной канал в Интернет 500 Мбит/сек;
приватную линию 200 Мбит/сек, для связи с главным офисом и складами.

BGP full view в этой схеме оказался не нужен, но если добавить ещё памяти и процессоров для VyOS, то он и его смог бы «пережевать».

И примерно похожая схема, реально работала без каких-то нареканий, только в мониторинге иногда могла подскочить утилизация процессоров VyOS до 40-50%, при повышении объёмов прокачиваемого через него трафика между внутренними сетями, хотя при этом каких-то неудобств в работе и сетевых задержек не наблюдалось.

В любом случае, была проанализирована причина такого поведения:

рост числа хостов с 10 до 20;
увеличение числа ВМ с ~120 до ~220;
увеличение количества внутренних сетей с трёх до пяти.

В связи с этими факторами, было принято решение перенести межсетевую маршрутизацию на сетевые коммутаторы третьего уровня, чтобы заранее предупредить потенциально вероятную ситуацию с сетевыми задержками между сетями, особенно при дальнейшем росте внутреннего трафика из-за увеличения числа хостов и ВМ. В итоге, получилась логическая схема сети в классическом её понимании, когда внутренний межсетевой трафик обрабатывается специализированными устройствами:

В реальной жизни сплошь и рядом бывают такие ситуации, когда какой-то проект приходится или переделывать прямо по ходу его выполнения, или переделывать/доделывать за кем-то другим. К таким ситуациям надо быть готовыми, так как наша задача заключается в том, чтобы помочь удовлетворить пожелания заказчика, и без прерывания рабочего процесса суметь что-то перепроектировать или изменить в уже имеющейся инфраструктуре, из-за наличия в ней проблем или узких мест.

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

Сеть нашего датацентра с самого начала проектировалась под следующие условия и оборудование:

два коммутатора Cisco 2960RX;
два физических хоста с ~20-30 ВМ;
две внутренние сети, которые необходимо выпустить в Интернет;
внутренняя сеть для управления всеми сетевыми устройствами.

Исходя из этих данных, было принято решение о создании сетевой инфраструктуры с двумя виртуальными маршрутизаторами VyOS, на которые была возложена дополнительная задача по маршрутизации трафика между внутренними сетями. До заказчика было доведено, что это не совсем правильная схема, и, хотя до поры до времени такая сетевая инфраструктура вполне будет удовлетворять требованиям по пропускной способности, но при условии дальнейшего роста проекта, придётся решать вопрос с организацией внутренней маршрутизации на специализированном оборудовании.

Одним из факторов, оказавших влияние на решение по использованию виртуальных маршрутизаторов VyOS для внутренней маршрутизации, явилась возможность их вертикального масштабирования, для компенсирования возникающей нагрузки из-за увеличения межсетевого трафика. Это означает, что у виртуального VyOS можно нарастить ресурсы по мере необходимости – увеличить количество vCPU и vRAM, и даже напрямую пробросить физическую сетевую карту с хоста, чтобы снизить утилизацию процессоров ВМ.

Как выяснилось позже, у заказчика (на складе или где-то под столом у завхоза – такое тоже бывает) были найдены две коробки с коммутаторами Cisco 3850, которые когда-то были куплены для каких-то уже неведомых внутренних целей. К сожалению, это произошло уже после запуска проекта, и до поры до времени коммутаторы оставались лежать без дела, хотя факт их обнаружения конечно же был принят во внимание.

Время шло, наш виртуальный датацентр постепенно расширялся – увеличивались объёмы прокачиваемого трафика между внутренними сетями через виртуальные маршрутизаторы и также постепенно на них росла постоянная утилизация vCPU. Поэтому было принято решение всё-таки задействовать коммутаторы Cisco 3850 по их прямому предназначению – для маршрутизации внутреннего трафика. Тем более, что в дальнейшем была запланирована модернизация сети нашего датацентра с 1 Гбит/с до 10 Гбит/с и коммутаторы Cisco 3850 в этот план тоже прекрасно вписались, благодаря неплохой пропускной способности стека на уровне 480 Гбит/с, наличию 10 Гбит/с портов, и другого не менее полезного функционала.

В общем, получилась немного затянутая вводная часть, но это было сделано специально, чтобы обосновать причины, по которым и в какой момент времени нужно внедрять Cisco 3850. Однозначно, что это надо было делать на самом начальном этапе реализации проекта, но иногда приходится заниматься такими вопросами на уже работающей сетевой инфраструктуре.

Вся остальная статья будет посвящена тому, как внедрить коммутаторы L3, ничего при этом не поломав и не допустив простоев в функционировании сети, так как непрерывная работа проекта – это одно из основных требований бизнеса. Нам в этом поможет уже существующая сетевая инфраструктура, которая позволит осуществить их внедрение практически безболезненно.

После вводной части, переходим к основному содержанию статьи, и чтобы было удобнее ориентироваться, приведу её основные главы:

Схема сети с межсетевой маршрутизацией на Cisco 3850
Подготовительные работы
Установка и настройка стека коммутаторов Cisco 3850
Подключение стека коммутаторов Cisco 2960RХ к стеку Cisco 3850
Принципы настройки маршрутизации между внутренними и внешними сетями
Организация маршрутизации между внутренними и внешними сетями с использованием PBR
Перевод внутренней межсетевой маршрутизации с VyOS'ов на стек Cisco 3850
Организация маршрутизации между внутренними и внешними сетями с использованием OSPF

Схема сети с межсетевой маршрутизацией на Cisco 3850

Вариант 1
Схема сети с использованием source-based маршрутизации на основе PBR

Представленная схема немного видоизменена по сравнению со схемой сети из предыдущей статьи – на ней добавлен логический коммутатор L3, две новые внутренние сети VLAN34 и VLAN35, а также с целью экономии места на схеме, урезан условный Интернет до одной сети – 172.16.3.0/24.

В составе тестового стенда будут использованы следующие сети:

VLAN17 – сеть 172.20.1.0/24, приватные адреса для хостов в датацентре (IPMI, management)
VLAN30 – сеть 172.16.1.0/24, «публичная» сеть, связь между VyOS1, VyOS2 и Provider-1
VLAN31 – сеть 172.16.2.0/24, «публичная» сеть, связь между VyOS2, VyOS1 и Provider-2
VLAN32 – сеть 172.20.32.0/23, приватные адреса для хостов в датацентре – PROD
VLAN34 – сеть 172.20.34.0/24, приватные адреса для хостов в датацентре – DEV
VLAN35 – сеть 172.20.35.0/24, приватные адреса для хостов в датацентре – DMZ
VLAN36 – сеть 172.16.10.8/30, «публичная» P2P сеть, связь между роутерами Provider-1 и Provider-3
VLAN37 – сеть 172.16.10.12/30, «публичная» P2P сеть, связь между роутерами Provider-2 и Provider-3
VLAN38 – сеть 172.16.3.0/24, «публичная» сеть для внешних хостов, эмуляция Интернет
VLAN40 – сеть 172.20.40.0/23, приватные адреса для хостов в датацентре – TEST

Вариант 2
Схема сети с использованием destination-based маршрутизации на основе протокола OSPF

На этой схеме добавлен логический коммутатор L3, две новые внутренние сети VLAN34 и VLAN35 для клиентов, и внутренняя сеть VLAN33 для связи между роутерами VyOS и стеком коммутаторов L3. Также из целей экономии места на схеме, урезан условный Интернет до одной сети – 172.16.3.0/24.

В составе тестового стенда будут использованы следующие сети:

VLAN17 – сеть 172.20.1.0/24, приватные адреса для хостов в датацентре (IPMI, management)
VLAN30 – сеть 172.16.1.0/24, «публичная» сеть, связь между VyOS1, VyOS2 и Provider-1
VLAN31 – сеть 172.16.2.0/24, «публичная» сеть, связь между VyOS2, VyOS1 и Provider-2
VLAN32 – сеть 172.20.32.0/23, приватные адреса для хостов в датацентре – PROD
VLAN33 – сеть 172.20.133.0/24, приватные адреса для связи между VyOS2, VyOS1 и 3850
VLAN34 – сеть 172.20.34.0/24, приватные адреса для хостов в датацентре – DEV
VLAN35 – сеть 172.20.35.0/24, приватные адреса для хостов в датацентре – DMZ
VLAN36 – сеть 172.16.10.8/30, «публичная» P2P сеть, связь между роутерами Provider-1 и Provider-3
VLAN37 – сеть 172.16.10.12/30, «публичная» P2P сеть, связь между роутерами Provider-2 и Provider-3
VLAN38 – сеть 172.16.3.0/24, «публичная» сеть для внешних хостов, эмуляция Интернет
VLAN40 – сеть 172.20.40.0/23, приватные адреса для хостов в датацентре – TEST-

Подготовительные работы

Для тестирования межсетевого взаимодействия, на кластере oVirt понадобится создать три новые логические сети – VLAN33, VLAN34, VLAN35, а также виртуальные машины с CentOS 7 x86/64 1810 Minimal (можно более свежую):

test-IM34 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- VLAN34, IP – 172.20.34.239/24, Gateway – 172.20.34.1
test-IM35 – 1 Gb RAM, 1 CPU, 10 Gb HDD
- VLAN35, IP – 172.20.35.239/24, Gateway – 172.20.35.1

После подключения этих двух ВМ к соответствующим логическим сетям, устанавливаем на них ОС, и настраиваем IP адреса и шлюзы.

На маршрутизаторах VyOS должны быть добавлены новые сетевые интерфейсы для работы с VLAN34 и VLAN35, а также настроен vrrp и HAIP для этих новых сетей.

Настройка VyOS1

set interfaces ethernet eth5 address '172.20.34.253/24'
set interfaces ethernet eth5 description 'VLAN34'

set interfaces ethernet eth6 address '172.20.35.253/24'
set interfaces ethernet eth6 description 'VLAN35'

set high-availability vrrp group haip-4 vrid 40
set high-availability vrrp group haip-4 interface eth5
set high-availability vrrp group haip-4 virtual-address 172.20.34.1/24
set high-availability vrrp group haip-4 priority '200'
set high-availability vrrp group haip-4 authentication type 'plaintext-password'
set high-availability vrrp group haip-4 authentication password 'b65495f9'
set high-availability vrrp group haip-4 preempt 2
set high-availability vrrp group haip-4 advertise-interval '1'

set high-availability vrrp group haip-5 vrid 40
set high-availability vrrp group haip-5 interface eth6
set high-availability vrrp group haip-5 virtual-address 172.20.35.1/24
set high-availability vrrp group haip-5 priority '200'
set high-availability vrrp group haip-5 authentication type 'plaintext-password'
set high-availability vrrp group haip-5 authentication password 'b65495f9'
set high-availability vrrp group haip-5 preempt 2
set high-availability vrrp group haip-5 advertise-interval '1'

commit

Настройка VyOS2

set interfaces ethernet eth5 address '172.20.34.254/24'
set interfaces ethernet eth5 description 'VLAN34'

set interfaces ethernet eth6 address '172.20.35.254/24'
set interfaces ethernet eth6 description 'VLAN35'

set high-availability vrrp group haip-4 vrid 40
set high-availability vrrp group haip-4 interface eth5
set high-availability vrrp group haip-4 virtual-address 172.20.34.1/24
set high-availability vrrp group haip-4 priority '199'
set high-availability vrrp group haip-4 authentication type 'plaintext-password'
set high-availability vrrp group haip-4 authentication password 'b65495f9'
set high-availability vrrp group haip-4 preempt 2
set high-availability vrrp group haip-4 advertise-interval '1'

set high-availability vrrp group haip-5 vrid 40
set high-availability vrrp group haip-5 interface eth6
set high-availability vrrp group haip-5 virtual-address 172.20.35.1/24
set high-availability vrrp group haip-5 priority '199'
set high-availability vrrp group haip-5 authentication type 'plaintext-password'
set high-availability vrrp group haip-5 authentication password 'b65495f9'
set high-availability vrrp group haip-5 preempt 2
set high-availability vrrp group haip-5 advertise-interval '1'

commit

Установка и настройка стека коммутаторов Cisco 3850

Основной интерес на схеме выше, для нас представляет Cisco 3850, который является логическим устройством, состоящим из двух физических коммутаторов – WS-C3850-24T-E, 24 x 1 GE, 350 W no PoE, 4 x 1 GE, 2 x 10 GE, соединённых:

посредством двух кабелей STACK-T1-50CM= в кольцо StackWise, с общей пропускной способностью стека в 480 Гбит/сек,
посредством двух кабелей CAB-SPWR-30CM= в кольцо StackPower, в котором мощность всех четырёх БП может или суммироваться для создания одного виртуального блока питания и разделения общей нагрузки, или же резервируется мощность одного из БП, для увеличения отказоустойчивости.

Последовательность действий по начальной установке и настройке стека коммутаторов Cisco 3850

1) Монтаж коммутаторов в стойку, коммутация между собой для создания стека.

Как установить коммутаторы в стойку, подключить к ним питание и соединить между собой специальными кабелями для создания стека посредством StackWise и StackPower, подробно и наглядно описано в официальной документации – Catalyst 3850 Switch Getting Started Guide.

Важно учитывать, что для настройки и поддержки технологий StackWise и StackPower имеются определённые требования, основными из которых являются:

использование (желательное) в стеке одинаковых моделей коммутаторов;
использование одинаковых версий ПО и лицензий на коммутаторах.

Также для того, чтобы задействовать для стека полнофункциональные сервисы на уровне L3, необходимо иметь определённый тип лицензии. В нашем случае будет использоваться PBR (policy based routing), поэтому на оба коммутатора была заранее установлена постоянная лицензия типа IP Services.

Для общей информации, отличия лицензий друг от друга

LAN Base
Функции коммутации второго уровня;
Статическая маршрутизация;
Базовая поддержка средств безопасности: порт ACL, 802.1x, DHCP snooping, DAI, IPSG;
Базовая поддержка качества обслуживания: Ingress policing, AutoQoS, Trust Boundary, DSCP mapping.
IP Base
Все функции коммутации второго уровня;
Статическая маршрутизация;
Полная поддержка средств безопасности;
Полная поддержка качества обслуживания;
Mobility controller и Flexible NetFlow (доступно для 3650/3850);
StackPower и EEM.
IP Services
Все функции коммутации второго уровня;
Динамическая и статическая маршрутизация (PBR, EIGRP, OSPF, BGP, VRF-lite и т.д.);
Полная поддержка средств безопасности;
Полная поддержка качества обслуживания;
Mobility controller и Flexible NetFlow (доступно для 3650/3850);
StackPower, EEM, IPSLA.

2) Подключение к коммутатору 3850 через консольный порт и выполнение начальной настройки.

Вся информация по приводимым в статье настройкам, командам и их функциям, доступна в основных справочных руководствах:

Software Configuration Guide, Cisco IOS XE Everest 16.6.x (Catalyst 3850 Switches)
Command Reference, Cisco IOS XE Everest 16.6.x (Catalyst 3850 Switches)
полный список всех команд, находится по ссылке – Command References

Подключиться к консольному порту коммутатора можно через специальные USB или RJ-45 порты, настройки программы для эмуляции терминала должны быть такими: 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control.
Если ПК администратора работает под Windows, то для эмуляции терминала можно использовать Putty, если под Linux, то minicom.

После подключения к терминальному порту устройства, выполняем базовую настройку стека коммутаторов:

Вначале проверяем версию ПО, модели коммутаторов в стеке и установленную на них лицензию

sh ver | beg Switch Ports Model
Switch  Ports   Model               SW Version          SW Image                    Mode
------  -----           -----               ----------                  ----------                  ----
*    1  32      WS-C3850-24T        16.6.7              CAT3K_CAA-UNIVERSALK9   INSTALL
     2  32      WS-C3850-24T        16.6.7              CAT3K_CAA-UNIVERSALK9   INSTALL

sh license right-to-use
Slot#       License Name          Type   Period left
----------------------------------------------------
    1         ipservices     Permanent      Lifetime
----------------------------------------------------
License Level on Reboot: ipservices

Slot#       License Name          Type   Period left
----------------------------------------------------
    2         ipservices     Permanent      Lifetime
----------------------------------------------------
License Level on Reboot: ipservices

Далее выполняем базовую настройку стека

enable  
 switch 1 priority 15
 switch 2 priority 14

conf t 
 hostname 3850-stack
 no ip domain-lookup
 no service pad
 service timestamps debug datetime msec
 service timestamps log datetime localtime show-timezone msec
 no service password-encryption
 service sequence-numbers
 logging buffered 16384

 stack-mac persistent timer 0
 stack-power stack Powerstack-1
 mode redundant

 clock timezone MSK 3
 vtp mode transparent
 ip subnet-zero

 spanning-tree mode rapid-pvst
 spanning-tree etherchannel guard misconfig
 spanning-tree extend system-id
 spanning-tree vlan 1,17,30-40 root primary
 spanning-tree loopguard default
 port-channel load-balance src-dst-ip
 errdisable recovery cause bpduguard
 errdisable recovery cause loopback
 errdisable recovery interval 60

line con 0
 session-timeout 60
 exec-timeout 60 0
 logging synchronous
line vty 5 15
 session-timeout 60
 exec-timeout 60 0
 logging synchronous

 ip http server
 ip http secure-server
 exit

wr mem
reload

После перезагрузки коммутатора, проверяем параметры стека

3850-stack>enable
3850-stack#show switch detail
Switch/Stack Mac Address : b090.7ebd.ХХХХ - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Switch#   Role    Mac Address     Priority Version  State
-------------------------------------------------------------------------------------
*1       Active   b090.7ebd.ХХХХ 15     V02     Ready
 2       Standby  b090.7ef3.ХХХХ 14     V02     Ready

         Stack Port Status             Neighbors
Switch#  Port 1     Port 2           Port 1   Port 2
--------------------------------------------------------
  1         OK         OK               2        2
  2         OK         OK               1        1

3850-stack#show switch stack-ring speed
Stack Ring Speed        : 480G
Stack Ring Configuration: Full
Stack Ring Protocol     : StackWise

3850-stack#show switch stack-ports
Switch#   Port1     Port2
----------------------------
1         OK        OK
2         OK        OK

3850-stack#show switch neighbors
  Switch #    Port 1       Port 2
  --------    ------       ------
      1         2             2
      2         1             1

3850-stack#show stack-power
Power Stack           Stack   Stack    Total   Rsvd    Alloc   Sw_Avail   Num  Num
Name                  Mode    Topolgy  Pwr(W)  Pwr(W)  Pwr(W)   Pwr(W)    SW   PS
--------------------  ------  -------  ------  ------  ------  ------  ----- ----
Powerstack-1          SP-R    Ring     1400    380     460     560       2    4

3850-stack#show stack-power detail
Power Stack           Stack   Stack    Total   Rsvd    Alloc   Sw_Avail   Num  Num
Name                  Mode    Topolgy  Pwr(W)  Pwr(W)  Pwr(W)   Pwr(W)    SW   PS
--------------------  ------  -------  ------  ------  ------  ------  ----- ----
Powerstack-1          SP-R    Ring     1400    380     460     560       2    4

Power stack name: Powerstack-1
    Stack mode: Redundant
    Stack topology: Ring
    Switch 1:
        Power budget: 230
        Power allocated: 230
        Low port priority value: 21
        High port priority value: 12
        Switch priority value: 3
        Port 1 status: Connected
        Port 2 status: Connected
        Neighbor on port 1: Switch 2 - b090.7ef3.ХХХХ
        Neighbor on port 2: Switch 2 - b090.7ef3.ХХХХ
    Switch 2:
        Power budget: 230
        Power allocated: 230
        Low port priority value: 22
        High port priority value: 13
        Switch priority value: 4
        Port 1 status: Connected
        Port 2 status: Connected
        Neighbor on port 1: Switch 1 - b090.7ebd.ХХХХ
        Neighbor on port 2: Switch 1 - b090.7ebd.ХХХХ

3850-stack#show stack-power neighbors
Power Stack           Stack   Stack    Total   Rsvd    Alloc   Sw_Avail   Num  Num
Name                  Mode    Topolgy  Pwr(W)  Pwr(W)  Pwr(W)   Pwr(W)    SW   PS
--------------------  ------  -------  ------  ------  ------  ------  ----- ----
Powerstack-1          SP-R    Ring     1400    380     460     560       2    4
    Power Stack           Port 1  Port 1             Port 2  Port 2
SW  Name                  Status  Neighbor SW:MAC    Status  Neighbor SW:MAC
--  --------------------  ------  ----------------   ------  ----------------
1   Powerstack-1          Conn    2:b090.7ef3.ХХХХ Conn    2:b090.7ef3.ХХХХ
2   Powerstack-1          Conn    1:b090.7ebd.ХХХХ Conn    1:b090.7ebd.ХХХХ

3850-stack#sh env all
Switch 1 FAN 1 is OK
Switch 1 FAN 2 is OK
Switch 1 FAN 3 is OK
FAN PS-1 is OK
FAN PS-2 is OK
Switch 2 FAN 1 is OK
Switch 2 FAN 2 is OK
Switch 2 FAN 3 is OK
FAN PS-1 is OK
FAN PS-2 is OK
Switch 1: SYSTEM TEMPERATURE is OK
Inlet Temperature Value: 20 Degree Celsius
Temperature State: GREEN
Yellow Threshold : 46 Degree Celsius
Red Threshold    : 56 Degree Celsius

Hotspot Temperature Value: 39 Degree Celsius
Temperature State: GREEN
Yellow Threshold : 105 Degree Celsius
Red Threshold    : 125 Degree Celsius
Switch 2: SYSTEM TEMPERATURE is OK
Inlet Temperature Value: 20 Degree Celsius
Temperature State: GREEN
Yellow Threshold : 46 Degree Celsius
Red Threshold    : 56 Degree Celsius

Hotspot Temperature Value: 38 Degree Celsius
Temperature State: GREEN
Yellow Threshold : 105 Degree Celsius
Red Threshold    : 125 Degree Celsius
SW  PID                            Serial#          Status         Sys Pwr      PoE Pwr     Watts
--  ------------------             ----------        ----------     -------     -------     -----
1A  PWR-C1-350WAC       ART2244F8ХХ  OK              Good       Good        350
1B  PWR-C1-350WAC       ART2248FLХХ  OK              Good       Good        350
2A  PWR-C1-350WAC       ART2244F9ХХ  OK              Good       Good        350
2B  PWR-C1-350WAC       ART2248FLХХ  OK              Good       Good        350

Если всё выглядит нормально, то продолжаем его настройку - добавляем необходимые VLAN'ы, включаем ssh, настраиваем IP адрес для удалённого управления, и т.п.

enable
conf t
vlan 17
 name 172.20.1.0/24
vlan 32
 name 172.20.32.0/23
vlan 33
vlan 34
 name 172.20.34.0/24
vlan 35
 name 172.20.35.0/24
vlan 36
vlan 37
vlan 38
vlan 39
vlan 40
 name 172.20.40.0/23

interface Vlan1
 no ip address
 shutdown
 exit

interface vlan 17
 ip address 172.20.1.2 255.255.255.0

crypto key generate rsa

ip ssh version 2
ip ssh time-out 90

line vty 0 4
 session-timeout 60
 exec-timeout 60 0
 privilege level 15
 logging synchronous
 transport input ssh

line vty 5 15
 session-timeout 60
 exec-timeout 60 0
 privilege level 15
 logging synchronous
 transport input ssh
snmp-server community Public RO
snmp-server location Moscow, Russia

aaa new-model
aaa authentication login default local 
username cisco privilege 15 secret mysecretpassword

enable secret myenablepassword
service password-encryption

ntp server 85.21.78.8 prefer
ntp server 89.221.207.113
ntp server 185.22.60.71
ntp server 192.36.143.130
ntp server 185.209.85.222

exit
wr mem

На этом создание стека коммутаторов Cisco 3850 и его начальная настройка выполнены.

Подключение стека коммутаторов Cisco 2960RХ к стеку Cisco 3850

Чтобы обеспечить связность на уровне L2 между стеком коммутаторов Cisco 2960RХ и стеком Cisco 3850, подключаем их друг к другу патч-кордами нужной длины, и далее настраиваем Etherchannel:

2960X Gi1/0/42 <-> 3850-stack Gi1/0/21
2960X Gi2/0/42 <-> 3850-stack Gi1/0/23
2960X Gi1/0/44 <-> 3850-stack Gi2/0/21
2960X Gi2/0/44 <-> 3850-stack Gi2/0/23

Выполняем настройку Etherchannel на стеке коммутаторов Cisco 2960RХ

enable
conf t

interface Port-channel 9
 description Channel->3850-stack
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 spanning-tree link-type point-to-point

interface GigabitEthernet1/0/44
 shut
 description Channel -> 3850-stack Gi1/0/21
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 spanning-tree link-type point-to-point
 channel-group 9 mode active

interface GigabitEthernet1/0/48
 shut
 description Channel -> 3850-stack Gi2/0/21
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 spanning-tree link-type point-to-point
 channel-group 9 mode active

interface GigabitEthernet2/0/44
 shut
 description Channel -> 3850-stack Gi1/0/23
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 spanning-tree link-type point-to-point
 channel-group 9 mode active

interface GigabitEthernet2/0/48
 shut
 description Channel -> 3850-stack Gi2/0/23
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 spanning-tree link-type point-to-point
 channel-group 9 mode active

exit
wr mem

Выполняем настройку Etherchannel на стеке коммутаторов Cisco 3850

enable
conf t

interface Port-channel 2
 description Channel -> 2960X-stack1
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 spanning-tree link-type point-to-point

interface GigabitEthernet1/0/21
 description Channel -> 2960X-stack1 Gi1/0/44 
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 channel-group 2 mode active
 no shut

interface GigabitEthernet1/0/23
 description Channel -> 2960X-stack1 Gi2/0/44
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 channel-group 2 mode active
 no shut

interface GigabitEthernet2/0/21
 description Channel -> 2960X-stack1 Gi1/0/48
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 channel-group 2 mode active
 no shut

interface GigabitEthernet2/0/23
 description Channel -> 2960X-stack1 Gi2/0/48
 switchport trunk allowed vlan 1,17,30-40
 switchport mode trunk
 channel-group 2 mode active
 no shut

exit
wr mem

Проверяем, поднялся ли Etherchannel между стеками 2960х и 3850-stack

3850-stack#sh etherchannel summary | beg Po2
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator
        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port
        A - formed by Auto LAG
2      Po2(SU)         LACP      Gi1/0/21(P) Gi1/0/23(P) Gi2/0/21(P)
                                 Gi2/0/23(P)

3850-stack#show lacp internal | beg Channel group 2
Flags:  S - Device is requesting Slow LACPDUs
        F - Device is requesting Fast LACPDUs
        A - Device is in Active mode       P - Device is in Passive mode
Channel group 2
                            LACP port     Admin     Oper    Port        Port
Port      Flags   State     Priority      Key       Key     Number      State
Gi1/0/21  SA      bndl      32768         0x2       0x2     0x116       0x3D
Gi1/0/23  SA      bndl      32768         0x2       0x2     0x118       0x3D
Gi2/0/21  SA      bndl      32768         0x2       0x2     0x216       0x3D
Gi2/0/23  SA      bndl      32768         0x2       0x2     0x218       0x3D

Если имеются какие-то проблемы, то обязательно смотрим логи на обоих коммутаторах:

sh logging

После того, как поднимется Etherchanel между коммутаторами, к Cisco 3850 можно будет подключиться, например, с любого маршрутизатора VyOS на IP адрес 172.20.1.2 по ssh.

Принципы настройки маршрутизации между внутренними и внешними сетями

Для настройки маршрутизации между внутренними и внешними сетями, у нас имеется как минимум два варианта.

Вариант 1

Реализуется с помощью destination-based маршрутизации, т.е. решение о том, куда трафик будет направлен, принимается на основании имеющихся маршрутов в таблице маршрутизации коммутатора 3-го уровня. В таблицу маршрутизации данные маршруты (или маршрут по умолчанию) могут попадать или из статически настроенных маршрутов, или из динамических протоколов маршрутизации.

Для его внедрения придётся переделывать внутреннюю маршрутизацию на роутерах VyOS:

убирать интерфейсы к внутренним сетям,
настраивать связь между VyOS и внутренними сетями, или с помощью протокола динамической маршрутизации, или используя статический маршрут к ним через Cisco 3850.

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

Вариант 2

Реализация происходит с помощью source-based маршрутизации, т.е. решение о том, куда трафик будет направлен, принимается в первую очередь на основании информации об источнике трафика, а далее уже определяется пункт назначения, куда конкретно этот трафик направляется. Здесь на VyOS практически ничего менять не надо, а вся внутренняя маршрутизация будет происходить на стеке Cisco 3850 с помощью PBR (policy based routing). Помимо относительной простоты реализации, этот вариант позволит исключить полный отказ стека Cisco 3850, когда трафик между внутренними сетями может быть переброшен обратно на роутеры VyOS.

Организация маршрутизации между внутренними и внешними сетями с использованием PBR (policy based routing)

Ссылки на справочную документацию:

Включаем простую маршрутизацию между VLAN'ами на стеке Cisco 3850, настраиваем адреса для SVI (Switch Virtual Interface)

enable
conf t

ip routing

interface Vlan17
 ip address 172.20.1.2 255.255.255.0

interface Vlan32
 ip address 172.20.32.2 255.255.254.0

interface Vlan34
 ip address 172.20.34.2 255.255.255.0

interface Vlan35
 ip address 172.20.35.2 255.255.255.0

interface Vlan40
 ip address 172.20.40.2 255.255.254.0

exit
wr mem

Если мы сейчас подключим хосты к вышеуказанным сетям, и назначим у них шлюзами соответствующие адреса SVI, то между хостами в разных сетях сразу же пойдёт трафик. Но из этих сетей нам также нужно выходить в Интернет и подключаться к внешним сетям, что мы и реализуем далее с помощью PBR (policy-based routing).

Disclaimer

PBR имеет свои пределы применимости, и места для применения, и в этом конкретном случае был выбран в силу того, что его использование даёт возможность пережить полный отказ стека 3850 почти безболезненно. В нашем случае для обеспечения отказоустойчивости внутренней межсетевой маршрутизации, к сожалению, нет второго стека 3850, поэтому в качестве основного, был выбран вариант с PBR, который позволяет:

перенести обработку внутреннего межсетевого трафика на стек 3850, не переделывая схему работы роутеров VyOS с внутренними сетями;
в случае полного отказа стека 3850 возможно перенести обработку внутреннего межсетевого трафика обратно на роутеры VyOS, изменив для этого только их HAIP адреса для vrrp.

Это решение:

может быть применимо только для небольшого количества внутренних сетей, так как ресурсы коммутатора ограниченны и количество строк в PBR имеет свой лимит;
вряд ли имеет смысл использовать, при наличии более чем одного датацентра, из-за overhead'а в ручной настройке политик маршрутизации и сложностей в поиске и устранении ошибок по мере дальнейшего роста сетей.
настраивается только вручную, при этом можно легко выйти за пределы лимитов при росте количества сетей или правил обработки трафика, особенно если слабо контролировать этот процесс;
из-за некорректных настроек, может привести к возникновению асимметричной маршрутизации, особенно в больших сетях.

Используйте его на свой страх и риск, учитывая все эти замечания

Если после прочтения этого disclaimer'а вас всё устраивает, то переходим к реализации межсетевой маршрутизации между внутренними и внешними сетями, настраиваемого с помощью PBR на стеке 3850. Если не устраивает, то можно перейти в конец статьи, к примечанию, и далее настраивать классический вариант маршрутизации с использованием протокола OSPF.

Настраиваем PBR на Cisco 3850, для исходящего трафика к внешним сетям

enable
conf t

ip access-list extended Access_to_External
 permit ip any 0.0.0.0 127.255.255.255
 permit ip any 128.0.0.0 31.255.255.255
 permit ip any 160.0.0.0 7.255.255.255
 permit ip any 168.0.0.0 3.255.255.255
 permit ip any 172.0.0.0 0.15.255.255
 permit ip any 172.16.0.0 0.3.255.255
 permit ip any 172.20.0.0 0.0.0.255
 permit ip any 172.20.2.0 0.0.1.255
 permit ip any 172.20.4.0 0.0.3.255
 permit ip any 172.20.8.0 0.0.7.255
 permit ip any 172.20.16.0 0.0.15.255
 permit ip any 172.20.36.0 0.0.3.255
 permit ip any 172.20.42.0 0.0.1.255
 permit ip any 172.20.44.0 0.0.3.255
 permit ip any 172.20.48.0 0.0.15.255
 permit ip any 172.20.64.0 0.0.63.255
 permit ip any 172.20.128.0 0.0.127.255
 permit ip any 172.21.0.0 0.0.255.255
 permit ip any 172.22.0.0 0.1.255.255
 permit ip any 172.24.0.0 0.7.255.255
 permit ip any 172.32.0.0 0.31.255.255
 permit ip any 172.64.0.0 0.63.255.255
 permit ip any 172.128.0.0 0.127.255.255
 permit ip any 173.0.0.0 0.255.255.255
 permit ip any 174.0.0.0 1.255.255.255
 permit ip any 176.0.0.0 15.255.255.255
 permit ip any 192.0.0.0 31.255.255.255

route-map VLAN17PBR permit 10
 match ip address Access_to_External
 set ip next-hop 172.20.1.1

route-map VLAN32PBR permit 10
 match ip address Access_to_External
 set ip next-hop 172.20.32.1

route-map VLAN34PBR permit 10
 match ip address Access_to_External
 set ip next-hop 172.20.34.1

route-map VLAN35PBR permit 10
 match ip address Access_to_External
 set ip next-hop 172.20.35.1

route-map VLAN40PBR permit 10
 match ip address Access_to_External
 set ip next-hop 172.20.40.1

interface Vlan17
 ip policy route-map VLAN17PBR
 ip route-cache policy

interface Vlan32
 ip policy route-map VLAN32PBR
 ip route-cache policy

interface Vlan34
 ip policy route-map VLAN34PBR
 ip route-cache policy

interface Vlan35
 ip policy route-map VLAN35PBR
 ip route-cache policy

interface Vlan40
 ip policy route-map VLAN40PBR
 ip route-cache policy

exit
wr mem

Как видно, из списка доступа Access_to_External, были исключены внутренние сети:

172.20.1.0/24
172.20.32.0/23 
172.20.34.0/24 
172.20.35.0/24 
172.20.40.0/23

Теперь, если у хостов из вышеуказанных внутренних сетей назначить шлюзами соответствующие адреса SVI, то трафик пойдёт не только между хостами в разных сетях, но и из этих внутренних сетей можно будет выходить в Интернет и подключаться к внешним сетям.

Не забываем, что мы ранее создали пять тестовых ВМ, подключенных ко всем пяти внутренним сетям, и поэтому на них рекомендуется изменить шлюзы по умолчанию на адреса SVI на Cisco 3850, и протестировать прохождение трафика как между самими ВМ, так и выход трафика наружу.

При желании, можно также настроить списки доступа на Cisco 3850, для ограничения прохождения трафика между внутренними сетями, но нужно иметь в виду, что существуют определённые ограничения для количества записей в списках ACL, PBR, QoS и др., которые можно увидеть из следующего вывода:

3850-stack#show platform hardware fed switch active fwd-asic resource tcam utilization
CAM Utilization for ASIC  [0]
 Table                                              Max Values        Used Values
 --------------------------------------------------------------------------------
 Unicast MAC addresses                              32768/512         429/22
 L3 Multicast entries                               4096/512           0/7
 L2 Multicast entries                               4096/512           0/9
 Directly or indirectly connected routes            16384/7168        477/23
 QoS Access Control Entries                         2560                86
 Security Access Control Entries                    3072               133
 Netflow ACEs                                        768                15
 Policy Based Routing ACEs                          1024               134
 Flow SPAN ACEs                                      512                 5
 Output Flow SPAN ACEs                               512                 8
 Control Plane Entries                               512               208
 Tunnels                                             256                17
 Lisp Instance Mapping Entries                       256                 3
 Input Security Associations                         256                 4
 Output Security Associations and Policies           256                 5
 SGT_DGT                                            4096/512           0/1
 CLIENT_LE                                          4096/256           0/0
 INPUT_GROUP_LE                                     6144                 0
 OUTPUT_GROUP_LE                                    6144                 0
 Macsec SPD                                          256                 2

Очень важным моментом является дальнейший мониторинг загрузки процессора и памяти коммутатора L3, т.к. на него возлагается как фильтрация пакетов с помощью ACL применяемых к SVI (опционально), так и обработка PBR, также применяемых к SVI. Полезные команды, которые могут в этом помочь:

sh processes | inc CPU
sh processes cpu sort | exclude 0.00
sh processes cpu history
sh ip route summary
sh memory summary
sh route-map  (число счётчиков пакетов и байтов должно быть ноль, или около него)

В дальнейшей работе не помешает знать, что нужно делать, например, в случае высокой утилизации процессора на коммутаторе, для этого имеется специальный раздел в документации – Troubleshooting TechNotes.

Рекомендуется настроить мониторинг утилизации процессоров, памяти и сетевых интерфейсов стека коммутаторов Cisco 3850, с помощью Zabbix. В Интернете можно без труда найти необходимые для этого шаблоны.

Перевод внутренней межсетевой маршрутизации с VyOS'ов на стек Cisco 3850

В принципе, дойдя до этого места в статье, можно считать нашу задачу практически выполненной, и даже оставить всё как есть, постепенно переведя шлюзы по умолчанию для хостов и ВМ с адресов типа 172.20.х.1 на адреса 172.20.х.2 – этот метод можно использовать, если у нас в наличии сравнительно небольшое количество хостов и виртуальных машин.

Если в сети имеется большое количество ВМ и хостов, то как вариант, можно массово изменить на них адреса шлюзов по умолчанию, используя, например, Ansible, или даже исполняя команды на хостах и ВМ удалённо через ssh.

Но наиболее простым и быстрым способом, является изменение IP адресов на SVI коммутатора Сisco 3850 и HAIP адресов, привязанных к внутренним интерфейсам на роутерах VyOS.

Для перехода на межсетевую маршрутизацию через Сisco 3850, без изменения адресов шлюзов на хостах и ВМ, нужно просто поочередно перенести IP адреса шлюзов сетей VLAN 17, 32, 34, 35, 40 (или 172.20.1.1, 172.20.32.1, 172.20.34.1, 172.20.35.1, 172.20.40.1) с роутеров VyOS на Сisco 3850.
Соответственно, адреса 172.20.1.2, 172.20.32.2, 172.20.34.2, 172.20.35.2, 172.20.40.2 с Сisco 3850 должны быть перенесены на роутеры VyOS.

Как это делается, можно увидеть на примере одной сети – 172.20.1.0/24, или VLAN 17, для этого необходимо лишь последовательно выполнить определённый набор команд на устройствах.

Итак, выполняем перевод IP адреса шлюза 172.20.1.1 с VyOS на Сisco 3850, сеть VLAN17.

Настройка стека 3850

en 
conf t
interface Vlan17
 no ip address 172.20.1.2 255.255.255.0
 no ip route-cache policy
 no ip policy route-map VLAN17PBR
 shut
 exit

 no route-map VLAN17PBR

Настройка роутеров VyOS1/2

configure
 delete high-availability vrrp group haip-1 virtual-address '172.20.1.1/24'
 set high-availability vrrp group haip-1 virtual-address '172.20.1.2/24'
 commit

Настройка стека 3850

route-map VLAN17PBR permit 10
 match ip address Access_to_External
 set ip next-hop 172.20.1.2

interface Vlan17
 ip address 172.20.1.1 255.255.255.0
 ip route-cache policy
 ip policy route-map VLAN17PBR
 no shut
 exit
wr mem

При определенной сноровке, за время выполнения этих трёх действий, пропадёт не более 10-15 пингов с хоста в сети VLAN 17, до шлюза по умолчанию 172.20.1.1, который теперь будет работать на Сisco 3850.

Ровно таким же способом переводим остальные адреса – 172.20.32.2, 172.20.34.2, 172.20.35.2 и 172.20.40.2 с Сisco 3850, на роутеры VyOS. В итоге, получаем обновлённую сетевую схему, в которой вся маршрутизация между внутренними сетями, происходит на специализированном устройстве – Сisco 3850. При этом, как мы видим, практически никаких глобальных изменений в сетевой схеме не произошло – кроме добавления Сisco 3850, на роутерах VyOS изменения делаются минимальные, на хостах и виртуальных машинах вообще ничего не надо делать. Сам переход на обновлённую сетевую схему внутренней маршрутизации, занимает пару-тройку минут, и самое главное, практически без простоя.

Одним из явных преимуществ именно такой схемы с интеграцией стека Сisco 3850 в сетевую инфраструктуру, является то, что при его фатальном отказе, можно всегда перевести внутреннюю маршрутизацию обратно на роутеры VyOS, всего лишь выполнив пару команд на них, как в этом примере для сети 172.20.1.0/24 или VLAN 17:

Настройка VyOS1/2

configure
 delete high-availability vrrp group haip-1 virtual-address '172.20.1.2/24'
 set high-availability vrrp group haip-1 virtual-address '172.20.1.1/24'
 commit

В результате, адреса шлюзов по умолчанию переносятся обратно на роутеры VyOS, внутренние сети в датацентре продолжают работать, а мы спокойно и не спеша разбираемся с отказом Сisco 3850.

Заключение

Цикл из четырёх статей по созданию отказоустойчивой ИТ инфраструктуры небольшого датацентра, практически закончен – нам удалось соединить все элементы в одно целое и получить желаемое, не используя при этом какое-либо коммерческое ПО. Все затраты пришлись только на приобретение оборудования и лицензий на его поддержку. Конечно, коммерческое ПО может быть в чём-то удобнее, функциональней, красивее и быстрее, и главное, иметь при этом поддержку, но тут уже всё зависит от бюджета, выделяемого на проект и требований заказчика.

Например, для этого проекта можно было бы приобрести 4 лицензии (на процессор) для Vmware vSphere Enterprise Plus, одну лицензию Vcenter Server Standard, и 4 лицензии (на процессор) для резервного копирования и репликации виртуальной инфраструктуры – Veeam B&R Enterprise. В связке с оборудованием, у нас получилась бы весьма неплохая, функциональная, гибкая и надёжная платформа виртуализации, но при этом дополнительные затраты без учёта стоимости оборудования, составили бы примерно 44.000 USD за VMware и 10.000 USD за Veeam (цены указаны вместе со стоимостью стандартной годовой поддержки).

Здесь необходимо отметить, что почти за те же самые деньги можно купить вторую СХД с парой серверов, и развернуть их, например, во втором датацентре и получить таким образом уже катастрофоустойчивость нашего решения (не вдаваясь в детали, что для этого ещё может потребоваться).

Безусловно, у каждого может быть своё видение, как проектировать и строить отказоустойчивую IT инфраструктуру для предприятий небольшого размера – в цикле статей был показан лишь один из подходов к этому вопросу, поэтому не надо судить строго. Необходимо лишь отметить, что очень важно совместить желания и возможности, чтобы заказчик мог получить надёжную платформу, с которой можно работать в дальнейшем.

Что касается дальнейшей судьбы проекта по созданию отказоустойчивой IT инфраструктуры, в части относящейся к кластеру oVirt, то у нас имеется как минимум два варианта по организации работы с ним:

классический – это когда администратор по заявке выделяет требуемые ресурсы на кластере виртуализации, создаёт виртуальные машины, устанавливает на них системное ПО и производит их настройки в соответствии с определёнными требованиями;
применение к проекту практик DevOps, относящихся к IaaС (Infrastructure as a Code) – это описание с помощью кода требуемой инфраструктуры, в виде автоматического создания ВМ для БД, узлов для Docker Swarm, веб-серверов, серверов для хранения логов, аналитики и т.п., с последующей их автоматической настройкой и предоставлением ресурсов для команды.

В реальной эксплуатации оба варианта могут конечно же использоваться как вместе, так и по отдельности, но второй вариант является более предпочтительным, так как отвечает современным запросам по организации совместной работы внутри команды и организации поставки цифровых продуктов компании для конечного пользователя. IaaС может и должна применяться в постоянно меняющихся условиях, для оптимизации и ускорения путей доставки цифровых продуктов, с целью увеличения прибыли компании.

oVirt/RHEV в полной мере поддерживает IaaС, для чего имеется соответствующий провайдер для Terraform, а также модуль для Ansible.
Если есть необходимость развёртывания ОС с нуля из установочного образа, например, для его дальнейшего использования в Terraform или Ansible, то можно использовать Cobbler, для автоматизации установки ОС по сети.

В дальнейшем планируется появление небольших дополнений к статьям о создании отказоустойчивой IT инфраструктуры, связанных, например, с внедрением мониторинга каких-то элементов инфраструктуры, или организацией их резервного копирования и т.п.

Помимо этого, возможно, будет выпущен новый цикл статей с уклоном в сторону DevOps, в части касающейся IaaС, где в качестве базовой платформы будет использоваться отказоустойчивый кластер oVirt и/или VMware vSphere.

P.S.
Если имеются какие-то замечания, предложения или уточнения по статьям, то добро пожаловать в комментарии.

Примечание

Исходя из обсуждений в комментариях, для тех, кто не хочет / не может использовать PBR на Cisco 3850 для роутинга внутренних сетей наружу (т.н. source-based маршрутизацию), предлагается использовать "классический" вариант настройки роутинга, на основе destination-based маршрутизации.

Про этот вариант в статье уже упоминалось, но без особых подробностей, и если его будете настраивать, то нужно иметь в виду следующее:

для его реализации придётся перенастраивать схему работы VyOS с внутренними сетями;
полный отказ стека Cisco 3850 отразится гораздо больнее на работе сети, чем если бы использовался PBR.

Организация маршрутизации между внутренними и внешними сетями с использованием OSPF

Схема межсетевого взаимодействия

Настройка Cisco 3850

Справочная информация – Chapter: Configuring IP Unicast Routing

Если ранее были сделаны настройки для работы коммутатора с PBR, то:

удаляем привязку route-map'ов с интерфейсов: VLAN17, VLAN32, VLAN34, VLAN35, VLAN40
удаляем route-map'ы: VLAN17PBR, VLAN32PBR, VLAN34PBR, VLAN35PBR, VLAN40PBR
удаляем access-list Access_to_External
для взаимодействия с роутерами VyOS по протоколу OSPF, настраиваем новый интерфейс VLAN33, чтобы обеспечить связь внутренних сетей с внешними.

Конфигурация Cisco 3850

interface Vlan33
 ip address 172.20.133.1 255.255.255.0
 ip ospf dead-interval 4
 ip ospf hello-interval 1
 ip ospf priority 100

interface Loopback0
 ip address 10.1.1.3 255.255.255.255

router ospf 1
 router-id 10.1.1.3
 network 10.1.1.3 255.255.255.255 area 0.0.0.0
 network 172.20.133.0 0.0.0.255 area 0.0.0.0
 network 172.20.1.0 0.0.0.255 area 0.0.0.0
 network 172.20.32.0 0.0.1.255 area 0.0.0.0
 network 172.20.34.0 0.0.0.255 area 0.0.0.0
 network 172.20.35.0 0.0.0.255 area 0.0.0.0
 network 172.20.40.0 0.0.1.255 area 0.0.0.0
 log-adjacency-changes
 passive-interface default
 no passive-interface Vlan33

Настройка маршрутизаторов VyOS

Справочная информация — Настройка OSPF на VyOS

Если на роутерах ранее были сделаны настройки для работы с Cisco 3850 на котором был настроен PBR, то:

удаляем настройку vrrp для всех интерфейсов;
удаляем балансировку нагрузки для выхода в Интернет, с сетевых интерфейсов VLAN32, VLAN34, VLAN35, VLAN40;
удаляем адреса с интерфейсов: VLAN17, VLAN32, VLAN34, VLAN35, VLAN40;
отключаем эти интерфейсы в настройках виртуальной машины через административный портал oVirt;
для взаимодействия с Cisco 3850 по протоколу OSPF, настраиваем интерфейс eth0, подключенный к сети с идентификатором VLAN33, чтобы обеспечить связь внутренних сетей с внешними.