OVH Community, your new community space.

Banda Roubaix-Milano


torpado
22.02.2013, 08.49
Citazione 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, 17.17
Citazione 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.

torpado
21.02.2013, 13.27
Citazione 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

torpado
21.02.2013, 13.25
Citazione 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, 12.29
Citazione 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, 12.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?

torpado
21.02.2013, 11.50
Citazione 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, 11.44
mi hanno risposto ora al ticket incidente segnalandomi che la connettività è stata ripristinata :|

torpado
21.02.2013, 09.53
Citazione 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.

yak983
21.02.2013, 09.50
attendiamo notizie dallo STAFF!

EvolutionCrazy
21.02.2013, 09.39
ora attendiamo i rimborsi :O

saranno fatti in automatico a tutti quelli che hanno sforato lo sla garantito 99.90 / 99.95? :O

yak983
21.02.2013, 06.27
Comment by OVH - Thursday, 21 February 2013, 07:20AM
The connection was restored.

http://status.ovh.net/?do=details&id=4165

technofab
20.02.2013, 23.30
Sono in buona compagnia vedo... OVH ha niente da dire? Non riesco quasi ad aprire un ticket.

yak983
20.02.2013, 21.44
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, 21.27
aspetta quando è tutto 100g..... un fibercut da 100g ed è da mettersi a piangere

yak983
20.02.2013, 21.20
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, 20.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

albert
20.02.2013, 20.25
... so gia' cosa ti diranno:

entri in modalita' rescue e controlli se la macchina ha problemi di hard-disk

EvolutionCrazy
20.02.2013, 19.59
manco si carica il manager per aprire un ticket incidente!

situazione scandalosa!

EvolutionCrazy
20.02.2013, 19.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

albert
20.02.2013, 19.17
Ciao a tutti.

La situazione e' drammatica, non raggiungo nessuna delle mie macchine.

Qualcuno ha notizie su quello che sta succedendo?

Cordialitè

wiggaz
20.02.2013, 18.20
Oh Oh

http://i.imgur.com/IVj0OMbl.jpg

viking2010
10.02.2013, 14.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, 20.13
Banda altalenante anche stasera...
verrà mai sistemata sta situazione?! mah...

viking2010
21.01.2013, 15.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, 18.45
Oles ha sistemato
https://twitter.com/olesovhcom/statu...65504673898497

http://i.imgur.com/6uNZpnR.png

EvolutionCrazy
20.01.2013, 17.24
aggiungo: sei fortunato ad avere clienti italiani...

io ho anche molti clienti inglesi.. e verso UK la situazione è OSCENA per usare un eufemismo...
(stessi utenti verso leaseweb.com o nforce.com non hanno problemi e mi tocca spostarli là)

esempi:

http://p19.smokeping.ovh.net/ovh-ser...rget=EU.AS5089
http://p19.smokeping.ovh.net/ovh-ser...rget=EU.AS2856
http://p19.smokeping.ovh.net/ovh-ser...rget=EU.AS8586
http://p19.smokeping.ovh.net/ovh-ser...rget=EU.AS9105
http://p19.smokeping.ovh.net/ovh-ser...rget=EU.AS5089

EvolutionCrazy
20.01.2013, 17.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

pftech
20.01.2013, 17.08
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, 16.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?

pftech
20.01.2013, 16.40
Citazione 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, 16.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?

pftech
20.01.2013, 15.46
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, 13.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, 04.06
rbx3

banda ok senza problemi (come gli altri che ho)... niente rbx4... boh...

technofab
04.01.2013, 08.18
Citazione 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, 15.01
Citazione Originariamente Scritto da EvolutionCrazy
basta la baia
Baia: 05B04
Sono su Roubaix 1

http://travaux.ovh.net/vms/index_rbx.html

EvolutionCrazy
03.01.2013, 13.53
basta la baia

