Traffic Shaping in AWMN [Αρχείο] - Athens Wireless Metropolitan Network

Achille

19/02/2004, 16:39

Η πρόταση μου με τον paravoid έχει ως εξής:

1) High priority ουρά. Τα πακέτα φεύγουν πρώτα. Έχουν εγγυημένο bandwidth 1Μbit (όταν το χρειαστούν, το κόβει από τους άλλους, όταν δεν το χρειάζονται, το δίνει στους άλλους).

Στην ουρά αυτή μπαίνουν:
Όλα τα UDP (=VoIP, streaming video-audio, το 90% των realtime προτοκόλλων), ICMP. Τα TCP πακέτα που ξεκινάνε τις συνδέσεις. Τα TCP πακέτα των interactive υπηρεσιών (IRC, Telnet, SSH, το interactive session του FTP).

2) Low priority ουρά. Τα πακέτα φεύγουν τελευταία. Δεν έχουν καθόλου εγγυημένο bandwidth. Δεν επιτρέπεται να ξεπεράσουν το 1.5Mbit σε καμία περίπτωση.

Στην ουρά αυτή μπαίνουν όλα τα P2P (DC, Emule, Kazaa, whatever)

3) Νοrmal priority ουρά. Όλα τα υπόλοιπα (HTTP, FTP, Email, ICQ - Jabber, whatever). Χωρίς εγγυημένο bandwidth. Απεριόριστο max bandwidth.

Μελετάται αν υπάρχει τρόπος τα πακέτα του FTP να πέσουν στην κατηγορία 2.

19/02/2004, 16:52

. Δεν επιτρέπεται να ξεπεράσουν το 1.5Mbit σε καμία περίπτωση.

Απλά να ρωτήσω μια διευκρίνηση. Το 1.5Mbps που αναφέρεις είναι απο τα 4.5Mbps πραγματικά διαθέσιμα ενός ιδανικού BB Link ή απο τα 11 θεωριτικά διαθέσιμα ;
Με τα πακέτα που έχουν να κάνουν με "apt" τί κάνουμε ; Σε ποιά κατηγορία πάνε (είναι δλδ http traffic) ;

jabarlee

19/02/2004, 16:53

Εγώ αν έχει καμμία αξία συμφωνώ απολύτως.

Μια παρέμβαση μόνο: απ' ότι κατάλαβα ψάχνοντας λίγο, το shoutcast είναι TCP. Αν όντως είναι έτσι, δεν μπορούμε να ορίσουμε 2 ports standard για shoutcast (8000 που είναι default και ένα ακόμα σε περίπτωση που κάποιος τρέχχει 2 servers) και από εκεί να το εντάξουμε στο high priority;
Αν δεν είναι έτσι γράψε άκυρο

Achille

19/02/2004, 16:55

Αν όντως είναι έτσι, δεν μπορούμε να ορίσουμε 2 ports standard για shoutcast (8000 που είναι default και ένα ακόμα σε περίπτωση που κάποιος τρέχχει 2 servers) και από εκεί να το εντάξουμε στο high priority;
Αν δεν είναι έτσι γράψε άκυρο

Ναι μπορούμε, αρκεί να μην το εκμεταλλευτεί κάποιος για να στήσει σε αυτά τα ports τον ftp server του.

jabarlee

19/02/2004, 16:58

lambrosk

19/02/2004, 17:04

Συμφωνώ!
Άψογο μου ακούγεται.

Achille

19/02/2004, 17:20

Απλά να ρωτήσω μια διευκρίνηση. Το 1.5Mbps που αναφέρεις είναι απο τα 4.5Mbps πραγματικά διαθέσιμα ενός ιδανικού BB Link ή απο τα 11 θεωριτικά διαθέσιμα ;

Είναι από τα πραγματικά διαθέσιμα, ανά κατεύθυνση. Επειδή έχουμε half-duplex επικοινωνία, είναι δυνατόν να έχουμε 5Μbit και προς τις 2 κατευθύνσεις, αλλά ταυτόχρονα έχουμε τα μισά (από 2.5)
Αν ένα link δουλεύει μόνο προς τη μια κατεύθυνση (leecherolink ;)), θα έχουμε μια σχετική σπατάλη bandwidth στα P2P (θα μπορούσαν να πάνε μέχρι 3Mbit ας πούμε), αλλά δεν νομίζω ότι μας ενδιαφέρει ιδιαίτερα.

Με τα πακέτα που έχουν να κάνουν με "apt" τί κάνουμε ; Σε ποιά κατηγορία πάνε (είναι δλδ http traffic) ;

HTTP ή FTP, ότι μας βολέψει.

Το θέμα είναι να περιορίσουμε το μαζικό file transfering τουλάχιστον σε πρώτη φάση (P2P). Όταν μπορέσουμε να αντιμετωπίσουμε και το file transfering μέσω FTP ή HTTP, θα το κάνουμε και αυτό.

MerNion

19/02/2004, 18:06

Θα συμφωνήσω και εγώ στην ιδεά αυτή, καθώς έτσι θα μπορέσουμε να δώσουμε περισσότερη βάση σε δοκιμές VOIP, video broadcasting και άλλες τέτοιες realtime εφαρμογές..

Αυτό που θα ήθελα να ρωτήσω και πιστεύω και αρκετοί ακόμα είναι πως ακριβώς θα επιτευχθεί αυτό το Traffic Shapping.. Απ' ότι έχω δει υπάρχουν δίαφορα προγράμματα για windows και linux που χρησιμοποιούν δίαφοροι στους κόμβους τους κατα καιρούς, αλλά απ' ότι καταλαβαίνω μιλάτε για κάτι οργανωμένο.. Πως θα γίνει δηλαδή η όλη ιστορία; Και θα πρέπει να γίνει από όλους; Από τους κόμβους Ax και Bx μόνο; Από μόνο "κεντρικούς" κόμβους;
Θα το αναλάβεται προσωπικά εσείς οι 2 ή μήπως θα ήταν καλό να κάνετε μια "πρώιμη" ομάδα (αφού ακάμα συζητούνται τα σχετικά) για να βοηθήσουν και κάποιοι άλλοι που ίσως ενδιαφέρονται;

racer

19/02/2004, 18:07

Εμένα θα μου επιτρέψετε να διαφωνίσω:)

Εαν εγώ θέλω να leecharw και το link μου είναι άδειο γιατί να έχω μόνο 1.5Mbit?

Καλύτερα να συζιτήσουμε ένα policy που να κάνει drop πακέτα μόνο όταν γεμίσει η γραμμή. Το πόσα πακέτα θα κάνει drop να ορίζετε απο το priority, πχ να μήν κάνει ποτέ drop ένα SSH πακέτο αλλα να κάνει drop μέχρι και 99% των πακετών που προέρχοντε απο το DC++ ... εγώ έτσι έχω μοιράσει την DSL μου και δέν ήχα ποτέ πρόβλημα :)

xaotikos

19/02/2004, 18:12

Χωρίς να έχω τις απαραίτητες γνώσεις στο αντικείμενο για να μπορέσω να εκφραστώ σωστά:
Γιατί πρέπει σώνει και καλά να υπάρχει αυτός ο στατικός ορισμός των κατηγοριών και των αναλόγων ορίων? Δηλαδή γιατί πρέπει να υπάρχει 1Mbit από τα 2.5 διαθέσιμα που είπες ντε και καλά για κάποιες υπηρεσίες και στην άλλη άκρη 1.5 max για File transfer?

Δεν υπάρχει η δυνατότητα δυναμικής επιλογής του minimum (που χρειάζονται τα services χαμηλού latency - ουράς 1 που λέτε) και ταυτόχρονα του maximum του file transfering? Το mimimum του bandwidth που χρειάζεται την δεδομένη στιγμή το link (βάζοντας και ένα 5-10% περισσότερο για σιγουριά) για υπηρεσίες των κατηγοριών 1-3 που αναφέρεις ποιο πάνω να το παίρνει από τον server και το υπόλοιπο να δίνεται σε file sharing. Όταν το minimum μεγαλώνει το filesharing μικραίνει και αντίστροφα,όταν το minimum μικραίνει το filesharing μεγαλώνει.

Πιστεύω ότι υπάρχει κάποια λογική στην σκέψη μου αλλά δεν ξέρω κατά πόσο μπορεί να εφαρμοστεί. Πάντως φοβάμαι ότι με στατικά όρια θα ε΄χουμε φαινόμενα που σε αρκετούς κόμβους θα "περισσέυουν" μερικά δεκάδες Kbps και είναι κρίμα αφού πάμε να εκμεταλευτούμε και την παραμικρή βελτίωση

MAuVE

19/02/2004, 19:12

Γιατί πρέπει σώνει και καλά να υπάρχει αυτός ο στατικός ορισμός των κατηγοριών και των αναλόγων ορίων?

Ισχύει η αρχή ότι ένα "κακό" μέτρο είναι καλύτερο από την απουσία οποιουδήποτε μέτρου.

Ας εφαρμοσθεί αυτό που σκέφθηκαν και αν μπορεί να βελτιωθεί, ας βελτιωθεί.

Εδώ συνηθίζουμε να βάζουμε άπιαστους θεωρητικούς στόχους, με αποτέλεσμα στην πράξη να μην κάνουμε τίποτα και να αφήνουμε τα πράγματα στη μοίρα τους.
Παράδειγμα :
Το λινκ μου με spirosco σύντομα θα έχει μόνο ιστορική αξία, αφού κάποιος-κάποιοι, πέσαν πάνω στον spirosco και τον "τάπωσαν"
Εμείς ακολουθούμε το "όλοι οι καλοί χωράνε" και το "θα βρούμε τον παρεμβολέα να τον βάλουμε ενδιάμεσο".

Μερικοί πρέπει να δούνε και το κατάρτι να εξαφανίζεται κάτω από το νερό για ν' αντιληφθούν ότι το πλοίο βουλιάζει.

paravoid

19/02/2004, 21:29

Αχ ρε Αχιλλέα, την χάλασες την έκπληξη ;)
Την υπομονή σας παρακαλώ, ακόμα σε φάση δοκιμών είμαστε...

m0bius

20/02/2004, 01:16

Βασικά η λύση είναι το QoS με priority lists.

Έστω ως πρώτη προτεραιότητα το VoIP και δεύτερη το filesharing. Όταν δεν χρησιμοποιείται το link πχ το link από VoIP τo bandwidth καταναλώνεται στο filesharing.
Την στιγμή που κάποιος πάει να χρησιμοποιήσει VoIP μειώνεται το available bandwidth του filesharing και εξασφαλίζεται το VoIP έως ότου να σταματήσει οπότε και επανέρχεται στο filesharing.

Είναι πιο δημοκρατική διαδικασία :-)

Mick Flemm

20/02/2004, 01:17

Well done παιδιά !!! και καλό κουράγιο...

Achille

20/02/2004, 04:56

Είναι πιο δημοκρατική διαδικασία :-)

Πες μας τώρα και πως υλοποιείται :)

Γιατί αν δεν μας πεις, θα μείνουμε στη δική μας φασιστική διαδικασία, που όμως υλοποιείται και δουλεύει :P

Achille

20/02/2004, 05:03

δίνεται σε file sharing. Όταν το minimum μεγαλώνει το filesharing μικραίνει και αντίστροφα,όταν το minimum μικραίνει το filesharing μεγαλώνει.

Πρέπει όμως για να γίνουν αυτά που λες, να ξέρεις το μέγιστο bandwidth που έχεις κάθε στιγμή. Γιατί αν δεν το ξέρεις, πώς θα ξέρεις αν χωράνε να περάσουν όλα ή πρέπει κάτι να κοπεί;

