maxkst

Насколько я понял, это делается на стороне клиента, и в новых версиях софта эта проблема уже исправлена и в этом нет необходимости

Долгое время приходилось использовать и то, и другое по очереди. Потому что и там и там были свои глюки. Например, на EoIP иногда интернет вел себя странно, скорость падала, не все сайты открывались, такое поведение обычно указывает на проблемы с MTU. Решалось обычно или ребутом роутеров, или удалением и пересозданием туннелей с теми же самыми параметрами. С VPLS чаще всего проблема возникала с поднятием канала просле смены маршрутов. Канал мог "лежать" до тех пор пока физическому интерфейсу не сделаешь down/up Где-то EoIP вел себя более стабильно, а где-то VPLS.

Ну вот нам не повезло, у нас такие ))):

Я тут нашел самый простенький онлайн калькулятор, кому интересно https://www.arstel.com/po/tv/ Простой, удобный, только делителя на 8 не нашел в нем

Вы вообще в школу ходили? Если да, то зачем? Лень было самому учиться по книжкам? А не западло было слушать учителя, вопросы задавать? Мне лично не сложно задавать интересующие вопросы. А вот вам видимо проще тут часами эту ахинею писать, вместо того чтобы потратить минуту и дать простой ответ. Задам свой вопрос еще раз. Просьба скайстару - проигнорируйте, хватит тут флудить! Сколько CC errors в день на канал допускается на стороне абонента? Где это количество задокументировано?

Elecard приглашает принять участие в вебинаре 16 июня как раз по похожей теме “Стратегии мониторинга качества прямых трансляций спортивных мероприятий”. Наврятли смогу принять участие из-за разницы во времени. Ну я понимаю, потешить свое ЧСВ немножко, а потом можно и спуститься с небес и подсказать. Но конкретно этот персонаж продолжает изображать из себя эксперта недосягаемого уровня. Психологи считают, что все проблемы идут из детства )) Пожалуй соглашусь )) Спрашивал сетевика одного, как он делает тест сети Ethernet своим тестером на соответствие RFC. Он мне дал понять, что threshold на pass или fail можно любой выставить, под конкретный SLA. А его уже кто какой хочет, тот такой и заказывает. Про SLA с абонентом сети кабельного телевидения честно скажу - не слыхал.

Видел тоже эту прогу, но что-то сцыкотно устанавливать на win10 софт с интерейсом win3.11 ))

Гостиницы тоже не любят лишние коробки, провода, пульты

Ваши бы слова да богу в уши. Дом престарелых не хочет STB, но очень любят смотреть телик ))

Нука, ткните меня носом туда, с размаху, чтобы я прям увидел, сколько continuity_counter errors допускается в сутки на каждый канал?

Кто чем пользовался при проектировании сети кабельного телевидения?

@Ivan_83 Само собой, это понятно. Допустим одна CC ошибка в час или 24 в день per channel это много или мало? у кого сколько ошибок прилетает за сутки на каждый канал?

Вопрос к тем, кто уже определился чем мониторить. Допустим вы видите ошибки. Сколько ошибок нужно увидеть чтобы оторвать пятую точку от рабочего места и начать диагностику сети?

Так можно обьяснять наличие порнухи на жестком диске. Подменили payload )))

Если у вас BGP пиринг с провайдером - почитайте про DDoS blackhole routing/filtering

RB4011 и CRS1072. в одном направлении поврежденные, в противоположном (от 1072 до 4011) все ок

@Saab95 То есть этот тест ни о чем не говорит, так и должно быть, или все таки проблема где-то?

@jffulcrum там другая история, у меня corrupted только с огромными пакетами

Это вообще нормально?

MLAG уже протестили? и как оно?

Все равно фигня какая-то получается. При отключенном Unknown Multicast flood работает только 4 минуты. При включенном Unknown Multicast flood, как ни странно, работает как надо

Как вариант, отключили Switch Rules и Unknown Multicast flood. Вместо этого включили IGMP snooping и Multicast Querier на бридже. Пока вроде работает, разбираемся, где и как включить Multicast Router, на портах или на бридже. Проблема состоит в том что после каждого изменения настройки надо ждать несколько минут, чтобы убедиться что поток идет стабильно и не пропадает по таймауту.

Поток с кучей мультикаст групп льется на свич (CRS326-24G-2S+) безо всяких IGMP, 4GBps суммарно. Задача - раскидать UDP по 1G портам в разных пропорциях, менее гига на порт, некоторые мультикаст группы должны присутствовать на нескольких портах. С одним портом проблем нет, SWITCH RULE отправляет нужные адреса на нужный порт. Проблема возникает если эти же потоки надо направить на два и более порта: multiple destination ports are not supported for this switch, хотя в самой RoS такая возможность есть, но далеко не для всех свичей: Multiple "new-dst-ports" are not supported on CRS3xx series switches. В каких свичах поддерживается Multiple "new-dst-ports"? Как еще можно реализовать задачу на имеющемся свиче?

МИкротик наверное ждет извинений )

ну или в основном правиле можно наверное добавить (!) connection-state=established,related не, там слишком много зла ))