Comments 46
Ну и конечно умиляет «были найдены две коробки с коммутаторами 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
Странно, что поменять на всех хостах gateway проще, чем пару секундный простой.
А в чём проблема с pbr?
в данном случае это ещё повлечёт за собой редиректы?
плюс читаемость конфига ухудшается что влечёт к проблемам
В плане потребления cpu это теперь не так, практически никакой разницы в утилизации процессора до включения pbr и после не заметно.
Еслии включить ещё acl для трафика, может что и подрастёт, но не проверял.
Хотя в своё время, помню, были проблемы — на cisco 3560 сталкивался с увеличением утилизации cpu
PBR в данном случае используется в силу своей большей гибкости, по сравнению с традиционным destination routing, так как позволяет настроить практически любые пути прохождения трафика от источника к назначению — по адресу источника или назначения, по сети источника или назначения, по протоколу, по порту и т.п. Также можно включить QoS для такого трафика. Сейчас конечно все эти возможности не используются по полной, но в будущем кто знает.
Видно сетевика — нет и всё :)
В своё время и виртуализация считалась чем-то противоестественным (только одна железка на один веб-сервер и никак иначе), да и докер поначалу только разрабами использовался :)
В официальной документации никаких противопоказаний к такому использованию PBR нет
PBR применяется примерно в таком же виде года этак с 2013 (на 3560, 3750...), но видимо из вредности и ненужности работает на них до сих пор (там правда имеется ещё куча всяких политик, но это как раз и есть работа для PBR).
В статье было отдельно отмечено, что ещё имеется вариант с настройкой обычной маршрутизации между 3850 и VyOS — можно, конечно, рассмотреть и такую настройку. Альтернатива (тем более с т.з классической маршрутизации) — это всегда хорошо :)
то что у вас pbr работает где то там с 2013 года не делает эту конфигурацию корректной и правильной.
Такие костыли имеют свойства ломаться в самый неподходящий момент и поиск проблем может занять достаточное время
Виртуализация просто как пример, когда что-то новое стало повседневной практикой.
В pbr нечему ломаться, если только специально конфиг кривой не применять. Такое может быть и с любым протоколом маршрутизации, если что-то настроить не так.
мне вот интересно, что произойдет при «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 к 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 имеется в виду С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.
Авторитетом при написании статьи являлось официальное руководствои затем
в котором никаких явных противопоказаний для использования PBRэто знаете ли мненого разные вещи. Точнее совсем разные вещи. Там явных противопоказаний против убийства людей тоже нет. Вы же не идете их убивать? Руководствуетесь Законом и Здравым смыслом. Так вот, Закон в нашем случае это учебники по циско дизайн, а здравый смысл это осознание того что PBR предназначена совершенно других задач, вы городите жуткий неюзабельный костыль и преподносите это как некий гайд. Нет, так не надо. И да, вопрос для обдумывания, почему PBR в сколько нибудь больших сетях это очень вредно с точки зрения TSHOOT?
никто человеков убивать не собирается, здесь немного другая философия — что не запрещено, то разрешено :))
Конечно же никто в здравом уме не будет масштабировать PBR на несколько датацентров, или использовать его для разруливания трафика между многими сотнями или даже несколькими десятками сетей — цель статьи была не в этом точно, а чтобы показать альтернативу по сравнению с традиционным подходом с использованием IGP, если имеются ограниченные аппаратные ресурсы по обеспечению отказоустойчивости сети. Если этот подход выбивается из того, что рекомендует вендор, то тут уже дело каждого — или использовать традиционный подход, или принимать на себя риски, делая по своему.
Всё верно, что PBR имеет как свои пределы применимости, так и места для применения, и в этом конкретном случае был выбран в силу того, что его использование даёт возможность пережить полный отказ стека 3850 почти безболезненно. Да, естественно, что имеются другие способы этого достичь, но в нашем случае для обеспечения отказоустойчивости внутренней межсетевой маршрутизации, к сожалению, нет второго стека 3850, поэтому выбран вариант с PBR, который позволяет:
- перенести обработку внутреннего межсетевого трафика на 3850, не переделывая схему работы виосов с внутренними сетями;
- в случае полного отказа 3850 возможно перенести обработку внутреннего межсетевого трафика обратно на виосы, изменив для этого только их адреса vrrp.
Это решение:
- может быть применимо только для небольшого количества внутренних сетей, так как ресурсы коммутатора ограниченны и количество строк в PBR имеет свой лимит;
- вряд ли имеет смысл его использовать при наличии более чем одного датацентра (ну как датацентра — одной-двух стоек), из-за оверхеда в ручной настройке политик маршрутизации и сложностей в поиске и устранении ошибок по мере дальнейшего роста сетей.
Что касается траблшутинга — помимо того, что основной риск при использовании PBR в том, что его настройка это сугубо ручной процесс и можно легко выйти за пределы лимитов при росте количества сетей или правил обработки трафика, ещё имеется вероятность возникновения асимметричной маршрутизации, особенно в больших сетях.
«Вот есть автомобиль, его покрышки нужно накачивать воздухом, но можно и водой чем мы сейчас с вами и займемся». Да, технически можно, но поедет он соответственно. Плохо и не очень далеко. Напомню название статей «Построение отказоустойчивого бла бла», а не «Эксперименты на тему, а что было бы если...»
в том, что его настройка это сугубо ручной процесс и можно легко выйти за пределы лимитовЭто не тишут. Проблема PBR в области тишута в том, что поведение трафика совершенно не очевидно и время этого самого тишута вырастает в разы. вместо ip route вам приходится смотреть в куче мест с какими роут-мэп и какими ACL матчится тот или иной вид трафика.
может быть применимо только для небольшого количества внутренних сетейИзвините, но эта картинка подходит сюда идеально
но едет же ;))
про tshoot и работу с ip route — ну, это очевидно, что настройки pbr в её выводе никак не увидеть :) и поэтому таки да, придётся читать и списки acl и роут-мапы
ок, в любом случае спасибо всем комментаторам, по результатам обсуждения немного подправил статью, и добавил вариант с настройкой OSPF между 3850 и виосами, а также дисклеймер про использование PBR.
Из своего опыта неоднократно убеждался, разбирая чужие конфиги, как грузит pcu под 100%. Не забывайте коммутатор, всегда останется коммутатором, хоть и третьего уровня.
В целом этот вариант не слишком удобен, так как предполагает перерыв в работе внутренних сетей из-за изменения конфигурации на 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
?
Заскриптуйте и проверьте операции, позволяющие безболезненно выводить из эксплуатации каждый из узлов — будет отличный материал для следующей статьи.
Третий коммутатор, кстати, в планах как зип :)
Если будут серьёзные проблемы со стеком, можно его просто выключить — кратковременное отсутствие сильно не повлияет на работу сети, пока работают виосы.
Про скрипты спасибо, но к сожалению все 3850 уже заняты, тренироваться не на ком :(
А так да, было бы здорово показать, что происходит при поломке стека, или одного из коммутаторов в нём и что делать при этом, но увы, пока нет такой возможности смоделировать это на живом железе.
Извините, но 1гиг сеть(на 29 каталистах) и термин датацентр как то не вяжуться между собой. Серверная было бы показательнее.
А так да, 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
Все равно это временное решение — ни 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 здесь конечно может быть катастрофой.
Создание отказоустойчивой ИТ инфраструктуры. Часть 4. Внедрение коммутаторов Cisco 3850 для межсетевой маршрутизации