La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
OVHcloud => Discussion démarrée par: thedark le 13 octobre 2021 à 09:37:05
-
Hello,
Chez moi OVH est dans le noir :(
Cordialement
Edit Vivien : Seul IPv4 était impacté. Voici la cause, expliquée dans un tweet qui a été rapidement supprimé :
(https://lafibre.info/images/ovh/202110_ovh_down_tweet_octave.jpg)
-
Chez moi aussi (Free Pro comme Bouygues Telecom)
Cela a beaucoup d'impacts.
Par exemple nperf.com qui a son architecture hébergée chez OVH ne répond plus.
-
idem pour moi, plus accès a notre site internet, ni notre messagerie...
-
Chez moi aussi (Free Pro comme Bouygues Telecom)
Cela a beaucoup d'impacts.
Par exemple nperf.com qui a son architecture hébergée chez OVH ne répond plus.
Je pense que la téléphonie K-NET est ko.
-
https://twitter.com/ovh_status/status/1448185498812485633 cette maintenance s'est mal passé ?
-
Les DNS de mes domaines sont chez eux, je n'ai plus rien non plus :(
Ils nous font une Facebook ?
-
c'est octobre, les stagiaires commencent leurs stages...
-
Le DNS du forum est chez OVH.
L'IPv4 si le DNS ne résout plus lafibre.info est 80.67.167.77
il suffit de mettre remplir l'information dans le fichier hosts de votre ordinateur.
Sous linux :
sudo nano /etc/hosts
rajouter la ligne
80.67.167.77 lafibre.info
-
Encore une grosse panne pour OVH. Une de plus.
je dirai pas une de trop, car de toute façon malgré les problèmes à répétition, ils conservent leurs clients... C'est incompréhensible. Y'a pas moins pro qu'OVH.
Klaba est un guignol.
-
Dire je voulais invertir dans la bourse. ::)
-
Du coup les DNS de Orange ont dût se faire flooder de requête, ça ne répond plus. (80.10.246.2 et 80.10.246.129)
EDIT : juste les domaines OVH
-
Cette fois c'est 100% des clients impactés...
-
Selon des gens, le routage IPV6 est ok.
-
Oui, du moins mes serveurs sont totalement accessibles en IPv6.
-
Cela a repris.
Première étape :
(https://lafibre.info/images/ovh/202110_ovh_panne_13_octobre2021.png)
Depuis le site d'OVH répond, mais pas celui de nPerf
-
Encore une grosse panne pour OVH. Une de plus.
je dirai pas une de trop, car de toute façon malgré les problèmes à répétition, ils conservent leurs clients... C'est incompréhensible. Y'a pas moins pro qu'OVH.
Klaba est un guignol.
Tu y vas fort. C'est pas comme si les services étaient down.
Côté SFR Mobile : RAS
-
Leurs offres telecom sont également inpactées... plus de net ici (fibre)
Suis un peu deg de lire que les serveurs sont accessibles en ipv6... ma connexion de secours ne dispose que d'ipv4... :(
-
pas de souci avec le site OVH
les sites comme Cartoradio ou le Groupe NRJ est down
-
IPv6 n'est pas impacté effectivement :
IPv6, c'est ok :
$ mtr -6zrwc10 test-api.arcep.fr
Start: 2021-10-13T09:54:08+0200
HOST: ubuntu Loss% Snt Last Avg Best Wrst StDev
1. AS5410 2001:860:f70a::1 0.0% 10 0.3 0.3 0.3 0.3 0.0
2. AS5410 2001:860:bbee:7c::1 0.0% 10 1.4 1.5 1.4 1.6 0.1
3. AS5410 2001:860:2::2 0.0% 10 1.8 1.9 1.8 2.1 0.1
4. AS16276 be303.par-gsw-sbb1-nc5.fr.eu 20.0% 10 2.1 2.2 2.1 2.3 0.1
5. AS??? ? ? 100.0 10
6. AS16276 2001:41d0:aaaa:100::6 50.0% 10 2.3 2.2 2.0 2.3 0.1
7. AS16276 be102.gra-g1-nc5.fr.eu 0.0% 10 6.7 7.1 6.7 8.1 0.5
8. AS16276 vl100.gra-d1-a75.fr.eu 0.0% 10 5.6 5.6 5.5 5.6 0.0
9. AS16276 2001:41d0:0:50::5:a1 0.0% 10 6.3 6.3 6.1 6.5 0.1
10. AS16276 2001:41d0:0:50::1:9971 0.0% 10 5.6 5.7 5.6 5.8 0.0
11. AS16276 2001:41d0:0:1:3::a009 0.0% 10 5.6 5.6 5.6 5.7 0.0
12. AS16276 2001:41d0:0:1:3::a3c9 0.0% 10 5.7 5.6 5.6 5.7 0.0
13. AS16276 2001:41d0:0:1:3::a420 0.0% 10 5.7 5.7 5.6 5.7 0.0
14. AS??? ? ? 100.0 10
15. AS16276 2001:41d0:305:2100::525e 0.0% 10 6.0 6.0 5.8 6.3 0.1
IPv4 : C'est KO :
$ mtr -4zrwc10 test-api.arcep.fr
Start: 2021-10-13T09:54:28+0200
HOST: ubuntu Loss% Snt Last Avg Best Wrst StDev
1. AS5410 194.158.119.185 0.0% 10 0.3 144.2 0.2 1093. 346.0
2. AS5410 62.34.2.156 80.0% 10 0.3 0.3 0.3 0.3 0.0
3. AS5410 62.34.2.155 50.0% 10 0.3 0.3 0.3 0.4 0.0
4. AS5410 be11.cbr01-cro.net.bbox.fr 0.0% 10 1.8 1.9 1.6 2.1 0.1
5. AS5410 62.34.2.251 0.0% 10 2.2 2.0 1.7 2.2 0.2
6. AS5410 62.34.2.90 90.0% 10 1.4 1.4 1.4 1.4 0.0
7. AS??? ? ? 100.0 10
8. AS??? ? ? 100.0 10
9. AS??? ? ? 100.0 10
10. AS??? ? ? 100.0 10
11. AS??? ? ? 100.0 10
12. AS16276 vl1332.was1-vin1-g1-nc5.wa.us 80.0% 10 83.9 83.6 83.4 83.9 0.4
13. AS??? ? ? 100.0 10
-
meme leur support ovhcloud sur twitter devait etre impacté et il ne devait plus avoir internet
https://twitter.com/ovh_support_fr/with_replies
plus aucun signe de vie depuis 9h25....
ils ont toujours rien dit sur twitter apres 30 mn ?!
-
Suite à une erreur humaine durant la reconfiguration du network sur notre DC à VH (US-EST), nous avons un souci sur la toute la backbone. Nous allons isoler le DC VH puis fixer la conf.
https://twitter.com/olesovhcom/status/1448196879020433409
-
Pas de soucis sur FTTH OVH chez nous. Tous les services hébergés sont down par contre
-
C'est donc bien un coup du stagiaire...
-
Cette fois c'est 100% des clients impactés...
comment sais-tu cela ?
-
Encore une grosse panne pour OVH. Une de plus.
je dirai pas une de trop, car de toute façon malgré les problèmes à répétition, ils conservent leurs clients... C'est incompréhensible. Y'a pas moins pro qu'OVH.
Klaba est un guignol.
Il y en a déjà un qui veut qu'on refasse le devis de l'an dernier pour héberger ses trucs, finalement il trouve notre prix correct après réflexion. ::)
-
Ils devraient se renommer OVH -> OVMDLS
On Vous Met Dans La Sauce ;D
-
comment sais-tu cela ?
Je trouve aucun site hébergé chez OVH qui fonctionne (à part OVH.com qui est revenu) :)
-
Attention au titre, SoS racistes peut débarquer d'une minute à l'autre :'(
-
Attention au titre, SoS racistes peut débarquer d'une minute à l'autre :'(
mdr :)
-
Suite à une erreur humaine durant la reconfiguration du network sur notre DC à VH (US-EST), nous avons un souci sur la toute la backbone. Nous allons isoler le DC VH puis fixer la conf.
https://twitter.com/olesovhcom/status/1448196879020433409
-
Bonne pub pour l'introduction en bourse. :P
-
C'est en train de remonter !
-
Oui, mes serveurs sont de nouveau accessibles en IPv4.
-
C'est remonter pour nous aussi
-
ca refonctionne chez nous, site internet et messagerie exchange.
-
Tout n'est pas remonté, et pas encore de téléphonie/fax
-
Mes IPs avec le Firewall d'activé ne marchent toujours pas.
Par contre sans Firewall ça marche très bien.
-
Les sites remonte progressivement
-
Suite à une erreur humaine durant la reconfiguration du network sur notre DC à VH (US-EST), nous avons un souci sur la toute la backbone. Nous allons isoler le DC VH puis fixer la conf.
https://twitter.com/olesovhcom/status/1448196879020433409
J’ai quand même du mal à piger qu'une erreur de config dans un DC aux US arrive à faire tomber le réseau en Europe.. ???
Ou alors ils se font une boucle sur le backbone ?
-
Un routeur qui annonce des routes qu'il ne devrait pas annoncer ? Avec une priorité qu'il ne devrait pas utiliser ?
-
un article
https://www.francebleu.fr/infos/societe/l-hebergeur-ovhcloud-touche-par-une-panne-geante-de-nombreux-sites-paralyses-1634113619
-
https://pbs.twimg.com/media/FBkeMa8WUAkopN4?format=jpg&name=4096x4096
https://twitter.com/ovh_support_fr/status/1448221957225340934
-
https://pbs.twimg.com/media/FBkeMa8WUAkopN4?format=jpg&name=4096x4096
https://twitter.com/ovh_support_fr/status/1448221957225340934
" la plus grande transparence sur les causes de cet incident "
comme l'incendie d'il y a 6 mois dont en entends plus parler ? ::)
-
Y'a ce tweet (supprimé) de Klaba qui tourne apparemment
(https://lafibre.info/images/ovh/202110_ovh_down_tweet_octave.jpg)
-
Y'a ce tweet (supprimé) de Klaba qui tourne apparemment
Ce qui expliquerait pourquoi en IPv6, tout est resté nickel :)
-
Pour l'occasion, on rappelle et/ou remarque que la téléphonie chez OVH est IPv4 only (affectée par le problème d'aujourd'hui donc). A quand IPv6 sur le SIP OVH ? :) (coucou @Vivien)
-
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.
(https://lafibre.info/images/ovh/201806_ovh_mx_mutualise_ipv6.png)
-
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.
Pffff...
Alors qu'ici :
(https://pix.milkywan.fr/OltoxI7h.png)
Et j'ai 0 problèmes, l'antispam (rspamd) se comporte super bien.
Faut juste se sortir les doigts et migrer.
-
Supervision de Facebook depuis OVH par Icinga : On voit bien que si l'internet IPv4 depuis OVH était injoignable, l'Internet IPv6 étai joignable.
(https://lafibre.info/images/ovh/202110_och_logiciel_supervision_Icinga.jpg)
Pour les sites OVH en IPv6 certains ont rencontrés des problèmes, car il y a des dépendances à IPv4 dans le back-end.
-
Y'a ce tweet (supprimé) de Klaba qui tourne apparemment
(https://lafibre.info/images/ovh/202110_ovh_down_tweet_octave.jpg)
Je confirme avoir vu ce tweet, je n’ai pas eu le temps faire une capture..
-
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
-
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 !
-
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.
-
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)
-
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.
(https://lafibre.info/images/ovh/201806_ovh_mx_mutualise_ipv6.png)
Ah ouais, comme même...
-
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.
-
Je confirme avoir vu ce tweet, je n’ai pas eu le temps faire une capture..
Confirmation :
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&
-
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...
-
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.
-
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.
-
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.
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.
-
Redistribué BGP dans OSPF est une pratique à risque. (https://routingcraft.net/what-happens-if-you-redistribute-bgp-full-view-into-ospf/)
Une erreur de route-map et ton réseau tombe avec une longue procédure de recuperation.
Mais bon, les mauvaises pratiques chez OVH, c'est historique (http://travaux.ovh.net/?do=details&id=4408&)
-
Quand je parlais des routes internes, je parlais pas des routes interne au routeur mais des routes internes à l'AS. Je sais pas si on s'est bien compris à ce niveau.
Le truc c'est qu'avec MPLS tu as un réseau IP qui encapsule un autre réseau (qui peut être IP, ou on peut même encapsuler des trames Ethernet en IP, ça fait les offres Lan to Lan des opérateurs).
Ils peuvent très bien décider dans leur construction MPLS de caser leur trafic Internet dans un réseau MPLS (je pars de cette hypothèse parce que sinon j'arrive pas à expliquer l'incident). ça donnerait donc des routeurs qui communiquent entre eux sur un réseau étanche d'Internet, qui se partagent des routes vers tous les autres routeurs du backbone en OSPF en mode "any-to-any". Au dessus de ça on a un MPLS Internet, des routes partagés en BGP (via des RR on espère !).
OSPF en mode "any-to-any" permettant ainsi de ne pas configurer des tables de routage statiques sur l'ensemble des routeurs du réseau pour joindre les RR.
En gros là on a :
Les routes externes qui sont annoncés via BGP, les routes internes (ce qu'ils appellent OVHcloud IGP) via OSPF - avec donc un nombre de route OSPF environ inférieur ou égale dans le pire des cas au nombre de routeur du backbone, c'est à dire sensiblement moins que 10 000.
Un peer BGP (un transitaire) qui leur balance une full view.
Une route-map qui n'a pas le nom attendu dans sa définition et de ce fait qui n'est appliquée.
Le comportement par défaut sur un peer OSPF serait donc de balancer toute la table de routage à son voisin ? Je me trompe ? A priori non, merci @thenico pour le lien !
Mais sur un gros réseau MPLS, pour les raisons vu plus haut, on peut difficilement faire mieux que de de l'OSPF. Reste plus qu'à régler la max-lsa limits, comme le recommande l'article envoyé par @thenico. A priori la feature est dispo sur Cisco ou Juniper.
-
On peut faire de l'IS-IS à la place d'OSPF.
-
Un peu les memes problématiques qu'en OSPF si je comprends bien le mécanisme, à part que la conf par défaut de Cisco semble être plus adaptée à un réseau grande échelle. Je sais pas si Juniper propose un mécanisme similaire et si ils l'appliquent également par défaut.
-
Quand je parlais des routes internes, je parlais pas des routes interne au routeur mais des routes internes à l'AS. Je sais pas si on s'est bien compris à ce niveau.
Heu, ben ouais, ça ne change rien.
Le truc c'est qu'avec MPLS tu as un réseau IP qui encapsule un autre réseau (qui peut être IP, ou on peut même encapsuler des trames Ethernet en IP, ça fait les offres Lan to Lan des opérateurs).
Oui, certes ?
Ils peuvent très bien décider dans leur construction MPLS de caser leur trafic Internet dans un réseau MPLS (je pars de cette hypothèse parce que sinon j'arrive pas à expliquer l'incident). ça donnerait donc des routeurs qui communiquent entre eux sur un réseau étanche d'Internet, qui se partagent des routes vers tous les autres routeurs du backbone en OSPF en mode "any-to-any". Au dessus de ça on a un MPLS Internet, des routes partagés en BGP (via des RR on espère !).
OSPF en mode "any-to-any" permettant ainsi de ne pas configurer des tables de routage statiques sur l'ensemble des routeurs du réseau pour joindre les RR.
C'est exactement ce que je te dis en fait...
Tes sessions BGP avec tes RR, tu les montes via des routes apprises en OSPF. Mais sur cet OSPF, tu ne mets *que* les ip de loopback de tes routeurs, et les IP de tes RR. Tu ne repartages PAS toutes les routes de ton AS, ça, tu le fais en iBGP.
Les routes externes qui sont annoncés via BGP, les routes internes (ce qu'ils appellent OVHcloud IGP) via OSPF - avec donc un nombre de route OSPF environ inférieur ou égale dans le pire des cas au nombre de routeur du backbone, c'est à dire sensiblement moins que 10 000
Ben non, tu mélanges tout, les routes internes ce n'est pas l'IGP, les routes internes c'est tous les préfixes internes à l'AS, donc le préfixe de la kimsufi de kévin, du public cloud d'Airbus, etc.
Dans ton IGP, tu ne mets que les loopbacks et les interfaces que tu autorises explicitement.
Le comportement par défaut sur un peer OSPF serait donc de balancer toute la table de routage à son voisin ? Je me trompe ? A priori non, merci @thenico pour le lien !
Non, le comportement par défaut c'est de n'annoncer que ce qui a été explicitement configuré.
Si tu active un "redistribute static, connected, bgp ou autre" ça rebalancera de la merde, pour ça qu'on ne l'active JAMAIS sans une route-map qui contrôle ce qui est annoncé, notamment.
Bref, je crois que tu te fourvoies sur ce qu'on met dans un IGP. iBGP n'est pas un IGP, OSPF est un IGP qui n'a pas vocation à accueillir autre chose que des loopbacks et des préfixes d'interco.
-
Mais sur un gros réseau MPLS, pour les raisons vu plus haut, on peut difficilement faire mieux que de de l'OSPF.
Mais c'est très bien OSPF, juste, pas pour faire ton routage interne, juste pour annoncer tes loopbacks et monter de l'iBGP (et eventuellement du MPLS) par dessus ;)
-
Mais c'est très bien OSPF, juste, pas pour faire ton routage interne, juste pour annoncer tes loopbacks et monter de l'iBGP
J'approuve ce message (enfin «très bien» va un peu loin, quand même :P )
Tu imagines la gueule d'un ospf avec 10000+ routes ?
À vrai dire OSPF est plus scalable qu'on ne pense... Mais bon la première quote reste vraie.
Le vrai truc inquiétant, c'est l'Area0 propagée partout dans le monde.
Pas ok.
Sur des déploiements type Tier1 internationaux, ISIS Level2 only (donc mono-aire mondiale) est classique. J'attire ton attention sur la migration d'ATDN (Tier1 de l'époque) d'OSPF vers ISIS en 2003, décrite lors du NANOG29:
https://archive.nanog.org/meetings/nanog29/presentations/gill.pdf
«Found out we didn’t need areas» «is-type level-2-only»
C'est ancien, certes, mais ça reste d'actualité.
Bon OSPF a été réimplémenté depuis que les gros tier1 ont tous migré (ou démarré) en ISIS, il reste probablement moins scalable mais les CPU des routeurs ont aussi migré vers du x86 depuis le temps.
Bref, l'aire backbone unique internationale n'est pas choquante.
-
Ok ! C'est un peu contre intuitif, vu les risques que ça représente en cas de loupé, mais c'est vrai que tout mettre dans l'Area0 c'est confortable et KISS :)