OVH Community, your new community space.

Livraison 26 Octobre 2008


oles@ovh.net
30.10.2008, 13.24
Bonjour,
Il y a quelques années, nous avons mis en place les protections
de serveurs de nos clients contre les attaques venant de l'Internet.
Nous nous sommes concentrés sur les grosses attaques de 500Mbps,
1Gbps ou 4Gbps venant de plusieurs centaines, milliers de serveurs
en destination d'un serveur hébergé chez Ovh. Ce genre d'attaque
ne posait pas de problème sur les routeurs (nous avons beaucoup
de capacité entre Internet et Ovh). Par contre lorsque l'attaque
n'était pas correctement filtrée, le problème apparaissait dans
la baie du serveur victime et donc sur 40/50 serveurs voisins.

Il y a 2-3 ans, dans 99% de cas, il s'agissait de guerres entre les
bandes de hackeurs. L'une de bandes a décidé d'attaquer un serveur
dédié qui hébergé le bot IRC d'une autre bande pour récupérer
l'accès à un channel IRC et il se trouvait que le bot IRC était
hébergé chez Ovh sur un serveur dédié. Et donc lorsqu'une attaque
a été reçue sur un serveur dédié, le serveur a été suspendu et
le contrat cassé.

Depuis la mise en place de filtrage IRC (avec déblocage manuel
par le client dans le manager), et la mise en place de protection
INPUT/OUTPUT (http://travaux.ovh.com/?do=details&id=1421), nous
avons vécu un temps calme et heureux. Ceci marche très bien, car
comme décrit dans le task 1421, nous avons eu une protection par
connexion (100Mbps puis au bout de 32Mo, la connexion passe à 10Mbps)
sans aucune limitation sur la somme de toutes les connexions.
Si quelqu'un attaquait un serveur, son attaque était rapidement
limité à 10Mbps. Et 10Mbps dans pas mal de cas, n'est pas un
problème.

Aujourd'hui, nous souhaitons gérer les petites attaques de 1Mbps,
10Mbps ou 20Mbps. Ce genre d'attaque sont souvent invisibles
pour Ovh puisque notre réseau a une capacité de 400Gbps. On
ne voit pas une attaque de 1Mbps. Or ce genre de petites attaques
sont très dure à gérer pour nos clients. Souvent malgré le
peu de Mbps reçu, le client ne peut plus se connecter sur le
serveur et bloquer l'attaque sur le serveur directement. Et
même s'il arrive, il suffit d'augmenter l'attaque de 20Mbps
à 80Mbps pour que le client perde à nouveau le contrôle du
serveur.

Nous avons mis au point 4 types de protections que le client
peut ou pas activer pour protéger son serveur. Ces protections
doivent maintenant être testés avec certains d'entre vous afin
d'affiner les réglages au besoins réels de nos clients.

4 protections:
- pas de protection du tout:
le client souhaite profiter au maximum de la bande passante
qu'Ovh lui propose. Nous avons enlevé la protection du task
1421 (en bêta test).
- protection WWW:
Si le client a une activité WWW avec les sites Internet
Web 2.0, il peut profiter d'une protection active de son
serveur contre les attaques. Il s'agit de limites la bande
passante entre Internet et le serveur du client, IP par IP
et gérer cette bande passante de chaque IP de l'Internet
vers le serveur. Les visiteurs profitent pleinement des
sites et il n'y a aucune dégradation du service. Par contre
on ne peut pas utiliser le serveur pour les backups ou
transfert de gros fichiers de l'Internet vers le serveur.
Les routeurs bloquent automatiquement ce genre "d'attaque".
Si le client souhaite utiliser le serveur comme le backup,
il suffit de prendre une IP fail-over, accrocher sur le
serveur et ne pas la protéger contre les attaques. Ainsi,
l'activité principale du serveur se basant sur l'IP du
serveur est protégé et sur l'IP fail-over, le client peut
mettre les activités qui nécessitent beaucoup de bande
passante entrante.
- protection GAME:
On voit de plus en plus souvent de petites attaques entre
les joueurs qui attaquent un autre joueur pour le retarder
dans le jeux et gagner la partie ... Nous avons mis au point
une protection spécialement conçue pour les serveurs de jeux.
Mais il faut encore l'affiner.
- protection TOTALE:
si un serveur reçu une attaque importante, nos équipes doivent
intervenir sur le réseau et bloquer l'attaque de manière
rapide et efficace. Cette protection est uniquement destiné
à l'utilisation interne. Une fois la protection mise, le
serveur fonctionne correctement et le client a un total
contrôle sur le serveur. Par contre, il ne peut rien transférer
sur le serveur. Dés qu'il y a trop de packets venant de l'Internet
vers le serveur, les routeurs protègent l'infrastructure d'Ovh.

Ces protections seront rapidement disponibles dans le manager
et activable avec un simple clic.

En attendant, on cherche les bêtas testeurs pour la protection WWW
et GAME. N'hésitez pas m'écrire sur oles@ovh.net en donnant votre
identifiant (-OVH) et l'IP de votre serveur. Si vous voyez d'autres
types de protections à développer, merci de nous faire part de
vos expériences.

Amicalement
Octave


j0t
28.10.2008, 19.37
Tchèquie = Rep. Ceca

torpado
28.10.2008, 18.49
Buongiorno,
ecco lo stato delle consegne il 26/10/2008 h.23.00

Quando c'è un ritardo bisogna leggere:
"L'ordine più vecchio pagato e non realizzato in XX ore di ritardo"

Real Private Server
- RPS 1 12H de retard (2008-10-26 16:00:14)
- RPS 2 OK -> 1 ora
- RPS 3 OK -> 1 ora

Servers per scoprire e di gioco:
- Kimsufi L OK -> 1 heure
- Kimsufi XL 12H de retard (2008-10-26 05:01:41)
- Kimsufi 2XL OK -> 1 ora
- Kimsufi 3XL OK -> 1 ora
- Kimsufi 4XL OK -> 1 ora

Servers impresa, professionali e critici:
- miniSP OK -> 1 ora
- SP bestof OK -> 1 ora
- SP Max fr,es OK -> 1 ora
- SP Max de OK -> 1 ora
- SP Max uk,pl OK -> 1 ora

- EG Bestof 12H di ritardo (2008-10-26 05:12:04)
- EG Max OK -> 1 ora
- EG Large OK -> 1 ora
- EG SSD OK -> 1 ora

- MG Bestof OK -> 1 ora
- MG Max OK -> 1 ora
- MG Large OK -> 1 ora
- MG SSD OK -> 1 ora
- MG X Large OK -> 1 ora

- miniHG OK -> 1 ora
- HG Bestof 3gg di ritardo (2008-10-23 20:02:10)
- HG BiTurbo 3gg di ritardo (2008-10-23 17:53:03)
- HG Large 7gg di ritardo (2008-10-16 21:01:05)



Le consegne di RPS non sono state molto regolari questa settimana. Noi abbiamo una crescita abbastanza violenta degli ordini da 2 settimane ed abbiamo ancora difficoltà a sapere quante nuove RPS devono essere fabbricate alla settimana. Inoltre, il sistema attuale di consegna di RPS non è previsto per consegnare più di 100 RPS/giorno, a causa del "non parallelismo" delle operazioni sulle infrastrutture di archiviazione. Cambiamo dunque metodi di lavoro e in alcuni giorni si dovrebbe portare a termine l'industrializzazione dei processi che riguarda gli RPS. Lo scopo è non di pubblicare il numero di RPS disponibili ma di avere sempre lo stock necessario per consegnare a tutti i clienti, indipendentemente dalla quantità, in 1 ora. C'è il contratto.

Le consegne di Kimsufi e PRO sono realizzate senza problema, eccetto per HG. Come già annunciato, prevediamo la messa in atto di una nuova gamma HG 2009 nel mese corrente della settimana, massimo 10 giorni e nella produzione sono stati orientati verso i nuovi server presto disponibili in 1 ora. Noi lavoriamo sul sito ed il motore delle opzioni. Infatti, desideriamo proporre un server estremamente potente, molto stabile e completamente personalizzabile. In 10 giorni massimi, si avrà la risposta se andiamo nella direzione giusta.


Questa settimana, abbiamo portato a termine il 90% del backbone europeo di Ovh. Siamo presenti su Espanix a Madrid con 2x10G, sul MIX a Milano con 1x10G, sul VIX a Vienna con 1x10G, su NIX a Praga con 1x10G e stabiliamo i primi peering con le altre reti presenti su questi punti di peering e che desiderano scambiare il traffico con Ovh. Questa settimana iniziamo la TIX e SwissIX a Zurick quindi il giro di Varsavia (un pò complicato ma vi arriverà). Potete vedere la nostra rete in tempo reale sul weathermap
http://weathermap.ovh.net/europe
Si tratta del backbone basata sui 10G. Per quelli che amano prendersi la testa, c'è una versione completa con tutti i legami input/output di Ovh:
http://weathermap.ovh.net/backbone
Oggi, abbiamo equilibrato il traffico tra tutte le città affinché la rete sia ottimizzata. Il traffico tra Roubaix e Milano, passa ora correttamente Roubaix-Paris-Frankfurt-Zurick-Milan invece di roubaix-Parigi-Madrid-Milano con in finale un guadagno 30ms. Inoltre il traffico di Vienna verso Parigi, passa da Praga-Frankfurt e non più da Milan-Zurick-Frankfurt.

Ci resta qualche problema da risolvere sulla backbone:
- http://travaux.ovh.com/?do=details&id=2547
Aggiungeremo un 10G tra il router e lo switch che gestisce le interconnessioni Decix. Lo xenpack arriverà domani a Francoforte
- http://travaux.ovh.com/?do=details&id=2534

Abbiamo un problema completamente sconosciuto su Linx 224. Il flusso di alcuni clienti verso alcune reti con che hanno scambio di traffico su Linx 224, non si fa a piena velocità. Dopo le prove effettuate con alcuni clienti, abbiamo isolato Linx 224, ma Linx non ha nessun problema di saturazione interna su Linx. Dunque cambieremo tutti i giuntori in fibra ottica su tutta la nostra infrastruttura di Londra. Anche se non si ha nessuna perdita di packet, c'è qualcosa da qualche parte. Occorre cominciare dunque da qualche parte.
http://weathermap.ovh.net/london
- http://travaux.ovh.com/?do=details&id=2492
uno switch deve essere realizzato a Bruxelles/Interxion quindi un 10G collegato tra il routeur di Bruxelles e Roubaix per garantire la migliore ridondanza. Si dovrebbe realizzarlo nella settimana. Con l'arrivo di questa rete, siamo molto vicini all'avviamento di ChtiX.eu con le offerte di VLAN tra tutte le località dove siamo presenti e tutti i punti di peerings dove siamo presenti. Così, avere 100Mbps tra Parigi e Vienna costerà 100Euro IVA esclusa/mese! Inoltre le offerte di transito 100Mbps = 100Euro/mese in full BGP. Un'offerta unica disponibile ovunque in Europa.

Alcuni clienti PL e UK ci hanno comunicato un bug sulla banda occupata interna sulla nostra rete. Una parte di questo problema è risolta ma non tutto. Abbiamo infatti molte attrezzature di rete diverse ed occorre adattare il setup per ogni elemento, essendo sicuro che produca lo stesso effetto. Ci siamo resi conto che secondo l'attrezzatura i parametri devono essere diversi per avere in fine lo stesso risultato. Ecco l'origine del problema. Si spera di risolvere tutti questi problemi nella settimana (occorre molto tempo per testare tutto e per vedere il risultato in tempo reale e sui grafici MRTG/RRD).
http://travaux.ovh.com/?do=details&id=2495

Con l'arrivo del backbone Est/Sud-Est, il traffico via Frankfurt aumenterà nella settimana a venire. Infatti, Praga, Vienna, Zurick e Milano passano per Frankfurt. Dunque inizieremo i lavori della creazione del backbone in proprio di 100Gbps tra Bruxelles e Frankfurt. Questi lavori prenderanno tra 4 e 6 mesi. Si dovrebbe dunque approfittarne interamente a partire da febbraio/marzo.

Tutti questi passi e questo investimento che riguarda la rete hanno uno scopo preciso: migliorare l'accesso di tutti gli ospiti Europei sulla nostra infrastruttura. Occorre trovare i mezzi con i quali ad esempio un ospite di CZ possa consultare il vostro dominio più rapidamente e possa scambiare il traffico con i vostri siti più rapidamente. Lo scopo non è dunque di costruire la più grande rete del mondo, ma di andare verso gli ospiti più vicino a dove loro vivono e trasportare sulla nostra rete tutto il traffico. In questo modo soltanto, si potranno garantire i tempi di accesso ed i flussi, tenendo conto che tutto sommato 100km generano 1ms di tempo di accesso in più e dunque non creeremo buchi neri nell'universo per fare arrivare i pacchetti verso Ovh in altro modo. Se si osservano i risultati di questa strategia si può così interrogarsi sul senso di tutti questi passi. Prendiamo ad esempio: un peering stabilito 30 minuti fa con una grande rete in CZ. Abbiamo avuto il peering su Amsix (Amsterdam) e l' abbiamo ora su NIX (Praga). Il risultato un guadagno di 4ms. 4ms… c' è che 4ms nelle nostre vite?

64 bytes from 195.113.144.244: icmp_seq=6 ttl=58 time=21.2 ms
64 bytes from 195.113.144.244: icmp_seq=7 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=8 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=9 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=10 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=11 ttl=58 time=17.6 ms
64 bytes from 195.113.144.244: icmp_seq=12 ttl=58 time=17.5 ms
64 bytes from 195.113.144.244: icmp_seq=13 ttl=58 time=17.7 ms
64 bytes from 195.113.144.244: icmp_seq=14 ttl=58 time=17.6 ms


Hmmm… 4 ms è un accesso migliore del 20% verso una rete più estesa in Tchèquie. Quello vale il gioco di investire per migliorare del 20% gli accessi alla nostra rete? Noi non abbiamo risposte a questa domanda. In ogni caso si pensa che il cliente vedrà l'interesse di utilizzare i servizi di un provider che propone migliori collegamenti possibili in Europa e lavora costantemente sul miglioramento della sua rete allo scopo di anticipare le necessità dei suoi clienti. Non si sa di cosa sia fatto il domani ed è difficile prevedere se questo sarà o no utile. In ogni caso, se domani avete progetti in Francia, in Germania, in Polonia o Tchèquie ed avete bisogno di un collegamento di qualità, sapete dove scrivere.

Amichevolmente
Octave

g.graziosi
28.10.2008, 14.41
Ha sbagliato lingua o dobbiamo rispolverare i libri di francese noialtri?

oles@ovh.net
26.10.2008, 23.50
Bonjour,
Voici l'état de livraison à 2008-10-26 23h00.

Quand il y a un retard, il faut lire:
"la plus ancienne commande payée et non réalisée a XX heures de retard"

Real Private Server
- RPS 1 12H de retard (2008-10-26 16:00:14)
- RPS 2 OK -> 1 heure
- RPS 3 OK -> 1 heure

Serveurs pour découvrir et de jeux:
- Kimsufi L OK -> 1 heure
- Kimsufi XL 12H de retard (2008-10-26 05:01:41)
- Kimsufi 2XL OK -> 1 heure
- Kimsufi 3XL OK -> 1 heure
- Kimsufi 4XL OK -> 1 heure

Serveurs d'entreprise, professionnels et critique:
- miniSP OK -> 1 heure
- SP bestof OK -> 1 heure
- SP Max fr,es OK -> 1 heure
- SP Max de OK -> 1 heure
- SP Max uk,pl OK -> 1 heure

- EG Bestof 12H de retard (2008-10-26 05:12:04)
- EG Max OK -> 1 heure
- EG Large OK -> 1 heure
- EG SSD OK -> 1 heure

- MG Bestof OK -> 1 heure
- MG Max OK -> 1 heure
- MG Large OK -> 1 heure
- MG SSD OK -> 1 heure
- MG X Large OK -> 1 heure

- miniHG OK -> 1 heure
- HG Bestof 3J de retard (2008-10-23 20:02:10)
- HG BiTurbo 3J de retard (2008-10-23 17:53:03)
- HG Large 7J de retard (2008-10-16 21:01:05)


Les livraisons de RPS n'ont pas été très régulières cette semaine. Nous
connaissons une croissance assez violente des commandes depuis 2 semaines
et nous avons encore du mal à savoir combien de nouveaux RPS doivent
être fabriqués par semaine. Aussi, le système actuel de livraison de RPS
n'est pas prévu pour livrer plus de 100 RPS / jour, à cause du "non parallélisme"
des opérations sur les infrastructures de stockage. Nous changeons donc des
méthodes de travail et sous quelques jours on devrait finaliser l'industrialisation
des processes concernant les RPS. Le but est de ne pas afficher le nombre des
RPS disponibles mais d'avoir toujours le stock nécessaire et livrer tous
les clients, quelque soit la quantité en 1 heure. C'est le contrat.

Les livraisons de Kimsufi et PRO se font sans problème, sauf pour le HG.
Comme déjà annoncé, nous prévoyons la mise en place d'une nouvelle gamme HG 2009
courant de la semaine, maximum 10 jours et la production a été réorientée
déjà vers les nouveaux serveurs bientôt disponibles en 1 heure. Nous
travaillons sur le site et le moteur des options. En effet, on souhaite vous
proposer un serveur extrement puissant, très stable et totalement personalisable.
Sous 10 jours maximum, on aura la réponse si nous allons dans la bonne direction.

Cette semaine, nous avons finalisé 90% de la backbone Européen d'Ovh. Nous sommes
présents sur l'Espanix à Madrid avec 2x10G, sur le MIX à Milan avec 1x10G, sur le
VIX à Vienne avec 1x10G, sur NIX à Prague avec 1x10G et nous établissons les
premiers peering avec les autres réseaux présents sur ces points de peering et
qui souhaitent échanger le trafic avec Ovh. Cette semaine nous démarrons le TIX
et SwissIX à Zurick puis ça sera le tour de Varsovie (un peu compliqué mais on
va y arriver). Vous pouvez voir notre réseau en temps réel sur le weathermap
http://weathermap.ovh.net/europe
Il s'agit de la backbone basés sur les 10G. Pour ceux qui aiment bien se prendre
la tête, il y a une version complète avec tous les liens input/output d'Ovh:
http://weathermap.ovh.net/backbone
Aujourd'hui, nous avons équilibré le trafic entre toutes les villes afin que
le réseau soit optimisé. Le trafic entre Roubaix et Milan, passe maintenant
correctement Roubaix-Paris-Frankfurt-Zurick-Milan au lieu de Roubaix-Paris-Madrid-Milan
et au finale un gain 30ms. De même, le trafic de Vienne vers Paris, passe par
Prague-Frankfurt et non plus par Milan-Zurick-Frankfurt.

Il nous reste quelques problèmes à résoudre sur la backbone:
- http://travaux.ovh.com/?do=details&id=2547
Nous allons ajouter un 10G entre le routeur et le switch qui gère les
interconnexions Decix. Le xenpack va arriver demain à Frankfurt et sera
mis en place dans la foulée.
- http://travaux.ovh.com/?do=details&id=2534
Nous avons un problème totalement étrange sur Linx 224. Le débit de certains
clients vers certains réseaux avec qui ont échange le trafic sur Linx 224,
ne se fait pas à pleine vitesse. D'après les tests effectués avec certains
clients, nous avons isolé Linx 224, mais d'après Linx il n'y a aucun problème
de saturation interne sur Linx. Nous allons donc changer toutes les jarretières
en fibre optique sur toute notre infrastructure de Londrès. Même s'il n'y a
aucune perte de packet, il y a quelque chose quelque part. Il faut commencer
donc quelque part.
http://weathermap.ovh.net/london
- http://travaux.ovh.com/?do=details&id=2492
un switch doit être mis en place à Bruxelles/Interxion puis un 10G connecté
entre le routeur de Bruxelles et Roubaix afin de garantir une meilleure
redondance. On devrait le réaliser dans la semaine.

Avec l'arrivée de ce réseau, nous sommes très proche de démarrage de ChtiX.eu avec
les offres de VLAN entre tous les sites où nous sommes présents et tous les points
de peerings où nous sommes présents. Ainsi, avoir 100Mbps entre Paris et Vienne
c'est 100Euro HT/mois ! De même les offres de transit 100Mbps = 100Euro / mois en
full BGP. Une offre unique disponible partout en Europe.

Certains clients PL et UK nous ont remontés un bug sur la bande passante interne
sur notre réseau. Une partie de ce problème est résolu mais pas tout. Nous avons
en effet beaucoup des équipements réseau différents et il faut adapter le setup
pour chaque éléments, tout en étant sûr qu'il produit le même effet. Nous nous
sommes rendus compte que suivant l'équipement les paramètres doivent être
différents pour au final avoir la même chose. Voilà l'origine du problème. On
espère qu'on fixera tous ces problèmes dans la semaine (il faut beaucoup de temps
pour tout tester pour voir le résultat en temps réel et sur les graphes MRTG/RRD).
http://travaux.ovh.com/?do=details&id=2495