Και επειδή δεν υπάρχει τρόπος να μετρήσεις το bandwidth που έχεις αυτόματα κάθε στιγμή σε ασύρματο δίκτυο, είσαι σε dead end.

Ακόμα και σε DSL- Ethernet σπαταλάς ένα 10% της γραμμής σου, προκειμένου να τη μοιράσεις σωστά, ώστε να μην μαζεύονται τα πακέτα σε ουρές άλλων routers που δεν έχεις έλεγχο. Και στο AWMN δεν έχεις έλεγχο σε όλους τους routers, αλλά σε ένα μέρος αυτών.

Εδώ θα αναγκαστούμε να σπαταλήσουμε κάτι παραπάνω, λόγω της ιδιομορφίας των ασυρμάτων δικτύων. Χάνουμε σε μέγιστη χωρητικότητα, κερδίζουμε σε σωστό καταμερισμό και πλήρη αξιοποίηση της χωρητικότητας που πράγματι χρησιμοποιούμε.

m0bius

20/02/2004, 05:16

Πες μας τώρα και πως υλοποιείται :)

Ε τώρα στην υλοποίηση απαιτείται πειραματισμός :-) Σε θεωρητικό πάντα επίπεδο δεν σε ενδιαφέρει καν πόσο είναι το διαθέσιμο bandwidth. Δίνεις όλο το bandwidth σε όποιο service το απαιτεί εκείνη την ώρα εάν είναι μόνο ένα και στην περίπτωση που υπάρχει κάποιο service με μεγαλύτερο priority τότε πέρνει αυτό κομμάτι από το bandwidth. Και τελικά καταλήγεις σε μια κατάσταση που αν το bandwidth εξαντληθεί και είναι επιπλέον services in queue τότε τα services με το χαμηλότερο priority θα μπούν στην αναμονή ή σε ένα ελάχιστο δυνατό reserved για τέτοιες περιπτώσεις.

Αυτό θεωρητικά εξασφαλίζει το να τρέχουν τα πάντα σχεδόν πάντοτε και να έχουν το περισσότερο δυνατό bandwidth.

Βασικά θα κοιτάξω να το μελετήσω περισσότερο το θέμα μπας και μπορεί να υλοποιηθεί εύκολα μια τέτοια μέθοδος και θα επανέλθω :-)

racer

20/02/2004, 07:05

paravoid

20/02/2004, 08:19

racer,
Για κάνε αυτό (http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html) σε FreeBSD.
(δεν είναι off-topic&OS-flame, όντως αυτό χρησιμοποιούμε μεταξύ άλλων)

Και για απαντήσω σε όλους:
Δεν ισχυριζόμαστε ότι βρήκαμε την τέλεια λύση για όλα τα προβλήματα του AWMN, ισχυριζόμαστε ότι βρήκαμε μια πιθανή (την καλύτερη από όσες βρήκαμε) στο κατ'εμάς μεγαλύτερο πρόβλημα του AWMN.

v.t.b.

20/02/2004, 08:26

Όπα !!!

Δεν εχω επεμβει μέχρι στιγμής ...

Αλλά paravoid θες να πεις οτι θα προταθει επίσημα κάτι τέτιο για τα linuxάκια??

Έχει δοκιμαστει σε μεγάλο φόρτο να δίτε τι κάνει σε κάτι λιγότερο από P3@1Ghz ...

jason

20/02/2004, 09:45

Είναι πιο δημοκρατική διαδικασία :-)

Πες μας τώρα και πως υλοποιείται :)

/* Pipes */
pipe 10 config bw 256Kbits/s queue 24
pipe 50 config bw 240KB/s queue 30

/* Outgoing Queues with GRED */
queue 11 config queue 24 pipe 10 weight 100
queue 12 config queue 24 pipe 10 weight 70 gred 0.001953/18/22/0.15
queue 13 config queue 24 pipe 10 weight 30 gred 0.001953/7/15/0.95

/* Incoming Queues with GRED */
queue 51 config queue 30 pipe 50 weight 100
queue 52 config queue 30 pipe 50 weight 70 gred 0.001953/24/28/0.1
queue 53 config queue 30 pipe 50 weight 50 gred 0.001953/20/27/0.8

// P1 to HIPORTS and ICMP
//add queue 11 udp from EXTERNAL to any HIPORTS out
add queue 11 tcp from EXTERNAL to any HIPORTS out via rl0

//add queue 51 udp from any HIPORTS to EXTERNAL in recv rl0
add queue 51 tcp from any HIPORTS to EXTERNAL in via rl0

// P2 everyone on LAN
add queue 12 tcp from any to EXTERNAL MIDPORTS out via rl0
//add queue 12 udp from any to EXTERNAL MIDPORTS in recv rl0

add queue 52 tcp from any MIDPORTS to EXTERNAL in via rl0
//add queue 52 udp from any MIDPORTS to EXTERNAL out

// P3 All other ports
add queue 13 all from EXTERNAL to any out via rl0
add queue 53 all from any to EXTERNAL in via rl0

Εάν δέν μπορείτε να το κάνετε σε Linux ... βάλτε FreeBSD 8) :lol: :D

Πω Πω αρχικοποιημένες τιμές που βλέπω! χαμός γίνεται. :shock: :shock: :shock: . Διαφωνώ με όλες, ειδικά με αυτά τα ειδικά βάρη (weight) που βάζεις. Τον μαθηματικό τύπο για τα δημόσια έργα εσύ τον έφτιαξες?

Μήπως η πρόταση-σύστημα του Achille είχε λιγότερες αρχικοποιημένες τιμές? Αν ναι, τότε είναι πιο Δημοκρατική από την δικιά σου... Για μετρηθήτε παρακαλώ...

(Για αυτούς που δεν ξέρουν, να διευκρινίσω ότι το QoS απαιτεί dedicated bandwidth, κάτι που ισοδυναμεί με το γεγονός ότι πάντα κάποιο ποσοστό του bandwidth θα παραμένει αχρησιμοποίητο)

Αυτό θεωρητικά εξασφαλίζει το να τρέχουν τα πάντα σχεδόν πάντοτε και να έχουν το περισσότερο δυνατό bandwidth.

Το άλλο με τον τοτό το ξέρεις ;

:mrgreen:

Achille

20/02/2004, 13:53

pipe 10 config bw 256Kbits/s queue 24
pipe 50 config bw 240KB/s queue 30

Τι είναι αυτά φίλε μου racer? Μήπως εδώ δήλωσες το bandwidth που έχει η γραμμή σου;

Τι νόμισες, ότι το BSD έχει το μαγικό ραβδάκι και αψηφά τους νόμους της φύσης; :)

Βάλε τώρα εκεί αντί για 256Kbit, 10Mbit, να δεις άμα ξαναδουλέψει το script σου, όταν έχεις ρυθμίσει λάθος το max bandwidth ;)

Achille

20/02/2004, 13:54

Έχει δοκιμαστει σε μεγάλο φόρτο να δίτε τι κάνει σε κάτι λιγότερο από P3@1Ghz ...

Δουλεύει στον κόμβο μου εδώ και 5-6 μέρες, Ppro 200Mhz, χωρίς σημαντική αύξηση στο load.

racer

20/02/2004, 14:33

Είναι απο την DSL μου στο UK (2mbit/256k) και το έκανα paste ώς παράδειγμα. Λειτουργει κανονικά και απροβλημάτιστα σε εμνένα ακόμα και αν έχουμε 3 ατομα ανοικτά kazaa,ftp,bittorent,klp (= many threads) εγώ μπορώ να κάνω SHH :)

ocean

20/02/2004, 14:35

μια σκέψη:

φαντάζομαι ότι κανένα script δεν μπορεί να πιάσει το traffic μεταξύ των clients του ίδιου AP, μια και δεν απασχολούν το router καθόλου, έτσι;

Λάθος.

Μπορούν να περνάνε μέσα απο τον router, αν το AP σου είναι σε άλλο subnet απο αυτο που είναι οι clients

Παράδειγμα:

AP Address 192.168.1.2 (Default Gateway στο AP ειναι το 192.168.1.1)

Router Address1: 192.168.1.1
Router Address2: 10.1.2.3
Client Addresses: (10.1.2.4-10.1.2.29)

Με αυτό τον τρόπο
1.Το AP ειναι transparent στους Clients (δηλαδή δεν μπορούν να το πειράξουν ούτε να δούν τα configuration pages του - αν εχεις βέβαια κάποια firewall rules)
2.Το Traffic περνάει υποχρεωτικά απο τον router οπου μπορεί να περάσει απο firewall, QOS, traffic shaping κ.λ.π.

Πω Πω αρχικοποιημένες τιμές που βλέπω! χαμός γίνεται...

Καλά δεν θα ασχοληθώ περισσότερο με τα παραπάνω σχόλια, παρα μόνο θα πώ οτι οι τιμές στο (G)RED οντως βγαίνουν με μαθηματικό τύπο, οπως με μαθηματικό τύπο βγαίνουν παρα πολλές αλλες τιμές στο κόσμο του networking. Αν δεν τις ξέρετε διαβάστε να τις μάθετε, αλλοιώς μην πετάτε άσχετα τσιτάτα χωρίς νόημα γιατι γίνεστε πιο αστείοι και απο τους πολιτικούς στα παράθυρα της τηλεόρασης...

(Για αυτούς που δεν ξέρουν, να διευκρινίσω ότι το QoS απαιτεί dedicated bandwidth, κάτι που ισοδυναμεί με το γεγονός ότι πάντα κάποιο ποσοστό του bandwidth θα παραμένει αχρησιμοποίητο)

Σε αυτό εχεις εν μέρει δίκαιο. Υπάρχουν χοντρικά δύο είδων traffic shaping, το static (οπου "κόβεις" το bandwidth σου σε συγκεκριμένα κόμματια και το κάθε κομμάτι δεν μπορεί να "δανείσει" το bandwidth του σε άλλα ακόμη και αν εκείνη την στιγμή "κάθεται") και το dynamic, οπου ουσιαστικά έχεις ολο το bandwidth σε ένα "μπουρί" και απλά δίνεις προτεραιότητα (βάρη) σε συγκεκριμένα πακέτα, για το πιο θα μπεί πρώτα στο "μπουρί" και ποιό θα περάσει πρώτο.
Και τα δύο συστήματα υποθέτουν οτι οντως ξέρεις το bandwidth της σύνδεσης σου γιατί (και αυτό ειναι κάτι που δεν το συνειδητοποιούν πολλοί) ο μόνος τρόπος να κάνεις traffic shaping σε επίπεδο δικτύου ειναι να κάνεις drop πακέτα - ετσι αναγκάζεις το remote end να κάνει adjust το transmission rate του αρα και να μειώθει το bandwidth που χρησιμοποιήται.
Η λέπτομέρεια είναι οτι στην συγκεκριμένη υλοποίηση που έδωσε ο racer σαν παράδειγμα, μπορείς να όρισεις το μέγεθος του queue είτε σε number of packets, είτε σε bytes, πράγμα που σε αποδεσμεύει (μερικά) απο τον περιορισμό του να ορίσεις το total bandwidth της σύνδεσης σου, ή εν πασει περιπτώσει, να μπορείς να το ρυθμίσεις με λιγότερο κόπο.

@paravoid:
απο το site που παραθέτεις:

IPP2P is a netfilter extension to identify P2P filesharing traffic....
....Traffic shaping on this box requires QoS support and at least a scheduler enabled in kernel config

