Pages: 1 2 3 4 [5] 6   En bas

Auteur Sujet: 13 octobre 2021: OVH totalement inaccessible en IPv4 (ok en IPv6)  (Lu 17339 fois)

0 Membres et 1 Invité sur ce sujet

aplufr

  • Abonné Sosh fibre
  • *
  • Messages: 15
    • APLU
OVH dans le noir (13 octobre 2021)
« Réponse #48 le: 13 octobre 2021 à 13:43:48 »
Citation de: madmass le 13 octobre 2021 à 12:00:52
Y'a ce tweet (supprimé) de Klaba qui tourne apparemment



Je confirme avoir vu ce tweet, je n’ai pas eu le temps faire une capture..
IP archivée

dj54

  • Abonné Free fibre
  • *
  • Messages: 924
  • Nancy (54)
    • La passion des ondes
OVH dans le noir (13 octobre 2021)
« Réponse #49 le: 13 octobre 2021 à 13:45:10 »
Comment OVH peut accepter ça ils devrait faire des routes indépendante entre les US et UE
le serveur est en France et la connexion aussi mais non il faut que ça passe par les USA
il va falloir corrigé ça
IP archivée

FloBaoti

  • Abonné MilkyWan
  • *
  • Messages: 1 300
  • 34
13 octobre 2021: OVH totalement inaccessible en IPv4 (ok en IPv6)
« Réponse #50 le: 13 octobre 2021 à 13:50:12 »
c'est justement le problème qu'il y a eu que tout était envoyé sur un DC aux US, en temps normal c'est pas le cas !
IP archivée

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 943
  • Delta S 10G-EPON sur Les Ulis (91)
OVH dans le noir (13 octobre 2021)
« Réponse #51 le: 13 octobre 2021 à 13:59:40 »
Citation de: madmass le 13 octobre 2021 à 12:00:52
Y'a ce tweet (supprimé) de Klaba qui tourne apparemment

Voilà une explication claire. Comme quoi une petite erreur de manip peut avoir de grosses conséquences, et qui ressemble beaucoup à ce qui s'est passé pour Facebook.
IP archivée

testing5555

  • Abonné Bbox fibre
  • *
  • Messages: 595
  • Lyon 3 (69)
13 octobre 2021: OVH totalement inaccessible en IPv4 (ok en IPv6)
« Réponse #52 le: 13 octobre 2021 à 14:04:38 »
C'est bizarre mon kimsufi est resté dispo quasi tout le temps depuis ma box SFR (qui est ipv4 only), alors que depuis orange il était bien inaccessible (et apparemment aussi bien en v4 qu'en v6)

IP archivée

mirtouf

  • Abonné Bbox fibre
  • *
  • Messages: 1 314
  • Chelles (77)
    • L'antre de la bête
OVH dans le noir (13 octobre 2021)
« Réponse #53 le: 13 octobre 2021 à 21:32:43 »
Citation de: vivien le 13 octobre 2021 à 12:58:45
Il y a plein de truc qui restent en IPv4 et c'est eux qui vont poser problème dans quelques années, quand n cherchera a éteindre IPv4.


Ah ouais, comme même...
IP archivée

Sn@ke

  • Officiel nPerf.com
  • Professionnel des télécoms
  • *
  • Messages: 566
  • Lyon (69)
    • nPerf
13 octobre 2021: OVH totalement inaccessible en IPv4 (ok en IPv6)
« Réponse #54 le: 14 octobre 2021 à 07:28:05 »
Le post-mortem :

For weeks we are experiencing heavy DDoS attacks which are being mitigated every day.

In order to improve our defense mechanisms, we have been continuously improving our configurations to keep on enhancing the level of protection we provide to our customers.

A change had been prepared and validated by our Change Advisory Board (CAB) with the right Method of Procedures (MOP) & peer reviewed (announced on 2021-10-12 at 16:28 CET)
http://travaux.ovh.net/?do=details&id=53785

