traffic shaping probleem

[budi]

Op verzoek van Nelske, een leuk CBQ probleem
(anderen mogen ook helpen hoor )

Ik heb een proefopstelling gemaakt in mijn netwerk met een intern en een extern netwerk, dat ziet er ongeveer als volgt uit:

code:

extern eth0 10.0.0.106
intern eth1 192.168.0.1

client 192.168.0.66

Ik heb kernel 2.4.14 draaien en gebruik iptables om te masquereren van het interne naar het externe subnet. Op zich is dat niet nodig, maar het is om de toekomstige situatie te simuleren dat de server een internet verbinding gaat delen.

Ik gebruik het iptables script van Monmotha. Dit werkt verder prima.

Nu wil ik graag ervoor zorgen dat 1 host van het interne netwerk geknepen wordt, de client 192.168.0.66. Ik heb de Advanced Routing Howto gelezen en me vooral geconcentreerd op pagina 9.

Ik heb het voorbeeldscript wat daar staat aangepast op mijn situatie en dat werkt op zich heel aardig: de downstream wordt keurig geknepen tot 64Kbit (in dit voorbeeld).

Het probleem wat ik heb is dat ik de upstream niet geknepen krijg. Ik vermoed dat dit te maken heeft met het maskeren van de IP adressen.

Het script:

code:

# setup Traffic control:

tc qdisc add dev eth1 root handle 10: cbq bandwidth 10Mbit avpkt 1000

# Nu de rootclass definieren waarvan de andere klassen worden afgeleid:
tc class add dev eth1 parent 10:0 classid 10:1 cbq bandwidth 10Mbit rate \
  10Mbit allot 1514 weight 1Mbit prio 8 maxburst 20 avpkt 1000

# Definieer nu de eerste klasse met een bandbreedte van 64 kbit
tc class add dev eth1 parent 10:1 classid 10:100 cbq bandwidth 10Mbit rate \
  64Kbit allot 1514 weight 4Kbit prio 5 maxburst 20 avpkt 1000 \
    bounded

# Geef nu aan hoe de queues moeten worden behandeld
tc qdisc add dev eth1 parent 10:100 sfq quantum 1514b perturb 15

# Tenslotte welke ipadressen moeten van welke queue gebruik maken
tc filter add dev eth1 parent 10:0 protocol ip prio 100 u32 match ip dst \
  192.168.0.66 flowid 10:100

############ UPLOAD: ############

# setup Traffic control:

tc qdisc add dev eth0 root handle 20: cbq bandwidth 10Mbit avpkt 1000

# Nu de rootclass definieren waarvan de andere klassen worden afgeleid:
tc class add dev eth0 parent 20:0 classid 20:1 cbq bandwidth 10Mbit rate \
  10Mbit allot 1514 weight 1Mbit prio 8 maxburst 20 avpkt 1000

# Definieer nu de eerste klasse
tc class add dev eth0 parent 20:1 classid 20:100 cbq bandwidth 10Mbit rate \
  32Kbit allot 1514 weight 2Kbit prio 5 maxburst 20 avpkt 1000 \
    bounded

# Geef nu aan hoe de queues moeten worden behandeld
tc qdisc add dev eth0 parent 20:100 sfq quantum 1514b perturb 15

# Tenslotte welke ipadressen moeten van welke queue gebruik maken
tc filter add dev eth0 parent 20:0 protocol ip prio 100 u32 match ip src \
  192.168.0.66 flowid 20:100

Ik heb dus eerst een queue aangemaakt op eth1 die al het verkeer naar 192.168.0.66 knijpt (downstream) en dat werkt prima, maar als ik op eth0 een queue aanmaak die het verkeer knijpt wat komt van 192.168.0.66 (upstream) dan gaat het mis.

Ik dacht daarna, moet ik misschien alleen op eth1 blijven werken? Misschien moet ik op eth1 nog een klasse aanmaken, maar dat kan niet, dan zegt ie 'file exists'.

Ik heb ook geprobeerd nog een extra queue aan te maken op eth1 en daar te matchen op de source van 192.168.0.66:

