OVHcloud Network Status

Current status
Legend
  • Operational
  • Degraded performance
  • Partial Outage
  • Major Outage
  • Under maintenance
vss-5b-6k RBX4
Scheduled Maintenance Report for Network & Infrastructure
Completed
Nous avons un probleme bizarre sur le routeur. Les ports
10G se coupent progressivement sur le routeur puis reviennent
sans aucune cause apparamente. Pas de CRC, pas de probleme
sur les liens. Et un peu près tous les liens sur chaque
cartes.

La consequence est qu'il doit y avoir de petites coupures
dans le service par ici et par là car les coupures sont
de quelques secondes, pas assez pourque le BGP/OSPF/HSRP/GLBP
se recalcule

Update(s):

Date: 2011-10-02 22:58:38 UTC
le CPU des routeurs sur les 2 derniers jours. \"ça va mieux\"(c)

----9999999999999999999999999999999999999999999999999999999999999999999999
----9999999999999999999999999999999999999999999999999999999999999999999999
100-******************#*#*************************************************
-90-******************###*************************************************
-80-*********#*##*########***#********************************************
-70-*******#####################*######***********************************
-60-****#*##############################**********************************
-50-****#################################*******######*#******************
-40-######################################################################
-30-######################################################################
-20-######################################################################
-10-######################################################################
...0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
.............0....5....0....5....0....5....0....5....0....5....0....5....0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%


Date: 2011-10-02 22:46:04 UTC
erreur humain de configuration sur le reseau:
46.105.116.0/24
46.105.117.0/24
46.105.118.0/24
46.105.119.0/24
176.31.226.0/24
176.31.227.0/24

on met ça sur le compte de la fatigue de l'équipe.
ça fait 48H qu'on est sur le task :(




Date: 2011-10-02 21:36:53 UTC
Suite à la mise en place de port channel en statique
les routeurs sont stable et ne chargent pas. on tourne
à 30% du CPU.

nous avons maintenant l'attaque dans les reseaux au
cul du routeur et on va donc bosser pour identifier
la cible de l'attaque puis la bloquer en amont.

Date: 2011-10-02 17:23:19 UTC
Il y a quelques jours nous avons renforcé la securité
sur nos routeurs pour eviter de se faire attaquer les
infrastructures. On vient de remarquer que notre
systeme de surveillance a detecté une attaque depuis
un certain temps qui a pour destination un routeur
chez ovh. Comment c'est possible ? Une erreur de frappe
dans les protections. On vient de corriger. C'est donc
bloqué maintenant et on a vient d'avoir une belle
preuvre que c'est bien les attaques qui sont à
l'origine du probleme qu'on recontre depuis quelques
jours:

http://travaux.ovh.net/?do=details&id=5808
http://travaux.ovh.net/?do=details&id=5841

En regardant les graphes, on a remarqué qu'on se
prend environ 5Gbps de trafic.

http://yfrog.com/z/nxxpbbsj
http://yfrog.com/z/nwr8ejwj
http://yfrog.com/z/kjwq0bej

Le plus simple est de nous envoyer l'email sur
noc@ovh.net avec l'origine du probleme ..

Date: 2011-10-02 15:37:15 UTC
Le routeur retrouvera la stabilitée dés que les ports
s'arreteront de flapper. sans ça c'est pas possible.
n'importe quoi.

Date: 2011-10-02 15:33:26 UTC
On a modifié le parametrage HSRP/GLBP pour eviter
que le routeur part en couille quand les ports
flap.

Date: 2011-10-02 15:21:28 UTC
Le fait de passer sur un autre type de port channel
semble fixer le probleme de flap. On attaque donc
ce changement avec les switchs au cul du routeur.

Date: 2011-10-02 15:15:27 UTC
On deactive flowcontrol sur les ports du routeur (conf par défaut)

Date: 2011-10-02 14:41:06 UTC
on change le type de port channel sur les uplinks
de 2 routeurs.

Date: 2011-10-02 14:23:37 UTC
Nous syncronisons les configurations entre les 2
routeurs puis on relance la machine d'ip failover.

le routeur semble d'être stable mais on a eu encore
un flap sur vss-5b et tiens un flap sur vss-5a ...
au secours;

Date: 2011-10-02 14:09:30 UTC
basculement fait.

Date: 2011-10-02 13:55:10 UTC
Nous avons ajouté une nouvelle carte 6704 et
on va basculer quelques ports qui flappent
sur cette nouvelle carte.

Date: 2011-10-02 13:18:19 UTC
On a ouvert un ticket TAC chez Cisco pour comprendre
d'où vient le probleme.

