Get webhook notifications whenever Network & Infrastructure creates an incident, updates an incident, resolves an incident or changes a component status.
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:
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: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.