Le Blog Oxymium

2010-08-03: Plage d'IPv6

Nous venons de recevoir la plage d'iPv6: 2a02:2218::/32
Dans les 3 prochains mois notre réseau fonctionnera completement en dual-stack IPv4 et IPv6.

2010-07-01: Installation à Equinix Saint-Denis PA3

Afin de pouvoir faire face aux nouvelles demandes d'hébergement, nous avons pris un espace privatif dans le datacenter Equinix (PA3) à Saint-Denis.

Cet espace nous permet un hébergement de plus forte densité et chaque baie bénéficie d'une double arrivée électrique.

Nos espaces de Equinix et Telehouse 2 seront reliés par une double paire de fibres dans le courrant de l'été.
Cette double adduction qui assurera une connectivité redondée. Ces fibres emprunteront des chemins différents.

2010-07-01: Mise en place Dual Feed électrique sur Telehouse 2

Nous avons fait mettre en place une 2ème arrivée électrique dans notre salle à Telehouse 2.
Cette 2ème arrivée électrique est issue d'une chaîne d'onduleurs et de générateurs indépendants de la 1ère.

Elle nous permet de sécuriser encore plus nos installations, l'interruption d'une arrivée électrique n'impactant pas les équipements branchés sur les 2 arrivées.

Nous allons progressivement passer l'intégralité de notre coeur de réseau en double alimentation ainsi que la plupart de nos serveurs (Mails, DNS, etc...)

Les clients hébergés chez nous peuvent également profiter de cette double alimentation (nous contacter à commercial AT oxymium DOT net).

2009-12-19: Problème sur les appels entrants

Un problème sur les équipement de l'un de nos fournisseurs de téléphonie s'est produit vendredi 19/12 entre 9h05 et 14h52.
Le problème est, semble-t-il, lié aux firmwares des équipements.
Les appels entrant ont été perturbés entre 9h05 et 12h56 puis entre 13h29 et 14h52.
Les appels sortants n'ont pas été impactés: ils ont été routé automatiquement vers un 2eme fournisseur (ce que nous ne pouvons hélas pas faire pour les appels entrants).

Connection à un nouveau point d'écahnge: Equinix paris

Depuis le 10 décembre dernier, Oxymium est connecté au point d'échange Equinix Paris. Cet IX nous permet (comme le Panap, le Sfinx ou le PouIX auxquels nous sommes déjà relié) d'échanger directement du traffic avec un nombre important de réseau et donc de faire bénéficier nos clients de temps de latence amélioré et une plus grande redondance des routes.

La liste complete de nos accords de peering

2009-09-01: Ajout de ram sur UWEB3

Nous allons proceder à l'ajout de mémoire sur le serveur 'uweb3' vers 20h ce 08/08/2008.
Cette intervention entrainera une interruption de service d'une 20aine de minutes.

Photos de vacances

Enfin non, simplement une photo des cables arrivant notre salle à Telehouse 2 :-)



Des fibres, des cables en cuivre venant d'un peu partout !


Tiens la caméra de surveillance nous montre une livraison de routeurs:


Au moindre mouvement nous sommes avertis !

2009-06-23: Doublement des quotas boites mail

Nous avons doublé les quotas standards des boites mails.
Cela vous permettra de passer de bonnes vacances sans avoir à relever votre courrier tous les 3 jours !

2009-06-02: Problemes SMTP, POP et IMAP

Nous avons des problemes intermittant au niveau de l'authentification des connections SMTP, POP et IMAP ce 02/06 entre 6h13 et 8h53.
Le problème est venu d'un des serveurs ldap qui ne repondait plus à toutes les requêtes sans pour autant être totalement mort.
Nous avons identifié la cause du problème et cela ne devrait plus se reproduire

2009-05-21: Redemarrage serveur d'admin

Nous avons du redemarrer physiquement l'un de nos serveurs d'administration (uadm1) suite à un problème de mémoire non corrigé par l'ECC.
L'interface de gestion des comptes a été indisponibles et les graphes de bande-passante ont été impactés.

2009-05-15 Redemarrage serveur Web

Suite a des problemes de gestion des logs et de connections FTP nous avons redemarré un serveur web à 11h35. Rétablissement total à 11h43

2009-02-11 Upgrade FTP sur un serveur web

Suite a un des plnatage lors de certains commande nous allons upgrader le service FTP sur le serveur web concerné.

Probleme de liaison Cogent/Sprint

Depuis le 30/10 vers 20h les réseaux Sprint et Cogent ne communiquent plus.

Concrètement, les réseaux qui n'ont comme fournisseur de transit que Sprint ne voient plus les réseaux qui n'ont comme fournisseur de transit que Cogent.

