https://mobile.opennet.me/openforum/vsluhforumID6/1292.html Добрый день!<br><br>Есть небольшая распределенная сеть, построенная на Cisco и Huawei AR2200. Каналы между ними построены на динамических туннелях (DMVPN) между цисками и статическими GRE-туннелями между Huawei'ями и цетром. По 10 Мбит до подразделений, и 100 Мбит до центра. Помимо обычной деятельности сети (почта, web, FTP, RDP и т.п.) есть приоритетный трафик (VoIP, видеоконференции и видеонаблюдение).<br>Вроде бы все нормально работает, голос не заикается, видеоконференции идут, видеонаблюдение хоть и с разрывами, но осуществляется. Но, как говорится, мятежный ум ищет себе чем заморочиться. Вот и я подумал, может кто-то предложит более оптимальные правила QoS.<br><br>Вот для Cisco (делал не я):<br><br>class-map match-any STREAMING-VIDEO<br> match ip dscp cs4 <br> match access-group name ACL-QoS-Video<br>class-map match-any BULK-DATA<br> match ip dscp af11 <br> match protocol ftp<br> match protocol smtp<br> match protocol pop3<br> match protocol exchange<br>class-map match-any VOICE-CONTROL<br> match ip dscp cs3 <br> match ip dscp af31 <br> ma https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#15 Wed, 18 Jun 2014 04:28:48 GMT &gt;[оверквотинг удален]<br>&gt; вешаем некую родительскую политику, на подинтерфейсы PortChannel вешаем следующие политики, <br>&gt; а собственно на последующие виртуальные интерфейсы можно и qos preclassify вешать. <br>&gt; Но, судя по счетчикам политик и по загрузке трафика в 90% от <br>&gt; максимума - у меня все работало и так.<br>&gt; Еще доберусь, и по первой Вашей подсказке, разделю политики раскраски и шейпинга <br>&gt; для более оптимальной нагрузки на проц и вообще все в шоколаде <br>&gt; будет :) Хотя и сейчас нагрузка в среднем за 72 часа <br>&gt; редко превышает 30%, так что это чисто в исследовательских целях :)) <br>&gt; Но тема очень интересная, будем углубляться :) <br>&gt; Спасибо Вам за советы и ценные указания! :) <br><br>Не за что)<br>QoS это такое, надо крутить и смотреть как оно реагирует)<br><br> https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#14 Tue, 17 Jun 2014 09:24:26 GMT &gt;[оверквотинг удален]<br>&gt; после его инкапсуляции информацию о метке вы берете из этой копии. <br>&gt; С этой функцией, мы можем на физическом интерфейсе резать полосу для <br>&gt; шифрованного трафика, как если бы он был нешифрованным.Т.е. он должен висеть <br>&gt; на всех туннелях(ipsec\gre), трафик которых вы хотите обрабатывать политикой.<br>&gt; А вот куда вешать полиси...Эх, не наврать бы.<br>&gt; Если память не изменяет, в такой ситуации нужно вешать на каждый интерфейс <br>&gt; отдельно, одинаковую полиси.<br>&gt; Но думаю многое зависит от ситуации и задачи. Вот тут вешают полиси <br>&gt; на интерфейс и на виртуальный интерфейс.<br>&gt; http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-3s/qos-mqc-xe-3s-book/qos-eth-int.html <br><br>Да, в целом понял, тут по принципу матрешки - на физические интерфейсы вешаем некую родительскую политику, на подинтерфейсы PortChannel вешаем следующие политики, а собственно на последующие виртуальные интерфейсы можно и qos preclassify вешать.<br>Но, судя по счетчикам политик и по загрузке трафика https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#13 Tue, 17 Jun 2014 09:09:40 GMT &gt; Огромное спасибо! Принял во внимание, поправлю.<br>&gt; Еще один вопрос, если на нескольких физических интерфейсах, объединенных в PortChannel, <br>&gt; висят куча подинтерфейсов, (на каждом подинтерфейсе свой bandwith) на которых организованы <br>&gt; либо простая L3, либо GRE-туннели с опцией qos pre-classify, то как <br>&gt; в этом случае настраивать qos? Вешать полисер на родительский портчаннел или <br>&gt; на каждый подинтерфейс, или вообще лучше на каждый туннель? Я тут, <br>&gt; если честно, совсем запутался.<br><br>QoS pre-classify по сути делает что:<br>Перед инкапсуляцией трафика эта функция делает копию ip header`а оригинального пакета и после его инкапсуляции информацию о метке вы берете из этой копии. С этой функцией, мы можем на физическом интерфейсе резать полосу для шифрованного трафика, как если бы он был нешифрованным.Т.е. он должен висеть на всех туннелях(ipsec\gre), трафик которых вы хотите обрабатывать политикой.<br>А вот куда вешать полиси...Эх, не наврать бы. <br>Если память не изменяет, в такой ситуации нужно вешать на каж https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#12 Tue, 17 Jun 2014 04:57:29 GMT &gt;[оверквотинг удален]<br>&gt; Курс офигенный, сознание расширяет) <br>&gt; Тут такой момент, у вас политика для туннеля, но висит на интерфейсе <br>&gt; физическом. Когда есть необходимость повесить политику на виртуальный интерфейс - без <br>&gt; полисера\шейпера не обойтись, но с физическим интерфейсом это добровольно. Мой основной <br>&gt; позыв был - а почему шейпим именно до 90%? Почему не <br>&gt; шейпить на все 10 мбит которые у вас есть. Если я <br>&gt; правильно понимаю, сейчас у вас в туннеле максимум 9 мбит может <br>&gt; пролезть, дальше все попадет в буфер шейпера.<br>&gt; Если были макс нагрузки на канал, посмотрите по мониторингу полка на каком <br>&gt; уровне была. Может имеет смысл чуть поднять CIR шейпера <br><br>Огромное спасибо! Принял во внимание, поправлю. <br>Еще один вопрос, если на нескольких физических интерфейсах, объединенных в PortChannel, висят куча подинтерфейсов, (на каждом подинтерфейсе свой bandwith) на которых организованы либо простая L3, либо GRE-туннели с опцией qos pre-classify, то как в этом случае настраивать qos? Вешать п https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#11 Wed, 11 Jun 2014 10:44:04 GMT &gt; Но вообще, конечно, тоже не мешало бы пройти этот курс... Вот только <br>&gt; ни времени ни ресурсов... В общем, как обычно, приходится все изучать <br>&gt; в процессе :) <br><br>Курс офигенный, сознание расширяет)<br><br>Тут такой момент, у вас политика для туннеля, но висит на интерфейсе физическом. Когда есть необходимость повесить политику на виртуальный интерфейс - без полисера\шейпера не обойтись, но с физическим интерфейсом это добровольно. Мой основной позыв был - а почему шейпим именно до 90%? Почему не шейпить на все 10 мбит которые у вас есть. Если я правильно понимаю, сейчас у вас в туннеле максимум 9 мбит может пролезть, дальше все попадет в буфер шейпера.<br>Если были макс нагрузки на канал, посмотрите по мониторингу полка на каком уровне была. Может имеет смысл чуть поднять CIR шейпера<br><br>По DSCP 25. Ей рекомендуют маркировать mission-critical трафик, но вы сами его нигде не промаркировали. Не думаю, что есть много приложений или устройств, которые сами маркируют так свой трафик (+ для этого вы должны доверять DS https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#10 Wed, 11 Jun 2014 08:46:43 GMT &gt; у меня вопрос по этой политике <br>&gt; policy-map OUT-QOS <br>&gt; class class-default <br>&gt; shape average percent 90 <br>&gt; service-policy WAN-EDGE <br>&gt; Для чего вы это делаете?<br>&gt; Вы вешаете родительскую политику на физический интерфейс,на котором указана ширина. После <br>&gt; этого шейпите все до 90 процентов.<br>&gt; По поводу эффективности самих политик - тут нужно смотреть на реальном трафике <br>&gt; под нагрузкой. + MISSION-CRITICAL-DATA включен RED. <br><br>Это делал админ головной организации, но, насколько я помню, такая конструкция возникла, когда топология сети изменилась с L2 на L3 и пришлось использовать подинтерфейсы и туннельные интерфейсы, но точнее сейчас уже сказать не смогу. Поправьте, если видите, что это не правильно.<br><br>&gt; Какой там трафик, имеет смысл его там включать?<br><br>Под MISSION-CRITICAL-DATA матчится dscp 25, но похоже, что такой трафик вообще не проходит через эти интерфейсы:<br>sh policy-map interface po1.170 output class MISSION-CRITICAL-DATA<br> Port-channel1.170 <br><br> Service-policy output: TTK-OUT-QOS<br> https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#9 Wed, 11 Jun 2014 08:04:52 GMT &gt; Огромное спасибо за науку! Пересмотрю свои правила.<br>&gt; А по существу соответствия моих политик между цисками и хуавеями ничего не <br>&gt; можете подсказать?<br><br>Не за что, лучше чтобы все таки кто то из опытных проверил,ибо практических навыков у меня тоже не густо (только вышел с курса по qos и сейчас занимаюсь внедрением у себя)<br>С хуавеями не работал)<br><br>у меня вопрос по этой политике<br>policy-map OUT-QOS<br>class class-default<br> shape average percent 90<br> service-policy WAN-EDGE <br><br>Для чего вы это делаете?<br>Вы вешаете родительскую политику на физический интерфейс,на котором указана ширина. После этого шейпите все до 90 процентов. <br>По поводу эффективности самих политик - тут нужно смотреть на реальном трафике под нагрузкой. + MISSION-CRITICAL-DATA включен RED. Какой там трафик, имеет смысл его там включать?<br> https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#8 Wed, 11 Jun 2014 07:00:30 GMT &gt;[оверквотинг удален]<br>&gt; работаете уже с промаркированным ранее трафиком. Политика для маркировки - универсальная, <br>&gt; ее можно как шаблон вешать на любой даунлинк в локалку. Политика <br>&gt; нарезания уже может быть разной для каждого канала.<br>&gt; Допустим у вас появится еще один канал, в котором вы планируете пускать <br>&gt; в основном голос. И голос должен иметь полный приоритет и голосового <br>&gt; трафика вы будете пускать там значительно больше чем остального. В моем <br>&gt; примере вам достаточно будет на исходящую политику этого канала повесить политику <br>&gt; по которой для уже промаркированного трафика вы выделите 70 процентов полосы. <br>&gt; В вашем примере вам нужно будет вешать эту полную политику маркировки <br>&gt; трафика и нарезания. А это дополнительная нагрузка на роутер.<br><br>Огромное спасибо за науку! Пересмотрю свои правила. <br>А по существу соответствия моих политик между цисками и хуавеями ничего не можете подсказать?<br> https://mobile.opennet.me/openforum/vsluhforumID6/1292.html#7 Wed, 11 Jun 2014 06:16:29 GMT &gt;&gt;&gt; Неужели знатоки данной темы перевелись?<br>&gt;&gt; А почему бы не маркировать трафик не на исходящем интерфейсе, а на <br>&gt;&gt; входящем?<br>&gt;&gt; Т.е. вы на исходящем интерфейсе одновременно и нарезаете полосу и красите трафик.<br>&gt;&gt; ИМХО, лучше будет на даунлинке в уровень агрегации, весь входящий трафик <br>&gt;&gt; маркировать. А вот на аплинке уже нарезать полосы согласно маркировке.<br>&gt;&gt; Пока у вас один аплинк - разницы не будет, когда их будет <br>&gt;&gt; больше, такая схема будет гибче.<br>&gt; Хмм, а можно небольшой пример? Что-то я не врубаюсь, как это будет <br>&gt; работать...<br><br>маркировать трафик нужно как можно ближе к источнику.<br>Если не хочется заморачиваться с маркировкой на L2, то тогда стоит промаркировать трафик в той точке, где у вас "впервые" появляется трафик на L3, а это даунлинк на уровень агрегации<br><br>К примеру<br>int gi0/0<br>desciption DOWNLINK<br>service-policy input MARK<br><br>class-map match-any MARK-BULK-DATA<br>match protocol ftp<br>match protocol smtp<br>match protocol pop3<br>match protocol exchange<br><br>class-map match-any MARK-TRAN