Νέα Φιλαδέλφεια/Νέα Χαλκηδόνα. Μεγάλη πτώση Bandwidth σε 100/10

[billybiros]

Και πάλι ο πάροχος δεν πρέπει να ζητήσει εξτρά κύκλωμα αφού ξέρει οτι έχει τόσους χρήστες; μήπως θα ήταν καλύτερα να είχε Ο.Κ.ΣΥ.Α.
ΦΥΠ-DSLAM-ΤΟΠ με οπτική αν περιμένει να έχει πολλούς χρήστες;

Η διαφορά του ΦΥΠ-DSLAM-ΤΟΠ με το OLO είναι ότι στην μια περίπτωση ο τερματικός εξοπλισμός είναι του ΟΤΕ (OLO) και η σύνδεση γίνεται μέσα στο ΑΚ - ενώ στο (ΦΥΠ) o εξοπλισμός είναι του παροχου και η σύνδεση γίνεται στο ΦΥΠ (Φρεάτιο) έξω από το ΑΚ. Οπότε αυτό που μετράει είναι τι κύκλωμα έχεις αγοράσει από τον Παροχο Πρόσβασης (ΟΤΕ) - προφανώς και είναι θέμα παροχου υπηρεσίας. Δεν νομίζω πως παίζει ρόλο αν είναι ΤΟΠ ή ΦΥΠ.

[netblues]

