red_neon

Можно ли будет совместить ipv4 + ipv6 в одном конфиге? (при условии что ипв6 с маской /64 или меньше)

спасибо! Вопрос, можно ли реализовать шейпирование ipv6 адресов в скрипте? Т.е. хеш таблицы под шестерку Или тут нужен другой метод шейпирования (ipset+iptables)?

Только эти: out_if = eth4 in_if = disable debug = 1 network = 192.168.253.0/24 192.168.230.0/24 192.168.240.0/24 192.168.2.0/24 syslog = 1

Заюзал шейпирование только одного интерфейса, спасибо что реализовали. Сделал как написано в комментах: # Possible values: interface name or "disable" keyword, which disables rule # generation for a specified traffic direction. sc.conf out_if = eth4 in_if = disable Однако: $ sc start $ sc list 2021 192.168.2.3 1024414kibit $ sc sync Cannot find device "disable" Command failed -:1 $ sc version Shaper Control Tool (version 1.5.2) Вроде всё работает но ошибка повторяется каждый раз при синхронизации

Спасибо, всё получилось! Надеемся увидеть такую опцию в новых версиях вашего скрипта, очень полезно в случае с несколькими бгп-сессиями.

photon, спасибо, с $o_if все получается хорошо, а с $i_if - нет, если убрать его во всех функциях, то не могут заполниться массивы например, вот здесь: sub u32_load { my ($ip, $cid, $rate); my $ret = E_OK; open my $TCFH, '-|', "$tc -p -iec filter show dev $i_if" or log_croak("unable to open pipe for $tc"); my @tcout = <$TCFH>; close $TCFH or log_carp("unable to close pipe for $tc"); for my $i (0 .. $#tcout) { ...

photon, подскажите как лучше сделать в такой ситуации. Текущая схема в сети: [юзеры]---[шлюз]---[шейпер]---[бгп]---[интернет]. На шлюзе и бгп по несколько гигабитных интерфейсов. При этом сеть от шлюза до бгп распараллелена по нескольким подсетям (что бы поделить трафик по гигабитным каналам, т.к. суммарный уже не помещается в один гигабит). Возникла идея убрать из этой схемы шейпер, а вместо этого шейпировать (методом шейпинга) входящий трафик на бгп (на интерфейсах в сторону шлюза), а исходящий - на шлюзе (интерфейсах в сторону бгп). Возникает проблема, скрипт не может работать только с один интерфейсом. Сразу оговорюсь - что полисинг не оправдал своих надежд, и мы были вынуждены от него в итоге отказаться. Что посоветуете изменить или закомментить в скрипте что бы новая схема заработала? Т.е. нужно добиться работы шейпера в двух новых режимах, а именно: - шейпировать только исходящий трафик (относительно юзеров) = входящий для данного сетевого адаптера - шейпировать только входящий трафик (для юзеров) = входящий для данного сетевого адаптера, но уже другого маршрутизатора

Забыл упомянуть о том что я уже писал содержимое файла рц.локал, в котором были такие строки: /usr/sbin/ethtool -K eth0 tso off tx off sg off /usr/sbin/ethtool -K eth1 tso off tx off sg off tx off - получается нужно вернуть в on? ----------------------------------- Есть возможность добавить?: 1.несимметричность скоростей, т.е. например входящая 10мбит, исходящая 5мбит. 2.шейпинг+полисинг на одной сетёвке (если сервер представляет собой 3в1: шлюз+шейпер+бгп). 3.табличка с приоритетами трафика с фильтрами по: протоколу, протокол+порт (в основном что бы игруны не жаловались).

Установили дистрибутив Дебиана "Squeeze" (тестируемый): # uname -a Linux sc 2.6.32-5-amd64 #1 SMP Fri Oct 15 00:56:30 UTC 2010 x86_64 GNU/Linux # ethtool -i eth0 driver: e1000e version: 1.0.2-k2 firmware-version: 5.11-2 bus-info: 0000:01:00.1 # ip -V ip utility, iproute2-ss100519 работает 5 дней при тех же нагрузках, не ругается. Видимо проблема была в драйвере сетевой, т.к. в состоянии простоя (без трафика) сервер не подвисал на Debian "Lenny". Там версия драйвера e1000e: 0.3.3.3-k2 Ринги по 4096, в данном случае могут быть: # ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Из этого нужно ли что-то включить или выключить?: # ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off

Проблема. Сервер работает ИДЕАЛЬНО 8-48 часов, а потом зависает, в логах - ничего. Пробовали так 5 раз, всё повторяется. Также переустанавливали линукс, тестировали память, ставили последнюю версию iproute2 (2.6.35) всё равно виснет. ОСь - Дебиан 5(lenny) - 64битный, со всеми последними обновлениями. Сервер: Intel Core 2 Quad 2.5 \ 8Gb RAM Сетёвки: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) sc v1.2 метод u32, shaping dblist 4к ip_conntrack_count в пиках ~ 405к --------------------------------------------------------------------------------------------------------------- rc.local: /usr/sbin/ethtool -K eth0 tso off tx off sg off /usr/sbin/ethtool -K eth1 tso off tx off sg off /usr/sbin/ethtool -G eth0 rx 4096 tx 4096 /usr/sbin/ethtool -G eth1 rx 4096 tx 4096 sleep 3 /sbin/ifconfig eth0 txqueuelen 10000 /sbin/ifconfig eth1 txqueuelen 10000 /bin/echo "400000" > /proc/sys/net/core/netdev_max_backlog /bin/echo "1000448" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max /bin/echo "1000448" > /sys/module/nf_conntrack/parameters/hashsize /bin/echo "0" > /proc/sys/net/ipv4/tcp_sack /bin/echo "1" > /proc/sys/net/ipv4/tcp_window_scaling /bin/echo "1" > /proc/sys/net/ipv4/tcp_timestamps /bin/echo "33554432" > /proc/sys/net/core/rmem_max /bin/echo "33554432" > /proc/sys/net/core/wmem_max /bin/echo "8388608" > /proc/sys/net/core/rmem_default /bin/echo "4194394" > /proc/sys/net/core/wmem_default /bin/echo "4096 8388608 16777216" > /proc/sys/net/ipv4/tcp_rmem /bin/echo "4096 4194394 16777216" > /proc/sys/net/ipv4/tcp_wmem /bin/echo "10000" > /proc/sys/net/unix/max_dgram_qlen /bin/echo "1" > /proc/sys/net/ipv4/tcp_syncookies /bin/echo "400000" > /proc/sys/net/ipv4/tcp_max_syn_backlog /bin/echo "400000" > /proc/sys/net/core/somaxconn /bin/echo "10" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent /bin/echo "10" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv /bin/echo 14400 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established /bin/echo "15" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait /bin/echo "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait /bin/echo "180" > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout /bin/echo "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait /bin/echo "15" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack /bin/echo "10" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close /bin/echo "10" > /proc/sys/net/ipv4/tcp_fin_timeout /bin/echo "1440000" > /proc/sys/net/ipv4/tcp_max_tw_buckets /bin/echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle /bin/echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse /bin/echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl /bin/echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes /bin/echo "1800" > /proc/sys/net/ipv4/tcp_keepalive_time /bin/echo "2" > /proc/sys/net/ipv4/tcp_synack_retries /bin/echo "1" > /proc/sys/net/ipv4/tcp_syn_retries /bin/echo 1 > /proc/sys/net/ipv4/tcp_orphan_retries /bin/echo "16384 61000" > /proc/sys/net/ipv4/ip_local_port_range /bin/echo "1" > /proc/sys/net/ipv4/tcp_no_metrics_save Продолжение:

А как был настроен скрипт на том шейпере с ~4к пользователями: для работы через ipset+iptables или u32? И какая разница между ними вплане быстродействия\ресурсопотребления?

photon Доброго времени суток. Вопрос. С каким количеством пользователей может работать ваш скрипт? 2к, 4к, 6к юзеров? При условии что канал выхода шлюз-шейпер-сервера в интернет 1 гигабит, как в теории, так и на практике.