Cisco: ограничение скорости транзитного вилана

[gul_tech]

Часто есть задача: ограничить скорость вилана, проходящего транзитом через свич из одного интерфейса в другой.
Каталисты легко поддерживают ingress policing на физическом интерфейсе, но если нужно ограничить не весь трафик из интерфейса, а отдельные виланы из транкового порта, всё становится сложнее. Особенно, если скорость должна быть ограничена не по сумме всех направлений вилана, а в каждую сторону независимо (а обычно оно именно так). Тем не менее, задача решается как на 3560 (3550, 3750, 3560-E и т.п.), так и на 6500.

3560 - через hierarchical policy-maps.
Пример конфига:

mls qos
no mls qos rewrite ip dscp
!
access-list 101 remark ANY
access-list 101 permit ip any any
!
class-map match-all INTERFACES-FOR-VLAN-10
  match input-interface  GigabitEthernet0/8
class-map match-all ANY
  match access-group 101
!
policy-map POLICY-FOR-INTERFACES-FOR-VLAN-10
  class INTERFACES-FOR-VLAN-10
    police 10240000 1920000 exceed-action drop
!
policy-map POLICY-FOR-VLAN-10
  class ANY
   set dscp 7
   service-policy POLICY-FOR-INTERFACES-FOR-VLAN-10
!
interface Vlan10
 no ip address
 service-policy input POLICY-FOR-VLAN-10

Счётчики не работают, но скорость ограничивается. Незначимые на вид части (match по access-list с "permit any", неиспользуемый "set dscp") действительно нужны, без них всё перестаёт работать. Как говорится, это трудно понять, но нужно запомнить. Какой именно dscp устанавливается - неважно (главное, чтобы не 0), но, судя по всему, для разных виланов нужно устанавливать разные значения.
На физическом интерфейсе должно быть прописано "mls qos vlan-based". В полиси по интерфейсам может быть несколько классов - для разных input interfaces.

Для 6500 делается иначе. Приведённый выше способ там не работает, условия "match input-interface", "match vlan" и прочие лобовые методы - тоже (по крайней мере, на "дешёвых" картах вроде WS-X6724-SFP или WS-X6748-GE-TX).
Для начала был попробован bridge с ограничением скорости на SVI и vlan-mapping обратно (чтобы номер вилана не менялся). Работает, но cpu-based, routing processor сразу убивается, да и клиентам не нравится jitter.
Поэтому было найдено более приемлемое решение (опробовано на sup32, sup720 и vs-s720 с разными линейными картами).

mac packet-classify use vlan
!
mac access-list extended VLAN10
 permit any any  vlan 10
!
class-map match-all vlan10-in
  match access-group name VLAN10
policy-map iface1
  class-map vlan10-in
    police cir 100000000 bc 1000000 be 2000000 conform-action transmit exceed-action drop
!
interface Vlan10
 no ip address
 mac packet-classify

На физическом интерфейсе (транковом) применяется service-policy iface1. В нём может быть много классов, для разных виланов. И на этом физическом интерфейсе не должно быть "mls qos vlan-based". В этом заключена неприятность: виланы в этом транке, которые терминируются локально, уже нельзя ограничивать на SVI, все нужно ограничивать только на этом физическом интерфейсе, по виланам.
В этом случае процессор расходуется гуманно (до определённых пределов), jitter практически не растёт, но при применении control-plane такие виланы всё равно отваливаются (что наводит на грустные мысли).
Кстати, в этом случае можно не только ограничивать скорость, но и считать трафик таких транзитных виланов в каждую сторону - счётчики в policy-map исправно работают.

Comments

[t800.livejournal.com]

Огромное спасибо за информацию. До того как попался этот пост, всё упиралось в рекомендации "гуру" купить 7600. Именно для контроля скорости per vlan.

У нас протяженная транспортная сеть, решенная, как это ни странно на 2960. Планируем виланы, требующие лимита скорости, пропускать через 3750G. Вопрос в том, как у нее процессор к этому отнесется...

[gul-kiev.livejournal.com]

Процессор отнесётся нормально, но вот насчёт того, какое кол-во виланов можно таким образом ограничить - не скажу. Вполне может оказаться, что не так уж много (например, 64 или даже 16).
7600, кстати, этот вопрос "по уму" не решит (см. в посте решение для 6500 - оно же и для 7600). Можно, конечно, посмотреть в сторону MPLS, но это отдельная тема.
Можно ещё посмотреть на Juniper EX3200 - он тоже умеет ограничивать скорость виланов, и там работают повиланные счётчики (через файервол). Правда, в некоторых случаях сталкивался с глюками, но это, я надеюсь, временное явление. А в целом железка приятная.

[t800.livejournal.com]

При наших масштабах (в смысле - не таких и существенных) до перевода сети на некий новый уровень, даже 16 виланов в лимите будут за радость. А то доходит до смешного: продаем канал 2 мегабита, а по факту ограничиваем только портом до 10 мегабит.

Я тут ремарку должен сделать, что сам больше телефонист. Сотовая и наземная связь, пэдэшник из меня постольку поскольку. MPLS я пытался курить, но понял так, что там L3 задействован, а следовательно продать прозрачный канал для клиента, чтобы он потом с нами каждую подсеть не согласовывал, - нереально. Или я неправ?

[gul-kiev.livejournal.com]

> MPLS я пытался курить, но понял так, что там L3 задействован, а следовательно продать прозрачный канал для клиента, чтобы он потом с нами каждую подсеть не согласовывал, - нереально. Или я неправ?

Нет, EoMPLS как раз позволяет продавать клиенту прозрачный L2, который будет ходить через ваши маршрутизаторы, использующие L3 (и, в частности, резервироваться через OSPF). Фактически это туннелирование.
Это более дорогое и более масштабируемое решение, чем предоставлять клиентам виланы. С одной стороны, MPLS-оборудование дороже, чем обычные L2-свичи с поддержкой q-in-q и stp, с другой - в случае mpls вы не ограничены номерами виланов, у вас в сети не будут ходить клиентские маки, резервирование через ospf имеет ряд преимуществ перед stp, открываются возможности traffic engineering и т.д.

[t800.livejournal.com]

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

[gul-kiev.livejournal.com]

Теоретически - да.
На практике можно вилан довести через обычные свичи до ближайшего MPLS-роутера, и там сделать xconnect между сабинтерфейсами роутеров. Это будет не совсем чистый EoMPLS, т.к. он будет проходить через ваши L2-свичи, но такое решение тоже используется достаточно широко. Но чтобы это имело смысл, действительно, должно быть кольцо из MPLS-роутеров.