Αρα το πακετό αυτό δεν ειναι το ίδιο ενα traffic shaper, αλλα ενα tool που σε βοηθάει να αναγνωρίσεις P2P sharing πακέτα κοιτώντας το payload τους, και να τα "πασάρεις" στον trafic shaper του συστήματος.

Τρείς παρατηρήσεις:
1. Ο τρόπος που λειτουργεί (κανοντας real-time capture πακέτα) προϋποθέτει οπως πολύ σωστά ανέφερε ο φιλος v.t.b.
σχετικά δυνατό μηχανάκι, πράγμα που επιβαρύνεται ακόμη περισσότερο απο την αυξημένη ταχύτητα των wireless συνδέσεων σε σχέση με αυτές του internet (ISDN aDSL κ.λ.π.) - (Πιο πολλά packets/sec)

2. Αυτό που με κουράζει με το Linux είναι οτι σχεδόν πάντα, για να κάνεις κάτι "σοβαρό", πρέπει να patchρεις τον Kernel, και να ξαναpatchρεις τον Kernel, και να βάλεις αυτο εκει, και να ξανακάνεις compile το άλλο, κλπ κλπ κλπ.... (πρoσωπική άποψη - no flames please)

3. Σχετικά με το αν γινεται στο FreeBSD, η απάντηση ειναι οτι αν η κοινότητα του *BSD θεωρήσει οτι χρειάζεται ενα τέτοιο πρόγραμμα και δεν υπάρχει τρόπος να πετύχει το ιδιο functionality με τα ήδη υπάρχοντα εργαλεία, να είσαι σίγουρος οτι πολύ σύντομα, θα βγεί το συγκεκριμένο πρόγραμμα σε Port η/και package (και κατα πάσα πιθανότητα δεν θα χρειάζεται και recompile στον Kernel) :)

ngia

20/02/2004, 15:56

Λάθος.

Μπορούν να περνάνε μέσα απο τον router, αν το AP σου είναι σε άλλο subnet απο αυτο που είναι οι clients

Παράδειγμα:

AP Address 192.168.1.2 (Default Gateway στο AP ειναι το 192.168.1.1)

Router Address1: 192.168.1.1
Router Address2: 10.1.2.3
Client Addresses: (10.1.2.4-10.1.2.29)

Αν ο πελάτης .4 ειναι στο ίδιο subnet με τον .20 για παράδειγμα, ότι διεύθυνση και να βάλεις στο AP τα πακέτα δε θα φτάσουν στην πόρτα του router. Θα φτάσουν μέχρι το AP και αυτό θα κάνει τη μεταγωγή - bridging.

Achille

20/02/2004, 16:02

Σε αυτό εχεις εν μέρει δίκαιο. Υπάρχουν χοντρικά δύο είδων traffic shaping, το static (οπου "κόβεις" το bandwidth σου σε συγκεκριμένα κόμματια και το κάθε κομμάτι δεν μπορεί να "δανείσει" το bandwidth του σε άλλα ακόμη και αν εκείνη την στιγμή "κάθεται") και το dynamic, οπου ουσιαστικά έχεις ολο το bandwidth σε ένα "μπουρί" και απλά δίνεις προτεραιότητα (βάρη) σε συγκεκριμένα πακέτα, για το πιο θα μπεί πρώτα στο "μπουρί" και ποιό θα περάσει πρώτο.
Και τα δύο συστήματα υποθέτουν οτι οντως ξέρεις το bandwidth της σύνδεσης σου γιατί (και αυτό ειναι κάτι που δεν το συνειδητοποιούν πολλοί) ο μόνος τρόπος να κάνεις traffic shaping σε επίπεδο δικτύου ειναι να κάνεις drop πακέτα - ετσι αναγκάζεις το remote end να κάνει adjust το transmission rate του αρα και να μειώθει το bandwidth που χρησιμοποιήται.

Επομένως συμφωνούμε. Στο παράδειγμά μου, όλες οι ουρές δανείζουν bandwidth στις διπλανές τους, απλά υπάρχουν και δυο αριθμητικά όρια, για να προστατευτούμε από καταχρήσεις, αφού δεν είναι δυνατόν να έχουμε σαφώς ορισμένο το μέγιστο bandwidth.

Αρα το πακετό αυτό δεν ειναι το ίδιο ενα traffic shaper, αλλα ενα tool που σε βοηθάει να αναγνωρίσεις P2P sharing πακέτα κοιτώντας το payload τους, και να τα "πασάρεις" στον trafic shaper του συστήματος.

Ακριβώς. Είναι ένα module για το netfilter, και σε βοηθάει να φιλτράρεις τα P2P και να τα κόψεις - βάλεις σε ουρές προτεραιότητας - περιορίσεις το bandwidth.

1. Ο τρόπος που λειτουργεί (κανοντας real-time capture πακέτα) προϋποθέτει οπως πολύ σωστά ανέφερε ο φιλος v.t.b.
σχετικά δυνατό μηχανάκι, πράγμα που επιβαρύνεται ακόμη περισσότερο απο την αυξημένη ταχύτητα των wireless συνδέσεων σε σχέση με αυτές του internet (ISDN aDSL κ.λ.π.) - (Πιο πολλά packets/sec)

Γι' αυτό και το δοκιμάσαμε, και σε 200Mhz CPU δεν φαίνεται να δημιουργεί πρόβλημα. Αν δούμε ότι δημιουργεί πρόβλημα, το επανεξετάζουμε.

2. Αυτό που με κουράζει με το Linux είναι οτι σχεδόν πάντα, για να κάνεις κάτι "σοβαρό", πρέπει να patchρεις τον Kernel, και να ξαναpatchρεις τον Kernel, και να βάλεις αυτο εκει, και να ξανακάνεις compile το άλλο, κλπ κλπ κλπ.... (πρoσωπική άποψη - no flames please)

Πολύ που μας νοιάζει ρε η άποψή σου για το Linux! Άντε κάνε κανένα compile τα port σου στον 133Mhz router σου, γιατί εμείς κάνουμε apt-get και ξεμπερδεύουμε σε δευτερόλεπτα :) :) :)

3. Σχετικά με το αν γινεται στο FreeBSD, η απάντηση ειναι οτι αν η κοινότητα του *BSD θεωρήσει οτι χρειάζεται ενα τέτοιο πρόγραμμα και δεν υπάρχει τρόπος να πετύχει το ιδιο functionality με τα ήδη υπάρχοντα εργαλεία, να είσαι σίγουρος οτι πολύ σύντομα, θα βγεί το συγκεκριμένο πρόγραμμα σε Port η/και package (και κατα πάσα πιθανότητα δεν θα χρειάζεται και recompile στον Kernel) :)

Προτείνεις δηλαδή να περιμένουμε την κοινότητα του BSD για να εφαρμόσουμε φίλτρα στα P2P στο AWMN? :P

20/02/2004, 16:05

Tο bandwidth ξέρετε τι είναι?
Το bandwidth είναι πόσα πακέτα αφήνω να περάσουν από ένα interface σε κάποιο χρονικό διάστημα.

Αχχχ βρε τζέισον, πας να κάνεις κάτι καλό και τα χαλάς...
Βάλε όπου πακέτα την λέξη "πληροφορία" και είσαι απόλυτα σωστός :lol:

@ocean / Achille
Αντί να κάνετε OSWar δεν συνεργάζεστε λίγο να δούμε αν κάτι παρόμοιο μπορεί να γίνει και στα BSDιά (που άλλωστε όλοι έχουμε μιας και το ΑΜΔΑ το επέλεξε :lol: ) ;
ocean τί λες ; το έψαξες καθόλου να δεις αν υπάρχει παρόμοια λύση "αναγνώρισης" P2P πακέτων.
Όσο για την ισχύ που χρειάζεται θέλω να το δοκιμάσω στο σχετικά μέτριο μηχάνημά μου (Celeron400) που έχει να δουλεύει και 2 non-DMA κάρτες και τους drivers τους +3 με DMA.
Αχιλλέα που είναι εκείνα τα "alpha" πακέτα ;

ocean

20/02/2004, 16:08

Αν ο πελάτης .4 ειναι στο ίδιο subnet με τον .20 για παράδειγμα, ότι διεύθυνση και να βάλεις στο AP τα πακέτα δε θα φτάσουν στην πόρτα του router. Θα φτάσουν μέχρι το AP και αυτό θα κάνει τη μεταγωγή - bridging.

Not true,

Tο εχω ετσι και παίζει σε ενα απο τα τρία APs μου. Για του λόγου το αλήθες, στήσε ενα AP και ενα routerακι οπως στο παράδειγμα, βάλε ενα rule στο router "deny ip from 10.1.2.4 to 10.1.2.20" και πρόσπαθησε να κάνεις ping απο τον client .4 στον client .20

Θα δείς οτι δεν θα μπορείς.

racer

20/02/2004, 18:17

Μισό λεπτάκι, το ερώτημα μας είναι εάν πρέπει να ξέρουμε η να μην ξέρουμε το διαθέσιμο bandwidth ή εάν θα πρέπει να βρούμε την δημοκρατικότερη λύση?

Έκανα αρχικά ένα post με της απόψεις μου, μου ζητήσανε να το υλοποιήσω και έκανα ένα ακόμα post με ένα παράδειγμα που λειτουργεί υπό συγκεκριμένες συνθήκες.

Φυσικά και χρειάζεται μελέτη για να υλοποιηθεί στης συνθήκες που το θέλουμε στο AWMN αλλά άπαξ και γίνει για μένα θα είναι πολύ πιο δίκαιο και δεν θα παραπονιέται κανείς.

@Jason
Σε πληροφορώ ότι το συγκεκριμένο παράδειγμα είναι αρκετά 'light' και ουσιαστικά κάνει favour στο file sharing. Σκέψου ότι το 0.8 drop θα γίνει *μόνο* εάν χρειαστεί.

BladeMaster

20/02/2004, 19:25

Συγνώμη για την ταπεινή μου παρέμβαση . . .
Αλλά έχετε σκεφτεί το εξής:

Από τη στιγμή που το πρόβλημα είναι το filetransfering, θα μπορούσε αυτό να μειωθεί στο μεγαλύτερο μέρος του ΒΒ αν δημιουργηθούν περισσότερα OFFICIAL hubs. Αν 5 άτομα απο το Μαρούσι κατεβάζουν από 5 άτομα στον Πειραιά και από 5 στο Αιγάλεο λογικό και αναμενόμενο είναι να γονατίσει όλο το δίκτυο.

Φαντάζομαι ότι θα υπάρχουν και άλλα hubs εκτός από αυτό του Achille. Όλα αυτά τα λέω γιατί σε αυτό το hub μπαίνω και εγώ και έχω δεί users σχεδόν από όλη την Αθήνα.Αν υπάρχουν και άλλα hubs o πολύς ο κόσμος ΔΕ τα ξέρει, και το λέω αυτό γιατί εγώ που πιστεύω οτι ασχολούμε αρκετά κάθε μέρα με το AWMN ξέρω μόνο 2.

Αν λοιπόν οι χρήστες του κάθε Hub είναι το πολύ 4 hops μακρυά θα σταματήσει πιστεύω το μεγάλο φόρτωμα του ΒΒ. Και με μια καλή επικοινωνία μεταξύ των διαφόρων hub θα μπορεί να εξασφαλιστεί να υπάρχουν περίπου τα ίδια πράγματα σε κάθε ένα από αυτά.Με την παρούσα κατάσταση δεν είναι εύκολο να δεί κάποιος που βρίσκεται ο χρήστης από τον οποίο κατεβάζει κάτι.