Avec l'arrivée de la backbone Est/Sud-Est, le trafic via le Frankfurt va augmenter
dans les semaines à venir. En effet, Prague, Vienne, Zurick et Milan passent par
Frankfurt. Nous allons donc démarrer les travaux de la création de la backbone en
propre à 100Gbps entre Bruxelles et Frankfurt. Ces travaux vont prendre entre 4 et
6 mois. On devrait donc en profiter pleinement à partir de Février/Mars.

Toutes ces démarches et ces investissement concernant le réseau ont un but précis:
améliorer l'accès de tous les visiteurs European sur notre infrastructure. Il
faut trouver le moyens que par exemple un visiteur de CZ puisse consulter vos
sites plus rapidement et puisse échanger le trafic avec vos sites plus rapidement.
Le but n'est donc pas de bâtir le plus gros réseau du monde, mais d'aller vers
les visiteurs au plus proche d'eux là où ils vivent et transporter sur notre
réseau tout le trafic. De cette manière uniquement, on pourra garantir les temps
d'accès et les débits, tout en sachant que malgré tout 100km vont générer 1ms de
temps d'accès en plus et donc on ne va pas créer de trou noir du cosmos pour
faire arriver les packets autrement vers Ovh. Si on regarde les résultats de cette
stratégie on peut aussi s'interroger sur le sens de toutes ces démarches. Prenons
exemples: un peering établit il y a 30 minutes avec un grand réseau en CZ. Nous
avons eu le peering sur Amsix (Amsterdam) et nous l'avons maintenant sur NIX (Prague).
Le résultat un gain de 4ms. 4ms ... c'est quoi 4ms dans nos vies ?

