pr0lan

Тоже думал об этом, но 1. Все конфиги сейвились (да конечно 100% уверенности быть не может) 2. должно было бы в чем другом вылезти помимо арпинга В общем пока продолжаем искать

в одной из подсетей (которая за NAT) после вынужденного ребута тазика (и всей связки комутаторов), каждый клиент на arping 10.100.2.2 выдает двойной ответ. Таких подсетей несколько, скрипт по отношению к ним - одинаков, но только в одной из подсетей такой двойной ответ. Подскажите в какую сторону копать? arping 10.100.2.12 -c1 ARPING 10.100.2.12 60 bytes from d8:32:14:08:1a:c9 (10.100.2.12): index=0 time=216.499 usec 60 bytes from d8:32:14:08:1a:c9 (10.100.2.12): index=1 time=344.721 usec --- 10.100.2.12 statistics --- 1 packets transmitted, 2 packets received, 0% unanswered (1 extra) rtt min/avg/max/std-dev = 0.216/0.281/0.345/0.064 ms

Стыдно признаться, но причина - банальна. Раз в 15 минут запускается кой какой скрипт, и буквально на долю секунды тушит файрвол. При скачивании мелких файлов статистически это не проявлялось совсем, видимо еще и реконнект с некоторых серверов срабатывал. А вот то, что больше - не влезало в эти 15 минут у некоторых клиентов по лимиту скорости. Как-то так. Спасибо за понимание.

Это ко мне вопрос, или, потерял нить. У меня нет высоких нагрузок, все клиенты в это время спокойно качают/youtube/сайтики смотрят.. но вот есть такие, которые не могут большие файлы выкачать, проверил - и правда обрывается закачка.

Украина, не установлено (пока...)