Αν μάθουν ΟΛΟΙ πιο Ηub είναι το πιο κοντινό τους και μπαίνουν εκεί ΚΑΙ ΜΟΝΟ εκεί πιστεύω πως θα βελτιωθεί το πράγμα.Και ας υπάρχει κάποιο hub για λ.χ 5 χρήστες και μόνο οι οποίοι θα εκπροσωπούν το hub τους και να προσπαθούν για μια "ισορροπία" μεταξύ του διαθέσιμού υλικού.

Ίσως όλα αυτά να τα είχατε σκεφτεί και για κάποιο λόγο να τα απορρίψατε, δυστυχώς το λόγο αυτό δεν τον διάβασα πουθενά. Ξέρω ότι η πρόταση μου δεν έχει να κάνει σχέση με τη δρομολόγηση αυτή καθέ αυτή αλλά πιστεύω ότι άξιζε να το αναφέρω . . .

xaotikos

20/02/2004, 19:39

Τα 3 πιο γνωστα DC hubs (grgs-jabarlee-achille) είναι ενωμένα μεταξύ τους και όλοι βλέπουν όλους. Ο κάθε χρήστης που πάει να μπει γίνεται redirect στο κοντινότερό του. Το θέμα είναι ότι σε όποιο hub και να είσαι δεν κατεβάζεις μέσω του hub αλλά η σύνδεση είναι απευθείας (peer 2 peer) μεταξύ των 2 χρηστών.
Ίσως αυτό που θα μπορούσε να γίνει (θεωρητικά) είναι να υπήρχε 1 hub στην κάθε περιοχή με τους χρήστες μόνο τις κάθε περιοχής μέσα οι οποίοι θα κατέβαζαν μόνο μεταξύ τους. Έπειτα να υπήρχε ένα search tool που να κάνει search στους users όλων των hub. Το hub από μόνο του να είχε ένα queue list στο οποίο θα έβαζε κάθε αίτηση για download από άλλο hub. Στην ουσία δηλαδή το hub να έκανε download από άλλα hubs και να κρατούσε αυτό το επίπεδο του BW σε ότι επίπεδα θέλει (και χρησιμοποιόντας το queue να ελέγχει πως και πόσο θα κατεβάζει).
Αυτό βέβαια δεν είναι τρόπος αντιμετώπισης του προβλήματος αλλά ιστορίες για αγριούς. Το πρόβλημα λύνεται με ρύθμιση του traffic από τους routers (να δούμε βέβαια ποιος θα τους setarei όλους αυτούς και πόσοι θα είναι λάθος).

ngia

20/02/2004, 20:02

Tο εχω ετσι και παίζει σε ενα απο τα τρία APs μου. Για του λόγου το αλήθες, στήσε ενα AP και ενα routerακι οπως στο παράδειγμα, βάλε ενα rule στο router "deny ip from 10.1.2.4 to 10.1.2.20" και πρόσπαθησε να κάνεις ping απο τον client .4 στον client .20
θα δείς οτι δεν θα μπορείς.

Δυστυχώς δεν έχω πόρτα ελεύθερη για να το δοκιμάσω, αλλά σκέψου ένα AP στον αέρα (δηλ πουθενά συνεδεμένο) με IP από άσχετο δίκτυο. Οι πελάτες .4 και .20 απο το παράδειγμα μας μπορούν να επικοινωνήσουν μεταξύ τους.
Νομίζω ότι αυτό το πείραμα είναι παρόμοιο με αυτό που προτείνεις.

harisk

20/02/2004, 20:27

Η πρόταση μου με τον paravoid έχει ως εξής:

1) High priority ουρά. Τα πακέτα φεύγουν πρώτα. Έχουν εγγυημένο bandwidth 1Μbit (όταν το χρειαστούν, το κόβει από τους άλλους, όταν δεν το χρειάζονται, το δίνει στους άλλους).

Στην ουρά αυτή μπαίνουν:
Όλα τα UDP (=VoIP, streaming video-audio, το 90% των realtime προτοκόλλων), ICMP. Τα TCP πακέτα που ξεκινάνε τις συνδέσεις. Τα TCP πακέτα των interactive υπηρεσιών (IRC, Telnet, SSH, το interactive session του FTP).

Μια σκέψη μόνο.Το ICMP με προβληματίζει, πολλά worms, scanners και άλλα "ευχαρίστα" το χρησιμοποιούν. Μίπως θα πρέπει να το βάλεις στην λίστα 2 ή 3 ? Θα επέλεγα την 3η ουρά (normal) με περιορισμό BW.

Όπως και να έχει είναι πολύ καλή η προσπάθεια, μπράβο!

φιλικά harisk

paravoid

20/02/2004, 21:17

@paravoid:
απο το site που παραθέτεις:

IPP2P is a netfilter extension to identify P2P filesharing traffic....
....Traffic shaping on this box requires QoS support and at least a scheduler enabled in kernel config

Αρα το πακετό αυτό δεν ειναι το ίδιο ενα traffic shaper, αλλα ενα tool που σε βοηθάει να αναγνωρίσεις P2P sharing πακέτα κοιτώντας το payload τους, και να τα "πασάρεις" στον trafic shaper του συστήματος.

Στο post μου δεν έγραψα "μεταξύ άλλων"; :P
Είναι ένα από τα εργαλεία που χρησιμοποιούμε...
Και ναι απαιτούνται και αλλαγές στον πυρήνα (εκτός από IPP2P χρειαζόμαστε και τα CONNMARK & CLASSIFY από το patch-o-matic του netfilter).
Αλλά όπως έχουμε ξαναπεί, σε Debian τη δουλειά την κάνουμε μια φορά εμείς και μετά... apt-get install kernel-image-2.4.25-awmn (φρέσκο πράγμα, χτες το φτιαξα) σε όλους τους υπόλοιπους ;)

Όσοι δεν έχουν Debian (spirosco, nasos κτλ) θα αναγκαστούν να το ξαναφτιάξουν, θα βοηθήσω και εγώ το κατά δύναμιν. Οι προαναφερθέντες πάντως έχουν συμφωνήσει (αν δεν συμφωνούσαν θα έβαζαν debian :twisted: )
Σε BSD δεν θα παίξει και δεν το βλέπω το port εύκολο. Ούτε σε Cisco ούτε σε Windows πρόκειται να παίξει... Ας μπει σε όλα τα Linuxάκια και οι υπόλοιποι ας διαβάσετε το TOS :P

Για την επεξεργαστική ισχύ νομίζω τα είπε ο Αχιλλέας και με στοιχεία.

paravoid

20/02/2004, 21:26

Μια σκέψη μόνο.Το ICMP με προβληματίζει, πολλά worms, scanners και άλλα "ευχαρίστα" το χρησιμοποιούν. Μίπως θα πρέπει να το βάλεις στην λίστα 2 ή 3 ? Θα επέλεγα την 3η ουρά (normal) με περιορισμό BW.

Όπως και να έχει είναι πολύ καλή η προσπάθεια, μπράβο!

φιλικά harisk

Χάρη, νομίζω πως αυτό δεν είναι τόσο μεγάλο πρόβλημα στο μέγεθος που βρίσκεται σήμερα το AWMN. Η ιστορία έχει δείξει ότι όποιοι έχουν worms scanners κτλ, τρώνε το λιγότερο ένα MAC filter ή ένα κόψιμο από το firewall. Εξάλλου τα worms χρησιμοποιούν και UDP για την μεταφορά τους (π.χ. Blaster) και αυτά δεν μπορούμε να τα αποφύγουμε.
Αν αναλογιστούμε ότι τα ICMP χρησιμοποιούνται από διαγνωστικά εργαλεία και μας οφελεί να φεύγουν γρήγορα ίσως αξίζει να βρίσκονται στην 1η ουρά.

koki

21/02/2004, 01:41

Απλά και μόνο επειδή ήταν άσχετα με το traffic shaping κάποια posts απέκτησαν νέο σπίτι!!

ocean

21/02/2004, 16:04

@ocean / Achille
Αντί να κάνετε OSWar δεν συνεργάζεστε λίγο να δούμε αν κάτι παρόμοιο μπορεί να γίνει και στα BSDιά (που άλλωστε όλοι έχουμε μιας και το ΑΜΔΑ το επέλεξε :lol: ) ;

Μα δεν κανουμε OSWar... οπως βλέπεις το κλίμα ειναι απόλυτα φιλικό, αλλωστε μου αρέσει να με πειράζει o Achille, οπως φαντάζομαι οτι του αρέσει να του την "μπαίνω" και εγώ που και που ... :) :) :)

ocean τί λες ; το έψαξες καθόλου να δεις αν υπάρχει παρόμοια λύση "αναγνώρισης" P2P πακέτων.

Το κοιτάω ήδη... I'll get back to you...

spirosco

21/02/2004, 18:58

... (αν δεν συμφωνούσαν θα έβαζαν debian :twisted: )

