[torpado]

Ora il problema sembra risolto, il ticket era il numero 1054488, può essere che i pacchetti arrivino o no a seconda se il monitoring sull'ip è acceso o no? Perchè dal ticket non vedo altra modifica.

Ho verificato il ticket ed il problema era legato al filtro del traffico applicato sia su ip principale che su ip failover.
Il filtro è stato applicato a seguito di un attacco entrante.

Il messaggio di sblocco del filtro arriva via email a partire dal sistema di monitoring.

[alex88]

Mi indichi gentilmente il numero di ticket in modo da verificare questo problema?

grazie

Ora il problema sembra risolto, il ticket era il numero 1054488, può essere che i pacchetti arrivino o no a seconda se il monitoring sull'ip è acceso o no? Perchè dal ticket non vedo altra modifica.

[torpado]

Purtroppo no, ha scritto così, ha disabilitato il monitoring per quel indirizzo IP e basta, nessun altra risposta.
Nel mentre si è bruciato l'alimentatore del server, viene cambiato in un ora (su questo non mi posso lamentare, anzi), finito l'intervento mi dice che è stato cambiato l'alimentatore e che l'intervento è concluso, allora scrivo "Thanks about that, what about the failover ip?" e risponde:

 Dear Customer,

About which ip you are talking about?

Best Regards,
Meryam

Cioè, ci son almeno 10 messaggi di conversazione e ti devo tornare a spiegare perchè ho aperto il ticket?
Quindi, per l'ennesima volta, gli dico, leggiti i traceroute, c'è qualcosa che non va, torna a abilitare/disabilitare il monitoring per l'ip failover e del server e mi lascia così...

Nel mentre ho comunque preso un altro ip in modo da avere il servizio online per tutti, fortuna che cambiamo provider in un mesetto...

Mi indichi gentilmente il numero di ticket in modo da verificare questo problema?

grazie

[alex88]

Purtroppo no, ha scritto così, ha disabilitato il monitoring per quel indirizzo IP e basta, nessun altra risposta.
Nel mentre si è bruciato l'alimentatore del server, viene cambiato in un ora (su questo non mi posso lamentare, anzi), finito l'intervento mi dice che è stato cambiato l'alimentatore e che l'intervento è concluso, allora scrivo "Thanks about that, what about the failover ip?" e risponde:

 Dear Customer,

About which ip you are talking about?

Best Regards,
Meryam

Cioè, ci son almeno 10 messaggi di conversazione e ti devo tornare a spiegare perchè ho aperto il ticket?
Quindi, per l'ennesima volta, gli dico, leggiti i traceroute, c'è qualcosa che non va, torna a abilitare/disabilitare il monitoring per l'ip failover e del server e mi lascia così...

Nel mentre ho comunque preso un altro ip in modo da avere il servizio online per tutti, fortuna che cambiamo provider in un mesetto...

[Raziel]

Dopo altri giorni senza risposta, faccio richiesta di cambio tecnico e finalmente:

Dear customer,

I have noticed the problem

I will perform necessary corrections and we will keep
you informed

alla buon ora.. Mi chiedo, se lo stesso ip failover fosse capitato ad un utente con server professionali, sarebbe cambiato qualcosa?

Grande scivolone per OVH che di certo non ne esce bene...
Sono contento comunque che dopo mille peripezie tu sia riuscito a risolvere i tuoi problemi

[alex88]

Dopo altri giorni senza risposta, faccio richiesta di cambio tecnico e finalmente:

Dear customer,

I have noticed the problem

I will perform necessary corrections and we will keep
you informed

alla buon ora.. Mi chiedo, se lo stesso ip failover fosse capitato ad un utente con server professionali, sarebbe cambiato qualcosa?

[alex88]

Dopo una settimana il router è riparato, ma i pacchetti si fermano ancora li, la settimana scorsa il supporto ovh si è collegato la mio server per un incidente aperto dal mio collega e ha eliminato il bridge di rete su cui erano collegate tutte le vm causando l'interruzione di tutti i nostri servizi.
Oltre a quello che vabbé, non sapendo com'è impostato un server può passare, il problema dei pacchetti che non raggiungono l'europa persiste e continuano a voler controllare la configurazione del nostro server (che è corretta e funziona da tutto il resto del mondo).

[alex88]

Come non detto, era un incidente noto http://travaux.ovh.net/?do=details&id=6882

[alex88]

Ancora nessuna risposta dal support. Niente di che meravigliarsi. Ho contattato anche Cloudflare e Telehouse America visto che con Cloudflare alcuni utenti che utilizzano new york come nodo non riescono ad accedere all'ip, altri utenti non riescono ad accedere all'ip se nel loro route ci sono i router di Telehouse America a NY.
Entrambe hanno confermato che è un problema di OVH (la quale non risponde).

Altro traceroute fornito da Telehouse America:

traceroute to 94.23.70.x (94.23.70.x), 20 hops max, 60 byte packets
  1  207.99.1.13 (207.99.1.13)	7.611 ms  7.612 ms  7.646 ms
  2  207.99.53.41 (207.99.53.41)  0.526 ms  0.576 ms  0.588 ms
  3  vlan801.tbr1.mmu.nac.net (209.123.10.9)  0.307 ms  0.327 ms  0.385 ms
  4  0.e1-1.tbr1.tl9.nac.net (209.123.10.102)  1.299 ms  1.335 ms  1.403 ms
  5  0.e2-1.pr2.tl9.nac.net (209.123.11.142)  1.329 ms  1.384 ms  1.410 ms
  6  nyiix.nyc.ny.us (198.32.160.77)  1.583 ms * *
  7  * * *
  8  * * *
  9  * * *
 10  * * *
 11  * * *
 12  * * *
 13  * * *
 14  * * *
 15  * * *
 16  * * *
 17  * * *
 18  * * *
 19  * * *
 20  * * *

[alex88]

Update, aperto un ticket, risposta:

The routing of the ip failover is correct:
--- Traceroute fatto internamente all'europa ---

Would you check the configuration of this IP.

So that I can respond as quickly as possible, would you
refer to this guide:

http://help.ovh.co.uk/InstallOvhKey

and take steps so that I can use our key.

If you use a port other than 22 for
ssh connections, it must be stated.
If you use a firewall / iptables, you must unlock
OVH ips:  http://help.ovh.co.uk/Firewall


Best Regards,
Celine S

secondo voi può essere un problema della configurazione del mio server se i pacchetti non passano l'oceano?

[alex88]

Salve a tutti,

son un paio di giorni che ho dei problemi verso tarda serata su un ip failover 94.23.70.x, un mio amico da Tucson, AZ dava il sito hostato su quel ip come irraggiungibile, mentre altri siti hostati su un altro ip failover che reindirizza alla stessa macchina funzionavano perfettamente. Questo era il suo traceroute:

1 *10.0.1.1 (10.0.1.1) *1.722 ms *1.045 ms *1.065 ms
 2 *96.120.59.129 (96.120.59.129) *11.546 ms *11.191 ms *44.641 ms
 3 *te-7-3-ur01.snyder.az.pima.comcast.net (69.139.177.145) *17.107 ms *9.968 ms *9.990 ms
 4 *te-9-3-ar02.pimaco.az.pima.comcast.net (68.87.172.45) *10.043 ms *27.421 ms *38.327 ms
 5 *te-0-0-0-5-cr01.losangeles.ca.ibone.comcast.net (68.86.95.101) *30.966 ms *27.540 ms *23.986 ms
 6 *as3549-5.losangeles.ca.ibone.comcast.net (66.208.233.206) *20.650 ms *22.194 ms *24.495 ms
 7 *nyk-1-6k.ny.us (178.32.135.29) *117.635 ms * *105.288 ms
 8 ** * *
 9 ** * *
10 ** * *
11 ** * *
12 ** * *
13 ** * *
14 ** * *
15 ** * *
16 ** * *
17 ** * *
18 ** * *
19 ** * *
20 ** * *
... ecc ecc fino a 64

mentre sull'altro ip failover che funziona correttamente è:

1 *10.0.1.1 (10.0.1.1) *2.605 ms *1.079 ms *1.007 ms
 2 *96.120.59.129 (96.120.59.129) *11.286 ms *10.449 ms *8.119 ms
 3 *te-9-3-ur01.snyder.az.pima.comcast.net (69.139.177.149) *11.925 ms *10.091 ms *9.404 ms
 4 *te-9-3-ar02.pimaco.az.pima.comcast.net (68.87.172.45) *10.246 ms *10.738 ms *9.850 ms
 5 *te-0-0-0-5-cr01.losangeles.ca.ibone.comcast.net (68.86.95.101) *32.959 ms *22.654 ms *35.295 ms
 6 *as3549-4.losangeles.ca.ibone.comcast.net (66.208.233.210) *21.179 ms *22.484 ms *119.600 ms
 7 *nyk-1-6k.ny.us (178.32.135.29) *90.557 ms *91.344 ms *89.653 ms
 8 *178.32.135.59 (178.32.135.59) *124.882 ms *92.028 ms *91.674 ms
 9 *178.32.135.218 (178.32.135.218) *107.771 ms * *
10 *178.33.100.235 (178.33.100.235) *160.443 ms * *
11 *rbx-g1-a9.fr.eu (91.121.215.141) *164.319 ms *164.898 ms *165.865 ms
12 *nostroip (nostroip) *165.181 ms *168.098 ms *164.334 ms

Da google ho vistro che nyk-1-6k.ny.us è un vostro router ovh, corretto? E' possibile verificare se ci sono problemi? Perchè son due giorni che da qualche parte degli usa durante il giorno ci sono delle interruzioni.
Anche http://www.downforeveryoneorjustme.com/ lo dava off mentre http://loads.in/ lo caricava, quindi è un problema di alcuni.