Αν και εχουμε κανει αρκετες υποθεσεις, ειναι σχεδον σιγουρο οτι η wind στα ΑΚ μεσα στην αθηνα πηγαινει με δικη της ινα και εξοπλισμο ΜΑΝ. Δεν συμφερει να πληρωνει οξιες και βαλανιδιες.. (τι ονομα και αυτο θεε μου, ποιος τα σκεφτεται αυτα..)
Στο μακρυνο παρελθον ειχα αναγκαστει να το ψαξω. (επι εποχης adsl) Εκανε στιγμιαιες διακοπες, για 4-5 sec ειχε request time out στο επομενο hop. Χωρις crc, χωρις fec και χωρις disconnections.
Καποια στιγμη παρατηρησα ακριβως το ιδιο σε αλλη συνδεση/σπιτι στο ιδιο ακ και παροχο (wind)
Με ενα μονιμο ping και μιλωντας στα τηλεφωνα παρατηρησα οτι το request timeout γινοταν και στις δυο συνδεσεις ΤΑΥΤΟΧΡΟΝΑ.
Με λιγο inside info επιβεβαιωσα οτι οι δυο συνδεσεις εξυπηρετουνται απο διαφορετικο dslam (εντος του ιδιου ακ αλλα κοινου backbone...
Εβαλα το ping να τρεχει μονιμα, μαζεψα synced data και απο τις δυο συνδεσεις για μια εβδομαδα, τα εκανα graph και τα εστειλα στο noc σε excelaκι (γιατι ΔΕΝ καταλαβαιναν τι τους ελεγα.)
Συντομα ηρθε feedback οτι ειχα δικιο και τωρα το βλεπουν και αυτοι το θεμα.. (σωωωωπα) και οτι εχει προγραματισθει η αντικατασταση της ινας με δικο τους κυκλωμα.
Περασε κανας μηνας, και μια νυχτα εγινε ενα καλο outage (το ping ετρεχε και τα εβλπα αυτα). Απο την αλλη μερα το πρωι... τελος. νο μορ request timeouts.


Ειμαι εξαιρετικα πιθανο οτι και το vdsl που παιρνουν, εκει το ριχνουν.
Για το ping, διαφορα utilties δεν μου δουλεψαν καλα πχ gping.. σκαει σε βαθος χρονου. Το παλιο κλασσικο mrtg κανει τη δουλεια τελεια. Προφανως και με rrd κλπ θα ειναι ακομα καλυτερα, αλλα πανε πολλα χρονια. Υπαρχει και το smokeping φυσικα
εχουμε και λεμε (under linux of course)
mrtg.cfg

########################  Hol ppp Peer
Target[holvdsl]: `/etc/mrtg/mrtgping.pl loopback2004.med01.dsl.hol.gr`
MaxBytes[holvdsl]: 1250000
Title[holvdsl]: HOL VDSL Latency to vdsl ppp peer
# remember not to define "bits" globally or here as everything will be multiplied by 8...
PageTop[holvdsl]: <H1>VDSL Latency pinging loopback2004.med01.dsl.hol.gr </H1>
Options[holvdsl]: gauge noinfo, nopercent, growright
YLegend[holvdsl]: mS
ShortLegend[holvdsl]: mS
LegendI[holvdsl]:  Avg.:
LegendO[holvdsl]:  Stddev:
Legend1[holvdsl]: Average Round Trip Time in ms
Legend2[holvdsl]: StdDev Round Trip Time in ms

mrtgping.pl

#!/usr/bin/env perl

$ipaddr = "NULL";
$ipaddr = $ARGV[0];
$numpings = 5;
$mrtgpinglog = ">> /var/log/mrtgping.log";

if ($ipaddr eq "NULL"){
        print "Usage mrtgping.pl [ipaddress]\n";
                exit;
                }

                open(MRTGPINGLOG, $mrtgpinglog);

                $date = `date +%Y%m%d%H%M%S`;
                chop ($date);

                $result = `/bin/ping -c $numpings -n -q $ipaddr | /usr/bin/tail -1`;
                chop($result);

                # Ping result will look like... 
                # round-trip min/avg/max/stddev = 18.707/91.234/325.268/118.491 ms

                ($descp1,$descp2,$equal,$data) = split(/ /,$result);

                ($min,$avg,$max,$stddev) = split(/\//,$data);

                ($avgint,$avgdec) = split(/\./,$avg);
                ($stddevint,$stddevdec) = split(/\./,$stddev);

                print MRTGPINGLOG "$date: ";
                print MRTGPINGLOG "$avgint ";
                print MRTGPINGLOG "$stddevint ";
                print MRTGPINGLOG "0 ";
                print MRTGPINGLOG "$ipaddr\n";

                print "$avgint\n";
                print "$stddevint\n";
                print "0\n";
                print "$ipaddr\n";

Θα παρεις αυτο.. Οταν υπαρχει το προβλημα θα δεις πανω απο 40-50msec (μονο το κατεβασμα ενοχλει, η νορμαλ χρηση δεν πειραζει)




Στο ετησιο φαινονται διαφορα....



αρχες αυγουστου μπηκε vectoring και γυρισε σε interleave. Δεν το πηρα χαμπαρι αμεσως.
Αρχες σεπτεμβριου αρχισε το θεματακι με το μπουκωμα του dslam (και η γκρινια) το πραγμα χειροτερεψε το σεπτεμβρη και εγινε ενοχλητικο τον οκτωβρη οπου και λυθηκε μαχαιρι, στα μεσα οκτωβρη, μετα απο ενα σχεδον ολονυκτιο outage.
Μετα ειναι απλα traffic (στο μηνιαιο graph αυτα ειναι ξεκαθαρα).



Καλη τυχη.

[billybiros]

Αν και εχουμε κανει αρκετες υποθεσεις, ειναι σχεδον σιγουρο οτι η wind στα ΑΚ μεσα στην αθηνα πηγαινει με δικη της ινα και εξοπλισμο ΜΑΝ. Δεν συμφερει να πληρωνει οξιες και βαλανιδιες.. (τι ονομα και αυτο θεε μου, ποιος τα σκεφτεται αυτα..)

Από τη στιγμή που κάποιος παροχος συγχρονίζει σε DSLAM άλλου παροχου, θα πρέπει να βρεθεί κάποιος τρόπος να πάρει την κίνηση στα δικά του κυκλώματα.
Αυτός ο τρόπος ονομάζεται Ο.Κ.Συ (Ολοκληρωμένη Κεντρική Σύνδεση) ή Ο.Κ.Συ.Α (Ολοκληρωμένη Κεντρική Σύνδεση ADSL).
O OTE το ονομάζει ΟΚΣυΑ (και είναι απαραίτητο σε συνδέσεις VPU και VPU Light) ενώ οι εναλλακτικοί το ονομάζουν ΟΚΣυ και είναι απαραίτητο σε συνδέσεις Wholesale-NGA.
Επι της ουσίας τα δυο παραπάνω είναι το ίδιο.

Η αγορά κυκλώματος Ο.Κ.Συ/Ο.Κ.Συ.Α είναι απαραίτητη.

Υπάρχουν 3 τύποι Ο.Κ.Συ.Α
O A και ο Β επι της ουσίας είναι ο ίδιος.



Στον Α και Β όλη η κίνηση από όλα τα DSLAM παιρναει από τους BRAS του ΟΤΕ και συγκεντρώνεται σε ένα κεντρικό Switch.
ΟΚΣυΑ είναι το κύκλωμα απο το Swith του ΟΤΕ μέχρι τον παροχο.
Η διάφορα του Α με το Β είναι ότι στο Α ο ΟΤΕ εγκαθιστά ο ίδιος τον τερματικό εξοπλισμό ΝΤΕ ενώ στο Β παραδίδει μέχρι το ΦΥΠ (Φρεάτιο Υποδοχής Παροχου).
Σε περίπτωση που υπάρχει μπούκωμα σε κύκλωμα τύπου Α ή Β θα έχουν πρόβλημα όλοι οι συνδρομητές που παίρνουν από το ΟΚΣυΑ - δηλαδή από όλα τα ΑΚ της ευρύτερης περιοχής.
Το Α και Β στην ουσία είναι το παλιό κύκλωμα ΑΡυΣ (και είναι λογικό να μην επαρκεί το bandwith μιας και μιλάμε για μια υπηρεσία που φτιάχτηκε για το παλιό ΑΡυΣ).
Σε Α και Β δεν μπορεί επίσης να δουλέψει VPU-Light.

Στο ΟΚΣυΑ Γ ο ΟΤΕ παιρναει όλη την κίνηση στο ΑΚ και από το ΑΚ την δίνει στον παροχο.
ΟΚΣυΑ Γ είναι το κύκλωμα του ΟΤΕ απο το ODF στο ΑΚ προς τον παροχο.
Η σύνδεση του παροχου από το ΑΚ στα Aggregation Routers του παραμένει η ίδια όπως στην περίπτωση του απλού FLLU.
Σε περίπτωση VPU-Light ο τύπος είναι υποχρεωτικά Γ.



Υπάρχουν 2 τρόποι παράδοσης σε ΟΚΣυΑ Γ'.
1) OLO-DSLAM-ΤΟΠΙΚΟ
2) ΦΥΠ-DSLAM-ΤΟΠΙΚΟ
Στο OLO ο ΟΤΕ εγκαθιστά στο ODF στην αίθουσα παροχων δικό του τερματικό εξοπλισμό ενώ
στο ΦΥΠ παραδίδει το κύκλωμα σε Φρεάτιο έξω απο το ΑΚ.
Επί της ουσίας στις δυο παραπάνω περιπτώσεις (OLO και ΦΥΠ) αυτό που μετράει είναι τι κύκλωμα έχεις αγοράσει από τον ΟΤΕ
(ποσά giga έχεις αγοράσει) και όχι αν στο παραδίδει μέσα ή έξω από το ΑΚ.
Τον εναλλακτικό τον βολεύει παράδοση μέσα στο ΑΚ εφόσον υπάρχει Φυσική Συνεγκατασταση.
Σε περίπτωση μπουκώματος στο ΟΚΣυΑ Γ' θα έχουν πρόβλημα μόνο οι συνδρομητές του εναλλακτικού που παίρνουν από συγκεκριμένο ΑΚ.