...για να ψαχνουμε με τα κυαλια ποιος θα μας κανει remote administration στον κομβο μας οταν δεν παιζει το ospf? (βλεπε κομβος koem...αλλοι το στησαν κι αλλοι τρεχαν να το συμαζεψουνε...-Mick δεν αναφερομαι σ'εσενα ) :lol:

jabarlee

21/02/2004, 23:40

Μια απορία ακόμα:

κάποια links παίζουν ή θα παίξουν σε 802.11g. Σε αυτή την περίπτωση τι γίνεται; Δηλαδή, το script έχει κανένα εύκολο configuration (για εμάς τους άσχετους) όσο αφορά το bandwidth κάθε link (και στο πόσο κλειδώνει υπηρεσίες όπως p2p) ? Βέβαια σε αυτά τα Links πρέπει να αλλάξει και το cost στο ospf, αλλά αυτό είναι για άλλο topic
Αν οι παραπάνω παράμετροι είναι κάπου κρυμμένοι, ή δεν ορίζονται κάπου καθαρά, μήπως πρέπει να προβλεφθεί κάτι τέτοιο; Ώστε ο admin ( :? ) κάθε κόμβου να μπορεί να το ρυθμίζει ανάλογα με το τι ισχύει σε κάθε Link του...

paravoid

22/02/2004, 02:09

spirosco

23/02/2004, 03:20

Το traffic shaping ειναι ενεργο απο σημερα στο κομβο μου, εστω και δοκιμαστικα.
Ευχαριστω τον paravoid για το script. (αν δεν παιζει αυτον να βαρατε :lol: )

nasos

24/02/2004, 08:03

Ευχαριστω τον paravoid για το script. (αν δεν παιζει αυτον να βαρατε :lol: )

Δεν μου το στέλνετε κι από'δω, ώστε να έχω έναν λόγο να βαράω κι εγώ τον paravoid; :lol: :lol: :lol:

middle_EAST_WEST

24/02/2004, 08:29

Αν είναι ας ανέβει κάπου στο Ασύρματο για να το πάρει ο κάθε ενδιαφερόμενος.

xaotikos

24/02/2004, 17:11

Προτείνω να μην ανέβει στο wireless και να το παίρνει όποιος θέλει. Γνώμη μου είναι πρώτα να δοκιμαστεί σε μερικούς επιλεγμένους κόμβους και έπειτα αν υπάρχει η δυνατότητα να γίνει ένα how-to ώστε να μπει σωστά.
Βέβαια πολλοί από εσάς έχουν το τεχνικό υπόβαθρο να καταλάβουνε και πως δουλεύει και τι χρειάζεται για να πάιξει σωστά αλλά δεν νομίζω πως θα πρέπει να ρισκάρουμε με κακό σετάρισμα των routers. Ως γνωστόν τίποτα μονιμότερο από το προσωρινό,γιαυτό ας μπει μαζικά μια και καλή (αλλά σωστά).

spirosco

24/02/2004, 21:43

Παιδια, εννοειτε πως οσοι εχουν debian θα κανουν λιγο υπομονη για να παρουν ετοιμα πακετα απο τον Achille με apt-get.

Οι υπολοιποι (slackware,mandrake,redhat κλπ), πρεπει πρωτα να ακολουθησουν μια διαδικασια ωστε να προετοιμασουν τους routers τους για να μπορουν να παιξουν τα παραπανω scripts.

Στο site του IPP2P project αναφερει ολα τα requirements κλπ.
http://rnvs.informatik.uni-leipzig.de/i ... ex_en.html (http://rnvs.informatik.uni-leipzig.de/ipp2p/index_en.html)

Για αρχη:
Πρωτα κατεβαζουμε το πακετο:
[internet] http://www.netfilter.org/files/patch-o- ... 19.tar.bz2 (http://www.netfilter.org/files/patch-o-matic-20031219.tar.bz2) .
[wireless] ftp://ftp1.spirosco.awmn/Linux/AWMN/Pac ... 19.tar.bz2 (ftp://ftp1.spirosco.awmn/Linux/AWMN/Packages/Slackware-9.1/IPP2P/patch-o-matic-20031219.tar.bz2)

Αυτο περιεχει τουλαχιστον 2 απαραιτητα patches για τον kernel (CONMARK, CLASSIFY).
Με το interactive script που υπαρχει μεσα στο πακετο κανουμε apply τα patches στον kernel μας.
Μετα το patcharisma στο compilation menu του kernel θα εχουν προστεθει τουλαχιστον 2 νεες επιλογες.
Συγκεκριμενα στο Networking options\IPV4 Netfilter configuration θα πρεπει να εχουν προστεθει τα Classify filter και Conmark filter.
Τα επιλεγουμε και κανουμε recompile τον kernel.

Οι μη εχοντες debian, καντε πρωτα αυτο (στειλτε pm αν υπαρχει προβλημα) και θα ετοιμασω εναν οδηγο για ολη την -υπολοιπη- διαδικασια.

Ο τολμων νικα...αλλα καλου-κακου καντε πρωτα ενα backup τα kernel sources σας :wink:

Παντως οι πρωτες εντυπωσεις απο το συγκεκριμενο μοντελο traf. shaping ηταν καλες.
Σε interface με δηλωμενο max. bandwidth 4.5 mbit και με 1.5 mbit "κρατημενο" για τα critical services, το throughput ποτε δεν ξεπερασε τα 3 mbits (DC++ , ftp).

middle_EAST_WEST

11/03/2004, 17:47

Για πάρτε λίγο μάτι αυτό:
http://www.cbq.pluton.one.pl/linux/shaperd_cbq_en.html

Σε mandrake δούλεψε χωρίς re-compile kernel και τα σχετικά

Από την στιγμή που υποστηρίζει ipchains μπορεί να δουλέψει και σε συστήματα που δεν έχουν iptables

....After appearing a new user in network and beginning data transfer from internet (local transfer don't allocate bandwidth), shaperd is testing user's connections and compare it with list of exceptions (/etc/shaper/ignore file). If daemon can't find connection in exception list then allocate bandwidth for this user. Size of bandwidth result from simple dividing maximum incoming speed of link by number of currently working users.
After specify time (default: 10 seconds) - shaperd checks utilization of user's allocated bandwidth. If user utilized less than 50% of allocated bandwidth, daemon reduce allocation about 25%. If user utilized more than 75% then shaperd increase bandwidth about minimum guaranteed bandwidth (e.g. 8000 bit/s that is 1 KB/s). If user utilized bandwidth between 50% and 75% then allocation is unchanged. Rule is to allocate bandwidth in sequence for: "new" users, low allocation users and rest of unused bandwidth is assigned to high allocated users. I hope it's clear :) Thanks to it shaperd prevent taking over whole bandwidth by single maniacs of P2P software or idiot opening 30 sesions of FTP in the same moment, Shaperd ...

Rallyeman

06/04/2004, 14:08

Oπως λεμε IBM Compatible, μηπως πρεπει να φτιαχτει και ο CiscoIOS compatible? H το Linux compatible?

Καποιοι απο εμας πιστευω εχουν Cisco συσκευες κι οχι Linux.
Tα ευλογημενα αυτα μηχανακια εχουν μια πληθωρα απο queueing techniques & algorithms για Marking, Classification and Marking, Policing, Shaping... για να διαλεξεις. Αναφορικα παραθετω:

Weighted Fair Queueing
Priority Queueing
Custom Queueing
IP RTP priority queueing
Low Latency Queueing
Class Based Weighted Fair Queueing

χωρια

το Weighted Random Early Detection, το Rate limiting, το Traffic shaping, το CAR κλπ κλπ

και φυσικα

το Network Based Application Recognition!!!

Σε ποιο απ ολα μοιαζει ο αλγοριθμος του Linux για να το ταιριαξω στα Cisco? Μηπως θα πρεπε να ξεκινησετε απο τους ετοιμους αλγοριθμους της Cisco και να τον προσαρμοσετε στο Linux? Για να μην ανακαλυπτετε τον τροχο...

Χ.

Acinonyx

25/10/2004, 20:07

Αυτο περιεχει τουλαχιστον 2 απαραιτητα patches για τον kernel (CONMARK, CLASSIFY).

Το CLASSIFY χρειάζεται σίγουρα; Στα tc filters ύπαρχει η επιλογη fw για να διαβάζει το MARK που έχει τοποθετηθει προηγουμένος από το firewall. Πιά η διαφορά μεταξύ των 2; Μπορεί κάποιος να με διαφωτίσει;

Acinonyx

31/10/2004, 16:53

Τα βρήκα μόνος μου. :P Επίσης έφτιαξα το παρακάτω scriptaκι.

-- EDITED after Debugging

#!/bin/sh
#
# This is the Traffic Control script
#
# Classes:
#
# Major Minor/Marks
# 1 = device imq0 (wlan0) 10 = prio 1
# 20 = prio 2
# 30 = prio 3
# 40 = prio 4
#
# CONNMARKs:
#
# 1 = ipp2p connection

# IMQ Devices Up
ip link set up imq0

#####################
### wlan0 -> imq0 ###
#####################

# Delete tc rules
tc qdisc del dev imq0 root >/dev/null 2>&1

######################
### Root htb qdisc ###
######################

tc qdisc add dev imq0 root handle 1: htb

#########################
## Limit for interface ##
#########################

tc class add dev imq0 parent 1: classid 1:1 htb rate 5Mbit

##############
# Priorities #
##############

# Priority 1 class
tc class add dev imq0 parent 1:1 classid 1:10 htb rate 1.25mbit ceil 5Mbit burst 15k prio 1
tc qdisc add dev imq0 parent 1:10 handle 110: sfq perturb 10
tc filter add dev imq0 parent 1: prio 10 protocol ip handle 10 fw flowid 1:10

# Priority 2 class
tc class add dev imq0 parent 1:1 classid 1:20 htb rate 1.25mbit ceil 5Mbit burst 15k prio 2
tc qdisc add dev imq0 parent 1:20 handle 120: sfq perturb 10
tc filter add dev imq0 parent 1: prio 20 protocol ip handle 20 fw flowid 1:20

# Priority 3 class
tc class add dev imq0 parent 1:1 classid 1:30 htb rate 1.25mbit ceil 5Mbit burst 15k prio 3
tc qdisc add dev imq0 parent 1:30 handle 130: sfq perturb 10
tc filter add dev imq0 parent 1: prio 30 protocol ip handle 30 fw flowid 1:30

# Priority 4 class
tc class add dev imq0 parent 1:1 classid 1:40 htb rate 1.25mbit ceil 5Mbit burst 15k prio 4
tc qdisc add dev imq0 parent 1:40 handle 140: sfq perturb 10
tc filter add dev imq0 parent 1: prio 40 protocol ip handle 40 fw flowid 1:40

####################
### Mangle table ###
####################

#########################
## User Defined chains ##
#########################

# Create chain
iptables -t mangle -N tcmarkin

# Default
iptables -t mangle -A tcmarkin -j MARK --set-mark 30

# Priority 4
iptables -t mangle -A tcmarkin -p tcp -m connmark --mark 0 -m ipp2p --ipp2p -j CONNMARK --set-mark 1
iptables -t mangle -A tcmarkin -p tcp -m connmark --mark 1 -j MARK --set-mark 40

# Priority 3
iptables -t mangle -A tcmarkin -p tcp -m multiport --sports 21,69,873 -j MARK --set-mark 30
iptables -t mangle -A tcmarkin -p tcp -m multiport --dports 21,69,873 -j MARK --set-mark 30

# Priotity 2
iptables -t mangle -A tcmarkin -p tcp -m multiport --sports 25,110,143,80,443 -j MARK --set-mark 20
iptables -t mangle -A tcmarkin -p tcp -m multiport --dports 25,110,143,80,443 -j MARK --set-mark 20

# Priority 1
iptables -t mangle -A tcmarkin -p udp -j MARK --set-mark 10
iptables -t mangle -A tcmarkin -p icmp -j MARK --set-mark 10
iptables -t mangle -A tcmarkin -p tcp --tcp-flags SYN,RST,ACK SYN -j MARK --set-mark 10
iptables -t mangle -A tcmarkin -p tcp -m multiport --sports 22,123,161,23,53,6667,179,10115,10113 -j MARK --set-mark 10
iptables -t mangle -A tcmarkin -p tcp -m multiport --dports 22,123,161,23,53,6667,179,10115,10113 -j MARK --set-mark 10

########################################
## Prerouting chain / Ingress traffic ##
########################################

#########
# wlan0 #
#########

# Mark packets
iptables -t mangle -A PREROUTING -i wlan0 -j tcmarkin

################
# IMQ redirect #
################

# wlan0 to imq0
iptables -t mangle -A PREROUTING -i wlan0 -j IMQ --todev 0

#########################################
## Postrouting chain / Engress traffic ##
#########################################

#########
# wlan0 #
#########

# Mark packets
iptables -t mangle -A POSTROUTING -o wlan0 -j tcmarkin

################
# IMQ redirect #
################

# wlan0 to imq0
iptables -t mangle -A POSTROUTING -o wlan0 -j IMQ --todev 0

-- EDITED after Debugging

Χρησιμοποιώ την ψευδο-συσκευή IMQ για να μπορώ να δανείζω bandwidth από το upload στο download και το αντίθετο αφού στο 802.11b αλληλοεπηρρεάζονται και δεν έχουν σταθερό ceiling. Για επιπλέον συσκευές χρειάζεται να αντιγραφούν οι ίδιες εντολές με τη διαφορά ότι πρέπει να δημιουργηθεί επιπλέον imq device και root qdisc όπως επίσης και child classes και qdiscs. Στο setup μου για 3 wlans αλλάζω το πρώτο ψηφίο των marks ανάλογα με το major number του ανάλογου qdisc (δείτε σχόλια στην αρχή του script). Ανάλογα με την ποιότητα του λινκ τα ceilings και rates πρέπει να αλλάξουν.

Αν υπάρχει κάτι που μού έχει διαφύγει πείτε το μιάς και είναι η πρώτη φορά που φτιάχνω τέτοιο traffic shaping. Όποιος μπορεί ας το δοκιμάσει για να δούμε αν είναι δουλεύει σωστά οπότε να το προσθέσουμε στο slackware repository.

ysam

02/11/2004, 01:43

Πολύ καλό, αλλά χωρίς new compile για connmark στο WRT δεν παίζει.

Επίσης για check αυτό...

# Default
iptables -t mangle -A PREROUTING -i wlan0 -m mark --mark 0 -j MARK --set-mark 226 ---> 126

και κάτι ακόμα.. το burst 15k νομίζω είναι πάρα πολύ και έχει σχέση με το τι cpu έχει ο καθένας. Κάπου διάβασα ότι για 10Μbit ένα καλό burst είναι το 2k για i386 πλατφόρμα.. Αν έκανες δοκιμές και σου παίζει καλά πάω πάσο φυσικά. Εμένα στο wrt που κάνω δοκ. δεν το βλέπω και πολύ σωστό αλλά εκεί βέβαια δεν είναι i386.

Θα κάνω κάποια στιγμή και ένα Post για generic openwrt χωρίς connmark και για 3 interfaces (eth1, vlan2 vlan3) που είναι βασισμένο σε αυτό εδώ αλλά με κάποιες αλλαγές φυσικά.

-Γιάννης

Achille

02/11/2004, 02:00

Γιατί έχει IMQ και ipp2p το wrt?

Καλή ιδέα πάντως το IMQ, αρκεί να είναι stable...

Θα πρότεινα να συνεργαστούμε πάνω στο traffic-shaping για πακέτα slack-debian ώστε να έχουμε ενιαία αντιμετώπιση στο δίκτυο.

Α και κάτι ακόμα. Καλό θα ήταν να κάνουμε ένα scriptάκι που θα του δίνεις το bandwidth που έχει η γραμμή σου και θα βγάζει τα όρια σαν ποσοστά, μιας και κυκλοφορούνε και πιο γρήγορα links από 5Mbit ;)

