kaktak

Просто да не просто. Так и оставите? До следующего ребута?)

Могли поменяться имена интерфейсов при перезагрузке

Вроде как для этого обычно удаленный доступ к пк абонента используют в том или ином виде

Ну вам же ядро пишет что arp replay от 213.85.178.17 приходит с интерфейса igb0 хотя должен бы с igb1. Добавили вторую сетевую карту? Или линки перепутали

Да нее. В соседней ветке начитался про интеловские процы и их cstate.

Проанализировал логи внимательнее и вспомнил.. Это я на них powertop запускал. Такие дела. Майор Джон - это я.

В том и дело, что в момент старта модуля ничего не запускал ) И даже в промиск интерфейсы не переводил )

Не, сервиса bluetooth в автозагрузке нет (использую sysvinit)

Нет, ни руками, ни своими скриптами в этот момент сервера вообще не трогал. В логах (в том числе логах крона) ничего похожего на причину рядом с загрузкой модуля блютус нет.

ну это как решение. просто интересно понять с чего он вдруг решил запуститься.

в кроне ничего похожего не вижу # lsmod | grep -i bluetooth bluetooth 119450 0 rfkill 19005 1 bluetooth crc16 12343 2 ext4,bluetooth # lsmod | grep -i bluetooth bluetooth 374429 0 6lowpan_iphc 16588 1 bluetooth rfkill 18867 2 bluetooth,asus_wmi crc16 12343 2 ext4,bluetooth

так я понимаю если бы это было при загрузке. а там аптайма от месяца до года. причем модуль в одно время примерно загрузился на разных серверах

Заметил в логах на нескольких серверах (все Debian 7-9, расположены в разных местах и даже в разных сетях ) примерно в одно и тоже время: [2389047.666379] Bluetooth: Core ver 2.19 [2389047.666390] Bluetooth: HCI device and connection manager initialized [2389047.666395] Bluetooth: HCI socket layer initialized [2389047.666397] Bluetooth: L2CAP socket layer initialized [2389047.666402] Bluetooth: SCO socket layer initialized никаких блютус устройств в сервера естественно не устанавливали. Что это может быть? Атака какая-то?

так это вроде только для процов Intel Nehalem/Westmere актуально.. у вас оно?

Подзабыл теорию tc.. Подскажите, правильно ли я понимаю, что параметр fwmark модуля shaper позволяет пустить промаркированный трафик мимо шейпера только в случае использования htb, но не будет работать с tbf?

Это да... но не везде возможно. Иначе вопрос о pppoe вообще не стоял бы )   Другое дело, что скорее всего процент левых pppoe, которые случайно оказались в сети стремится к нулю. А на тех, которые не случайно, указан правильный service-name. Тут где-то писали, что в некоторых случаях может спасти от pppoe другого оператора (например не правильная настройки при аренде вланов и т.д.)

От левых pppoe (случайных) может спасти.

Использовать ли service-name на сервере доступа pppoe? Или с ним больше гемора, чем пользы? Например кривые клиенты не правильно или вообще не указывающие service-name в padi? Еще какие-то подводные камни?

Debian. Я так понял, решили, что задавать опции при загрузке модуля не круто и запретили это делать. Подскажите аналог QueuePairs в ethtool? Пробовал так: # ethtool -L eth0 combined 1 # ethtool -l eth0 Channel parameters for eth0: Pre-set maximums: RX: 0 TX: 0 Other: 1 Combined: 8 Current hardware settings: RX: 0 TX: 0 Other: 1 Combined: 1 Но очереди все равно не спаренные: # cat /proc/interrupts | grep eth0 46: 1 0 PCI-MSI-edge eth0 47: 7946543 2856540 PCI-MSI-edge eth0-rx-0 48: 10083378 4281961 PCI-MSI-edge eth0-tx-0 Как с помощью ethtool получить одну очередь eth0-RxTx-0 ?

Интересно, что сейчас счетчик показывает тоже самое кол-во: #sh int gig 3/10 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi3/10 0 0 0 0 0 1337680 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Gi3/10 0 0 0 0 0 0 т.е. проблема с переполнением буфера носит скорее эпизодический характер, а вот описанные в первом топике задержки за это время были не раз. Так что дело видимо не в буферах, а может и не в зеркале даже )

но ведь это дропы, а не задержки... в тех случаях которые я наблюдал пакеты все же были доставлены, но с опозданием. хотя возможно были и просто потери. WS-X6516-GE-TX В принципе на sup-е есть один свободный порт. Но я сейчас посмотрел на том, который занят тоже есть OutDiscards. Думаете на sup-е буферы все же больше? вообще по платам: Switching resources: Module Part number Series CEF mode 2 WS-X6704-10GE CEF720 CEF 3 WS-X6516-GE-TX CEF256 CEF 4 WS-X6516A-GBIC CEF256 CEF 5 WS-SUP720-BASE supervisor CEF Может плата с GBIC имеет большие буферы?

да, похоже есть: #sh int gig 3/10 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi3/10 0 0 0 0 0 1337680 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Gi3/10 0 0 0 0 0 0 0 Port SQETest-Err Deferred-Tx IntMacTx-Err IntMacRx-Err Symbol-Err Gi3/10 0 0 0 0 0

CPU utilization for five seconds: 8%/3%; one minute: 14%; five minutes: 14% PID 5Sec 1Min 5Min Process 1 0.1% 0.2% 0.2% kernel 16406 4.5% 4.8% 4.3% ios-base 16429 1.3% 1.1% 0.5% tcp.proc 16431 2.1% 7.7% 8.2% iprouting.iosproc в таком случае должны быть CRC ошибки на принимающей стороне, разве нет?

Стоит сервер блокировок запрещенных сайтов в пассивном режиме (на него зеркалируется исходящий трафик, он шлет редиректы подставляя ip адреса). Иногда редирект от сервера приходит позже ответа сайта из реестра. Производитель сервера высказал предположение, что проблема связана с переполнением очереди SPAN порта, поэтому сервер получает пакеты с задержкой. SPAN организован на cisco cat 6500 (sup720-3bxl), порт 1Gb (медь), трафика в него выливается не более 400Mb/s. Можно ли что-то подтюнить (qos еще что-то) или хотя бы диагностировать проблему?

встречал описание подобных решений. конечно не так удобно, как релей (требует перенастройки при изменениях в спиках каналов), но как вариант.. Насколько я понял ffmpeg осуществляет некий транскодинг? Просветите для чего он? И видимо это не дешевая операция. Можете примерно сказать какого уровня понадобится сервер(-ы) для транскодирования этим способом к примеру 100 каналов (из них 20 hd)? насколько я понял с помощью ffmpeg генерируются файлы (чанки?) с разным битрейтом и указываются в плей-листе.