[silverblue]

Οι τοπολογίες στις παραπάνω εικόνες ισχύουν μόνο στην περίπτωση που οι καμπίνες είναι του ΟΤΕ ή γενικά; Μιλάω για το κομμάτι της μεταφοράς της κίνησης από τον έναν πάροχο στον άλλον.

[billybiros]

Οι τοπολογίες στις παραπάνω εικόνες ισχύουν μόνο στην περίπτωση που οι καμπίνες είναι του ΟΤΕ ή γενικά; Μιλάω για το κομμάτι της μεταφοράς της κίνησης από τον έναν πάροχο στον άλλον.

Καμπίνα ΟΤΕ, VPU και Φυσική Συνεγκατασταση.
Σε απομακρυσμένη παραδίδει σε Φρεάτιο και σε Rural ισχύουν αυτα

[silverblue]

Στην περίπτωση που έχουμε το αντίστροφο από την περίπτωση του OP, δηλαδή εάν έχουμε Πάροχο Υπηρεσίας ΟΤΕ από π.χ. καμπίνα Vodafone, τότε η μεταφορά της κίνησης στους BRAS του ΟΤΕ γίνεται ανά Α/Κ ή πιο κεντρικά;

[billybiros]

Στην περίπτωση που έχουμε το αντίστροφο από την περίπτωση του OP, δηλαδή εάν έχουμε Πάροχο Υπηρεσίας ΟΤΕ από π.χ. καμπίνα Vodafone, τότε η μεταφορά της κίνησης στους BRAS του ΟΤΕ γίνεται ανά Α/Κ ή πιο κεντρικά;