ysam

02/11/2004, 02:28

Ναι σωστά αυτά τα ξέχασα τα είχα κόψει εξ αρχής και έβαλα για το μεν IMQ κατευθείαν το i/f και το άλλο στον κουβά :)

Πάντος ναι πρέπει να βγεί κάτι generic για να προστατεύουμε τουλάχιστον κανένα ssh και VOIP! και άλλα οπως πχ το BGP!! από τα ipp2p ;)

Acinonyx

02/11/2004, 21:09

Επίσης για check αυτό...

# Default
iptables -t mangle -A PREROUTING -i wlan0 -m mark --mark 0 -j MARK --set-mark 226 ---> 126

Σωστός! Το διόρθωσα... Βρήκα και μερικά άλλα bugs και τα διόρθωσα κι αυτά. Ένα ήταν ότι αυτό -> # Default
iptables -t mangle -A POSTROUTING -o wlan0 -m mark --mark 0 -j MARK --set-mark 116 όπου δεν έβαζε το default mark αφού είχε μαρκαριστέι πριν με non-zero στο PREROUTING και ένα δεύτερο είναι ότι έκανα restore στο CONNMARK με mark που δεν χαρακτηρίζει την σύνδεση αλλά την προτεραιότητα.

Το δοκίμασα και διασταύρωσα τα στατιστικά του με το iptraf και τα στατιστικά των iptables και δείχνει να παίζει πολύ καλά. :)

spirosco

02/11/2004, 21:18

Μεχρι το ΣΚ πιστευω να το εχω σηκωσει κι εγω δοκιμαστικα (ισως το σηκωσω και σε tenorism,b52 ταυτοχρονα).
Το imq ειναι στα 2.4.26 slack packages (το χρησιμοποιω 3-4 μηνες στη dsl), το testing σε επιπεδο wireless backbone μας λειπει.

ysam

03/11/2004, 00:06

Παιδιά Plz κάποιος να ασχοληθεί με το openwrt γιατί εγώ δεν μπορώ ούτε να ... σω και χρόνο έχω μόνο τα Σ/Κ και αν...

@Acinonyx

Γιατί βάζεις το default πρώτο ?

Ηπάρχει και ή λύση του RETURN για να είσαι σιγουρος ότι δεν θα πάει παρακάτω.

Acinonyx

03/11/2004, 14:04

Έβαλα το default πρώτο γιατί ένα πακέτο μπορεί να είναι ήδη μαρκαρισμένο από το PREROUTING chain με το if από το οποίο εισήλθε και δεν μπορώ να ελεγξω ευκολά σε ποιό σημείο markαρίστικε στο τέλος.. Δυστυχως δεν μπορώ να χρησιμοποιήσω το -j RETURN γιατί στο τέλος το στέλνω στο IMQ. Δοκίμασα να το στείλω στο IMQ μετά από κάθε μαρκάρισμα αλλά δεν είδα κάποια διαφορά στο latency ενω το script έγινε περίπλοκο και δυσανάγνωστο.

Achille

03/11/2004, 23:06

Γιατί βάζεις διαφορετικά marks ανά IMQ και incoming-outgoing?

Acinonyx

04/11/2004, 03:22

Γιατί βάζεις διαφορετικά marks ανά IMQ και incoming-outgoing?

Για το incoming-ougoing είναι διαφορετικά γιατί και τα incoming κατι τα outgoing καταλήγουν στο ίδιο IMQ οπότε πρέπει να ξεχωρίζουν ώστε να δανείζεται το ένα από το άλλο.

Για τα διαφορετικά IMQ είναι γιατί θέλω σε κάθε IMQ να μπορώ να έχω διαφορετικά rates και ceiling όπως επίσης και τη δυνατότηα να έχω διαφορετικά priorities ( :twisted: ) χωρίς να επηρρεάζω κάποιο άλλο traffic shaping που μπορεί να τρέχει σε μία eth ή σε κάποιο ppp.

Υ.Γ. Βρήκα άλλο ένα τυπογραφικό λάθος και το διόρθωσα.

Achille

04/11/2004, 04:06

Για το incoming-ougoing είναι διαφορετικά γιατί και τα incoming κατι τα outgoing καταλήγουν στο ίδιο IMQ οπότε πρέπει να ξεχωρίζουν ώστε να δανείζεται το ένα από το άλλο.

Αφού καταλήγουν στο ίδιο, αν τα έριχνες μαζί στον κουβά, θα το μοιράζονταν έτσι και αλλιώς, αφού θα ήταν στην ίδια ουρά.

Έχεις φτιάξει διπλές ουρές με δανειζόμενο bandwidth, ενώ μπορούσες να φτιάξεις απλές ουρές που θα τους έδινες το συνολικό bandwidth και θα έριχνες μέσα τα πακέτα είτε ήταν ingress είτε egress.

Αν κάνω κάπου λάθος, διόρθωσέ με, γιατί δεν έχω δουλέψει το IMQ.

Για τα διαφορετικά IMQ είναι γιατί θέλω σε κάθε IMQ να μπορώ να έχω διαφορετικά rates και ceiling όπως επίσης και τη δυνατότηα να έχω διαφορετικά priorities ( :twisted: ) χωρίς να επηρρεάζω κάποιο άλλο traffic shaping που μπορεί να τρέχει σε μία eth ή σε κάποιο ppp.

Το διαφορετικά priorities ναι, αν και λίγο τραβηγμένο για generic script για traffic shaping στο AWMN. Τα διαφορετικά rate-ceil δεν έχουν να κάνουν με το marking σου, αλλά με τη δημιουργία των ουρών στο tc.

Δεν καταλαβαίνω λοιπόν για ποιο λόγο μαρκάρεις τα πακέτα με τόσους τρόπους και έχεις κάνει τόσο πολύπλοκο το script, ενώ απλά χρειάζεσαι ένα mark για κάθε ουρά, δηλαδή 4, άντε και κανά 2 για το CONNMARK.

Επίσης έχεις μπλέξει με τους classifiers του tc, ενώ με το CLASSIFY patch του patch-o-matic του netfilter τα πράγματα απλοποιούνται πολύ ;)

Acinonyx

04/11/2004, 04:51

Αφού καταλήγουν στο ίδιο, αν τα έριχνες μαζί στον κουβά, θα το μοιράζονταν έτσι και αλλιώς, αφού θα ήταν στην ίδια ουρά.

Έχεις φτιάξει διπλές ουρές με δανειζόμενο bandwidth, ενώ μπορούσες να φτιάξεις απλές ουρές που θα τους έδινες το συνολικό bandwidth και θα έριχνες μέσα τα πακέτα είτε ήταν ingress είτε egress.

Αν κάνω κάπου λάθος, διόρθωσέ με, γιατί δεν έχω δουλέψει το IMQ.

Θα τα μοιράζονταν βέβαια αλλά δεν θα είχαν τα incoming και τα outgoing κάποιο εγγυημένο rate. Θέλω να ελεγχω τι rate έχω σε κάθε μία κατευθυνση ξεχωριστά και όχι και στις 2 κατευθύνσεις μαζί. Αν έχω και από τις 2 πλευρές ενός λινκ, outgoing της ίδιας priority και με το ίδιο rate αυτό δε σημαίνει ότι κάθε πλευρά θα πάρει ακριβώς το μισό bandwidth από το κοινό κανάλι όταν το αυτό κορεσθεί. Το script αυτό ελπίζω ότι θα αντιμετωπίσει το πρόβλημα όπου το download "καπελώνει" το upload και το αντίτθετο.

Το διαφορετικά priorities ναι, αν και λίγο τραβηγμένο για generic script για traffic shaping στο AWMN.

Τα διαφορετικά rate-ceil δεν έχουν να κάνουν με το marking σου, αλλά με τη δημιουργία των ουρών στο tc.

Δεν γλύτωνα τίποτα πάντως σε εντολές ακόμη κι αν δεν έβαζα ξεχωριστά marks για κάθε IMQ. Δεν μπορούσα να markάρω γενικά όλα τα πακέτα που περνάνε από το box γιατί υπάρχουν κι άλλα interfaces που μπορεί να τρέχουν με άλλο traffic shaping π.χ. μία ppp DSL ή ένα AP. Οπότε πρέπει να τα μαρκάρω για κάθε interface μιας και δεν υπάρχει module που να διαλέγεις multiple interfaces. Αφού το κάνω αυτό βάζω και διαφορετικό mark για να τα ξεχωρίζω και καλύτερα.

Επίσης έχεις μπλέξει με τους classifiers του tc, ενώ με το CLASSIFY patch του patch-o-matic του netfilter τα πράγματα απλοποιούνται πολύ ;)

Είδα ότι είναι ακόμη experimental και δεν ήθελα να το ρισκάρω. :)

Achille

04/11/2004, 05:11

Αν έχω και από τις 2 πλευρές ενός λινκ, outgoing της ίδιας priority και με το ίδιο rate αυτό δε σημαίνει ότι κάθε πλευρά θα πάρει ακριβώς το μισό bandwidth από το κοινό κανάλι όταν το αυτό κορεσθεί.

Μα δεν θέλουμε να πάρει το μισό. Θέλουμε κάθε stream να μοιραστεί, και αυτό το κάνει το sfq που έχεις παρακάτω.

Άκου ας πούμε παράδειγμα. Από την μια κατεύθυνση κατεβάζει ένας, και από την άλλη, δέκα. Οι δέκα θα μοιραστούνε τα 2.5Mbit, και ο άλλος θα πάρει άλλα 2.5Mbit μόνος του.

Δεν νομίζω ότι είναι ιδιαίτερα δίκαιο. Δώστους στο sfq όλους μαζί, και αφού έχεις στον ίδιο κουβά όλες τις ουρές από όλες τις κατευθύνσεις, δεν θα πατήσει κανένας τα high priority, είτε της μιας είτε της άλλης κατεύθυνσης.

Δεν γλύτωνα τίποτα πάντως σε εντολές ακόμη κι αν δεν έβαζα ξεχωριστά marks για κάθε IMQ.

Γλίτωνες όμως σε νούμερα και σε καθαρότητα. Ήδη διόρθωσες αρκετά λάθη που οφείλονται στην πολυπλοκότητα αυτή ;)

