La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
OVHcloud => Discussion démarrée par: vivien le 18 septembre 2016 à 14:46:04
-
OVH offre l’accès à tous ses transitaires et paid-peering, même dans ses offres d'entrée de gamme.
Alors que Online, le premier concurrent d'OVH, propose maintenant une bande passante "basic" dans ses serveurs dédiés Dedibox d'entrée de gamme (la "gamme perso"), OVH m'annonce qu'il a revu sa politique et que la page https://www.ovh.com/fr/serveurs_dedies/detail-upgrade-bande-passante.xml sera très rapidement mis à jour pour refléter la politique actuelle.
Ce dimanche 18 septembre, nous observons :
- OVH offre l’accès à tous ses transitaires et peering (même les peering paynts) sur l'ensemble de ses serveurs.
- Online, sur sa gamme "perso" fait sorti tout le trafic par Cogent + les peering gratuits. Un acteur qui ne peer pas gratuitement avec Online, comme Orange ou SFR, le trafic sera envoyé par le transitaire low-cost Cogent. Une seule exception : le peering avec Free a été remis en place, Free saturant avec Cogent. A noter que c'est du "test" et que Online peut faire évoluer la situations les prochains jours :
on va quand meme apporter les bonnes nouvelles, on a remis Free ;)
vous aurez plus d'infos lundi, pour le moment ca reste du test
Cf le sujet dédié : Online: trafic sortant via Cogent pour Free/Orange/SFR (pour certains serveurs) (https://lafibre.info/online/online-trafic-sortant-via-cogent/)
- Online sur ses autres gammes de serveurs, offre un accès à tous ses peering et transitaires.
Voici pour mémoire une copie d'écran de la page https://www.ovh.com/fr/serveurs_dedies/detail-upgrade-bande-passante.xml où OVH décline les différentes qualité d'interconnexion qu'il propose a ses clients. La page sera mis à jour rapidement pour refléter la réalité. (note : j'ai supprimé dans la copie d'écran les peering via GIX qui sont bien entendu proposé à tous les clients. OVH est présent sur pas moins de 27 GIX différents !)
(https://lafibre.info/images/ovh/201609_ovh_bande_passante_premium.png)
-
C'est valable pour Kimsufi et SoYouStart ?
-
Haha, c'est magique ! Par contre je n'ai pas compris
Ce dimanche 18 septembre, nous observons :
Quelle est ta source ? Juste une observation ?
-
Une discussion avec Octave Klaba / Oles sur Twitter qui m'a expliqué que l'information diffusée sur le sujet d'Online (ici (https://lafibre.info/online/online-trafic-sortant-via-cogent/msg371950/#msg371950)) était fausse. La page d'OVH qui annonce un seul transitaire, Cogent pour la bande passante Premium, était fausse et que la page concernée n'est plus à jour.
Je précise bien aujourd’hui, car les choses pourraient évoluer demain chez Online.
C'est valable pour Kimsufi et SoYouStart ?
Oui.
Tous les transit / peering sont accessible depuis les serveurs Kimsufi et SoYouStart (entrée de gamme OVH)
-
Je précise bien aujourd’hui, car les choses pourraient évoluer demain chez Online.
Wait&See :)
-
Voici un topic intéressant.
-
OVH n'a toujours pas modifié sa page https://www.ovh.com/fr/serveurs_dedies/detail-upgrade-bande-passante.xml
Elle affiche toujours un seul transitaire, Cogent, pour la bande passante "Premium"
-
Une discussion avec Octave Klaba / Oles sur Twitter qui m'a expliqué que l'information diffusée [...] était fausse. La page d'OVH qui annonce un seul transitaire, Cogent pour la bande passante Premium, était fausse et que la page concernée n'est plus à jour.
[...]
Tous les transit / peering sont accessible depuis les serveurs Kimsufi et SoYouStart (entrée de gamme OVH)
Et OVH est bien 100% conforme à la promesse qui t'a été donnée, vu de moi.
-
Une discussion avec Octave Klaba / Oles sur Twitter qui m'a expliqué que l'information diffusée sur le sujet d'Online (ici (https://lafibre.info/online/online-trafic-sortant-via-cogent/msg371950/#msg371950)) était fausse. La page d'OVH qui annonce un seul transitaire, Cogent pour la bande passante Premium, était fausse et que la page concernée n'est plus à jour.
Après, peut-être qu'OVH ne veut pas corriger cette page, pour pouvoir changer du jour au lendemain sa politique de routage, et dégrader la qualité des offres low cost librement...
Leon.
-
C'est pas le genre de la maison ce type de pratique ! ;D
-
C'est pas le genre de la maison ce type de pratique ! ;D
Tout comme on pensait que ce n'était pas le genre d'Online de faire ça (En tout cas moi)
-
+1 :-[
-
Messieurs, vous êtes quand même de grand naïfs.
Pour ma part, j'aurais quand même préféré une limite sur le volume mensuel pour ne pas léser tous les clients mais il semblerait que la conservation des marges passe avant tout.
-
Je suis pas naif, y'a des opérateurs qui font de la qualité, pourquoi pas des hébergeurs ?
-
Je vais vous raconter le rêve que j'ai fais cette nuit : Online avait sorite une offre pour que ceux qui peer en direct avec lui puisent commercialiser des IP Online. OVH avait souscrit à cette offre et les clients OVH pouvaient prendre un VLAN pour avoir une seconde IP Online.
Concrètement les clients de serveurs dédiés OVH :
- ont une IP OVH comme d'habitude
- peuvent souscrire à une offre "IP" chez Online : leur IP Online leur est livré sur un VLAN. Tout le trafic sortant de ce VLAN sort directement par le transit/peering Online.
Voila mes rêves complètements fous !
-
Je vais vous raconter le rêve que j'ai fais cette nuit : Online avait sorite une offre pour que ceux qui peer en direct avec lui puisent commercialiser des IP Online. OVH avait souscrit à cette offre et les clients OVH pouvaient prendre un VLAN pour avoir une seconde IP Online.
Concrètement les clients de serveurs dédiés OVH :
- ont une IP OVH comme d'habitude
- peuvent souscrire à une offre "IP" chez Online : leur IP Online leur est livré sur un VLAN. Tout le trafic sortant de ce VLAN sort directement par le transit/peering Online.
Voila mes rêves complètements fous !
ça n'arrivera jamais ce que tu as rêvé. (même si ton idée n'est pas mauvaise mais bonjour les configurations tordues avec 2 ip différentes)
ce que tu décris là c'est une redondance à 2 opérateurs et c'est le fondement même de BGP et miracle ... tout ça sur la même IP! pas besoin de jongler d'une IP à l'autre...
pour avoir accès à BGP il faut s'adresser à des vrais hébergeurs business, pas le segment lowcost comme ovh ou online. je dis ça car ou je suis hébergé j'ai cela, bgp, AS,.. c'est effectivement le graal.
-
Je pense que Vivien connait BGP, ne t'en fais pas ::)
-
C'est un rêve la nuit, je sais très bien que ce n'est pas possible.
-
Et une offre d'interconnexion de LAN privés (Vrack, RPN) entre OVH et Online-Scaleway (et d'autres européens type 1&1, Hetzner), vous pensez que c'est crédible?
Quitte à étendre ça également aux opérateurs entreprise (accès FTTE/FTTO), pour créer des réseaux privés de bout en bout facilement.
Avec ce type d'offre, on pourrait faire exactement ce qu'imagine Vivien, côté client : avoir une IP Scaleway sur une machine OVH et vice versa.
Ca serait à fond dans l'idée d'écosystème Européen en concurrence des mastodontes du cloud, idée que Octave promeut depuis quelques années.
Leon.
-
OVH propose déjà une interco de ce genre, ils peuvent te livrer ton VRACK sur un port en DC... Online, rien vu passer :(
-
Salut Hugues.
Oui, je sais qu'on peut livrer terminer un VRACK dans un POP chez OVH, chez AWS et plein d'autres.
J'imaginais quelque chose de plus cloud/automatisé : la possibilité d'interconnecter des VRACK (OVH) RPN (Scaleway) de différents fournisseurs de cloud, sans avoir besoin d'une présence dans un datacenter/POP pour le client. Sans avoir de port dédié pour chaque client. Donc une interconnexion "unique" entre OVH et Scaleway (par exemple) et qui encapsulerait, mutualiserait toutes les interconnexions entre réseaux privés qu'achèteraient les clients.
On peut imaginer à l'extrême des interconnexions entre plein de fournisseurs de Cloud et d'opérateurs, le tout configurable en automatique, quitte à passer par un partenaire qui interconnecte tous les fournisseurs / opérateurs entre eux.
C'est ce que Equinix a essayé de proposer, je ne sais pas où ça en est.
On en parlait ici https://lafibre.info/gix/equinix-interconnexion/
Leon.
-
On peut imaginer à l'extrême des interconnexions entre plein de fournisseurs de Cloud et d'opérateurs, le tout configurable en automatique, quitte à passer par un partenaire qui interconnecte tous les fournisseurs / opérateurs entre eux.
C'est ce que proposent énormément d'opérateurs, déjà :)
Tu as ça aussi : https://www.businesswire.com/news/home/20191104005626/fr/
-
C'est ce que proposent énormément d'opérateurs, déjà :)
Tu aurais plus d'info, des pistes pour que je puisse me renseigner sur le sujet, stp? Des noms d'opérateurs qui s'interconnectent avec des fournisseurs de cloud?
Quelques exemples de noms d'offres qui font tout ça?
C'est plutôt des offres type "entreprise", donc plutôt haut de gamme?
Du coup, ça veut sans doute dire qu'on peut faire ce qu'imaginait Vivien initialement : avoir une IP AWS sur une machine OVH et vice versa.
Leon.
-
Il me semble que l'interco de clouds est plutôt en L3 chez les gros.
C'est au catalogue de tout un tas d'acteurs, du T1 comme Zayo ou Telia au petit comme Volterra ou Jaguar...
-
Salut Hugues.
Oui, je sais qu'on peut livrer terminer un VRACK dans un POP chez OVH, chez AWS et plein d'autres.
J'imaginais quelque chose de plus cloud/automatisé : la possibilité d'interconnecter des VRACK (OVH) RPN (Scaleway) de différents fournisseurs de cloud, sans avoir besoin d'une présence dans un datacenter/POP pour le client. Sans avoir de port dédié pour chaque client. Donc une interconnexion "unique" entre OVH et Scaleway (par exemple) et qui encapsulerait, mutualiserait toutes les interconnexions entre réseaux privés qu'achèteraient les clients.
On peut imaginer à l'extrême des interconnexions entre plein de fournisseurs de Cloud et d'opérateurs, le tout configurable en automatique, quitte à passer par un partenaire qui interconnecte tous les fournisseurs / opérateurs entre eux.
C'est ce que Equinix a essayé de proposer, je ne sais pas où ça en est.
On en parlait ici https://lafibre.info/gix/equinix-interconnexion/
Leon.
Plusieurs acteurs proposent ce que tu décris:
- Equinix Cloud Exchange
- InterCloud
- MEGAport
- DE-CIX (c'est intégré dans l'IX)
- et désormais les opérateurs ont intégré ce type d'offre
Tous proposent soit une inter-connexion L2 directe (point-à-point en général) entre le client et des clouds providers (1 tag de vlan par destination pour le client) et/ou entre les clouds providers soit une inter-connexion L3 avec du BGP. C'est souvent cette dernière qui est déployée pour ls inter-connexions entre Cloud Providers car la configuration est imposée et sont souvent incompatibles (exemple: GCP impose une MTU inférieure à 1500, ou l'IP à utiliser est la même des 2 côtés).
Niveau automatisation, c'est souvent au client de se débrouiller seul en commandant sur l'Exchange puis chez le Cloud PRovider et enfin de rentrer tous les paramètres BGP, souvent de chaque côté, soit d'un seul. Certes la config se déploie seule mais le client doit saisir des configs IP/BGP un peu de partout.
Petit à petit les portais fournis par ces acteurs commencent à tout intégrer mais on est de loin d'un simple clic.
-
Merci BadMax, c'est très intéressant.
Du coup, techniquement, pour une interco L3 BGP entre un cloud provider et un opérateur (ou opérateur d'interconnexion cloud type Equinix Cloud Exchange), le client configure un "routeur virtuel" côté cloud provider? Avec une API dédiée du cloud provider?
Je suppose qu'il faut un "routeur virtuel" par zone géographique (zone du cloud provider), voire un par datacenter.
Leon.
-
Un peu des 2:
- côté Cloud Provider, il y a toujours une instance de routage dans la zone d'arrivée (AWS VPC, Azure VNET, OVH vRack)
- à la frontière Opérateur/Cloud Provider, ce dernier en fournira une autre où BGP est obligatoire pour gérer les annonces (sauf en L2 si supporté)
- côté opérateur, il peut y avoir ou pas un routeur virtuel fourni servant d'intermédiaire entre le réseau du client (MPLS voir son DC) et le Cloud Provider.
-
Côté cloud provider, le client a accès à une API pour configurer son routeur virtuel? C'est une API maison? Ou alors un truc repris des standards ouverts?
Et côté matériel utilisé par les clouds provider, pour réaliser ces instances de routeur virtuel, on sait si c'est réalisé par des gros routeurs physiques? (mutualisés entre plusieurs clients bien sur). Ou alors par de simples machines x64, physiques ou virtuelles?
Leon.
-
Oui il y a des API mais chacun a sa propre implémentation fonctionnelle. C'est du REST donc facile à gérer mais le processus est propre à chacun. Toutefois il y a une sémantique commune.
-
Pour les devices, certains c'est des équipements physiques (switches L3 avec des vrfs) d'autres c'est effectivement des VM type Cisco CSR. Sur GCP il me semble que c'est un L2TP entre le POP et le DC et ce dernier héberge la VM.
-
J'ai jamais compris cet engouement pour avoir une interco physique entre providers pour les réseaux privés, ca va juste vous restreindre en terme de haute dispo (a avoir 1 ou 2 liens juste pour ca au lieux de pouvoir bénéficier du taux de dispo du backbone et du routage IP publique)...
Je préfère largement la solution VPN IPSEC entre plusieurs sites, avec les bonnes gateway et du peering direct les performances sont généralement très bonnes et c'est aussi bien plus accessible en terme de budget. (apres si vous voulez du +10Gbps garantie de façon permanent forcément c'est peut être le seul cas ou la oui ça aurais du sens)
Et faire du L2 inter-provider (et inter-site en general) c'est généralement chercher les soucis.