Frau Опубликовано 18 мая, 2010 · Жалоба Доброго времени суток всем, есть такая проблема - дропается мультикаст схема: Принимается поток 250 ппс на 10G Интерфейс 7604, далее он роутится по ядру сети с помощью pimsm, replication mode ingress, используется qos на 7604, маркируется верно, дропов output не видно, в спане вижу как поток уходит в 250 pps. На принимающей стороне мерию поток - уже 140-150 ппс. Интерфейсы загружены на 80-90%, на принимающей стороне нет управления входящими очередями и нет соответственно никакой статистики (me3400). Пробовала положить мультикаст в strict-priority очередь - та же история, теже дропы. Дело скорее всего в настройках qos на 7604, но не могу понять где, т/к до клиента метки доходят верные Как траблшутить? Буду благодарна за любую инфу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mschedrin Опубликовано 18 мая, 2010 · Жалоба Почему бы не настроить qos на me3400? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 18 мая, 2010 · Жалоба Почему бы не настроить qos на me3400?он там настроендо этого вместо 7604-3400 было 3400-3400, дропов не было при аналогичной загрузке линков Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 18 мая, 2010 · Жалоба Доброго времени суток всем,есть такая проблема - дропается мультикаст схема: Принимается поток 250 ппс на 10G Интерфейс 7604, далее он роутится по ядру сети с помощью pimsm, replication mode ingress, используется qos на 7604, маркируется верно, дропов output не видно, в спане вижу как поток уходит в 250 pps. На принимающей стороне мерию поток - уже 140-150 ппс. Интерфейсы загружены на 80-90%, на принимающей стороне нет управления входящими очередями и нет соответственно никакой статистики (me3400). Пробовала положить мультикаст в strict-priority очередь - та же история, теже дропы. Дело скорее всего в настройках qos на 7604, но не могу понять где, т/к до клиента метки доходят верные Как траблшутить? Буду благодарна за любую инфу. Конфигу выкладывайте релевантную проблеме, с пояснениями какой порт куда подключен и загрузку каналов на фабрику. Посередине, между 7600 и 3400 есть возможность миррор сделать ? В ппсах не ошиблись, точно не кппс ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 19 мая, 2010 · Жалоба конфиг qos 10G, сюда приходит мультикаст: service-policy input PLC Policy Map PLC Class CM7 set precedence 7 Class CM0 set precedence 0 Class class-default set precedence 5 Распределение по очередям на исходящем интерфейсе: wrr-queue bandwidth percent 20 0 80 priority-queue queue-limit 20 wrr-queue queue-limit 20 0 60 wrr-queue cos-map 1 1 0 1 2 3 4 6 wrr-queue cos-map 3 1 5 priority-queue cos-map 1 7 общий конфиг мультикаста на 7604: ip multicast-routing ip multicast route-limit 200 mls ip multicast replication-mode ingress mls ip multicast flow-stat-timer 9 no mls rate-limit multicast ipv4 fib-miss no mls rate-limit multicast ipv4 partial конфиг на принимающей стороне: service-policy input PLC Policy Map PLC Class class-default set cos cos При загрузке 1G линка 76->34 в 700 mbit/s потери в мультикасте также есть Линк между 7604-3400 в тегированном режиме Миррор между ними возможности сделать естественно нет :) 250 ппс - это размер одного потока, суммарно примерно 2200 pps Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 19 мая, 2010 · Жалоба В какие карты (тип) у вас все подключено? Дайте show queueing interface для обоих интерфейсов, входящего и исходящего на 7600. Кроме мультикаста в 10G интерфейс еще что-то идет ? Линк 1GE между 7600 и 3400 в первом посте также присутсвовал, т.е. вы уменьшили нагрузку с 80-90 до 70% и все равно фиксируете дропы ? Вот это поясните - priority-queue cos-map 1 7 и чуть выше wrr-queue cos-map 1 1 0 1 2 3 4 6 Номер очереди разве может быть одинаков ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 19 мая, 2010 · Жалоба В какие карты (тип) у вас все подключено?Дайте show queueing interface для обоих интерфейсов, входящего и исходящего на 7600. Кроме мультикаста в 10G интерфейс еще что-то идет ? Линк 1GE между 7600 и 3400 в первом посте также присутсвовал, т.е. вы уменьшили нагрузку с 80-90 до 70% и все равно фиксируете дропы ? Вот это поясните - priority-queue cos-map 1 7 и чуть выше wrr-queue cos-map 1 1 0 1 2 3 4 6 Номер очереди разве может быть одинаков ? 1. карты:WS-X6708-10GE WS-X6748-GE-TX 2. в аттаче 3. Кроме мультикаста идет обычный юникастовый трафик 30 second input rate 2634358000 bits/sec, 533083 packets/sec 30 second output rate 1948363000 bits/sec, 444707 packets/sec 4. тестировалось во время минимальной загрузки линков 5. распределение 1p3q8t, очередь для strict единственная, поэтому она должна быть номер 1. Если не так, поправьте плз и дайте по возможности ссылку 1G_queueing.txt 10G_queueing.txt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 19 мая, 2010 · Жалоба В какие карты (тип) у вас все подключено?Дайте show queueing interface для обоих интерфейсов, входящего и исходящего на 7600. Кроме мультикаста в 10G интерфейс еще что-то идет ? Линк 1GE между 7600 и 3400 в первом посте также присутсвовал, т.е. вы уменьшили нагрузку с 80-90 до 70% и все равно фиксируете дропы ? Вот это поясните - priority-queue cos-map 1 7 и чуть выше wrr-queue cos-map 1 1 0 1 2 3 4 6 Номер очереди разве может быть одинаков ? 1. карты:WS-X6708-10GE WS-X6748-GE-TX 2. в аттаче 3. Кроме мультикаста идет обычный юникастовый трафик 30 second input rate 2634358000 bits/sec, 533083 packets/sec 30 second output rate 1948363000 bits/sec, 444707 packets/sec 4. тестировалось во время минимальной загрузки линков 5. распределение 1p3q8t, очередь для strict единственная, поэтому она должна быть номер 1. Если не так, поправьте плз и дайте по возможности ссылку Вы ставите преседенс в service-policy, а порт Gi3/24 у вас в mode-cos, поставьте cos. С номерами очередей ясно, цискины нюансы, все ок. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 19 мая, 2010 · Жалоба Вы ставите преседенс в service-policy, а порт Gi3/24 у вас в mode-cos, поставьте cos.С номерами очередей ясно, цискины нюансы, все ок. а как я могу выставить cos если там routed-порт? Там нет тегов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 19 мая, 2010 · Жалоба Вы ставите преседенс в service-policy, а порт Gi3/24 у вас в mode-cos, поставьте cos.С номерами очередей ясно, цискины нюансы, все ок. а как я могу выставить cos если там routed-порт? Там нет тегов Мне тут коллеги подсказывают, что set cos 7 для вашего случая не будет идиотизмом ) т.е. это внутренний cos, он дойдет до гигабитного порта и правильно разложиться в 4-ю очередь. У вас ситуация просто не тривиальная, гигабитная карта не имеет режима для очередей dscp-mode. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 20 мая, 2010 · Жалоба Мне тут коллеги подсказывают, что set cos 7 для вашего случая не будет идиотизмом )т.е. это внутренний cos, он дойдет до гигабитного порта и правильно разложиться в 4-ю очередь. У вас ситуация просто не тривиальная, гигабитная карта не имеет режима для очередей dscp-mode. не срабатывает назначение политики set cos cannot be configured on input direction for this interface Configuration failed! политика вида service-policy input PLC-C Policy Map PLC Class CM7 set cos 7 Class CM0 set cos 0 Class class-default set cos 5 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 20 мая, 2010 · Жалоба Ясно. Пока не понимаю, почему у вас не срабатывает дефолтная карта ipp-cos. Попробуйте зайти с другой стороны, поставьте set на egress порту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 20 мая, 2010 · Жалоба Ясно.Пока не понимаю, почему у вас не срабатывает дефолтная карта ipp-cos. Попробуйте зайти с другой стороны, поставьте set на egress порту. спасибо за советы, но походу у меня проблема аналогичная описанной в теме http://forum.nag.ru/forum/index.php?showtopic=55680 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 20 мая, 2010 · Жалоба К первому варианту, у меня set cos ставиться на сабинтерфейс. policy-map prioritize class prioritize set cos 2 interface Port-channel3.657 encapsulation dot1Q 657 ip address no ip redirects no ip unreachables no ip proxy-arp service-policy input prioritize interface TenGigabitEthernet1/7 no ip address load-interval 30 mls qos trust ip-precedence channel-group 3 mode active Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 20 мая, 2010 (изменено) · Жалоба Ясно.Пока не понимаю, почему у вас не срабатывает дефолтная карта ipp-cos. Попробуйте зайти с другой стороны, поставьте set на egress порту. спасибо за советы, но походу у меня проблема аналогичная описанной в теме http://forum.nag.ru/forum/index.php?showtopic=55680 Э не, там совсем о другом речь. Вы же выложили рейт юникастный, там крохи. Фабрику правда не показали. И карты у вас стандартные, на которых qos обязан работать. У вас же видны дропы в первой очереди гигабитного порта. т.е. проблема в неправильной разметке, трафик попадает в первую очередь вместо четвертой. Еще бы неплохо с секундомером посчитать нарастание дропов и сравнить с мультикастом, что-то около 220-150 в сек должно быть. Проблемка на входе, в 10G, почему-то преседенс не наследуется во внутренний dscp. Попробуйте сказать на 10G mls qos trust ip-precedence, т.е. перевести порт в трастед режим с одновременно примененной service-policy. Быть может, одной полиси недостаточно, чтобы заработало дефолтное маппирование взамен переписывания в ноль. Изменено 20 мая, 2010 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 21 мая, 2010 · Жалоба так, я окончательно запуталась в qos'е )) должно наследоваться во внутренний dscp в этих случаях: 1. когда пришло с dscp и порт в состоянии trust dscp 2. когда пришло с tos и порт в trust ip-prec 3. когда пришел заранее установленный cos в dot1q трафике, или, если cos не промаркирован, то выставляется дефолтное значение cos (как понимаю порт в trust cos) 4. service-policy на порту у меня 4-й случай, порт в режиме untrust && service-policy на порту trust на порту дает 0 tos на выходе либо я не так мониторю, т/к в неинкапсулированный спан завернут транковый порт-чэнел, и я вижу dscp в мониторинге.. с трастами я экспериментировала, все метки сбрасываются и на скорость мультикаст-потока это никак не отразилось уже не знаю, может принимающая сторона не успевает разгребать входящую очередь? с другой стороны есть картинка (в аттаче) по которой видно, что по первому же ответвлению выставится "внутренний CoS" в default port cos, в моем случае он нулевой и передасться с нулевым внутренним cos в switching engine как связать внутренние метки с "не внутренними"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 21 мая, 2010 (изменено) · Жалоба так, я окончательно запуталась в qos'е )) должно наследоваться во внутренний dscp в этих случаях: 1. когда пришло с dscp и порт в состоянии trust dscp 2. когда пришло с tos и порт в trust ip-prec 3. когда пришел заранее установленный cos в dot1q трафике, или, если cos не промаркирован, то выставляется дефолтное значение cos (как понимаю порт в trust cos) 4. service-policy на порту у меня 4-й случай, порт в режиме untrust && service-policy на порту trust на порту дает 0 tos на выходе либо я не так мониторю, т/к в неинкапсулированный спан завернут транковый порт-чэнел, и я вижу dscp в мониторинге.. с трастами я экспериментировала, все метки сбрасываются и на скорость мультикаст-потока это никак не отразилось уже не знаю, может принимающая сторона не успевает разгребать входящую очередь? с другой стороны есть картинка (в аттаче) по которой видно, что по первому же ответвлению выставится "внутренний CoS" в default port cos, в моем случае он нулевой и передасться с нулевым внутренним cos в switching engine как связать внутренние метки с "не внутренними"? Тоже перечитал доку, все вроде так. Верните конфиг взад. В случае 3, дефолт выставляется для антаггет трафика. В случае 4, порт в антрастед. т.е. у вас все правильно, порт антрастед и прикручена сервисная полиси, устанавливающая преседенс, она и должна маппиться в финальный внутренний dscp. Потом, на выходе через гигабитный порт, эта dscp мапиться в cos. Осталось понять почему у вас пакет не перекладывается в нужную очередь, или перекладывается, но вы этого не замечаете. Я не очень здорово знаю циску, можно ли в лан картах посмотреть счетчики на егресс по каждой очереди раздельно ? На ингресс точно нельзя. Какая у вас версия PFC (результирующая, наименьший деноминатор в понятии циски) и IOS ? Что значит принимающая сторона не успевает разгребать очередь ? (Какую коробку имеете в виду) Вы сказали, что делали спан на гигабитном порту 7600 и количество пакетов соответствовало норме т.е. подозреваете 3400 ? Может действительно сделать qos в траст на нем и настроить очереди. Изменено 21 мая, 2010 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 21 мая, 2010 · Жалоба Попробуйте в policy-map на входе ставить DSCP а не precedence. Так чтобы этот DSCP мапился в CoS для приоритетной очереди на выходе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 23 мая, 2010 · Жалоба ...Я не очень здорово знаю циску, можно ли в лан картах посмотреть счетчики на егресс по каждой очереди раздельно ? На ингресс точно нельзя. Какая у вас версия PFC (результирующая, наименьший деноминатор в понятии циски) и IOS ? Что значит принимающая сторона не успевает разгребать очередь ? (Какую коробку имеете в виду) Вы сказали, что делали спан на гигабитном порту 7600 и количество пакетов соответствовало норме т.е. подозреваете 3400 ? Может действительно сделать qos в траст на нем и настроить очереди. на егресс тоже нельзя смотреть счетчики по каждой очереди PFC operating mode : PFC3C Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVENTERPRISEK9-M), Version 12.2(33)SRD4, RELEASE SOFTWARE (fc2) в спане с гигабитного порта уходил поток соответствующий норме, но я видела схемку, и там после момента заворота в спан, впринципе есть еще места где может дропнуться поток Уже подозреваю 3400 то что она не может разгрести входящую очередь, т.к. вторая 76-я, которая тоже стоит на приеме, на ней потоки тоже соответствуют норме. На 3400 нельзя посмотреть статистику по очереди и дропам, у нее есть такой глюк - она ее не показывает. И к тому же, интерфейсы на 3400 1G не "разгоняются" до предела - полка 800 мбит/c. Получается в сторону 3400 у меня идет 1гбит/c, обратно 800 мбит/c, вот и думаю может у 3400 предел и она не разгребает уже пакеты? qos в trust на 10G порту я сделать не могу, т.к. это то место где я маркирую пакеты, раньше маркировать нельзя >>Попробуйте в policy-map на входе ставить DSCP а не precedence не помогает. Да и по докам поидее это одно и тоже Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 24 мая, 2010 (изменено) · Жалоба на егресс тоже нельзя смотреть счетчики по каждой очереди PFC operating mode : PFC3C Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVENTERPRISEK9-M), Version 12.2(33)SRD4, RELEASE SOFTWARE (fc2) в спане с гигабитного порта уходил поток соответствующий норме, но я видела схемку, и там после момента заворота в спан, впринципе есть еще места где может дропнуться поток Уже подозреваю 3400 то что она не может разгрести входящую очередь, т.к. вторая 76-я, которая тоже стоит на приеме, на ней потоки тоже соответствуют норме. На 3400 нельзя посмотреть статистику по очереди и дропам, у нее есть такой глюк - она ее не показывает. И к тому же, интерфейсы на 3400 1G не "разгоняются" до предела - полка 800 мбит/c. Получается в сторону 3400 у меня идет 1гбит/c, обратно 800 мбит/c, вот и думаю может у 3400 предел и она не разгребает уже пакеты? qos в trust на 10G порту я сделать не могу, т.к. это то место где я маркирую пакеты, раньше маркировать нельзя >>Попробуйте в policy-map на входе ставить DSCP а не precedence не помогает. Да и по докам поидее это одно и тоже По поводу изысканий с 7600, наверное пора закончить, думаю на ней проблем нет, я по незнанию много чего предположил ) У вас конфиг с самого начала был правильный. Посмотрите только еще раз набегают ли дропы в первой очереди через show queueing int. Остался 3400. Вот здесь посмотрите, люди пишут, что можно глянуть дропы на 3400 - http://www.gossamer-threads.com/lists/cisco/nsp/80758 Что значит не разгоняются интерфейсы, может проблема в малой выходной очереди, в ссылке тоже есть про это. Выложите конфиги 3400 по поводу коса. Изменено 24 мая, 2010 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mschedrin Опубликовано 24 мая, 2010 · Жалоба Вот как можно посмотреть дропы на 3400: sh policy-map interface g0/4 GigabitEthernet0/4 Service-policy output: queueing Class-map: control-traffic (match-all) 97697216 packets Match: ip dscp af42 (36) Priority Output Queue: Max queue-limit default threshold: 48 Tail Packets Drop: 0 Class-map: iptv (match-all) 750591 packets Match: ip dscp cs4 (32) Queue Limit queue-limit 544 (packets) Output Queue: Max queue-limit default threshold: 544 Tail Packets Drop: 0 Class-map: class-default (match-any) 727857205 packets Match: any Output Queue: Max queue-limit default threshold: 48 Tail Packets Drop: 107591 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 26 мая, 2010 · Жалоба Остался 3400.Вот здесь посмотрите, люди пишут, что можно глянуть дропы на 3400 - http://www.gossamer-threads.com/lists/cisco/nsp/80758 Что значит не разгоняются интерфейсы, может проблема в малой выходной очереди, в ссылке тоже есть про это. Выложите конфиги 3400 по поводу коса. по ссылке там очереди output, я знаю как управлять output-очередями на 3400. конфиг у меня касаемо qos на 3400: service-policy input PL-TAC service-policy output PL-OUT policy-map PL-TAC class class-default set cos cos policy-map PL-OUT class CM-7 bandwidth 200000 queue-limit 544 class CM-5 bandwidth 600000 queue-limit 544 class CM-0 bandwidth 200000 queue-limit 48 2mschedrin Вы выложили как можно посмотреть дропы на output, а я говорила об input дропах Service-policy input: PL-TAC Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Set cos cos статистика по input-очередям тут впринципе не отображается Поток не поднимается выше 1600kbps, самое странное что если запрашивают несколько потоков, то суммарная скорость их также не превышает 1600 kbps Дело не в QoS, т/к если бы было в qos, то проблема бы не проявлялась при низкой нагрузке, получается где стоит rate-limit на 3400.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 26 мая, 2010 (изменено) · Жалоба Вы не сказали, прибавляются ли счетчики в первой егресс очереди на 7600. Если прибавляются, посмотрите включена ли у вас посылка pause фреймов от 3400 к 7600 и их прием на стороне 7600. По поводу 3400, попробуйте выключить qos на нем. Поток 1,6 мбит/с это имеется в виду суммарный мультикаст ? Видно ли на 7600 в снупинге, что запрашивают несколько каналов ? Покажите вывод статистики на output по любому из двух способов, предложенных ранее, чтобы увидеть, что у вас правильно все мапиться по классам. Покажите настройки мультикаста на 3400. Если включен роутинг/снупинг, попробуйте выключить и сделать из 3400 прозрачную трубу для мультикаст трафика. Изменено 26 мая, 2010 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Frau Опубликовано 27 мая, 2010 · Жалоба Всем откликнувшимся спасибо, проблема решена. Проблема была в балансировке мультикаста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 27 мая, 2010 · Жалоба Можете подробнее пояснить ? Чтоб в голове отложилось, а то незавершенным процесс остался ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...