survivor Опубликовано 12 февраля, 2015 (изменено) · Жалоба Доброго дня Странная ситуевина - на всех интерфейсах стоит: mls qos cos override mls qos cos 0 проверяю на каждом интерфейсе свича: sh mls qos interface statistics GigabitEthernet1/0/1 dscp: incoming ------------------------------- 0 - 4 : 35376986 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 0 0 0 0 30 - 34 : 0 0 0 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 0 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 dscp: outgoing ------------------------------- 0 - 4 : 743198 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 0 0 0 0 30 - 34 : 0 0 0 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 79 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 cos: incoming ------------------------------- 0 - 4 : 35376986 0 0 0 0 5 - 7 : 0 0 0 cos: outgoing ------------------------------- 0 - 4 : 743277 0 0 0 0 5 - 7 : 0 79 0 output queues enqueued: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 743198 7402 2411 queue 2: 0 0 0 queue 3: 0 0 0 output queues dropped: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 0 0 0 queue 2: 0 0 0 queue 3: 0 0 0 Policer: Inprofile: 0 OutofProfile: 0 GigabitEthernet1/0/2 ... как видно входящих cos=5 нет (так на всех интерфейсах), есть только cos=0, как и настроено. Однако, на двух аплинк интерфейсах видно неслабый поток исходящих пакетов с cos=5: #sh mls qos interface gigabitEthernet 1/0/6 statistics GigabitEthernet1/0/6 (All statistics are in packets) dscp: incoming ------------------------------- 0 - 4 : 32287604 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 0 0 0 0 30 - 34 : 0 0 0 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 1084 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 9 0 0 0 60 - 64 : 0 0 0 0 dscp: outgoing ------------------------------- 0 - 4 : 78580585 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 0 0 0 0 30 - 34 : 0 0 0 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 4255046 0 0 0 0 45 - 49 : 0 0 0 1172 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 cos: incoming ------------------------------- 0 - 4 : 32357595 0 0 0 0 5 - 7 : 0 1094 31 cos: outgoing ------------------------------- 0 - 4 : 78660296 0 0 0 0 5 - 7 : 4255046 1172 0 output queues enqueued: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 19024500 0 0 queue 1: 126805991 7945 1979 queue 2: 0 0 0 queue 3: 0 0 0 output queues dropped: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 7156 0 0 queue 2: 0 0 0 queue 3: 0 0 0 Policer: Inprofile: 0 OutofProfile: 0 На втором то же самое. При этом таблицы в норме: #sh mls qos maps cos-dscp Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------- dscp: 0 8 16 24 32 40 48 56 #sh mls qos maps dscp-mutation Dscp-dscp mutation map: Default DSCP Mutation Map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 00 01 02 03 04 05 06 07 08 09 1 : 10 11 12 13 14 15 16 17 18 19 2 : 20 21 22 23 24 25 26 27 28 29 3 : 30 31 32 33 34 35 36 37 38 39 4 : 40 41 42 43 44 45 46 47 48 49 5 : 50 51 52 53 54 55 56 57 58 59 6 : 60 61 62 63 #sh mls qos map dscp-cos Dscp-cos map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 00 00 00 00 00 00 00 00 01 01 1 : 01 01 01 01 01 01 02 02 02 02 2 : 02 02 02 02 03 03 03 03 03 03 3 : 03 03 04 04 04 04 04 04 04 04 4 : 05 05 05 05 05 05 05 05 06 06 5 : 06 06 06 06 06 06 07 07 07 07 6 : 07 07 07 07 Откуда оно может взяться? Изменено 12 февраля, 2015 пользователем survivor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 12 февраля, 2015 · Жалоба направил этот непонятный траффик в отдельную (4-ю) очередь, которой дал наихудшие настройки и зашейпил на 100килобит. Ничего в сети не изменилось... interface GigabitEthernet1/0/6 srr-queue bandwidth share 49 49 1 1 srr-queue bandwidth shape 0 0 0 10000 queue-set 2 mls qos srr-queue output cos-map queue 4 threshold 1 5 mls qos queue-set output 2 buffers 49 49 1 1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 12 февраля, 2015 · Жалоба У Вас в таблице dscp->cos есть 45->5 и на 6м интерфейсе входящий с dscp=45. Осталось понять кто генерит такие пакеты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 12 февраля, 2015 (изменено) · Жалоба Хм, а ведь и правда - количество EF пакетов уходящих на gig1/0/6 равно (в точности) количеству EF пакетов приходящих с него... Спасибо, сам не обратил внимания не, не так, совсем уже все перед глазами перемешалось... Изменено 12 февраля, 2015 пользователем survivor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 12 февраля, 2015 · Жалоба У Вас в таблице dscp->cos есть 45->5 и на 6м интерфейсе входящий с dscp=45. Осталось понять кто генерит такие пакеты. на 6 интерфейсе приходит dscp=48 и по таблице dscp->cos он становится cos=6. Такого трафика мало и речь не о нем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 12 февраля, 2015 · Жалоба Извиняюсь. У Вас же на всех интерфейсах override в 0 выставлено. Насколько помню это действует только на входящие пакеты. В общем надо смотреть в мануалах. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 12 февраля, 2015 (изменено) · Жалоба У Вас же на всех интерфейсах override в 0 выставлено. вот-вот! Если на всех интерфейсах стоит override входящего в 0, откуда тогда может взяться исходящий 5? Он ведь должен был сначала как-то попасть на свич. Изменено 12 февраля, 2015 пользователем survivor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 12 февраля, 2015 (изменено) · Жалоба У Вас же на всех интерфейсах override в 0 выставлено. вот-вот! Если на всех интерфейсах стоит override входящего в 0, откуда тогда может взяться исходящий 5? Он ведь должен был сначала как-то попасть на свич. А разве самим свичом он не мог сгенерироваться? Я вот не уверен. Может попробовать поймать да посмотреть что это за пакетики? Поправка - исходящий у вас не 5 а 5-7 cos и 45-49 dscp. Изменено 12 февраля, 2015 пользователем NikAlexAn Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 февраля, 2015 · Жалоба Вообще бурда какая-то творится... Собрал лабу на столе. Голый свич 3750. На gig1/0/1 подается траффик (iptv multicast + data), помечаю его: interface GigabitEthernet1/0/1 service-policy input mark-iptv-stream class-map match-all iptv-stream match access-group name iptv-stream ! ! policy-map mark-iptv-stream class iptv-stream set dscp ef Пока помечаю ВЕСЬ траффик: ip access-list extended iptv-stream permit ip any any А он ни хрена не помечается: #sh mls qos interface gigabitEthernet 1/0/1 statistics GigabitEthernet1/0/1 (All statistics are in packets) dscp: incoming ------------------------------- 0 - 4 : 10197 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 0 0 0 0 30 - 34 : 0 0 0 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 7 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 dscp: outgoing ------------------------------- 0 - 4 : 172 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 0 0 0 0 30 - 34 : 0 0 0 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 0 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 cos: incoming ------------------------------- 0 - 4 : 11155 0 0 0 0 5 - 7 : 0 0 0 cos: outgoing ------------------------------- 0 - 4 : 181 0 0 0 0 5 - 7 : 0 0 0 output queues enqueued: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 1106 0 1 queue 2: 0 0 0 queue 3: 0 0 259 output queues dropped: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 0 0 0 queue 2: 0 0 0 queue 3: 0 0 0 Policer: Inprofile: 0 OutofProfile: 0 Как был 0 так и остается. Вот конфиг интерфейса: #sh mls qos interface gigabitEthernet 1/0/1 GigabitEthernet1/0/1 Attached policy-map for Ingress: mark-iptv-stream trust state: not trusted trust mode: not trusted trust enabled flag: ena COS override: dis default COS: 0 DSCP Mutation Map: Default DSCP Mutation Map Trust device: none qos mode: port-based Но самое веселое, что на выходе, на интерфейс 1/0/2: #sh mls qos interface gigabitEthernet 1/0/2 statistics GigabitEthernet1/0/2 (All statistics are in packets) dscp: incoming ------------------------------- 0 - 4 : 197 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 0 0 0 0 30 - 34 : 0 0 0 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 0 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 dscp: outgoing ------------------------------- 0 - 4 : 336 0 0 0 0 5 - 9 : 0 0 0 0 0 10 - 14 : 0 0 0 0 0 15 - 19 : 0 0 0 0 0 20 - 24 : 0 0 0 0 0 25 - 29 : 0 0 0 0 0 30 - 34 : 0 0 0 0 0 35 - 39 : 0 0 0 0 0 40 - 44 : 0 0 0 0 0 45 - 49 : 0 0 0 1 0 50 - 54 : 0 0 0 0 0 55 - 59 : 0 0 0 0 0 60 - 64 : 0 0 0 0 cos: incoming ------------------------------- 0 - 4 : 266 0 0 0 0 5 - 7 : 0 0 0 cos: outgoing ------------------------------- 0 - 4 : 1467 0 0 0 0 5 - 7 : 0 1 0 output queues enqueued: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 1180 0 1 queue 2: 0 0 0 queue 3: 0 0 336 output queues dropped: queue: threshold1 threshold2 threshold3 ----------------------------------------------- queue 0: 0 0 0 queue 1: 0 0 0 queue 2: 0 0 0 queue 3: 0 0 0 Policer: Inprofile: 0 OutofProfile: 0 что-то неизвестное гладется в очередь 4 (queue 3)!!! Хотя выходит туда только cos=0 (один пакет cos=6 не в счет). Согласно: #sh mls qos maps cos-output-q Cos-outputq-threshold map: cos: 0 1 2 3 4 5 6 7 ------------------------------------ queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-3 4-1 4-1 это может быть только cos=4,6 и 7. Но их нет!!! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 февраля, 2015 · Жалоба К слову - этот же конфиг, с разметкой dscp через policy-map прекрасно у меня работает на 3550 в рабочей сети. Проверено в боевых условиях так сказать. Что не так с 3750? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 февраля, 2015 · Жалоба Избыток чувств выразил в джипеге Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 февраля, 2015 (изменено) · Жалоба Новая вводная - через некоторое время работы свича - он вдруг перестал пропускать траффик, любой. Выключаю qos траффик появляется, включаю прекращается. Даже пинги. updated: Эта проблема похоже была связана со слишком большим размером буфера очереди, который я в сердцах задал. Очевидно просто общая память кончалась. Зависание траффика решилось сбросом размеров буферов на дефолт. Изменено 13 февраля, 2015 пользователем survivor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 13 февраля, 2015 · Жалоба А sh mls qos, sh policy-map gi1/0/1 что показывают? Глобальные команды mls qos какие? Вроде как на свичах надо ещё и глобальные mls qos команды какие то чтоб в зависимости от dscp в разные выходные очереди распихать. Конкретно в вашем случае надо ли полиси мапом dscp выставлять, может просто cos rewrite в нужный на входящем порту? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 февраля, 2015 (изменено) · Жалоба Конкретно в вашем случае надо ли полиси мапом dscp выставлять, может просто cos rewrite в нужный на входящем порту? да, потому что на входящем порту есть и интернет и тв, нужно только тв помечать. Вообщем кое-что у меня получилось: 1)Получилось размечивать тв отдельно от данных 2)Получилось класть тв в нужную очередь 3)Получилось настроить эту очередь так чтобы она никогда не дропалась Рабочий конфиг такой: mls qos srr-queue output cos-map queue 1 threshold 3 5 mls qos queue-set output 2 threshold 1 1000 1000 100 2000 ! class-map match-all iptv-stream match access-group name iptv-stream ! policy-map mark-iptv-stream class iptv-stream set dscp ef ! interface GigabitEthernet1/0/1 service-policy input mark-iptv-stream interface GigabitEthernet1/0/2 queue-set 2 priority-queue out ! ip access-list extended iptv-stream permit ip x.x.x.x 0.0.0.7 host 239.xxx.xxx.13 permit ip x.x.x.x 0.0.0.7 host 239.xxx.xxx.24 ... Заработало это все после того как я убрал из access-list'а строчку permit ip any any и убрал настройки входящей очереди. Какие проблемы остались? Собственно - сабж. По прежнему на gig1/0/2 что-то выходит в четвертой очереди (queue 3), хотя ни по конфигу, ни по "cos: outgoing" или "dscp: outgoing" в этой очереди ничего быть не должно. Есть мысли на этот счет? Ну и опять встала проблема входящей очереди. На 3750 по умолчанию cos=5 кладется в очередь 2, которая хоть и priority, но ограничена 40% от bandwidth, что мне не приемлемо. Сейчас эти настройки по умолчанию, только так корректно заработала исходящая приоритезация... У меня было так: mls qos srr-queue input bandwidth 100 1 mls qos srr-queue input buffers 100 0 mls qos srr-queue input priority-queue 2 bandwidth 0 mls qos srr-queue input cos-map queue 1 threshold 1 5 Изменено 13 февраля, 2015 пользователем survivor Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 13 февраля, 2015 · Жалоба Тесты на столе показали что на входящую очередь можно смело забить и оставить ее по умолчанию, а то что не влазит в приоритетные 40% потом нормально делится SRR c первой очередью. Ни визуально, ни анализатором это никак не заметно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...