Asatiany

Приветствую, коллеги! У нас и РТРС оба мультиплекса уже с 12-го числа не работают корректно. 2-ой вообще часто не работает. Берем по "оптике". Эфир еще более-менее функционирует.

Особо не вдавался в datasheet, но на первый взгляд I210 более энергоэффективнее, более "домашний". Что-то критичное не заметил. К тому же, как я узнал, I210 уже используется в другом "зеркале". Правда, только на прием "части" трафика. Без проблем и уже очень давно...

Вдаваться в вопрос с $0Rm я не буду. Вопрос про зеркало. У меня есть опасения, что I210 оFигеет от такой наглости. Да и грамотно прописать qdisc и filter надо...

Да, именно так. Сейчас берем зеркало с L3-коммутатора. Витой парой.

Приветствую! Имеем Linux Router с: $ lspci | grep Ethernet 01:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 04:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) I350 - дискретная, I210 - встроенная $ ip li sh 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 10000 link/ether **:**:**:**:**:f6 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 10000 link/ether **:**:**:**:**:f7 brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether **:**:**:**:**:81 brd ff:ff:ff:ff:ff:ff 5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether **:**:**:**:**:82 brd ff:ff:ff:ff:ff:ff 6: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether **:**:**:**:**:83 brd ff:ff:ff:ff:ff:ff 7: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether **:**:**:**:**:84 brd ff:ff:ff:ff:ff:ff 8: v3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether **:**:**:**:**:f7 brd ff:ff:ff:ff:ff:ff где eth0 - uplink, eth1 - local (I350); eth2-5 (I210), причем eth5 - IPMI $ tc qdisc show qdisc noqueue 0: dev lo root refcnt 2 qdisc mq 0: dev eth0 root qdisc fq_codel 0: dev eth0 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev eth0 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev eth0 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc mq 0: dev eth1 root qdisc fq_codel 0: dev eth1 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev eth1 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev eth1 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc fq_codel 0: dev eth1 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn qdisc noqueue 0: dev v3 root refcnt 2 $ tc class show dev eth0 class mq :1 root class mq :2 root class mq :3 root class mq :4 root class mq :5 root class mq :6 root class mq :7 root class mq :8 root $ tc class show dev eth1 class mq :1 root class mq :2 root class mq :3 root class mq :4 root class mq :5 root class mq :6 root class mq :7 root class mq :8 root Нагрузка на каждый порт I350 порядка 900 Мбит/с. Требуется: зеркало трафика из eth1, причем Tx/Rx -> eth2, Tx -> eth3. Вопросы: Насколько вообще возможно сделать зеркало средствами tc с порта дискретной сетевой карты на встроенную? Насколько "точное" зеркало будет? P.S. С tc знаком поверхностно. Пробовал на виртуальной машине настроить зеркало - получилось, но не при такой нагрузке, не на таких сетевых, без уже имеющихся очередях... Как вы понимаете, при такой нагрузке на боевой машине тестировать не хочется... Поэтому решил спросить совета у более опытных пользователей. Заранее спасибо!

Была как-то проблема с SFP UTP от GIGALINK. Закупили несколько модулей в резерв. Случилась нештатная ситуация на одном из узлов, пришлось задействовать. Не завелись на установленном там D-Link DGS-3627G. Вообще никак. Установили в D-Link DGS-3120 - работают. И в DES-3200-26, и в DES-3200-28. А вот в DES-3526 - нет. Звонил в техподдержку GIGALINK, где техспециалист сообщил, что "да, есть такая проблема, на старых dlink'ах (и еще каких-то вендоров) на модулях с маркировкой (не помню, к большому сожалению, какой, но точно знаю, что "Q036(YR) не определяется)". И сказал, что при заказе указывать "такую-то маркировку". Тогда вопрос я детально не рассматривал. И наступил день, когда потребовались сие модули. Вспомнил разговор с GIGALINK'ом, решил позвонить. А там вопросу про маркировку ну очень удивились! Цитирую: "В первый раз о таком слышу..." Пришлось заказать SNR. Теперь не знаю, как быть с GIGALINK...

