Перейти к содержимому
Калькуляторы

704114

Пользователи
  • Публикации

    41
  • Зарегистрирован

  • Посещение

О 704114

  • Звание
    Абитуриент
  1. Всем спасибо за советы! Раз 10Г пока редкость для такого железа, начнем тесты с teleste luminato + FEC codec module.
  2. Из первых рук уточню. Каналов на данный момент ~450. ~ 3.5G трафика. В города конечно не нужно передавать всё, но из практики, есть примеры где передается 800мбит. И вот что делать с таким трафиком и тем же teleste luminato + FEC codec module.... Всего 2x1G. Добавив FEC в 1G уже не влезет, придётся делить трафик по двум интерфейсам. Ну предположим что поделим. Дальше возникнет потребность для надёжности использовать 2 канала связи и передавать и принимать сразу по обоим. Тут этот teleste luminato вообще захлебнется и придется второй покупать. А там делить трафик сразу по 2м железкам и уже по 4м интерфейсам) в общем сложно. На самом деле железка которая поддерживает 10G уже есть, cisco dcm9902, но думал может что попроще есть, ведь нужен один FEC и функционал циски тут избыточен. Но выходит что дешевого решения не найти в любом случае.
  3. Насчёт Wisi Inca спасибо, действительно вижу поддержку LACP. А ProMPEG точно поддерживается? Что-то не нашёл в описании поддержку.
  4. А гигабитные порты на этих всех железках, работают только как независимые порты или их в LACP можно объединять?
  5. Добрый день! Кто-нибудь посоветует устройство, которое может кодировать/декодировать потоки iptv multicast в ProMPEG ? Из того что есть в планах взять на тестирование: teleste luminato + FEC codec module Но уже сейчас данное решение не нравиться тем, что имеет 2x1G интерфейса. Мультикаста же достаточно много, порядка 3GBps. (и это не предел предполагается рост) Прыгать с покупкой нескольких устройств и делить по ним трафик не особо пока хочется. Идеально было бы 2x10G интерфейса. Cisco DCM9902 не предлагать) они уже есть но ставить их в каждый город, куда планируется доставка, дороговато получается.
  6. Что стоит со стороны РТРС к сожалению не видел. Странно вообще что они всем разные настройки делают. Два потока всего раздают да еще нужно для получения join ы слать. Специально что ли надежность схемы снижают :-) Логично вроде сделать статическую подписку на их железе, чтобы потоки просто флудились. Значит я рано обрадовался что в Москве так хорошо подключения прошли... ведь ещё в регионах в планах делать.
  7. хе хе... да неужели у них для разных клиентов разные настройки... у меня еще тут третий стык с ними намечается, вот сейчас ради интереса порт перевел в UP, накинул untag vlan туда в котором ничего нет и трафик полилася сразу... мы ведь об одной и той же точке включения говорим ? Моя железка на Академика Королева 15к2 #sh int status | grep 0/2 Gi 0/2 Up 1000 Mbit Full 399 #sh int Gi 0/2 | grep Multi 1177910 Multicasts, 2 Broadcasts 843539 Multicasts, 0 Broadcasts, 0 Unicasts #sh int Gi 0/2 | grep Multi 1191275 Multicasts, 2 Broadcasts 843540 Multicasts, 0 Broadcasts, 0 Unicasts #sh int Gi 0/2 | grep Multi 1204705 Multicasts, 2 Broadcasts 843541 Multicasts, 0 Broadcasts, 0 Unicasts #sh int Gi 0/2 | grep Multi 1211421 Multicasts, 2 Broadcasts 843542 Multicasts, 0 Broadcasts, 0 Unicasts #sh int Gi 0/2 | grep Multi 1224785 Multicasts, 2 Broadcasts 843543 Multicasts, 0 Broadcasts, 0 Unicasts #sh int Gi 0/2 | grep Multi 1231501 Multicasts, 2 Broadcasts 843543 Multicasts, 0 Broadcasts, 0 Unicasts #sh int Gi 0/2 | grep Multi 1251648 Multicasts, 2 Broadcasts 843545 Multicasts, 0 Broadcasts, 0 Unicasts
  8. Летит, двух операторов подключал к РТРС. Стоит активировать порт на стыке и мультикаст от РТРС без всяких join льется в порт. Каких либо настроек специальных не просил. Против pim конечно ничего против не имею, но считаю что l3 применять нужно тогда, когда это действительно нужно. В данном случае считаю что самый простой и надежный вариант это l2, с полностью выключенным snooping во vlan.
  9. Зачем лишние настройки городить с static join? со snooping? Там всего то 2 группы. Тем более что "Перезагрузил порт на астре, чтоб поновой полетели igmp запросы - всё заработало." Вырубай snooping, совершенно не нужно тут, да и igmp вырубай, статики все убирай и будет он у тебя флудиться от РТРС до Астры как обычный броадкаст и проблем не будет. Принимаю у двух операторов РТРС исключительно по L2, snooping выключен по всей цепочке чтобы не создавать лишнюю точку отказа. В первом случае потоки сливаю на DCM9902, который преобразует их в SPTS. Во втором случае на DCM пока нету и преобразование в SPTS с помощью dvblast происходит. В обоих случаях работает железно, мониторинг не фиксировал не секунды простоя.
  10. Похоже разобрался. По дефолту на порту висело всего 2 очереди. UC и MC. В MC помимо моего ценного мультикаста сливался броадкаст, unknown unicast и прочий широковещательный трафик, который временами переполнял очередь MC на гиговых линках. Вытащил мультикаст с тв потоками в отдельную очередь и поставил ей высший приоритет. В MC дефолтовой дропы по-прежнему остались, ну и фиг с ними, ненужные широковещалки пусть дропаются иногда. В UC и новой созданной MC всё по нулям. Ещё понаблюдаю и может вообще широковещалки все вытащу в отдельную очередь и ограничу в ней ресурсы чтобы буфер не расходовать зря.
  11. странно вообще, нет возможности менять настройку для конкретного порта хотя в документации указана возможность даже для 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 если я правильно понял то он половину буфера по дефолту отводит под юникаст а половину под мультикаст? если так тогда покрутив ручки для каждого порта явно можно добиться уменьшения дропов
  12. про wrr unicast-bandwidth читаю тут дело не только в мультикасте юникаст когда теряется это тоже плохо и теперь я уже увидел что в extreme это дело лечится и подкрутив ручки буферов сервис здорово улучшился с нексусами пока решения такого нет. т.е. если имеется вход 10Г - выход 1Г то жди дропов на порту 1Г
  13. 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
  14. про такие цифры как 80% даже говорить не хочу будет ОЧЕНЬ много discards т.е. чем больше загрузка тем вероятность возникновения discards больше в минимальных количествах могут наблюдаться и при загрузке в 30-40% и этого минимума вполне хватит чтобы вызвать недовольство у потребителя услуги особенно если iptv для него основной заработок :-)
  15. судя по мануалу также пока пришёл к выводу что дефолтный 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 я понимаю что увеличение буфера, возможно, не оптимальный выход т к в чем то другом я потеряю хотя и не будет потерь например вырастет джиттер но если рассматривать именно мультикаст - то те кого волнует большой джиттер поставят мультиплексор и сделают де-джиттер а потери уже не восполнишь, пакеты потерялись картинка подсыпает...