En paralelle on bascule la configuration du A vers le
meme type que le B. Il y a pour 1h30 de boulot. Allez.

Date: 2011-10-02 13:09:09 UTC
On reallume les ports de serveurs 100M

Date: 2011-10-02 13:03:16 UTC
c'est fait et nous avons à nouveau les ports qui flappent.
mais c'est quoi ce truc ???

Date: 2011-10-02 12:49:55 UTC
ça respire.

on va voir si l'attaque a été sur ipv6 ou pas

nous avons mis en place
http://travaux.ovh.net/?do=details&id=5853

et on va reactiver ipv6 sur vss-5b

Date: 2011-10-02 12:14:31 UTC
c'est fait

Date: 2011-10-02 12:11:03 UTC
on va desactiver ipv6 sur le vss-5b

Date: 2011-10-02 12:06:23 UTC
C'est fait. Tous les serveurs 100M sont uniquement sur le vss-5A.
le vss-5B respire et vss-5A ça va. le changement est que l'IP
du routeur de chaque subnet est down. Peut etre l'attaque est
orienté vers cette IP ?

on donne quelques 20 minutes au B pour voir si les ports flap ou
pas. Si ça ne flap plus, alors c'est tout vu, on bascule tout ça
sur vss-6B.

Date: 2011-10-02 11:57:56 UTC
On prepare la migration de tous les serveurs 100Mbps
de vss-5AB vers le nouveau vss-6AB.

On coupe ces serveurs sur le B. A continue à router.
On va recabler les ports de vss-5B sur vss-6B puis
reactiver le routage sur vss-6B avec ses ip failover.

Date: 2011-10-02 11:46:01 UTC
On pense que le probleme de port vient du fait que
la LACP tombe parce que le routeur est surchargé.
Mais pourquoi B uniquement et pas A.

On a coupé l'un des 3 route reflector sur A et B

Date: 2011-10-02 11:39:17 UTC
B fait

on attaque la même chose sur le A.

en suite on remet l'usine de ip failover pour executer
tout ce qui est en attente.

Date: 2011-10-02 10:32:13 UTC
on va changer la maniere de configurer les serveurs
sur le routeur pour retrouver une configuration de
RBX1/2/3

Date: 2011-10-02 09:34:11 UTC
On a pris 6 liens 10G qui ont flappé depuis 1 heure
et on reverifie l'ensemble des liens pour comprendre
pourquoi ça flap

Date: 2011-10-02 09:10:40 UTC
Nous avons changé again time de l'infrastructure pour
eviter d'expirer les positions de MAC sur les ports.
Ca fixe déjà pas mal des problemes.

Date: 2011-10-02 08:16:50 UTC
Le probleme continue. L'origine du probleme n'est pas
connu pour l'instant.

Nous avons 2 problemes differents:
- sur le routeur B les ports se coupent, parfois, de maniere
inexpliqué et puis les ports reviennent up sans explication
toujours.
- les serveurs ne pingent pas bien et rien à avoir avec le
1er probleme

On a plusieurs pistes qu'on va explorer maintenant. et pour
les 2 problemes.

Date: 2011-10-02 03:42:57 UTC
nous avons remplacé la sup. le probleme continue. on a
cherché l'origine mais pas vraiment de piste.

pendant ce temps le A a vraiment du mal.

nous avons remis le trafic sur les 2 routeurs. les 2
routeurs tournent mais c'est pas le top.

on va chercher l'origine des surcharges pour savoir
quelle type d'attaque on subit. puis on reflechit en
parallele sur les coupures de ports.

Date: 2011-10-02 00:02:46 UTC
Le routeur est revenu. Mais ça va pas mieux. On va changer
la carte SUP du routeur.

Pendant ce temps là vss-5a-6k continue à router. Mais il a
du mal. On va programmer les basculements de certains
reseaux de vss-5AB vers vss-6AB pour permettre un fonctionnement
normal au vss-5AB. On a anormelement beaucoup d'attaques
qu'il faut etudier et voir de quoi il s'agit. Ca demandera
du temps et donc pendant ce temps là il faut que ça continue
à fonctionner.

Date: 2011-10-01 23:32:52 UTC
On coupe GLBP et HSRP sur le B. Il faut donner 10-15 secondes
au routeur A pour reprendre le trafic du subnet.

Date: 2011-10-01 23:12:33 UTC
On prepare le reboot.

le trafic n'arrive plus sur le routeur. vss-5a assure le routage.
ip failover ont été coupé. vss-5a assure le routage.
Posted Oct 01, 2011 - 22:48 UTC