Το μυστηριο με τo square spiked latency της Forthnet στο ΑΙΧ

[psyxakias]

Off Topic

Ας μην το κάνουμε εντελώς sci-fi, φτάνουν οι θεωρίες συνωμοσίας του MNP-10 και εμένα. Γιατί σε λίγο μας βλέπω να λέμε ότι πρόκειται για επίθεση UFO από UFP (Unidentified Flying Protocol) και θα μας βγάλει ο Χαρδαβέλλας 1ο θέμα

[karavagos]

Μπορεί η αύξηση να μην είναι 0=>400 σε 1", αλλά μπορούμε να συζητάμε για "σταδιακή"; Τα σημεία που έχω κάνει bold, δείχνουν αύξηση 18.1 ms/sec (199 ms / 11s) και μείωση 29.25 ms/sec (234 ms / 8s). Το Π που αναφέρει o MNP-10 ισχύει.

Εγώ πάντως αυτό που είπα από την αρχή είναι το ότι δεν ανεβαίνει σε 1", όπως ισχυρίζονταν κάποιοι άλλοι Δεν μίλησα ούτε έφερα κάποια αντίρρηση για το Π, για την "σταδιακή" αύξηση ή για το πως κατεβαίνει.
Και είνα απόλυτα φυσιολογικό (βάση των τεχνικών χαρακτηριστικών των κυκλωμάτων και των πρωτοκόλλων που εμπλέκονται) το ότι ανεβαίνει σε κάποια sec ενώ κατεβαίνει σε πολύ λιγότερα sec.

[psyxakias]

Χ*σε μας με το 1"

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

Επιπλέον, θεωρείς ως πιο ρεαλιστική προσέγγιση του wintech2003 ως τώρα; (αν μάθω ότι άνοιξε "λυσάρι", θα τον μαλώσω!). Όχι τίποτε άλλο, να δώσουμε και κανένα έπαθλο όποιος λύσει το μυστήριο

[MNP-10]

QoS εις βαρος των ICMP, τελικα δεν ειναι. Εχει Π τωρα και δοκιμασα - οι χρονοι ειναι ιδιοι:

linux-qm1n:~/Desktop/AIX proof/script # ping www.forthnet.gr
PING www.forthnet.gr (193.92.150.50) 56(84) bytes of data.
64 bytes from www.forthnet.gr (193.92.150.50): icmp_seq=1 ttl=246 time=412 ms
64 bytes from www.forthnet.gr (193.92.150.50): icmp_seq=2 ttl=246 time=408 ms
64 bytes from www.forthnet.gr (193.92.150.50): icmp_seq=3 ttl=246 time=409 ms
64 bytes from www.forthnet.gr (193.92.150.50): icmp_seq=4 ttl=246 time=411 ms
^C
--- www.forthnet.gr ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3010ms
rtt min/avg/max/mdev = 408.864/410.811/412.700/1.723 ms
linux-qm1n:~/Desktop/AIX proof/script # wine tcping.exe www.forthnet.gr 80

Probing 193.92.150.50:80/tcp - Port is open - time=410ms
Probing 193.92.150.50:80/tcp - Port is open - time=413ms
Probing 193.92.150.50:80/tcp - Port is open - time=405ms
Probing 193.92.150.50:80/tcp - Port is open - time=405ms
^Clinux-qm1n:~/Desktop/AIX proof/script #

[psyxakias]

Off Topic

Το "AIX proof" μ'άρεσε

[MNP-10]