Keep it simple.

Είδα ότι είναι ακόμη experimental και δεν ήθελα να το ρισκάρω. :)

Παίζει εδώ και κανένα χρόνο στο trafshape-awmn απροβλημάτιστα, και έχει μπει στον 2.6 εδώ και 2-3 εκδόσεις.

acoul

04/11/2004, 08:01

Δύο σχετικά links με το θέμα:

http://p2pshaper.sourceforge.net/
http://l7-filter.sourceforge.net/

Achille

04/11/2004, 10:10

http://l7-filter.sourceforge.net/

Αυτό το έχουμε υπόψιν, αλλά μέχρι πρόσφατα έπαιζε μόνο με 2.6. Επίσης διαβάζει τα φίλτρα από text αρχεία, ενώ το ipp2p τα έχει hardcoded, με αποτέλεσμα να μην γνωρίζουμε πόσο impact θα έχει στη CPU του συστήματος.

Ας αποφασίσουμε πρώτα τι θέλουμε να κάνουμε με τις ουρές, και μετά ψαχνόμαστε για καλύτερους classifiers.

Acinonyx

04/11/2004, 15:27

Μα δεν θέλουμε να πάρει το μισό. Θέλουμε κάθε stream να μοιραστεί, και αυτό το κάνει το sfq που έχεις παρακάτω.

Άκου ας πούμε παράδειγμα. Από την μια κατεύθυνση κατεβάζει ένας, και από την άλλη, δέκα. Οι δέκα θα μοιραστούνε τα 2.5Mbit, και ο άλλος θα πάρει άλλα 2.5Mbit μόνος του.

Είναι όπως το βλέπει κανείς. Εγώ το έφτιαξα με τη λογική να περνάνε ίσα incoming και outgoing όταν είναι πηγμένο. Η σκέψη σου είναι όμως σωστή γιατί είναι πιό σημαντικό πόσοι εξυπηρετούνται παρα τι κίνηση περνάει. Οπότε θα το αλλάξω... :)

Ερώτηση: Μπορώ να στείλω στο CLASSIFY από το prerouting chain; Κάπου πήρε το μάτι μου ότι γίνεται μόνο στο POSTROUTING. Μπορεί να το δοκιμάσει κάποιος να μου πει αν ισχύει; Αλλιώς θα πρέπει να κάνω compile τον kernel. :roll:

Acinonyx

04/11/2004, 17:05

Παίζει εδώ και κανένα χρόνο στο trafshape-awmn απροβλημάτιστα, και έχει μπει στον 2.6 εδώ και 2-3 εκδόσεις.

Το κατέβασα το scriptάκι και είδα ότι μόνο sfq κάνει και είναι και classless. :?: :!: Που το χρησιμοποιήσες το classify βρε??? :)

Achille

05/11/2004, 04:51

Αυτό είναι το trafshape-awmn όπως ήταν μέχρι σήμερα.

/etc/init.d/trafshape_netfilter

#!/bin/sh

modprobe ipt_ipp2p

# netfilter section

iptables -t mangle -F

iptables -t mangle -A PREROUTING -j TOS --set-tos Normal-Service

for CHAIN in PREROUTING OUTPUT; do

# UDP - ICMP - TCP SYN

iptables -A $CHAIN -t mangle -p udp -j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p icmp -j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN \
-j MARK --set-mark 1

# P2P

iptables -t mangle -A $CHAIN -p tcp -j CONNMARK --restore-mark
iptables -t mangle -A $CHAIN -p tcp -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A $CHAIN -p tcp -m ipp2p --ipp2p -j MARK --set-mark 3
iptables -t mangle -A $CHAIN -p tcp -m mark --mark 3 -j CONNMARK --save-mark

# Telnet, ssh & ftp

iptables -A $CHAIN -t mangle -p tcp --sport ssh \
-j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p tcp --dport ssh \
-j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p tcp --sport telnet \
-j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p tcp --dport telnet \
-j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p tcp --sport ftp \
-j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p tcp --dport ftp \
-j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p tcp --sport 6667 \
-j MARK --set-mark 1
iptables -A $CHAIN -t mangle -p tcp --dport 6667 \
-j MARK --set-mark 1

# VPNs

iptables -A $CHAIN -t mangle -p udp --sport 65000:65535 \
-j MARK --set-mark 2
iptables -A $CHAIN -t mangle -p udp --dport 65000:65535 \
-j MARK --set-mark 2

done

iptables -t mangle -A POSTROUTING -m mark --mark 1 -j CLASSIFY --set-class 1:10
iptables -t mangle -A POSTROUTING -m mark --mark 2 -j CLASSIFY --set-class 1:20
iptables -t mangle -A POSTROUTING -m mark --mark 3 -j CLASSIFY --set-class 1:30

iptables -t mangle -A POSTROUTING -m mark --mark 1 -j TOS --set-tos Minimize-Delay
iptables -t mangle -A POSTROUTING -m mark --mark 3 -j TOS --set-tos Maximize-Throughput

# Enable IP Forwarding
if [ -e /proc/sys/net/ipv4/ip_forward ]; then
echo -n "Enabling packet forwarding: "
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "done."
fi

# Disable rp_filter
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n "Disabling rp_filter: "
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 0 > $f
done
echo "done."
fi

# Increase number of max conntrack connections
if [ -e /proc/sys/net/ipv4/ip_conntrack_max ]; then
echo -n "Setting ip_conntrack_max to 100000: "
echo 100000 > /proc/sys/net/ipv4/ip_conntrack_max
echo "done."
fi

/usr/sbin/trafshape_up

#!/bin/sh
IFACE=$1
RATE=$2

if [ "$IFACE" == "lo" ]; then
exit
fi

# traffic shaping section

tc qdisc del dev $IFACE root >/dev/null 2>&1

tc qdisc add dev $IFACE root handle 1: htb default 20

tc class add dev $IFACE parent 1: classid 1:1 htb rate $RATE

# High priority traffic
tc class add dev $IFACE parent 1:1 classid 1:10 htb rate 1mbit ceil 1mbit prio 1
# General traffic
tc class add dev $IFACE parent 1:1 classid 1:20 htb rate 128kbit ceil $RATE prio 2
# Bulk traffic
tc class add dev $IFACE parent 1:1 classid 1:30 htb rate 128kbit ceil 1.5mbit prio 3

tc qdisc add dev $IFACE parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $IFACE parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $IFACE parent 1:30 handle 30: sfq perturb 10

Σου έχω και άλλα νέα που τα συζητούσαμε με τον paravoid στο τηλέφωνο, ότι δηλαδή δεν έχουν νόημα οι priorities στο ingress, και επίσης δεν έχει νόημα να βάζεις rates στο ingress εκτός από τα tcp πακέτα.

Επίσης μου είπε πως είδε το dummy net device και κάνει ακριβώς ότι χρειαζόμαστε από το imq, και είναι μέσα στον πυρήνα.

Άλλη ώρα όμως που θα έχω χρόνο να σου εξηγήσω ;)

Acinonyx

05/11/2004, 14:39

Σου έχω και άλλα νέα που τα συζητούσαμε με τον paravoid στο τηλέφωνο, ότι δηλαδή δεν έχουν νόημα οι priorities στο ingress, και επίσης δεν έχει νόημα να βάζεις rates στο ingress εκτός από τα tcp πακέτα.

Επίσης μου είπε πως είδε το dummy net device και κάνει ακριβώς ότι χρειαζόμαστε από το imq, και είναι μέσα στον πυρήνα.

Άλλη ώρα όμως που θα έχω χρόνο να σου εξηγήσω ;)

Δεν χρειάζεται να μου εξηγήσεις για το ingress. Φαντάζομαι ότι στηρίζεται στο ότι δεν μπορείς να ελεγξεις το rate που θα σου στείλει ο άλλος. Στα TCP μπορείς να το ελεγξεις κάνοντας drop τα πακέτα ενώ στα UDP όχι. Πρέπει όμως με κάποιο τρόπο να μετράω το incoming rate για να ρυθμίζω και το outgoing. Αν τα incoming UDP και ICMP φτάσουν πάνω από 1,25mbits τότε θεωρείται flood οπότε ας τα κάνω drop.

Το dummy device το είχα και εγώ υπόψην αλλά είδα πως δεν είναι τόσο βολικό όσο το IMQ.

Achille

05/11/2004, 20:01

Αν τα incoming UDP και ICMP φτάσουν πάνω από 1,25mbits τότε θεωρείται flood οπότε ας τα κάνω drop.

Άμα τα κάνεις drop όμως, δεν τα μετράς σωστά. Πχ αν έχεις 5Μbit UDP traffic και εσύ την κάνεις "drop" στο 1Mbit, θα νομίζεις ότι έχεις ένα, ενώ θα έχεις πέντε. Αντιθέτως στο egress, θα τα κάνεις drop κανονικότατα.

Πρέπει να τα βάλεις εκτός ορίων, απλά για να μετράς πόσα είναι και να κανονίζεις τις υπόλοιπες ουρές (όχι εσύ, το σύστημα).

Το dummy device το είχα και εγώ υπόψην αλλά είδα πως δεν είναι τόσο βολικό όσο το IMQ.

Προς το παρόν, δεν ξέρω / δεν απαντώ ;)

Επίσης χρειαζόμαστε μια παράμετρο στο script που να σηκώνει μόνο το egress σε κάποιο interface, αν και ο απέναντι κόμβος τρέχει trafshape, για να μην κάνουμε διπλή δουλειά χωρίς λόγο.

Acinonyx

05/11/2004, 20:44

Άμα τα κάνεις drop όμως, δεν τα μετράς σωστά. Πχ αν έχεις 5Μbit UDP traffic και εσύ την κάνεις "drop" στο 1Mbit, θα νομίζεις ότι έχεις ένα, ενώ θα έχεις πέντε.

Ναι αλλά με αυτό τον τρόπο θα πιστεύω (όχι εγώ :P ) ότι έχω bandwidth διαθέσιμο και θα ξεκινήσω να στέλνω. Επειδή το κανάλι είναι κοινό και για τις 2 κατευθύνσεις το αποτέλεσμα θα είναι να πέσει το ανεγξελεκτο ingress rate.

Achille

06/11/2004, 04:17

Ναι αλλά με αυτό τον τρόπο θα πιστεύω (όχι εγώ :P ) ότι έχω bandwidth διαθέσιμο και θα ξεκινήσω να στέλνω. Επειδή το κανάλι είναι κοινό και για τις 2 κατευθύνσεις το αποτέλεσμα θα είναι να πέσει το ανεγξελεκτο ingress rate.

Το QoS σου όμως θα πάει περίπατο, ελπίζω να καταλαβαίνεις γιατί :)

Εκεί που θέλω να καταλήξω είναι ότι η σωστή λύση είναι να εφαρμοστεί το egress σε ολόκληρο το AWMN, και να χρησιμοποιείται το ingress κυρίως σε περιπτώσεις ανάγκης, όπου ο απέναντι για κάποιο ανεξήγητο λόγο (Cisco :)) δεν μπορεί να το εφαρμόσει. (Θα ήθελα να δώ υλοποίηση των παραπάνω σε IOS αν κάποιος έχει τις γνώσεις να το κάνει...)

Το να μετράμε όμως πόσο bandwidth περνάει από το ingress είναι πολύ καλή ιδέα για το QoS μας, αφού έχουμε δανειζόμενο bandwidth, αρκεί να μετράμε πόσο πραγματικά περνάει και όχι πόσο θα θέλαμε εμείς να πέρναγε ;)

mindfox

06/11/2004, 13:37

