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

Часто есть задача: ограничить скорость вилана, проходящего транзитом через свич из одного интерфейса в другой.
Каталисты легко поддерживают 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 исправно работают.