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

  • 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 (можно более свежую):


  1. test-IM34 – 1 Gb RAM, 1 CPU, 10 Gb HDD
    • VLAN34, IP – 172.20.34.239/24, Gateway – 172.20.34.1
  2. 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 через консольный порт и выполнение начальной настройки.


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



Подключиться к консольному порту коммутатора можно через специальные 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, чтобы обеспечить связь внутренних сетей с внешними.

Настройка VyOS1
set interfaces loopback lo address '10.1.1.1/32'

set interfaces ethernet eth0 address '172.20.133.253/24'
set interfaces ethernet eth0 description 'VLAN33'
set interfaces ethernet eth0 ip ospf dead-interval '4'
set interfaces ethernet eth0 ip ospf hello-interval '1'
set interfaces ethernet eth0 ip ospf priority '1'
set interfaces ethernet eth0 ip ospf retransmit-interval '5'
set interfaces ethernet eth0 ip ospf transmit-delay '1'

set protocols ospf area 0.0.0.0 network '172.20.133.0/24'
set protocols ospf area 0.0.0.0 network '10.1.1.1/32'
set protocols ospf default-information originate metric '10'
set protocols ospf default-information originate metric-type '2'
set protocols ospf log-adjacency-changes
set protocols ospf neighbor 172.20.133.1 poll-interval '5'
set protocols ospf neighbor 172.20.133.1 priority '1'
set protocols ospf parameters abr-type 'cisco'
set protocols ospf parameters router-id '10.1.1.1'
set protocols ospf passive-interface 'default'
set protocols ospf passive-interface-exclude 'eth0'
set protocols ospf redistribute static metric '5'
set protocols ospf redistribute static metric-type '2'

Настройка VyOS2
set interfaces loopback lo address '10.1.1.2/32'

set interfaces ethernet eth0 address '172.20.133.254/24'
set interfaces ethernet eth0 description 'VLAN33'
set interfaces ethernet eth0 ip ospf dead-interval '4'
set interfaces ethernet eth0 ip ospf hello-interval '1'
set interfaces ethernet eth0 ip ospf priority '1'
set interfaces ethernet eth0 ip ospf retransmit-interval '5'
set interfaces ethernet eth0 ip ospf transmit-delay '1'

set protocols ospf area 0.0.0.0 network '172.20.133.0/24'
set protocols ospf area 0.0.0.0 network '10.1.1.2/32'
set protocols ospf default-information originate metric '20'
set protocols ospf default-information originate metric-type '2'
set protocols ospf log-adjacency-changes
set protocols ospf neighbor 172.20.133.1 poll-interval '5'
set protocols ospf neighbor 172.20.133.1 priority '1'
set protocols ospf parameters abr-type 'cisco'
set protocols ospf parameters router-id '10.1.1.2'
set protocols ospf passive-interface 'default'
set protocols ospf passive-interface-exclude 'eth0'
set protocols ospf redistribute static metric '10'
set protocols ospf redistribute static metric-type '1'

Для проверки результатов работы протокола OSPF, можно использовать эти команды:


sh ip ospf interface
sh ip ospf neighbor
show ip ospf
show ip route
show ip route ospf
Lenvendo
Разработка и техподдержка онлайн-проектов