(απο πολυυυυ προηγουμενο ποστ

Διότι δίχως QoS/rate-limits για να φτάσει η συμφόρηση να προκαλεί αύξηση 400 ms (σε μόλις 32-bytes ICMP πακέτα), πρέπει να υπάρχει τρομερή έλλειψη bandwidth, τόση που θα ήταν ελεεινά εκνευριστική όταν θα προσπαθούσαμε να ανοίξουμε την οποιαδήποτε σελίδα μέσω AIX, αφού θα χρειαζόταν ολόκληρα λεπτά ώσπου να φορτώσει όλες τις εικόνες.

Μπορει τελικα να μην υπαρχει τοσο ελλειψη bandwidth για τις εικονες, αλλα το latency επηρεαζει κανονικα το loading. Δοκιμασα το www forthnet.gr και ηταν εκνευριστικα αργο.. πχ ειχε αισθητο blank screen πριν φορτωσει η σελιδα.. μετα το ξανατρεξα με ethereal και τα 400αρια gaps φαινονται κανονικα... .. Εχω βαλει κατι κουκιδιτσες ενδιαμεσα.

Το συνολικο time φορτωσης της σελιδας ηταν >12sec.

[MNP-10]

Off Topic

Το "AIX proof" μ'άρεσε

Off Topic

Κανονικα επρεπε να το βαλω AIX Data, για τα στοιχεια που συλλεγονται, αλλα επειδη κραταω και αλλα Data για το ΑΙΧ (ρεκορ κινησης, αξιοπεριεργες μερες / συμβαντα και αλλα co-relations) το εβαλα "proof" γιατι ειχε πιο πολυ σχεση με το case-building προς τη κατευθυνση του "κατι ειναι αφυσικο εδω περα"

[SfH]

Τώρα που το σκέφτομαι, η θεωρία του wintech δεν είναι ιδιαιτερα δύσκολο να δοκιμαστεί. Θα μπορούσαμε να κάνουμε μερικά transfers και προς τις 2 κατευθύνσεις μεταξύ hosts που είναι σε forthnet και hosts που είναι σε κάποιο άλλο μέλος του aix ανά διαφορα χρονικά διαστήματα και να συγκρίνουμε receive/send όταν έχουμε Π και όταν δεν.

Any volunteers ?

[giannhs1984]

Off Topic

Μπορείς να αναφέρεις λίγο πιο αναλυτικά τι εννοείς με το "attack σε ipv6 με 33syn flood per sec αλλα enacpsulated σε ipv4 απευθειας σε ipv6" και ιδιαίτερα στο bold?

solarflare πιστευω το ξερεις το μικρο αυτο προγραμματακι τι μπορει να κανει (λογικα)
αυτο το προγραμμα ρωσικο φυσικα εγινε για αυτο το λογο στελνει syn flood req σε κλωνους του οπου αυτοι floodαρουν αυτο που εχει θεσπισει ο user του προγραμματος με αποτελεσμα να μην θελει ενα τεραστειο bot net απο το irc αλλα λιγα και οπουδηποτε..
απλα αυτο καταφερε να στελνει 33 πακετα χωρις ack στον στοχο με encapsulation με αποτελεσμα hardware failure (και ναι ειναι επι πληρωμη το προγραμμα..)
(οπως φυσικα τα data μας γινονται encapsulated σε udp ετσι και αυτο το προγραμματακι καταφερε να περασει απο το v4 σε v6 απο software mode )
υποθεσεις κανουμε

[karavagos]

Off Topic

(οπως φυσικα τα data μας γινονται encapsulated σε udp ετσι και αυτο το προγραμματακι καταφερε να περασει απο το v4 σε v6 απο software mode)

Δυστυχώς και πάλι δεν σε καταλαβαίνω.

[giannhs1984]

Off Topic

Δυστυχώς και πάλι δεν σε καταλαβαίνω.

Off Topic

πως να στο πω
βρηκε τροπο να κανει ddos μιας μορφης που δεν θυμαμαι ακριβως το ονομα της η οποια ειναι η χειροτερη στο ipv4 στο να περασει μεσα απο το ipv6 που υποτιθεται οτι την κοβει αυτο κανει
αλλα ετσι και αλλιως ddos attack δεν ειναι αυτο οποτε το ολο σκεπτικο ειναι ανουσιο

[SfH]

Test #1

Δεν είμαστε σε peak του Π . Το test είναι σε συμμετρικό κύκλωμα forthnet, με αρκετά μικρό utilization αυτή τη στιγμή. Το απέναντι κύκλωμα είναι αρκετά μεγάλης χωρητικότητας για να πληρώσει πλήρως το άλλο.

Other ISP -> Forthnet : 244982.72 bytes/sec
Forthnet -> Other ISP : 138390.60 bytes/sec

Να ξεκαθαρίσω ότι η διαφορα τους είναι πολύ μεγαλύτερη από τη διαφορα downstream/upstream του μικρότερου κυκλώματος. Για να δούμε τώρα όταν πετύχουμε Π , αν η διαφορα τους θα είναι μικρότερη.

[SfH]

Test #2

Π @ ~380ms.

Other ISP -> Forthnet : 104126.08 bytes/sec
Forthnet -> Other ISP : 136889.08 bytes/sec

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

[drhouse]

Τα ping δείχνουν ένα μεγάλο latency. Από τις πληροφορίες του ping όμως δεν μπορούμε να βγάλουμε συμπέρσαμα τι latency μπορεί να είναι αυτό;

1) client problem,
2) network latency,
3) forthnet server processor latency ... τι απ' όλα, όλα?

