- Покритикуйте правила QoS,
 vigogne, 11:35 , 02-Апр-14 (1)А вот для Huawei (делал сам, так что прошу более детально просмотреть, хотя бы на соответствие QoS у Cisco:
#
# - Хоть и включил использование SAC глобально и на интерфейсе, так и не смог заставить его работать в политике QoS, поэтому пришлось делать по портам
#
acl name TRANSACTIONAL-DATA 3992
rule 5 permit tcp destination-port eq www
rule 10 permit tcp destination-port eq 443
rule 15 permit tcp destination-port eq 1433
rule 20 permit tcp destination-port range 5222 5223
acl name NETWORK-MANAGEMENT 3993
rule 5 permit tcp destination-port eq domain
rule 10 permit udp destination-port eq dns
acl name BULK-DATA 3994
rule 5 permit tcp destination-port range ftp-data ftp
rule 10 permit tcp destination-port eq smtp
rule 15 permit tcp destination-port eq pop3
acl name VoIP-RTP 3995
rule 5 permit udp destination-port range 16384 32767
acl name VoIP-Control 3996
rule 5 permit tcp destination-port eq 1720
rule 10 permit tcp destination-port range 11000 11999
rule 15 permit udp destination-port eq 2427
rule 20 permit tcp destination-port eq 2428
rule 25 permit tcp destination-port range 2000 2002
rule 30 permit udp destination-port eq 1719
rule 35 permit udp destination-port eq 5060
acl name ACL-QoS-Video 3997
rule 5 permit tcp destination-port eq 4500
rule 10 permit tcp destination-port eq 4600
#
traffic classifier ROUTING operator or
if-match dscp cs6
traffic classifier BULK-DATA operator or
if-match dscp af11
if-match acl BULK-DATA
traffic classifier MISSION-CRITICAL-DATA operator or
if-match dscp 25
traffic classifier VOICE operator or
if-match dscp ef
if-match acl VoIP-RTP
traffic classifier VOICE-CONTROL operator or
if-match dscp cs3 af31
if-match acl VoIP-Control
traffic classifier NETWORK-MANAGEMENT operator or
if-match dscp cs2
if-match acl NETWORK-MANAGEMENT
traffic classifier VIDEO-CONFERENCING operator or
if-match dscp af41
traffic classifier STREAMING-VIDEO operator or
if-match dscp cs4
if-match acl ACL-QoS-Video
traffic classifier TRANSACTIONAL-DATA operator or
if-match dscp af21
if-match acl TRANSACTIONAL-DATA
traffic classifier SCAVENGER-DATA operator or
if-match dscp cs1
#
traffic behavior ROUTING
car cir pct 3 green pass yellow pass red discard
statistic enable
traffic behavior BULK-DATA
car cir pct 4 green pass yellow pass red discard
remark dscp cs1
statistic enable
traffic behavior MISSION-CRITICAL-DATA
remark dscp af31
queue llq bandwidth pct 12
statistic enable
traffic behavior class-default
car cir pct 18 green pass yellow pass red discard
queue wfq
statistic enable
traffic behavior VOICE
remark dscp ef
car cir pct 20 green pass yellow pass red discard
statistic enable
queue llq bandwidth pct 20
traffic behavior VOICE-CONTROL
remark dscp cs5
car cir pct 2 green pass yellow pass red discard
statistic enable
traffic behavior NETWORK-MANAGEMENT
remark dscp cs2
car cir pct 2 green pass yellow pass red discard
statistic enable
traffic behavior VIDEO-CONFERENCING
car cir pct 20 green pass yellow pass red discard
remark dscp cs5
statistic enable
traffic behavior STREAMING-VIDEO
remark dscp af21
car cir pct 10 green pass yellow pass red discard
statistic enable
traffic behavior TRANSACTIONAL-DATA
remark dscp cs3
queue llq bandwidth pct 8
statistic enable
traffic behavior SCAVENGER-DATA
remark dscp default
car cir pct 1 green pass yellow pass red discard
statistic enable
#
traffic policy WAN-EDGE
classifier ROUTING behavior ROUTING
classifier VOICE behavior VOICE
classifier VIDEO-CONFERENCING behavior VIDEO-CONFERENCING
classifier STREAMING-VIDEO behavior STREAMING-VIDEO
classifier MISSION-CRITICAL-DATA behavior MISSION-CRITICAL-DATA
classifier VOICE-CONTROL behavior VOICE-CONTROL
classifier TRANSACTIONAL-DATA behavior TRANSACTIONAL-DATA
classifier NETWORK-MANAGEMENT behavior NETWORK-MANAGEMENT
classifier BULK-DATA behavior BULK-DATA
classifier SCAVENGER-DATA behavior SCAVENGER-DATA
#
# Хуавей, в отличие от Cisco позволяет навешивать политику QoS на туннельные интерфейсы, поэтому не стал приводить конфиг интерфейса-аплинка.
#
interface Tunnel0/0/0
mtu 1472
bandwidth 10
tcp adjust-mss 1432
ip address 10.45.253.150 255.255.255.252
tunnel-protocol gre
source GigabitEthernet0/0/2
destination 192.168.200.2
gre key 456
traffic-policy WAN-EDGE outbound
ospf cost 1
ospf mtu-enable
ospf dr-priority 2
ospf timer hello 30
ospf bfd enable
ospf bfd frr-binding
ospf enable 45 area 0.0.0.0
- Покритикуйте правила QoS, GolDi, 16:11 , 02-Апр-14 (2)
>[оверквотинг удален]
> destination 192.168.200.2
> gre key 456
> traffic-policy WAN-EDGE outbound
> ospf cost 1
> ospf mtu-enable
> ospf dr-priority 2
> ospf timer hello 30
> ospf bfd enable
> ospf bfd frr-binding
> ospf enable 45 area 0.0.0.0 Чтобы что-то оценить, посмотрите статистику .
- Покритикуйте правила QoS, vigogne, 17:40 , 02-Апр-14 (3)
>[оверквотинг удален]
>> gre key 456
>> traffic-policy WAN-EDGE outbound
>> ospf cost 1
>> ospf mtu-enable
>> ospf dr-priority 2
>> ospf timer hello 30
>> ospf bfd enable
>> ospf bfd frr-binding
>> ospf enable 45 area 0.0.0.0
> Чтобы что-то оценить, посмотрите статистику .Это все понятно, я же говорил, что все работает, НО, все это делалось, без твердой уверенности, что это самый оптимальный конфиг, и, может быть, можно сделать хоть что-то, но лучше, оптимальнее, быстрее, и т.п. Более того, если даже взять за идеал конфиг прежнего админа на цисках, нет уверенности в идентичности переноса этого конфига на хуавеи.
Именно это я и прошу у более опытных коллег.
- Покритикуйте правила QoS, vigogne, 12:27 , 18-Апр-14 (4)
Неужели знатоки данной темы перевелись?
- Покритикуйте правила QoS, burner, 16:36 , 10-Июн-14 (5)
> Неужели знатоки данной темы перевелись?А почему бы не маркировать трафик не на исходящем интерфейсе, а на входящем?
Т.е. вы на исходящем интерфейсе одновременно и нарезаете полосу и красите трафик. ИМХО, лучше будет на даунлинке в уровень агрегации, весь входящий трафик маркировать. А вот на аплинке уже нарезать полосы согласно маркировке.
Пока у вас один аплинк - разницы не будет, когда их будет больше, такая схема будет гибче.
- Покритикуйте правила QoS, vigogne, 07:45 , 11-Июн-14 (6)
>> Неужели знатоки данной темы перевелись?
> А почему бы не маркировать трафик не на исходящем интерфейсе, а на
> входящем?
> Т.е. вы на исходящем интерфейсе одновременно и нарезаете полосу и красите трафик.
> ИМХО, лучше будет на даунлинке в уровень агрегации, весь входящий трафик
> маркировать. А вот на аплинке уже нарезать полосы согласно маркировке.
> Пока у вас один аплинк - разницы не будет, когда их будет
> больше, такая схема будет гибче.Хмм, а можно небольшой пример? Что-то я не врубаюсь, как это будет работать...
- Покритикуйте правила QoS, burner, 10:16 , 11-Июн-14 (7) +1
>>> Неужели знатоки данной темы перевелись?
>> А почему бы не маркировать трафик не на исходящем интерфейсе, а на
>> входящем?
>> Т.е. вы на исходящем интерфейсе одновременно и нарезаете полосу и красите трафик.
>> ИМХО, лучше будет на даунлинке в уровень агрегации, весь входящий трафик
>> маркировать. А вот на аплинке уже нарезать полосы согласно маркировке.
>> Пока у вас один аплинк - разницы не будет, когда их будет
>> больше, такая схема будет гибче.
> Хмм, а можно небольшой пример? Что-то я не врубаюсь, как это будет
> работать...маркировать трафик нужно как можно ближе к источнику.
Если не хочется заморачиваться с маркировкой на L2, то тогда стоит промаркировать трафик в той точке, где у вас "впервые" появляется трафик на L3, а это даунлинк на уровень агрегации К примеру
int gi0/0
desciption DOWNLINK
service-policy input MARK class-map match-any MARK-BULK-DATA
match protocol ftp
match protocol smtp
match protocol pop3
match protocol exchange class-map match-any MARK-TRANSACTIONAL-DATA
match protocol telnet
match protocol ssh
match protocol irc
match protocol sqlnet
match protocol sqlserver
match protocol notes
match protocol http policy map MARK
class MARK-BULK-DATA
set dscp cs1
class MARK-TRANSACTIONAL-DATA
set dscp cs2 Теперь у вас весь трафик промаркирован и дальше можно принимать решение о нарезании полосы int gi0/1
description UPLINK
service-policy output WAN-EDGE class-map BULK-DATA
match dscp cs1 class-map TRANSACTIONAL-DATA
match dscp cs2 policy map WAN-EDGE
class TRANSACTIONAL-DATA
bandwidth percent 8
random-detect
class BULK-DATA
bandwidth percent 4
random-detect В этом случае, у вас на нарезание полосы отдельная политика и вы работаете уже с промаркированным ранее трафиком. Политика для маркировки - универсальная, ее можно как шаблон вешать на любой даунлинк в локалку. Политика нарезания уже может быть разной для каждого канала.
Допустим у вас появится еще один канал, в котором вы планируете пускать в основном голос. И голос должен иметь полный приоритет и голосового трафика вы будете пускать там значительно больше чем остального. В моем примере вам достаточно будет на исходящую политику этого канала повесить политику по которой для уже промаркированного трафика вы выделите 70 процентов полосы. В вашем примере вам нужно будет вешать эту полную политику маркировки трафика и нарезания. А это дополнительная нагрузка на роутер.
- Покритикуйте правила QoS, vigogne, 11:00 , 11-Июн-14 (8)
>[оверквотинг удален]
> работаете уже с промаркированным ранее трафиком. Политика для маркировки - универсальная,
> ее можно как шаблон вешать на любой даунлинк в локалку. Политика
> нарезания уже может быть разной для каждого канала.
> Допустим у вас появится еще один канал, в котором вы планируете пускать
> в основном голос. И голос должен иметь полный приоритет и голосового
> трафика вы будете пускать там значительно больше чем остального. В моем
> примере вам достаточно будет на исходящую политику этого канала повесить политику
> по которой для уже промаркированного трафика вы выделите 70 процентов полосы.
> В вашем примере вам нужно будет вешать эту полную политику маркировки
> трафика и нарезания. А это дополнительная нагрузка на роутер.Огромное спасибо за науку! Пересмотрю свои правила.
А по существу соответствия моих политик между цисками и хуавеями ничего не можете подсказать?
- Покритикуйте правила QoS, burner, 12:04 , 11-Июн-14 (9)
> Огромное спасибо за науку! Пересмотрю свои правила.
> А по существу соответствия моих политик между цисками и хуавеями ничего не
> можете подсказать?Не за что, лучше чтобы все таки кто то из опытных проверил,ибо практических навыков у меня тоже не густо (только вышел с курса по qos и сейчас занимаюсь внедрением у себя)
С хуавеями не работал) у меня вопрос по этой политике
policy-map OUT-QOS
class class-default
shape average percent 90
service-policy WAN-EDGE Для чего вы это делаете?
Вы вешаете родительскую политику на физический интерфейс,на котором указана ширина. После этого шейпите все до 90 процентов.
По поводу эффективности самих политик - тут нужно смотреть на реальном трафике под нагрузкой. + MISSION-CRITICAL-DATA включен RED. Какой там трафик, имеет смысл его там включать?
- Покритикуйте правила QoS, vigogne, 12:46 , 11-Июн-14 (10)
> у меня вопрос по этой политике
> policy-map OUT-QOS
> class class-default
> shape average percent 90
> service-policy WAN-EDGE
> Для чего вы это делаете?
> Вы вешаете родительскую политику на физический интерфейс,на котором указана ширина. После
> этого шейпите все до 90 процентов.
> По поводу эффективности самих политик - тут нужно смотреть на реальном трафике
> под нагрузкой. + MISSION-CRITICAL-DATA включен RED. Это делал админ головной организации, но, насколько я помню, такая конструкция возникла, когда топология сети изменилась с L2 на L3 и пришлось использовать подинтерфейсы и туннельные интерфейсы, но точнее сейчас уже сказать не смогу. Поправьте, если видите, что это не правильно. > Какой там трафик, имеет смысл его там включать? Под MISSION-CRITICAL-DATA матчится dscp 25, но похоже, что такой трафик вообще не проходит через эти интерфейсы:
sh policy-map interface po1.170 output class MISSION-CRITICAL-DATA
Port-channel1.170 Service-policy output: TTK-OUT-QOS Class-map: MISSION-CRITICAL-DATA (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp 25
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 139
Bandwidth 12 (%)
Bandwidth 245 (kbps)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
exponential weight: 9
mean queue depth: 0 class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 0/0 0/0 0/0 20 40 1/10
1 0/0 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 30 40 1/10
6 0/0 0/0 0/0 32 40 1/10
7 0/0 0/0 0/0 34 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10 QoS Set
dscp af31
Packets marked 0 Вообще, в подразделениях, где стоят каталисты, включен mls qos, и по идее, устройства, маркирующие свой трафик должны нормально его передавать раскрашенным. Но вообще, конечно, тоже не мешало бы пройти этот курс... Вот только ни времени ни ресурсов... В общем, как обычно, приходится все изучать в процессе :)
- Покритикуйте правила QoS, burner, 14:44 , 11-Июн-14 (11) +1
> Но вообще, конечно, тоже не мешало бы пройти этот курс... Вот только
> ни времени ни ресурсов... В общем, как обычно, приходится все изучать
> в процессе :) Курс офигенный, сознание расширяет) Тут такой момент, у вас политика для туннеля, но висит на интерфейсе физическом. Когда есть необходимость повесить политику на виртуальный интерфейс - без полисера\шейпера не обойтись, но с физическим интерфейсом это добровольно. Мой основной позыв был - а почему шейпим именно до 90%? Почему не шейпить на все 10 мбит которые у вас есть. Если я правильно понимаю, сейчас у вас в туннеле максимум 9 мбит может пролезть, дальше все попадет в буфер шейпера.
Если были макс нагрузки на канал, посмотрите по мониторингу полка на каком уровне была. Может имеет смысл чуть поднять CIR шейпера По DSCP 25. Ей рекомендуют маркировать mission-critical трафик, но вы сами его нигде не промаркировали. Не думаю, что есть много приложений или устройств, которые сами маркируют так свой трафик (+ для этого вы должны доверять DSCP меткам на L2) Хотя может я и ошибаюсь)
- Покритикуйте правила QoS, vigogne, 08:57 , 17-Июн-14 (12)
>[оверквотинг удален]
> Курс офигенный, сознание расширяет)
> Тут такой момент, у вас политика для туннеля, но висит на интерфейсе
> физическом. Когда есть необходимость повесить политику на виртуальный интерфейс - без
> полисера\шейпера не обойтись, но с физическим интерфейсом это добровольно. Мой основной
> позыв был - а почему шейпим именно до 90%? Почему не
> шейпить на все 10 мбит которые у вас есть. Если я
> правильно понимаю, сейчас у вас в туннеле максимум 9 мбит может
> пролезть, дальше все попадет в буфер шейпера.
> Если были макс нагрузки на канал, посмотрите по мониторингу полка на каком
> уровне была. Может имеет смысл чуть поднять CIR шейпера Огромное спасибо! Принял во внимание, поправлю.
Еще один вопрос, если на нескольких физических интерфейсах, объединенных в PortChannel, висят куча подинтерфейсов, (на каждом подинтерфейсе свой bandwith) на которых организованы либо простая L3, либо GRE-туннели с опцией qos pre-classify, то как в этом случае настраивать qos? Вешать полисер на родительский портчаннел или на каждый подинтерфейс, или вообще лучше на каждый туннель? Я тут, если честно, совсем запутался.
- Покритикуйте правила QoS, burner, 13:09 , 17-Июн-14 (13)
> Огромное спасибо! Принял во внимание, поправлю.
> Еще один вопрос, если на нескольких физических интерфейсах, объединенных в PortChannel,
> висят куча подинтерфейсов, (на каждом подинтерфейсе свой bandwith) на которых организованы
> либо простая L3, либо GRE-туннели с опцией qos pre-classify, то как
> в этом случае настраивать qos? Вешать полисер на родительский портчаннел или
> на каждый подинтерфейс, или вообще лучше на каждый туннель? Я тут,
> если честно, совсем запутался.QoS pre-classify по сути делает что:
Перед инкапсуляцией трафика эта функция делает копию ip header`а оригинального пакета и после его инкапсуляции информацию о метке вы берете из этой копии. С этой функцией, мы можем на физическом интерфейсе резать полосу для шифрованного трафика, как если бы он был нешифрованным.Т.е. он должен висеть на всех туннелях(ipsec\gre), трафик которых вы хотите обрабатывать политикой.
А вот куда вешать полиси...Эх, не наврать бы.
Если память не изменяет, в такой ситуации нужно вешать на каждый интерфейс отдельно, одинаковую полиси.
Но думаю многое зависит от ситуации и задачи. Вот тут вешают полиси на интерфейс и на виртуальный интерфейс.
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/con...
- Покритикуйте правила QoS, vigogne, 13:24 , 17-Июн-14 (14)
>[оверквотинг удален]
> после его инкапсуляции информацию о метке вы берете из этой копии.
> С этой функцией, мы можем на физическом интерфейсе резать полосу для
> шифрованного трафика, как если бы он был нешифрованным.Т.е. он должен висеть
> на всех туннелях(ipsec\gre), трафик которых вы хотите обрабатывать политикой.
> А вот куда вешать полиси...Эх, не наврать бы.
> Если память не изменяет, в такой ситуации нужно вешать на каждый интерфейс
> отдельно, одинаковую полиси.
> Но думаю многое зависит от ситуации и задачи. Вот тут вешают полиси
> на интерфейс и на виртуальный интерфейс.
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/con... Да, в целом понял, тут по принципу матрешки - на физические интерфейсы вешаем некую родительскую политику, на подинтерфейсы PortChannel вешаем следующие политики, а собственно на последующие виртуальные интерфейсы можно и qos preclassify вешать.
Но, судя по счетчикам политик и по загрузке трафика в 90% от максимума - у меня все работало и так.
Еще доберусь, и по первой Вашей подсказке, разделю политики раскраски и шейпинга для более оптимальной нагрузки на проц и вообще все в шоколаде будет :) Хотя и сейчас нагрузка в среднем за 72 часа редко превышает 30%, так что это чисто в исследовательских целях :))
Но тема очень интересная, будем углубляться :) Спасибо Вам за советы и ценные указания! :) - Покритикуйте правила QoS, burner, 08:28 , 18-Июн-14 (15)
>[оверквотинг удален]
> вешаем некую родительскую политику, на подинтерфейсы PortChannel вешаем следующие политики,
> а собственно на последующие виртуальные интерфейсы можно и qos preclassify вешать.
> Но, судя по счетчикам политик и по загрузке трафика в 90% от
> максимума - у меня все работало и так.
> Еще доберусь, и по первой Вашей подсказке, разделю политики раскраски и шейпинга
> для более оптимальной нагрузки на проц и вообще все в шоколаде
> будет :) Хотя и сейчас нагрузка в среднем за 72 часа
> редко превышает 30%, так что это чисто в исследовательских целях :))
> Но тема очень интересная, будем углубляться :)
> Спасибо Вам за советы и ценные указания! :) Не за что)
QoS это такое, надо крутить и смотреть как оно реагирует)
|
Версия для распечатки
Покритикуйте правила QoS, 