64 bytes from 195.113.144.244: icmp_seq=6 ttl=58 time=21.2 ms
64 bytes from 195.113.144.244: icmp_seq=7 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=8 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=9 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=10 ttl=58 time=21.1 ms
64 bytes from 195.113.144.244: icmp_seq=11 ttl=58 time=17.6 ms
64 bytes from 195.113.144.244: icmp_seq=12 ttl=58 time=17.5 ms
64 bytes from 195.113.144.244: icmp_seq=13 ttl=58 time=17.7 ms
64 bytes from 195.113.144.244: icmp_seq=14 ttl=58 time=17.6 ms

Hmmm ... 4 ms c'est un accès meilleur de 20% vers l'un de réseau le plus important
en Tchèquie. Est-ce que ça vaut le coup d'investir pour améliorer de 20% les accès
à notre réseau ? Nous n'avons pas de réponse à cette question. En tout cas on pense
que le client lui verra l'intérêt d'utiliser les services d'un hébergeur qui propose
des meilleurs connexions possible en Europe et travaillent constamment sur l'amélioration
son réseau dans le but d'anticiper les besoins de ses clients. On ne sait pas de
quoi est fait demain et il est difficile de prévoir si ceci vous sera ou pas utile.
En tout cas, si demain vous avez des projets en France, en Allemagne, en Pologne ou
Tchèquie et vous avez besoins d'une connexion de qualité, vous savez où taper.

Amicalement
Octave