Tο ICMP δεν έχει ούτε TCP ούτε UDP header.
Περιέχουν
1) Ethernet Header
2) IP header
3) ICMP header

Αρα με ping τύπου ICMP το σίγουρο είναι πως το delay δεν μπορεί να αποδοθεί στο forthent server delay.

Οι αιτίες που προκαλούν το delay (από τα δεδομένα του πινγκ) είναι
1) προβλήματα με τα client (το οποίο δεν ισχύει).
2) Congestion στο δίκτυο.
3) congestion στον forthnet server.

Μελετώντας ένα TCP connection μπορεί κανείς εύκολα να έχει μια καλή ένδειξη αν υπάρχει congestion στον server και σε μένα το παρακάτω forthent trace αυτό μου λέει.
Οτι δηλαδή έχουμε όχι μόνο ένα congested network αλλά και ένα congested forthnet server.

Πηρα λοιπόν το wireshark, και το ρύθμισα να δείχνει στην κολώνα time -> Seconds since previous captureed packet και την περίοδο που το ping έδειχνε delay 200-400ms πήγα στην σελίδα της www.forthnet.gr

Διαπίστωσα δε τα εξής:

Πακέτο 7, το client στέλνει [SYN]
Πακέτο 8, ο srv απαντάει με [SYN ACK] delta time 142 ms περίπου.
Τα 142 ms είναι μια πολύ καλή εκτίμηση του round trip latency (wire latency) γιατί σε αυτό το handshake φθάνουμε (στον fortnet srv) μέχρι TCP layer (το μόνο processing που εμπλέκεται ελιναι η δημιουργία sequence numbers).

Πακέτο 9, μόλις το client παραλάβει το [SYN ACK] του forthent srv του απαντάει πολύ γρήγορα (0.000069) με ένα πακέτο [ACK].
Αν σε αυτό το στάδιο είχαμε delays, αυτές θα οφείλοντας αποκλειστικά στο client stack.

Πακέτο 10, το client ζητά ένα αρχείο, από τον forthnet srv, με την εντολή GET
Το delay και σε αυτό το βήμα (134 ms περίπου) είναι το ίδιο περίπου με αυτό του πακέτου 8.
Άν μετά το client ack, το client καθυστερουσε να στείλει το get, θα μιλάγαμε για πρόβλημα στο client.

Πακέτο 11, τα 155 ms σε αυτό το στάδιο είναι πάλι wire delay.

Στα επόμενα βήματα ο forthnet srv θα ανέβει ποίο πάνω από το tcp layer, μέχρι το application layer διότι θα επιχειρήσει να στήλει το αρχείο που του ζητήθηκε με την εντολή GET.

Στο πακέτο 12 ο forthnet srv λεέι στο client ότι ανανεώνει το srv window size,
εδώ σημειώνεται καθηστέριση 159 ms.
Υπ' όψιν ότι ο forthent srv, ακόμα δεν ανέβηκε ποιό πάνω από το tcp layer.
Τέλος στο πακέτο 13, φθάνει σε appication layer ακουμπώντας τα δεδομένα.
Χρειάστηκε όμως ΑΛΛΑ 734 ms DELAY.

Συμπεραίνω τα 159+734 είναι forthnet SERVER PROCESSOR DELAY.

Αν λοιπόν αυτό είναι σωστό, πως να μην δημιουργούνται Πs.

Congested network και congested forthent processor srv και τη κάτσαμε την βάρκα.



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



Lost packets




RTT



Αυτή είναι η δική μου γνώμη.

Τα παρακάτω είναι από διαφορετικό Fortnet trace.
Κι εδώ κατά την ταπεινή μου άποψη τα τράγματα είναι ομαλά εκτός από το Server Processor Congestion.







ΥΓ Είναι τυχαίο ότι σε κάθε http base line analysis o forthnet srv κάνει windows update;
Το ίδιο φαινόμενο εμφανίζεται και στο trace του ΝΜP-10.

[anon]

Νομίζω το πρόβλημα δεν ήταν μόνο στοn forthnet server αλλά σε όλο το δίκτυο της 4NET.