![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gul_techЧасто есть задача: ограничить скорость вилана, проходящего транзитом через свич из одного интерфейса в другой.
Каталисты легко поддерживают ingress policing на физическом интерфейсе, но если нужно ограничить не весь трафик из интерфейса, а отдельные виланы из транкового порта, всё становится сложнее. Особенно, если скорость должна быть ограничена не по сумме всех направлений вилана, а в каждую сторону независимо (а обычно оно именно так). Тем не менее, задача решается как на 3560 (3550, 3750, 3560-E и т.п.), так и на 6500.
3560 - через hierarchical policy-maps.
Пример конфига:
Счётчики не работают, но скорость ограничивается. Незначимые на вид части (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 с разными линейными картами).
На физическом интерфейсе (транковом) применяется service-policy iface1. В нём может быть много классов, для разных виланов. И на этом физическом интерфейсе не должно быть "mls qos vlan-based". В этом заключена неприятность: виланы в этом транке, которые терминируются локально, уже нельзя ограничивать на SVI, все нужно ограничивать только на этом физическом интерфейсе, по виланам.
В этом случае процессор расходуется гуманно (до определённых пределов), jitter практически не растёт, но при применении control-plane такие виланы всё равно отваливаются (что наводит на грустные мысли).
Кстати, в этом случае можно не только ограничивать скорость, но и считать трафик таких транзитных виланов в каждую сторону - счётчики в policy-map исправно работают.
Каталисты легко поддерживают 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 исправно работают.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-04-08 06:37 am (UTC)Сначала, забыла, попробовала по документации циско, но, видимо, что-то из "надо запомнить" пропускала :)
no subject
Date: 2012-03-27 04:48 am (UTC)no subject
Date: 2012-03-27 08:17 pm (UTC)И кажется, там дискретность у полисеров именно 64k, хотя, если не ошибаюсь, видел багфиксы с этим в каких-то release notes. Так что, если вообще не ограничивает, скорее всего, дело в какой-то детали, которая кажется несущественной. А если ограничивает, но не на 64k, а больше, попробуйте обновить IOS.