Αχιλλέα,

για να μη κάθομαι να μαθαίνω iptables και ipchains, αν μπορείς με απλά λόγια να μου εξηγήσεις το set των κανόνων, θα δω τι μπορεί να γίνει και για Cisco

Acinonyx

06/11/2004, 14:18

Εκεί που θέλω να καταλήξω είναι ότι η σωστή λύση είναι να εφαρμοστεί το egress σε ολόκληρο το AWMN, και να χρησιμοποιείται το ingress κυρίως σε περιπτώσεις ανάγκης, όπου ο απέναντι για κάποιο ανεξήγητο λόγο (Cisco :)) δεν μπορεί να το εφαρμόσει. (Θα ήθελα να δώ υλοποίηση των παραπάνω σε IOS αν κάποιος έχει τις γνώσεις να το κάνει...)

Δες το αρχικό post που έκανα. Το IMQ το χρησιμοποίησα για να μετράω το ingress και όχι τόσο πολύ για shaping. Αν γίνει μόνο egress και στις δύο πλευρές τότε δεν θα μπορεί η μία πλευρά να ξέρει το διαθέσιμο bandwidth που έχει γιατί αυτό εξαρτάται και από την άλλη. Θα το χωρίσεις 2,5 και 2,5mbits; Έτσι δεν θα εκμεταλλεύεσαι όλο το κανάλι. Γιαυτό το λόγο ήθελα το ingress. Κατέβασα κάποια script που κυκλοφορούσαν στο AWMN και είδα ότι περιόριζαν την εξεχόμενη κίνηση στο μισό της χωρητικότητας του καναλιού γιατι απλά δεν μπορούσαν να μετρήσουν την ingress traffic. Δεν είναι δυνατόν να έχουμε ένα κανάλι χωρίς traffic από τη μία κατεύθυνση και σώνει και καλά να περιορίζεται στα 2,5 ενώ μπορεί να δεχτεί μέχρι 5. Πάντως το scriptάκι δουλευει μιά χαρά αν το έχουν και οι 2 κατευθύνσεις και επίσης κάνει ότι μπορεί όταν ο άλλος δεν εχει καθόλου traffic shaping.

Achille

06/11/2004, 20:01

Δες το αρχικό post που έκανα. Το IMQ το χρησιμοποίησα για να μετράω το ingress και όχι τόσο πολύ για shaping. Αν γίνει μόνο egress και στις δύο πλευρές τότε δεν θα μπορεί η μία πλευρά να ξέρει το διαθέσιμο bandwidth που έχει γιατί αυτό εξαρτάται και από την άλλη. Θα το χωρίσεις 2,5 και 2,5mbits;

Όχι, θα το μετράς, αλλά δεν θα το πειράζεις. Θα έχεις και μια παραπανίσια ουρά που θα το ρίχνεις και αυτό, χωρίς να του βάζεις limits (τα limits θα τα βάζει ο απέναντι).

Αν πας να το κάνεις shape εκτός tcp, θα έχεις λάθος μετρήσεις, επομένως θα πέφτεις στη γνωστή τρύπα.

Το script του AWMN θεωρούσε 5Mbit ανά κατεύθυνση, δεν περιόριζε δηλαδή το bandwidth, αλλά προφανώς όταν το κανάλι ήταν τίγκα, δεν έκανε καλό shaping.

Γι' αυτό και είχαμε περιορίσει τα p2p τόσο χαμηλά, μέχρι να βρούμε λύση που να μετράει και το ingress.

Achille

06/11/2004, 20:02

Αχιλλέα,

για να μη κάθομαι να μαθαίνω iptables και ipchains, αν μπορείς με απλά λόγια να μου εξηγήσεις το set των κανόνων, θα δω τι μπορεί να γίνει και για Cisco

Όταν γυρίσω Αθήνα μέσα στη βδομάδα, θα ασχοληθώ περισσότερο με το ζήτημα, και θα βγάλω και mapping για να το συζητήσουμε.

Acinonyx

06/11/2004, 22:17

Όχι, θα το μετράς, αλλά δεν θα το πειράζεις. Θα έχεις και μια παραπανίσια ουρά που θα το ρίχνεις και αυτό, χωρίς να του βάζεις limits (τα limits θα τα βάζει ο απέναντι).

Αν πας να το κάνεις shape εκτός tcp, θα έχεις λάθος μετρήσεις, επομένως θα πέφτεις στη γνωστή τρύπα.

Το script του AWMN θεωρούσε 5Mbit ανά κατεύθυνση, δεν περιόριζε δηλαδή το bandwidth, αλλά προφανώς όταν το κανάλι ήταν τίγκα, δεν έκανε καλό shaping.

Γι' αυτό και είχαμε περιορίσει τα p2p τόσο χαμηλά, μέχρι να βρούμε λύση που να μετράει και το ingress.

Ωραία μας τα λες Αχιλλέα αλλά μη νομίζεις ότι δεν τα έχω σκεφτεί και εγώ. Προσπάθησε να βγάλεις ένα τέτοιο configuration και θα δεις ότι δεν είναι δυνατόν με τα υπάρχοντα εργαλεία που συζητάμε - τουλάχιστον με HTB δε γίνεται. Για να το μετρήσεις ΧΩΡΙΣ να το πειράζεις πρέπει να κάνεις μία ουρά με εγγυημένο rate όσο το ceiling και όπως είπες κι εσύ πριν, αν το κάνεις αυτό πάει περίπατο το QoS γιατί μετά τι εγγυημένο rate θα ορίσεις στις άλλες ουρές. Εξάλλου όπως είπα και πριν αν κάποιος μου στέλνει τόσο μεγάλη ποόστητα UDP και ICMP τότε υπάρχει πρόβλημα και τι να το κάνω το QoS - ας τα κάνω drop και να μετράω λάθος.

Γι' αυτό και είχαμε περιορίσει τα p2p τόσο χαμηλά, μέχρι να βρούμε λύση που να μετράει και το ingress

Η λύση που πρότεινα δουλεύει. Δουλέυει άψογα αν το έχουν και οι 2 πλευρές. Επίσης δουλεύει άψογα μέχρι την στιγμή που θα με floodάρει κάποιος με ICMP και UDP. Ηδη έχω δοκιμάσει την περίπτωση με τα TCP και πράγματι τα περιορίζει. Η περίπτωση στην οποία δεν θα δουλεύει απόλυτα σωστά είναι ακραία. Πιστεύω ότι μέχρι να βρεθεί η τέλεια λύση που θα αντιμετωπίζει και την παραμικρή ακραία περίπτωση μπορούμε να το χρησιμοποιούμε. Θεωρώ ότι είναι πολύ καλύτερο από το να περιορίζεις το rate τόσο χαμηλά και να κρατάς τόσο μεγάλο μέρος του badnwidth (κάποιες φορές ακόμη και πάνω από το μισό!) αχρησιμοποιήτο όπως γίνεται αυτή τη στιγμή.

Btw, μέτρησα το πόση κίνηση από UDP περνάει από τον κόμβο μου και ήταν λιγότερο από το 4% της συνολικής κίνησης! :evil:

Achille

07/11/2004, 11:19

Για να το μετρήσεις ΧΩΡΙΣ να το πειράζεις πρέπει να κάνεις μία ουρά με εγγυημένο rate όσο το ceiling και όπως είπες κι εσύ πριν, αν το κάνεις αυτό πάει περίπατο το QoS γιατί μετά τι εγγυημένο rate θα ορίσεις στις άλλες ουρές. Εξάλλου όπως είπα και πριν αν κάποιος μου στέλνει τόσο μεγάλη ποόστητα UDP και ICMP τότε υπάρχει πρόβλημα και τι να το κάνω το QoS - ας τα κάνω drop και να μετράω λάθος.

Ένα παράδειγμα για να καταλάβεις ότι σε μερικές περιπτώσεις είναι καλύτερη λύση να έχεις rate=ceil στα incoming, παρά να προσπαθείς να τα κάνεις shape.

Έχουμε link με speed 5Mbit. Έστω ότι έχει incoming udp traffic 3Mbit, δηλαδή περισσεύουν 2Mbit για τις υπόλοιπες υπηρεσίες.

Έστω τώρα ότι τα outgoing rules σου λένε το εξής: 1Mbit εγγυημένο για τα outgoing UDP. 256kbit εγγυημένο HTTP traffic, με ceil 5Mbit.

Αν προσπαθήσεις να κάνεις shape το incoming udp στο 1Mbit, θα νομίζεις ότι έχεις 4Μbit ελεύθερα, με αποτέλεσμα να προσπαθήσεις να στείλεις 1Mbit UDP + 3Mbit HTTP. Θα κάνεις overflow το κανάλι (3incoming + 1 udp outgoing + 3 HTTP outgoing = 7) επομένως οι εγγυήσεις σου πάνε περίπατο, ακόμα και στα outgoing UDP που σε καίνε.

Αν τώρα θεωρείς ότι αφού τα incoming UDP δεν τα ελέγχω, άρα τα θεωρώ το ύψιστο εγγυημένο traffic, θα θεωρήσεις ότι το κανάλι σου έχει ελεύθερο bandwidth 2Mbit, και θα κάνεις shape προς τα κάτω τα HTTP στο 1Mbit, και το 1Mbit outgoing UDP θα περάσει εγγυημένα, δηλαδή θα έχεις επιτύχει το στόχο σου.

Το πρόβλημα με αυτή τη λογική είναι ότι αν ο άλλος ανεβάσει το incoming UDP rate στα 5Mbit πχ, εσύ θα σταματήσεις να στέλνεις οτιδήποτε. Άρα πρέπει να ορίσεις ένα άνω όριο, πάνω από το οποίο θα σταματάς να θεωρείς ότι έχεις δυνατότητες να κάνεις QoS, και να το γυρίζεις στο όποιον πάρει ο χάρος (να έχεις πχ τα incoming UDP μαζί με το 2nd class outgoing traffic σου).

Το θέμα είναι που θα είναι αυτό το όριο, ώστε να μπορέσεις να εκμεταλλευτείς όσο μπορείς περισσότερο την πρώτη περίπτωση.

Όλα αυτά βέβαια είναι θεωρίες, η καλύτερη λύση είναι ο απέναντι να περιορίζει τουλάχιστον τα UDP-ICMP σε κάποιο λογικό όριο, το οποίο εσύ να γνωρίζεις, ώστε εσύ να μην χρειάζεται να χαλάσεις ποτέ το QoS σου.

Θεωρώ ότι είναι πολύ καλύτερο από το να περιορίζεις το rate τόσο χαμηλά και να κρατάς τόσο μεγάλο μέρος του badnwidth (κάποιες φορές ακόμη και πάνω από το μισό!) αχρησιμοποιήτο όπως γίνεται αυτή τη στιγμή.

Δεν διαφωνώ καθόλου. Απλά σου εξήγησα το σκεπτικό της τότε ρύθμισης. Δεν υποστήριξα ότι είναι καλύτερη από τη λύση που προτείνεις τώρα.

Btw, μέτρησα το πόση κίνηση από UDP περνάει από τον κόμβο μου και ήταν λιγότερο από το 4% της συνολικής κίνησης! :evil:

Αυτό θα αλλάξει πολύ σύντομα. Υπολογίζουμε να αυξηθεί η κίνηση σε openvpn tunnels, και όταν μπει και multicasting και αρχίσουν τα broadcasts, θα αρχίσουμε να έχουμε τέτοια προβλήματα.

Καλό είναι λοιπόν να αρχίσουμε να το συζητάμε, ασχέτως του ποια λύση τελικά θα εφαρμόσουμε προσωρινά.