Всем доброго времени суток!
Перерыл весь форум, но ничего конкретного по сабжу не нашел.
Имеется:
- UTM5.2.1-007 с модулем динамического шейпирования, ключи/лицензии в порядке;
- маршрутизатор Cisco 7206 vxr - он же NAS в нашей реализации;
- сам сервер, где крутится UTM5.
Проблема:
Никак не могу добиться корректной работы динамического шейпирования.
Возникла необходимость шейпить трафик днем и вечером, по мере того как абонент скачает определенное количество трафика в гигабайтах. В соответствии с мануалом по UTM5 были созданы несколько правил в разделе Настройки-Динамическое шейпирование, к примеру, есть безлимитный тариф 1024Кб/с, нужно чтобы когда абонент привысил границу в 5Гб, скорость ему подрезалась до 768Кб/с, после, когда он перешел границу в 6Гб - 512Кб/с. Соответствующие значения были выставлены в форме создания правила и вставлены RADIUS-атрибуты:
lcp:interface-config#1=rate-limit input IN_BANDWIDTH_BITS IN_CISCO_NORMAL_BURST IN_CISCO_EXTENDED_BURST conform-action transmit exceed-action drop
lcp:interface-config#1=rate-limit output OUT_BANDWIDTH_BITS OUT_CISCO_NORMAL_BURST OUT_CISCO_EXTENDED_BURST conform-action transmit exceed-action drop
То есть все как в учебнике, и, если сделать так, то циска на приходящие изменения канала никак не реагирует, скорость остается "тарифной" (видел из дебага циски - параметры приходят, но изменений не происходит).
Натолкнулся на пост TiRider'a viewtopic.php?t=7603&highlight=#top, так вот, при коннекте после того, как граница шейпа пройдена, выдается ошибка 734, а в дебаге циски можно видеть следующее:
Sep 3 10:56:00.086: RADIUS: Cisco AVpair [1] 29 "ip:sub-qos-policy-in=1024in"
Sep 3 10:56:00.086: RADIUS: Vendor, Cisco [26] 37
Sep 3 10:56:00.086: RADIUS: Cisco AVpair [1] 31 "ip:sub-qos-policy-out=1024out"
Sep 3 10:56:00.086: RADIUS: Vendor, Cisco [26] 111
Sep 3 10:56:00.086: RADIUS: Cisco AVpair [1] 105 "lcp:interface-config#1=rate-limit input 786432 147456 294912 conform-action transmit exceed-action drop"
Sep 3 10:56:00.086: RADIUS: Vendor, Cisco [26] 94
Sep 3 10:56:00.086: RADIUS: Cisco AVpair [1] 88 "lcp:interface-config#1=rate-limit output conform-action transmit exceed-action drop"
Почему-то не выдаются параметры исходящего канала.
И еще не понятно по правилам фаервола в админке в случае с циской опять же. В мане очень размыто сказано нужно ли создавать правила в админке для событий установление/изменение ширины канала и снятие ограничений или нет, если в качестве брандмаура (не локальный ipfw) используется кошка...
Я видел, что люди задаются такими же вопросами, окончательного решения нигде не было.
Очень надеюсь на помощь, потому как сломал всю голову уже... Заранее СПАСИБО!
Шейп трафика на Cisco при помощи модуля Dynashape
Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2)
В целом, в работе иоса глюков замечено не было...
По конфигу:
class-map match-all internal.in
match access-group name internal.in
class-map match-all internal.out
match access-group name internal.out
!
!
policy-map 1024in
class internal.in
police rate 1024000 burst 64000 peak-burst 64000
conform-action transmit
exceed-action drop
violate-action drop
class class-default
police rate 1024000 burst 64000 peak-burst 64000
conform-action transmit
exceed-action drop
violate-action drop
policy-map 1024out
class internal.out
police rate 1024000 burst 64000 peak-burst 64000
conform-action transmit
exceed-action drop
violate-action drop
class class-default
police rate 1024000 burst 64000 peak-burst 64000
conform-action transmit
exceed-action drop
violate-action drop
На самой циске границы шейпирования в конфиге не устанавливались, они берутся из модуля dynashape.
В UTM в Динамическом шейпировании для тарифа 1024 создаем границы и прописываем значения скоростей.
Во вкладке Входящий канал: Временной диапазон - День, Граница - 4G, значение 768;
Исходящий канал: Временной диапазон - День, Граница - 0, значение 1024.
То есть, подразумевается, что входящий режется через 4 гб, а исходящий вообще не режется. Вот если слить чего-нибудь на 4 с лихом гигабайта и попробовать переподнять VPN, то выдает ошибку 734 и такую штуку в дебаге, как указано в первом посте.
Или может стоит как-то по-другому подойти к шейпированию на циске? Поделитесь опытом плиз
В целом, в работе иоса глюков замечено не было...
По конфигу:
class-map match-all internal.in
match access-group name internal.in
class-map match-all internal.out
match access-group name internal.out
!
!
policy-map 1024in
class internal.in
police rate 1024000 burst 64000 peak-burst 64000
conform-action transmit
exceed-action drop
violate-action drop
class class-default
police rate 1024000 burst 64000 peak-burst 64000
conform-action transmit
exceed-action drop
violate-action drop
policy-map 1024out
class internal.out
police rate 1024000 burst 64000 peak-burst 64000
conform-action transmit
exceed-action drop
violate-action drop
class class-default
police rate 1024000 burst 64000 peak-burst 64000
conform-action transmit
exceed-action drop
violate-action drop
На самой циске границы шейпирования в конфиге не устанавливались, они берутся из модуля dynashape.
В UTM в Динамическом шейпировании для тарифа 1024 создаем границы и прописываем значения скоростей.
Во вкладке Входящий канал: Временной диапазон - День, Граница - 4G, значение 768;
Исходящий канал: Временной диапазон - День, Граница - 0, значение 1024.
То есть, подразумевается, что входящий режется через 4 гб, а исходящий вообще не режется. Вот если слить чего-нибудь на 4 с лихом гигабайта и попробовать переподнять VPN, то выдает ошибку 734 и такую штуку в дебаге, как указано в первом посте.
Или может стоит как-то по-другому подойти к шейпированию на циске? Поделитесь опытом плиз

