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

[l2tp.livejournal.com]

Вот спасибо.

Хоть и не люблю использовать рецепты из серии "Это нельзя понять, это надо запомнить", другого варианта для каталистов пока не нашла.

Спробую что ли.

[l2tp.livejournal.com]

Попробовала. Спасибо

Сначала, забыла, попробовала по документации циско, но, видимо, что-то из "надо запомнить" пропускала :)

[(Anonymous)]

Доброго времени суток. Тоже поставили задачу по ограничению скорости в транзитном влане этак до 64к между cat3750-e, пробовал вышеизложенный конфиг, но iperf выдал гораздо большую пропускную способность...Может что надо сделать по другому для 3750-e?

[gul-tech.livejournal.com]

Нет, для 3750 должно именно описанное работать.
И кажется, там дискретность у полисеров именно 64k, хотя, если не ошибаюсь, видел багфиксы с этим в каких-то release notes. Так что, если вообще не ограничивает, скорее всего, дело в какой-то детали, которая кажется несущественной. А если ограничивает, но не на 64k, а больше, попробуйте обновить IOS.

[fornike.livejournal.com]

А не в курсе как бы такое сделать на 4948 ?

[gul-kiev.livejournal.com]

К сожалению, не знаю - с 4948 не приходилось иметь дело.
По идее, иерархические policy-map там работают, так что можно попробовать первый способ. Ну либо второй, если с первым не выйдет.
Если что-то получится - буду благодарен за информацию об этом. :)

[fornike.livejournal.com]

Да вот прикол в том что:

L3(config)#class-map match-all test
L3(config-cmap)#ma
L3(config-cmap)#match ?
access-group Access group
any Any packets
cos IEEE 802.1Q/ISL class of service/user priority values
ip IP specific values
not Negate this match result
protocol Protocol

L3(config-cmap)#match

нету match input-interface

а тут:
L3(config)#mac access-list extended test
L3(config-ext-macl)#permit any any ?
protocol-family An Ethernet protocol family


L3(config-ext-macl)#permit any any

нету permit any any vlan номервлан. Такие пироги :)

[fornike.livejournal.com]

Всё же разобрались. Как оказалось резать скорость на L2 влан на 4948 на самом деле очень простая штука. Почему не получалось до этого - просто надо было включить qos глобально.

policy-map PolTestL2shape
class TestL2shape
police 128 kbps 12 kbyte conform-action transmit exceed-action drop
!

class-map match-any TestL2shape
match any
!

!
interface Vlan666
no ip address
service-policy input PolTestL2shape
service-policy output PolTestL2shape
end
!

И всё :) Главное чтобы:
L3#show qos
QoS is enabled globally
IP header DSCP rewrite is disabled

Если надо per port vlan, то service-policy вешается так:
!
interface GigabitEthernet1/30
description DownLink
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 666
switchport mode trunk
speed 10
vlan-range 666
service-policy input PolTestL2shape
service-policy output PolTestL2shape
end

[gul-kiev.livejournal.com]

Спасибо.
Только я не понял насчёт vlan-range. Эта строка что означает?
Если на порту в транке несколько виланов, и нужно ограничить в них скорость независимо (ну или просто в одном независимо от трафика в других) - это получается?

[fornike.livejournal.com]

Получается.
Кусок конфига в предыдущем посте неинмормативный получился касательно этой строчки, т.к. форматирование сбилось. я лучше дам ссылку на первоисточник :) http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sga/configuration/guide/qos.html

там Figure 30-6

интересно :)

[asealel.livejournal.com]

Очень интересно. Спасибо большое. :)
Тестирую на 6500 sup32.
может есть опыт сколько VLAN она таким способом может заполисить ?
или хотя бы предположение ...
:))

Re: интересно :)

[gul-kiev.livejournal.com]

Предполагаю, что это больше зависит от трафика, чем от количества виланов.
В общем - не знаю, надо экспериментировать. :(
Ну и посматривать на "show platform hardware capacity" и другие параметры железки.

Re: интересно :)

[cmhungry.livejournal.com]

на 6500-суп32 можно пользоваться UBRL

Re: интересно :)

[gul-kiev.livejournal.com]

Если описанная задача решается через microflow, и это оказывается более эффективно - было бы интересно посмотреть пример конфига. Мне казалось, там только по IP классификация происходит. Ошибаюсь?
Ну и надо помнить, что microflow несовместим с IOS-SLB, Reflexive ACL, TCP-Intercept, WCCP, CBAC и NAT/PAT. И что в этом случае можно создать не более 64 различных полисеров (в смысле, на различные скорости).

[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-роутеров.

Пожалуй для многих простой вопрос.

[(Anonymous)]

Господа подскажите как шейпить/полисить траффик по IP адресам на 7604. До этого работал только с 28 и 38 серией, а в супервайзере нет команды rate-limit. Каким образом резать скорость?

Re: Пожалуй для многих простой вопрос.

[gul-kiev.livejournal.com]


policy-map client-in
class class-default
police cir 100000000 bc 1000000 be 2000000 conform-action transmit exceed-action drop violate-action drop
policy-map client-out
class class-default
police cir 100000000 bc 1000000 be 2000000 conform-action transmit exceed-action drop violate-action drop
!
interface GigabitEthernet1/5
switchport
switchport access vlan 10
switchport mode access
mls qos vlan-based
!
interface Vlan10
ip address 10.0.0.1 255.255.255.0
service-policy input client-in
service-policy output client-out
!


[(Anonymous)]

Прошу помощи зала.
Есть подобная задача - есть 6506-Е с SUP720-3B. В порт Te1/1(trunk) приходят несколько вланов в которых подняты BGP с пирами(допустим эти вланы 100,101,102) от каждого примерно по 10К перфиксов, и есть int Te1/2(trunk) в котором проброшен один влан(допустим vlan300) для клиента, в нем тоже организована BGP и туда отдаются все префиксы пиров ~ 30K. Надо сделать так чтобы можно было ограничивать клиентскую скорость по каждому направлению, скажем чтобы к пиру во влане 100 была гарантированная полоса 500 мегабит, а к пиру во влане 101 к примеру 300 мегабит. Как посоветуете сделать это?

[gul-kiev.livejournal.com]

Насколько я понимаю, вопрос в том, что таких клиентов много, иначе можно было бы ограничить egress-фильтрами на виланах 100,101,102. И проблема в том, чтобы отличить трафик одного клиента от другого.
Тут я вижу два варианта: либо покрасить трафик (dscp) и потом матчить его на выходе (не забыть при этом сказать "platform ip features sequential"), либо покрасить анонсы через "bgp table-map", на клиентском интерфейсе сказать "bgp-policy destination ip-prec-map" или ip-qos-map (если ip-qos-map будет работать, это предпочтительнее, но я не уверен, что он заработает), и тогда ограничивать уже у клиента на ingress. Ну или наоборот - клиентские анонсы раскрасить и на аплинковых интерфейсах ограничивать - задача ведь симметричная.

Думаю, что хотя бы один из этих двух способов должен работать на sup720.