Comments 46

    0
    Так упорно делаете акцент на Cisco 2960RХ, интересно а знаете чем отличается от Cisco 2960Х?
    Ну и конечно умиляет «были найдены две коробки с коммутаторами Cisco 3850» ;-)
      0

      Если так интересно в чем отличия, то можете сами почитать
      В статье использовалась конкретная модель — Cisco WS-C2960RX-48FPS-L


      Умиляет конечно — у завхоза (а особенно у каптёра (кто знает, тот поймёт)) можно ещё и не то найти :))

        0
        Вы указали ссылку, по которой ни слова именно об этой модели. Это только подтверждает, что вы не знаете ответ.
          0

          Base ethernet MAC Address: 0C:D0:F8:E4:5B:XX
          Motherboard assembly number: 73-16691-07
          Power supply part number: 341-0527-03
          Motherboard serial number: FOC22374XXX
          Power supply serial number: DCB22316XXX
          Model revision number: A0
          Motherboard revision number: A0
          Model number: WS-C2960RX-48FPS-L
          Daughterboard assembly number: 73-14200-03
          Daughterboard serial number: FOC22412XXX
          System serial number: JTV23031XXX
          Top Assembly Part Number: 68-5898-04
          Top Assembly Revision Number: A0
          Version ID: V04
          Daughterboard revision number: B0
          Hardware Board Revision Number


          Switch 02

          Switch Uptime: 34 weeks, 9 hours, 7 minutes
          Base ethernet MAC Address: 00:29:C2:51:1XX:XX
          Motherboard assembly number: 73-16691-07
          Power supply part number: 341-0527-03
          Motherboard serial number: FOC22452XXX
          Power supply serial number: DCB22316XXX
          Model revision number: A0
          Motherboard revision number: A0
          Model number: WS-C2960RX-48FPS-L
          Daughterboard assembly number: 73-14200-03
          Daughterboard serial number: FOC22510XXX
          System serial number: JTV23051XXX
          Top assembly part number: 68-5898-04
          Top assembly revision number: A0
          Version ID: V04
          Daughterboard revision number: B0

            0
            Не понимаю к чему ссылки невпопад или листинги с оборудования.
            Вопрос был простой: знаете ли вы чем отличается Cisco 2960RХ от Cisco 2960Х.
            Ответ такой же простой: RX означает собран в/для России, не путать с XR.
              0

              Спасибо!
              Конечно же WS-C2960RX-48FPS-L = WS-C2960X-48FPS-L
              Главное, что эта модель позволяет создавать стек, что требовалось в рамках задачи.


              Ещё такой момент есть — на него устанавливается фиксированная лицензия LAN Base, которую нельзя сменить.

              +1

              R — это произведено в РФ. Больше отличий нет (кроме цены).

                0

                ага
                WS-C2960RX-48FPS-L = WS-C2960X-48FPS-L

        +2
        Включить pbr на 3850 это возможно худшее что вы могли сделать.

        Странно, что поменять на всех хостах gateway проще, чем пару секундный простой.
          0

          А в чём проблема с pbr?

            0
            Я наверно слишком старый и для меня pbr это однозначное ухудшение перформанса, увеличение потребления cpu. Ну и рутинг должен строится от назначения а не от источника…

            в данном случае это ещё повлечёт за собой редиректы?
            плюс читаемость конфига ухудшается что влечёт к проблемам
              0

              В плане потребления cpu это теперь не так, практически никакой разницы в утилизации процессора до включения pbr и после не заметно.
              Еслии включить ещё acl для трафика, может что и подрастёт, но не проверял.


              Хотя в своё время, помню, были проблемы — на cisco 3560 сталкивался с увеличением утилизации cpu

                0

                PBR в данном случае используется в силу своей большей гибкости, по сравнению с традиционным destination routing, так как позволяет настроить практически любые пути прохождения трафика от источника к назначению — по адресу источника или назначения, по сети источника или назначения, по протоколу, по порту и т.п. Также можно включить QoS для такого трафика. Сейчас конечно все эти возможности не используются по полной, но в будущем кто знает.

                  0
                  Вы используете pbr там где он не нужен и более того вреден. И не важно какое вы для этого находите объяснение.

                    0

                    Видно сетевика — нет и всё :)


                    В своё время и виртуализация считалась чем-то противоестественным (только одна железка на один веб-сервер и никак иначе), да и докер поначалу только разрабами использовался :)


                    В официальной документации никаких противопоказаний к такому использованию PBR нет


                    PBR применяется примерно в таком же виде года этак с 2013 (на 3560, 3750...), но видимо из вредности и ненужности работает на них до сих пор (там правда имеется ещё куча всяких политик, но это как раз и есть работа для PBR).


                    В статье было отдельно отмечено, что ещё имеется вариант с настройкой обычной маршрутизации между 3850 и VyOS — можно, конечно, рассмотреть и такую настройку. Альтернатива (тем более с т.з классической маршрутизации) — это всегда хорошо :)

                      0
                      причём тут виртуализация?

                      то что у вас pbr работает где то там с 2013 года не делает эту конфигурацию корректной и правильной.

                      Такие костыли имеют свойства ломаться в самый неподходящий момент и поиск проблем может занять достаточное время
                        0

                        Виртуализация просто как пример, когда что-то новое стало повседневной практикой.


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

                          0
                          Только я pbr настраивал ещё лет так 20 назад. Ничего нового здесь нет.

                          мне вот интересно, что произойдет при «no ip redirects» на интерфейсе.

                            0
                            мне вот интересно, что произойдет при «no ip redirects» на интерфейсе.

                            Завтра уже узнаем

                              0

                              20 лет назад CEF поддерживали только старшие модели, и по всей видимости на основной массе устройств обработка PBR действительно делалась на процессоре.


                              При выключенном ip redirects:


                              sh run int Vlan34
                              Building configuration...
                              
                              Current configuration : 133 bytes
                              !
                              interface Vlan34
                               ip address 172.20.34.2 255.255.255.0
                               no ip redirects
                               ip route-cache policy
                               ip policy route-map VLAN34PBR
                              end

                              Хост в сети VLAN34 видит все хосты во внутренних сетях VLAN 17,32,35,40 и наоборот, а также выходит наружу в Интернет.
                              Загрузка процессора 3850 никак при этом не меняется, если это имеет значение.

                                0
                                насколько я помню cef поддерживался на всех моделях… точно на всех с которыми я работал.
                                cef к pbr не имеет вообще ни какого отношения. Более того cef это как раз про destination switching.
                                Если вы про cef switched pbr то вы его отключили командой ip route-cache policy.
                                  0

                                  cef включен глобально — The default configuration is CEF or dCEF enabled on all Layer 3 interfaces.


                                  Что касается SVI, то например:


                                  3850-stack#   show cef interface vlan35
                                  Vlan35 is up (if_number 79)
                                    Corresponding hwidb fast_if_number 79
                                    Corresponding hwidb firstsw->if_number 79
                                    Internet address is 172.20.35.2/24
                                    ICMP redirects are always sent
                                    IP unicast RPF check is disabled
                                    Input features: Policy Routing
                                    IP policy routing is enabled
                                    IP policy route map is VLAN35PBR
                                    BGP based policy accounting on input is disabled
                                    BGP based policy accounting on output is disabled
                                    Hardware idb is Vlan35
                                    Fast switching type 1, interface type 156
                                    IP CEF switching enabled
                                    IP CEF switching turbo vector
                                    IP Null turbo vector
                                    IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
                                    Input fast flags 0x2, Output fast flags 0x0
                                    ifindex 78(78)
                                    Slot 0 (0) Slot unit 35 VC -1
                                    IP MTU 1500
                          0
                          Видно сетевика — нет и всё :)
                          ну тоесть, мнение профессионала для вас не авторитет? «Мы пойдем другим путем». Я вот тоже сетевик с глубоким в это погружением и подпишусь под словами
                          Вы используете pbr там где он не нужен и более того вреден. И не важно какое вы для этого находите объяснение.
                          . Вы совершенно не понимаете что такое PBR, для чего он нужен и как его использовать. Более того, использование PBR и всяких TE в вашем случае категорически противоречит анонсируемой вами же «Отказоустойчивости».
                            0

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


                            В чём именно противоречие?

                              0
                              Покажите мне в CCDx место, где хоть намеком сказано что данные задачи решаются с помощью PBR? CCDx в данном случае как раз то самое «официальное руководство».
                                0

                                CCDx имеется в виду Сisco Сertified Design ..., правильно понимаю?


                                Согласно "Designing for Cisco Network Service Architectures (ARCH) Foundation Learning Guide, Fourth Edition", задачи внутренней маршрутизации решаются с помощью протоколов OSPF или EIGRP. Про PBR в этом руководстве есть упоминание, но только применительно к Cisco ASA.


                                С 2020 года сертификация CCDP заменена на CCNP Enterprise, в рамках которой есть экзамен 300-420 ENSLD и курс Designing Cisco Enterprise Networks (ENSLD).
                                Этот курс относится к дизайну, но к нему доступа нет, и что там пишут теперь про PBR не знаю.


                                Что касается PBR, то при написании статьи использовалось руководство Routing Configuration Guide, Cisco IOS XE Everest 16.6.x (Catalyst 3850 Switches), в котором никаких явных противопоказаний для использования PBR во внутренних сетях, для организации их маршрутизации наружу нет.


                                • You can use policy-based routing (PBR) to configure a defined policy for traffic flows.
                                • By using PBR, you can have more control over routing by reducing the reliance on routes derived from routing protocols.
                                • You can use PBR to provide equal-access and source-sensitive routing, routing based on interactive versus batch traffic, or routing based on dedicated links.

                                Про риски PBR написано в коментах уже достаточно, наиболее интересный комментарий был от bukoka, на него приведён развёрнутый ответ — почему все-таки выбран был не IGP или статика, а именно PBR. Чтобы уж совсем не отходить от канонов, статья была обновлена, и в её конце приведён пример с настройкой OSPF между 3850 и виосами вместо использования PBR.

                                  0
                                  Сisco Сertified Design да, там же отлично описывается (правда размазано по многим томам) для чего используется PBR. Если в кратце «PBR нужен для манипуляций с трафиком отличных от поведения по-умолчанию». Тоесть, того что предоставляет IGP. Плюс там есть множество кейсов когда применяется PBR. Вы же утверждаете
                                  Авторитетом при написании статьи являлось официальное руководство
                                  и затем
                                  в котором никаких явных противопоказаний для использования PBR
                                  это знаете ли мненого разные вещи. Точнее совсем разные вещи. Там явных противопоказаний против убийства людей тоже нет. Вы же не идете их убивать? Руководствуетесь Законом и Здравым смыслом. Так вот, Закон в нашем случае это учебники по циско дизайн, а здравый смысл это осознание того что PBR предназначена совершенно других задач, вы городите жуткий неюзабельный костыль и преподносите это как некий гайд. Нет, так не надо. И да, вопрос для обдумывания, почему PBR в сколько нибудь больших сетях это очень вредно с точки зрения TSHOOT?
                                    0

                                    никто человеков убивать не собирается, здесь немного другая философия — что не запрещено, то разрешено :))


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


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


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

                                    Это решение:


                                    • может быть применимо только для небольшого количества внутренних сетей, так как ресурсы коммутатора ограниченны и количество строк в PBR имеет свой лимит;
                                    • вряд ли имеет смысл его использовать при наличии более чем одного датацентра (ну как датацентра — одной-двух стоек), из-за оверхеда в ручной настройке политик маршрутизации и сложностей в поиске и устранении ошибок по мере дальнейшего роста сетей.

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

                                      0
                                      Знаете как выглядет в вашем случае «альтернатива».
                                      «Вот есть автомобиль, его покрышки нужно накачивать воздухом, но можно и водой чем мы сейчас с вами и займемся». Да, технически можно, но поедет он соответственно. Плохо и не очень далеко. Напомню название статей «Построение отказоустойчивого бла бла», а не «Эксперименты на тему, а что было бы если...»
                                      в том, что его настройка это сугубо ручной процесс и можно легко выйти за пределы лимитов
                                      Это не тишут. Проблема PBR в области тишута в том, что поведение трафика совершенно не очевидно и время этого самого тишута вырастает в разы. вместо ip route вам приходится смотреть в куче мест с какими роут-мэп и какими ACL матчится тот или иной вид трафика.
                                      может быть применимо только для небольшого количества внутренних сетей
                                      Извините, но эта картинка подходит сюда идеально image
                                        0

                                        но едет же ;))


                                        про tshoot и работу с ip route — ну, это очевидно, что настройки pbr в её выводе никак не увидеть :) и поэтому таки да, придётся читать и списки acl и роут-мапы


                                        ок, в любом случае спасибо всем комментаторам, по результатам обсуждения немного подправил статью, и добавил вариант с настройкой OSPF между 3850 и виосами, а также дисклеймер про использование PBR.

                      0
                      Все верно вам сказали. pbr это костыль, которого лучше избегать.
                      Из своего опыта неоднократно убеждался, разбирая чужие конфиги, как грузит pcu под 100%. Не забывайте коммутатор, всегда останется коммутатором, хоть и третьего уровня.
                        0

                        Загрузка под 100% бывает только или из-за неправильной конфигурации pbr, или из-за несоблюдения лимитов — если всё настроено корректно, то такого не будет.

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

                  Вместо того, что бы сделать Правильно, средствами которые для этого предназначены, предлагается кривой костыль. Напомните мне, на платформе 38 deny в PBR при (set ip next-hop) тоже обрабатываются софтово, как на 3750 например? Вторая статья из разряда Как ни в коем случае НЕ надо делать.
                    0

                    Где в конфиге pbr написано про deny???
                    Про его обработку в 3750 известно, и поэтому deny никогда не используется.


                    Вторая статья из разряда Как ни в коем случае НЕ надо делать.

                    Не делайте
                    Про классический вариант маршрутизации между 3850 и виос добавлю позже.

                      0
                      Про классический вариант маршрутизации между 3850 и виос добавлю позже.

                      Я может действительно ничего не понимаю но в чем сакральный смысл писать статью с заведомо кривым, костыльным решением, к тому же под заголовком «построение отказоустойчивого бла бла».
                      и поэтому deny никогда не используется.
                      используется. Возможно просто вы про это не знаете. Там в конце acl implicit deny и если вам вдруг (а это весьма распространенная задача) понадобится «выкусить» из этого кривого TE кусочек трафика и направить по другим правилам, то тут у вас обработка и ляжет на плечи хиленького процессора коммутатора. А вместе с ним ляжет и весь CP. Ещё раз: не только я один вам сказал, ваше решение очень кривое, с помощью средств которые созданы совершенно для другого. Содержание статьи полностью не соответствует заголовку.
                        0

                        Сбой одного из коммутаторов 2960 или 3850 сеть выдержит? Да.
                        Сбой одного из роутеров VyOS выдержит? Да.
                        Полный отказ 3850 сеть выдержит? Да, если переконфигурировать haip для vrrp на VyOS. Можно даже это поведение заскриптовать на VyOS, или на управляющей машине в сети.


                        Ещё раз повторю, что явный deny в pbr никогда не использую.

                  0

                  А могли бы вы подсказать, что на этой модели покажет
                  show platform tcam utilization
                  ?

                    0

                    Для устройства нет такой команды, в статье имеется вывод другой команды — show platform hardware...
                    Она показывает чего и сколько используется, и сколько ещё имеется ресурсов.


                    3850-stack#sh platform tcam utilization
                                           ^
                    % Invalid input detected at '^' marker.
                    
                    3850-stack#
                    +1
                    Третий 3850 купите/возьмите с волшебной полочки. Лично наблюдал, как один элемент такого стека мрет — приятного мало.
                    Заскриптуйте и проверьте операции, позволяющие безболезненно выводить из эксплуатации каждый из узлов — будет отличный материал для следующей статьи.
                      0

                      Третий коммутатор, кстати, в планах как зип :)


                      Если будут серьёзные проблемы со стеком, можно его просто выключить — кратковременное отсутствие сильно не повлияет на работу сети, пока работают виосы.


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

                      +1

                      Извините, но 1гиг сеть(на 29 каталистах) и термин датацентр как то не вяжуться между собой. Серверная было бы показательнее.
                      А так да, PBR в небольших серверных это наше все).

                        0

                        Таки да, для кого-то и системный блок — это один большой процессор :))
                        Но что имеем, то и имеем :(
                        Ну какая серверная — это всего одна стойка по железу, даже половина.
                        Зато название звучит :)


                        А так да, PBR в небольших серверных это наше все).

                        Во, и я о том же :))

                        +1
                         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.2 255.255.255.0
                         ip route-cache policy
                         ip policy route-map VLAN17PBR
                         no shut
                         exit
                        wr mem 


                        Тут маленькая ошибка
                        interface Vlan17
                        ip address 172.20.1.1 255.255.255.0

                        Это в конце последняя настройка Cisco 3850
                          0

                          Спасибо! Действительно ошибся

                          0
                          Имхо, не надо было городить огород c PBR, никакой выгоды по сравнению со стандартным решением, которое Вы же и описывали, я не увидел. Но это снизило бы стоимость эффортов по будущему обслуживанию и понимаю того, что происходит в сети — что-то типа Keep It Stupid, Simple. Кроме того — PBR все же затратная тема для такого low-level свитча.

                          Все равно это временное решение — ни DCI, ни фаерволов в DMZ, никакой сложной работы с трафиком на данном этапе развития «ЦОД» нету — Вы излишне морочите голову, аргументируя простоем.

                          На мой неискушенный взгляд — надо было сделать одну сеть между VyOS с VRRP и прописать на VIP дефолтный статический маршрут (ну и с VyOS вместо пачки статиков — саггрегировать в один условный статик с /16 в сторону 3850). Мигрировать плавно (без простоя) на это решение гораздо проще, чем переделывать все потом (если конечно понимать как работает маршрутизация — что Connected-маршрут предпочтительней, чем статик, и правило more specific mask).

                          За LACP — плюсую, правильное решение, но следует обратить внимание на отказоустойчивость Вашей схемы в сценарии отказа StackWise или по простому Split-brain, когда свитчи разъедутся из стека.

                          P.S:
                          Access-list Access_to_External пишется буквально в несколько строчек:

                          deny ip any <внутренние сети, которые у вас на SVI>
                          в конце
                          permit ip any any

                          P.P.S:
                          Простите за излишнюю прямоту, но вот после такой извращенной логики хождения трафика — хочется придушить предыдущего сетевого админа — обычно он уходит, когда потоки продового трафика уже довольно большие, и тебе приходится срочно что-то выдумывать, чтобы на продовой системе плавно мигрировать к нормальной (читай простой) архитектуре для такого решения, так как эта схема не масштабируема в части TCAM-ресурсов стека.
                            0

                            Ну вот смотрите, какое уже получается разнообразие возможностей и вариантов:


                            • PBR, которое было предложено использовать в качестве основы для маршрутизации внутренних сетей наружу
                            • в конце статьи добавил вариант с настройкой OSPF между 3850 и виосами
                            • вы предложили статику с 3850 на HAIP на виосах, что потребует только одной строчки в конфиге на 3850 и пары строчек конфига на виосах — прямо хокку :)
                            • кто-то скажет что RIP здесь вообще самое то :)

                            Разнообразие — это хорошо, выбирай что пригодится или что считаешь нужным и правильным :)


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


                            Наверное, основная проблема статьи в том, что надо было предлагать PBR в качестве дополнительного решения, который может быть полезен в зависимости от потребностей, а не делать его основным вариантом, но что сделано, то сделано, по крайней мере вариант с классической destination-based маршрутизацией предложен тоже :)


                            Далее немного пройдусь по любимому PBR.


                            Access-list Access_to_External пишется буквально в несколько строчек:

                            deny ip any <внутренние сети, которые у вас на SVI>
                            в конце
                            permit ip any any

                            Знаете, в своё время пришлось на 3650 и 3750 споткнуться на "Do not match ACLs with deny ACEs" — после этого, хотя для 3850 уже и нет такого ограничения, но уже по привычке делается ACL без явного указания в нём deny.


                            Теперь про ресурсы TCAM, в статье приведен вывод команды show platform hardware fed switch active fwd-asic resource tcam utilization
                            Не буду приводить его в этом комменте, просто отмечу, что в принципе да, истощение ресурсов можно получить, если планируется неконтроллируемый рост числа сетей, но прямо сейчас до этого ещё очень далеко. Это уже дело админа контролировать ресурсы, подсказки как это делать в статье есть. Хочу ещё отметить, что в данном случае количество сетей дальше расти не планируется, хотя направления потоков трафика меняться могут, но здесь всё пока под контролем.


                            Основная причина использования PBR, как бы это ни прозвучало — это его простота и понятность работы на данной конкретной схеме сети. И ещё преимущество его в том, что мы в любой момент можем исключить стек 3850 из схемы вообще, если с ним что-то будет не так, да даже если просто потребуется обновить на нём ПО, например.


                            Здесь подходим к другому вопросу, вы написали:


                            За LACP — плюсую, правильное решение, но следует обратить внимание на отказоустойчивость Вашей схемы в сценарии отказа StackWise или по простому Split-brain, когда свитчи разъедутся из стека.

                            К сожалению, сейчас нет возможности промоделировать сбой одного из коммутаторов в стеке 2960RX или 3850. Если есть какие-то предложения по повышению отказоустойчивости в таких ситуациях, то просьба прокомментировать этот момент подробнее, добавлю информацию о методах противодействия этому в статью. Опять же про вариант с PBR — он может позволить практически не обращать внимания на потерю 3850, но вот про стек 2960RX этого уже не скажешь. Хотя хосты и подключены к нему через Etherchannel, но split-brain здесь конечно может быть катастрофой.

                          Only users with full accounts can post comments. Log in, please.