В процессе проверки Там ничего интересного, без особых лимитов, вот здесь бы я поискал поправки в лимитах #!/bin/bash /sbin/ethtool -K eth1 tx off rx off #можно поменять буферы 256-4096 ethtool -G eth1 rx 2048 tx 2048 /sbin/ethtool -A eth1 rx off tx off /sbin/ethtool -A eth1 autoneg off /sbin/ifconfig eth1 txqueuelen 10000 /sbin/ifconfig eth1.1220 txqueuelen 10000 /sbin/ifconfig eth1.3200 txqueuelen 10000 /sbin/ifconfig eth1.3201 txqueuelen 10000 /sbin/ifconfig eth1.3300 txqueuelen 10000 /sbin/ifconfig eth1.3301 txqueuelen 10000 /sbin/ifconfig eth1.3302 txqueuelen 10000 /sbin/ifconfig eth1.3400 txqueuelen 10000 /sbin/ifconfig eth1.3501 txqueuelen 10000 /sbin/ifconfig eth1.3502 txqueuelen 10000 /sbin/ifconfig eth1.546 txqueuelen 10000 /sbin/ifconfig eth1.547 txqueuelen 10000 /sbin/sysctl -w net.ipv4.neigh.default.gc_thresh1=4096 # > /dev/null 2>&1 /sbin/sysctl -w net.ipv4.neigh.default.gc_thresh2=8192 # > /dev/null 2>&1 /sbin/sysctl -w net.ipv4.neigh.default.gc_thresh3=8192 # > /dev/null 2>&1 echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 8192 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh3 #ADDEDD 12.01.18 net.ipv4.neigh.default.base_reachable_time=86400 net.ipv4.neigh.default.gc_stale_time=86400 echo 86400 > /proc/sys/net/ipv4/neigh/default/base_reachable_time echo 86400 > /proc/sys/net/ipv4/neigh/default/gc_stale_time /sbin/sysctl -w net.ipv4.netfilter.ip_conntrack_buckets=131070 /sbin/sysctl -w net.netfilter.nf_conntrack_max=1048560 # > /dev/null 2>&1 sysctl -w net.netfilter.nf_conntrack_acct=0 sysctl -w net.netfilter.nf_conntrack_generic_timeout=60 sysctl -w net.netfilter.nf_conntrack_expect_max=256 net.netfilter.nf_conntrack_helper=1 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent=60 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent2=60 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=60 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_fin_wait=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_last_ack=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close=30 sysctl -w net.netfilter.nf_conntrack_udp_timeout=30 sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=45 sysctl -w net.netfilter.nf_conntrack_icmp_timeout=1 sysctl -w net.netfilter.nf_conntrack_log_invalid=0 sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal = 0 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_fin_wait=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_last_ack=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_max_retrans=30 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_unacknowledged=30 sysctl -w net.netfilter.nf_conntrack_tcp_loose=1 sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=0 sysctl -w net.netfilter.nf_conntrack_tcp_max_retrans=3 sysctl -w net.netfilter.nf_conntrack_udp_timeout=60 sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=60 sysctl -w net.netfilter.nf_conntrack_icmp_timeout=10 sysctl -w net.netfilter.nf_conntrack_timestamp=0 sysctl -w net.netfilter.nf_conntrack_events=1 sysctl -w net.netfilter.nf_conntrack_events_retry_timeout=15 #/sbin/sysctl -w net.netfilter.nf_conntrack_generic_timeout=30 #> /dev/null 2>&1 #/sbin/sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=30 # > /dev/null 2>&1 /sbin/sysctl -w net.ipv4.tcp_max_tw_buckets=1048576 # > /dev/null 2>&1 /sbin/sysctl -w net.netfilter.nf_conntrack_checksum=1 # > /dev/null 2>&1 echo 262140 > /sys/module/nf_conntrack/parameters/hashsize #> /dev/null 2>&1 #RP_filter sysctl -w net.ipv4.conf.all.rp_filter=1 # > /dev/null 2>&1 sysctl -w net.ipv4.conf.eth1.rp_filter=1 sysctl -w net.ipv4.conf.eth22.rp_filter=1 #> /dev/null 2>&1 sysctl -w net.ipv4.conf.default.rp_filter=1 #> /dev/null 2>&1 #Misha Edit sysctl -w net.ipv4.conf.all.accept_redirects=0 #> /dev/null 2>&1 sysctl -w net.ipv4.conf.all.secure_redirects=0 # > /dev/null 2>&1 echo 1 > /proc/sys/net/ipv4/ip_forward #> /dev/null 2>&1 ##### sysctl -w net.ipv4.conf.default.accept_source_route=0 sysctl -w net.ipv4.tcp_syncookies=1 # increase TCP max buffer size setable using setsockopt() # изменение размеров буферов для приема и отправки данных через сокеты, tcp-memory sysctl -w net.core.rmem_default=16777216 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_default=16777216 sysctl -w net.core.wmem_max=16777216 # increase Linux autotuning TCP buffer limits # min, default, and max number of bytes to use # set max to at least 4MB, or higher if you use very high BDP paths # net.ipv4.tcp_rmem=4096 87380 16777216 # net.ipv4.tcp_wmem=4096 65536 16777216 echo '3--------------------------' sysctl -w net.ipv4.tcp_rmem="4096 16777216 16777216" sysctl -w net.ipv4.tcp_wmem="4096 16777216 16777216" # Максимальное число сокетов в состоянии TIME-WAIT одновременно. При превышении этого порога лишний сокет разрушается # и пишется сообщение в системный журнал. Цель этой переменной – предотвращение простейших разновидностей DoS-атак # Значение по-умолчанию – 180000 sysctl -w net.ipv4.tcp_max_tw_buckets=1800000 # Переменная задает максимальное число осиротевших (не связанных ни с # одним процессом) сокетов. Если это число будет превышено, то такие # соединения разрываются, а в системный журнал пишется предупреждение. Это # ограничение существует исключительно ради предотвращения простейших # разновидностей DoS-атак. sysctl -w net.ipv4.tcp_max_orphans=262144 # net.ipv4.tcp_max_orphans=65536 # net.ipv4.tcp_max_syn_backlog=262144 # When in a non-Napi (or Interrupt) mode, this counter indicates that the stack is dropping packets. # net.core.netdev_max_backlog=10000 sysctl -w net.core.netdev_max_backlog=30000 # net.core.somaxconn=262144 # These ensure that TIME_WAIT ports either get reused or closed fast. sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.tcp_tw_recycle=1 # защита от syn-флуда sysctl -w net.ipv4.tcp_syncookies=1 # запрет приёма ICMP-редиректов # net.ipv4.conf.all.accept_redirects=0 # net.ipv4.conf.default.accept_redirects=0 # игнорируем широковещательные ICMP-запросы sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 # игнорируем пакеты, в которых указан путь до источника sysctl -w net.ipv4.conf.all.accept_source_route=0 # Укажем диапазон портов которые разрешено использовать в качестве # локальных. По умолчанию этот диапазон достаточно мал, и при высокой # нагрузке вам их может просто не хватить # net.ipv4.ip_local_port_range=16384 61000 sysctl -w net.ipv4.ip_local_port_range=1024 65535 # Уменьшим время которое используется для сообщений # о поддержке keep alive соединений sysctl -w net.ipv4.tcp_keepalive_time=7200 # Уменьшим время до закрытия TCP соединения, данный параметр стоит менять # только на высоко нагруженных серверах. sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=7200 # Другие таймауты: sysctl -w net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=60 sysctl -w net.ipv4.netfilter.ip_conntrack_udp_timeout=60 #sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=3600 # В случае kernel panic reboot через 10 секунд (panic может возникнуть при высокой нагрузке и irqbalance, например) #sysctl -w kernel.panic=10 # чтобы не переполнялась арп-таблица (пишет в логах kernel: ipv4: Neighbour table overflow) sysctl -w net.ipv4.neigh.default.gc_thresh1=4096 sysctl -w net.ipv4.neigh.default.gc_thresh2=8192 sysctl -w net.ipv4.neigh.default.gc_thresh3=16384 #pptp modprobe ip_nat_pptp echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