Для выдачи настроек поднимаемого канала использовал метод, описанный TiRider'ом, а в модуле динамического шейпирования настроил границы и временные диапазоны и в radius-атрибутах шейпа вставил:
lcp:interface-config#1=rate-limit input IN_BANDWIDTH_BITS IN_CISCO_NORMAL_BURST IN_CISCO_EXTENDED_BURST conform-action transmit exceed-action drop
lcp:interface-config#1=rate-limit output OUT_BANDWIDTH_BITS OUT_CISCO_NORMAL_BURST OUT_CISCO_EXTENDED_BURST conform-action transmit exceed-action drop
Теперь после перехода границы, судя по логам радиус-сервера, выдаются настройки скорости для канала.
?Debug : Sep 09 13:51:32 AuthServer: User <user> connecting
?Debug : Sep 09 13:51:32 AuthServer: Session for sessionid <user> not found in <172.18.1.1> cache
?Debug : Sep 09 13:51:32 RADIUS DBA: Info for login <user> found. type <1>
?Debug : Sep 09 13:51:32 AuthServer: Auth scheme: MS-CHAPv2
?Debug : Sep 09 13:51:32 AuthServer: MS-CHAPv2: Authorized user <user>
?Debug : Sep 09 13:51:32 AuthServer: MS-CHAPv2: MPPE Keys send
?Debug : Sep 09 13:51:32 AuthServer: IP claimed: 0xac1e000c (<172.30.0.12>)
?Debug : Sep 09 13:51:32 AuthServer: Calling fill radius attributes for service. Attr storage size <2>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data Vendor:<9> Attr:<1> String val:<ip:sub-qos-policy-in=1024in> Size:<27> Result:<0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data verify Size:<27>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data Vendor:<9> Attr:<1> String val:<ip:sub-qos-policy-out=1024out> Size:<29> Result:<0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data verify Size:<27>
?Debug : Sep 09 13:51:32 AuthServer: Calling fill radius attributes for slink. Attr storage size <0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data Vendor:<9> Attr:<1> String val:<lcp:interface-config#1=rate-limit output 786432 147456 294912 conform-action transmit exceed-action drop> Size:<104> Result:<0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data verify Size:<27>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data Vendor:<9> Attr:<1> String val:<lcp:interface-config#1=rate-limit input 1048576 196608 393216 conform-action transmit exceed-action drop> Size:<104> Result:<0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data verify Size:<27>
?Debug : Sep 09 13:51:32 AuthServer: Calling fill radius attributes for NAS. Attr storage size <0>
Notice: Sep 09 13:51:32 AuthServer: Login OK <user> from NAS <172.18.1.1> CLID <> Calling-station <>
?Debug : Sep 09 13:51:32 AuthServer: Setting interim update interval from config
?Debug : Sep 09 13:51:32 AuthServer: Auth reply: RPacket:
Code: 2; ID: 241
<Vendor: 0; Attr: 6>[4]: 00000002
<Vendor: 0; Attr: 7>[4]: 00000001
<Vendor: 0; Attr: 8>[4]: ac1e000c
<Vendor: 0; Attr: 9>[4]: ffffffff
<Vendor: 0; Attr: 27>[4]: 00015180
<Vendor: 9; Attr: 1>[27]: 69703a7375622d716f732d706f6c6963792d696e3d31303234696e
<Vendor: 9(0); Attr: 1>[29]: 69703a7375622d716f732d706f6c6963792d6f75743d313032346f7574
<Vendor: 9(1); Attr: 1>[104]: 6c63703a696e746572666163652d636f6e66696723313d726174652d6c696d6974206f75747075742037383634333220313437
<Vendor: 9(2); Attr: 1>[104]: 6c63703a696e746572666163652d636f6e66696723313d726174652d6c696d697420696e707574203130343835373620313936
<Vendor: 311; Attr: 7>[4]: 00000001
<Vendor: 311; Attr: 8>[4]: 00000006
<Vendor: 311; Attr: 16>[34]: 874f29bf5e2fcdaf8a3f3aad3ca8e7942a5aae72616f40c9204115ad67a871b12d9f
<Vendor: 311; Attr: 17>[34]: 84b0be083d73663f7bc53c39b6e8e3b15c87803caceb59b69bd3be20c7bf44389b5e
<Vendor: 311; Attr: 26>[43]: 81533d46303745433043464232363946433145413737363131353844344639373939453044393234433138
Обнаружилась другая проблема: БЕЗ шейпа канал поднимается в соответствии с тарифом, а С шейпом канал поднимается, но открываются не все интернет-страницы, некоторые открываются и работают нормально, а некоторые вообще не открываются (данный сервер не доступен), а также нет возможности измерить скорость получившегося канала, потому как измерители попросту не открываются. Пинги идут нормально. Такое ощущение, что выдача шейпа повлияла еще на какие-то параметры связи. Ничего не понимаю...
lcp:interface-config#1=rate-limit input IN_BANDWIDTH_BITS IN_CISCO_NORMAL_BURST IN_CISCO_EXTENDED_BURST conform-action transmit exceed-action drop
lcp:interface-config#1=rate-limit output OUT_BANDWIDTH_BITS OUT_CISCO_NORMAL_BURST OUT_CISCO_EXTENDED_BURST conform-action transmit exceed-action drop
Теперь после перехода границы, судя по логам радиус-сервера, выдаются настройки скорости для канала.
?Debug : Sep 09 13:51:32 AuthServer: User <user> connecting
?Debug : Sep 09 13:51:32 AuthServer: Session for sessionid <user> not found in <172.18.1.1> cache
?Debug : Sep 09 13:51:32 RADIUS DBA: Info for login <user> found. type <1>
?Debug : Sep 09 13:51:32 AuthServer: Auth scheme: MS-CHAPv2
?Debug : Sep 09 13:51:32 AuthServer: MS-CHAPv2: Authorized user <user>
?Debug : Sep 09 13:51:32 AuthServer: MS-CHAPv2: MPPE Keys send
?Debug : Sep 09 13:51:32 AuthServer: IP claimed: 0xac1e000c (<172.30.0.12>)
?Debug : Sep 09 13:51:32 AuthServer: Calling fill radius attributes for service. Attr storage size <2>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data Vendor:<9> Attr:<1> String val:<ip:sub-qos-policy-in=1024in> Size:<27> Result:<0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data verify Size:<27>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data Vendor:<9> Attr:<1> String val:<ip:sub-qos-policy-out=1024out> Size:<29> Result:<0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data verify Size:<27>
?Debug : Sep 09 13:51:32 AuthServer: Calling fill radius attributes for slink. Attr storage size <0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data Vendor:<9> Attr:<1> String val:<lcp:interface-config#1=rate-limit output 786432 147456 294912 conform-action transmit exceed-action drop> Size:<104> Result:<0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data verify Size:<27>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data Vendor:<9> Attr:<1> String val:<lcp:interface-config#1=rate-limit input 1048576 196608 393216 conform-action transmit exceed-action drop> Size:<104> Result:<0>
?Debug : Sep 09 13:51:32 AuthServer: fill_radius_data verify Size:<27>
?Debug : Sep 09 13:51:32 AuthServer: Calling fill radius attributes for NAS. Attr storage size <0>
Notice: Sep 09 13:51:32 AuthServer: Login OK <user> from NAS <172.18.1.1> CLID <> Calling-station <>
?Debug : Sep 09 13:51:32 AuthServer: Setting interim update interval from config
?Debug : Sep 09 13:51:32 AuthServer: Auth reply: RPacket:
Code: 2; ID: 241
<Vendor: 0; Attr: 6>[4]: 00000002
<Vendor: 0; Attr: 7>[4]: 00000001
<Vendor: 0; Attr: 8>[4]: ac1e000c
<Vendor: 0; Attr: 9>[4]: ffffffff
<Vendor: 0; Attr: 27>[4]: 00015180
<Vendor: 9; Attr: 1>[27]: 69703a7375622d716f732d706f6c6963792d696e3d31303234696e
<Vendor: 9(0); Attr: 1>[29]: 69703a7375622d716f732d706f6c6963792d6f75743d313032346f7574
<Vendor: 9(1); Attr: 1>[104]: 6c63703a696e746572666163652d636f6e66696723313d726174652d6c696d6974206f75747075742037383634333220313437
<Vendor: 9(2); Attr: 1>[104]: 6c63703a696e746572666163652d636f6e66696723313d726174652d6c696d697420696e707574203130343835373620313936
<Vendor: 311; Attr: 7>[4]: 00000001
<Vendor: 311; Attr: 8>[4]: 00000006
<Vendor: 311; Attr: 16>[34]: 874f29bf5e2fcdaf8a3f3aad3ca8e7942a5aae72616f40c9204115ad67a871b12d9f
<Vendor: 311; Attr: 17>[34]: 84b0be083d73663f7bc53c39b6e8e3b15c87803caceb59b69bd3be20c7bf44389b5e
<Vendor: 311; Attr: 26>[43]: 81533d46303745433043464232363946433145413737363131353844344639373939453044393234433138
Обнаружилась другая проблема: БЕЗ шейпа канал поднимается в соответствии с тарифом, а С шейпом канал поднимается, но открываются не все интернет-страницы, некоторые открываются и работают нормально, а некоторые вообще не открываются (данный сервер не доступен), а также нет возможности измерить скорость получившегося канала, потому как измерители попросту не открываются. Пинги идут нормально. Такое ощущение, что выдача шейпа повлияла еще на какие-то параметры связи. Ничего не понимаю...