Проработал эту версию. Канал "Киноуж...с", фильм "Они" Сделал захват 10 минут (точнее 09:49) с 3-мя "гаснущими" моментами (без участия QAM, с IP выхода ресивера). Анализ через TS Analyser показал только PCR Interval Error (472) и PCR Accuracy Error (>1000), Unreferenced PID отсутствуют. Запустил записанный фрагмент через VLC с ПК на QAM. Экран гас... Вообще, Unreferenced PID - это PID'ы по стандарту (таблиц PAT, PMT и т.д.)? Я к тому, что мы фильтруем таблицы NIT, CAT от uplink'а, т.е. таблицы как-таковые не идут в потоке, а ссылки в PAT, например, на них есть. Может, поэтому эти ошибки присутствуют? GOP Size = 29, кстати... Все больше склоняюсь к версии, что виновник "дискомфорта" - сам ТВ... :-(

Вновь вернулся к проблеме. 1. MER как с выхода IP-QAM Dexin NDS3316, так и возле ТВ - в норме (39 - 39,1). 2. BER также в норме (по прибору Deviser DS2400Q preBER до -6 прыгают, postBER стабильно -9, соответственно, поле COR незначительно, UNCOR - отсутствуют). 3. Для замеров по TR 101 290 использовал приложение Promax TS Analyser. Поток выпускал напрямую с ресивера по IP, захватывал с помощью VLC (без конвертации в формате *.ts) в течении 15-20 секунд. Изначально Analyser указывал на следующие проблемы: Contunity Count Error (>100); PCR Accuracy Error (>1000); Unreferenced PID (>100); + некоторое количество проблем по Priority 1 и 3. Поборол PCR путем настройки IP-QAM, а именно: TS Config -> Output TS * -> General -> PCR Correct = yes; PCR Speed BW = 3 (0 - default); PCR State BW = 3 (0); PCR Compensate = 3 (0). Затем повторил п. 3, ошибки практически исчезли (единичные появления), за исключением Unreferenced PID. 4. GOP Size вычислял через ffprobe (за основу взят захваченный ts канала "Киноуж...с" как канал с наибольшим количеством темных сцен). Прогонял сцены в 2-х разных фильмах, где GOP в одном - 43, в другом - 30. Самое интересное, что проблема отключения есть и на каналах РТРС ("Пятница") (принимаем по оптике). GOP проверял (давно, правда) = 12. Телевизоры пока не обновляли на последнюю на данный момент прошивку. Причем своими глазами видел, что экран гас только при воспроизведении цифровых каналов, не аналоговых. И на пульт реакция есть лишь частичная: звук регулируется (полоски регулировки не видно), выключается, но каналы не переключаются... Каков путь истинный, господа? P.S. Ну, нет у нас профессионального анализатора... Эх...

И, получается, что с HTTPS бороться можно только действующим доменом и официальным сертификатом? Придется ковыряться с DNS?

Возможно ли сбросить через firewall такое защищенное (уже установленное) соединение, чтобы процедура его установления прошла заново? Ведь пакеты попадают под DNAT, но браузер будет ругаться на сертификат, а если "Все-равно загрузить" - то выскочит "заглушка"... Как организовать?

Убедили, спасибо! Как же с ним быть? Да и вообще - почему? Создание защищенного подключения (грубо говоря обмен сертификатами) ведь происходит ПОСЛЕ создания подключения (обмена начальными пакетами-запросами). Неужели на этом этапе нельзя применить ограничения, которые дает firewall?

Поясните, пожалуйста, какими? Как говориться: "Предупрежден - значит вооружен". Уже говорил, что , то есть как мне "зарулить" все уже установленные соединения на страницу-пояснение при блокировке? Сервер - NAS, сетей три - абонентская (local - под туннели), ospf и туннели пользователей (PPTP). Вот и не пойму, КАК именно и КУДА именно src'ить...

Логика более-менее понятна, но сложна, ибо оперирует уже ФИЛЬТРОВАННЫМИ адресами, без указания глобальных. В DNAT попадает только первый пакет (новый ресурс). Уже с установленными соединениями оно не работает. Тут, прям, REDIRECT напрашивается, но "заглушка" на другой машине... К тому же, есть нюансы с HTTPS (порт 443): ругается на сертификаты и защищенность. Вот, вот, как бы SNAT'ить правильно?

Приветствую! UP'ну тему. Используя ipset, как правильно построить правила SNAT? Поясню. Имеем: ipset "BLOCK" - для заблокированных пользователей; ipset "FREE" - разрешенные ресурсы; 1.1.1.1 - страница блокировки на другом сервере; ppp+ - интерфейсы пользователей. Пока блокировка отсутствует, пользователь пользуется всеми благами Интернета. Если принудительно блокируем, то великолепно DNAT'ит только НОВЫЕ страницы браузера, если там уже были открыты какие-либо ресурсы, то ими спокойно пользуешься. Политикой DROP в цепочке mangle FORWARD можно убить их, но как-то не комильфо видеть "Страница недоступна" без пояснения. Понимаю, что спасет действие SNAT. Но как, если --to-source там - конкретный IP-адрес, а не список ipset?

Значит, не мы одни такие... :-) Я так понимаю, что без хорошего анализатора проблему не поймать... P.S. Весьма доходчиво! Большое спасибо за столь развернутый ответ!