Σε περίπτωση εναλλακτικού το κύκλωμα επιστρέφει από τον παροχο πρόσβασης (αυτόν που έχει την καμπίνα) στο ΑΚ.
Το ΟΚΣυ είναι από το ΑΚ στο ΦΥΠ έξω από το ΑΚ (στην προσφορά αναφοράς για το wholesale-nga αναφέρει ότι παραδίδεται σε ΦΥΠ).
Τώρα πως ακριβώς το υλοποιούν οι παροχοι μεταξυ τους δεν το γνωρίζω (έχω την αίσθηση ότι από την στιγμή που υπάρχει κύκλωμα πχ εναλλακτικού με τον ΟΤΕ χρησιμοποιούν το ίδιο).
Υπάρχουν δηλαδή κέντρα που έχει nga και ο ΟΤΕ και ο εναλλακτικός (εκεί θεωρώ λογικό ότι από την στιγμή που υπάρχει κύκλωμα - χρησιμοποιούν το ίδιο).

[silverblue]

Σε ευχαριστώ πολύ για τις πληροφορίες. Και γω φαντάστηκα ότι η διασύνδεση των παρόχων θα γίνεται μέσα στο Α/Κ, αλλά στη δική μου περίπτωση διαπίστωσα ότι πριν που έπαιρνα ΟΤΕ VDSL από Α/Κ και μετά όταν συνδέθηκα σε καμπίνα VF (πάλι ΠΥ ΟΤΕ), άλλαξα δρομολόγηση (άλλο bras, core links κλπ) και σκέφτηκα ότι λογικά δεν γίνεται η διασύνδεση στο Α/Κ μου αλλά κάπου αλλού.

[BlueChris]

Πολύ ενδιαφέροντα όλα αυτά, ευχαριστώ για τις πληροφορίες παιδιά.

[netblues]

Σε περίπτωση VPU-Light ο τύπος είναι υποχρεωτικά Γ.


