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

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


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

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

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

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

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


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

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

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

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

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


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

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

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

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


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


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


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


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

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

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

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

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


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

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

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

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

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

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 никак при этом не меняется, если это имеет значение.

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

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
Видно сетевика — нет и всё :)
ну тоесть, мнение профессионала для вас не авторитет? «Мы пойдем другим путем». Я вот тоже сетевик с глубоким в это погружением и подпишусь под словами
Вы используете pbr там где он не нужен и более того вреден. И не важно какое вы для этого находите объяснение.
. Вы совершенно не понимаете что такое PBR, для чего он нужен и как его использовать. Более того, использование PBR и всяких TE в вашем случае категорически противоречит анонсируемой вами же «Отказоустойчивости».

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


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

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

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.

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

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


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


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


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

Это решение:


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

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

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

но едет же ;))


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


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

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

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

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

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

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


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

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

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

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

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


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

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

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


3850-stack#sh platform tcam utilization
                       ^
% Invalid input detected at '^' marker.

3850-stack#
Третий 3850 купите/возьмите с волшебной полочки. Лично наблюдал, как один элемент такого стека мрет — приятного мало.
Заскриптуйте и проверьте операции, позволяющие безболезненно выводить из эксплуатации каждый из узлов — будет отличный материал для следующей статьи.

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


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


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

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

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


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

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

 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
Имхо, не надо было городить огород 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-ресурсов стека.

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


  • 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 those users with full accounts are able to leave comments. Log in, please.
Information
Location

Россия

Employees

51–100 employees

Registered

5 December 2019