viking2010
03.01.2013, 12.51
Citazione 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, 20.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, 20.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, 15.22
Citazione Originariamente Scritto da EvolutionCrazy
dici?
Per la piccola esperienza avuta.... Si...

EvolutionCrazy
02.01.2013, 15.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, 14.44
Citazione 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, 14.33
Citazione 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, 10.45
Citazione 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.

torpado
27.12.2012, 10.42
Citazione 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, 08.39
L'ip del server è sempre quello...
Sai dove posso trovare la lista di ip bloccati?

technofab
27.12.2012, 06.49
Citazione 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, 20.48
Citazione Originariamente Scritto da technofab
Ovviamente non è il tuo caso, ma che ci siano politiche anti-botnet?
eh?! potresti spiegarti meglio?

technofab
25.12.2012, 09.23
Citazione 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, 18.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, 16.35
Ci sono problemi di banda da OVH-->Telecom Italia?

ardyp
12.12.2012, 12.06
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, 11.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

ardyp
12.12.2012, 11.51
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, 11.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â

ardyp
12.12.2012, 11.30
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.

yak983
08.11.2012, 21.39
manca come sempre

viking2010
08.11.2012, 21.33
Banda sempre alterina, che succede?

EvolutionCrazy
17.09.2012, 20.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 ...

yak983
17.09.2012, 17.54
morti 2 link da 10G francoforte - milano

lumaca mode ON

dc94
16.09.2012, 21.25
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, 13.44
Citazione 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, 13.25
il problema è che abbiamo servers gbit non saturi e download che oscillano tra i 100 e i 200k :/

viking2010
16.09.2012, 13.15
4 link da 10G saturi al 96%

EvolutionCrazy
16.09.2012, 12.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 -_-')

yak983
16.09.2012, 11.02
risegnalato a oles .. vediamo se hanno la decenza di sistemare..

viking2010
16.09.2012, 10.55
Oggi tutto rosso

http://i45.tinypic.com/5zfgoh.jpg

yak983
13.09.2012, 20.10
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, 20.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, 22.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, 21.16
Io direi anche un 100G...
Guardiamo nel futuro noi

viking2010
01.09.2012, 11.08
Sempre peggio, ed è appena mezzogiorno:

http://i50.tinypic.com/slhg8i.jpg

Vediamo più tardi come va

yak983
29.08.2012, 20.53
non male... forse al POP di milano qualche altro bel link 10G non guasterebbe...

viking2010
29.08.2012, 20.50
Mi preoccupa questa cosa sinceramente:

http://i46.tinypic.com/9prm36.jpg

viking2010
24.08.2012, 14.25
Potrebbero ottimizzare il routing.

Visto che AscoTLC si appoggia a interoute (presente anche nel mix di Milano) potrebbero fare un peering.

yak983
24.08.2012, 14.19
più lungo ma guadagna in ms... 28 contro i 31

viking2010
24.08.2012, 14.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?!

yak983
24.08.2012, 14.09
hanno VSIX come internet exchange..
se non ricordo male come IP transit AscoTLC usa retelit e interoute

viking2010
24.08.2012, 14.07
Quindi per capirci escono su internet tramite il VSIX NAP?

yak983
24.08.2012, 08.45
mah per quei 4 utenti in croce che hanno
poi sono presenti al http://www.vsix.it

viking2010
24.08.2012, 08.43
Citazione Originariamente Scritto da yak983
per le barzellette del giorno?
Se prima o poi saranno presenti nel mix

yak983
24.08.2012, 08.14
per le barzellette del giorno?

viking2010
24.08.2012, 08.09
Citazione Originariamente Scritto da yak983
la vedo dura... ascotlc non è presente al MIX di Milano

http://www.mix-it.net/index.php?opti...mid=84&lang=en
Bella rogna Proverò a sentire AscoTLC.

yak983
23.08.2012, 16.48
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, 16.44
Potreste procedere con il peering verso AscolTLC?

