Sergey R. Опубликовано 2 февраля, 2017 · Жалоба Всем привет! Столкнулся с одной неприятной проблемой, нужен совет. Имеются коммутаторы с линками 10/1Г. Конкретно используемые модели: cisco Nexus 3064, extreme X670V-48x. Так вот, на всех без исключения гиговых портах временами проскакивают ошибки, на cisco Nexus 3064 это output discard, на extreme X670V-48x это congestion drops. Это реальные потери пакетов, которые вызваны судя по всему перегрузкой буферов на гиговых портах, т.е. пакеты ломятся с портов 10Г на гиговый порт и перегружают буфер. Стал разбираться и на экстримах это дело быстро вылечил: https://gtacknowledge.extremenetworks.com/articles/Solution/Prevent-packet-drops Как они советуют надо либо апгрейдить порт, либо увеличить буфер для порта. Увеличил буфер и проблема ушла. В дальнейшем конечно проапгрейдим порты. Вопрос как что-то подобное сделать на cisco? Т.к. проапгрейдить все порты быстро не получиться, а терять трафик тоже плохо. Это явно не проблема конкретной железки и наблюдается на всех устройствах в сети, не только свитчи но роутеры cisco7609. QoS в данном случае не поможет т к на многих портах трафик однотипный (например на порту раздаётся только мультикаст для операторов связи). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 2 февраля, 2017 · Жалоба Смените Cut-Through на Store-And-Forward switching-mode store-forward http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/layer2/503_U3_1/b_Cisco_n3k_Layer_2_Switching_Config_503_U31/b_Cisco_n3k_Layer_2_Switching_Config_503_U31_chapter_01000.pdf После этого ищите порт с ошибками. Буферов у нексуса должно хватать. Что у Вас бегает через свитч? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey R. Опубликовано 2 февраля, 2017 · Жалоба Спасибо, Cut-Through и Store-And-Forward посмотрю. Через свитчи бегает разное. Есть только с мультикастом свитчи, есть трафик пользователей + мультикаст. Проблема наблюдается везде. Как гиговый линк так постоянно копиться счетчик output discard. Где трафик пользователей + мультикаст ещё QoS можно посмотреть. Но там где только мультикаст QoS уже нет смысла трогать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 2 февраля, 2017 · Жалоба Есть только с мультикастом свитчи, есть трафик пользователей + мультикаст. Проблема наблюдается везде. Значит точно не буфера. При нехватке буферов проблема превалировала бы на свитчах с малткастом. Команда не требует перезагрузки, поэтому в любом случае стОит попробывать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v_r Опубликовано 2 февраля, 2017 · Жалоба на cisco Nexus 3064 это output discard Видел что на N3K проскакивают discards in/discards out на нескольких портах при флапе одного из портов, причина мне не ясна. У вас только output discards или input discards тоже есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 3 февраля, 2017 · Жалоба Это явно не проблема конкретной железки и наблюдается на всех устройствах в сети, не только свитчи но роутеры cisco7609. на 7609 какие модули гигабитные используются? включн mls qos? Смените Cut-Through на Store-And-Forward по вашему мануалу как раз cut-through нужен, на сколько я понимаю 10 GB to 1 GB cut-through Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 3 февраля, 2017 · Жалоба по вашему мануалу как раз cut-through нужен, на сколько я понимаю 10 GB to 1 GB cut-through Да, оно работает лучше, но если нет ошибок на портах. Достаточно ошибок хоть на одном порту - и они начнут сыпаться по всей сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey R. Опубликовано 3 февраля, 2017 (изменено) · Жалоба судя по мануалу также пока пришёл к выводу что дефолтный Cut-Through Switching Mode больше подходить в пятницу щёлкать на Store-and-Forward Switching Mode точно не буду если других решений не найдется то попробую переключить на следующей недели :-) про 7609 можно вопрос закрыть т.к. уже неактуально их все по 10Г подключили и вопросов не осталось discards in есть но я на них внимания не заострял, т.к. если на другом конце стоит коммутатор, который шлет пакеты с vlan id, которого нет на устройстве, то также счетчик discards in растет чтобы не приплетать сюда qos: имеются коммутаторы на которых присутствует ТОЛЬКО мультикаст. каждый пакет важен и я не могу по очередям его распихивать вот опять посмотрел счетчики которые чистил вчера все набежавшие ошибки исключительно на гиговых портах на 10Г всё чисто если на этом порту подключен оператор, которого волнует качество услуг то он естественно у себя ставит пробник для мониторинга мультикаста в итоге у меня output discard проскакивает и пробник материться в этот момент всё же подозреваю что на 90 процентов это из-за буферов в екстриме я вылечил как тут написано https://gtacknowledge.extremenetworks.com/articles/Solution/Prevent-packet-drops configure port <PORT> shared-packet-buffer 100 вот хотел на нексусе что-то подобное найти nexus2# sh int | inc "output discard" 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 349 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 2212063 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 25362 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 160494 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 61765 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard 0 lost carrier 0 no carrier 0 babble 0 output discard я понимаю что увеличение буфера, возможно, не оптимальный выход т к в чем то другом я потеряю хотя и не будет потерь например вырастет джиттер но если рассматривать именно мультикаст - то те кого волнует большой джиттер поставят мультиплексор и сделают де-джиттер а потери уже не восполнишь, пакеты потерялись картинка подсыпает... Изменено 3 февраля, 2017 пользователем 704114 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 3 февраля, 2017 · Жалоба гиговые порты загружены на сколько %? Я как-то смотрел теории умных людей и они утверждали что при переходе 80% загрузки начинают резко расти требования к размеру буфера чтобы не терялись пакеты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey R. Опубликовано 3 февраля, 2017 (изменено) · Жалоба про такие цифры как 80% даже говорить не хочу будет ОЧЕНЬ много discards т.е. чем больше загрузка тем вероятность возникновения discards больше в минимальных количествах могут наблюдаться и при загрузке в 30-40% и этого минимума вполне хватит чтобы вызвать недовольство у потребителя услуги особенно если iptv для него основной заработок :-) Изменено 3 февраля, 2017 пользователем 704114 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 3 февраля, 2017 · Жалоба а это вам не подойдет для мониторинга? http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3548/sw/system_mgmt/b_N3548_System_Management_Config_503_A1/b_N3548_System_Management_Config_503_A1_chapter_010000.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey R. Опубликовано 3 февраля, 2017 · Жалоба http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/qos/503_u3_1/b_Cisco_Nexus_3000_QoS_Config_Guide_Release_503_U3_1/b_Cisco_Nexus_3000_QoS_Config_Guide_Release_503_U3_1_chapter_011.html вот тут нашел как буфер мониторить nexus2(config)# hardware profile buffer info port-threshold front-port 25 threshold 1 nexus2# show hardware internal buffer info pkt-stats port-log [ Port 25 ] 02-03-2017 16:52:31.150274 Port 25 buffer threshold 1398 cells[5.2% - ~0.3MB] exceeded 270[1%] 02-03-2017 16:52:18.473785 Port 25 buffer threshold 824 cells[3.1% - ~0.2MB] exceeded 270[1%] 02-03-2017 16:52:05.751226 Port 25 buffer threshold 588 cells[2.2% - ~0.1MB] exceeded 270[1%] 02-03-2017 16:52:05.403766 Port 25 buffer threshold 373 cells[1.4% - ~0.1MB] exceeded 270[1%] 02-03-2017 16:52:04.393693 Port 25 buffer threshold 293 cells[1.1% - ~0.1MB] exceeded 270[1%] только боюсь то что хочется увидеть - не получится потери очень кратковременные так что тут интересуют пиковые значения буфера а это как раз не поддерживается nexus2# show hardware internal buffer info pkt-stats peak ERROR: peak counters are not supported on this platform Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v_r Опубликовано 3 февраля, 2017 · Жалоба На Nexus 30xx только 4 мультикаст очереди (очередей длдя юникаста 8) и они связаны с qos group по умолчанию так: # sh wrr-queue qos-group-map MCAST Queue ID Qos-Group Map 0 0 1 1 2 3 2 4 5 3 6 7 Если у вас мультикаст-трафик бежит в ту же очередь что и юникаст то можете направить мультикаст-трафик другую очередь, делается настройкой wrr-queue qos-group-map. По умолчанию юникаст и мультикаст делят исходящую полосу поровну: # sh wrr unicast-bandwidth UCAST Bandwidth percent: 50 Можете увеличить полосу для мультикаста глобально на свитче или индивидуально на каждом порту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 4 февраля, 2017 · Жалоба по идее потери мультикаста могут наблюдаться только на этапе сборки потока от разных источников. Как только поток мультикаста собран в один 1Г поток он потом должен нормально влезать в другие 1Г порты. Собирать поток надо на том, что имеет очень большие буфера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey R. Опубликовано 4 февраля, 2017 · Жалоба про wrr unicast-bandwidth читаю тут дело не только в мультикасте юникаст когда теряется это тоже плохо и теперь я уже увидел что в extreme это дело лечится и подкрутив ручки буферов сервис здорово улучшился с нексусами пока решения такого нет. т.е. если имеется вход 10Г - выход 1Г то жди дропов на порту 1Г Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 4 февраля, 2017 · Жалоба если смотреть, что пишут в DS по 3064 Buffers 9 MB shared то я в стопоре, как можно на такую железку такие буфера Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey R. Опубликовано 4 февраля, 2017 · Жалоба странно вообще, нет возможности менять настройку для конкретного порта хотя в документации указана возможность даже для 5й прошивки на этом устройстве стоит version 6.0(2)U3(8) nexus2(config-if)# wrr unicast-bandwidth ? *** No matching command found in current mode, matching in (config) mode *** <0-100> Value in percentage (Default is set to 50) nexus2(config-if)# wrr unicast-bandwidth если я правильно понял то он половину буфера по дефолту отводит под юникаст а половину под мультикаст? если так тогда покрутив ручки для каждого порта явно можно добиться уменьшения дропов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
v_r Опубликовано 4 февраля, 2017 (изменено) · Жалоба Unicast-bandwidth я на порту не настраивал, посмотрел в мануале. На NX-OS 7.0 такая же картина - на порту не дает настроить wrr unicast-bandwidth. Еще в документации похоже ошибка насчет wrr-queue qos-group-map, сказано что настраивается для L3 routed трафика, по факту влияет и на транзитный трафик. Буферы для определенного трафика на N3K по идее можно увеличить настройками того же QoS, я не пытался их изменять, не было необходимости. если я правильно понял то он половину буфера по дефолту отводит под юникаст а половину под мультикаст? Пишут что в случае переполнения очереди полоса пропускания будет распределяться между юникаст и мультикаст трафиком согласно настройки, то есть это типичный scheduling. Насчет буферов в документации не сказано. Изменено 4 февраля, 2017 пользователем v_r Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey R. Опубликовано 10 февраля, 2017 (изменено) · Жалоба Похоже разобрался. По дефолту на порту висело всего 2 очереди. UC и MC. В MC помимо моего ценного мультикаста сливался броадкаст, unknown unicast и прочий широковещательный трафик, который временами переполнял очередь MC на гиговых линках. Вытащил мультикаст с тв потоками в отдельную очередь и поставил ей высший приоритет. В MC дефолтовой дропы по-прежнему остались, ну и фиг с ними, ненужные широковещалки пусть дропаются иногда. В UC и новой созданной MC всё по нулям. Ещё понаблюдаю и может вообще широковещалки все вытащу в отдельную очередь и ограничу в ней ресурсы чтобы буфер не расходовать зря. Изменено 10 февраля, 2017 пользователем 704114 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
