- Покритикуйте правила 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 это такое, надо крутить и смотреть как оно реагирует)
|