Jump to content
Калькуляторы

Linux htb iptables потери

Помогите понять почему

Время от времени появляется такая ситуация на 5 - 10 минут вечером в это же время многие жалуются на потери пакетов

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 728.537ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 368.519ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 368.519ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 188.510ms

.....................................

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 32.502ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 852.544ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 852.544ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 664.534ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 0.500ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 0.500ms

Unicast reply from 10.0.40.115 [00:1E:E5:59:8C:45] 0.500ms

А дальше все отлично по 0.500ms

И так на любой хост на устройстве eth0 (побит на вланы)

В топе в этот момент ничего не меняется по iptraf тоже нет никаких всплесков

top - 00:35:29 up 1 day, 1:24, 1 user, load average: 0.24, 0.15, 0.10

Tasks: 89 total, 2 running, 87 sleeping, 0 stopped, 0 zombie

Cpu0 : 0.6%us, 0.2%sy, 0.0%ni, 92.7%id, 0.8%wa, 0.9%hi, 4.8%si, 0.0%st

Cpu1 : 0.6%us, 0.3%sy, 0.0%ni, 83.2%id, 0.0%wa, 3.3%hi, 12.7%si, 0.0%st

Mem: 1539588k total, 900136k used, 639452k free, 209568k buffers

Swap: 1052216k total, 0k used, 1052216k free, 221012k cached

Шейпер
Основные 2 класса

tc qdisc add dev eth0 root handle 1: htb default 1000

tc class add dev eth0 parent 1: classid 1:1 htb rate 18300kbit quantum 18000 # burst 20k

tc class add dev eth0 parent 1: classid 1:2 htb rate 70000kbit quantum 18000 # burst 20k

tc class add dev eth0 parent 1:1 classid 1:1000 htb rate 16kbit quantum 1500 # DEFAULT CLASS

Абонентские

tc class add dev eth0 parent 1:2 classid 1:4216 htb rate 16kbit ceil 4096kbit quantum 3000 # burst 12

tc filter add dev eth0 protocol 802.1q parent 1: prio 2 u32 match ip dst 10.0.40.216 at 20 flowid 1:4216

tc filter add dev vlan740 parent ffff: protocol ip u32 match ip src 10.0.40.216 police rate 1024kbit burst 128k drop flowid :4216

И так на каждого всего 400

На сетевой работают разные вланы абсолютно одинаковая проблемма на всех вланах

Сначала подумал на сетевую, поменял - не помогло

Порт свича и патч корд - не помогло

Сам свитч (пользуясь случаем) - - не помогло

Заметил очень интересную особенность когда переписал vlan с другой сетевой на эту сетевую с ним началась таже история

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

На трафик смотрел(глазами всмысле)? На статистику на интерфейсе этом?

Share this post


Link to post
Share on other sites

Заметил очень интересную особенность когда переписал vlan с другой сетевой на эту сетевую с ним началась таже история

flow control в каком состоянии?

Share this post


Link to post
Share on other sites

Спасибо

flow control в каком состоянии?
На свиче сейчас включил, на сервере сейчас буду разбиратся как

 

На трафик смотрел(глазами всмысле)? На статистику на интерфейсе этом?

До iptraf-ом количество pps и траффик. Оно в этот момент не растет, даже немного снижается

Также снимаются графики Cacti траффик, pps, загрузка cpu и памяти (всплесков нет)

 

net.netfilter.nf_conntrack_max = 65536

net.netfilter.nf_conntrack_count = до 30000 бывало и больше

net.netfilter.nf_conntrack_buckets = 8192

Edited by isup

Share this post


Link to post
Share on other sites
tc filter add dev vlan740 parent ffff: protocol ip u32 match ip src 10.0.40.216 police rate 1024kbit burst 128k drop flowid :4216

Подозреваю, что значение burst надо побольше поставить. 128K для 1Мбит/с это нормально, но для скоростей в десятки мегабит, burst должен быть 1Mb, а то и больше. Либо надо перейти на шейпинг вместо полисинга. Другим узким местом могут быть rx/tx rings у сетевух. Их можно увеличить с помощью ethtool.

Edited by photon

Share this post


