kernel panic

[Тодор Лазаров]

Имам дебиан 2.6.28-10 с patch IMQ

след рестарт и зареждане на IMQ

modprobe imq

Дебиан-а умира:

В лога пише: "BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]

IMQ го ползвам защото схемата ми е:

eth +

    | vlan...

    | vlan...

С IMQ-to правя общ shaper върху всички влани

та въпроса ми е има ли друг начин за shaper и така да се отърва от IMQ-to

с тази схема съм работил доста повече от 6 месеца, но явно при update на някое приложение съм счупил някоя зависимост

[martos]

http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb

[Тодор Лазаров]

на мен ми трябва тази схема

дали с IFB ще стане

t.e. как да пратя трафика от различните влани към IFB-to

при IMQ-to беше лесно

iptables -t mangle -A PREROUTING -i vlan100 -j IMQ --todev 0

[Тодор Лазаров]

Разбраш го.

Ще го кажа и на другите които четат този пост.

1. Създаваме дисциплината във виртуалния интерфейс ifb0

- създаваме виртуалния интерфеис ifb0

modprobe ifb

ip link set dev ifb0 up

- създаваме класовете в него

tc qdisc del dev ifb0 root

tc qdisc add dev ifb0 root handle 1: htb

tc class add dev ifb0 parent 1: classid 1:1 htb rate 1000Mbit

tc class add dev ifb0 parent 1:1 classid 1:100 htb rate 1Mbit ceil 1Mbit

tc qdisc add dev ifb0 parent 1:100 handle 100: sfq perturb 10

tc filter add dev ifb0 parent 1: protocol ip prio 2 u32 match ip dst 192.168.108.2/32 flowid 1:100

2. Пренасочваме трафика от физическия интерфейс къв виртуалния

......

tc filter add dev vlan101 parent 1: protocol ip u32 match ip dst 192.168.108.2/32 \

action mirred egress redirect dev ifb0

примера е хост 192.168.108.2 който се намира на интерфейс vlan101 искаме да го добавим към въртуалния интерфейс и да му дадем скорост 1Мбит

така може да пренасочим трафика от други физически интерфейси към нашия виртуален интерфейс

ако трябва да вземем всичкия трафик от интерфейс eth0 и да го пратим към виртуалния ifb0

то изпълняваме

tc filter add dev eth0 parent 1: protocol ip \

u32 match u32 0 0 action mirred egress redirect dev ifb0

Идеята е че ако в рутера влизат N-на брой интерфейси, ни е така може да ги пратим към един виртуален интерфеис и там да направим един общ shaper.

[kokaracha]

Ти беше писал в една тема преди,че ще ползваш imq-то. Там имаше съвет да ползваш ifb-to за тая работа.

Вече не ти са нужни вече тези пачове за ингреса,това го можеш вече и в момента с новите ядра.

  Сега ако искаш да не се занимаваш със глупусти,си маркираи правилно трафика идващ от вланите и си направи шейпа на аут дивейса.

[Тодор Лазаров]

Ползвам IMQ щото имам нереални IP-ta, и беш чел че IFB не се справя с NAT

лошото на IMQ-to че докато го дигнеш пачваш като за световно

И след като се преабаш системката немам нерви пак да си гърча като мазохист.

Сега дигнаш IFB благодарско че са дигнали в ядрото ... по подразбиране

иначе за оптимизация позвам и това:

Fast u32 hashing filter generator

благодаря на руманеца дето го е написал

а това как да го разбирам:

"Сега ако искаш да не се занимаваш със глупусти, си маркираи правилно трафика идващ от вланите и си направи шейпа на аут дивейса."

То нашата работа е такава като нямаме хард изпълнение за shaper-и

между другото гледам в Linux от доста отдавна няма нещо ново и револиционно в тази тема ...

така че гърча прoдължава ....

ето едно добро HOWTO благодарско братушки

[Тодор Лазаров]

били ми светнал за следното как да разгранича изходящия и входящия трафик

т.е. така ли би изглеждало:

#Изходящ /upload/

tc qdisc add dev eth0 ingress

tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

#Входящ /download/

tc qdisc add dev eth0 root handle 2: prio

tc filter add dev eth0 parent 2: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb1

като:

- ifb0 е виртуалния за уплоада

- ifb1 е виртуалния за донлоада

правилно ли мисля ... ех че съм неуверен /годинките оказват своето влияние/

защото искам да разделя up/down да ходят на различни виртуални интерфейси