2021-10-13 09:05 CET - The scheduled change is started as expected with a window (http://travaux.ovh.net/?do=details&id=53785)
2021-10-13 09:18 CET - The change actions are being processed as expected (BGP isolation, changes, configuration updates)
2021-10-13 09:20 CET - During the route-map modification, an Issue occurred : router didn't take the last digit in the entry. The route-map aimed at redistributing BGPv4 into OSPF. All IPv6 traffic were accessible.
2021-10-13 09:21 CET - The team detected an issue on the router behavior & escalated immediately
2021-10-13 09:25 CET - Beginning of the crisis management process, in full compliance with our implemented procedures (the lag between the crisis is due to the buffer we take for the convergence time)
2021-10-13 09:30 CET - The rollback procedure didn't work so we took the decision to shut down physically the related device & requested an onsite assistance to do so
2021-10-13 09:45 CET - DC Team is joining the telco room in order to launch the mitigation plan 2
2021-10-13 10:00 CET - DC technician kicks-off operations in the telco room (3:00 am local time)
2021-10-13 10:02 CET - First request was initially to unplug the optical equipment in order to isolate the connectivity & get the service backed-up
2021-10-13 10:10 CET - Finally we took the decision to power off the faulty router
2021-10-13 10:18 CET- The faulty device is shutdown (It takes 2min for convergence)
2021-10-13 10:20 CET - First services restored
2021-10-13 10:30 CET - Stabilization of the connectivity in order to restore all the remaining services
2021-10-13 10:57 CET - End of the crisis from a technical perspective
2021-10-13 10:30 CET - Ongoing actions in order finalize & sanity check our network & finalize to restore some remaining non-blocking services (Travaux tasks will be following up on the actions)

OVHcloud operates a global backbone reaching all continents. To ensure the best reach possible to its customers the backbone is fully meshed.
• By nature this mesh means that all the routers participating in the backbone are directly or indirectly connected to one another and constantly exchanging routing information.

During the outage, the full Internet routing table was being announced in the OVHcloud IGP. The massive influx of routing information on the IGP led some routers to miss behave : OSPF table got full, overloading RAM and CPU. The impact was the IPv4 routing only and all IPv6 traffic were accessible.

Our newer routers started to use D2 VIN as the default gateway for all the internet traffic, hence causing the traffic to flow to the US. This led to an unability to process the traffic properly for IPv4 on all our sites.

We were able to take back control over the situation very quickly with the access to the physical faulty equipment and isolate it from the network.
(Once the D2 was put offline the network reconverged, emptying the OSPF tables on the devices and routing traffic to the nominal gateways).

Our immediate actions is to re-assess our validation procedure on such type of devices (which applies and commits the command line natively) & reinforces accordingly the change process.

As this incident impacted our customers using IPv4 protocol, our teams across the globe have been following the situation as closely as can be, to help them recover and keep them up to date.

We sincerely apologize for the inconvenience.
IP archivée

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 943
  • Delta S 10G-EPON sur Les Ulis (91)
OVH dans le noir (13 octobre 2021)
« Réponse #55 le: 14 octobre 2021 à 07:28:17 »
Citation de: aplufr le 13 octobre 2021 à 13:43:48
Je confirme avoir vu ce tweet, je n’ai pas eu le temps faire une capture..

Confirmation :
Citer
2021-10-13 09:20 CET - During the route-map modification, an Issue occurred : router didn't take the last digit in the entry. The route-map aimed at redistributing BGPv4 into OSPF. All IPv6 traffic were accessible.

http://travaux.ovh.net/?do=details&id=53798&
IP archivée

lechuck

  • Abonné Orange Fibre
  • *
  • Messages: 1 806
  • 06
13 octobre 2021: OVH totalement inaccessible en IPv4 (ok en IPv6)
« Réponse #56 le: 14 octobre 2021 à 09:26:47 »
On est en 2021 et les mecs font toujours de la maintenance d'équipements critiques à coup de putty/telnet et de copier-coller du bloc note ? ???

Y'a que moi que ca choque ?

Normalement dans une boite sérieuse, on a un environnement de test/staging qui simule l'env de prod, on prépare un script à l'avance, on l'applique sur le test et on vérifie que ca casse rien avant d'aller appliquer le même script en prod...???

J'ai l'impression que cette boite est restée sur le même mode de fonctionnement que lors de ses début, où le type dans son garage faisait le bricolo du telnet du dimanche... ca fait peur...
IP archivée

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 677
  • Lyon 3 (69) / St-Bernard (01)
    • Twitter
13 octobre 2021: OVH totalement inaccessible en IPv4 (ok en IPv6)
« Réponse #57 le: 14 octobre 2021 à 09:58:44 »
Citation de: lechuck le 14 octobre 2021 à 09:26:47
Y'a que moi que ca choque ?
Vaut mieux un bon humain qu'un mauvais script, selon la conf à faire, c'est pas choquant.

Ce qui l'est un peu plus c'est de redistribuer des routes BGP dans OSPF. Leur design doit être bien crade.
IP archivée

Tarkok

  • Abonné Orange Fibre
  • *
  • Messages: 227
  • Dunkerque (59)
13 octobre 2021: OVH totalement inaccessible en IPv4 (ok en IPv6)
« Réponse #58 le: 14 octobre 2021 à 17:54:19 »
Citation de: Hugues le 14 octobre 2021 à 09:58:44
Vaut mieux un bon humain qu'un mauvais script, selon la conf à faire, c'est pas choquant.

Ce qui l'est un peu plus c'est de redistribuer des routes BGP dans OSPF. Leur design doit être bien crade.

OSPF pour les routes internes, BGP pour les routes avec les AS externes. C'est juste un backbone MPLS classique en fait. Rien de crade.

Et oui une route default mal poussée peut te planter un réseau car diffusée à l'ensemble des routeurs via les RR (route reflector). La question que je me pose est : existe t-il des mécanismes à mettre en place au niveau des RR afin d'éviter qu'une route default puisse être poussée avec une telle priorité ? Je pense que oui, et qu'ils n'ont pas été mis en place.

Avec une bonne configuration au niveau des RR l'impact aurait pu être plus local.

Ou bien seconde hypothèse ils ont pas de RR et les routeurs se poussent les routes entre eux directement (comme semble l'expliquer leur post mortem) et alors là oui c'est un bordel ingérable.
IP archivée

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 677
  • Lyon 3 (69) / St-Bernard (01)
    • Twitter
13 octobre 2021: OVH totalement inaccessible en IPv4 (ok en IPv6)
« Réponse #59 le: 14 octobre 2021 à 18:00:49 »
Citation de: Tarkok le 14 octobre 2021 à 17:54:19
OSPF pour les routes internes, BGP pour les routes avec les AS externes. C'est juste un backbone MPLS classique en fait. Rien de crade

Heu non, tu mets pas toutes tes routes internes dans ton OSPF, personne de censé ne fait ça. Tu imagines la gueule d'un ospf avec 10000+ routes ?
Non, tu mets uniquement les loopbacks de tes routeurs, et encore, tu fais des Area et tu agrège en bordure. Moins un OSPF a de routes et de chemins dans la même aire, plus il est rapide en cas de coupure.
Et dans tous les cas, même avec les routes "internes" redistribuées, tu ne les apprends pas depuis BGP. Donc aucune raison d'avoir un "redistribute bgp" actif sur ospf.


Citation de: Tarkok le 14 octobre 2021 à 17:54:19
Et oui une route default mal poussée peut te planter un réseau car diffusée à l'ensemble des routeurs via les RR (route reflector). La question que je me pose est : existe t-il des mécanismes à mettre en place au niveau des RR afin d'éviter qu'une route default puisse être poussée avec une telle priorité ? Je pense que oui, et qu'ils n'ont pas été mis en place.
Rien à voir avec les RR, une default apprise en BGP a été redistribuée dans OSPF, elle a donc été préférée.

Le vrai truc inquiétant, c'est l'Area0 propagée partout dans le monde.
IP archivée
Pages: 1 2 3 4 [5] 6   En haut