Savszelesseg korlatozas TC-vel VLAN interface-en

( tibby | 2021. 02. 07., v – 11:40 )
Debian GNU/Linux

Sziasztok!

Eth0.101 interface-en szeretnenk limitalni a le es felmeno forgalmat.
Azt olvastam, hogy TC-vel lehet ilyesmit csinalni, de csak a lefele forgalmat szabalyoza es a felfele menetet nem.

Van valakinek javaslata, hogy hogyan lehetne korlatozni a le es fel forgalmat?

Es IP cimtol fuggetlenul szeretnenk, csak az adot VLAN-t. ingress es egress-t.

Koszi!

( wpeople v | 2021. 02. 07., v – 13:44 )

Szerkesztve: 2021. 02. 07., v – 13:45

korlátozni (pontosabb queue-t ill. scheduler-t) csak egress tudsz.

Miután a megfelelő class-okat és qdisc-eket elkészítetted, már csak match-elni kell:
/sbin/tc filter add dev eth0 protocol ip parent 2:0 prio 1 u32 match ip dst a.b.c.d flowid 2:0c0d

Uezt az out interface-re is.

Ha pisztolyt fognak a fejemhez, akkor sem tudom megmondani, hogy a TC esetén a root device az eth0 vagy külön tree-ket tudsz-e felhúzni a külön VLAN-okra.
Nyilván utóbbi lenne a logikus, de pár perc alatt Te is ki tudod próbálni...

Ha most konkretan ezt probaljuk:

tc qdisc add dev eth3.101 root handle 1: htb default 30
tc class add dev eth3.101 parent 1: classid 1:1 htb rate 10mbit
tc class add dev eth3.101 parent 1: classid 1:2 htb rate 10mbit
tc filter add dev eth3.101 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.101/32 flowid 1:1
tc filter add dev eth3.101 protocol ip parent 1:0 prio 1 u32 match ip src 192.168.0.101/32 flowid 1:2

eth3.101 en siman megy a korlatozas lefele, de csak a forras IP fele. Meg nem ertjuk, hogy mit csinaljunk hogy a teljes interface-re legyen a szabaly es ne csak adott IP-re. gondolom match IP src es dst-t kene modositani valamire...

Felfele nem mukodik a dolog, nyilvan mert ingress-re nem lehet ugyan ezen az interface-en. Valaki azt javasolta, hogy csinaljunk egy bridge interface-t eth3.101 re es azon szurjuk a felfele meno forgalmat.

WAN interface van, de ott VLAN nincs felhuzva es anelkul nem hiszem, hogy tudnank szurni.

Hat benazunk nagyon :) de elvileg ez igy mukodik ingress

 

iptables -A PREROUTING -t mangle -i eth3.101 -j MARK --set-mark 101

tc qdisc  add dev eth2 root handle 1:0 htb default 10
tc class  add dev eth2 parent 1:0 classid 1:1 htb rate 10mbit
tc filter add dev eth2 protocol ip parent 1:0 handle 101 fw flowid 1:1

 

mostmar csak egress-re kell megcsinalni.

Ez igy nem mukodik:

iptables -A FORWARD -i eth3.101 -j MARK --set-mark 101

tc qdisc  add dev eth3.101 root handle 1:0 htb default 10
tc class  add dev eth3.101 parent 1:0 classid 1:1 htb rate 10mbit
tc filter add dev eth3.101 protocol ip parent 1:0 handle 101 fw flowid 1:1

Ez igen, de nem MARK-al van, es valahogy azzal szeretnenk iptables-bol, FORWARD rol, de nem sikerul

tc qdisc add dev eth3.101 root handle 1:0 htb default 10
tc class add dev eth3.101 parent 1:0 classid 1:10 htb rate 10mbit prio 0

Megvan!

ingress (Letoltes / Inbound)

iptables -A PREROUTING -t mangle -i eth3.101 -j MARK --set-mark 101

tc qdisc  add dev eth2 root handle 1:0 htb default 10
tc class  add dev eth2 parent 1:0 classid 1:1 htb rate 10mbit
tc filter add dev eth2 protocol ip parent 1:0 handle 101 fw flowid 1:1

egress (Feltoltes / Outbound) 


iptables -A POSTROUTING -t mangle -o eth3.101 -j MARK --set-mark 101

tc qdisc  add dev eth3.101 root handle 1:0 htb default 10
tc class  add dev eth3.101 parent 1:0 classid 1:1 htb rate 10mbit
tc filter add dev eth3.101 protocol ip parent 1:0 handle 101 fw flowid 1:1

na várj, korlatozas lefele, de csak a forras IP fele - itt valami árulás van.
forrás helyett cél IP-t akartál írni, ugye?

többször mondták, hogy csak egress interface-n tudsz korlátozni.
jelen esetben neked az úgy működne, hogy az egress interface az eth1 (mondjuk)
arra ugyanígy megcsinálod a szabályokat (1: helyett 2: lesz)
és IDE teszed az src match -t, valamint a parent 2:0 lesz, a flowid pedig 2:1

a lartc.org-on frankón el tudod olvasni az egésznek a miértjét.
az utolsó sor jelen esetben úgy lenne helyes, hogy:
tc filter add dev eth3.101 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.102/32 flowid 1:2

ebben az esetben a két egymás mellett lévő "leaf" azonos prioritással bír, és egyenlő arányban lesz megosztva köztük a sávszélesség.

"WAN interface van, de ott VLAN nincs felhuzva es anelkul nem hiszem, hogy tudnank szurni."
nem kell VLAN a szűréshez. a VLAN egy "virtuális" interface. azért is volt (számomra) kétséges, hogy a tree root az a fizikai interface-hez kapcsolódik-e, vagy nem. Én azt tartanám logikusnak, hiszen két VLAN interface között is simán lehet "versenyhelyzet".

( mauzi v | 2021. 02. 07., v – 14:01 )

Egy interfészen csak az egress forgalmat tudod szabályozni, de ha a szabályzás egy gatewayen történik, ott jellemzően van (legalább) két interfészed, pl. egy WAN és egy LAN. A felhasználó szemszögéből letöltés irány a LAN interfészen lesz egress, a feltöltés irány pedig a WAN interfészen lesz egress, tehát, tudod szabályozni mindkét irányt, csak nem ugyanazon az interfészen.

( debtamas88 | 2021. 02. 23., k – 21:24 )

Szerkesztve: 2021. 02. 23., k – 21:31

Szia!

Nem tudom működik-e a következő, próbáld ki
 

# bridge létrehozása #
ovs-vsctl addbr br0
ovs-vsctl addbr brvlan100
ovs-vsctl addbr brvlan101
...

# bridge -be interfészek hozzáadása #
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port brvlan100 eth0.100
ovs-vsctl add-port brvlan101 eth0.101
...

# bridge ip-je, L3 #
ifconfig brvlan100 $ip
ifconfig brvlan101 $ip
...

# QOS hozzáadása portra #
ovs-vsctl -- set Port eth0.101 qos=@newqos -- \
--id=@newqos create QoS type=linux-htb other-config:max-rate=10000000 queues=0=@q0 -- \
--id=@q0 create Queue other-config:min-rate=10000000 other-config:max-rate=10000000

# QOS törlése a portról #
ovs-vsctl clear Port eth0.101 qos