помогите с траблшутингом мультикаста

[Frau]

Доброго времени суток всем,

есть такая проблема - дропается мультикаст

схема:

Принимается поток 250 ппс на 10G Интерфейс 7604, далее он роутится по ядру сети с помощью pimsm, replication mode ingress, используется qos на 7604, маркируется верно, дропов output не видно, в спане вижу как поток уходит в 250 pps. На принимающей стороне мерию поток - уже 140-150 ппс. Интерфейсы загружены на 80-90%, на принимающей стороне нет управления входящими очередями и нет соответственно никакой статистики (me3400).

Пробовала положить мультикаст в strict-priority очередь - та же история, теже дропы.

Дело скорее всего в настройках qos на 7604, но не могу понять где, т/к до клиента метки доходят верные

Как траблшутить? Буду благодарна за любую инфу.

[mschedrin]

Почему бы не настроить qos на me3400?

[Frau]

Почему бы не настроить qos на me3400?

он там настроен

до этого вместо 7604-3400 было 3400-3400, дропов не было при аналогичной загрузке линков

[rus-p]

Доброго времени суток всем,

есть такая проблема - дропается мультикаст

схема:

Принимается поток 250 ппс на 10G Интерфейс 7604, далее он роутится по ядру сети с помощью pimsm, replication mode ingress, используется qos на 7604, маркируется верно, дропов output не видно, в спане вижу как поток уходит в 250 pps. На принимающей стороне мерию поток - уже 140-150 ппс. Интерфейсы загружены на 80-90%, на принимающей стороне нет управления входящими очередями и нет соответственно никакой статистики (me3400).

Пробовала положить мультикаст в strict-priority очередь - та же история, теже дропы.

Дело скорее всего в настройках qos на 7604, но не могу понять где, т/к до клиента метки доходят верные

Как траблшутить? Буду благодарна за любую инфу.

Конфигу выкладывайте релевантную проблеме, с пояснениями какой порт куда подключен и загрузку каналов на фабрику.

Посередине, между 7600 и 3400 есть возможность миррор сделать ?

В ппсах не ошиблись, точно не кппс ?

 

 

 

[Frau]

конфиг 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

 

[rus-p]

В какие карты (тип) у вас все подключено?

Дайте 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 Номер очереди разве может быть одинаков ?

 

[Frau]

В какие карты (тип) у вас все подключено?

Дайте 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

[rus-p]

В какие карты (тип) у вас все подключено?

Дайте 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.

С номерами очередей ясно, цискины нюансы, все ок.

 

 

[Frau]

Вы ставите преседенс в service-policy, а порт Gi3/24 у вас в mode-cos, поставьте cos.

С номерами очередей ясно, цискины нюансы, все ок.

а как я могу выставить cos если там routed-порт? Там нет тегов

[rus-p]

Вы ставите преседенс в service-policy, а порт Gi3/24 у вас в mode-cos, поставьте cos.

С номерами очередей ясно, цискины нюансы, все ок.

а как я могу выставить cos если там routed-порт? Там нет тегов

Мне тут коллеги подсказывают, что set cos 7 для вашего случая не будет идиотизмом )

т.е. это внутренний cos, он дойдет до гигабитного порта и правильно разложиться в 4-ю очередь.

 

У вас ситуация просто не тривиальная, гигабитная карта не имеет режима для очередей dscp-mode.

[Frau]

Мне тут коллеги подсказывают, что 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

[rus-p]

Ясно.

Пока не понимаю, почему у вас не срабатывает дефолтная карта ipp-cos.

Попробуйте зайти с другой стороны, поставьте set на egress порту.

 

[Frau]

Ясно.

Пока не понимаю, почему у вас не срабатывает дефолтная карта ipp-cos.

Попробуйте зайти с другой стороны, поставьте set на egress порту.

спасибо за советы, но походу у меня проблема аналогичная описанной в теме http://forum.nag.ru/forum/index.php?showtopic=55680

[rus-p]

К первому варианту, у меня 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

 

[rus-p]

Ясно.

Пока не понимаю, почему у вас не срабатывает дефолтная карта 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.

Быть может, одной полиси недостаточно, чтобы заработало дефолтное маппирование взамен переписывания в ноль.

Edited May 20, 2010 by rus-p

[Frau]

так, я окончательно запуталась в 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

 

как связать внутренние метки с "не внутренними"?

 

[rus-p]

так, я окончательно запуталась в 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 в траст на нем и настроить очереди.

Edited May 21, 2010 by rus-p

[nnm]

Попробуйте в policy-map на входе ставить DSCP а не precedence. Так чтобы этот DSCP мапился в CoS для приоритетной очереди на выходе.

[Frau]

...

Я не очень здорово знаю циску, можно ли в лан картах посмотреть счетчики на егресс по каждой очереди раздельно ?

На ингресс точно нельзя.

 

Какая у вас версия 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

не помогает. Да и по докам поидее это одно и тоже

[rus-p]

на егресс тоже нельзя смотреть счетчики по каждой очереди

 

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 по поводу коса.

Edited May 24, 2010 by rus-p

[mschedrin]

Вот как можно посмотреть дропы на 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

[Frau]

Остался 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..

 

[rus-p]

Вы не сказали, прибавляются ли счетчики в первой егресс очереди на 7600.

Если прибавляются, посмотрите включена ли у вас посылка pause фреймов от 3400 к 7600 и их прием на стороне 7600.

 

По поводу 3400, попробуйте выключить qos на нем.

 

Поток 1,6 мбит/с это имеется в виду суммарный мультикаст ?

Видно ли на 7600 в снупинге, что запрашивают несколько каналов ?

Покажите вывод статистики на output по любому из двух способов, предложенных ранее, чтобы увидеть, что у вас правильно все мапиться по классам.

 

Покажите настройки мультикаста на 3400.

Если включен роутинг/снупинг, попробуйте выключить и сделать из 3400 прозрачную трубу для мультикаст трафика.

Edited May 26, 2010 by rus-p

[Frau]

Всем откликнувшимся спасибо, проблема решена. Проблема была в балансировке мультикаста.

[rus-p]

Можете подробнее пояснить ?

Чтоб в голове отложилось, а то незавершенным процесс остался )