Link to post
Share on other sites
tc filter add dev vlan740 parent ffff: protocol ip u32 match ip src 10.0.40.216 police rate 1024kbit burst 128k drop flowid :4216
Подозреваю, что значение burst надо побольше поставить. 128K для 1Мбит/с это нормально, но для скоростей в десятки мегабит, burst должен быть 1Mb, а то и больше. Либо надо перейти на шейпинг вместо полисинга. Другим узким местом могут быть rx/tx rings у сетевух. Их можно увеличить с помощью ethtool.

Спасибо

Увеличить буферы пока не могу

Стояла intel пока поставил дурную на марвеле. Но ситуация 1 в 1

Подскажите пож как перейти на шейпинг. Я думал что сейчас все шейпается

Еще подскажите 400 классов без hashing tables это нормально ? загрузка si до 25%

Share this post


Link to post
Share on other sites
Подскажите пож как перейти на шейпинг. Я думал что сейчас все шейпается

Еще подскажите 400 классов без hashing tables это нормально ? загрузка si до 25%

Я бы уже ввел хэширование, т.к. 400 правил в обе стороны -- это много. Для перехода на шейпинг надо знать, с какого интерфейса отправляется исходящий трафик, который сейчас приходит на vlan740 (где полисинг). Подозреваю, что это eth1. На этом интерфейсе и надо делать шейпинг, т.е. создавать filter, class, leaf qdisc для каждого пользователя, по аналогии с тем, как это сделано на eth0.
Edited by photon

Share this post


Link to post
Share on other sites
Заметил очень интересную особенность когда переписал vlan с другой сетевой на эту сетевую с ним началась таже история
flow control в каком состоянии?

Включение flow control не помогло :(

Share this post


Link to post
Share on other sites
Включение flow control не помогло :(
А какие сетевые вообще?

 

Что говорит

cat /proc/interrupts

 

Share this post


Link to post
Share on other sites
Включение flow control не помогло :(
А какие сетевые вообще?

Что говорит

cat /proc/interrupts

cat /proc/interrupts

s1:~ # cat /proc/interrupts

CPU0 CPU1

0: 145 1 IO-APIC-edge timer

1: 0 2 IO-APIC-edge i8042

2: 0 0 XT-PIC-XT cascade

5: 0 0 IO-APIC-fasteoi ohci_hcd:usb1

6: 0 5 IO-APIC-edge floppy

7: 1 0 IO-APIC-edge parport0

8: 0 2 IO-APIC-edge rtc

10: 165281713 4778 IO-APIC-fasteoi HDA Intel, eth0

11: 54 239808998 IO-APIC-fasteoi sata_nv, ehci_hcd:usb2, eth1

12: 0 4 IO-APIC-edge i8042

14: 53135 3051 IO-APIC-edge libata

15: 0 0 IO-APIC-edge libata

220: 1920770 701 PCI-MSI-edge eth2

NMI: 0 0

LOC: 4779726 4779706

На вход временное решение realtec 8139 (потерь на ней нет)

На выход вместо intel pro пока поставил marvell ситуция 1 в 1

На сетевой работают разные вланы абсолютно одинаковая проблемма на всех вланах

Сначала подумал на сетевую, поменял - не помогло

Edited by isup

Share this post


Link to post
Share on other sites

Помоему сам разобрался

htb default class был 8k увеличил до 64k. Он наверно забивался и хождение arp who-has и arp-rely было затруднено.

Вопрос №2 можно ли увидеть кто или что забивает default class?

Share this post


Link to post
Share on other sites

создайте отдельный класс с высоким приоритетом и скоростью на все локальные нужды (ARP, DHCP, DNS, ICMP, TCP, SSH... и т.д.). дефолт должен играть роль буфера для классифицированного трафика, то есть того о котором вам ничего не известно и/или на качество которого наплевать.

Share this post


Link to post
Share on other sites
создайте отдельный класс с высоким приоритетом и скоростью на все локальные нужды (ARP, DHCP, DNS, ICMP, TCP, SSH... и т.д.).
Спасибо, в точку. Особенно про arp.

Другие наверно не надо т.к. пакет с ip адреса будет попадать в свой класс (тарифный план) а протокол, например dns в другой класс (который 1 на всех) и который 1 пользователь может забить так что будет тормозить у других.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this