yak983
23.05.2012, 18.02
da quello che so TISCALI non ha peering al MIX praticamente con nessuno.
Cercano di vendere il loro IP Transit

torpado
11.05.2012, 10.29
Citazione Originariamente Scritto da tormento
Novità?
Siamo in contatto ed in attesa di risposta da parte di Tiscali

tormento
11.05.2012, 08.46
Citazione Originariamente Scritto da tmit
Dovremmo contattare Tiscali e richiedere un peering al MIX con OVH...
Avviso
Novità?

tormento
18.04.2012, 07.43
Grazie mille.

tmit
17.04.2012, 12.09
Dovremmo contattare Tiscali e richiedere un peering al MIX con OVH...
Avviso

tormento
17.04.2012, 08.18
TMIT, riesci a far qualcosa per Tiscali?

tormento
05.04.2012, 08.04
Citazione 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]

tmit
02.01.2012, 16.29
Citazione Originariamente Scritto da viking2010
errore
Non capisco questo post... Potresti rispondere in "verbose" mode?

viking2010
01.01.2012, 18.19
errore

viking2010
23.12.2011, 14.26
Citazione 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, 18.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, 16.45
Citazione 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

tmit
23.11.2011, 16.05
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, 15.50
Citazione 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?

tmit
23.11.2011, 15.22
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, 15.06
Citazione 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?

tmit
23.11.2011, 14.49
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, 14.36
Quindi ogni ISP italiano deve accordarsi con voi per transitare tramite l'accesso MIX-->OVH?

tmit
23.11.2011, 14.34
E4A AS34695 (IT) -> TINET AS3257 (DE) -> TINET AS3257 (DE) -> Global Crossing GBLX (Amsterdam) -> OVH AS16276 (Roubaix)

viking2010
23.11.2011, 14.24
Citazione Originariamente Scritto da tmit
Perchè non abbiamo l'interconnessione con questo ISP.
E quindi passa x Amsterdam?!

tmit
23.11.2011, 14.21
Citazione Originariamente Scritto da viking2010
Come mai?
Perchè non abbiamo l'interconnessione con questo ISP.

viking2010
23.11.2011, 14.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?

tmit
23.11.2011, 13.44
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, 13.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?

tmit
23.11.2011, 11.53
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, 11.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?

tmit
23.11.2011, 11.38
Citazione Originariamente Scritto da viking2010
Cmq o hai la fibra ottica o l'ADSL
Svista mia Sorry

viking2010
23.11.2011, 11.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

tmit
23.11.2011, 09.24
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, 09.16
pftech grazie della spiegazione

pftech
23.11.2011, 06.58
Citazione 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, 08.44
Per me sono delle impostazioni dei router invece. Tutti i collegamenti sono in fibra.

pftech
21.11.2011, 06.51
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, 14.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, 14.35
Il nodo del mix di Milano comincia ad essere un pò carico:

http://i39.tinypic.com/wspiya.jpg

pftech
02.11.2011, 06.38
Citazione Originariamente Scritto da viking2010
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

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, 19.56
Citazione 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, 16.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, 18.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, 08.07
Citazione 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.

pftech
29.10.2011, 06.28
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, 07.06
Grazie, ora mi è tutto più chiaro.

Ciao.

viking2010
23.10.2011, 19.55
Per quanto riguarda Telecom Italia il traffico passa per il seabone, per il resto passa per il mix...

gen_patton
22.10.2011, 07.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, 00.15
Intendo il link Mix<-->Mil-1-6k

gen_patton
20.10.2011, 08.06
Intendi i link Ovh<->Mix o il Mix come infrastruttura?
Grazie

viking2010
19.10.2011, 21.07
Il mix è sempre + carico...rischio...

tmit
18.10.2011, 09.10
L'attuale connettività è la seguente:
http://weathermap.ovh.net/milan

gen_patton
16.10.2011, 09.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.