Ситуация следующая: Linux Softrouter (Debian 10). Все подкручено, поднастроено.. НО у нескольких клиентов нашлась проблема - обрыв загрузки с некоторых файлообменников. Хоть 100Мб хоть 1Гб линк(на 1Гб успевает стянуть почти все) - файл 14Гбайт - обрывается. Пробовал с разных ресурсов тянуть, история похожа. В софтроутере вроде особых ограничений не нашел (на первый взгляд), но все же.. Подозрения где-то на уровне sysctl -w net.netfilter....... Но вот где именно, пока не пойму.

Волшебных кнопок - особо нет, у меня тазик ловит трапы, а самопис на питоне - обрабатывает. Возможно сделать все. Биллинг - тоже самопис.

Имеется - linux softrouter и linux zabbix server. Между ними - интернет, у обоих маршрутизируемые стат. адреса. Что хочу сделать - на заббикс собирать по snmp данные, которые находятся за роутером и висят в отдельной подсети 10.0.0.1/24. Думал в сторону заббикс прокси, но он тоже будет грузить тазик да и БД надо вешать, что не есть правильно. Потому прошу совета - на чем там нынче модно/безопасно делать туннель для данной задачи.

Попробовал последнюю убунту 18,04,2 - все завелось без шаманства arping 100-200 usec (ядро 4.18) Накатил на дебиан ядро 4.19 - та же печальная история 1-20 msec Вот думаю что не в ядре дело.. либо же в конфиге ядра убунты отличия. Собственно рассматриваю вариант мигрировать на убунту lts. Но придется много вещей переписать. Потому вдруг у кого есть идеи по тому как остаться на debian - буду рад.

Фигня какая-то, доставил карту купленную года два назад в Китае. ethtool -i eth1 driver: ixgbe version: 5.5.5 firmware-version: 0x2b2c0001 expansion-rom-version: bus-info: 0000:05:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes ethtool -i eth2 driver: ixgbe version: 5.5.5 firmware-version: 0x2b2c0001 expansion-rom-version: bus-info: 0000:01:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes firmware-version: 0x2b2c0001 одинаковы... вот какая вероятность того, что две карты купленные в разное время в разных местах могут быть идентичны. Есть подозрение, что драйвер сам подтягивает нужную прошивку (не называл бы ее прям так), где-то даже такое встречал на просторах.

Тогда решение моей проблемы - только замена? Все равно не пойму почему на ядрах постарше все хорошо..

Может быть, но вот на Дебиан 7 с арпингом все ок. На рабочей машинке прошивка 0х5...... таки постарше. Я так понимаю в кустарных условиях прошивку не обновить?

Напоминаю, система голая, стоит как обычный хост без нагрузки. Никаких очередей кроме дефолтных нету...

Тоже не дало результата. Нашел жесткий диск еще с 7-м дебианом - arping < 1000 usec, так что железо исключил наверняка. Балуюсь с 9-м - arping 1-15 ms(уже лучше чем было), пинг до этих же хостов - 1-2 мс. Linux d-9 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux driver: ixgbe version: 5.5.5 firmware-version: 0x2b2c0001 expansion-rom-version: bus-info: 0000:01:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes Докручу - попробую ночью переключить, но все же мне такой арпинг не очень нравится. Если кому не сложно посмотрите арпинг от шлюза до хостов клиентов, у кого что твориться.