Banda Roubaix-Milano
Originariamente Scritto da
technofab
Secondo me la cosa è molto facile se avete X siti, mettiamo 3, Sede A, B e C; l'interfaccia dei ticket deve essere sempre al di fuori di dove possono accadere questo tipo di problemi. Non dovete spostarla dopo che il problema si è evidenziato, ma prevenire facendolo prima; anche perchè è un ovvietà tecnica. Se qualcuno dei miei tecnici avesse fatto un errore simile si sarebbe già preso un richiamo formale, data l'errore grossolano e da dilettante.
Il mio messaggio :
Stiamo spostando l'interfaccia di gestione su un'infrastruttura separata totalmente dalla rete per evitare che possa subire rallentamenti ed essere quindi consultabile in qualsiasi momento.
In altre parole stiamo perfezionando l'interfaccia pubblica degli incidenti :
http://status.ovh.it/
L'obiettivo è renderla il più indipendente possibile da possibili interruzioni senza penalizzare la sua raggiungibilità ed il suo livello di protezione globali.
@Technofab: Non hai capito ed ecco qui la tua consueta valutazione errata e provocatoria della discussione.
Parliamo di perfezionare/migliorare un servizio non di un errore.
technofab
21.02.2013, 18.17
Originariamente Scritto da
torpado
La vera questione risiede nel determinare il livello corretto dove applicare questa divisione, la divisione esiste da sempre.
Il livello corretto cambia con l'evolversi dell'infrastruttura
Secondo me la cosa è molto facile se avete X siti, mettiamo 3, Sede A, B e C; l'interfaccia dei ticket deve essere sempre al di fuori di dove possono accadere questo tipo di problemi. Non dovete spostarla dopo che il problema si è evidenziato, ma prevenire facendolo prima; anche perchè è un ovvietà tecnica. Se qualcuno dei miei tecnici avesse fatto un errore simile si sarebbe già preso un richiamo formale, data l'errore grossolano e da dilettante.
Originariamente Scritto da
technofab
Pensarci prima no eh?
E' mai possibile che una azienda come OVH che per lavoro fornisce servizi su datacenter, non possa capire prima che è necessario dividere le 2 cose?
La vera questione risiede nel determinare il livello corretto dove applicare questa divisione, la divisione esiste da sempre.
Il livello corretto cambia con l'evolversi dell'infrastruttura
Originariamente Scritto da
EvolutionCrazy
il problema è che non sapendo come vengono gestiti i rimborsi per il non rispetto dello SLA penso fosse utile aprire un ticket per ogni server in modo da datare precisamente il problema e le risposte... :/
oppure sono cose che avvengono automaticamente?
Certo hai fatto molto bene a segnalare per sicurezza i dettagli in un ticket, ma la mia risposta fa riferimento unicamente a quanto da te riportato qui sul forum :
mi hanno risposto ora al ticket incidente segnalandomi che la connettività è stata ripristinata :|
Visto il tuo messaggio ho ritenuto necessario sottolineare la necessità di seguire l'interfaccia pubblica di gestione incidenti per sapere l'evoluzione dello stato di riparazione e rientro alla normalità operativa
technofab
21.02.2013, 13.29
Originariamente Scritto da
torpado
L'interfaccia pubblica di gestione degli incidenti è stata creata appositamente per non gestire le singole richieste in casi come questi dove l'intera rete è coinvolta.
Stiamo spostando l'interfaccia di gestione su un'infrastruttura separata totalmente dalla rete per evitare che possa subire rallentamenti ed essere quindi consultabile in qualsiasi momento.
Pensarci prima no eh?
E' mai possibile che una azienda come OVH che per lavoro fornisce servizi su datacenter, non possa capire prima che è necessario dividere le 2 cose?
EvolutionCrazy
21.02.2013, 13.08
il problema è che non sapendo come vengono gestiti i rimborsi per il non rispetto dello SLA penso fosse utile aprire un ticket per ogni server in modo da datare precisamente il problema e le risposte... :/
oppure sono cose che avvengono automaticamente?
Originariamente Scritto da
EvolutionCrazy
mi hanno risposto ora al ticket incidente segnalandomi che la connettività è stata ripristinata :|
L'interfaccia pubblica di gestione degli incidenti è stata creata appositamente per non gestire le singole richieste in casi come questi dove l'intera rete è coinvolta.
Stiamo spostando l'interfaccia di gestione su un'infrastruttura separata totalmente dalla rete per evitare che possa subire rallentamenti ed essere quindi consultabile in qualsiasi momento.
EvolutionCrazy
21.02.2013, 12.44
mi hanno risposto ora al ticket incidente segnalandomi che la connettività è stata ripristinata :|
Originariamente Scritto da
yak983
attendiamo notizie dallo STAFF!
Non appena abbiamo una soluzione ufficiale in merito all'incidente :
http://status.ovh.it/?do=details&id=4165
provvederemo a comunicarla.
attendiamo notizie dallo STAFF!
EvolutionCrazy
21.02.2013, 10.39
ora attendiamo i rimborsi :O
saranno fatti in automatico a tutti quelli che hanno sforato lo sla garantito 99.90 / 99.95? :O
Comment by OVH - Thursday, 21 February 2013, 07:20AM
The connection was restored.
http://status.ovh.net/?do=details&id=4165
technofab
21.02.2013, 00.30
Sono in buona compagnia vedo... OVH ha niente da dire? Non riesco quasi ad aprire un ticket.
si spera in tragitti diversi almeno per il 50% di fibre da un pop all'altro ..
sicuramente c'è da rivedere un po' la politica della ridondanza della rete in casi di failure con l'aggiunta magari di ulteriori link di backup con una buona capienza di banda e non trovarsi a fare 4k/s
EvolutionCrazy
20.02.2013, 22.27
aspetta quando è tutto 100g..... un fibercut da 100g ed è da mettersi a piangere
per un fibercut ridursi così... ma non dovrebbe essere tutto N +1 con scavi separati per ovviare a questi problemi?
un gran autogol all'immagine! (altro che giannino)
EvolutionCrazy
20.02.2013, 21.40
si infatti... volevo proprio capire se mi dicono "controlli di avere le scarpe ben allacciate, e chiuda le finestre prima di lanciare lo speedtest"... vedremo...
http://proof.ovh.net/
http://i.imgur.com/fC3QWQx.png
... so gia' cosa ti diranno:
entri in modalita' rescue e controlli se la macchina ha problemi di hard-disk
EvolutionCrazy
20.02.2013, 20.59
manco si carica il manager per aprire un ticket incidente!
situazione scandalosa!
EvolutionCrazy
20.02.2013, 20.47
tutta oggi che non funziona un cavolo nemmeno qui...
da tutta europa ricevo errori di connessioen random verso OVH
//edit dopo 20 minuti di tentativi sono riuscito ad aprire ticket incidente... vediamo cosa dicono...
comunque mai stato così scarico milano:
http://i.imgur.com/EQC4TTU.png
0% verso seabone
Ciao a tutti.
La situazione e' drammatica, non raggiungo nessuna delle mie macchine.
Qualcuno ha notizie su quello che sta succedendo?
Cordialitè
viking2010
10.02.2013, 15.55
Come mai si esce ancora da Seabone a francoforte e non a Milano?!?!?!?!
Codice:
traceroute to (82.54.xxx.xxx), 30 hops max, 60 byte packets
1 rbx-14-m2.fr.eu (91.121.27.252) 0.671 ms 0.984 ms 1.151 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 4.084 ms * *
3 rbx-g1-a9.fr.eu (213.186.32.233) 0.835 ms 0.820 ms 0.847 ms
4 * fra-1-6k.de.eu (178.33.100.249) 7.877 ms *
5 * * *
6 seabone.as6762.fr.eu (91.121.131.18) 92.288 ms 86.976 ms 92.181 ms
viking2010
06.02.2013, 21.13
Banda altalenante anche stasera...
verrà mai sistemata sta situazione?! mah...
viking2010
21.01.2013, 16.17
Ho notato che ora da
OVH-->Telecom Italia (provincia di Treviso) esco dalla rete OVH da Francoforte:
Codice:
traceroute to 87.0.xxx.xxx, 30 hops max, 60 byte packets
1 rbx-14-m2.fr.eu (91.121.27.252) 1.175 ms 1.817 ms 2.125 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 12.766 ms * *
3 rbx-g1-a9.fr.eu (213.186.32.233) 1.416 ms 1.440 ms 1.459 ms
4 fra-1-6k.de.eu (91.121.131.198) 8.026 ms * *
5 seabone.as6762.de.eu (94.23.122.158) 8.252 ms 8.552 ms 8.620 ms
Mentre da
OVH-->AscoTlc (Provincia di Treviso) esco da OVH da Londra:
Codice:
traceroute to 80.86.xxx.xxx, 30 hops max, 60 byte packets
1 rbx-14-m2.fr.eu (91.121.27.252) 15.037 ms 15.352 ms 15.630 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.662 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.10) 1.137 ms 1.364 ms 1.409 ms
4 ldn-5-6k.uk.eu (91.121.131.178) 4.209 ms ldn-5-6k.uk.eu (91.121.128.166) 4.230 ms ldn-5-6k.uk.eu (91.121.128.192) 4.244 ms
5 Gi3-0.lonth-inter-1.interoute.net (195.66.224.53) 4.311 ms 4.308 ms 4.296 ms
6 ae1-0.par-gar-score-1-re0.interoute.net (212.23.42.21) 26.998 ms 26.845 ms 26.942 ms
7 ae1-0.mil-cal-score-2-re0.interoute.net (89.202.146.93) 27.108 ms 27.017 ms 26.886 ms
8 ae0-0.mil-cal-score-1-re1.interoute.net (89.202.146.85) 24.256 ms 24.196 ms 24.118 ms
9 Gi10-0.vce-val-access-1.interoute.net (217.118.118.150) 27.934 ms 27.958 ms 196.868 ms
10 gi-0-0-3.bgr-svend01-02.ascotlc.net (89.202.198.141) 28.699 ms 28.666 ms 28.650 ms
11 gi-0-0-2.bgr-svend01-01.ascotlc.net (188.125.113.34) 28.673 ms 28.719 ms 28.712 ms
12 gi-0-0-3.bgr-casie01-01.ascotlc.net (188.125.113.50) 29.288 ms 29.326 ms 29.319 ms
13 ge-1-0-0-vi-973.pop-casie01-02.ascotlc.net (188.125.113.70) 28.479 ms 28.428 ms 28.499 ms
Che logica usano per fare il routing?!
EvolutionCrazy
20.01.2013, 19.45
EvolutionCrazy
20.01.2013, 18.24
EvolutionCrazy
20.01.2013, 18.12
Questa immagine penso parli da sola:
http://i.imgur.com/V61gpYa.png
(il download da ovh è ancora qua che va a 140KB/sec...)
Codice:
traceroute to proof.ovh.net (188.165.12.106), 30 hops max, 60 byte packets
1 xxxxxx 2.633 ms * *
2 cr1-ge-1-0-1-0-cal4.mil.kpnqwest.it (94.141.0.113) 0.214 ms 0.217 ms 0.213 ms
3 * * *
4 * ovh.mix-it.net (217.29.66.67) 0.415 ms *
5 * * *
6 * * *
7 rbx-s3-6k.fr.eu (213.186.32.142) 68.693 ms rbx-s3-6k.fr.eu (213.186.32.164) 68.791 ms *
8 * *^C
Personalmente i 100 mbps non li posso testare dato che i server che abbiamo son tutti in OVH, non vado oltre i 14 mbps di un'adsl2 Interbusiness... in ogni caso con quella non vado oltre i 700-800 kb/sec in download dai nostri server, ciò significa comunque che la banda è in qualche modo ristretta a causa sicuramente dell'elevato carico della tratta Fra-Mil.
Proviamo ad aprire qualche ticket tecnico e sentiamo cosa dicono. OVH Italia son davvero molto gentili e corretti nel rispondere!
EvolutionCrazy
20.01.2013, 17.45
beh... non credo ci sia molto da decidere o sperare...
o forse attendono che iniziamo tutti ad aprire ticket dicendo che il server non funziona perché non si riescono a raggiungere i 100mbit garantiti? mmm
qualcuno riesce a farli sti 100mbit verso l'italia?
Originariamente Scritto da
EvolutionCrazy
sbg verso milano credo non abbia ancora nulla... tutto passa comunque per altri pop (francoforte?)
SBG e RBX passano entrambi da Frankfurt e più precisamente "oscillano" (presumo a seconda del carico) su fra-1-6k e fra-5-6k.
Infatti un traceroute verso i nostri server a RBX4 passano da fra-5-6k e lo stesso vale per i server che abbiamo in SBG, passano sempre da fra-5-6k.
L'unica eccezione è che il traceroute verso SBG passa da mil-5-6k mentre per RBX il passaggio di mil-5-6k viene saltato e va diretto a fra-5-6k ma in ogni caso, se si vede la weathermap anche fra-5-6k è saturo (94-97% di occupazione verso l'Italia!).
Il problema che non raggiungiamo velocità elevate in download dai nostri server è proprio legato alla saturazione del link Frankfurt-Milan che trasporta tutto il traffico dei server OVH verso l'Italia.
Speriamo decidano di ampliare la banda perchè di questo passo non si va molto avanti....
EvolutionCrazy
20.01.2013, 17.10
sbg verso milano credo non abbia ancora nulla... tutto passa comunque per altri pop (francoforte?)
il problema non è il motivo (saturazione?) ma il risultato (servers non vanno veloci quanto garantito)
sulle schede dei prodotti è scritto:
Banda passante garantita 100 Mbps
non riesco però a superare nemmeno i 20mbit verso servers con connettività gbit kpnqwest italia...
i 100mbit garantiti verso chi e cosa sono garantiti?
In effetti la banda di Milano è decisamente satura... mi chiedo cosa aspettano a mettere in cantiene di aumentarla!
Tra l'altro sarebbe il caso di cambiare il titolo del Topic più genericamente banda OVH-Milano poichè anche verso SBG è la stessa situazione...
Alohaa...
EvolutionCrazy
20.01.2013, 14.38
grossi problemi di banda RBX -> Milano
weathermap rossa fissa...
http://weathermap.ovh.net/milan
http://i.imgur.com/eSsJCsJ.png
che succede?
ora con tutte queste nuove politiche dei 200mbit etc non doveva migliorare la situazione?!?!
PS: propongo di spostare i grafici di milano su
sweathermap.ovh.net anzichè weathermap.ovh.net ... mi sembra un nome pià azzeccato vedendo i colori e ipotizzando il carico dei router
EvolutionCrazy
06.01.2013, 05.06
rbx3
banda ok senza problemi (come gli altri che ho)... niente rbx4... boh...
technofab
04.01.2013, 09.18
Originariamente Scritto da
EvolutionCrazy
dici?
sto attendendo (da ieri notte... alla faccia dell'1h disponibilità ... ) l'attivazione di una nuova macchina (SP 32G SSD - ordine 17648129)... vediamo se finisce in rbx4 ... essendo hw nuovo rispetto ai vecchi presumo (temo?) finirà in uno dei dc nuovi...
Sei stato attivato? Che hai vinto?
viking2010
03.01.2013, 16.01
Originariamente Scritto da
EvolutionCrazy
Baia: 05B04
Sono su Roubaix 1
http://travaux.ovh.net/vms/index_rbx.html
EvolutionCrazy
03.01.2013, 14.53
basta la baia
viking2010
03.01.2013, 13.51
Originariamente Scritto da
EvolutionCrazy
questo file lo scarichi a banda piena:
http://proof.ovh.net/files/1Gio.dat
o va lento come dal tuo server?
per vedere in che DC sei devi entrare nel cp nella pagina di riepilo info e scrivere qui in che rack ti trovi
Ma lento uguale...
Vuoi la baia o anche il numero?
EvolutionCrazy
02.01.2013, 21.22
questo file lo scarichi a banda piena:
http://proof.ovh.net/files/1Gio.dat
o va lento come dal tuo server?
per vedere in che DC sei devi entrare nel cp nella pagina di riepilo info e scrivere qui in che rack ti trovi
viking2010
02.01.2013, 21.10
Ho controllato l'ip del mio server, e dell'attuale mio ip Telecom nella lista
http://abuse.ovh.net/index.php?action=blockedByASN ma non risultano blocchi.
Sinceramente è da un pò di settimane che ho notato rallentamenti nel download da OVH-->Telecom. Per esempio ora vado tra i 800kb/s e i 500kb/s. Altre rare volte sono + fortunato e vado a banda piena, ossia 1,2mb/s. Che succede?
Le possibili motivazioni che mi vengono in mente sono:
- Problema di banda OVH
- Problema di routing con Telecom
- Policy sul traffico
Come posso vedere in che RBX sono?
Telecom-->OVH
Codice:
9 70 ms * 64 ms mil-1-6k.it.eu [91.121.131.25]
10 * * * Richiesta scaduta.
11 51 ms 51 ms 52 ms rbx-g1-a9.fr.eu [91.121.131.205]
12 218 ms 256 ms * rbx-1-6k.fr.eu [94.23.122.105]
13 50 ms 53 ms 68 ms rbx-14-m1.fr.eu [213.251.191.165]
14 51 ms 71 ms 52 ms ksxxxxx.kimsufi.com [91.121.27.xxx]
OVH-->Telecom
Codice:
1 rbx-14-m2.fr.eu (91.121.27.252) 0.828 ms 1.043 ms 1.181 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.677 ms * *
3 rbx-g1-a9.fr.eu (213.186.32.233) 1.459 ms 1.487 ms 1.511 ms
4 * * *
5 mil-1-6k.it.eu (213.251.128.65) 18.955 ms * *
6 seabone.as6762.fr.eu (91.121.131.26) 18.002 ms 17.902 ms 26.882 ms
technofab
02.01.2013, 16.22
Originariamente Scritto da
EvolutionCrazy
Per la piccola esperienza avuta.... Si...
EvolutionCrazy
02.01.2013, 16.01
dici?
sto attendendo (da ieri notte... alla faccia dell'1h disponibilità ... ) l'attivazione di una nuova macchina (SP 32G SSD - ordine 17648129)... vediamo se finisce in rbx4 ... essendo hw nuovo rispetto ai vecchi presumo (temo?) finirà in uno dei dc nuovi...
technofab
02.01.2013, 15.44
Originariamente Scritto da
EvolutionCrazy
c'è qualche problema?
perché questa differenza?
Imho qos policy di Telecom su alcune classi OVH.
Ricordo che cambiai ip ad un server, e da una rete telecom prima non andavo, subito dopo iniziai a volare. O di riffa o di raffa, da qualche parte c'è un qos.
EvolutionCrazy
02.01.2013, 15.33
Originariamente Scritto da
technofab
Ma non avevi detto che avevi cambiato l'ip di telecom?
C'è una lista newsletter che dice quali ip e in continua evoluzione vedo ri ritrovartela.
forse ti riferisci a:
http://abuse.ovh.net/index.php?action=blockedByASN
?
comunque ho vari feedback da utenti telecom italia che riscontrano velocità oscene (in certi momenti riportano anche velocità di picco di 80kbyte/sec ... di media non si superano mai i 300kbyte/sec) nel download da server in RBX4 (uno che sto vedendo ora per esempio entra da vss-8a-6k )...
mentre da server in RBX1 e RBX2 stesso utente, stesso ip, stesso PC scaricano a banda piena ...
c'è qualche problema?
perché questa differenza?
technofab
27.12.2012, 11.45
Originariamente Scritto da
viking2010
L'ip del server è sempre quello...
Sai dove posso trovare la lista di ip bloccati?
Ma non avevi detto che avevi cambiato l'ip di telecom?
C'è una lista newsletter che dice quali ip e in continua evoluzione vedo ri ritrovartela.
Originariamente Scritto da
viking2010
Cambiato ip pubblico Telecom e magicamente ho di nuovo la banda piena in download...
Ovviamente ci sono problemi di routing per certe classi di ip...
In questi casi per approfondire il problema ed avere i dettagli utilii è necessario avere un traceroute Internet <-> Ovh e conoscere l'ip pubblico in questione.
Non esitare a postare queste informazioni nel caso si ripresenti il problema, grazie
viking2010
27.12.2012, 09.39
L'ip del server è sempre quello...
Sai dove posso trovare la lista di ip bloccati?
technofab
27.12.2012, 07.49
Originariamente Scritto da
viking2010
eh?! potresti spiegarti meglio?
Datosi che Telecom attua politiche anti-botnet, blocca alcune classi di ip sistematicamente con regole di qos ed altro. Ovviamente tu non covi una botnet, ma ti chiedevo se avevi indagato se il tuo ip rientrava in queste classi bloccate, dato che appena cambiato riprende il download a velocità soddisfacente.
viking2010
26.12.2012, 21.48
Originariamente Scritto da
technofab
Ovviamente non è il tuo caso, ma che ci siano politiche anti-botnet?
eh?! potresti spiegarti meglio?
technofab
25.12.2012, 10.23
Originariamente Scritto da
viking2010
Cambiato ip pubblico Telecom e magicamente ho di nuovo la banda piena in download...
Ovviamente ci sono problemi di routing per certe classi di ip...
Ovviamente non è il tuo caso, ma che ci siano politiche anti-botnet?
viking2010
24.12.2012, 19.55
Cambiato ip pubblico Telecom e magicamente ho di nuovo la banda piena in download...
Ovviamente ci sono problemi di routing per certe classi di ip...
viking2010
22.12.2012, 17.35
Ci sono problemi di banda da OVH-->Telecom Italia?
Grazie.
Dunque ho 2 rbx4(quelli a 3M/s), uno misconosciuto baia 45A10 che credo sia rbx3 che è quello che va a carbone(600k/s).
EvolutionCrazy
12.12.2012, 12.59
nel manager vedi i dettagli del rack (riepilogo: Baia: XXX)
quindi cerca il tuo rack qui:
http://status.ovh.it/vms/
PS: prima ho sbagliato era RBX2 quello, ho provato anche un RBX1 e pure va bene
Su 3 server, tutti rbx, 2 che sono intorno ai 3M/s e uno addirittura 600k/s...in particolare quest'ultimo che va a carbone è un mg server serie 2012.
Dove vedo in che n° di dc sono le macchine fisicamente?
EvolutionCrazy
12.12.2012, 12.33
direi di no... da rbx4
Codice:
wget -O /dev/null http://mi.mirror.garr.it/mirrors/CentOS/6.3/isos/i386/CentOS-6.3-i386-LiveDVD.iso
--2012-12-12 12:32:29-- http://mi.mirror.garr.it/mirrors/CentOS/6.3/isos/i386/CentOS-6.3-i386-LiveDVD.iso
Resolving mi.mirror.garr.it... 193.206.139.34, 2001:760:ffff:b1::34
Connecting to mi.mirror.garr.it|193.206.139.34|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1735393280 (1.6G) [application/octet-stream]
Saving to: â/dev/nullâ
100%[==========================================>] 1,735,393,280 87.3M/s in 28s
2012-12-12 12:32:57 (59.7 MB/s) - â/dev/nullâ
Possibile che la banda francia-italia sia circa 10M/s per server?
Sto provando a scaricare iso random dai mirror italiani e non supero mai i 3-4M/s che raggiungo al massimo dal garr:
wget
http://mi.mirror.garr.it/mirrors/Cen...86-LiveDVD.iso
--2012-12-12 12:25:02--
http://mi.mirror.garr.it/mirrors/Cen...86-LiveDVD.iso
Risoluzione di mi.mirror.garr.it... 193.206.139.34, 2001:760:ffff:b1::34
Connessione a mi.mirror.garr.it|193.206.139.34|:80... connesso.
HTTP richiesta inviata, in attesa di risposta... 200 OK
Lunghezza: 1735393280 (1,6G) [application/octet-stream]
Salvataggio in: "CentOS-6.3-i386-LiveDVD.iso.5"
0% [> ] 15.988.784 3,33M/s est 8m 21s
40% [================================================== =========> ] 704.984.684 3,32M/s est 5m 1s
da altri server raggiungo senza problemi i 10M/s(su porta 100mbps) in download senza problemi.
Ovviamente ovh to ovh va da dio:
wget
http://proof.ovh.net/files/10Gb.dat
--2012-12-12 12:28:49--
http://proof.ovh.net/files/10Gb.dat
Risoluzione di proof.ovh.net... 188.165.12.106, 2001:41d0:2:876a::1
Connessione a proof.ovh.net|188.165.12.106|:80... connesso.
HTTP richiesta inviata, in attesa di risposta... 200 OK
Lunghezza: 1250000000 (1,2G) [application/octet-stream]
Salvataggio in: "10Gb.dat"
100%[================================================== ================================================== =============================================>] 1.250.000.000 110M/s in 11s
2012-12-12 12:29:00 (107 MB/s) - "10Gb.dat" salvato [1250000000/1250000000]
Ci sono filtri per il traffico fuori ovh che non consentono di utilizzare tutta l'ampiezza di banda? Giusto per chiarire, il sintomo si presenta tanto in download che in upload.
viking2010
08.11.2012, 22.33
Banda sempre alterina, che succede?
EvolutionCrazy
17.09.2012, 21.15
lo speedtest da telecom italia fa piangere
http://proof.ovh.net/
Codice:
Last Result:
Download Speed: 1329 kbps (166.1 KB/sec transfer rate)
Upload Speed: 226 kbps (28.3 KB/sec transfer rate)
Latency: 108 ms
Mon Sep 17 2012 21:16:05 GMT+0200 (ora legale Europa occidentale)
1mbit a malapena e RTT che non scende sotto i 100ms ...
morti 2 link da 10G francoforte - milano
lumaca mode ON
io ho risolto temporaneamente usando winscp + tunnel sftp verso 1 una mia piccola vps che ha ip fallover ovh italiano (e che sembra immune a questo problema, sarà x l'ip ke è italiano?) xkè sennò x trasferire file andavo massimo a 200 kb ;(
viking2010
16.09.2012, 14.44
Originariamente Scritto da
EvolutionCrazy
il problema è che abbiamo servers gbit non saturi e download che oscillano tra i 100 e i 200k :/
La banda a disposizione non è all'altezza...
EvolutionCrazy
16.09.2012, 14.25
il problema è che abbiamo servers gbit non saturi e download che oscillano tra i 100 e i 200k :/
viking2010
16.09.2012, 14.15
4 link da 10G saturi al 96%
EvolutionCrazy
16.09.2012, 13.55
siamo messi proprio male qua...
la banda verso telecom italia fa ridere e nessuno dice nulla... boh... mi sa che è giunto il momento di iniziare a telefonare a Milano e sentire cosa dicono... alla fine sono questi i problemi in cui il supporto serve (e non per seguire l'utente ad aggiungere un ip failover o cambiare la psw di root come leggo in giro -_-')
risegnalato a oles .. vediamo se hanno la decenza di sistemare..
viking2010
16.09.2012, 11.55
i link seabone sia a francoforte che parigi sono perennemente full
vediamo che dicono in mailing list... l'altra volta avevano dirottato del traffico che passava da milano per l'egitto.
lot of new trafic to Egypt. I've moved it to Frankfurt.
anyway we are looking to build a direct network from
SBG to MIL with 2 dark fibers.
questa era stata la risposta...
viking2010
13.09.2012, 21.03
Milano un pò alla volta, si satura
http://i46.tinypic.com/33y6jcn.jpg
Nemmeno il Seabone che esce direttamente da Francoforte non è messo bene:
http://i48.tinypic.com/swpxg3.jpg
viking2010
11.09.2012, 23.36
Con Telecom Italia, avete notato che con un singolo flusso (per esempio 1 solo trasferimento FTP) da OVH-->Internet (Alice) la banda è molto ballerina?
Giovanni
06.09.2012, 22.16
Io direi anche un 100G...
Guardiamo nel futuro noi
viking2010
01.09.2012, 12.08
Sempre peggio, ed è appena mezzogiorno:
http://i50.tinypic.com/slhg8i.jpg
Vediamo più tardi come va
non male... forse al POP di milano qualche altro bel link 10G non guasterebbe...
viking2010
29.08.2012, 21.50
Mi preoccupa questa cosa sinceramente:
http://i46.tinypic.com/9prm36.jpg
viking2010
24.08.2012, 15.25
Potrebbero ottimizzare il routing.
Visto che AscoTLC si appoggia a interoute (presente anche nel mix di Milano) potrebbero fare un peering.
più lungo ma guadagna in ms... 28 contro i 31
viking2010
24.08.2012, 15.16
Si utilizza Interoute.
Tracert da AscoTLC-->OVH
Codice:
tracert 91.121.xxx.xxx
Rilevazione instradamento verso ks21366.kimsufi.com [91.121.xxx.xxx]
su un massimo di 30 punti di passaggio:
1 1 ms 1 ms 1 ms 192.168.1.1
2 2 ms 3 ms 4 ms 10.4.0.17
3 18 ms 2 ms 2 ms 10.4.0.9
4 3 ms 2 ms 2 ms rh-1-vi-30.fwl-svend01-01.ascotlc.net [188.125.113.126]
5 * * * Richiesta scaduta.
6 3 ms 3 ms 3 ms gi-0-0-0.bgr-svend01-01.ascotlc.net [188.125.113.57]
7 3 ms 3 ms 3 ms gi-0-0-0.bgr-svend01-02.ascotlc.net [188.125.113.33]
8 4 ms 4 ms 3 ms 89.202.198.137
9 8 ms 7 ms 7 ms xe-2-2-1-0.mil-cal-score-1-re1.interoute.net [217.118.118.149]
10 8 ms * 14 ms ovh.mix-it.net [217.29.66.67]
11 18 ms * 41 ms fra-1-6k.de.eu [213.251.128.66]
12 36 ms 33 ms 34 ms rbx-g1-a9.fr.eu [91.121.131.193]
13 31 ms * 31 ms rbx-2-6k.fr.eu [213.186.32.234]
14 31 ms 32 ms 31 ms rbx-14-m1.fr.eu [213.251.191.165]
15 56 ms 31 ms 31 ms ks21366.kimsufi.com [91.121.xxx.xxx]
Rilevazione completata.
Tracert da OVH-->AscoTLC
Codice:
traceroute 188.125.xxx.xxx
traceroute to 188.125.xxx.xxx (188.125.xxx.xxx), 30 hops max, 60 byte packets
1 rbx-14-m2.fr.eu (91.121.27.252) 0.867 ms 1.071 ms 1.205 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 36.219 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.10) 1.799 ms 1.865 ms 1.846 ms
4 ldn-5-6k.uk.eu (91.121.128.192) 4.070 ms ldn-5-6k.uk.eu (91.121.128.166) 4.067 ms *
5 Gi3-0.lonth-inter-1.interoute.net (195.66.224.53) 4.110 ms 4.075 ms 4.122 ms
6 ae1-0.par-gar-score-1-re0.interoute.net (212.23.42.21) 27.033 ms 30.584 ms 30.445 ms
7 ae1-0.mil-cal-score-2-re0.interoute.net (89.202.146.93) 27.640 ms 27.629 ms 27.615 ms
8 ae0-0.mil-cal-score-1-re1.interoute.net (89.202.146.85) 24.083 ms 24.074 ms 24.069 ms
9 Gi10-0.vce-val-access-1.interoute.net (217.118.118.150) 27.651 ms 27.698 ms 27.969 ms
10 89.202.198.141 (89.202.198.141) 28.803 ms 28.790 ms 28.770 ms
11 gi-0-0-2.bgr-svend01-01.ascotlc.net (188.125.113.34) 28.621 ms 28.616 ms 28.585 ms
12 ge-0-0-0-vi-970.pop-svend01-01.ascotlc.net (188.125.113.58) 28.676 ms 28.656 ms 28.896 ms
13 rh-1-vi-31.fwl-svend01-01.ascotlc.net (188.125.113.214) 28.762 ms 28.717 ms 28.675 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ib-vi-31.pop-svend01-01.ascotlc.net (188.125.113.210) 27.863 ms 27.937 ms 27.925 ms
19 * * *
20 ib-vi-31.pop-svend01-01.ascotlc.net (188.125.113.210) 27.924 ms 27.927 ms 27.912 ms
21 * * *
22 ib-vi-31.pop-svend01-01.ascotlc.net (188.125.113.210) 27.898 ms 27.978 ms 27.970 ms
23 * * *
24 * * *
25 * * *
26 ib-vi-31.pop-svend01-01.ascotlc.net (188.125.113.210) 28.276 ms 28.235 ms 28.076 ms
27 * * *
28 ib-vi-31.pop-svend01-01.ascotlc.net (188.125.113.210) 28.145 ms 28.515 ms 28.105 ms
29 * * *
30 ib-vi-31.pop-svend01-01.ascotlc.net (188.125.113.210) 28.392 ms 28.378 ms 28.369 ms
Per entrare nella rete OVH entra direttamente da Francoforte, su fra-1-6k.de.eu.
Da OVH esce sul nodo di Londra su ldn-5-6k.uk.eu, ma che giro fa?!
hanno VSIX come internet exchange..
se non ricordo male come IP transit AscoTLC usa retelit e interoute
viking2010
24.08.2012, 15.07
Quindi per capirci escono su internet tramite il VSIX NAP?
mah per quei 4 utenti in croce che hanno
poi sono presenti al
http://www.vsix.it
viking2010
24.08.2012, 09.43
Originariamente Scritto da
yak983
per le barzellette del giorno?
Se prima o poi saranno presenti nel mix
per le barzellette del giorno?
viking2010
24.08.2012, 09.09
Originariamente Scritto da
yak983
Bella rogna Proverò a sentire AscoTLC.
la vedo dura... ascotlc non è presente al MIX di Milano
http://www.mix-it.net/index.php?opti...mid=84&lang=en
viking2010
23.08.2012, 17.44
Potreste procedere con il peering verso AscolTLC?
da quello che so TISCALI non ha peering al MIX praticamente con nessuno.
Cercano di vendere il loro IP Transit
Originariamente Scritto da
tormento
Siamo in contatto ed in attesa di risposta da parte di Tiscali
tormento
11.05.2012, 09.46
Originariamente Scritto da
tmit
Dovremmo contattare Tiscali e richiedere un peering al MIX con OVH...
Avviso
Novità?
tormento
18.04.2012, 08.43
Grazie mille.
Dovremmo contattare Tiscali e richiedere un peering al MIX con OVH...
Avviso
tormento
17.04.2012, 09.18
TMIT, riesci a far qualcosa per Tiscali?
tormento
05.04.2012, 09.04
Originariamente Scritto da
tmit
mi sono segnato anche altri operatori più
o meno importanti, verso i quali possiamo proporre il peering.
Si riesce a far qualcosa per Tiscali?
Codice:
Traccia instradamento verso proof.ovh.net [188.165.12.106]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.103.254
2 26 ms 25 ms 25 ms static-xxx-xxx-xxx-xxx.clienti.tiscali.it [xxx.xxx.xxx.xxx]
3 27 ms 26 ms 25 ms 94.32.130.1
4 26 ms 27 ms 26 ms static-213-205-56-105.clienti.tiscali.it [213.205.56.105]
5 26 ms 28 ms 26 ms 94.32.128.145
6 25 ms 27 ms 25 ms ae2-300.mil20.ip4.tinet.net [77.67.94.37]
7 26 ms 25 ms 26 ms as3549.ip4.tinet.net [77.67.75.90]
8 51 ms 52 ms * ams-5-6k.nl.eu [94.23.122.133]
9 53 ms 56 ms 54 ms rbx-g2-a9.fr.eu [91.121.131.173]
10 51 ms 51 ms * rbx-s3-6k.fr.eu [178.33.100.98]
11 53 ms 53 ms 54 ms proof.ovh.net [188.165.12.106]
Originariamente Scritto da
viking2010
Non capisco questo post... Potresti rispondere in "verbose" mode?
viking2010
01.01.2012, 19.19
errore
viking2010
23.12.2011, 15.26
Originariamente Scritto da
tmit
Certo che si e difatti ho riportato il feedback di questa questione
ai tecnici che si occupano delle infrastrutture. Inoltre esattamente
a questo proposito, mi sono segnato anche altri operatori più
o meno importanti, verso i quali possiamo proporre il peering.
Ho visto che avete fatto...ottima cosa...
Codice:
Traccia instradamento verso ksxxxxx.kimsufi.com [91.121.xxx.xxx]
su un massimo di 30 punti di passaggio:
1 3 ms 1 ms 2 ms host9.pool-98.net-94-47.e4a.it [94.47.98.x]
2 4 ms 2 ms 2 ms host250.pool-98.net-94-47.e4a.it [94.47.98.250]
3 3 ms 4 ms 9 ms 77.42.38.2
4 3 ms 3 ms 6 ms host253.pool-109.net-94-47.e4a.it [94.47.109.253
]
5 10 ms 12 ms 4 ms host2.pool-109.net-94-47.e4a.it [94.47.109.2]
6 5 ms 4 ms 6 ms 77.42.113.142
7 15 ms 7 ms 9 ms 46.40.154.206
8 43 ms 96 ms 23 ms 94.47.147.73
9 26 ms 23 ms 18 ms 94.47.0.194
10 32 ms * 35 ms ovh.mix-it.net [217.29.66.67]
11 36 ms * 50 ms mil-5-6k.it.eu [94.23.122.251]
12 41 ms * 45 ms fra-5-6k.de.eu [91.121.128.35]
13 75 ms 65 ms 49 ms rbx-g2-a9.fr.eu [91.121.131.130]
14 110 ms 82 ms 62 ms rbx-2-6k.fr.eu [91.121.131.9]
15 54 ms 70 ms 55 ms rbx-14-m1.fr.eu [213.251.191.165]
16 48 ms 49 ms 41 ms ksxxxxx.kimsufi.com [91.121.xxx.xxx]
Traccia completata.
Ora passa per Milano, mentre una volta passava per Amsterdam
viking2010
19.12.2011, 19.22
Da un pò di giorni noto problemi di banda ballerina verso sera dai server ovh (con adsl Telecom Italia), anche dal server proof.ovh.net...Dopo una certa ora ritorna tutto alla normalità, ossia banda piena dal server (compreso proof.ovh.net).
Scaricando da altri server non ovh (nel periodo che noto la banda ballerina) la banda è sempre piena.
Per banda ballerina intendo dire che varia di moltissimo, per esempio 900kb/s-->100kb/s-->500kb/s e così via. Cosa identica sia dal mio server, che proof.ovh.net.
viking2010
23.11.2011, 17.45
Originariamente Scritto da
tmit
Certo che si e difatti ho riportato il feedback di questa questione
ai tecnici che si occupano delle infrastrutture. Inoltre esattamente
a questo proposito, mi sono segnato anche altri operatori più
o meno importanti, verso i quali possiamo proporre il peering.
Grazie della collaborazione
Certo che si e difatti ho riportato il feedback di questa questione
ai tecnici che si occupano delle infrastrutture. Inoltre esattamente
a questo proposito, mi sono segnato anche altri operatori più
o meno importanti, verso i quali possiamo proporre il peering.
viking2010
23.11.2011, 16.50
Originariamente Scritto da
tmit
No, come già detto in precedenza devono essere loro a richiederlo,
o nel caso noi a proporlo. Inoltre non ho informazione ufficiale, ma
dovrebbe trattarsi di una operazione fattibile gratuitamente.
Visto che è compromessa anche la navigazione sui siti hostati sui vostri server, non potete richiederla voi?
No, come già detto in precedenza devono essere loro a richiederlo,
o nel caso noi a proporlo. Inoltre non ho informazione ufficiale, ma
dovrebbe trattarsi di una operazione fattibile gratuitamente.
viking2010
23.11.2011, 16.06
Originariamente Scritto da
tmit
Si, fondamentalmente i vari provider che hanno un autonomous system
(al MIX in questo caso) hanno la possibilità di richiederci un peering interno,
stessa cosa che possiamo fare anche noi, per poter instradare in maniera
ottimale il traffico da quel determinato provider verso OVH.
Ritornando sul discorso
E4A, anche loro dovrebbero essere sul mix:
La CONNETTIVITA' INTERNET avviene attraverso dorsali multiple in fibra ottica interconnesse sui POP di Vicenza, Padova, Milano, Roma, Londra, Amsterdam, Dublino, Praga, Berlino, Varsavia, Miami, Los Angeles e Zurigo da dove partono le interconnessioni dirette verso gli operatori nazionali presso NaMeX, MIX, MINAP, VSIX e verso i principali operatori internazionali presso LINX, AMS-IX, INEX, NIX.CZ, BCIX, PLIX, NOTA, Any2 e SwissIX, e le rimanenti connessioni internazionali attraverso i carrier Cogent, Global Crossing, Level3 e Hurricane Electric.
Questo peering interno avviene a pagamento?
Si, fondamentalmente i vari provider che hanno un autonomous system
(al MIX in questo caso) hanno la possibilità di richiederci un peering interno,
stessa cosa che possiamo fare anche noi, per poter instradare in maniera
ottimale il traffico da quel determinato provider verso OVH.
viking2010
23.11.2011, 15.36
Quindi ogni ISP italiano deve accordarsi con voi per transitare tramite l'accesso MIX-->OVH?
E4A AS34695 (IT) -> TINET AS3257 (DE) -> TINET AS3257 (DE) -> Global Crossing GBLX (Amsterdam) -> OVH AS16276 (Roubaix)
viking2010
23.11.2011, 15.24
Originariamente Scritto da
tmit
Perchè non abbiamo l'interconnessione con questo ISP.
E quindi passa x Amsterdam?!
Originariamente Scritto da
viking2010
Perchè non abbiamo l'interconnessione con questo ISP.
viking2010
23.11.2011, 15.06
Capito...
Questo tracert sotto è un caso strano (fatto da un mio compaesano), tracert con connessione internet con l'ISP
E4A:
Codice:
C:\Users\xxxxx>tracert 91.121.xxx.xxx
Traccia instradamento verso ksxxxxx.kimsufi.com [91.121.xxx.xxx]
su un massimo di 30 punti di passaggio:
1 2 ms 1 ms 2 ms host9.pool-98.net-94-47.e4a.it [94.47.98.x]
2 78 ms 4 ms 6 ms host250.pool-98.net-94-47.e4a.it [94.47.98.250]
3 30 ms 2 ms 3 ms 77.42.38.2
4 3 ms 3 ms 2 ms host253.pool-109.net-94-47.e4a.it [94.47.109.253]
5 5 ms 3 ms 7 ms host2.pool-109.net-94-47.e4a.it [94.47.109.2]
6 17 ms 5 ms 4 ms 77.42.113.142
7 12 ms 13 ms 13 ms 46.40.156.142
8 35 ms 23 ms 18 ms 94.47.147.73
9 20 ms * 34 ms 94.47.0.193
10 35 ms 35 ms 27 ms xe-4-3-0-301.mil20.ip4.tinet.net [77.67.65.69]
11 25 ms 30 ms 32 ms as3549.ip4.tinet.net [77.67.75.90]
12 61 ms 38 ms 49 ms po4.ar6.AMS2.gblx.net [67.16.132.122]
13 239 ms 229 ms 93 ms ams-5-6k.nl.eu [94.23.122.86]
14 55 ms 61 ms 71 ms rbx-g2-a9.fr.eu [94.23.122.189]
15 43 ms 47 ms * rbx-2-6k.fr.eu [91.121.131.9]
16 * 57 ms 53 ms rbx-14-m1.fr.eu [213.251.191.165]
17 53 ms 46 ms 48 ms ksxxxx.kimsufi.com [91.121.xxx.xxx]
Traccia completata.
Fa un giro alquanto strano, ed entra in OVH da Amsterdam...
Oltre a questo la banda da
OVH -->
E4A è veramente bassa, non supera i 50kb/s (quando va bene!).
Come mai?
Al MIX girano solo le interconnessioni per le quali abbiamo il peering come
per fare un esempio Fastweb, BT-Italia, COLT, Eutelia, GARR e molti altri.
Con TI in particolare abbiamo la gestione separata tramite TISparkle Global IP Backbone (Seabone).
viking2010
23.11.2011, 14.06
Ora mi è chiaro...invece il traffico da OVH-->Italia passa per il mix giusto?
Ma questo giro verso OVH ed il seabone avviene solo per le connessioni Telecom Italia o per tutte?
Perchè Seabone non ci ha mai offerto il peering verso il MIX.
EDIT:
Per essere più chiari:
in pratica Seabone riconosce il nostro AS come internazionale,
poichè il traffico passante per il MIX andrebbe diretto oltralpe,
ovvero traffico non nazionale. Il peering presso il MIX viene
offerto solo per le connessioni nazionali.
viking2010
23.11.2011, 12.45
Come mai da Telecom verso OVH si fa questo giro (seabone_milano --> seabone_francoforte --> francoforte --> ovh) :
Codice:
7 31 ms 31 ms 31 ms bundle-ether14.milano26.mil.seabone.net [93.186.128.213]
8 52 ms 53 ms 52 ms te4-1.franco15.fra.seabone.net [89.221.34.121]
e non
seabone --> mix --> ovh?
Originariamente Scritto da
viking2010
Cmq o hai la fibra ottica o l'ADSL
Svista mia Sorry
viking2010
23.11.2011, 12.28
Ecco il mio da connessione in fibra ottica:
Codice:
C:\Documents and Settings\xxxxxx>ping proof.ovh.net -n 10
Esecuzione di Ping proof.ovh.net [188.165.12.106] con 32 byte di dati:
Risposta da 188.165.12.106: byte=32 durata=35ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=35ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=31ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=60ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=44ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=42ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=64ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=50ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=47ms TTL=47
Risposta da 188.165.12.106: byte=32 durata=50ms TTL=47
Statistiche Ping per 188.165.12.106:
Pacchetti: Trasmessi = 10, Ricevuti = 10, Persi = 0 (0% persi),
Tempo approssimativo percorsi andata/ritorno in millisecondi:
Minimo = 31ms, Massimo = 64ms, Medio = 45ms
e relativo tracert:
Codice:
C:\Documents and Settings\xxxxx>tracert proof.ovh.net
Rilevazione instradamento verso proof.ovh.net [188.165.12.106]
su un massimo di 30 punti di passaggio:
1 2 ms 2 ms 1 ms 192.168.1.1
2 2 ms 3 ms 4 ms 10.4.0.17
3 5 ms 7 ms 5 ms 10.4.0.5
4 9 ms 2 ms 2 ms 192.168.2.1
5 4 ms 4 ms 3 ms gi-0-0-0.bgr-casie01-01.ascotlc.net [188.125.113.65]
6 4 ms 3 ms 4 ms gi-0-0-0-vi-20.bgr-svend01-01.ascotlc.net [188.125.113.116]
7 8 ms 3 ms 4 ms gi-0-0-0.bgr-svend01-02.ascotlc.net [188.125.113.33]
8 4 ms 4 ms 6 ms roanne.wizzgo.com [89.202.198.137]
9 12 ms 9 ms 8 ms xe-5-2-0-0.mil-cal-score-1-re0.interoute.net [217.118.118.149]
10 8 ms * 11 ms ovh.mix-it.net [217.29.66.67]
11 19 ms * 26 ms fra-1-6k.de.eu [213.251.128.66]
12 38 ms 38 ms 33 ms rbx-g1-a9.fr.eu [91.121.131.193]
13 58 ms * 183 ms rbx-s4-6k.fr.eu [178.33.100.58]
14 31 ms 32 ms 32 ms proof.ovh.net [188.165.12.106]
Rilevazione completata.
Cmq o hai la fibra ottica o l'ADSL
Vorrei anche farvi presente che testando da una ADSL connessa in fibra ottica,
difatti il limite si attesta sempre e comunque attorno ai 20ms
Codice:
$ ping -c10 proof.ovh.net
PING proof.ovh.net (188.165.12.106) 56(84) bytes of data.
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=1 ttl=52 time=19.7 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=2 ttl=52 time=19.4 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=3 ttl=52 time=21.7 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=4 ttl=52 time=20.6 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=5 ttl=52 time=19.4 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=6 ttl=52 time=20.3 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=7 ttl=52 time=19.2 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=8 ttl=52 time=19.4 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=9 ttl=52 time=19.0 ms
64 bytes from proof.ovh.net (188.165.12.106): icmp_req=10 ttl=52 time=21.0 ms
--- proof.ovh.net ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 19.048/20.022/21.726/0.842 ms
viking2010
23.11.2011, 10.16
pftech grazie della spiegazione
Originariamente Scritto da
viking2010
Per me sono delle impostazioni dei router invece. Tutti i collegamenti sono in fibra.
No, mi dispiace ma non sono semplici impostazioni, essendo i collegamenti tutti in F.O. si deve appunto sottostare alla velocità trasmissiva della F.O. che dipende appunto dalla luce oltre che dalla velocità dei transciever stessi che convertono i segnali in F.O. su rame e viceversa.
La latenza teorica di un cavo in f.o. è di 5 microsecondi al km! Se calcoli che tra Milano e Parigi ci saranno almeno 1500 km di fibra ottica, la latenza MINIMA teorica che si dovrebbe avere è di 7,5 ms a questi però bisogna aggiungere le latenze dovute alla rigenerazione del segnale. Ricordo infatti che le trasmissioni in fibra su lunga distanza necessitano di una rigenerazione del segnale ogni 50-70 km circa, quindi considerando anche 1 solo ms di latenza per ogni rigenerazione otteniamo almeno 30 ms aggiuntivi per le rigenerazioni del segnale ottico. Questo chiaramente è tutto in linea teorica, comunque se considerate che dal MIX a OVH ci sono circa 24-28 ms di latenza, i conti che ho fatto mi sembrano abbastanza corretti.
Ricordo che da Firenze al MIX ci sono 7-8 ms per una distanza di circa 500 km di f.o., moltiplicato per 3 se consideriamo 1500 km di fibra per Parigi, i 25 ms di media ci stanno tutti quanti!!!
Mi dispiace ma non sono impostazioni dei router... magari lo fossero... e poi perchè metterebbero queste latenze??
Saluti....
viking2010
21.11.2011, 09.44
Per me sono delle impostazioni dei router invece. Tutti i collegamenti sono in fibra.
Ottima notizia del potenziamento del nodo del MIX con raddoppio di banda...
Il problema dei PING penso sia fisiologico poichè i ms impiegati sono quelli tipici per coprire una distanza del genere (ovvero 1000-1500 km!) e non penso siano risolvibili in alcun modo a livello fisico (velocità di trasmissione dati di poco inferiore alla velocità della luce, quest'ultima resta il limite teorico massimo!).
E' esattamente la stessa cosa di ciò che avviene pingando da Roma o più a sud, il Mix, anche con ottime connessioni 10-15 ms come minimo ci sono per la distanza!!! Io con un'ottima connessione annessa direttamente al Mix tramite ULI da Firenze al Mix ho sempre pingato almeno a 10-12 ms non più basso!!!
Purtroppo questo è l'unico "limite" di OVH e delle serverfarm in Francia per noi Italiani. Se però provi a pingare da server in Lussemburgo, Belgio o Germania (verso il confine Francese) vedrai che i ping son ben più bassi... 3-4 ms per i primi paese, 7-10 ms per la Germania. E' tutto normale purtroppo!
Ciaooooo
viking2010
19.11.2011, 15.52
Il collegamento verso il MIX è stato potenziato, ora 2 flussi 10G, quindi per un totale di 10Gx2...
http://i40.tinypic.com/k9bhg.jpg
http://i39.tinypic.com/242ykwz.jpg
Ottima cosa...
Xò il fatto del ping rimane sempre...
Da
AscoTLC in fibra verso il mio server:
Codice:
C:\Documents and Settings\xxxxxxx>tracert 91.121.xxx.xxx
Rilevazione instradamento verso ksxxxxx.kimsufi.com [91.121.xxx.xxx]
su un massimo di 30 punti di passaggio:
1 1 ms 1 ms 1 ms 192.168.1.1
2 2 ms 2 ms 2 ms 10.4.0.17
3 2 ms 4 ms 4 ms 10.4.0.10
4 3 ms 4 ms 2 ms 192.168.2.5
5 2 ms 2 ms 2 ms gi-0-0-0.bgr-casie01-01.ascotlc.net [188.125.113.65]
6 3 ms 3 ms 3 ms gi-0-0-0-vi-20.bgr-svend01-01.ascotlc.net [188.125.113.116]
7 3 ms 3 ms 3 ms gi-0-0-0.bgr-svend01-02.ascotlc.net [188.125.113.33]
8 4 ms 4 ms 4 ms roanne.wizzgo.com [89.202.198.137]
9 8 ms 7 ms 8 ms xe-5-2-0-0.mil-cal-score-1-re0.interoute.net [217.118.118.149]
10 8 ms * 8 ms ovh.mix-it.net [217.29.66.67]
11 19 ms * 19 ms fra-1-6k.de.eu [213.251.128.66]
12 32 ms 32 ms 32 ms rbx-g1-a9.fr.eu [91.121.131.205]
13 31 ms 31 ms * rbx-1-6k.fr.eu [94.23.122.105]
14 32 ms 31 ms 31 ms rbx-14-m1.routers.chtix.eu [213.251.191.37]
15 31 ms 31 ms 32 ms ksxxxxx.kimsufi.com [91.121.xxx.xxx]
Rilevazione completata.
Si nota che tra il nodo
ovh.mix-it.net e
rbx-g1-a9.fr.eu prende
24ms all'interno della rete OVH. Strano sinceramente.
Da
ADSL Telecom Italia verso il mio server:
Codice:
C:\Documents and Settings\xxxxxxx>tracert 91.121.xxx.xxx
Rilevazione instradamento verso ksxxxxx.kimsufi.com [91.121.xxx.xxx]
su un massimo di 30 punti di passaggio:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Richiesta scaduta.
3 23 ms 22 ms 22 ms 172.17.217.37
4 22 ms 22 ms 23 ms 172.17.216.5
5 29 ms 29 ms 28 ms 172.17.9.129
6 30 ms 30 ms 29 ms 172.17.10.81
7 31 ms 31 ms 31 ms bundle-ether14.milano26.mil.seabone.net [93.186.128.213]
8 52 ms 53 ms 52 ms te4-1.franco15.fra.seabone.net [89.221.34.121]
9 * 52 ms * fra-1-6k.de.eu [94.23.122.157]
10 61 ms 60 ms 63 ms rbx-g1-a9.fr.eu [94.23.122.210]
11 81 ms 76 ms * rbx-1-6k.fr.eu [94.23.122.105]
12 60 ms 60 ms 60 ms rbx-14-m1.routers.chtix.eu [213.251.191.37]
13 60 ms 59 ms 59 ms ksxxxxx.kimsufi.com [91.121.xxx.xxx]
Rilevazione completata.
Si nota che tra il nodo
bundle-ether14.milano26.mil.seabone.net e
fra-1-6k.de.eu prende
21ms all'interno del seabone. Xkè non far passare il traffico direttamente dal nodo
mil-1-6k?
viking2010
05.11.2011, 15.35
Il nodo del mix di Milano comincia ad essere un pò carico:
http://i39.tinypic.com/wspiya.jpg
Originariamente Scritto da
viking2010
Grazie Viking per i chiarimenti!! Non sapevo che ogni connessione sulla mappa corrispondesse a 10 Gbps di link. Quello del mix mi era sfuggito... mi aveva impressionato i 30 Gbps ma non avevo visto che attualmente collegati al momento sono 10 Gbps.
Per Telecom su Seabone confermo perchè da tutte le linee Telecom Italia si passa da Seabone per arrivare a OVH mentre da molti altri (tra cui BT, Vodafone, Eutelia) si passa dal Mix.
Tra l'altro, non so se qualcun'altro l'ha notato, negli ultimi giorni, nel primo pomeriggio, capita che passando BT attraverso il Mix verso OVH, ci siano dei problemi di peering poichè il traffico viene instradato su Level3 Frankfurt e poi verso OVH e lì la tratta si interrompe.
Son dei disservizi di 30 minuti al massimo, non oltre, ma è già capitato 2 volte (venerdì e lunedì 31), speriamo non continuino.
Ciaooooo
viking2010
01.11.2011, 20.56
Originariamente Scritto da
gen_patton
Ne deduco che l'utenza Telecom Italia richiamando un ip OVH passa prioritariamente per il seabone e nel caso quest'ultimo sia saturo switccia sul mix.
Questa cosa non la so...
So che Telecom passa per il seabone, mentre gli altri operatori italiani per il mix.
gen_patton
01.11.2011, 17.19
Grazie Viking per il chiarimento. Quindi con Seabone ha 30gbps. Ne deduco che l'utenza Telecom Italia richiamando un ip OVH passa prioritariamente per il seabone e nel caso quest'ultimo sia saturo switccia sul mix. Un bel casino, ma molto interessante.
Ciao.
viking2010
31.10.2011, 19.06
Allora, dalla mappa di OVH, ogni link è una connessione da 10gbps...è qua per il mix ce ne è solo 1, quindi 10gbps...
http://i44.tinypic.com/s32ams.jpg
Sul mix è messo che utilizzano solo 10gbps dei 30gbps che avrebbero a disposizione...
http://i44.tinypic.com/35krh3n.jpg
Guarda tu stesso:
http://www.mix-it.net/index.php?opti...mid=84&lang=it
gen_patton
30.10.2011, 09.07
Originariamente Scritto da
pftech
La banda del link con OVH -- Mix di Milano è di 30 Gbps (così è dichiarato nell'elenco degli afferenti al Mix sul sito del Mix stesso). Considerate che con quella banda OVH è il secondo provider in assoluto al Mix in ordine di banda... prima Telecom Italia con 40 Gbps.
In ogni caso Ovh ha routing verso l'Italia anche attraverso Seabone come han già detto altri...
In teoria dovesse andare giù il link del Mix c'è sempre la ridondanza su Seabone che "dovrebbe" reggere!!!
Sono riuscito a trovate la lista degli afferenti, mi ero impantanato nei menu del Mix
30Gbps + seabone, non male.
Ciao.
La banda del link con OVH -- Mix di Milano è di 30 Gbps (così è dichiarato nell'elenco degli afferenti al Mix sul sito del Mix stesso). Considerate che con quella banda OVH è il secondo provider in assoluto al Mix in ordine di banda... prima Telecom Italia con 40 Gbps.
In ogni caso Ovh ha routing verso l'Italia anche attraverso Seabone come han già detto altri...
In teoria dovesse andare giù il link del Mix c'è sempre la ridondanza su Seabone che "dovrebbe" reggere!!!
gen_patton
24.10.2011, 08.06
Grazie, ora mi è tutto più chiaro.
Ciao.
viking2010
23.10.2011, 20.55
Per quanto riguarda Telecom Italia il traffico passa per il seabone, per il resto passa per il mix...
gen_patton
22.10.2011, 08.51
Quindi mi sembra di capire che è quello il link da tenere d'occhio per il traffico italiano, in quanto è il vero e proprio peering con gli operatori italiani. O sto sbagliando?
E' anche curiosità, in quanto non sono un espertone di reti e mi interesserebbe saperne di piu.
Grazie della disponibilità.
viking2010
22.10.2011, 01.15
Intendo il link Mix<-->Mil-1-6k
gen_patton
20.10.2011, 09.06
Intendi i link Ovh<->Mix o il Mix come infrastruttura?
Grazie
viking2010
19.10.2011, 22.07
Il mix è sempre + carico...rischio...
L'attuale connettività è la seguente:
http://weathermap.ovh.net/milan
gen_patton
16.10.2011, 10.18
Ciao, posseggo un server OVH nel datacenter a Roubaix. Il sito che ci ospito è per un utenza internazionale. A breve necessiterò di un server piu grosso, quindi, avendo un sito in italiano in crescita (ora su uno shared hosting), devo decidere se mantenere il server e spostarci il sito in italiano, oppure prendere un server in italia, che costa molto di piu.
Quindi avrei bisogno di sapere che connettività ha OVH con il MIX. Il sito in italiano ha anche parecchi video in streaming.
Grazie.