taf_321

<tcp> <!-- For: tcp- and tcp-http. --> <connectTimeout>300</connectTimeout> <!-- Connect timeout. --> <reconnectInterval>60</reconnectInterval> <!-- Retry connect delay. --> <reconnectCount>1024</reconnectCount> <!-- Retry count. --> <remonteHostname>192.168.0.125</remonteHostname> </tcp> Изначально значения таймаутов так же были 5 и 5 секунд, 300/60 стали уже в процессе ковыряния, без всякого изменения поведения. Хм... Разница только в том, что у меня не указан порт в remotehostname. Но при старте поток из указанного так источника запускается и до первого падения работает.

В логах вот такая картина: May 15 10:35:14 stream1 msd[115320]: /channel/TVch1.ts - 1/2: stop [1: ERROR ]... May 15 10:35:14 stream1 msd[115320]: /channel/TVch1.ts - 1/2: requesting for data [1: ERROR ]... May 15 10:35:14 stream1 msd[115320]: /channel/TVch1.ts - 1/2: waiting for data [1: ERROR ]... May 15 10:35:14 stream1 msd[115320]: /channel/TVch1.ts: switch src from 2 to 2 - backup. May 15 10:35:14 stream1 msd[115320]: /channel/TVch1.ts - 1/2: stop [1: ERROR ]... May 15 10:35:14 stream1 msd[115320]: /channel/TVch1.ts - 2/2: stop [1: ERROR ]... И что-то вообще никаких таймаутов при реконнектах не вижу. Так же в логах не вижу выхлопа от от строки syslog(LOG_INFO, "Retry %"PRIu64"/%"PRIu64" connect to %s...", conn_tcp->conn_try, conn_tcp->conn_try_count, straddr); из src/stream_src.c. Такое подозрение, что где-то что-то отрабатывает не так.

Пытаюсь запустить msd на проксирование потоков http-to-http. Вроде как все запускается и работает, но если источник пропадает на время от нескольких десятков секунд до пары минут, то на msd вещание прекращается, и после возвращение источника из коматоза, не восстанавливается. Когда источником был multicast такой проблемы не наблюдалось, вещание и раздачи восстанавливались при возобновлении мультикаста. Конфиг msd и каналы для примера привожу. Что нужно подкрутить, чтобы msd восстанавливал прием канала уникастом от отвалившегося источника?

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

Что мешает вам последовать вашему же мудрому решению, и запросить у РТ где проходит раздел зон ответственности между оператором и пользователем. Я вижу эту только одно препятствие - ваше желание пофлеймить.

И терминал и опциональный роутер после него, и точка доступа за ними, и компьютеры-планшеты-ТВ-приставки-телефоны это тоже абонентское оборудование. И да, вон вы процитировали про "...технические характеристики которого позволяют получить услугу на сети связи ПАО "Ростелеком...", и таки РТ решает, что позволяет а что нет получать услугу в оптической части соединения.

Тут надо смотреть где кончается сеть оператора, и начинается "собственное абонентское оборудование", и что-то мне подсказывает, что это будет медный порт на оптическом терминале.

Есть несколько сотен OLT на которых до десяти тыс оптических портов. Идея создать иерархию вланов для vlan-per-user подклюлчения. Первая метка cvlan клиента, вторая svlan - привязывается к порту OLT, третья для всего конкретного OLT полностью.

Приветствую! Господа кошководы, нужна ваша консультация. Умеет ли ASR1002-HX заворачивать-разворачивать пакет даже не с двумя, а с тремя vlan метками? В линухе это делается на раз-два, интересна возможность подобного в "настоящем взрослом оборудовании". Вообще, такая конструкция будет рабочей? interface Port-channel1 description DOWNLINK mtu 9000 no ip address ! interface Port-channel1.11 description SUB-DOWNLINK encapsulation dot1Q 11 mtu 1504 no ip address ! interface Port-channel1.11.12 description SUB-SUB-DOWNLINK encapsulation dot1Q 12 mtu 1500 no ip address !

И еще проще делать выгрузку дельтами, там этот подписанный файл нужен только для старта процесса, дальше уже все будет по логину-паролю. В 2020 году перешли на этот метод, и больше никаких запар с сертами.

Продвигали HT как технологию, которая позволяет более полно утилизировать процессоры, ибо при выполнении команд, процессор использует только некоторые блоки, и типа можно еще накинуть задачи, которые будут выполняться на других блоках. Возникновение ситуации, когда за ресурсы процессора будут конкурировать такие задачи, которым нужны те же самые блоки это вопрос статистики. А уж на роутере как раз и будут те задачи, которым требуется исполнять на процессоре идентичный набор инструкций. Собственно, по perf top можно посмотреть самые часто исполняемые команды процессора на самых прожорливых процессах.

В связи с прикрытием халявы от RH, судьба деривативов от RHEL сейчас туманна. Пересобирать чужое с нескучными обоями и гордится "совместимостью вплоть до воспроизведения ошибок" это одно, а заниматься реально разработкой дистра это уже совсем другое. Аномалия возникает, когда система решает, что вот это ядро и это ядро это разные ядра и на них навешивает тяжелые задачи, но в физике это оказывается одно и то же ядро. И да, HT на роутинге все же надо выключать.

https://forum.proxmox.com/threads/proxmox-7-and-mellanox-connectx4-and-vlan-aware-bridge.104926/ ConnectX3: 128 vlan limit ConnectX4LX: 512 vlan limit (tested) ConnectX4: 4096 vlan limit ConnectX5: 512 vlan limit (tested)

С мелланоксами проблема с количеством поддерживаемых VLAN'ов. Где-то всего 128, где-то подняли лимит до 512, но все равно проблема остается.

Еще возможен вариант, когда кто-то из участников на концах считает, что вся среда между корреспондентами умеет в jumbo, но реально это не так. В итоге тормоза, постоянные ретрансмиты.