про tshoot и работу с ip route — ну, это очевидно, что настройки pbr в её выводе никак не увидеть :) и поэтому таки да, придётся читать и списки acl и роут-мапы
ок, в любом случае спасибо всем комментаторам, по результатам обсуждения немного подправил статью, и добавил вариант с настройкой OSPF между 3850 и виосами, а также дисклеймер про использование PBR.
никто человеков убивать не собирается, здесь немного другая философия — что не запрещено, то разрешено :))
Конечно же никто в здравом уме не будет масштабировать PBR на несколько датацентров, или использовать его для разруливания трафика между многими сотнями или даже несколькими десятками сетей — цель статьи была не в этом точно, а чтобы показать альтернативу по сравнению с традиционным подходом с использованием IGP, если имеются ограниченные аппаратные ресурсы по обеспечению отказоустойчивости сети. Если этот подход выбивается из того, что рекомендует вендор, то тут уже дело каждого — или использовать традиционный подход, или принимать на себя риски, делая по своему.
Всё верно, что PBR имеет как свои пределы применимости, так и места для применения, и в этом конкретном случае был выбран в силу того, что его использование даёт возможность пережить полный отказ стека 3850 почти безболезненно. Да, естественно, что имеются другие способы этого достичь, но в нашем случае для обеспечения отказоустойчивости внутренней межсетевой маршрутизации, к сожалению, нет второго стека 3850, поэтому выбран вариант с PBR, который позволяет:
перенести обработку внутреннего межсетевого трафика на 3850, не переделывая схему работы виосов с внутренними сетями;
в случае полного отказа 3850 возможно перенести обработку внутреннего межсетевого трафика обратно на виосы, изменив для этого только их адреса vrrp.
Это решение:
может быть применимо только для небольшого количества внутренних сетей, так как ресурсы коммутатора ограниченны и количество строк в PBR имеет свой лимит;
вряд ли имеет смысл его использовать при наличии более чем одного датацентра (ну как датацентра — одной-двух стоек), из-за оверхеда в ручной настройке политик маршрутизации и сложностей в поиске и устранении ошибок по мере дальнейшего роста сетей.
Что касается траблшутинга — помимо того, что основной риск при использовании PBR в том, что его настройка это сугубо ручной процесс и можно легко выйти за пределы лимитов при росте количества сетей или правил обработки трафика, ещё имеется вероятность возникновения асимметричной маршрутизации, особенно в больших сетях.
CCDx имеется в виду Сisco Сertified Design ..., правильно понимаю?
Согласно "Designing for Cisco Network Service Architectures (ARCH) Foundation Learning Guide, Fourth Edition", задачи внутренней маршрутизации решаются с помощью протоколов OSPF или EIGRP. Про PBR в этом руководстве есть упоминание, но только применительно к Cisco ASA.
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, которое было предложено использовать в качестве основы для маршрутизации внутренних сетей наружу
в конце статьи добавил вариант с настройкой 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 здесь конечно может быть катастрофой.
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
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 никак при этом не меняется, если это имеет значение.
Таки да, для кого-то и системный блок — это один большой процессор :))
Но что имеем, то и имеем :(
Ну какая серверная — это всего одна стойка по железу, даже половина.
Зато название звучит :)
А так да, PBR в небольших серверных это наше все).
Сбой одного из коммутаторов 2960 или 3850 сеть выдержит? Да.
Сбой одного из роутеров VyOS выдержит? Да.
Полный отказ 3850 сеть выдержит? Да, если переконфигурировать haip для vrrp на VyOS. Можно даже это поведение заскриптовать на VyOS, или на управляющей машине в сети.
Ещё раз повторю, что явный deny в pbr никогда не использую.
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
Загрузка под 100% бывает только или из-за неправильной конфигурации pbr, или из-за несоблюдения лимитов — если всё настроено корректно, то такого не будет.
Авторитетом при написании статьи являлось официальное руководство, в данном случае. К чужому мнению всегда можно прислушаться, тем более что я писал что имеется и классический вариант настройки маршрутизации, но не раскрывая его.
Если будут серьёзные проблемы со стеком, можно его просто выключить — кратковременное отсутствие сильно не повлияет на работу сети, пока работают виосы.
Про скрипты спасибо, но к сожалению все 3850 уже заняты, тренироваться не на ком :(
А так да, было бы здорово показать, что происходит при поломке стека, или одного из коммутаторов в нём и что делать при этом, но увы, пока нет такой возможности смоделировать это на живом железе.
Виртуализация просто как пример, когда что-то новое стало повседневной практикой.
В pbr нечему ломаться, если только специально конфиг кривой не применять. Такое может быть и с любым протоколом маршрутизации, если что-то настроить не так.
Для устройства нет такой команды, в статье имеется вывод другой команды — show platform hardware...
Она показывает чего и сколько используется, и сколько ещё имеется ресурсов.
Должен конечно, вот сравнительная таблица решений резервного копирования для oVirt/RHEV (немного правда старенькая)
но едет же ;))
про tshoot и работу с ip route — ну, это очевидно, что настройки pbr в её выводе никак не увидеть :) и поэтому таки да, придётся читать и списки acl и роут-мапы
ок, в любом случае спасибо всем комментаторам, по результатам обсуждения немного подправил статью, и добавил вариант с настройкой OSPF между 3850 и виосами, а также дисклеймер про использование PBR.
никто человеков убивать не собирается, здесь немного другая философия — что не запрещено, то разрешено :))
Конечно же никто в здравом уме не будет масштабировать PBR на несколько датацентров, или использовать его для разруливания трафика между многими сотнями или даже несколькими десятками сетей — цель статьи была не в этом точно, а чтобы показать альтернативу по сравнению с традиционным подходом с использованием IGP, если имеются ограниченные аппаратные ресурсы по обеспечению отказоустойчивости сети. Если этот подход выбивается из того, что рекомендует вендор, то тут уже дело каждого — или использовать традиционный подход, или принимать на себя риски, делая по своему.
Всё верно, что PBR имеет как свои пределы применимости, так и места для применения, и в этом конкретном случае был выбран в силу того, что его использование даёт возможность пережить полный отказ стека 3850 почти безболезненно. Да, естественно, что имеются другие способы этого достичь, но в нашем случае для обеспечения отказоустойчивости внутренней межсетевой маршрутизации, к сожалению, нет второго стека 3850, поэтому выбран вариант с PBR, который позволяет:
Это решение:
Что касается траблшутинга — помимо того, что основной риск при использовании PBR в том, что его настройка это сугубо ручной процесс и можно легко выйти за пределы лимитов при росте количества сетей или правил обработки трафика, ещё имеется вероятность возникновения асимметричной маршрутизации, особенно в больших сетях.
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 во внутренних сетях, для организации их маршрутизации наружу нет.
Про риски PBR написано в коментах уже достаточно, наиболее интересный комментарий был от bukoka, на него приведён развёрнутый ответ — почему все-таки выбран был не IGP или статика, а именно PBR. Чтобы уж совсем не отходить от канонов, статья была обновлена, и в её конце приведён пример с настройкой OSPF между 3850 и виосами вместо использования PBR.
Ну вот смотрите, какое уже получается разнообразие возможностей и вариантов:
Разнообразие — это хорошо, выбирай что пригодится или что считаешь нужным и правильным :)
Везде есть свои плюсы и минусы конечно тоже. С одной стороны, простота и классика — это конечно аргумент, с другой стороны, может не хватить как возможностей статики, так и внутренних протоколов маршрутизации, когда понадобится трафик раскидать по разным направлениям в зависимости от источника и назначения. Если бы с таким не приходилось сталкиваться, то вариант с PBR даже бы и не предлагался.
Наверное, основная проблема статьи в том, что надо было предлагать PBR в качестве дополнительного решения, который может быть полезен в зависимости от потребностей, а не делать его основным вариантом, но что сделано, то сделано, по крайней мере вариант с классической destination-based маршрутизацией предложен тоже :)
Далее немного пройдусь по любимому PBR.
Знаете, в своё время пришлось на 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 из схемы вообще, если с ним что-то будет не так, да даже если просто потребуется обновить на нём ПО, например.
Здесь подходим к другому вопросу, вы написали:
К сожалению, сейчас нет возможности промоделировать сбой одного из коммутаторов в стеке 2960RX или 3850. Если есть какие-то предложения по повышению отказоустойчивости в таких ситуациях, то просьба прокомментировать этот момент подробнее, добавлю информацию о методах противодействия этому в статью. Опять же про вариант с PBR — он может позволить практически не обращать внимания на потерю 3850, но вот про стек 2960RX этого уже не скажешь. Хотя хосты и подключены к нему через Etherchannel, но split-brain здесь конечно может быть катастрофой.
cef включен глобально — The default configuration is CEF or dCEF enabled on all Layer 3 interfaces.
Что касается SVI, то например:
Спасибо! Действительно ошибся
20 лет назад CEF поддерживали только старшие модели, и по всей видимости на основной массе устройств обработка PBR действительно делалась на процессоре.
При выключенном ip redirects:
Хост в сети VLAN34 видит все хосты во внутренних сетях VLAN 17,32,35,40 и наоборот, а также выходит наружу в Интернет.
Загрузка процессора 3850 никак при этом не меняется, если это имеет значение.
ага
WS-C2960RX-48FPS-L = WS-C2960X-48FPS-L
Спасибо!
Конечно же WS-C2960RX-48FPS-L = WS-C2960X-48FPS-L
Главное, что эта модель позволяет создавать стек, что требовалось в рамках задачи.
Ещё такой момент есть — на него устанавливается фиксированная лицензия LAN Base, которую нельзя сменить.
Таки да, для кого-то и системный блок — это один большой процессор :))
Но что имеем, то и имеем :(
Ну какая серверная — это всего одна стойка по железу, даже половина.
Зато название звучит :)
Во, и я о том же :))
Сбой одного из коммутаторов 2960 или 3850 сеть выдержит? Да.
Сбой одного из роутеров VyOS выдержит? Да.
Полный отказ 3850 сеть выдержит? Да, если переконфигурировать haip для vrrp на VyOS. Можно даже это поведение заскриптовать на VyOS, или на управляющей машине в сети.
Ещё раз повторю, что явный deny в pbr никогда не использую.
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
Где в конфиге pbr написано про deny???
Про его обработку в 3750 известно, и поэтому deny никогда не используется.
Не делайте
Про классический вариант маршрутизации между 3850 и виос добавлю позже.
Загрузка под 100% бывает только или из-за неправильной конфигурации pbr, или из-за несоблюдения лимитов — если всё настроено корректно, то такого не будет.
Авторитетом при написании статьи являлось официальное руководство, в данном случае. К чужому мнению всегда можно прислушаться, тем более что я писал что имеется и классический вариант настройки маршрутизации, но не раскрывая его.
В чём именно противоречие?
Завтра уже узнаем
Третий коммутатор, кстати, в планах как зип :)
Если будут серьёзные проблемы со стеком, можно его просто выключить — кратковременное отсутствие сильно не повлияет на работу сети, пока работают виосы.
Про скрипты спасибо, но к сожалению все 3850 уже заняты, тренироваться не на ком :(
А так да, было бы здорово показать, что происходит при поломке стека, или одного из коммутаторов в нём и что делать при этом, но увы, пока нет такой возможности смоделировать это на живом железе.
Виртуализация просто как пример, когда что-то новое стало повседневной практикой.
В pbr нечему ломаться, если только специально конфиг кривой не применять. Такое может быть и с любым протоколом маршрутизации, если что-то настроить не так.
Для устройства нет такой команды, в статье имеется вывод другой команды — show platform hardware...
Она показывает чего и сколько используется, и сколько ещё имеется ресурсов.