Здравствуйте
Кто используется UBRL (rate-limit на основе flow mask) на 6500 (или 4500)?
Может подкинете пример рабочей конфигурации на большое кол-во пользователей -
в примерах на циске и др есть только на одного/двух пользователей.
Вопрос вот в чем - как настроить UBRL на много пользователей - надо порядка 2000.
Пользователям выделены подсетки /30 и /29. По примеру получается что на каждого надо по
acl + class + строка в policy-map. Строк в policy-map вроде как максимум 255.
У меня все приходит через один интерфейс. Получается что такое кол-во юзеров полисить нельзя?
или пользователи обязательно должны быть размазаны по интерфейсам в количестве не более 255 на интерфейс чтобы их можно было разными policy-map описать?
>[оверквотинг удален]
>много пользователей - надо порядка 2000.
>Пользователям выделены подсетки /30 и /29. По примеру получается что на каждого
>надо по
>acl + class + строка в policy-map. Строк в policy-map вроде как
>максимум 255.
>У меня все приходит через один интерфейс. Получается что такое кол-во юзеров
>полисить нельзя?
> или пользователи обязательно должны быть размазаны по интерфейсам в
>количестве не более 255 на интерфейс чтобы их можно было разными
>policy-map описать?чегой-то слабо верится что у всех n абонентов скорости разные...
может имеет смысл определить классы условно
128k
256k
512k
и группировать по классам ?
для каждого класса по acl'ю. адреса юзеров в acl'и
в полиси поклассовую резню :)
вроде должно работать...
Пока не совсем понял идею - а за счет объединения нескольким юзерам не достанется
одна и та же полоса? Со скоростями именно так как вы и указали
Насколько я понял предложенное (например user1 и user2 тариф 256k, user3 512k):
access-list 101 permit ip host 201.10.1.1 any # 256k user
access-list 102 permit ip host 201.10.1.2 any # 256k user
access-list 103 permit ip host 201.10.1.3 any # 512k user
class-map match-any identify-user-256k
match access-group 101
match access-group 102
class-map match-any identify-user-512k
match access-group 103
policy-map police-customer-traffic
class identify-user-256k
police flow mask src-only 256000 5000 conform-action transmit exceed action drop
class identify-user-512k
police flow mask src-only 512000 5000 conform-action transmit exceed action dropinterface gig3/1
service-policy input police-customer-trafficА точно в таком случае user1 и user2 получат _каждый_ по 256k а не 256к на всех?
Или речь о таком?
access-list 101 permit ip host 201.10.1.1 any # 256k user
access-list 101 permit ip host 201.10.1.2 any # 256k user
access-list 103 permit ip host 201.10.1.3 any # 512k user
class-map match-any identify-user-256k
match access-group 101
class-map match-any identify-user-512k
match access-group 103
policy-map police-customer-traffic
class identify-user-256k
police flow mask src-only 256000 5000 conform-action transmit exceed action drop
class identify-user-512k
police flow mask src-only 512000 5000 conform-action transmit exceed action dropinterface gig3/1
service-policy input police-customer-trafficЕсть кто - у кого работает схема?
>[оверквотинг удален]
>чегой-то слабо верится что у всех n абонентов скорости разные...
>
>может имеет смысл определить классы условно
>128k
>256k
>512k
>и группировать по классам ?
>для каждого класса по acl'ю. адреса юзеров в acl'и
>в полиси поклассовую резню :)
>вроде должно работать...
>[оверквотинг удален]
>>чегой-то слабо верится что у всех n абонентов скорости разные...
>>
>>может имеет смысл определить классы условно
>>128k
>>256k
>>512k
>>и группировать по классам ?
>>для каждого класса по acl'ю. адреса юзеров в acl'и
>>в полиси поклассовую резню :)
>>вроде должно работать...http://www.cisco.com/en/US/prod/collateral/switches/ps5718/p...
User-Based Rate Limiting (UBRL) on the Cisco Catalyst 6500 Supervisor Engine 32 and Cisco Catalyst 6500 Series Supervisor Engine 720 with Cisco IOS Software Only
User-Based Rate Limiting functionality is supported only on the Cisco Catalyst 6500 Supervisor Engine 32 and Cisco Catalyst 6500 Series Supervisor Engine 720 and is a microflow policing function which provides a means to rate limit many source or destination IP addresses to an individual rate. This configuration requires only two ACLs and can support a large number of users. Only supported in Cisco IOS Software, the example below demonstrates UBRL by rate limiting traffic from each user in a user-group to 1 Mbps each, going to the subnet 192.168.0.0/16:Cisco IOS Software
Access-list 101 permit ip any 192.168.0.0 0.0.255.255
Class-map 1Mbps-rate
Match access-group 101
Policy-map Outbound
Class 1Mbps-rate
Police flow mask src-only 1000000 ...
Int gig 3/1
Service-policy input Outbound
Понятно, эту доку видел, но к сожалению в абзац не вчитался до полного понимания.
Значит второй вариант.
Спасибо.
>[оверквотинг удален]
>Policy-map Outbound
>
>Class 1Mbps-rate
>
>Police flow mask src-only 1000000 ...
>
>Int gig 3/1
>
>Service-policy input Outbound
>
Вот только еще об одном моменте подумал - в примере выше сеть описана одним acl
с широкой маской. UBRL как частный случай microflow policing полисит по маске per flow.
Соответсвенно если поток будет с каждого ip, то у меня получится на каждый ip по например 1мб. Если я раздаю клиентам сети /30 все хорошо, используемый ip там один.
Однако в случае если я дам сетку /29 или (не дай бог :) /28 то у меня получится
что полисить будет по 1мб на каждый ip. Это действительно так или я где-то заблудился?
И если так то как бороться?>[оверквотинг удален]
>>Policy-map Outbound
>>
>>Class 1Mbps-rate
>>
>>Police flow mask src-only 1000000 ...
>>
>>Int gig 3/1
>>
>>Service-policy input Outbound
>>
>[оверквотинг удален]
>с широкой маской. UBRL как частный случай microflow policing полисит по маске
>per flow.
>Соответсвенно если поток будет с каждого ip, то у меня получится на
>каждый ip по например 1мб. Если я раздаю клиентам сети /30
>все хорошо, используемый ip там один.
> Однако в случае если я дам сетку /29 или (не
>дай бог :) /28 то у меня получится
>что полисить будет по 1мб на каждый ip. Это действительно так или
>я где-то заблудился?
>И если так то как бороться?User Based Rate Limiting is a form of Microflow Policing. As mentioned above, Microflow policing supports the policing of *individual* flows. The switch uses a flow mask to determine what constitutes a flow. There are a number of different flow masks available in the PFC1 and PFC2, and they include:
- Destination Only IP (this is the default)
- Source and Destination IP
- Full Flow (Source and Destination IP, Protocol and Source and Destination Port)И думаю более интересное для PFC3x(интересно что здесь по умолчанию? - наверно Source IP Address):
The PFC3x introduced support for multiple flow masks to be used at the same time. It also added support
for a range of new flows masks including the following:
- Destination: Destination IP Address
- Source: Source IP Address
- Source & Destination: Source and Destination IP Address
- Interface, Source & Destination: Input interface, source and destination IP address
- Full: Source, Destination IP address, IP protocol, TCP/UDP source and destination ports if present
- Interface, Full: Input interface, Source, Destination IP address, IP protocol, TCP/UDP source and destination ports if presentДумаю да, да и к тому же не факт что на один уникальный ip будет резать по 1мб, здесь скорее привязка к приложениям которые создают потоки и к количеству потоков.
И этих потоков согласно документации - 128К, а что будет при их превышении хз.
А бороться - наверно выбирать правильную "flow mask".For the PFC1, PFC2, PFC3 and PFC3B you can rate limit up to 128K+ unique flows using up to 63 different rate + traffic class combinations. The PFC3BXL allows up to 256K flows to be policed. For Aggregate policers, there is a system limit of 1023 policers and this applies across all PFC versions.
>
Гм, получается усовершенствования идут в сторону удлинения маски,
а мне надо указать ее короче для случая с например /29, т.е. что-то вроде
неполной маски source IP address.
В моем случае multiple flow masks не спасут, тут речь только о том
что можно кого-то без учета TCP/UDP информации шейпить, а кого-то по приложениям.
А к приложениям не должно быть привязано, это вроде четко написано - для
этого маски отличные от full flow и нужны.
Насчет 128K (ну или 256K) это интересный вопрос. Хотелось бы знать еще речь идет о потоках с учетом flow-mask или нет. Судя по даташитам на sup720 это максимальное
число netflow потоков, т.е. ubrl тут не при чем. Можно предположить что при превышении
пакеты не будут попадать в netflow и соответственно шейпиться будет только то что попало.
Как будет возможность проверю поэкспериментирую.>[оверквотинг удален]
>которые создают потоки и к количеству потоков.
>И этих потоков согласно документации - 128К, а что будет при их
>превышении хз.
>А бороться - наверно выбирать правильную "flow mask".
>
>For the PFC1, PFC2, PFC3 and PFC3B you can rate limit up
>to 128K+ unique flows using up to 63 different rate +
>traffic class combinations. The PFC3BXL allows up to 256K flows to
>be policed. For Aggregate policers, there is a system limit of
>1023 policers and this applies across all PFC versions.
>Гм, получается усовершенствования идут в сторону удлинения маски,
>а мне надо указать ее короче для случая с например /29, т.е.
>что-то вроде
>неполной маски source IP address.
> В моем случае multiple flow masks не спасут, тут речь
>только о том
>что можно кого-то без учета TCP/UDP информации шейпить, а кого-то по приложениям.Протестировал на src-only flow mask.
policy-map Limit-1M
class DATA
police flow mask src-only 1024000 64000 conform-action transmit exceed-action dropДва vlan`а. Повесил алиасами по два ip адреса из подсети 172.16.133.0/24 на одну FreeBSD и 172.16.143.0/24 на вторую FreeBSD. Закрепил пары на cкачивания(172.16.133.3-172.16.143.3 и 172.16.133.30-172.16.143.30)
Действительно резало для каждого потока по 1Мб/с.
6500sup720#show ip cache flow
Displaying hardware-switched flow entries in the PFC (Standby) Module 1:
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts-- 172.16.143.3 --- 0.0.0.0 00 0000 0000 33K
-- 0.0.0.0 --- 0.0.0.0 00 0000 0000 478K
-- 172.16.133.30 --- 0.0.0.0 00 0000 0000 21K
-- 172.16.133.3 --- 0.0.0.0 00 0000 0000 28K
-- 172.16.143.30 --- 0.0.0.0 00 0000 0000 21K
Действительно странно, меньше то получается flow mask`и и нет. Даже если укажешь source-only маску(а как я это понимаю это минимальная), то для каждого ip`а из подсети /29 получишь по записи в netflow таблице, а соответствено и полисинг будет по 1Мб на каждый ip. Ну и нафиг такая нарезка через flow masks если выдал пользователю /29 и он сидит довольный что у него на каждый ip по 1Мб :)> А к приложениям не должно быть привязано, это вроде четко
>написано - для
>этого маски отличные от full flow и нужны.Это если src-only использовать то будет на один ip завязано, а если взять flow mask побольше, скажем с учётом портов, то тут уже и на каждый отдельный поток будет резать скорость. Запустил wget в 5 потоков и у тебя 5Мбит/c, хочешь больше скорость - делай больше потоков! :)
> Насчет 128K (ну или 256K) это интересный вопрос. Хотелось бы знать
>еще речь идет о потоках с учетом flow-mask или нет. Судя
>по даташитам на sup720 это максимальное
>число netflow потоков, т.е. ubrl тут не при чем. Можно предположить что
>при превышении
>пакеты не будут попадать в netflow и соответственно шейпиться будет только то
>что попало.
> Как будет возможность проверю поэкспериментирую.Если будут результаты, скинь сюда, интересно посмотреть.