Cela n'a pas d'impact pour nous et nos clients: Sprint est joignable par notre fournisseur de Transit Typhon et Cogent est joignable en direct.

C'est une nouvelle péripétie de la guerre que se livrent les opérateurs 'Tiers 1' (et ceux qui se veulent Tiers 1).

Cogent a indiqué que Sprint avait coupé les liaisons entre leurs réseaux et Sprint indique qu'effectivement ils ont coupé car Cogent ne répondait plus aux criteres de leurs accords de liaison de 2006.

Il semble que le traffic Cogent vers Sprint soit plus important que l'inverse (Sprint vers Cogent): en très gros: les clients de sprint envoient des requêtes vers les clients de Cogent (faible traffic) et les clients de Cogent envoient le contenu demandé (traffic plus important).
Sprint estime sans doute que Cogent doit le payer pour accéder à son réseau et à ses clients tandis que Cogent estime que non.

Ces 2 réseaux n'achetant officiellement pas de transit, il n'y a pas de chemin alternatif.

Comment cela va finir ? En gros celui qui va céder le premier va perdre la manche. Cogent ne peut pas trop se permettre de céder car il court dans ce cas le risque de se voir de-peerer par d'autres réseaux qui lui reprochent ses tarifs agressifs. Sprint a probablement plus de latitude. Cela dit quand la liaison sera rétablit on ne saura sans doute pas qui des deux a gagné ou perdu; le communiqué de presse sera: "Cogent et Sprint ont trouvé un accord; blabla, blabla...". Les termes dudit accords seront confidentiels...
Cela dit, les 'perdants' sont déja connus: les clients mono-homé de Sprint et Cogent...

Morale de l'histoire: ne jamais être mono-homé chez un "Tier 1": vu la guerre en cours depuis plusieurs années, c'est l'assurance d'être un jour ou l'autre (voire régulierement) coupé d'une partie d'Internet.

Plus d'informations techniques:
Blog Renesys

Si vous êtes mono-homé chez Sprint ou Cogent et présent à Telehouse 2 Paris, n'hésitez pas à nous contacter: nous avons des offres de transit backup ou principale intéressantes !

2008-10-05: Intervention réseau

L'un de nos transits a programmé une mise à jour réseau le dimanche 5/10/2008 entre 4h et 5 du matin: 2 interruptions de 1 à 2 minutes chacune devraient avoir lieu.

Impact attendu: Aucun, le second transit assurant la continuité.

Bon courage leur équipe !
Nous surveillerons de notre coté le bon fonctionnement du réseau.

Préparation upgrade transit

Nous allons upgrader le lien Cogent de 100Mbps à 1Gps dans les prochains jours.
Impact attendu: aucun.

Changement d'adresse

Nouveau siège social:
10 rue Rochambeau
75009 Paris

Adresse pour la correspondance:
4 rue Auguste Gillot
93200 Saint-Denis

Les coordonnées téléphoniques ne changent pas.

Incident Telehouse2

Un incident semble-t-il important a impacté Telehouse2 ce 18/04/2008.

Il a engendré pour nous une perte partielle de connectivité de quelques secondes entre 15:13:44 et 15:14:54.

Nous attendons un compte-rendu d'incident....

Anti-Spam: toujours plus !

Une partie du week-end a été consacré à l'amélioration des systèmes en place, notament pour supporter la charge et à l'étude de nouvelles possibilités pour filtrer encore mieux le spam...

Une piste est la collecte des scores après le passage dans spamassassin afin de detecter les machines windows ayant une IP dynamiques et n'envoyant que du spam.

Ces 3 criteres réunis désignent très probablement une machine zombie (à savoir une machine infectée dans le but d'envoyer du spam).

On va regarder ce que la collecte d'infos donne et si c'est concluant, on mettra en place des filtres basé dessus....

Nouveau peering: DailyMotion

Vu qu'on a un peu de traffic avec eux, autant avoir une liaison assez directe !

La liste complete de nos peering est ici

Service Mail: Tuning du test reverse DNS

Auparavant, les mails provenant d'un serveur sans reverse dns étaient rejetés temporairement. Le serveur devant les représenter ultérieurement (en géneral pendant 3 à 5 jours).
Pendant ce laps de temps, l'émeteur n'était pas forcement prévenu du probleme par son serveur (ou celui de son prestataire).
Maintenant, si un serveur émeteur est connu comme n'ayant pas de reverse DNS sur les 3 derniers jours, le rejet est permanent et l'emeteur devrait être informé par son serveur (ou celui de son prestataire).

Plus d'info ici