Как «задушить» соединение через Ethernet до 100 кбит/с?

Пользуюсь Интернет-соединением через Ethernet. В последнее время возникли проблемы со скоростью (крайне нестабильна, колеблется от максимальной до нуля, причём в основном до нуля). При этом провайдер утверждает, что по его показателям у меня на отдачу скорость аж 800 Мбит/с, это при том, что по моему тарифному плану максимум — 10 Мбит/с. В общем, служба поддержки попросила искусственно ограничить скорость соединения до 100 кбит/с. Порывшись в Интернете, составил следующую команду:

ethtool -s eth2 duplex full speed 0.1 autoneg off

В ответ:

ethtool: bad command line argument(s)
For more information run ethtool -h

Попробовал менять:

ethtool -s eth2 duplex full speed 0,1 autoneg off

ethtool -s eth2 duplex full speed '0.1' autoneg off

ethtool -s eth2 duplex full speed "0.1" autoneg off

ethtool -s eth2 duplex full speed '0,1' autoneg off

ethtool -s eth2 duplex full speed "0,1" autoneg off

Ответ тот же.

Прочитал справку, но найти ошибку в команде не могу. Явно чего-то не понимаю. Если просто ввожу:

ethtool -s eth2 speed 0.1

Ответ прежний.

Помогите, пожалуйста, разобраться.

Для справки:

# ethtool eth2
Settings for eth2:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Half 1000baseT/Full 
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes
# lspci | grep -i 'ethernet'
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 06)

man tc - оно как раз для этого создано

"gabix" написал:

служба поддержки попросила искусственно ограничить скорость соединения до 100 кбит/с.

Вот это конечно супер слышать от тех. поддержки. Это как пингануть и любая бабулька справится. Фигли самим напрягаться, Пусть пользователь думает что с их линией.

"gabix" написал:

В последнее время возникли проблемы

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

gabix, а что пинг говорит? Потерь нет на нем?

dyasny, спасибо за подсказку. Попробовал следующее:

tc qdisc add dev eth2 handle 1:0 root dsmark indices 1 default_index 0
tc qdisc add dev eth2 handle 2:0 parent 1:0 tbf burst 20480 limit 20480 mtu 1514 rate 128kbps

Отсюда: http://serverfault.com/questions/452829/limiting-interface-bandwidth-with-tc-under-linux

Но что-то оно ничего не ограничивает.

XliN, по крайней мере, было год всё окей, проблемы начались недели три назад, на моей стороне ничего не менялось.

baralgin, типа вот это:

ping -c 10 mts.by
PING mts.by (217.21.61.18) 56(84) bytes of data.
64 bytes from www.mts.by (217.21.61.18): icmp_seq=1 ttl=59 time=2.23 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=2 ttl=59 time=2.25 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=3 ttl=59 time=2.52 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=4 ttl=59 time=2.02 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=5 ttl=59 time=2.36 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=6 ttl=59 time=2.28 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=7 ttl=59 time=1.95 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=8 ttl=59 time=1.88 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=9 ttl=59 time=2.15 ms
64 bytes from www.mts.by (217.21.61.18): icmp_seq=10 ttl=59 time=1.97 ms
--- mts.by ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 1.881/2.164/2.521/0.194 ms

?

gabix, ну да, только пакетам по 100 статистику посмотрите. И схему включения свою расскажите.

baralgin, по 100 пакетам то же самое, потерь нет, разве что разброс времени пинга больше, до 15 мс (что многовато). Сейчас, похоже, хороший период.

"baralgin" написал:

И схему включения свою расскажите.

В смысле? Кабель, включён непосредственно в разъём на материнской плате, подключён только один компьютер. Управление через KNetworkManager.

Рекомендую прочитать
http://habrahabr.ru/post/24046/

Так же посмотри tcpdump, на наличие постороннего траффика.
Если с твоей стороны все ок, то есть вероятность что тебя или твою сеть ддосят.
У меня такое было. Ддосили по 123 udp. Провайдер говорил забили скорость в 700 мбит

есть ещё вот что:

6.4.3.1. Критерий Limit

Должен подгружаться явно ключом -m limit. Прекрасно подходит для правил, производящих запись в системный журнал (logging) и т.п. Добавляя этот критерий, мы тем самым устанавливаем предельное число пакетов в единицу времени, которое способно пропустить правило. Можно использовать символ ! для инверсии, например -m limit ! --limit 5/s. В этом случае подразумевается, что пакеты будут проходить правило только после превышения ограничения.

http://www.opennet.ru/docs/RUS/iptables/#EXPLICITMATCHES