code:

# Definieer nu de tweede klasse met een bandbreedte van 64 kbit
tc class add dev eth1 parent 10:1 classid 10:200 cbq bandwidth 10Mbit rate \
  64Kbit allot 1514 weight 4Kbit prio 5 maxburst 20 avpkt 1000 \
    bounded

tc qdisc add dev eth1 parent 10:200 sfq quantum 1514b perturb 15

tc filter add dev eth1 parent 10:0 protocol ip prio 100 u32 match ip src \
  192.168.0.66 flowid 10:200

De uploads lijken nu wel ietsjes trager te gaan dan normaal: iets van 300 KB/s ipv 900 KB/s, maar dat kan ook komen doordat hij meer CPU tijd nodig heeft.

Wie kan mij helpen? Ik hoop dat ik het probleem een beetje duidelijk heb uitgelegd? Alvast bedankt voor de reacties.

[Verwijderd]

Kijk dit zijn nou eens interessante dingen

Het probleem zit hem inderdaad in het masqueraden. Je moet packets gaan markeren; dit kan in de mangle table van iptables (zie documentatie van iptables).
Probleem is echter dat dit gebeurt voordat het verkeer de NAT table doorgaat.
Wat betekent dit nu. De destination (eigenlijk een intern IP) is op dat moment nog gelijk aan je externe IP.
Tja weg is het punt waarop je kan markeren (is namelijk voor alle interne IP's gelijk)

Helaas kan je dus ook niet voor elke client apart een mark maken. Althans ik heb het nog niet gezien en het is mij ook nog nooit gelukt
Ik vrees dat ik je wat dat betreft zal moeten teleurstellen.

Verkeer dat vanaf de client komt gaan we markeren (eventueel voor Shaping, QOS o.i.d. dit markeren is niet strik noodzakelijk en kan ook met de u32 classifier)

code:

iptables -t mangle -I PREROUTING -s 192.168.0.66/32 -j MARK --set-mark 1

Verkeer dat vanaf internet komt gaan we ook markeren. Je kun hierbij nog onderscheid gaan maken op poorten ed.
Nadat het verkeer ge-deMASQed is is de mark helaas ook weg.

code:

iptables -t mangle -I PREROUTING -s 10.0.0.106/32 -j MARK --set-mark 2

Nu kunnen we dus mooi aan de hand van de marks, het verkeer in gaan delen in CBQ klasses.
Dit gebeurt met de fw classifier i.p.v. de u32 classifier.

M.b.v de fw-classifier gaat je laatste bestaande regel voor upload verkeer er nu dus zo uit zien:

code:

# Tenslotte welke ipadressen moeten van welke queue gebruik maken
tc filter add dev eth0 parent 20:0 protocol ip prio 100 handle 1 fw classid 20:100

en gaat je laatste bestaande regel voor download verkeer er nu dus zo uit zien:

code:

# Tenslotte welke ipadressen moeten van welke queue gebruik maken
tc filter add dev eth1 parent 10:0 protocol ip prio 100 handle 2 fw classid 10:100

Je kan testen door bijvoorbeeld tcpdump te draaien en te kijken naar de TOS velden om te controleren of packets goed gemarkeerd worden (uiteraard moet je dan wel op TOS markeren (-j TOS --set-tos ).

Succes

[edit]
Eerdere verhaal (in aangepaste vorm) werkt alleen met 2 servers, zoals ik hier thuis heb staan.

[budi]

Hardstikke bedankt voor je uitleg!

Dat van het ene IP adres was trouwens maar om te experimenteren, het is uiteindelijk de bedoeling om 1 subnet beperkingen te geven en de andere niet.

Uiteindelijk komt het er ongeveer zo uit te zien:

code:

extern eth0 10.0.0.106
intern eth1 192.168.0.1 gewone PC's
intern eth2 192.168.1.1 wireless LAN

Ik ga er nu even mee rommelen en ik zal morgen wel even posten wat het uiteindelijk is geworden.