Υπάρχουν 2 τρόποι παράδοσης σε ΟΚΣυΑ Γ'.
1) OLO-DSLAM-ΤΟΠΙΚΟ
2) ΦΥΠ-DSLAM-ΤΟΠΙΚΟ
Στο OLO ο ΟΤΕ εγκαθιστά στο ODF στην αίθουσα παροχων δικό του τερματικό εξοπλισμό ενώ
στο ΦΥΠ παραδίδει το κύκλωμα σε Φρεάτιο έξω απο το ΑΚ.
Επί της ουσίας στις δυο παραπάνω περιπτώσεις (OLO και ΦΥΠ) αυτό που μετράει είναι τι κύκλωμα έχεις αγοράσει από τον ΟΤΕ
(ποσά giga έχεις αγοράσει) και όχι αν στο παραδίδει μέσα ή έξω από το ΑΚ.
Τον εναλλακτικό τον βολεύει παράδοση μέσα στο ΑΚ εφόσον υπάρχει Φυσική Συνεγκατασταση.
Σε περίπτωση μπουκώματος στο ΟΚΣυΑ Γ' θα έχουν πρόβλημα μόνο οι συνδρομητές του εναλλακτικού που παίρνουν από συγκεκριμένο ΑΚ.

Ανακεφαλαιοντοντας και αφαιροντας τα "οτεδιστικα" σε περιοχες των μεγαλων αστικων κεντρων οπου εχουν εγκατασταθει καμπινες με dslam και οι παροχοι ειχαν ηδη συνεγκατασταση εντος του κεντρου
η κινηση παραλαμβανεται απο τον εκαστοτε παροχο εντος του κτιριου (και στη πραξη με πολλαπλα gigabit ethernet). Αυτη ειναι η συνηθεστερη περιπτωση.
Δεν εχω ακουσει να υπαρχουν 10G πορτες και ουτε να παιζει bonding πολλων 1g lan σε 1 virtual.
κραταμε οτι αυτο το πηξιμο ειναι ανα παροχο/gigabot interface, κοστιζει επιπλεον λεφτα και χρειαζεται χρονο η αναβαθμιση του.

[BlueChris]

Λοιπόν το έφτιαξαν χτες και με πήραν τηλ. Η γραμμή επανήλθε στα κανονικά της και ίσως και καλύτερα ... θα το παρακολουθήσω κάποιες μέρες να δω αλλά νομίζω είμαι ΟΚ.

thx όλους για τη βοήθεια.

[ΤΕΧΝΗΛΕΚΤΡ37Β]

Καλησπέρα, υπάρχει περίπτωση μετά το DSLAM της καμπίνας του ΟΤΕ το τραφικ να δρομολογείται στο ΑΚ, μετά στο BBRAS του ΟΤΕ και μετά με ΟΚΣΥΑ στον πάροχο;Σε έκπτωση που δεν έχει σύνδεση ο πάροχος με το συγκεκριμένο ΑΚ;

Επίσης αυτή η διάταξη που οι καμπίνες του ΟΤΕ συνδέονται κατευθείαν στο δίκτυο του και δε περνάνε από το ΑΚ, είναι συχνή;Νόμιζα πως όλες οι καμπίνες VDSL του ΟΤΕ είναι συνδεδεμένες με το ΑΚ

Κάθε ΑΚ έχει φρεάτιο υποδοχής παρόχου ;Κάθε εταιρίας;

[BlueChris]

Καλησπέρα, υπάρχει περίπτωση μετά το DSLAM της καμπίνας του ΟΤΕ το τραφικ να δρομολογείται στο ΑΚ, μετά στο BBRAS του ΟΤΕ και μετά με ΟΚΣΥΑ στον πάροχο;Σε έκπτωση που δεν έχει σύνδεση ο πάροχος με το συγκεκριμένο ΑΚ;

Επίσης αυτή η διάταξη που οι καμπίνες του ΟΤΕ συνδέονται κατευθείαν στο δίκτυο του και δε περνάνε από το ΑΚ, είναι συχνή;Νόμιζα πως όλες οι καμπίνες VDSL του ΟΤΕ είναι συνδεδεμένες με το ΑΚ

Κάθε ΑΚ έχει φρεάτιο υποδοχής παρόχου ;Κάθε εταιρίας;

Δεν το ξέρω αυτό να σου απαντήσω .. αλλά αν γινόταν αυτό τότε δεν θα είχες IP από τον OTE? και όχι από τον άλλο πάροχο?