-
Hello !
Petite mise à jour de ce post, quelques mois après ! Les anciennes versions de ce post sont disponibles ici : https://lafibre.info/milkywan/archive-milkywan-as57199
MilkyWan est un opérateur associatif que j’ai fondé en 2015, c’était, pendant quelques années mon terrain de jeu personnel. Au fil du temps, j’ai commencé à ramener du monde autour du projet et à faire grandir l’infrastructure, de quelques routeurs dans ma chambre, on est passés à des serveurs dédiés chez Online, des VM chez Hivane ou K-Net à un vrai réseau national indépendant.
(https://lafibre.info/images/associatif/logo_milkywan_big.png)
1/ Infrastructure
MilkyWan est un réseau associatif expérimental qui fête ses 8 ans cette année, qui a commencé avec des routeurs Linux et des ERL montés en tunnel un peu partout, et qui évolue maintenant vers une infra en propre.
Je ne vais pas parler de l'ancienne infra ici, c'était en gros basé sur : des dédiés Online, GRE,FRR,BGP,et un peu d'L2TP.
En Février 2018, nous avons décidé de passer à l’étape supérieure en devenant un “vrai” opérateur, en exploitant notre propre infrastructure système et réseau, de la bordure aux routeurs de collecte, en passant par les serveurs et les NAS.
Nous avons d'abord commencé avec des routeurs de la marque Mikrotik, gamme CCR et RB, nous sommes progressivement en train de décomissionner ces derniers pour passer sur du matos plus "opérateur" : Cisco, Juniper, Arista, etc
En 2023, MilkyWan s’étend sur près de 11 points de présence, sur toute la France et en Suisse.
1.a/ Côté Matos :
L'infra réseau est grosso modo séparée en 3 parties :
- L'infra de backbone (appelée Edge)
- L'infra datacenter (appelée Core)
- L'infra de collecte (Appelée Col)
Coté Edge, nous exploitons des routeurs des constructeurs Arista, Juniper et Mikrotk :
- Quatre Arista 7280TR : Des gros routeurs 100G. Ils tiennent une full-table. Nous avons des modèles 48x10G Cuivre (inutilisés) + 6 ports 100G.
- Deux Arista 7050SX : Nous les avons choisis pour leur excellent rapport qualité prix. Ils tiennent environ 3-400k routes, ce qui nous suffit. Nous avons des modèles 48x10G + 4 ou 6 ports 40G.
- Un Arista 7050QX-32S : Le même routeur qu'au dessus mais en format 32x40G + 4x10G
- Un CCR1009 : Dans leur version 1x10G. Ce sont les routeurs avec lesquels on a commencé, et que nous déprovisionnons aujourd’hui, il n'en reste plus qu'un, à Rennes, qui récupère Breizh-IX et fournit un peu de connectivité aux copains :)
- Un Juniper MX80 à Lille qui collecte LillIX et divers L2L à travers la France
Coté Core, on exploite du Cisco, du Dell et de l'Arista, c'est amené à évoluer pour de l'Arista only. Nous avons :
- Trois Arista 7050QX-32S : Ce sont les routeurs de coeur de nos trois POP Système : CBO, dc2scale et HosTELyon. Les serveurs 40G sont également branchés dessus.
- Deux Cisco Catalyst 4500X : Des switchs d'agrégation 24x10G qui servent a relier les serveurs aux Arista
- Un Dell N4032 : Un simple switch 24x10G + 2x40G, il relie des serveurs à un routeur d'agreg
- Un Arista 7050QX-32 : Il collecte les abonnés de Nexeren
Bref, une infra assez simple mais qui marche incroyablement bien :)
Coté Collecte, nous exploitons plusieurs matériels :
- Deux Cisco ASR1001 + SPA10G qui routent les abonnés du SIEA à Genève et quelques clients + la porte de secours du SIEA à Nexeren.
- Deux Cisco ASR1002+ESP10 : Pour les collectes L2TP / PPPoE, c'est de la bombe !
- Des Mikrotik RB4011 : Des super petits routeurs de collecte, on fait terminer les tunnels L2TP/GRE/IPIP dessus, ils sont en train d'être migrés sur les ASR1001 et 1002
Nous sommes présents dans de nombreux DC, par ordre d’apparition :
- Scaleway DC2 (Vitry, sud de Paris) :
- SFR Venissieux (Venissieux, Sud de Lyon)
- Telehouse 2 (Paris 11)
- Cogent Rennes
- CIV Lille
- DC2Scale Velizy
- Appliwave CBO (Croissy-Beaubourg)
- HosTELyon
- Nexeren
- Cogent Toulouse
- Le CIXP à Genève
Plus de détails et de photos de nos POP ici : https://lafibre.info/milkywan/milkywan-photos-des-pop/
1.b/ Côté Ressources IP :
En IP Legacy, nous avons plusieurs blocs alloués par le RIPE : 45.13.104.0/22,193.58.42.0/24, 195.20.209.0/24 et un /24 alloué par Gitoyen : 80.67.167.0/24
Le premier est utilisé pour les abonnés, le second pour l'infra :)
En IPv6, nous avons un /32 alloué par AppliWave : 2a0b:cbc0::/32 et un /29 alloué par le RIPE : 2a0e:e700::/29
Même principe qu'en v4, le /32 sert surtout à l'infra (et aux premiers abonnés), le /29 sert aux abonnés uniquement
Et évidemment, l’AS2027 (anciennement AS57199), un AS 16 Bits puisqu’il n’est pas possible de faire de la commu étendue sur un AS32b avec Mikrotik. Et c’est quand même plus classe d’avoir un AS 16b, il faut le dire :)
1.c/ : Coté Interconnexions.
Je pense qu’on peut affirmer sans trop se mouiller que nous sommes l’opérateur associatif le mieux interconnecté de France :-)
Coté Transit, nous avons :
- 300Gbit/s de transit AppliWave (AS200780), sur DC2, TH2 et Vénissieux (Régional), en 100G sur trois POP
- 10Gbit/s de transit partiel Hivane Network (AS34019), qui nous partage ses nombreux peerings
- 10Gbit/s de transit protégé Acorus (AS35280) avec l'anti-DDoS qui va bien :D
- 40Gbit/s de transit FiberWay (AS49434) (parce que pourquoi pas ?)
- 10Gbit/s de transit Verixi (AS6696) avec Anti-DDoS également
Coté Peering, nous avons :
- 10G sur le LyonIX à Venissieux, avec comme remote peering activé : TopIX, AuvernIX et GrenoblIX
- 10G sur LyonIX à TH2
- 10G sur FranceIX Paris à DC2, avec comme remote peering FranceIX Marseille.
- 10G sur le LillIX, à Lille, on peer notamment avec OVH et Ielo-Liazo là bas.
- 10G sur FranceIX Toulouse avec un remote-peering à Paris
- 10G sur le Breizh-IX à Rennes
Ce qui nous donne un total de 430Gbit/s de capacité vers internet. Une capacité honorable :-)
D’ailleurs, on est régulièrement dans le top HE France sur le nombre de peers IPv4/v6 <3
1.d/ Le reste :
Nous sommes déclarés à l’ARCEP (code MILK), membres de la Task Force IPv6 (enfin moi), et membres d’aucune association d’opérateurs associatifs, vu que la principale ne correspond pas à notre vision et qu'il n'y en a pas d'autres (mais on bosse quand même avec plaisir avec tous les autres FAI Associatifs ! :-)
2/ Le setup :
Nous exploitons donc un backbone assez varié, avec du 10G, du 40G et du 100G. Il est pur IP (pas de MPLS, de SR ou autre), Il est drivé par un control plane doté d’une part d’ OSPF en IPv4 et OSPFv3 en IPv6, et d’autre part iBGP, avec 3 RR virtualisés sur nos POP système. Nous n'apprenons plus la fullview en IPv4, le gap de prix (minimum x5) entre un routeur avec et sans full a fait pencher la balance. Autant avoir un réseau qui marche bien sans full qu'un réseau bricolé avec la full. En IPv6 par contre, nous apprenons la fullview :)
Tout ce backbone est relié par des Lan2Lan en 10/40G pour les liaisons Nationales et des Waves DWDM en 10G sur tout le réseau métropolitain de Paris/Lyon. Ces liens sont fournis par AppliWave, Rezopole ou Quantic Telecom (merci à eux !)
On essaie d’avoir un backbone le plus redondant possible, mais c’est parfois un peu compliqué, nous faisons donc confiance à la fiabilité de celui de nos sponsors (et on n’a que très rarement eu de coupures).
On relie aussi les serveurs, NAS, et les routeurs de collecte en n*10G (quand ils en sont capables) ou en N*1G.
On a de la MTU9k partout, ce qui permet de proposer des tunnels L2 avec une MTU 9k entre tous nos PoP, et aussi simplement qu’avec du MPLS, grâce à VxLAN.
Voici la Weathermap du réseau, accessible à cette URL en IPv6 Only : https://weathermap.milkywan.fr/milkywan.html
(https://pix.milkywan.fr/nVnhN3lV.png)
Historiquement on faisait de l’eBGP avec des AS Privés, chaque routeur de collecte ayant un AS, ce qui permet de bénéficier de la qualité du filtrage de BGP.
Maintenant nous faisons de l'OSPF jusqu'aux routeurs de collecte et de l'iBGP, ça marche très bien aussi et ça évite d'avoir 15 AS à gérer.
Les abonnés Tunnel ayant demandé une redondance sont également livrés en eBGP avec AS privé, c’est plus simple à gérer, encore une fois :)
3/ L’équipe
Nous sommes actuellement 12 dans l’asso dont notamment :
- Vincent, Admin sys
- Guilhem, Responsable Communication et DA
- François, Secrétaire, Admin sys et développeur iOS
- Raphaël, Admin réseau
- Pierre, Responsable infra système
- Marc, Responsable Delivery/Support
- Gary, Trésorier
- Gabriel, responsable d'exploitation FTTH et relations OI/RIP
- Nicolas, responsable sécu
- Adrien, développeur
- Paul, admin réseau
- Damien, responsable SI et lead dev
- Moi, Admin Réseau, Sys et Président
- Corentin, membre d'honneur
- Julien, membre d'honneur
4/ Les services
On propose tout ce qu’un “vrai” opérateur peut vous proposer, à peu de choses près.
Pour résumer, on a deux catégories de produits :
4.b/ Pour les particuliers :
- FTTH : Collecte nationale, collectes régionales sur certains réseaux, allez voir le topic dédié : https://lafibre.info/milkywan/ftth-milkywan/
- xDSL : Pareil qu'au dessus, même topic :)
- Tunnels IP : Un simple tunnel (ou VPN) depuis le réseau de MilkyWan. On peut même faire de la redondance avec BGP :)
- Machines virtuelles : On propose plein de VM, je ne vais pas tout détailler ici, mais le point important, c’est que le réseau n’est pas bridé !
4.a/ : Les services Opérateurs
On propose tout un tas de services à destination des opérateurs, dans le lot :
- Transit IP BGP : Le plus connu, on propose du transit, avec un commit démarrant à 7,5Mbit/s jusqu’à 1Gbit/s (voir plus, mais vous n’avez plus besoin de nous, je pense :)), sachant que notre réseau est plutôt très développés (parmi les meilleurs de France selon HE)
- Lan2Lan : On vous transporte en 100M/1G ou plus, entre tous nos PoP !
- Housing : On vous héberge, à DC2Scale, Appliwave CBO ou Lyon HosTELyon. Et on a des partenariats pour les autres DC, au besoin :)
- FTTO : On sait livrer de la FTTO un peu partout en France pour vous livrer tout ce qui est au dessus.
Bref, on reste sur du classique, mais efficace, et avec un excellent réseau :)
4.c / Les services Web :
Principalement des services qu’on utilise en interne, et qu’on ouvre au plus grand nombre :
- Pix (https://pix.milkywan.fr/): Un service d’hébergement d’images
- Hastebin (https://hastebin.milkywan.fr/) : Un service de pastebin plutôt joli
- Pad (https://pad.milkywan.fr/) : Un service de pad collaboratif assez efficace.
Conclusion :
Bref, voilà un petit post sur ce qu’on fait, on est plutôt content du chemin parcouru depuis 2015, et on espère que les 5 prochaines années seront encore plus fructueuses, lancer le FTTH et l'xDSL est pour moi une vraie consécration et je me demande jusqu'où ça nous mênera :)
Si vous voulez voir nos nouvelles, on est sur Twitter (@MilkyWan_net), sur IRC (#milkywan sur libera.chat, n'hésitez pas à rejoindre #lafibre aussi, on se marre bien :) ).
Le site web est ici : https://milkywan.fr/ (https://milkywan.fr/)
On est sur PeeringDB et je maintiens les objets RIPE à jour :)
Je vous laisse sur quelques photos de l’infra :)
TH2
(https://pix.milkywan.fr/UfSZsCfo.jpg)
DC2
(https://pix.milkywan.fr/60sED5dI.jpg)
DC2Scale
(https://pix.milkywan.fr/mboSVGXD.jpg)
CBO
(https://pix.milkywan.fr/LmmqzlEL.jpg)
HosTELyon
(https://pix.milkywan.fr/OJC2QmHr.jpg)
-
Il est toujours possible d'avoir un AS 16bits ?
Quel serait l’intérêt alors de choisir un AS 32bits si il n'y a pas de pénurie en 16bits ?
Sinon, voici quelques traceroutes vers ce nouveau réseau :
Bouygues Telecom Interxion2 IPv4 :
$ mtr -z4rwc100 milkywan.fr
Start: Mon Feb 26 22:30:20 2018
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS5410 194.158.119.185 0.0% 100 0.4 4.0 0.3 358.7 35.8
2. AS5410 be11.cbr01-ntr.net.bbox.fr 0.0% 100 3.6 2.7 1.5 3.9 0.3
3. AS5410 la13.rpt02-ix2.net.bbox.fr 81.0% 100 1.2 1.2 1.1 1.2 0.0
4. AS??? appliwave-dc3.par.franceix.net 0.0% 100 1.5 2.2 1.5 68.4 6.7
5. AS200780185.217.200.18 0.0% 100 1.6 1.6 1.5 5.3 0.4
6. AS??? ? ? 100.0 100
7. AS200780130.117.11.5 0.0% 100 2.1 2.2 1.9 5.8 0.4
Bouygues Telecom Interxion2 IPv6 : Passage par AS 5511 !
$ mtr -z6rwc100 milkywan.fr
Start: Mon Feb 26 22:32:41 2018
HOST: ubuntu Loss% Snt Last Avg Best Wrst StDev
1. AS5410 2001:860:f70a::1 0.0% 100 0.8 0.5 0.4 0.8 0.0
2. AS5410 2001:860:bbee:4d::1 0.0% 100 1.2 1.2 1.2 1.5 0.0
3. AS5511 2a01:cfc4:0:e00::4 0.0% 100 2.4 2.1 1.2 38.1 4.4
4. AS5511 2a01:cfc4:0:1c00::13 0.0% 100 1.2 1.3 1.2 2.2 0.0
5. AS??? 2a02:e5c:0:3::2 0.0% 100 1.6 1.7 1.6 3.8 0.3
6. AS??? 2a02:e5c:2:11::2 0.0% 100 1.7 1.8 1.7 3.5 0.2
7. AS2007802a05:46c0:0:210::5 0.0% 100 1.8 1.9 1.7 3.2 0.2
8. AS57199 saturn.dc3.milkywan.network 0.0% 100 2.2 4.3 2.0 141.4 14.5
9. AS57199 web.milkywan.space 0.0% 100 2.2 2.7 2.0 31.4 2.9
Adeli / Maxnod dans l'Ain IPv4 : C'est le transit Ielo qui est utilisé avant de passer sur France-IX
$ mtr -z4rwc100 milkywan.fr
Start: Mon Feb 26 22:31:34 2018
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1. AS43142 portevlan.adeli.biz 0.0% 100 0.3 0.7 0.2 5.0 1.0
2. AS29075 sw1-le9lyon-ge-1-4.ix-customers-le9lyon.ielo.net 0.0% 100 1.3 3.3 1.2 51.9 6.3
3. AS??? frpar-th2-a9k1.as29075.net 1.0% 100 7.7 7.6 7.4 8.3 0.0
4. AS??? appliwave-dc3.par.franceix.net 0.0% 100 6.9 6.8 6.5 19.7 1.3
5. AS200780185.217.200.18 0.0% 100 8.8 7.3 6.6 59.6 5.3
6. AS??? 10.1.0.158 2.0% 100 8.8 7.2 7.0 8.8 0.3
7. AS200780130.117.11.5 0.0% 100 8.9 7.3 7.0 9.2 0.3
Adeli / Maxnod dans l'Ain IPv6 : Transit Ielo aussi avant de passer sur France-IX
$ mtr -z6rwc100 milkywan.fr
Start: Mon Feb 26 22:34:40 2018
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1. AS43142 bgp1.adeli.biz 0.0% 100 0.3 0.6 0.2 7.9 1.1
2. AS29075 cr5.rt.ielo.net 0.0% 100 10.7 8.8 6.6 79.9 7.8
3. AS29075 frpar-th2-a9k1.as29075.net 1.0% 100 8.3 8.5 8.2 15.1 0.7
4. AS??? appliwave-dc3.par.franceix.net 95.0% 100 8.2 8.3 8.2 8.8 0.0
5. AS2007802a05:46c0:0:210::5 0.0% 100 8.2 9.0 8.2 73.2 6.5
6. AS57199 saturn.dc3.milkywan.network 1.0% 100 8.4 8.9 8.3 27.2 2.3
7. AS57199 web.milkywan.space 2.0% 100 8.4 8.8 8.4 24.9 1.7
Ikoula Reims IPv4 : Peering France-IX
$ mtr -z4rwc100 milkywan.fr
Start: Mon Feb 26 22:32:26 2018
HOST: ikoula Loss% Snt Last Avg Best Wrst StDev
1. AS21409 ik063002.ikoula.com 0.0% 100 0.6 9.9 0.3 665.7 66.7
2. AS21409 eth-trunk2.core16.ikdc1.ikoula.com 0.0% 100 1.1 21.0 0.8 391.5 65.6
3. AS21409 eth-trunk14.core14.ikdc1.ikoula.com 0.0% 100 1.0 8.4 0.8 479.8 52.7
4. AS21409 po2.core13.ikdc2.ikoula.com 0.0% 100 3.8 9.0 3.3 202.3 29.2
5. AS21409 po3.core12.ikdc2.ikoula.com 0.0% 100 1.1 2.8 1.1 89.1 9.1
6. AS21409 eth-trunk1.core15.rb.ikoula.com 0.0% 100 3.8 11.5 3.7 225.6 31.8
7. AS??? appliwave-dc3.par.franceix.net 0.0% 100 3.9 4.2 3.9 24.6 2.2
8. AS200780185.217.200.18 0.0% 100 4.1 4.2 3.9 14.3 1.3
9. AS??? 10.1.0.158 0.0% 100 4.8 5.2 4.3 53.6 5.1
10. AS200780130.117.11.5 0.0% 100 4.5 5.5 4.4 72.4 7.0
Ikoula Reims IPv6 : Peering France-IX même si le reverse du sot N°2 est incorrect.
$ mtr -z6rwc100 milkywan.fr
Start: Mon Feb 26 22:34:45 2018
HOST: ikoula Loss% Snt Last Avg Best Wrst StDev
1. AS21409 2a00:c70:1:213:246:63:0:1 0.0% 100 0.6 7.9 0.4 381.6 43.2
2. AS174 ikoula.demarc.cogentco.com 0.0% 100 1.2 24.2 0.8 395.9 73.3
3. AS21409 2a00:c70::1:13 0.0% 100 1.4 3.7 1.2 132.2 14.3
4. AS21409 2a00:c70::1:12 0.0% 100 1.7 2.5 1.2 38.5 5.7
5. AS??? ikoula.par.franceix.net 0.0% 100 4.1 12.9 3.8 325.3 45.7
6. AS??? appliwave-dc3.par.franceix.net 0.0% 100 4.1 4.1 3.9 5.8 0.2
7. AS2007802a05:46c0:0:210::5 0.0% 100 4.2 4.4 3.9 24.2 2.0
8. AS57199 saturn.dc3.milkywan.network 1.0% 100 4.5 5.0 4.3 29.8 2.8
9. AS57199 web.milkywan.space 1.0% 100 4.5 5.0 4.4 46.7 4.3
-
A quand le dégroupage des NRA alors ?
http://wholesalefrance.orange.fr/fr/Nos-offres/Solutions-Fixe-Grand-Public/Offre-Solutions-Fixe-Grand-Public/DSL-Collect-IP (http://wholesalefrance.orange.fr/fr/Nos-offres/Solutions-Fixe-Grand-Public/Offre-Solutions-Fixe-Grand-Public/DSL-Collect-IP)
http://wholesalefrance.orange.fr/fr/Nos-offres/Solutions-Infrastructures-de-Reseau/Offres-Solutions-Infrastructures-de-Reseau/Lien-Fibre-Optique-LFO (http://wholesalefrance.orange.fr/fr/Nos-offres/Solutions-Infrastructures-de-Reseau/Offres-Solutions-Infrastructures-de-Reseau/Lien-Fibre-Optique-LFO)
http://wholesalefrance.orange.fr/fr/Nos-offres/Solutions-Fixe-Grand-Public/Offre-Solutions-Fixe-Grand-Public/Acces-DSL-DSL-Access (http://wholesalefrance.orange.fr/fr/Nos-offres/Solutions-Fixe-Grand-Public/Offre-Solutions-Fixe-Grand-Public/Acces-DSL-DSL-Access)
Pas de Cisco, Juniper, Alcatel ? Va falloir lâcher un billet quand même.
-
Il est toujours possible d'avoir un AS 16bits ?
Yes !
Pour l'intéret, je l'ai expliqué ici ->
On a un ASN 16Bits (AS57199 donc) parce qu'on a des vieux routeurs (bigiron 4000 récupérés chez Hivane) avec lesquels j'aimerais jouer un jour, et que sur les Mikrotik, les communautés BGP étendues, nécéssaires avec un AS32B ne sont pas gérées.
Sinon pour les traceroute, on assigne pour l'instant le backbone en IP privées (vu qu'on a pas encore d'IPs à nous), c'est pour ça qu'il manque des Hops.
Je suis assez content de la connectivité qu'on a via Appliwave, mais bon, ça manque de multihoming quand même chez nous ::)
-
J'ai bien compris l’intérêt d'avoir un AS 16 bits (compatibilité avec plus de routeurs)
Par contre choisir un AS 32 bits cela a quel intérêt, a part ne pas pouvoir peerer avec ceux qui ont un vieux routeur ?
-
Ah pardon, j'ai mal lu !
Il y'a une pénurie 'relative' en 16 Bits, donc c'est mieux de passer en 32Bit par défaut, sauf contre indication.
Est-ce qu'il y'a encore beaucoup de vieux routeurs en circulation ? Le seul truc que je connaisse, c'est mes dinosaures de Bigiron 4K justement :D J'en ai croisé dans une salle à TH2 une fois, ça m'a surpris d'en voir encore en production !
-
Sympa ce que tu fais, en tous cas bravo, ca fait plaisir de voir des gens motivés.
-
Merci ! ;-)
-
Du coup on a monté notre premier peering avec Petrus (AS206155), ça m'a permis de tester mes templates de peering :D
-
sympa!
good luck dans ce projet :)
-
Très beau projet, bravo à vous !
-
Salut,
Sur le papier, c'est un super projet, bien fun, et que je suivrais avec attention... mais
...il y a un truc qui me dérange quand même : On parle de s'amuser, de bidouiller, d'expérimenter, sur le vrai Internet avec de vrais AS et tout et tout. Vous annoncez en IPv4 des plages d'IP très petites, donc vous contribuez à la multiplication du nombre de routes sur l'Internet dans son ensemble. Si tout le monde, tous les acteurs faisaient comme ça, le nombre de routes exploserai, et certains routeurs ne sauraient plus gérer. On sait déjà que des acteurs avec des routeurs un peu ancien ont énormèment de mal à gérer la taille actuelle d'une table de routage full view IPv4.
Vous n'êtes pas les premiers à faire ça, et ça me dérange à chaque fois en fait.
Leon.
-
Perso, je ne comprends pas tout mais j'admire la passion que vous mettez dans votre projet et c'est ce que j´en retiens ;)
-
Vous annoncez en IPv4 des plages d'IP très petites
Aujourd'hui ils n'ont pas d'IPv4 (les IPv4 sont à leur transitaire Appliwave, seul les IPv6 sont à MilkyWan => L'AS en IPv4 est différente de l'AS IPv6) donc il est fort probable que hors de peering que montes MilkyWan, les plages IPv4 sont agrégées avec les autres IP d'Appliwave.
-
Milkywan un projet sympa que l'on connait ici depuis un certain temps, mais qui semble donc se développer. A suivre...
-
De notre côté on est content de pouvoir aider une association dont l'objectif principale est la formation. En effet, je sais qu'il est compliqué de pouvoir bien tester pas mal de choses et que les cours ne sont plus adaptés à beaucoup de besoins ::)
Je suis assez content de la connectivité qu'on a via Appliwave
Et encore, on passe la deuxième pour améliorer ça ;).
-
,
Sur le papier, c'est un super projet, bien fun, et que je suivrais avec attention.
Merci ;)
Vous annoncez en IPv4 des plages d'IP très petites
Du tout !
Le /27 qui nous est routé n’est pas annoncé sur internet, c’est juste du temporaire le temps d’avoir un /24
Du coup non, je ne l’annonce nulle part, même pas en Peering, car ce ne sont pas mes IPs :)
-
Sinon merci pour vos messages sympa ;)
-
C'est un peu Hivane y'a 14 ans ;). Welcome on internet AS57199, et good luck pour la suite.
Et vive les transits/intercos en 10G, j'espère un jour arriver à architecturer Hivane avec des transports intersites + transits à 10G (mais y'a du boulot d'architecture à gérer avant :))
-
C'est un peu Hivane y'a 14 ans ;). Welcome on internet AS57199, et good luck pour la suite.
Merci ! C'est clair que je suis admiratif de ce que tu fais avec Hivane, mais ça tu le sais déjà :p
Et vive les transits/intercos en 10G, j'espère un jour arriver à architecturer Hivane avec des transports intersites + transits à 10G (mais y'a du boulot d'architecture à gérer avant :))
Yay ! On va voir si on arrive à se développer comme ça aussi :)
-
Salut,
Sur le papier, c'est un super projet, bien fun, et que je suivrais avec attention... mais
...il y a un truc qui me dérange quand même : On parle de s'amuser, de bidouiller, d'expérimenter, sur le vrai Internet avec de vrais AS et tout et tout. Vous annoncez en IPv4 des plages d'IP très petites, donc vous contribuez à la multiplication du nombre de routes sur l'Internet dans son ensemble. Si tout le monde, tous les acteurs faisaient comme ça, le nombre de routes exploserai, et certains routeurs ne sauraient plus gérer. On sait déjà que des acteurs avec des routeurs un peu ancien ont énormèment de mal à gérer la taille actuelle d'une table de routage full view IPv4.
Vous n'êtes pas les premiers à faire ça, et ça me dérange à chaque fois en fait.
Leon.
Salut,
Sauf que nous sommes en 2018, et il n’est plus si simple d’obtenir des IPs qu’il y a 5 ou 10 ans. Donc même sur des ASes « commerciaux », il n’est pas forcèment si simple d’annoncer moins spécifique que du /24, simplement parce que l’on peut très bien n’avoir qu’un /24.
Et si tu as un routeur qui ne sait pas gérer autant de routes, tu peux très bien demander à tes transitaires de t’annoncer une route par défaut et de filtrer au /23 ou /22, personne n’a jamais été forcé d’installer 700k routes en FIB.
-
Non, mais que MW annonce son /24 qu'elle aura acquis via un tiers-LIR, ou son /22 qu'elle aura acquis en devenant LIR, il n'en demeure pas moins que c'est une route (légitime) en plus dans la DFZ, comme des milliers d'autres, et on ne peut pas le leur interdire, fort heureusement
L'important est surtout que ca ne fasse pas du flip-flop à outrance pendant les bidouilles des gens qui expérimentent: un flap sur un transit = une update BGP sur tous les routeurs du nainternet, et un flap sur un peering = une update BGP chez tes peers.
Faut penser qu'on n'est plus tout seul, même si les impacts ressentis sont souvent locaux :)
-
Salut!
Quand vous êtes chez Cogent à Rennes pas de soucis pour s'interco avec Breizh-IX! on a encore de la place sur le bandeau pour les crossco ^^
-
Je pense que Leon pensait surtout à mon /27, mais je ne compte pas l'annoncer nulle part (heureusement) !
-
Ca serait un peu vain en effet, d'annoncer un /27 sur internet :-D
-
D’après le lg du ring, y’en a qui le font :p
bird> show route count primary where net.len = 27
2259 of 827321 routes for 827321 networks
bird> show route count primary where net.len > 24
99147 of 827336 routes for 827336 networks
-
Joli projet, cela donne envie de participer
-
D’après le lg du ring, y’en a qui le font :p
Oui, certes, mais la visibilité d'un petit préfixe sur la LG du ring, ne présage pas de la visibilité globale dudit préfixe sur internet.
Ceux qui montent des peerings avec la LG du ring peuvent y annoncer n'importe quoi (y compris des préfixes internes, qui ne devraient pas être annoncés, faute assez commune en BGP :))
-
En effet :)
(je viens de vérifier, j’ai réussi à ne pas faire la connerie pour grifon :p)
Il y a l’air d’y avoir une étude un peu plus sérieuse que trois commandes dans un LG ici : https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-prefixes
-
Très beau projet, ça fait plaisir à voir autant de passion et cette soif d'apprendre !!!
Bonne continuation !
-
Hello, je voyais MW ou surtout Hugues sur twitter sans trop d'info sur MW à me demander ce que ça représente, merci pour la présentation :)
Tu parles budget et notamment des investissements personnels pour financer l'infra, des ordres d'idées à partager ? ::)
Dans tous les cas bon courage pour la suite !
-
Je ne sais pas, je dirais qu'on a laché environ 1000€ là, sans compter les serveurs qu'on loue chez Online (qui sont amenés à disparaitre) et le Housing (que je payerai de ma poche) et qu'on va lâcher environ 3000€ en matos d'ici Avril (Serveurs (dont ram, ssd), routeurs, consommable fibre, etc...)
Après, sur tout ce que j'ai dépensé depuis que MW existe ? Je préfère ne pas essayer de compter xD
-
Merci à tous pour votre soutien :)
-
Waaah la classe 8) l'AS 16 bits à l'ancienne !
Si tu viens sur Cogent Bordeaux (ha HAHA HAHA ha ha) on peut certainement peerer avec toi chez Aquilenet :p
-
Je peux venir sur Cogent Bordeaux oui ! Après si c'est juste pour un Peering ça aura pas grand intéret :p Y'a un IXP dans le coin ?
-
Pas encore… mais un jour peut-être ? :) Monter (ou aider à monter) un IXP, on a l'idée qui traîne depuis quelques années chez Aquilenet, mais ça bouge pas trop.
-
Si vous ressortez GirondIX du placard, pensez à réviser les prix parce que 3,1k pour un port 100Mbit/s la première année c'est un poil élevé ::)
http://www.girondix.net/pages/tarifs.html
En tout cas si vous voulez un coup de main, faites signe ! On peut avoir un partenaire pour descendre sur Bordeaux nous :)
-
Salut !
Beau projet, pleins d'ambitions et surtout, bravo pour accomplir et mettre sur papier votre passion.
Si jamais un jour vous avez besoin d'un coup de main/pied ou des petits conseils côté archi LAN DC, n'hésitez pas à toquer à ma porte.
Aujourd'hui je ne suis pas un grand expert dans le monde SP, mais ca fait déjà quelques années que je bosse dans le monde DC avec en ce moment une migration d'une infra LAN 3tier en Cisco Nexus vers une infra VXLAN. Peut-être qu'un jour cela pourra vous intéresser.
En tout cas, continuez comme ca!
-
cool, enfin la vérité sur MilkyWan ! projet cool et doc intéressante :D
bon, du coup je m'aperçois que je bite pas grand chose à ce que tu racontes ... le réseau c'est pas pour les sysadmin :o
have fun !
-
le réseau c'est pas pour les sysadmin :o
Et inversement ! Mais c'est complèmentaire, c'est sympa de faire un réseau full 10G, mais si c'est pour n'avoir aucun traf, ça perd son sens ;)
-
Et la partie sys est celle qui coute de loin le plus cher...
-
Et la partie sys est celle qui coute de loin le plus cher...
Ah bon ? Attends d'avoir des vrais switches & routeurs, et tu vas sûrement réviser ton jugement :-)
-
Ah bon ? Attends d'avoir des vrais switches & routeurs, et tu vas sûrement réviser ton jugement :-)
J'ai regardé les coûts pour des Junip MX5/10, je crois qu'on vas rester sur du MKT pour le moment o/
(Ou alors si jamais quelqu’un d'ici souhaite s'en débarrasser hein, on sait jamais).
-
Sans parler d'acheter des MX, des routeurs 10G, c'est pas monnaie courante pour une densité raisonnable ;-)
-
Alors je ne comprends pas grand chose (et c'est peu de le dire) mais quoiqu'il en soit, je vous tire mon chapeau et vous souhaite bon courage pour la suite de vos aventures :P
-
On vient de monter un Looking Glass avec Gaëtan :)
Have fun :)
https://lg.milkywan.fr/detail/dc2/ipv6?q=dc2
-
Cool !
Pour tout ceux qui utiliseraient bird-lg, si vous faites des modifs dessus, publiez vos modifs svp, et de preference sur les sources d'origine (de sileht). J'ai vu beaucoup de modifs faites a droite et a gauche, mais soit pas publiques, soit sur des forks, et c'est dommage parceque bien souvent ca pourrait servir a tout le monde.
</PSA>
-
Sans parler d'acheter des MX, des routeurs 10G, c'est pas monnaie courante pour une densité raisonnable ;-)
Si tu fais pas full-table (genre 256K OK), si.
Si tu n'a pas de probleme d'espace et d'elec, si.
... il faut juste avoir les poches assez bien remplies (encore plus si tu veux full-table).
Pour le premier c'est limite meme pas abusivement cher.
-
Ah evidemment, je parle de notre cas : Soit en récup, soit pour (vraiment) pas cher ;-)
-
C'est super ce que tu fais , de passage à Paris un jour, tu me raconterais/détaillerais ça autour d'un verre ? :-)
-
Je vis en région parisienne, donc c'est possible oui !
-
Hello,
La Weathermap est a jour :)
https://weathermap.milkywan.fr/milkywan.html
-
Hello,
La Weathermap est a jour :)
https://weathermap.milkywan.fr/milkywan.html
Mmm le lien ne semble pas (plus ?) fonctionner ?
-
Ça marche chez moi, depuis un TGV :)
-
Ah, problème quelque part alors :
-
Ça marche depuis chez moi (Bouygues) et en 4g (sosh). Un traceroute depuis sfr ?
Edit:ça ressemble à un problème dns... Quels dns utilises tu ? Ceux de sfr ?
-
Ca ressemble surtout a un souci de serveur web sous iOS, ça ne marche pas non plus sur mon iPad. Étrange.
-
Ok résolu.
C'était ce souci : http://forum.directadmin.com/showthread.php?t=55803
Et j'ai résolu en ajoutant la ligne "proxy_hide_header Upgrade;" dans nginx.conf.
Aucune idée de pourquoi/comment... :)
-
Hello !
Petite mise a jour, on a publié les tarifs de nos offres sur le site. https://milkywan.fr/prices
Grosso modo, on propose pour le moment : Du VPN, du transit IP, des VM et du Housing.
Si ça vous tente, faites un petit mail via le formulaire, et on s'occupe de vous :)
PS : Je rappelle qu'on est ouverts à sponsoriser des projets, donc si vous avez un projet sympathique, faites un mail aussi :)
-
Tu as oublié de préciser la taille du serveur : un Raspberry Pi ou un serveur tour, c'est le même prix ?
Quelle est la limitation en terme de transit ? Port 100 Mb/s full ? 1 Gb/s full ?
Pour l'IPv4 Nat : il y a possibilité d'ouvrir un ou plusieurs ports, sous réserve de disponibilité ? (si oui, il pourrait être pertinent de spécifier le nb de port qu'il est possible d'ouvrir gratuitement et de fixer un prix pour le port 80 et le port 443 par exemple 1€/mois chacun)
Je sais que MilkyWan est assez ouvert, mais plus de détails dans le cadre fixé serait intéressant.
Le copier / coller du site actuel :
Hébergement à Paris Iliad DC2 ou à Paris Leonix Bourse, dans une baie mutualisée à partir de 70€/mois.
Hébergement dans une baie mutualisée sur un des Datacenters suivant :
- Paris Iliad DC2
- Paris Leonix Bourse
Accès possible sur RDV Et Accompagné (gratuit)
Alimentation : 0,3Kva max
Transit inclu (IPv4 NAT et /48 IPv6))
-
C’est pour 1U, mais on peut discuter si besoin d’autre chose.
On fournit 100 ports en A+P. Pour le transit, c’est livré sur port 1G, et c’est du best effort, en bonne intelligence :)
Non, je ne vais pas faire payer plus cher certains ports, si tu veux des ports, tu prends une IPv4 à 2,5€\mois et puis voilà, sinon c’est trop galère à gérer :)
-
Quel équipement permet de faire le A+P, si ce n'est pas indiscret ?
Cela permet 655 clients sur une même IPv4, c'est bien ça ?
-
N'importe quel routeur qui sait faire du NAT. Un Mikrotik en l'occurence.
Théoriquement oui, en pratique, on en est loin :)
-
Petit update !
MilkyWan est maintenant présent à TH2 (en 22-16 et 12E2B pour ceux que ça intéresse) et à Leonix Bourse (Dans la baie associative).
On va avoir quelques transits, peerings et PNIs sur les deux sites :
Transits :
Peerings :
- Rezopole Paris
- LillIX
- Equinix-IX
PNIs :
On va aussi monter des portes de collecte avec Leonix et AppliWave, pour pouvoir proposer de l'ADSL, du VDSL, et surtout du FTTH chez Bouygues (quand l'offre sortira), on aura aussi de la collecte Orange FTTH et SFR FTTH quand les offres sortiront, un jour peut-être.
Faites signe si de l'ADSL vous intéresse en tout cas, on va avoir besoin de beta testeurs :)
La Weathermap est déjà à jour avec les modifications :
https://weathermap.milkywan.fr/milkywan.html
(https://weathermap.milkywan.fr/milkywan.html)
Quelques petites photos des installations :)
TH2 :
(https://stuff.milkywan.fr/pix/th2brs/th2_1_mini.jpg) (https://stuff.milkywan.fr/pix/th2brs/th2_1.jpg)
(https://stuff.milkywan.fr/pix/th2brs/th2_2_mini.jpg) (https://stuff.milkywan.fr/pix/th2brs/th2_2.jpg)
Bourse :
(https://stuff.milkywan.fr/pix/th2brs/brs_1_mini.jpg) (https://stuff.milkywan.fr/pix/th2brs/brs_1.jpg)
Et en bonus, un petit passage en faux plancher à TH2 :p
(https://stuff.milkywan.fr/pix/th2brs/th2_3_mini.jpg) (https://stuff.milkywan.fr/pix/th2brs/th2_3.jpg)
-
Le bonus c'est... Ed Sheeran qui fait le cablage ? 8) ;D ;D ;)
-
Oh un vieux Netscreen. :D
Les photos sont sympa.
-
Elle n'a pas bobo la fibre en haut à droite dans le lovage ?
-
Le faux planch de TH2, c'est la guerre, donc tu as aussi des fibres tombées au combat, en effet :(
-
Dans la baie au dessus de l'écran du mikrotik je veux dire
-
Ah celle là ! Non pas vraiment, c'est juste une duplex 1m, donc ça supporte bien les contraintes, et j'ai des valeurs tout à fait normales en DOM :)
-
Bonjour bonjour !
Nous sommes maintenant présents à Rennes !
Grifon nous héberge bien gentiment dans leur baie (https://lafibre.info/fournisseurs-dacces-a-internet-associatif/grifon-fai-associatif/), au DC Cogent.
(https://pix.milkywan.fr/2xJmwfDK.jpg)
Merci à Quantic qui nous fournit le L2L pour nous relier à TH2, et à Manuel Guesdon pour sa rapidité à tirer le crossco (on a réussi à faire 3 jours entre la commande et la prod du lien !)
On peere evidemment sur le Breizh-IX (https://lafibre.info/gix/breizhix) :D
On va aussi fournir du transit partiel à quelques AS du coin pour leur faire profiter de nos ports IXP :)
La Weathermap est à jour !
(https://weathermap.milkywan.fr/images/milkywan.png)
@+
Hugues
-
Hé beh, Milkywan se développe bien (au moins son réseau) !
-
Plutôt oui ! Ouvrir TH2 nous a permis de concrétiser plein de petits projets qui étaient en suspens depuis quelques temps :)
-
Petrus... C'est notre ami Petrus qui joue aussi avec ses routeurs? Il a des routeurs à lui en datacenter à Rennes?
https://lafibre.info/switch/vos-installations-reseau/msg305876/#msg305876
Sinon, pour comprendre : c'est exclusivement des "dons" et du mécénat qui vous permet de vous développer autant? Un L2 de 1 ou 10Gbps qui traverse la France, ça n'est pas gratuit.
Pour les 3 sites DC2, TH2 et VNX (Lyon Venissieux), je pense que c'est du mécénat AppliWave.
Leon.
-
Petrus... C'est notre ami Petrus qui joue aussi avec ses routeurs? Il a des routeurs à lui en datacenter à Rennes?
Tout a fait, il a même un AS !
Sinon, pour comprendre : c'est exclusivement des "dons" et du mécénat qui vous permet de vous développer autant? Un L2 de 1 ou 10Gbps qui traverse la France, ça n'est pas gratuit.
Pour les L2L, Uniquement oui ! Pour le reste, on a aussi quelques clients et on met aussi de l'argent perso pour acheter du matos.
J'ai la chance d'avoir des très gentils sponsors ! ;-)
-
C'est des dons uniquement pour les L2? Pour les L2 (hors Rennes), c'est bien AppliWave le mécène?
Pour l'hébergement sur les 5 POPs, ça n'est pas du mécénat? J'avais l'impression que si...
La place dans les baies, l'énergie ?
Appliwave étant aussi un "transitaire" pour vous, non? Gratos aussi?
Du coup, vous payez quoi réellement? Le matos, et les cross-connect en datacenter et c'est tout?
En tout cas, c'est un beau projet!
Leon.
-
C'est des dons uniquement pour les L2? Pour les L2 (hors Rennes), c'est bien AppliWave le mécène?
Pour l'hébergement sur les 5 POPs, ça n'est pas du mécénat? J'avais l'impression que si...
La place dans les baies, l'énergie ?
Du coup, vous payez quoi réellement? Le matos, et les cross-connect en datacenter et c'est tout?
Alors, ce qui est du don/échange de bons procédés :
* Les L2L
*Une partie du matos
*la place en POP.
* La FON Bourse-TH2
* Les ports IXP
Ce qu'on paie :
*Une partie du matos (consommables, optiques, certains routeurs, les serveurs et les disques dedans)
*L'hébergement à TH2
En tout cas, c'est un beau projet!
Merci :D
-
C'est des dons uniquement pour les L2? Pour les L2 (hors Rennes), c'est bien AppliWave le mécène?
Pour l'hébergement sur les 5 POPs, ça n'est pas du mécénat? J'avais l'impression que si...
La place dans les baies, l'énergie ?
Appliwave étant aussi un "transitaire" pour vous, non? Gratos aussi?
Du coup, vous payez quoi réellement? Le matos, et les cross-connect en datacenter et c'est tout?
En tout cas, c'est un beau projet!
Leon.
Effectivement on "aide" MilkyWan avec ce que l'on peut. On le propose aussi à d'autres associations quand on peut ;)
Aujourd'hui donner du L2 entre plusieurs points en France pour nous, avec si peu de traf réellement utilisé ça nous coûte presque rien ;). En échange on a de bons services de la part des gars de MilkyWan sur certaines choses... ;)
-
Hello !
On a reçu notre premier /24 (80.67.167.0/24) du LIR Gitoyen !
Il n'est pas encore annoncé globalement pour le moment (un souci de ROA et des LOA à envoyer), mais ça arrive :)
PS pour Vivien, la .1 ping :)
-
Orange Melun (77) :
$ mtr -zrwc100 80.67.167.1
Start: Sun Aug 26 17:13:01 2018
HOST: Orange Loss% Snt Last Avg Best Wrst StDev
1. AS??? livebox.home 0.0% 100 0.4 0.5 0.4 1.8 0.1
2. AS??? 80.10.233.189 0.0% 100 2.0 2.0 1.8 3.1 0.1
3. AS??? ae116-0.ncidf303.Aubervilliers.francetelecom.net 0.0% 100 2.7 3.0 2.6 7.6 0.8
4. AS??? ae43-0.nridf301.Paris15eArrondissement.francetelecom.net 0.0% 100 3.0 3.1 2.8 11.9 1.1
5. AS??? ae44-0.noidf001.Paris3eArrondissement.francetelecom.net 0.0% 100 3.0 3.6 2.9 18.0 1.8
6. AS??? 193.253.13.206 0.0% 100 2.9 3.0 2.4 4.3 0.1
7. AS??? lag-th2-1.dc3-2a.rt.hopus.net 0.0% 100 3.3 3.3 3.2 4.2 0.0
8. AS??? appliwave.dc3-2.rt.hopus.net 0.0% 100 3.4 8.1 3.3 154.7 20.8
9. AS200780 185.217.202.77 0.0% 100 4.2 7.5 4.0 154.6 19.1
10. AS20766 80.67.167.1 0.0% 100 4.4 4.4 4.3 5.1 0.0
SFR câble Paris :
$ mtr -zrwc100 80.67.167.1
Start: 2018-08-26T17:10:04+0200
HOST: SFR Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 100 0.3 0.3 0.2 0.8 0.1
2. AS??? ? ? 100.0 100
3. AS21502 evy1rj-ge-1-1-5.200.numericable.net 0.0% 100 6.6 10.0 5.7 68.6 10.4
4. AS??? 172.19.132.146 0.0% 100 9.6 13.6 6.7 42.5 5.9
5. AS29075 gitoyen.ix-customers-th2.ielo.net 0.0% 100 9.4 12.3 6.9 136.5 16.7
6. AS??? equinix-ix.th2.infra.integral-connect.net 0.0% 100 10.5 15.0 7.5 194.6 22.5
7. AS20766 80.67.167.1 2.0% 100 16.9 17.3 14.5 45.6 4.9
Bouygues Teleco Paris :
$ mtr -zrwc100 80.67.167.1
Start: Sun Aug 26 17:11:29 2018
HOST: Bouygues Loss% Snt Last Avg Best Wrst StDev
1. AS5410 194.158.119.185 0.0% 100 0.4 1.4 0.3 103.1 10.3
2. AS5410 1.la10.bsr02-ix2.net.bbox.fr 0.0% 100 0.4 0.3 0.3 0.8 0.0
3. AS5410 be11.cbr01-cro.net.bbox.fr 0.0% 100 8.2 8.5 7.4 9.7 0.3
4. AS5410 be5.cbr01-lyo.net.bbox.fr 0.0% 100 9.8 11.0 7.1 15.0 2.2
5. AS5410 la44.bsr01-lyo.net.bbox.fr 69.0% 100 6.9 7.0 6.9 7.1 0.0
6. AS5410 la10.bsr02-lyo.net.bbox.fr 0.0% 100 7.0 7.0 6.9 7.3 0.0
7. AS??? 193.253.12.9 0.0% 100 7.8 7.5 7.3 18.7 1.1
8. AS??? ae40-0.nolyo101.Lyon3eArrondissement.francetelecom.net 0.0% 100 7.4 7.5 7.4 16.9 0.9
9. AS??? 193.252.227.98 0.0% 100 7.6 7.9 7.5 15.3 1.3
10. AS??? lag-ly-1.th2-1.rt.hopus.net 0.0% 100 7.4 7.4 7.4 7.5 0.0
11. AS??? lag-th2-1.dc3-2a.rt.hopus.net 0.0% 100 7.7 7.6 7.6 7.7 0.0
12. AS??? appliwave.dc3-2.rt.hopus.net 0.0% 100 7.8 10.0 7.7 130.9 13.4
13. AS200780185.217.202.77 0.0% 100 8.4 10.5 8.3 123.2 14.5
14. AS20766 80.67.167.1 0.0% 100 8.6 8.6 8.6 8.7 0.0
Adeli dans l'Ain :
$ mtr -zrwc100 80.67.167.1
Start: Sun Aug 26 17:10:38 2018
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1. AS43142 portevlan.adeli.biz 0.0% 100 0.3 41.9 0.2 1754. 219.8
2. AS29075 sw1-le9lyon-ge-1-4.ix-customers-le9lyon.ielo.net 0.0% 100 1.3 2.6 1.1 23.6 3.5
3. AS??? ielo.ly-1.rt.hopus.net 0.0% 100 7.5 7.6 7.2 16.9 1.6
4. AS??? lag-ly-1.th2-1.rt.hopus.net 0.0% 100 7.1 7.2 7.1 7.7 0.0
5. AS??? lag-th2-1.dc3-2a.rt.hopus.net 0.0% 100 7.5 7.5 7.4 8.1 0.0
6. AS??? appliwave.dc3-2.rt.hopus.net 0.0% 100 10.1 16.6 10.0 171.1 26.4
7. AS200780185.217.202.77 0.0% 100 10.8 11.5 10.6 49.9 4.3
8. AS20766 80.67.167.1 0.0% 100 8.6 8.7 8.5 12.7 0.4
-
Yes, pour l'instant on n'est joignable que par Hopus, les seuls à utiliser les objets routes pour leurs filtres.
-
Numericable, cela ne passe pas par Hopus
-
Ah oui bien vu. Il n'y a pas de sécurités sur le RS d'Equinix-IX du coup, faut croire :p
-
Numericable (213.245.128.0/17) Istres (13):
ubnt@gateway:~$ mtr -rwc100 80.67.167.1
HOST: gateway Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.100.176.1 0.0% 100 45.0 7.4 4.3 45.0 6.7
2.|-- ip-182.net-80-236-6.static.numericable.fr 0.0% 100 5.0 8.5 4.3 70.2 10.0
3.|-- 172.19.132.146 1.0% 100 24.9 24.2 19.0 34.2 2.9
4.|-- gitoyen.par.franceix.net 6.0% 100 19.4 20.4 18.1 29.5 2.2
5.|-- equinix-ix.th2.infra.integral-connect.net 0.0% 100 23.7 28.8 19.3 213.2 34.0
6.|-- 80.67.167.1 0.0% 100 19.9 21.6 19.0 50.1 4.0
Orange FTTH FBN (86.229.0.0/17) Marseille (13):
ubnt@AstriaPorta:~$ mtr -rwc100 80.67.167.1
HOST: AstriaPorta Loss% Snt Last Avg Best Wrst StDev
1.|-- 80.10.234.97 8.0% 100 8358. 2109. 58.3 9282. 3326.7
2.|-- lag-109.ncmar202.Marseille3eArrondissement.francetelecom.net 61.0% 100 1.0 2.7 0.6 20.7 4.0
3.|-- ae43-0.nrmar102.Marseille3eArrondissement.francetelecom.net 0.0% 100 1.0 2.2 0.5 11.1 2.1
4.|-- ae44-0.nrlyo202.Lyon3eArrondissement.francetelecom.net 0.0% 100 4.5 7.0 4.5 33.6 4.7
5.|-- ae40-0.nrlyo201.Lyon3eArrondissement.francetelecom.net 0.0% 100 5.0 6.6 4.6 21.9 3.0
6.|-- ae43-0.nolyo101.Lyon3eArrondissement.francetelecom.net 0.0% 100 4.7 6.5 4.5 38.1 4.5
7.|-- 193.252.227.98 0.0% 100 5.4 7.3 4.7 37.1 4.8
8.|-- lag-ly-1.th2-1.rt.hopus.net 0.0% 100 30.5 12.1 10.3 35.0 3.6
9.|-- lag-th2-1.dc3-2a.rt.hopus.net 0.0% 100 12.5 12.9 10.4 53.4 5.7
10.|-- appliwave.dc3-2.rt.hopus.net 0.0% 100 11.3 14.3 10.7 168.7 15.9
11.|-- 185.217.202.77 0.0% 100 11.3 17.5 11.3 180.5 24.2
12.|-- 80.67.167.1 0.0% 100 15.3 14.0 11.6 32.4 4.1
Tiens Orange tente de livrer à Hopus sur Lyon.
-
Depuis ADSL SFR ça passe bien par Hopus :
Détermination de l’itinéraire vers 80.67.167.1 avec un maximum de 30 sauts.
1 1 ms <1 ms <1 ms 192.168.1.1
2 6 ms 5 ms 6 ms 1.84.135.77.rev.sfr.net [77.135.84.1]
3 11 ms 7 ms 6 ms 49.184.154.77.rev.sfr.net [77.154.184.49]
4 7 ms 7 ms 6 ms 189.147.154.77.rev.sfr.net [77.154.147.189]
5 6 ms 7 ms 6 ms 157.93.20.93.rev.sfr.net [93.20.93.157]
6 11 ms 11 ms 10 ms 146.93.20.93.rev.sfr.net [93.20.93.146]
7 23 ms 14 ms 14 ms 46.128.136.77.rev.sfr.net [77.136.128.46]
8 27 ms 25 ms 25 ms 1.128.136.77.rev.sfr.net [77.136.128.1]
9 26 ms 25 ms 25 ms 1.128.136.77.rev.sfr.net [77.136.128.1]
10 27 ms 25 ms 26 ms sfr.th2-2.rt.hopus.net [37.77.34.28]
11 26 ms 26 ms 25 ms lag-th2-1.dc3-2a.rt.hopus.net [37.77.32.47]
12 25 ms 25 ms 25 ms appliwave.dc3-2.rt.hopus.net [37.77.36.23]
13 26 ms 25 ms 26 ms 185.217.202.77
14 22 ms 21 ms 22 ms 80.67.167.1
Itinéraire déterminé.
-
Tiens Orange tente de livrer à Hopus sur Lyon.
Cela fait des années... et cela fout la grouille sur le PNI Orange Bouygues Telecom. Tout le trafic Bouygues Telecom => Hopus passe par Orange Lyon puis Hopus Lyon, cela se voit sur mon traceroute Bouyuges.
-
Bouygues a du transit Orange ? Je ne vois pas de raison pour qu’Orange ré-annonce Hopus sur ce PNI sinon.
-
En même temps Free était bien joignable en passant par Hopus via Orange. J'imagine que ça un intérêt pour Orange (augmenter le trafic entrant via Hopus ?).
-
Ah oui bien vu. Il n'y a pas de sécurités sur le RS d'Equinix-IX du coup, faut croire :p
Non on a une session avec Gitoyen :)
-
Les seules routes du genre que je vois sur le LG du ring, c’est tetaneutral qui passe par Orange pour toucher un bout de Free :
bird> show route count where bgp_path ~ [= * 5410 3215 * =]
0 of 54741076 routes for 838944 networks
bird> show route count where bgp_path ~ [= * 3215 5410 * =]
0 of 54741242 routes for 838943 networks
bird> show route count where bgp_path ~ [= * 12322 3215 * =]
0 of 54739759 routes for 838905 networks
bird> show route count where bgp_path ~ [= * 3215 12322 * =]
6 of 54739025 routes for 838856 networks
bird> show route where bgp_path ~ [= * 3215 12322 * =]
78.192.0.0/11 unreachable [TETANEUTRAL1 17:02:37 from 91.224.149.152] (100/-) [AS12322i]
82.240.0.0/12 unreachable [TETANEUTRAL1 17:02:37 from 91.224.149.152] (100/-) [AS12322i]
88.176.0.0/12 unreachable [TETANEUTRAL1 17:02:37 from 91.224.149.152] (100/-) [AS12322i]
78.224.0.0/11 unreachable [TETANEUTRAL1 17:02:37 from 91.224.149.152] (100/-) [AS12322i]
82.224.0.0/12 unreachable [TETANEUTRAL1 17:02:37 from 91.224.149.152] (100/-) [AS12322i]
88.160.0.0/12 unreachable [TETANEUTRAL1 17:02:37 from 91.224.149.152] (100/-) [AS12322i]
-
Non on a une session avec Gitoyen :)
Aucun rapport puisque le traceroute fait Numéricable -> MilkyWan :p
-
Bouygues a du transit Orange ? Je ne vois pas de raison pour qu’Orange ré-annonce Hopus sur ce PNI sinon.
Les métriques vers les routeurs pour connecter les clients (BSR) sont plus faibles que pour les routeurs de transit/peering (RTP).
Sur Lyon il n'y a pas de routeur de transit/peering, ce qui signifie que toutes les annonces sur un peering de Lyon seront prioritaires sur les autres peering / transit.
=> tout le trafic de Bouygues Telecom vers Orange sort sur Lyon (inversement il Orange envoi sur le PNI au plus proche)
Maintenant pourquoi Orange annonce Hopus à Bouygues ?
Pour Orange, Hopus est un client de AS3215, comme un autre. Il est donc annoncé a ses peer.
Financièrement ce n'est pas rentable pour Orange qui doit payer le trafic vers Hopus de Bouygues alors que le trafic entrant passe probablement en direct Hopus => Bouygues sur un GIX (à vérifier)
-
Aucun rapport puisque le traceroute fait Numéricable -> MilkyWan :p
Sauf erreur si ! Vu que ton /24 n’est pas dans leur DFZ ça va vers le /19 de Gitoyen !
J’ai faux ?
-
Putain ouais, laisse tomber, pas les yeux en face des trous ce soir :-\
-
Maintenant pourquoi Orange annonce Hopus à Bouygues ?
Pour Orange, Hopus est un client de AS3215, comme un autre. Il est donc annoncé a ses peer.
Financièrement ce n'est pas rentable pour Orange qui doit payer le trafic vers Hopus de Bouygues alors que le trafic entrant passe probablement en direct Hopus => Bouygues sur un GIX (à vérifier)
Intéressant, je ne savais pas qu’Hopus était considéré comme un client. Et c’est assez étrange vu le modèle économique d’Hopus, en effet.
-
Petrus... C'est notre ami Petrus qui joue aussi avec ses routeurs? Il a des routeurs à lui en datacenter à Rennes?
https://lafibre.info/switch/vos-installations-reseau/msg305876/#msg305876
Tout a fait, il a même un AS !
Et sinon, c'est quoi le réseau de Petrus? Il héberge des serveurs? C'est documenté un peu quelque part? Si c'est un réseau "associatif" ou équivalent, ça serait sympa de documenter un minimum.
Leon.
-
Je crois que c'est juste un /48 ipv6 chez lui, mais il en parlera mieux que moi :)
-
Petrus... C'est notre ami Petrus qui joue aussi avec ses routeurs? Il a des routeurs à lui en datacenter à Rennes?
https://lafibre.info/switch/vos-installations-reseau/msg305876/#msg305876
Tout a fait, il a même un AS ! Et sinon, c'est quoi le réseau de Petrus? Il héberge des serveurs? C'est documenté un peu quelque part? Si c'est un réseau "associatif" ou équivalent, ça serait sympa de documenter un minimum.
Je suis démasqué !
En effet j'ai mon as (206155) et mon préfixe ipv6. Rien d'associatif, c'est pour ma conso personnelle :D
J'ai mis à jour le topic sur les installations perso (https://lafibre.info/switch/vos-installations-reseau/msg571339/#msg571339) avec une rapide description histoire de pas polluer le topic sur MW :)
-
Hello !
Je n'ai pas mis à jour le sujet depuis quelques temps, mais vu que je suis passé faire un peu de ménage au data, voici une petite photo de notre infra Réseau et Systèmes à Bourse, chez Leonix.
(https://pix.milkywan.fr/Tzu5hhYc.jpg)
Vous pouvez voir de bas en haut :
- Le routeur BGP, un CCR1009 avec 1x10G
- Un EdgeCore 48x10G & 4x40G qui fait de l'agreg de 10G pour le CCR, gentiment prêté par CERIZ, qui sera remplacé par un CRS317 quand j'aurais le temps
- Un Cisco 2960G qui sert principalement aux serveurs en dessous
- Un Cisco 7301, qui sert de LNS (Pour les abonnements L2TP)
- Un RB3011, qui sert de routeur de service pour les VM, et qui fait terminaison L2TP/GRE avec NAT
- Un DL360G7, avec 192Go de RAM et un Xeon X5650 12 coeurs 24 Threads
- Un NAS Thecus Pro avec 36To bruts de stockage
- Un DL360G6 avec 144Go de RAM et un Xeon E5530 avec 8 coeurs 16 Threads
À venir ici :
- Un transit 10G par Leonix Telecom
- Un PNI avec Gitoyen
- Un PNI avec Ceriz
- Une collecte L2TP par Leonix Telecom
- La FON qui va venir de chez moi dans le 15è
- Un L2L vers Lyon
- Un L2L vers PA2 (prochain site qu'on va POPer)
- Une collecte L2TP par un autre sponsor
Voilà voilà :)
-
Sympa le NAS :-)
-
Vous pouvez voir de bas en haut :
C'est plutôt de haut en bas, non ?
-
Jolie. Ce n'est que du don le matériel ?
-
Belle infrastructure.
Cela ne dois pas être une configuration très économe en énergie (les CPU des serveurs sont anciens).
-
Ça marche c’est l’essentiel :-)
-
- Le routeur BGP, un CCR1009 avec 1x10G
C'est pas trop galère pour avaler une full table ? Surtout si tu comptes ajouter un transit supplèmentaire ?
-
Pas plus pas moins que n'importe quel CCR, j'en ai aussi un à Venissieux qui se mange transit+peering+iBGP, il ne bronche pas :)
-
C'est bien connu que le multithreading sur RouterOS, ce n'est pas trop leur fort... :-)
-
MilkyWan est maintenant LIR !
Nous avons reçu quelques IP :
45.13.104.0/22
2a0e:e700::/29
8)
-
Félicitations :-)
-
Merci ! \o/
-
Bravo :)
Quels sont vos prochains projets :) ?
-
MilkyWan est maintenant LIR !
Nous avons reçu quelques IP :
45.13.104.0/22
2a0e:e700::/29
Après les débats sur la fin des IPv4, et ce que tu avais dit, on s'en doutait. Au moins, tu auras eu un /22 avant que cela passe éventuellement à un /24.
Et donc une bonne dose d'IPv6.
-
Félicitations !
Sinon vous allez pouvoir bientôt proposer du FTTH ? Où en est l'ouverture de la collecte chez les 4 grands opérateurs ?
-
MilkyWan est maintenant LIR !
Nous avons reçu quelques IP :
45.13.104.0/22
2a0e:e700::/29
8)
Sans indiscretion, cela revient à combien ? Sous quel délais vous avez eu ?
-
2000€ en FAS, 1400€/an (modulo les reducs de l'année).
Tu as ca en environ 2/3 semaines, normalement, si l'administratif est correctement traité
-
Bravo :)
Quels sont vos prochains projets :) ?
Faut que je monte de quoi vendre des xDSL pour ceux que ça intéresse. Ensuite on aimerait faire du Hertzien, mais je cherche un endroit où ça ait de la valeur ajoutée.
Sinon, continuer de se développer dans notre activité de transitaire associatif en fournissant aussi de la collecte xDSL et pourquoi pas FTTH, des assignations IP, des L2L et autres joyeusetés dont les FAI ont besoin pour vivre :)
-
Sinon vous allez pouvoir bientôt proposer du FTTH ? Où en est l'ouverture de la collecte chez les 4 grands opérateurs ?
Pour l'instant seul le FTTH Pro est ouvert :
- Orange : Ouvert uniquement par KOSC, tarifs prohibitifs (environ 60€/mois TTC de mémoire) + plusieurs centaines d'euros de FAS + 1 an d'engagement mini
- SFR : Ouvert en propre, hors de prix (environ 55€/mois TTC) + plusieurs centaines d'euros de FAS + 1 an d'engagement mini
- Bouygues : Ouvert en propre (environ 45€/mois TTC) + 3 (!) ans d'engagement mini
- Free : MDR.
Bref, c'est volontairement calculé pour ne pas faire de FTTH Grand Public, c'est des choses que je peux techniquement vendre, mais que personne n'achètera (il faut rajouter entre 5 et 10 euros de couts d'infra par dessus, entre autres pour la collecte).
Voilà, et l'ARCEP ne fait évidemment rien, le BS FTTH GP, on m'a dit de m'asseoir dessus, c'est ce que je fais :-)
PS : MilkyWan a des FTTH en prod, d'ailleurs, en collecte Bouygues, (pour les gens a qui on fait assez confiance pour s'engager avec eux sur 36 mois), on doit être parmi les seuls FAI Associatifs à en avoir ;-)
-
Et du FTTO, il y en a en prod ? ;)
-
Non, on l'a mis pour le fun, mais c'est surtout destiné à des FAI Asso qui voudraient prendre ça comme tronc de collecte local :)
-
Non, on l'a mis pour le fun, mais c'est surtout destiné à des FAI Asso qui voudraient prendre ça comme tronc de collecte local :)
Les CGV de Orange (j'imagine que c'est basé sur du CELAN Orange) autorisent ça ?
-
Non, pas forcèment, on a pleeeeein de petits opérateurs pour faire du FTTO mieux qu'Orange ! (on a aussi du CELAN au besoin)
Il ne me semble pas que ce soit interdit en CELAN, non
-
Non, pas forcèment, on a pleeeeein de petits opérateurs pour faire du FTTO mieux qu'Orange !
Même en province ? (pas forcèment en rase campagne, mais disons ma ville par exemple, Montauban)
-
Les CGV de Orange (j'imagine que c'est basé sur du CELAN Orange) autorisent ça ?
clairement oui, et encore heureux, tu achète juste un L2 à l'opérateur tu en fait ce que tu veux
-
MilkyWan est maintenant LIR !
Nous avons reçu quelques IP :
45.13.104.0/22
2a0e:e700::/29
8)
Alors on a pris du v4 ? c'était pas censé etre du 100% IpV6 Non ?
-
On a toujours eu de l'IPv4, d'abord via AppliWave qui nous prêtait un /27, ensuite par Gitoyen qui nous alloue un /24, et maintenant en propre
-
(https://pix.milkywan.fr/AjZICk8D.PNG)
Merci Hugues d'avoir créé Mw, grâce à lui j'ai de beaux wallpapers x)
-
Pas de souci haha :D
-
On voit bien le coupable du down ce midi, en haut avec ses petites lumières bleues ? :)
-
Faut que je monte de quoi vendre des xDSL pour ceux que ça intéresse. Ensuite on aimerait faire du Hertzien, mais je cherche un endroit où ça ait de la valeur ajoutée.
Sinon, continuer de se développer dans notre activité de transitaire associatif en fournissant aussi de la collecte xDSL et pourquoi pas FTTH, des assignations IP, des L2L et autres joyeusetés dont les FAI ont besoin pour vivre :)
Sympa de suivre votre aventure. Pour chacun des POP, vous êtes en baie mutualisé ?
-
Personne n'a encore posté de mtr ? Je me lance...
45.13.104.1
HOST: mm.ornethd.net Loss% Snt Last Avg Best Wrst StDev
1. AS41114 gateway 0.0% 10 0.3 0.5 0.2 1.4 0.0
2. AS41114 cust-bond0.bd1.rombas.infra.ornethd.net 0.0% 10 0.6 0.6 0.4 1.5 0.0
3. AS41114 vl200-rombas.bgp1.briey.infra.ornethd.net 0.0% 10 1.8 1.4 1.2 1.8 0.0
4. AS??? leonixtelecom.par.franceix.net 0.0% 10 6.6 7.5 6.5 11.4 1.3
5. AS50628 te0-2-0.a9k-1.core.brs.bb.leonix.net 0.0% 10 6.7 6.9 6.6 8.0 0.3
6. AS50628 te0-2-0.a9k-2.core.brs.bb.leonix.net 0.0% 10 6.8 7.2 6.6 11.1 1.2
7. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2a0e:e700::
HOST: mm.ornethd.net Loss% Snt Last Avg Best Wrst StDev
1. AS41114 gateway 0.0% 10 0.9 0.9 0.8 1.0 0.0
2. AS41114 cust-bond0.bd1.rombas.infra6.ornethd.net 0.0% 10 1.3 0.8 0.6 1.3 0.0
3. AS41114 bd1-bond0.bgp1.briey.infra6.ornethd.net 0.0% 10 1.9 1.4 1.2 1.9 0.0
4. AS??? leonixtelecom.par.franceix.net 0.0% 10 6.7 6.8 6.4 7.1 0.0
5. AS50628 2a0b:3b00:1::252:2 0.0% 10 6.9 7.4 6.8 9.2 0.5
6. AS50628 2a0b:3b00:1::248:2 0.0% 10 7.0 6.9 6.8 7.0 0.0
7. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
C'est propre :)
-
Depuis Bouygues Telecom (fr.archive.ubuntu.com) :
$ mtr -zrwc100 45.13.104.1
Start: 2019-05-09T20:12:48+0200
HOST: ubuntu Loss% Snt Last Avg Best Wrst StDev
1. AS5410 194.158.119.185 0.0% 100 0.5 0.4 0.3 0.8 0.1
2. AS5410 be11.cbr01-ntr.net.bbox.fr 0.0% 100 1.9 2.5 1.4 3.6 0.6
3. AS5410 la13.rpt02-ix2.net.bbox.fr 66.0% 100 1.1 1.1 1.0 1.4 0.1
4. AS??? leonixtelecom.par.franceix.net 0.0% 100 1.9 1.8 1.6 2.1 0.1
5. AS50628 te0-2-0.a9k-1.core.brs.bb.leonix.net 0.0% 100 2.0 1.9 1.8 2.1 0.1
6. AS50628 te0-2-0.a9k-2.core.brs.bb.leonix.net 0.0% 100 2.0 2.1 2.0 2.5 0.1
7. AS??? ? ? 100.0 100
$ mtr -zrwc100 2a0e:e700::
Start: 2019-05-09T20:15:46+0200
HOST: ubuntu Loss% Snt Last Avg Best Wrst StDev
1. AS5410 2001:860:f70a::1 0.0% 100 0.4 0.4 0.4 0.8 0.1
2. AS??? ? ? 100.0 100
3. AS5511 2a01:cfc4:0:1500::e 0.0% 100 7.4 7.6 7.3 13.9 0.8
4. AS??? ? ? 100.0 100
5. AS??? ? ? 100.0 100
6. AS5511 2a01:cfc0:200:8300:193:252:102:50 0.0% 100 7.6 8.3 7.4 24.1 2.5
7. AS5511 2a01:cfc0:200:8300:193:252:102:49 0.0% 100 9.1 8.9 7.5 42.4 4.0
8. AS5511 2a01:cfc4:0:1b00::13 0.0% 100 7.3 7.3 7.2 7.4 0.1
9. AS??? 2a02:e5c:0:15::2 0.0% 100 7.3 7.3 7.2 7.4 0.0
10. AS??? 2a02:e5c:4:4::2 4.0% 100 7.9 7.9 7.8 8.2 0.1
11. AS50628 2a0b:3b00:1::250:2 12.0% 100 8.1 8.1 8.0 8.3 0.1
12. AS??? ? ? 100.0 100
Pour l'IPv6, je devine le peering régional avec Orange AS3215 sur Lyon qui aspire tout le trafic qui est annoncé à AS3215 sur Lyon.
-
Depuis SFR en ADSL (Marseille)
Détermination de l’itinéraire vers 45.13.104.1 avec un maximum de 30 sauts.
1 <1 ms <1 ms <1 ms box [192.168.1.1]
2 38 ms 38 ms 38 ms x.x.144.77.rev.sfr.net [77.144.x.x]
3 38 ms 39 ms 38 ms 253.80.65.86.rev.sfr.net [86.65.80.253]
4 37 ms 38 ms 38 ms 245.15.6.109.rev.sfr.net [109.6.15.245]
5 39 ms 38 ms 38 ms 117.135.96.84.rev.sfr.net [84.96.135.117]
6 38 ms 38 ms 38 ms 101.135.96.84.rev.sfr.net [84.96.135.101]
7 milkywan-l2.peers.lyonix.net [77.95.71.132] rapports : Impossible de joindre l’hôte de destination.
Itinéraire déterminé.
Détermination de l’itinéraire vers 2a0e:e700:: avec un maximum de 30 sauts.
1 <1 ms <1 ms <1 ms box
2 38 ms 38 ms 38 ms 2a02-8400-0000-0004-0000-0000-0000-005c.rev.sfr.net [2a02:8400:0:4::5c]
3 39 ms 38 ms 38 ms 2a02-8400-0000-0004-0000-0000-0000-005b.rev.sfr.net [2a02:8400:0:4::5b]
4 39 ms 39 ms 38 ms 2a02-8400-0000-0004-0000-0000-0000-0051.rev.sfr.net [2a02:8400:0:4::51]
5 39 ms 38 ms 39 ms 2a02-8400-0000-0004-0000-0000-0010-00fe.rev.sfr.net [2a02:8400:0:4::10:fe]
6 38 ms 39 ms 38 ms 2a02-8400-0000-0004-0000-0000-0000-004f.rev.sfr.net [2a02:8400:0:4::4f]
7 39 ms 38 ms 39 ms 2a02-8400-0000-0004-0000-0000-0010-00f6.rev.sfr.net [2a02:8400:0:4::10:f6]
8 42 ms 41 ms 42 ms 2a02-8400-0000-0003-0000-0000-0000-1896.rev.sfr.net [2a02:8400:0:3::1896]
9 39 ms 40 ms 40 ms 2a02-8400-0000-0003-0000-0000-0000-4165.rev.sfr.net [2a02:8400:0:3::4165]
10 51 ms 50 ms 50 ms 2a02-8400-0000-0003-0000-0000-0000-416a.rev.sfr.net [2a02:8400:0:3::416a]
11 51 ms 50 ms 50 ms 2a02-8400-0000-0003-0000-0000-0000-08a5.rev.sfr.net [2a02:8400:0:3::8a5]
12 50 ms 50 ms 49 ms 2a02:e5c:4:6::1
13 50 ms 50 ms 49 ms 2a02:e5c:0:2::1
14 50 ms 51 ms 51 ms 2a02:e5c:4:4::2
15 52 ms 51 ms 51 ms 2a0b:3b00:1::250:2
16 Impossible de joindre le réseau de destination.
Itinéraire déterminé.
-
ping ça compte ?
root@debian-revns:/home/philippe# ping 45.13.104.131
PING 45.13.104.131 (45.13.104.131) 56(84) bytes of data.
64 bytes from 45.13.104.131: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 45.13.104.131: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 45.13.104.131: icmp_seq=3 ttl=64 time=0.041 ms
64 bytes from 45.13.104.131: icmp_seq=4 ttl=64 time=0.039 ms
;D ;D
Merci Hugues et toute l'équipe :)
-
;-)
-
Depuis Free :
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| FREEBOX - 0 | 3 | 3 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 1 | 0 | 0 | 0 | 0 | 0 |
| 194.149.166.38 - 0 | 3 | 3 | 2 | 2 | 2 | 2 |
| free.th2-2.rt.hopus.net - 0 | 3 | 3 | 2 | 2 | 2 | 2 |
| lag-th2-1.dc3-2a.rt.hopus.net - 0 | 3 | 3 | 2 | 2 | 3 | 2 |
| appliwave.dc3-2.rt.hopus.net - 0 | 3 | 3 | 2 | 8 | 21 | 2 |
|milkywan.rbgp1-10g.dc2.paris.france.as200780.net - 0 | 3 | 3 | 2 | 2 | 3 | 3 |
| moon.milkywan.space - 0 | 3 | 3 | 2 | 2 | 3 | 2 |
| web.milkywan.cloud - 0 | 3 | 3 | 2 | 2 | 3 | 2 |
|________________________________________________|______|______|______|______|______|______|
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 2a01:e0a:xxxx:xxxx::1 - 0 | 11 | 11 | 0 | 0 | 0 | 0 |
| 2a01:e00:2d:f836:392::ffff - 0 | 11 | 11 | 1 | 2 | 20 | 1 |
| 2a01:e00:2d:1700::ffff - 75 | 4 | 1 | 0 | 2 | 2 | 2 |
| Request timed out. - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| 2a01:e00:2a::5 - 0 | 11 | 11 | 2 | 2 | 3 | 2 |
| 2a02:e5c:1:13::1 - 0 | 11 | 11 | 2 | 2 | 4 | 2 |
| 2a02:e5c:0:18::2 - 0 | 11 | 11 | 2 | 2 | 3 | 3 |
| 2a02:e5c:3:5::2 - 0 | 11 | 11 | 2 | 2 | 5 | 3 |
| ge1-8-rt2-th2.bb.hivane.net - 0 | 11 | 11 | 2 | 3 | 10 | 2 |
| 2a05:46c0:100:1000::2 - 0 | 11 | 11 | 3 | 3 | 8 | 8 |
| 2a0b:3b00:1::96:2 - 0 | 11 | 11 | 2 | 2 | 3 | 3 |
| cassini.milkywan.space - 0 | 11 | 11 | 2 | 2 | 4 | 3 |
| web.milkywan.cloud - 0 | 11 | 11 | 3 | 3 | 3 | 3 |
|________________________________________________|______|______|______|______|______|______|
Dans les deux cas ça sort de chez Free via Hopus mais en IPv6 ça passe ensuite par Hivane plutôt qu'Appliwave en IPv4.
-
Depuis OVH FTTH:
# mtr -4rzwc100 web.milkywan.cloud
Start: 2019-05-09T21:19:18+0200
HOST: wopr Loss% Snt Last Avg Best Wrst StDev
1. AS??? AstriaPorta.vl102.mrs.in.byme.at 0.0% 100 0.2 0.2 0.2 0.3 0.0
2. AS35540 cpe.eth2.mrs.byme.at 0.0% 100 0.5 0.5 0.4 5.1 0.5
3. AS16276 145.239.153.19 0.0% 100 13.0 16.5 12.8 33.1 5.1
4. AS16276 145.239.153.139 0.0% 100 52.3 15.6 13.2 52.3 4.5
5. AS16276 be100-45.th2-1-a9.fr.eu 0.0% 100 14.8 16.9 13.2 35.7 4.5
6. AS16276 be100-1043.rbx-g1-nc5.fr.eu 0.0% 100 19.7 26.9 17.6 138.7 20.3
7. AS16276 be1.rbx-5-a72.fr.eu 0.0% 100 18.9 18.9 16.5 36.4 3.7
8. AS??? 193.34.197.247 65.0% 100 21.1 24.3 20.9 79.0 9.8
9. AS57199 te4.2985-1.ccr1072.core.dc2.ip4.infra.milkywan.net 69.0% 100 22.1 23.8 21.3 39.4 4.1
10. AS57199 moon.milkywan.space 0.0% 100 23.9 24.1 21.4 45.0 3.9
11. AS57199 web.milkywan.cloud 0.0% 100 22.2 24.4 21.4 44.6 4.9
# mtr -6rzwc100 web.milkywan.cloud
Start: 2019-05-09T21:19:00+0200
HOST: wopr Loss% Snt Last Avg Best Wrst StDev
1. AS35540 AstriaPorta.vl102.mrs.in.byme.at 0.0% 100 0.3 0.3 0.2 0.6 0.0
2. AS35540 cpe.eth2.mrs.byme.at 0.0% 100 0.7 0.5 0.4 1.3 0.1
3. AS35540 2001:41d0:fde0::22 0.0% 100 13.1 16.4 13.1 44.7 5.3
4. AS35540 2001:41d0:fde0:80::11 0.0% 100 23.8 16.9 13.5 49.0 6.1
5. AS16276 be100-45.th2-1-a9.fr.eu 89.0% 100 17.1 16.3 13.7 24.5 3.5
6. AS16276 be100-1043.rbx-g1-nc5.fr.eu 70.0% 100 21.8 24.5 17.7 122.1 18.8
7. AS16276 be1.rbx-5-a72.fr.eu 0.0% 100 21.5 18.4 16.7 38.8 3.4
8. AS200780 2a05:46c0:100:1000::2 0.0% 100 18.9 20.2 17.8 37.0 3.9
9. AS50628 2a0b:3b00:1::96:2 0.0% 100 21.1 20.7 17.4 94.3 8.3
10. AS57199 cassini.milkywan.space 1.0% 100 21.4 22.1 17.6 73.4 7.6
11. AS57199 web.milkywan.cloud 0.0% 100 29.8 21.3 17.7 42.1 5.1
-
Chez K-NET
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 2 | 2 | 0 | 0 | 0 | 0 |
| No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 172.16.120.74 - 0 | 2 | 2 | 15 | 15 | 15 | 15 |
| milkywan-l2.peers.lyonix.net - 0 | 2 | 2 | 17 | 17 | 17 | 17 |
|te4.2986-1.ccr1072.core.dc2.infra.ip4.milkywan.net - 0 | 2 | 2 | 24 | 24 | 25 | 25 |
| moon.milkywan.space - 0 | 2 | 2 | 25 | 25 | 25 | 25 |
| web.milkywan.cloud - 0 | 2 | 2 | 25 | 25 | 25 | 25 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 2a03:4980::23:0:1 - 0 | 4 | 4 | 6 | 6 | 7 | 6 |
| 2a03:4980::24:0:1 - 0 | 4 | 4 | 5 | 5 | 7 | 5 |
|te1.2984-0.ccr1072.core.th2.infra.ip6.milkywan.net - 0 | 4 | 4 | 15 | 15 | 16 | 15 |
|te1.901-0.ccr1072.core.brs.infra.ip6.milkywan.net - 0 | 4 | 4 | 15 | 15 | 16 | 15 |
| cassini.milkywan.space - 0 | 4 | 4 | 15 | 15 | 16 | 15 |
| web.milkywan.cloud - 0 | 4 | 4 | 15 | 16 | 17 | 15 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
-
Chez Orange en IPV4
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| lan.home - 0 | 215 | 215 | 0 | 0 | 2 | 0 |
| 80.10.236.209 - 0 | 215 | 215 | 1 | 7 | 746 | 2 |
|ae106-0.ncstr101.Schiltigheim.francetelecom.net - 0 | 215 | 215 | 3 | 4 | 32 | 3 |
|ae42-0.nrstr201.Schiltigheim.francetelecom.net - 0 | 215 | 215 | 2 | 3 | 26 | 3 |
|ae45-0.nridf301.Paris15eArrondissement.francetelecom.net - 0 | 215 | 215 | 8 | 11 | 71 | 11 |
|ae44-0.noidf001.Paris3eArrondissement.francetelecom.net - 0 | 215 | 215 | 10 | 11 | 26 | 11 |
| 193.253.13.206 - 0 | 215 | 215 | 10 | 10 | 12 | 10 |
| lag-th2-1.dc3-2a.rt.hopus.net - 0 | 215 | 215 | 10 | 10 | 13 | 11 |
| appliwave.dc3-2.rt.hopus.net - 0 | 215 | 215 | 10 | 16 | 200 | 11 |
|te4.2985-1.ccr1072.core.dc2.ip4.infra.milkywan.net - 43 | 80 | 46 | 10 | 16 | 270 | 11 |
| moon.milkywan.space - 0 | 215 | 215 | 11 | 11 | 94 | 11 |
| web.milkywan.cloud - 0 | 215 | 215 | 10 | 12 | 82 | 11 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
Chez Orange en IPV6
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| livebox.home - 0 | 74 | 74 | 0 | 0 | 0 | 0 |
|2a01cb08a00402170193025300760164.ipv6.abo.wanadoo.fr - 0 | 73 | 73 | 1 | 1 | 2 | 2 |
| 2a01:cfc0:200:8300:193:252:102:43 - 0 | 73 | 73 | 11 | 12 | 28 | 19 |
| 2a01:cfc4:0:f01::2 - 0 | 73 | 73 | 11 | 12 | 31 | 11 |
| gw-milkywan-th2.bb.hivane.net - 0 | 73 | 73 | 11 | 11 | 39 | 11 |
|te1.901-0.ccr1072.core.brs.infra.ip6.milkywan.net - 0 | 73 | 73 | 11 | 11 | 13 | 12 |
| cassini.milkywan.space - 0 | 73 | 73 | 11 | 11 | 15 | 11 |
| web.milkywan.cloud - 0 | 73 | 73 | 11 | 12 | 18 | 12 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
c'est curieux, moins de saut à faire en IPV6 !
-
Je n’annonce pas mes routes internes IPv4 à Hivane pour éviter de passer par son port Hopus, c’est pour ça :-)
-
Depuis OVH FTTH:
Ils n'arrivent toujours pas à passer par notre peering en v6, je sais pas comment ils font :-X
-
depuis renater sur Paris
Start: 2019-05-10T10:15:34+0200
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS2439 147.215.40.253 0.0% 100 5.9 3.4 1.0 12.1 2.7
2. AS2439 147.215.119.2 0.0% 100 1.2 1.2 0.8 12.4 1.1
3. AS2200 195.220.83.107 0.0% 100 1.6 2.0 1.4 3.1 0.3
4. AS2200 vl148-gi3-2-marne-rtr-021.noc.renater.fr 0.0% 100 2.8 2.3 1.6 3.3 0.4
5. AS2200 vl630-te1-2-jussieu-rtr-021.noc.renater.fr 0.0% 100 8.6 8.4 7.7 9.7 0.4
6. AS2200 193.51.180.108 0.0% 100 3.8 4.2 2.3 21.6 3.2
7. AS2200 te0-6-0-4-lyon1-rtr-001.noc.renater.fr 0.0% 100 8.4 8.4 7.7 22.3 1.7
8. AS??? milkywan-l2.peers.lyonix.net 0.0% 100 8.0 8.2 7.6 9.1 0.3
9. AS57199 te4.2986-1.ccr1072.core.dc2.infra.ip4.milkywan.net 73.0% 100 15.7 15.8 15.2 16.5 0.3
10. AS57199 moon.milkywan.space 0.0% 100 15.5 15.8 15.2 17.0 0.3
11. AS20766 web.milkywan.cloud 0.0% 100 15.8 15.9 15.3 18.0 0.4
Comment expliquer les 73% de pertes en arrivant sur te4.2986-1.ccr1072.core.dc2.infra.ip4.milkywan.net ?
-
Pas de perte, le dernier hop est à 0%, mon routeur fait juste autre chose que de répondre au ping :)
-
Depuis grifon :
10:24 alarig@mew ~ % mtr -bzwe 45.13.104.1
Start: 2019-05-10T10:24:19+0200
HOST: mew.swordarmor.fr Loss% Snt Last Avg Best Wrst StDev
1. AS204092 br-ganeti.regis.swordarmor.fr (89.234.186.209) 0.0% 10 0.4 0.4 0.3 0.4 0.1
2. AS204092 asbr02.cogent-rns.grifon.fr (89.234.186.6) 0.0% 10 0.5 0.5 0.4 0.6 0.1
3. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10:24 alarig@mew ~ % mtr -bzwe 2a0e:e700::1
Start: 2019-05-10T10:24:40+0200
HOST: mew.swordarmor.fr Loss% Snt Last Avg Best Wrst StDev
1. AS204092 br-ganeti.regis.swordarmor.fr (2a00:5884:102:1::1) 0.0% 10 0.3 0.4 0.3 0.5 0.1
2. AS204092 asbr02.cogent-rns.grifon.fr (2a00:5884::6) 0.0% 10 0.6 0.6 0.4 0.7 0.1
3. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10:24 alarig@mew ~ % mtr -bzwe4 web.milkywan.cloud
Start: 2019-05-10T10:25:02+0200
HOST: mew.swordarmor.fr Loss% Snt Last Avg Best Wrst StDev
1. AS204092 br-ganeti.regis.swordarmor.fr (89.234.186.209) 0.0% 10 0.4 0.3 0.3 0.4 0.0
2. AS204092 asbr02.cogent-rns.grifon.fr (89.234.186.6) 0.0% 10 0.5 0.5 0.4 0.5 0.0
3. AS57199 ge2-0.ccr1016.core.ren.infra.ip4.milkywan.net (80.67.167.221) 0.0% 10 0.6 0.5 0.5 0.7 0.1
4. AS57199 te1.52-1.ccr1072.core.th2.infra.ip4.milkywan.net (80.67.167.241) 30.0% 10 7.2 8.0 7.1 12.9 2.2
5. AS57199 te4.2985-1.ccr1072.core.dc2.ip4.infra.milkywan.net (80.67.167.225) 30.0% 10 7.8 7.6 7.5 7.8 0.1
6. AS57199 moon.milkywan.space (80.67.167.82) 0.0% 10 7.7 7.7 7.5 7.8 0.1
7. AS57199 web.milkywan.cloud (80.67.167.84) 0.0% 10 7.8 7.7 7.5 7.9 0.1
10:25 alarig@mew ~ % mtr -bzwe6 web.milkywan.cloud
Start: 2019-05-10T10:32:22+0200
HOST: mew.swordarmor.fr Loss% Snt Last Avg Best Wrst StDev
1. AS204092 br-ganeti.regis.swordarmor.fr (2a00:5884:102:1::1) 0.0% 10 0.4 0.4 0.3 0.5 0.1
2. AS204092 asbr02.cogent-rns.grifon.fr (2a00:5884::6) 0.0% 10 0.6 0.6 0.5 0.7 0.1
3. AS57199 ge2-0.ccr1016.core.ren.infra.ip6.milkywan.net (2a0b:cbc0:1::bd) 0.0% 10 0.8 0.8 0.7 0.9 0.1
4. AS57199 te1.50-0.ccr1072.core.th2.infra.ip6.milkywan.net (2a0b:cbc0:1::b5) 0.0% 10 7.5 7.5 7.3 7.8 0.1
5. AS57199 te1.901-0.ccr1072.core.brs.infra.ip6.milkywan.net (2a0b:cbc0:1::8e) 0.0% 10 7.6 7.7 7.6 7.8 0.1
6. AS57199 cassini.milkywan.space (2a0b:cbc0:110d:1::b) 0.0% 10 8.1 8.1 7.7 9.1 0.4
7. AS57199 web.milkywan.cloud (2a0b:cbc0:1100:1::24) 0.0% 10 8.1 8.6 8.1 10.7 0.7
-
Ah oui j'avais pas fait attention.
-
Depuis grifon :
Étonnant dis donc xD
-
Si vous voulez la route retour :)
https://lg.milkywan.fr/traceroute/milkywan/ipv4?q=8.8.8.8
-
Si vous voulez la route retour :)
https://lg.milkywan.fr/traceroute/milkywan/ipv4?q=8.8.8.8
Du coup chez Free ça n'a pas l'air symétrique, je n'ai pas l'impression que ça passe par Hivane en IPv6 sortant.
-
Probablement, mais le routage symétrique, ça n'a pas grand intéret...
Là on fait
MW -> AppliWave -> Hopus -> Free en v4+v6
Et en retour :
Free -> Hopus -> AppliWave -> MW en v4
Free -> Hopus -> Hivane -> MW en v6
Hivane ayant un port 1G sur Hopus et AppliWave (et Leonix) un port 10G, je préfère faire passer le trafic par là !
Par contre ce n'est pas vrai pour les clients transit de MilkyWan, j'annonce leurs routes à Hivane pour qu'ils puissent profiter de meilleures routes :)
-
Pour le fun !
(https://lafibre.info/images/associatif/201905_milkywan_team.jpg)
-
Tiens on dirait la Pointe de la Fumée à Fouras.
Un pt'it week-end à l'Ile D'Aix ?
-
En effet, on est passés faire coucou à l'AG FFDN 2019 :)
-
J'espère que vous étiez munis d'une SIM Orange, parce que la 4G sur l'ile c'est misère chez ByT&SFR.
-
On y'est encore, Orange et SFR passent bien...
-
Depuis OVH FTTH:
# mtr -4rzwc100 web.milkywan.cloud
Start: 2019-05-09T21:19:18+0200
HOST: wopr Loss% Snt Last Avg Best Wrst StDev
1. AS??? AstriaPorta.vl102.mrs.in.byme.at 0.0% 100 0.2 0.2 0.2 0.3 0.0
2. AS35540 cpe.eth2.mrs.byme.at 0.0% 100 0.5 0.5 0.4 5.1 0.5
3. AS16276 145.239.153.19 0.0% 100 13.0 16.5 12.8 33.1 5.1
4. AS16276 145.239.153.139 0.0% 100 52.3 15.6 13.2 52.3 4.5
5. AS16276 be100-45.th2-1-a9.fr.eu 0.0% 100 14.8 16.9 13.2 35.7 4.5
6. AS16276 be100-1043.rbx-g1-nc5.fr.eu 0.0% 100 19.7 26.9 17.6 138.7 20.3
7. AS16276 be1.rbx-5-a72.fr.eu 0.0% 100 18.9 18.9 16.5 36.4 3.7
8. AS??? 193.34.197.247 65.0% 100 21.1 24.3 20.9 79.0 9.8
9. AS57199 te4.2985-1.ccr1072.core.dc2.ip4.infra.milkywan.net 69.0% 100 22.1 23.8 21.3 39.4 4.1
10. AS57199 moon.milkywan.space 0.0% 100 23.9 24.1 21.4 45.0 3.9
11. AS57199 web.milkywan.cloud 0.0% 100 22.2 24.4 21.4 44.6 4.9
# mtr -6rzwc100 web.milkywan.cloud
Start: 2019-05-09T21:19:00+0200
HOST: wopr Loss% Snt Last Avg Best Wrst StDev
1. AS35540 AstriaPorta.vl102.mrs.in.byme.at 0.0% 100 0.3 0.3 0.2 0.6 0.0
2. AS35540 cpe.eth2.mrs.byme.at 0.0% 100 0.7 0.5 0.4 1.3 0.1
3. AS35540 2001:41d0:fde0::22 0.0% 100 13.1 16.4 13.1 44.7 5.3
4. AS35540 2001:41d0:fde0:80::11 0.0% 100 23.8 16.9 13.5 49.0 6.1
5. AS16276 be100-45.th2-1-a9.fr.eu 89.0% 100 17.1 16.3 13.7 24.5 3.5
6. AS16276 be100-1043.rbx-g1-nc5.fr.eu 70.0% 100 21.8 24.5 17.7 122.1 18.8
7. AS16276 be1.rbx-5-a72.fr.eu 0.0% 100 21.5 18.4 16.7 38.8 3.4
8. AS200780 2a05:46c0:100:1000::2 0.0% 100 18.9 20.2 17.8 37.0 3.9
9. AS50628 2a0b:3b00:1::96:2 0.0% 100 21.1 20.7 17.4 94.3 8.3
10. AS57199 cassini.milkywan.space 1.0% 100 21.4 22.1 17.6 73.4 7.6
11. AS57199 web.milkywan.cloud 0.0% 100 29.8 21.3 17.7 42.1 5.1
Hello
Petite question concernant le nommage de votre matos, notamment : te4.2985-1.ccr1072.core.dc2.ip4.infra.milkywan.net.
Visiblement, il y à un paquet de matériel nommé de cette façon. Ça fait partie des "bonnes pratiques" que tout le monde s'est habitué à utiliser ou bien c'est dans une RFC ?
Si je comprends bien, "CCR1072" ça correspond au modèle du routeur. D'une certaine façon, c'est pas risqué de le publier ?
Par curiosité, à quoi correspond "te4.2985-1" ?
-
Visiblement, il y à un paquet de matériel nommé de cette façon. Ça fait partie des "bonnes pratiques" que tout le monde s'est habitué à utiliser ou bien c'est dans une RFC ?
Pas de RFC, mais c'est une bonne pratique que d'être explicite sur tes reverses pour faciliter le débug, voir ce sujet : https://lafibre.info/bgp/nomenclature-ptr-routeurs/
Si je comprends bien, "CCR1072" ça correspond au modèle du routeur. D'une certaine façon, c'est pas risqué de le publier ?
C'est ça. On poste même des photos de nos routeurs, alors bon, on peut bien dire de quel modèle il s'agit, je ne trouve pas ça très stratégique.
Par curiosité, à quoi correspond "te4.2985-1" ?
C'est la 2nde IP du vlan 2985 du 4è port 10G du routeur mikrotik ccr1072 de DC2. De mémoire c'est le VLAN de notre TH2-DC2 :)
-
Pas de RFC, mais c'est une bonne pratique que d'être explicite sur tes reverses pour faciliter le débug, voir ce sujet : https://lafibre.info/bgp/nomenclature-ptr-routeurs/
C'est ça. On poste même des photos de nos routeurs, alors bon, on peut bien dire de quel modèle il s'agit, je ne trouve pas ça très stratégique.
C'est la 2nde IP du vlan 2985 du 4è port 10G du routeur mikrotik ccr1072 de DC2. De mémoire c'est le VLAN de notre TH2-DC2 :)
Merci pour les précisions ;)
-
MAJ du coup chez SFR depuis Marseille mais en FTTH
Détermination de l’itinéraire vers web.milkywan.cloud [80.67.167.84]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms box [192.168.1.1]
2 1 ms 1 ms 1 ms 1.224.139.88.rev.sfr.net [88.139.224.1]
3 1 ms 1 ms 2 ms 102.89.136.77.rev.sfr.net [77.136.89.102]
4 6 ms 5 ms 6 ms 230.244.5.109.rev.sfr.net [109.5.244.230]
5 6 ms 6 ms 6 ms 230.244.5.109.rev.sfr.net [109.5.244.230]
6 6 ms 5 ms 5 ms milkywan-l2.peers.lyonix.net [77.95.71.132]
7 14 ms * 13 ms te4.2986-1.ccr1072.core.dc2.infra.ip4.milkywan.net [80.67.167.233]
8 13 ms 13 ms 14 ms moon.milkywan.space [80.67.167.82]
9 14 ms 13 ms 14 ms web.milkywan.cloud [80.67.167.84]
Itinéraire déterminé.
-
Depuis Lyon (enfin j'habite en Ardèche, mais tout mon trafic passe par lyon).
mtr -4rzwc100 web.milkywan.cloud
Start: 2019-07-22T16:51:42+0200
HOST: renaud-pc Loss% Snt Last Avg Best Wrst StDev
1. AS??? bt.lpa.lan 0.0% 100 4.8 2.1 1.2 4.8 0.9
2. AS??? lac-net1.bslyo256.Lyon3eArrondissement.francetelecom.net 0.0% 100 23.1 21.7 20.4 25.6 0.9
3. AS??? 10.125.112.138 0.0% 100 22.0 24.4 20.9 35.0 3.4
4. AS??? ae20-0.nclyo202.Lyon3eArrondissement.francetelecom.net 0.0% 100 21.0 23.1 20.6 51.4 3.4
5. AS??? ae42-0.nrlyo202.Lyon3eArrondissement.francetelecom.net 0.0% 100 23.0 23.4 20.8 43.1 3.3
6. AS??? ae42-0.nridf102.Aubervilliers.francetelecom.net 0.0% 100 27.2 29.2 26.2 48.7 3.6
7. AS??? ae41-0.noidf002.Aubervilliers.francetelecom.net 0.0% 100 28.3 28.5 26.4 46.4 2.3
8. AS??? 193.253.13.202 0.0% 100 26.6 27.2 25.9 30.2 0.7
9. AS??? leonix.pa3.hopus.net 0.0% 100 28.3 28.2 26.7 32.6 1.0
10. AS50628 te0-2-1.a9k-2.core.brs.bb.leonix.net 0.0% 100 30.2 28.2 26.6 31.1 0.9
11. AS57199 te1.901-1.ccr1072.core.brs.ip4.infra.milkywan.net 65.0% 100 28.6 27.7 26.7 31.7 1.0
12. AS34019 gw-milkywan-th2.bb.hivane.net 66.0% 100 27.3 27.9 26.7 29.5 0.8
13. AS57199 te4.2985-1.ccr1072.core.dc2.ip4.infra.milkywan.net 71.0% 100 28.8 28.4 27.1 31.2 0.8
14. AS20766 moon.milkywan.space 0.0% 100 27.6 28.6 26.9 66.1 3.9
15. AS20766 web.milkywan.cloud 0.0% 100 27.9 28.0 27.2 32.9 0.8
Curieux qu'il ne détecte pas l'AS d'Orange.
-
Curieux qu'il ne détecte pas l'AS d'Orange.
Ce n'est pas curieux que l'AS d'Orange ne soit pas détecté, c'est simplement lié au fait qu'Orange n'annonce pas sur Internet les subnets d'adresse IP qu'ils utilisent pour leurs intercos.
-
Ce n'est pas curieux que l'AS d'Orange ne soit pas détecté, c'est simplement lié au fait qu'Orange n'annonce pas sur Internet les subnets d'adresse IP qu'ils utilisent pour leurs intercos.
Ah ok, merci pour l'info :)
-
Légère différence de routage en IPv4 et IPv6.
Start: Mon Jul 22 17:35:26 2019
HOST: sip1.ornethd.net Loss% Snt Last Avg Best Wrst StDev
1. AS41114 gateway 0.0% 10 0.3 0.3 0.3 0.4 0.0
2. AS41114 cust-bond0.bd1.rombas.infra.ornethd.net 0.0% 10 0.7 4.0 0.3 31.4 9.7
3. AS41114 vl200-rombas.bgp1.briey.infra.ornethd.net 0.0% 10 7.3 2.1 0.8 7.3 2.1
4. AS??? leonixtelecom.par.franceix.net 0.0% 10 6.1 6.3 5.9 7.1 0.0
5. AS50628 te0-2-0.a9k-1.core.brs.bb.leonix.net 0.0% 10 6.2 6.3 6.1 6.7 0.0
6. AS50628 te0-2-0.a9k-2.core.brs.bb.leonix.net 0.0% 10 6.4 6.2 6.0 6.5 0.0
7. AS50628 milkywan.bgp.cust.leonix.net 40.0% 10 5.6 5.7 5.5 6.0 0.0
8. AS200780185.217.202.178 70.0% 10 6.1 6.1 6.1 6.2 0.0
9. AS200780milkywan.rbgp1-10g.dc2.paris.france.as200780.net 40.0% 10 5.9 6.0 5.8 6.4 0.0
10. AS57199 moon.milkywan.space 0.0% 10 5.9 6.0 5.8 6.3 0.0
11. AS57199 web.milkywan.cloud 0.0% 10 6.0 6.5 6.0 9.2 0.9
Start: Mon Jul 22 17:36:40 2019
HOST: sip1.ornethd.net Loss% Snt Last Avg Best Wrst StDev
1. AS41114 gateway 0.0% 10 0.7 0.8 0.7 1.0 0.0
2. AS41114 cust-bond0.bd1.rombas.infra6.ornethd.net 0.0% 10 0.4 0.4 0.4 0.5 0.0
3. AS41114 bd1-bond0.bgp1.briey.infra6.ornethd.net 0.0% 10 0.7 1.0 0.7 1.6 0.0
4. AS??? appliwave-dc3.par.franceix.net 0.0% 10 5.7 6.6 5.7 14.3 2.6
5. AS200780milkywan.rbgp1-10g.dc2.paris.france.as200780.net 0.0% 10 5.7 5.7 5.6 5.9 0.0
6. AS2007802a05:46c0:100:1000::2 0.0% 10 6.4 6.6 6.4 7.5 0.0
7. AS50628 2a0b:3b00:1::96:2 0.0% 10 5.9 6.1 5.9 6.9 0.0
8. AS57199 cassini.milkywan.space 0.0% 10 6.1 6.8 6.0 9.7 1.1
9. AS57199 web.milkywan.cloud 0.0% 10 6.8 7.0 6.4 9.1 0.7
-
J'ai aussi un truc drôle : Si j'essaie un mtr vers moon.milkywan.space, je ne passe pas du tout par la même route chez Orange (paris au lieu d'aubervilliers, alors que le reste est quasi identique) :
C'est pour éviter la saturation ? On varie la route selon l'ip même si c'est pour atteindre le même AS ?
mtr -4rzwc5 80.67.167.82
Start: 2019-07-22T18:34:53+0200
HOST: renaud-pc Loss% Snt Last Avg Best Wrst StDev
1. AS??? bt.lpa.lan 0.0% 5 1.6 1.6 1.6 1.8 0.1
2. AS??? lac-net1.bslyo256.Lyon3eArrondissement.francetelecom.net 0.0% 5 21.8 22.0 20.9 22.8 0.7
3. AS??? 10.125.112.206 0.0% 5 21.6 21.5 21.1 22.2 0.4
4. AS??? ae20-0.nclyo201.Lyon03.francetelecom.net 0.0% 5 23.9 22.8 21.0 24.2 1.3
5. AS??? ae42-0.nrlyo201.Lyon3eArrondissement.francetelecom.net 0.0% 5 23.7 22.8 21.9 23.7 0.6
6. AS??? ae42-0.nridf101.Paris3eArrondissement.francetelecom.net 0.0% 5 29.1 28.1 26.9 29.6 1.2
7. AS??? ae41-0.noidf001.Paris3eArrondissement.francetelecom.net 0.0% 5 28.6 35.9 27.4 54.2 10.8
8. AS??? 193.253.13.206 0.0% 5 27.2 27.6 27.2 28.2 0.4
9. AS??? lag-th2-1.pa3-2.rt.hopus.net 0.0% 5 27.5 27.5 27.0 28.3 0.5
10. AS??? leonix.pa3.hopus.net 0.0% 5 28.4 28.1 27.9 28.4 0.2
11. AS50628 te0-2-1.a9k-2.core.brs.bb.leonix.net 0.0% 5 28.3 28.0 27.7 28.3 0.3
12. AS57199 te1.901-1.ccr1072.core.brs.ip4.infra.milkywan.net 0.0% 5 28.8 28.3 27.7 28.8 0.5
13. AS34019 gw-milkywan-th2.bb.hivane.net 0.0% 5 28.0 28.0 27.5 28.6 0.4
14. AS57199 te4.2985-1.ccr1072.core.dc2.ip4.infra.milkywan.net 0.0% 5 27.3 28.0 27.3 28.3 0.4
15. AS20766 moon.milkywan.space
-
Nous sommes UP sur FranceIX depuis ce soir :)
On a un petit souci en IPv6, donc je l'ai activé en v4 uniquement, ne vous inquiétez pas :)
-
Nous sommes UP sur FranceIX depuis ce soir :)
On a un petit souci en IPv6, donc je l'ai activé en v4 uniquement, ne vous inquiétez pas :)
Merci Hugues. C'est possible d'en savoir un peu plus, stp?
Milkywan est connecté en direct à France IX, avec une liaison dédiée? 1Gbps?
Ou alors via un partenaire-revendeur?
Leon.
-
La page des membres de FranceIX dit 200 Mbps.
-
200M dans 10G semble-t-il : https://x.com/huguesdelamure/status/1184875525908697093
-
Milkywan est connecté en direct à France IX, avec une liaison dédiée? 1Gbps.
Un port 10G LR sur DC2, avec un commit à 200M (qu'on veille à ne pas dépasser) :)
-
On a résolu le souci en IPv6 ! :-)
-
C’était quoi alors ? :)
-
Cela se fête. :)
Champagne !!! pas de côte de Blaye, il fait mal à la tête :p ( private joke).
-
C’était quoi alors ? :)
Surement MikroTik, évidemment.
En gros, j'avais des neighbors NDP qui passaient en 'failed' et la résolution MAC échouait, ce qui blackholait du trafic.
J'ai testé des trucs, j'ai fini par lancer une maintenance, reboot & MàJ le routeur, et au reboot ça s'est remis à marcher. Bon, soit...
Champagne !!! pas de côte de Blaye, il fait mal à la tête :p ( private joke).
Tu sais qu'en 1 semaine et demi sur place, je n'ai bu que du champagne et de la bière ? Pas une seule goute de leur machin local, je n'aime pas le rouge...
Merci en tout cas ;)
-
A quand votre arrivée dans un DC à marseille sur un switch France IX ?
Hugues je ne trouve pas la weathermap de milkywan, tu peux mettre le lien ?
-
A quand votre arrivée dans un DC à marseille sur un switch France IX ?
On est en remote peering, pour un POP à Marseille, il nous faudrait un partenariat avec un opérateur là bas :)
La Weathermap n'est plus accessible en dehors du réseau de MilkyWan, pour l'instant
-
Ah dommage j'aurais aimé voir la weathermap. Je suis curieux et jaime bien savoir et apprendre.
Tu penses qu elle sera dispo ou pour le moment cest non ?
-
Le souci c'est que tu as des petits malins qui s'en servent pour nous attaquer, donc ça donne assez moyennement envie de la remettre en public... On verra quand ça se sera durablement calmé.
En attendant, voilà à quoi elle ressemble :) :
(https://pix.milkywan.fr/pJiIeiGk.png)
-
Bien foutu et ergonomique avec les codes couleurs. Je comprends mieux ! Les transitaire peering et point dechange. Tout comme votre site
Tu peux nous expliquer dans les grandes lignes ce que tu rentends par remonte peeling avec marseille france IX ?
-
Entends par remote peering*
-
Mon port FranceIX Marseille est livré sur un VLAN sur mon port à Paris :)
-
Donc mylki est présent physiquement dans un Pop à marseille alors ou jai mal compris ?
Car tu dis que ton port a marseille France ix, donc tu es dans un pop ?
Or sur le site de France XI je vois que vous ete à DC2 mais rien a marseille
-
Je veux comprendre. Jai pas ton niveau d'expertise.
-
FranceIX Marseille est un IXP à Marseille, mais tu peux te faire livrer le port à Paris, sans avoir besoin d'être à Marseille.
Donc on est présents sur FranceIX Marseille, mais sans être à Marseille
-
Et donc pour les interconnexions. A l'instant t un abonné milkywan qui habite marseille passe par france ix marseille du coup quand il se balade sur le net ? Quel est l interet d etre présent physiquement a Marseille alors pour vous ? Rajouter de nouveaux peerins et donc d interco ?
-
Joindre les réseaux qui sont présents à marseille seulement. Ça ne concerne pas spécialement les clients des 4 gros FAI. Après j'ai fait une demande de peering à SFR sur Marseille, on verra si ils répondent. Dans ce cas, on enverrait le trafic de leurs clients dans le Sud directement là bas, ce qui permettrait d'avoir la config déjà prête pour faire du régionalisé quand on migrera le port à Marseille :)
-
Je ne comprends pas trop la différence entre les "Customers" en violet et les transitaires en rouge sur la WeatherMap, si je comprends bien, Milky est le transitaire des customers ? (Griffon, Petrus, quantic) ? c'est bien ca ?
-
Oui. Après je vais les enlever de la carte bientôt, c'est ingérable sinon, on a trop de clients xD
-
Tu pourrais pas les agréger ?
-
Nop :/
-
J'attend votre retour pour la souscription du VPN au fait :P
-
Ca arrive, Thibault traite les bons de commande en attente ce soir. Vu qu'on est tous bénévoles, on fait ça sur notre temps libre :)
-
Pas de soucis je sais, merci, je patiente jusqu'au week end prochain
-
J'ai remis l'accès à la Weathermap en public, par contre, elle est dorénavant en v6 Only, parce qu'on est en 2019 :)
-
Un beau Forbidden sur le port 80 et 443 :)
443 où le certificat est celui de as-stats.milywan.fr
Apache/2.4.33 (Ubuntu) Server at weathermap.milkywan.xyz Port 80
Du coup j'ai changé le TLD en .fr, ça marche mieux ...
-
Ça a (quasiment) toujours été en .fr, tu as trouvé ce lien où ?
-
Ben :
https://hastebin.milkywan.xyz
https://pix.milkywan.xyz
Ça paraissait logique :)
Plus :
Ma conf ? Ben tout ça est en IPv6 fixe et avec du routage statique -> https://weathermap.milkywan.xyz/Neo.html
Et j'ai deux serveurs DNS chez moi, un serveur DNS chez Online et un serveur DNS chez K-Net.
bref, je pourrais passer en Dynamique, mais ça serait un calvaire à gérer et routage dynamique obligatoire.
et
Si besoin -> https://weathermap.milkywan.xyz/
Et enfin avec les keywords "weathermap milky", le 1er lien que je trouve : https://tls.imirhil.fr/https/weathermap.milkywan.xyz
-
Ben :
https://hastebin.milkywan.xyz
https://pix.milkywan.xyz
Ben, c'est les .fr aussi, depuis longtemps ^^
Effectivement, en 2017, j'avais mis du xyz, mais purée, c'était y'a presque 3 ans quoi :P
Je vais désactiver les records du .xyz, il ne sert plus en public.
-
Internet n'oublie pas :)
Je vais désactiver les records du .xyz, il ne sert plus en public.
Ou un CNAME ? Un 301 au lieu du 403 ?
-
Ça fait 2 ans que j'ai mis un 301, au bout d'un moment... :)
-
Ah ?
Bon ben ... le temps du xYz est révolu :)
-
J'ai remis l'accès à la Weathermap en public, par contre, elle est dorénavant en v6 Only, parce qu'on est en 2019 :)
Cool :D
-
C'est pas délirant comme en France tout le monde propose désormais de l'IPv6 au moins en fixe. Mais ici je vais devoir me passer de la weathermap, il n'y en a nulle part :D
-
Question conne, mais j'aime bien comprendre, désolé si ca parait évident pour vous.
Quand je suis en VPN chez MW (vive MW au passage et tous les FAI/Heebrgeur associatif :-* ), pourquoi je monte à Paris avant de revenir sur Lyon pour venir taper lafibre.info ? Sachant que MW peere déjà et est présent à Lyon IX. Je tiens juste à préciser que ca ne me gène absolument pas, mais je suis dans une démarche de compréhension, tout va bien de mon coté, tout marche nickel !
Je suis à Marseille
Tracert en VPN MW
D‚termination de l'itin‚raire vers lafibre.info [2a01:6e00:10:410::2]
avec un maximum de 30 sautsÿ:
2 25 ms 24 ms 25 ms gateway.ip6.vxlan1100.cluster.par.milkywan.net [2a0b:cbc0:1100:1::1]
3 24 ms 25 ms 24 ms be0-0.ccr1072.core.dc2.infra.ip6.milkywan.net [2a0b:cbc0:1::45]
4 36 ms 30 ms 30 ms adeli.par.franceix.net [2001:7f8:54::111]
5 1788 ms 44 ms 31 ms bgp1.adeli.biz [2a01:6e00:10:42c::1]
6 30 ms 31 ms 32 ms lafibre.info [2a01:6e00:10:410::2]
Tracert sans VPN MW (avec Numericable), là je passe directement par LyonIX
D‚termination de l'itin‚raire vers lafibre.info [46.227.16.8]
avec un maximum de 30 sautsÿ:
1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * D‚lai d'attente de la demande d‚pass‚.
3 7 ms 6 ms 6 ms lim1rj-ge-0-1-5.0.numericable.net [213.245.254.145]
4 8 ms 6 ms 8 ms 57.229.154.77.rev.sfr.net [77.154.229.57]
5 37 ms 37 ms 38 ms 54.216.129.77.rev.sfr.net [77.129.216.54]
6 23 ms 23 ms 22 ms 30.12.6.109.rev.sfr.net [109.6.12.30]
7 18 ms 17 ms 17 ms adeli-l2.peers.lyonix.net [77.95.71.11]
8 17 ms 17 ms 21 ms lafibre.info [46.227.16.8]
-
J'imagine que le tunnel fourni par MW se termine sur un équipement à Paris, du coup tout ton trafic sorte forcément par là.
-
Ah oé d'accord je me sens con, Oui ca doit être le routeur Mikrotic qui termine toutes les connexions VPN, et il se trouve à Paris.
-
Tracert en VPN MW
2 25 ms 24 ms 25 ms gateway.ip6.vxlan1100.cluster.par.milkywan.net [2a0b:cbc0:1100:1::1]
Yep, visiblement ça sort à Paris.
Tu peux demander à ce que ton tunnel sorte à Lyon, mais il faut que ton opérateur (Numéricâble) peer avec Milkywan sur Lyon, sinon tu vas quand même passer par Paris (dans ce cas en gros, pour atteindre le bout de ton tunnel, tu vas forcément passer par l'interconnexion entre Numéricable et Milkywan, qui est à Paris)
-
Yep, visiblement ça sort à Paris.
Tu peux demander à ce que ton tunnel sorte à Lyon, mais il faut que ton opérateur (Numéricâble) peer avec Milkywan sur Lyon, sinon tu vas quand même passer par Paris (dans ce cas en gros, pour atteindre le bout de ton tunnel, tu vas forcément passer par l'interconnexion entre Numéricable et Milkywan, qui est à Paris)
Mais je pensais que des qu'on peere dans un GIX (ici LyonIX) on peerait avec tous les membres non, donc SFR/Bouygues/Free/Orange non ? Ou alors SFR/NC ne fait pas de perring public et il faut donc que MW fasse du PNI avec Numericable c'est ca ?
Sur cette page, on peut voir les membres, dont NC et MW
https://www.rezopole.net/fr/membres-rezopole
-
Mais je pensais que des qu'on peere dans un GIX (ici LyonIX) on peerait avec tous les membres non, donc SFR/Bouygues/Free/Orange non ?
Ce serait trop simple :)
Ça dépend de la politique de peering des opérateurs. En gros, on peut séparer les politiques en 3 catégories :
- Open : L'opérateur est ouvert à toutes les demandes de peering
- Selective : L'opérateur demande des étapes préalables avant d'établir le peering (débit d'échange minimum, redondance...)
- Restrictive : L'opérateur ne peer avec presque personne, car il n'autorise que les très gros opérateurs à peerer avec lui
En temps normal, il faut établir une session de peering pour chaque opérateur partenaire de peering, ce qui peut être long si l'IXP a beaucoup d'opérateurs. De plus, cela demande de contacter l'opérateur partenaire de peering pour que lui aussi établisse une session de peering.
Pour résoudre ce problème dans les IXP, il existe des Route-Server. Ils permettent de faciliter le peering entre opérateur, puisqu'il suffit d'établir une session de peering avec le Route-Server pour peer avec tous les autres opérateurs qui ont établi une session avec le Route-Server. La création d'une session avec le Route-Server n'est pas systématique pour les opérateurs (malheureusement), même pour ceux qui ont une politique de peering ouverte (Open)
Orange a une politique de peering restrictive.
SFR, Free et Bouygues ont une politique de peering sélective.
On peut trouver les politiques de peering, ainsi que leurs conditions sur peeringdb.com
-
Ce serait trop simple :)
Ça dépend de la politique de peering des opérateurs. En gros, on peut séparer les politiques en 3 catégories :
- Open : L'opérateur est ouvert à toutes les demandes de peering
- Selective : L'opérateur demande des étapes préalables avant d'établir le peering (débit d'échange minimum, redondance...)
- Restrictive : L'opérateur ne peer avec presque personne, car il n'autorise que les très gros opérateurs à peerer avec lui
En temps normal, il faut établir une session de peering pour chaque opérateur partenaire de peering, ce qui peut être long si l'IXP a beaucoup d'opérateurs. De plus, cela demande de contacter l'opérateur partenaire de peering pour que lui aussi établisse une session de peering.
Pour résoudre ce problème dans les IXP, il existe des Route-Server. Ils permettent de faciliter le peering entre opérateur, puisqu'il suffit d'établir une session de peering avec le Route-Server pour peer avec tous les autres opérateurs qui ont établi une session avec le Route-Server. La création d'une session avec le Route-Server n'est pas systématique pour les opérateurs (malheureusement), même pour ceux qui ont une politique de peering ouverte (Open)
Orange a une politique de peering restrictive.
SFR, Free et Bouygues ont une politique de peering sélective.
On peut trouver les politiques de peering, ainsi que leurs conditions sur peeringdb.com
Donc NC/SFR n'est pas présent sur les RS pour échanger et parler BGP avec tous les membres c'est ca ? contrairement à MW
Sur le lien de Rezopole, il est noté que NC est en OPP = peeering ouvert
-
Alors, plusieurs choses :
- Le tunnel de Solidus se termine à Paris, parce que nous n'avons pas (encore) de serveur OpenVPN à Lyon. En effet, on ne termine pas les OpenVPN sur un Mikrotik, mais sur une VM SSD à DC2.
- On peer déjà avec SFR/NC sur LyonIX
- On sort par Paris parce qu'on route au plus proche avec Adeli :)
-
SFR, Free et Bouygues ont une politique de peering sélective.
Free, c'est clairement Restrictive :)
-
Free, c'est clairement Restrictive :)
Certes, mais publiquement ils s'affichent comme ayant une politique sélective (même si dans les faits, c'est aussi dur de peer avec Free qu'avec Orange)
-
J'aurais plutôt dit cher que dur... :D
-
- On sort par Paris parce qu'on route au plus proche avec Adeli :)
Par contre, si le tunnel se terminait à Lyon, on est d'accord que le traffic passerait par Lyonix ?
-
J'aurais plutôt dit cher que dur... :D
#Cogent et consœurs ?
-
Hopus et paid-peering, surtout :)
-
Par contre, si le tunnel se terminait à Lyon, on est d'accord que le traffic passerait par Lyonix ?
Là comme ça, je dirais que oui, mais pas certain pour autant, pour la partie NC -> MW
-
Hopus
Ah oui, je l'avais oublié celui-là :)
-
Alors, plusieurs choses :
- Le tunnel de Solidus se termine à Paris, parce que nous n'avons pas (encore) de serveur OpenVPN à Lyon. En effet, on ne termine pas les OpenVPN sur un Mikrotik, mais sur une VM SSD à DC2.
- On peer déjà avec SFR/NC sur LyonIX
- On sort par Paris parce qu'on route au plus proche avec Adeli :)
Au temps pour moi, je pensais qu'il y avait un Mikrotic quelque part pour les tunnels VPN, je sais plus sur quel topic j'ai lu ca pour milky...Ou alors il y 'a un Mikrotic à Lyon mais qui est pas encore operationnel pour acheminer les tunnels vpn ?
Je cite ton offre VPN Hugues "Routage régionnalisé a Lyon pour Orange, SFR, Bouygues et K-Net"
- On peer déjà avec SFR/NC sur LyonIX >> Un PNI ou via les RS ?
Donc, en résumé, tous les abonnés VPN chez Milky "montent" à Paris, ca n'a rien à avoir avec une histoire de peering avec un FAI, c'est parce que présentement, le serveur OpenVPN est à Paris, c'est aussi simple que ca
Merci pour vos explications en tout cas
-
Donc, en résumé, tous les abonnés VPN chez Milky "montent" à Paris, ca n'a rien à avoir avec une histoire de peering avec un FAI, c'est parce que présentement, le serveur OpenVPN est à Paris, c'est aussi simple que ca
Il n’y a pas qu’OpenVPN comme VPN. Il y a (probablement) des mikrotik à Lyon qui peuvent recevoir des terminaisons de tunnels L2TP ou GRE
-
Il n’y a pas qu’OpenVPN comme VPN. Il y a (probablement) des mikrotik à Lyon qui peuvent recevoir des terminaisons de tunnels L2TP ou GRE
Oui j'ai pas pensé aux autres "tunnels" effectivement. Mais je parlais pour OpenVpn
-
Au temps pour moi, je pensais qu'il y avait un Mikrotic quelque part pour les tunnels VPN, je sais plus sur quel topic j'ai lu ca pour milky...Ou alors il y 'a un Mikrotic à Lyon mais qui est pas encore operationnel pour acheminer les tunnels vpn ?
Il y'a 3 Mikrotik à Lyon. 2 pour le coeur de réseau et 1 routeur de collecte qui achemine :
- Les L2TP
- Les GRE
- Les EoIP
OpenVPN étant chiffré, et vu que je n'ai pas envie de ruiner les perfs du pauvre routeur de collecte, on n'en fait qu'aux endroits où on a des serveurs. C'est prévu à Lyon, mais les choses prennent du temps.
Je cite ton offre VPN Hugues "Routage régionnalisé a Lyon pour Orange, SFR, Bouygues et K-Net"
Je pense que je vais l'enlever, K-Net m'envoie son trafic n'importe comment, mon transit à Lyon est KO depuis 1 an, donc plus de régionalisé pour Orange, et Bouygues persiste à m'envoyer le traf par Paris. Il n'y a qu'SFR qui fait le taf correctement et passe par LyonIX
- On peer déjà avec SFR/NC sur LyonIX >> Un PNI ou via les RS ?
Via une session directe, donc ni l'un ni l'autre (mais ça ne change pas grand chose, je ne comprend pas l'intéret de la question)
Donc, en résumé, tous les abonnés VPN chez Milky "montent" à Paris, ca n'a rien à avoir avec une histoire de peering avec un FAI, c'est parce que présentement, le serveur OpenVPN est à Paris, c'est aussi simple que ca
Les deux. De toute façon, le routage régionalisé avec les 4 gros FAI, c'est plus un voeu pieu qu'une réalité... J'ai 90% des tunnels qui se finissent à Paris, parce que c'est l'endpoint avec le moins de latence vers les abonnés...
-
Je pensais que dans le peering, c’était soit du peering public, soit privée (PNI)
En quoi consiste une session direct ?
Ce que j'ai compris, quand tu arrives dans un GIX, tu parles BGP et tu annonces ton AS et réseau en prenant un port chez le GIX, le GIX te fournit une IP de son range, et tu balances ta sauce, avec tout les membres qui sont dans le RS (contrairement aux Gros FAI et à Jaguar Network, pour citer un exemple)
Sinon tu fais un PNI
Mais je ne savais pas qu'il y avait une 3eme possibilité
-
Je pensais que dans le peering, c’était soit du peering public, soit privée (PNI)
En quoi consiste une session direct ?
En temps normal, il faut établir une session de peering pour chaque opérateur partenaire de peering, ce qui peut être long si l'IXP a beaucoup d'opérateurs. De plus, cela demande de contacter l'opérateur partenaire de peering pour que lui aussi établisse une session de peering.
En gros, quand tu es sur un IXP, tu as 2 moyens de faire du peering public. Soit tu établis une session de peering pour chaque partenaire de peering (opérateur), soit tu peer avec le RS. Et les deux ne sont pas incompatibles.
Par exemple, tu rejoins un IXP avec les opérateurs A, B et C. Les opérateurs A et C peer avec le RS, mais pas l'opérateur B. Si tu veux peer avec A et C, il te suffit de peer avec le RS (mais tu peux aussi établir une session de peering avec chacun d'entre eux). Pour peer avec B, tu es obligé de contacter B et d'établir une session de peering avec lui.
-
Sur FRance-IX, tu peut voir si un membre est sur le route serveur ou non : https://www.franceix.net/fr/france-ix-paris/members-in-paris/
SFR AS15557 n'est pas sur les route serveur, afin de sélectionner les peer.
-
Hello !
Petite mise à jour de ce post, 2 ans après ! Le post original est disponible ici : https://lafibre.info/milkywan/archive-milkywan-as57199
MilkyWan est un opérateur associatif que j’ai fondé en 2015, c’était, pendant quelques années mon terrain de jeu personnel. Au fil du temps, j’ai commencé à ramener du monde autour du projet et à faire grandir l’infrastructure, de quelques routeurs dans ma chambre, on est passés à des serveurs dédiés chez Online, des VM chez Hivane ou K-Net à un vrai réseau national indépendant.
(https://pix.milkywan.fr/BWHtB3Si.png)
1/ Infrastructure
MilkyWan est un réseau associatif expérimental qui fête ses 5 ans cette année, qui a commencé avec des routeurs Linux et des ERL montés en tunnel un peu partout, et qui évolue maintenant vers une infra en propre.
Je ne vais pas parler de l'ancienne infra ici, c'était en gros basé sur : des dédiés Online, GRE,FRR,BGP,et un peu d'L2TP.
En Février 2018, nous avons décidé de passer à l’étape supérieure en devenant un “vrai” opérateur, en exploitant notre propre infrastructure système et réseau, de la bordure aux routeurs de collecte, en passant par les serveurs et les NAS.
En 2020, MilkyWan s’étend sur près de 7 points de présence, sur toute la France.
1.a/ Côté Matos :
Nous exploitons uniquement des routeurs Mikrotik CCR pour notre coeur de réseau. Ce ne sont pas les meilleurs routeurs du marché, mais ils ont un rapport de conso par port et un tarif incroyable et imbattable à l’heure actuelle.
Dans la gamme, nous exploitons :
- Des CCR1072 : Le plus gros routeur de Mikrotik, 8 ports 10Gbit, une grosse capa de routage (Quasi 80MPPS en théorie)
- Des CCR1036 : Dans leur version 2x10G, ils sont pratiques pour les sites sateliltes ou couplés avec un switch d’agrégation
- Des CCR1016 : Dans leur version 1x10G. Sur les petits sites où l’on raccorde des ports 1Gbit/s
- Des CCR1009 : Dans leur version 1x10G. Ce sont les routeurs avec lesquels on a commencé, et que nous déprovisionnons aujourd’hui.
- Des CRS317 : Des gros switch 16x10G qui nous servent de multiprise sur les sites où nous avons une autre baie déportée ou un routeur trop peu dense
- Des RB3011 et 4011 : Des CPE à l’origine, mais qui font d’excellents routeurs de collecte pour des tunnels GRE, L2TP ou EOIP
En dehors de Mikrotik, nous avons aussi divers équipements :
- FS S5850 : Un gros switch 4x100G, 2x40G et 48x10G, idéal en coeur de réseau sur les gros sites
- Brocade GS648p : Pour les sites avec des ports Cuivre, il permet de les agréger vers ses 2x10G vers un plus gros switch
- Cisco 7301 : Un petit routeur avec seulement 4x1G, il sert de LNS pour les clients ADSL et d’endpoint pour quelques tunnels
- Divers serveurs dont je vous passerais la config, mais avec plus de 100Go de RAM à chaque fois :)
Nous sommes présents dans de nombreux DC, par ordre d’apparition et avec le stuff associé :
- Scaleway DC2 (Vitry, sud de Paris) : CCR1072, un R610 et un RB4011
- SFR Venissieux (Venissieux, Sud de Lyon) : CCR1009, CRS317 et un RB3011
- Telehouse 2 (Paris 11) : CCR1072, CRS317 et un RB4011
- Leonix Datacenter Bourse (Paris 2) : CCR1072, FS S5850, Ciscoo 7301, Brocade GS648p, Des HP G6/7 et un NAS Thecus
- Cogent Rennes : CCR1016
- CIV Lille : CCR1036
- (Soon) HosTELyon (Lyon 7) : à définir
1.b/ Côté Ressources IP :
En IP Legacy, nous avons un /22 alloué par le RIPE : 45.13.104.0/22 et un /24 alloué par Gitoyen : 80.67.167.0/24
L’idée à terme est d’utiliser le premier pour nos clients et le second pour l’infrastructure et les services gérés par l’asso
En IPv6, nous avons un /32 alloué par AppliWave : 2a0b:cbc0::/32 et un /29 alloué par le RIPE : 2a0e:e700::/29
Nous n’utilisons quasiment que le premier, sauf pour quelques tunnels délégués avec un /48 du second bloc.
Et évidemment, l’AS57199, un AS 16 Bits puisqu’il n’est pas possible de faire de la commu étendue sur un AS32b avec Mikrotik. Et c’est quand même plus classe d’avoir un AS 16b, il faut le dire :)
1.c/ : Coté Interconnexions.
Je pense qu’on peut affirmer sans trop se mouiller que nous sommes l’opérateur associatif (à part Hivane, mais il est plus en mode "closed") le mieux interconnecté de France :-)
Coté Transit, nous avons :
- 30Gbit/s de transit AppliWave (AS200780), sur DC2 (Nominal), TH2 (Backup) et Venissieux (Régional), ce dernier est temporairement shut le temps d’une Maj coté Appliwave
- 10Gbit/s de transit Leonix Telecom (AS50628) sur Bourse.
- 10Gbit/s de transit partiel Hivane Network (AS34019), qui nous partage ses nombreux peerings
- 10Gbit/s de transit protégé Acorus (AS35280) sur TH2, le dernier arrivé, pour contrer les DDoS :)
Coté Peering, nous avons :
- 10G sur le LyonIX à Venissieux, avec comme remote peering activé : TopIX, TouIX, SwissIX, CIXP, NetIX, LoNAP, AuvernIX, GrenoblIX, EuroGIX
- 10G sur Rezopole Paris à TH2, l’IXP de Rezopole à Paris (sur la même fabric qu’à Lyon, c’est un peu notre backup de LyonIX)
- 10G sur FranceIX Paris à DC2, avec comme remote peering FranceIX Marseille.
- 10G sur le LillIX, à Lille, on peer notamment avec OVH et Ielo-Liazo là bas.
- 1G sur le Breizh-IX à Rennes, IXP dont je suis membre du bureau, et qui sent bon le kouign amann :)
Ce qui nous donne un total de 101Gbit/s de capacité vers internet. Une capacité honorable :-)
D’ailleurs, on est régulièrement dans le top HE France sur le nombre de peers IPv4/v6 <3
1.d/ Le reste :
Nous sommes déclarés à l’ARCEP (code MILK), membres de la Task Force IPv6 (enfin moi), et membres d’aucune association d’opérateurs associatifs, vu que la principale ne correspond pas à notre vision et qu'il n'y en a pas d'autres :-)
2/ Le setup :
Nous exploitons donc un backbone MikroTik. Il est pur IP (pas de MPLS, de SR ou autre), Il est drivé par un control plane doté d’une part d’ OSPF en IPv4 et… des routes statiques en IPv6. En effet, l’implémentation de MikroTik d’OSPFv3 étant complètement cassée au niveau des routes récursives et rend le machin impossible à utiliser avec iBGP. OSPFv3 est néanmoins installé et fonctionnel, même si il ne fait que de la décoration à l’heure actuelle. Et d’autre part iBGP, en full mesh, et avec une fullview sur tous les POP, vu que nous sommes amenés à livrer du transit sur ceux-là.
Tout ce backbone est relié par des Lan2Lan, des Waves ou des FON à 10Gbit/s (sauf Rennes, en 1G), fournis par AppliWave, Leonix ou Quantic Telecom (merci à eux !)
On essaie d’avoir un backbone le plus redondant possible, mais c’est assez compliqué, nous faisons donc confiance à la fiabilité de celui de nos sponsors (et on n’a que très rarement eu de coupures).
On relie aussi les serveurs, NAS, et les routeurs de collecte en 10G (quand ils en sont capables) ou en N*1G.
On a de la MTU9k partout, ce qui permet de proposer des tunnels L2 avec une MTU 9k entre tous nos PoP, et aussi simplement qu’avec du MPLS, grâce à EoIP.
Voici la Weathermap du réseau, accessible à cette URL en IPv6 Only : https://weathermap.milkywan.fr/milkywan.html
(https://pix.milkywan.fr/KYH0OSvt.png)
Coté routage interne (hors core), on fait de l’eBGP avec des AS Privés, chaque routeur de collecte a un AS, ce qui permet de bénéficier de la qualité du filtrage de BGP tout en ayant un IGP moins tentaculaire qu’OSPF.
Les clients Tunnel ayant demandé une redondance sont également livrés en BGP avec AS privé, c’est plus simple à gérer, encore une fois :)
3/ L’équipe
Nous sommes actuellement 7 dans l’asso :
- Thibault, développeur et trésorier
- Corentin, Admin Sys
- PM, Admin réseau
- Gaëtan, Admin Sys
- Aloïs, Admin Réseau et Vice-Président
- Guilhem, Responsable Communication et DA
- Moi, Admin Réseau, Sys et Président
On cherche à recruter (ici), si ça vous dit, venez ! :)
4/ Les services
On propose tout ce qu’un “vrai” opérateur peut vous proposer, à peu de choses près.
Pour résumer, on a deux catégories de produits :
4.a/ : Les services Opérateurs
On propose tout un tas de services à destination des opérateurs, dans le lot :
- Transit IP BGP : Le plus connu, on propose du transit, avec un commit démarrant à 7,5Mbit/s jusqu’à 1Gbit/s (voir plus, mais vous n’avez plus besoin de nous, je pense :)), sachant que notre réseau est plutôt très développés (parmi les meilleurs de France selon PeeringDB)
- Lan2Lan : On vous transporte en 100M/1G ou plus, entre tous nos PoP !
- Housing : On vous héberge, à Paris Bourse, Online DC2 ou Lyon HosTELyon. Et on a des partenariats pour les autres DC, au besoin :)
- Gros blocs IP : Si vous êtes un opérateur qui débute, on peut vous router un bloc d’IP (jusqu’à /25), avec une facturation progressive.
- FTTO : On sait livrer de la FTTO un peu partout en France pour vous livrer tout ce qui est au dessus.
4.b/ Pour les particuliers :
- Tunnels IP : Un simple tunnel (ou VPN) depuis le réseau de MilkyWan. On peut même faire de la redondance avec BGP :)
- Machines virtuelles : On propose plein de VM, je ne vais pas tout détailler ici, mais le point important, c’est que le réseau n’est pas bridé !
Ce qu’on prévoit de proposer dans un futur proche :
- FTTH : D’abord sur le réseau du SIEA parce que c’est simple, ensuite sur d’autres RIP, et pour finir partout en France quand Orange décidera de relâcher son Bistream FTTH…
- ADSL : En fait, on pourrait déjà le faire, mais l’intérêt est assez faible, donc pour l’instant, ça attend l’infra pour le FTTH.
Bref, on reste sur du classique, mais efficace, et avec un excellent réseau :)
4.c / Les services Web :
Principalement des services qu’on utilise en interne, et qu’on ouvre au plus grand nombre :
- Pix (https://pix.milkywan.fr/): Un service d’hébergement d’images
- Hastebin (https://hastebin.milkywan.fr/) : Un service de pastebin plutôt joli
- Pad (https://pad.milkywan.fr/) : Un service de pad collaboratif assez efficace.
Conclusion :
Bref, voilà un petit post sur ce qu’on fait, on est plutôt content du chemin parcouru depuis 2015, et on espère que les 5 prochaines années seront encore plus fructueuses, on est en train de préparer un gros déploiement sur la région lyonnaise, et, qui sait, peut-être qu’on arrivera enfin à descendre à Marseille, Toulouse et les villes du sud :-)
Si vous voulez voir nos nouvelles, on est sur Twitter (@MilkyWan_net), sur IRC (#milkywan sur freenode, n'hésitez pas à rejoindre #lafibre aussi, on se marre bien :) ).
Le site web est ici : https://milkywan.fr/ (https://milkywan.fr/)
On est sur PeeringDB et je maintiens les objets RIPE à jour :)
Je vous laisse sur quelques photos de l’infra :)
TH2
(https://pix.milkywan.fr/cSjOtBoL.JPG)
DC2
(https://pix.milkywan.fr/WhbdHeEE.jpg)
1G !
(https://pix.milkywan.fr/tEgJqelb.JPG)
BRS
(https://pix.milkywan.fr/0ABicv8F.jpg)
-
L'évolution sur 5 ans de MilkyWan est impressionnante. ::)
Bonne continuation à tous et hâte de voir le résultat pour les 10ans du projet 8)
-
Salut Hugues.
Merci pour ce gros update. Quelle aventure! C'est franchement impressionnant.
Quelques questions indiscrètes (comme d'hab):
Côté "frais récurrents" (transit, Wave, Lan2Lan, hébergement en datacenter), vous vivez toujours en grande partie sur du mécénat d'opérateurs amis? Tu accepterais de partager une estimation de la part du mécénat (frais récurrents uniquement)?
On peut avoir une idée du chiffre d'affaire actuel? Et du nombre de clients?
Quels sont vos clients? Uniquement des particuliers et associations? Ou alors aussi des entreprises? Si entreprises, quel type d'entreprise?
Tu dis ne pas être en phase avec les idées de la FFDN, tu peux nous en dire plus? Tu parles des discours révolutionnaires, et sensationnalistes de Benjamin et ses camarades, ou c'est plus profond?
Tu ne parles pas des DDoS, vous en êtes où avec ça, vu que vous avez eu des soucis ces derniers mois? Vous avez mis en place des protections efficaces?
L'équipe est uniquement bénévole? Ou alors il y a des salariés (même à temps partiel)?
Question de newbie: Si vos routeurs ne gèrent que les AS 16bits, ça permet quand même de dialoguer avec des AS 32 bits?
Leon.
-
Côté "frais récurrents" (transit, Wave, Lan2Lan, hébergement en datacenter), vous vivez toujours en grande partie sur du mécénat d'opérateurs amis? Tu accepterais de partager une estimation de la part du mécénat (frais récurrents uniquement)?
Oui, toujours en grande partie. Difficile de donner un chiffre vu que les offres ne sont pas vraiment au catalogue de certains de nos sponsors.
Mais la tendance est à la baisse, d'une part, parce qu'on a envie d'être indépendant, et d'autre part, parce qu'on commence à le pouvoir.
Et du nombre de clients?
On a environ 60 clients qui paient, et on doit en avoir une trentaine qui ne paient pas (soit parce qu'ils étaient déjà là quand on filait du VPN gratos, soit parce qu'on les sponso)
Quels sont vos clients? Uniquement des particuliers et associations? Ou alors aussi des entreprises? Si entreprises, quel type d'entreprise?
Majoritairement des particuliers et asso, on a aussi quelques entreprises, généralement de la SASU ou assimilé, mais c'est marginal sur les revenus/trafic.
Tu dis ne pas être en phase avec les idées de la FFDN, tu peux nous en dire plus? Tu parles des discours révolutionnaires, et sensationnalistes de Benjamin et ses camarades, ou c'est plus profond?
Non, je les trouve infiniment trop politiques à mon gout.
Par exemple, quand tu veux adhérer à la FFDN (une fédération d'opérateurs, à la base), tu dois leur soumettre tes statuts, et si ils ne les trouvent pas assez "éthiques", ils demandent des changements. De manière générale, la FFDN est une association très politique (pour le meilleur et pour le pire), et il y'a des débats en son sein qui me semblent complètement étrangers.
Leur vision globale est "tout le monde peut devenir FAI", ça me dérange, parce qu'avoir 50 associations qui ne font que louer du VPN en ayant leur coeur de réseau à TH2, ça n'a pas grand intérêt (et j'exagère à peine). Disons que pour eux, l'infra technique est un "prétexte" pour en faire de la politique (genre neutralité du net, libertés individuelles, etc...). Si les gens veulent en faire, ça les regarde, mais je ne veux pas mêler mon asso à ça.
En gros, tu dois gérer ton association de la manière qu'ils l'entendent, et ça me dérange. Donc on bosse avec des opérateurs de la FFDN, mais on n'est pas à la FFDN.
Tu ne parles pas des DDoS, vous en êtes où avec ça, vu que vous avez eu des soucis ces derniers mois? Vous avez mis en place des protections efficaces?
Je ne parle pas des DDoS parce que nous sommes sur un forum public, et je n'ai pas envie de donner des billes à celui/ceux qui ont plaisir à me faire chier :)
L'équipe est uniquement bénévole? Ou alors il y a des salariés (même à temps partiel)?
Bénévole, et en manque cruel de temps :)
Question de newbie: Si vos routeurs ne gèrent que les AS 16bits, ça permet quand même de dialoguer avec des AS 32 bits?
C'est les communautés étendues qu'ils ne gèrent pas, pas les AS 32Bits.
-
Wahou, Belle évolution.
-
C'est les communautés étendues qu'ils ne gèrent pas, pas les AS 32Bits.
Petite précision pour ceux qui ne voient pas le rapport : un communauté classique BGP c’est 16-bits:16-bits, par exemple 57199:65080.
Avec un AS 32 ça ne passe pas, il faut utiliser les « grandes » communautés (large communities), et non les communautés étendues (qui elles sembles supportées et appelées route-targets). Par exemple : 204092:100:150
-
Ah oui, my bad. Je ne joue avec aucune des deux.
Je crois que les Route Target ne fonctionnent réellement (sur Mkt) qu'en MP-BGP avec MPLS, le tag est sans effet le reste du temps.
-
Je n’ai joué avec les communautés étendues que très récemment (pour le filtrage RPKI car IOS-XE exporte le statut de la route comme ça : generic:0x43000000:0x0, avec 0x0 pour les routes signées, 0x1 pour les routes non-signées et 0x2 pour les routes mal annoncées)
J’ai longtemps mélangé les deux auparavant :D
-
Nous exploitons donc un backbone MikroTik. Il est pur IP (pas de MPLS, de SR ou autre),
Le MPLS c'est ça qui a un peu tué un opérateur dans l'Est de la France (en dehors d'erreurs de gestion), car ça s'équilibrait très mal, les switchs au milieu avaient énormément de mal à équilibrer la charge (car ils voient que les 2 IP d'interco), et aussi l'équipe, on était un peu largué, seul le boss savait gérer, et s'il lui arrivait le moindre pb de santé...
Du coup pour bâtir le nouveau backbone d'OrneTHD, on est aussi parti sur du pur VLAN et IP. Comme ça les switchs au milieu voient toutes les IP (et pas seulement celles d'interco) et ça s'équilibre super bien. Et aussi, des gens moins calés que moi peuvent comprendre comment ça fonctionne et m'aidé à gérer tout ça. On a des techs qui savent tirer de la fibre et maintenant, gérer des VLAN.
Donc bravo pour ces choix pleinement assumés, je vous souhaite le meilleur pour le futur :)
-
Le MPLS c'est ça qui a un peu tué un opérateur dans l'Est de la France (en dehors d'erreurs de gestion), car ça s'équilibrait très mal, les switchs au milieu avaient énormément de mal à équilibrer la charge (car ils voient que les 2 IP d'interco), et aussi l'équipe, on était un peu largué, seul le boss savait gérer, et s'il lui arrivait le moindre pb de santé...
En fait, on a fait simple: Tout ce qui n'est pas offload est banni.
Donc MPLS : Pas offload, à quoi bon avoir des intercos 10G si les routeurs saturent avant ?
Merci en tout cas <3
-
Le MPLS c'est ça qui a un peu tué un opérateur dans l'Est de la France (en dehors d'erreurs de gestion), car ça s'équilibrait très mal, les switchs au milieu avaient énormément de mal à équilibrer la charge (car ils voient que les 2 IP d'interco)
Si switch == de base, alors il ne voit que les adresses MAC des deux routeurs, pas les IPs (et en effet ça fait toujours les deux mêmes valeurs, donc en LAG ça n'équilibre rien du tout).
S'il est plus performant et voit les IPs, ce ne sont pas les IPs d'interco mais les IPs source et dest (et là ça a des chances de faire un plus grand nombre de cas possibles).
et aussi l'équipe, on était un peu largué, seul le boss savait gérer, et s'il lui arrivait le moindre pb de santé...
Le recrutement et la formation c'est pas facile :-\
-
Le MPLS c'est ça qui a un peu tué un opérateur dans l'Est de la France (en dehors d'erreurs de gestion), car ça s'équilibrait très mal, les switchs au milieu avaient énormément de mal à équilibrer la charge (car ils voient que les 2 IP d'interco)
Il y avait peut-etre d'autres erreurs dans la conception du machin (genre des switch entre les routeurs, en plus charges à faire l'eclatement du traffic sur plusieurs liens).
et aussi l'équipe, on était un peu largué, seul le boss savait gérer, et s'il lui arrivait le moindre pb de santé...
Autre erreur assez commun chez les petits operateurs : le big boss est le seul qui comprends sufissament bien comment ca marche.
Du coup pour bâtir le nouveau backbone d'OrneTHD, on est aussi parti sur du pur VLAN et IP. Comme ça les switchs au milieu voient toutes les IP (et pas seulement celles d'interco) et ça s'équilibre super bien.
Autant une infra IP ca peut etre parfaitement legitime, le concept de VLAN (etendu) c'est a banir dans un coeur reseau operateur. Ca peut aller sur la partie acces, mais pas n'importe comment. Seulement l'utilisation des tags 802.1q pour multiplexer un port est acceptable.
Et aussi, des gens moins calés que moi peuvent comprendre comment ça fonctionne et m'aidé à gérer tout ça. On a des techs qui savent tirer de la fibre et maintenant, gérer des VLAN.
Fais gaffe, un reseau operateur et un LAN d'entreprise, c'est pas le meme chose. Les gens (generalement formates pour le LAN d'entreprise), ca se forme, meme si parfois il y a des ratees magnifiques.
-
le concept de VLAN (etendu) c'est a banir dans un coeur reseau operateur.
👍
-
D'ailleurs, il n'y en a aucun dans le coeur de réseau de MilkyWan ::)
-
salut, est-ce que vos statuts sont publique quelque part? Ce pourrait être interressant à partager pour permettre des expériences similaires :)
-
Hello, ils n'ont rien de très intéressants, on n'a pas de collégiale, de conseil d'administration ou autre trucs comme chez FFDN, un simple président+bureau renouvelable tous les ans par les membres. Donc non, pas prévu, autant communiquer sur l'infra ne me dérange pas, autant, notre tambouille interne reste interne, mw c'est quand même un peu un truc "entre nous", contrairement à d'autres projets qui sont plus ouverts et collégiaux.
-
Salut !
On a mis en place un nouveau routeur à TH2, le tout nouveau CCR2004 de Mikrotik ;D
(https://pix.milkywan.fr/s6b9gnmf.jpeg)
(https://pix.milkywan.fr/hbaUEN0I.jpeg)
-
ça y est vous avez accroché SFR
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 17 | 12 | 10 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| 26.206.185.81.rev.sfr.net - 1 | 101 | 100 | 0 | 9 | 100 | 1 |
| 74.56.154.77.rev.sfr.net - 1 | 258 | 257 | 1 | 1 | 29 | 1 |
| 57.185.90.92.rev.sfr.net - 0 | 528 | 528 | 7 | 8 | 19 | 7 |
| milkywan-l2.peers.lyonix.net - 0 | 622 | 622 | 6 | 7 | 14 | 7 |
|te4.2986.ccr1072.core.dc2.infra.ip4.milkywan.net - 0 | 322 | 322 | 13 | 14 | 17 | 14 |
| moon.milkywan.space - 15 | 7 | 6 | 14 | 14 | 14 | 14 |
| web.milkywan.cloud - 0 | 309 | 309 | 14 | 14 | 43 | 15 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
-
Il y a une cage SFP+ à 25 Gb/s sur le CCR2004 ?
-
Il semble que oui (ou en tout cas SFP28) :
Number of 25G SFP28 ports 2
https://mikrotik.com/product/ccr2004_1g_12s_2xs
P.S : d'ailleurs on trouve chez fs.com des SFP28 10 km BiDi (25GBASE-BX10-U) à 116 €. Ce n'est pas donné, mais cela reste accessible.
https://www.fs.com/fr/c/25g-bidi-sfp28-3618
-
Le peering avec SFR est up depuis le 5 Décembre 2018 tout de même :D
-
P.S : d'ailleurs on trouve chez fs.com des SFP28 10 km BiDi (25GBASE-BX10-U) à 116 €. Ce n'est pas donné, mais cela reste accessible.
On en a commandé une paire d'ailleurs
-
On en a commandé une paire d'ailleurs
On prod quand ?
-
Je te dirais quand elle arrivera :D
-
C'est cool de voir que vous testez le 25Gb/s. Vous commencez à jouer dans la cour des grands, là... C'est du lourd.
Ca serait pour quels liens le 25Gb/s?
Au moins entre Bourse et TH2?
C'est envisagé à DC2 également?
La boucle TH2-DC2-Bourse avec 3 liaisons 25Gb/s, ça serait la grande classe.
Leon.
-
Salut,
Ca sera la porte de collecte Appliwave qui sera en 25G (derrière leur backbone 100G), donc en pratique, tous les L2L entre TH2 et Lille, Lyon et DC2, ainsi que le transits passeront par le lien 25G :)
-
Je me demandais où cela allait. Cela veut dire qu'Appliwave a aussi des ports 25 Gb/s SFP28 (peut-être le même Mikrotik ?).
Ce n'est quand même pas courant les ports 25 Gb SFP28.
-
C'est un Arista 7280 de l'autre coté, et c'est assez courant le 25G maintenant :)
-
Merci pour le retour et la précision. Bon, disons que je n'en ai pas vu beaucoup.
-
Salut,
Ca sera la porte de collecte Appliwave qui sera en 25G (derrière leur backbone 100G), donc en pratique, tous les L2L entre TH2 et Lille, Lyon et DC2, ainsi que le transits passeront par le lien 25G :)
OK, merci, c'est plus clair.
Je croyais que TH2-DC2 était sur un lambda, mais je me trompais.
Du coup, vous n'avez qu'un seul lamba dédié (ou Fibre noire carrément?) dans le réseau MilkyWan, pour faire les 3km TH2-Bourse, c'est ça?
Leon.
-
Yep, c'est ça. En fait, on pourrait en avoir plus, mais un L2L c'est plus sécurisé et plus pratique a gérer (coté xco surtout), donc pour l'instant c'est bien comme ça :)
DC2-BRS sera en lambda aussi si tout se passe bien.
-
Yep, c'est ça. En fait, on pourrait en avoir plus, mais un L2L c'est plus sécurisé et plus pratique a gérer (coté xco surtout), donc pour l'instant c'est bien comme ça :)
Pour être sur de comprendre : tu veux dire que dans le cas d'un lambda dédié (passif, sans équipement actif côté fournisseur), tu as besoin d'une qualité de cross-connect irréprochable (perte) pour assurer ton lien de plusieurs dizaines de km?
Surtout en comparaison d'une simple liaison 10Gb locale au datacenter de quelques centaines de mètres?
Ou alors est-ce que l'avantage, c'est qu'un seul et unique cross-connect peut transporter simultanément plusieurs LAN2LAN entre ton fournisseur et toi?
Ou encore, le fait que tu peux utiliser du "bidi" sur du LAN2LAN donc monopoliser 1 seul cross-connect, alors que le vrai lambda dédié (passif) impose le plus souvent 1 paire de cross-connect?
Ou alors tu pensais à autre chose?
Leon.
-
Tu peux mutualiser un port 10G pour plusieurs services, donc ca permet de faire plus avec moins :)
Ensuite, tu n'as pas a gérer pas la redondance du lien, ce qui est pratique quand tu as des Mikrotik qui ont un peu de mal a converger
Et les optiques coutent moins cher, ce qui permet d'avoir du spare.
Bref, dans le cas d'un réseau asso, c'est assez arrangeant :)
-
OK, merci, j'ai compris.
C'est beaucoup plus simple pour un réseau associatif, effectivement.
Mais on est d'accord que pour un réseau "pro", ça pourrait potentiellement réduire la fiabilité, pour 2 raisons:
- le lien unique entre ton routeur et ton fournisseur (Appliwave) devient un quasi SPOF (Single Point of Failure) pour le site TH2, donc si ton optique tombe tu perds beaucoup de choses d'un seul coup
- Sur chaque lien entre datacenters, au lieu d'avoir un seul et unique équipement actif de chaque côté (ton routeur) en mode "lambda dédié passif", tu as une cascade de plusieurs équipements actifs (le tien puis ceux de ton fournisseur), ce qui réduit en théorie la fiabilité.
L'idéal, pour un opérateur "pro" qui a les moyens, c'est à priori de gérer soi même, allumer soi même ses liaison (lambda dédié passif ou FON) sur un MAN parisien, et d'assurer soi même la redondance de liens optiques.
Mais je comprends que pour une association, les choix soient plus pragmatiques, surtout avec des moyens humains et matériels limités (Mikrotik).
Leon
-
- le lien unique entre ton routeur et ton fournisseur (Appliwave) devient un quasi SPOF (Single Point of Failure) pour le site TH2, donc si ton optique tombe tu perds beaucoup de choses d'un seul coup
C'en est un, même
- Sur chaque lien entre datacenters, au lieu d'avoir un seul et unique équipement actif de chaque côté (ton routeur) en mode "lambda dédié passif", tu as une cascade de plusieurs équipements actifs (le tien puis ceux de ton fournisseur), ce qui réduit en théorie la fiabilité.
Oui certes, après tu es censé pouvoir tolérer des pannes.
L'idéal, pour un opérateur "pro" qui a les moyens, c'est à priori de gérer soi même, allumer soi même ses liaison (lambda dédié passif ou FON) sur un MAN parisien, et d'assurer soi même la redondance de liens optiques.
C'est ce que je fais chez Leonix, on a un backbone DWDM Passif entre tous les sites, avec pour partie nos fibres en propre, et pour le reste des PFON louées à des tiers.
-
Salut,
Ca sera la porte de collecte Appliwave qui sera en 25G (derrière leur backbone 100G), donc en pratique, tous les L2L entre TH2 et Lille, Lyon et DC2, ainsi que le transits passeront par le lien 25G :)
Une porte de collecte c'est quoi concrètement? Un switch ? Une fibre ou du cuivre ? J'ai fait des recherches sur internet et même sur le blog de spyo et sur ses articles *créer son fai * je n'arrive pas à visualiser une porte de collecte dans une infra.
-
C'est un port sur un switch ou un routeur entre 2 réseaux :)
-
Donc milkywan loue la porte de collecte à appliwave. Et appliwave loue la porte de collecte vers quelle fai ? Orange sfr free Bouygues ou ovh ou nerim ? Car je pense que ce sont les seuls fai détenteurs de leur dslam non ?
-
C'est un peu une sorte de poupée russe non ?
-
Attention, porte de collecte ne veut pas dire "ADSL", tu peux faire passer des clients xDSL dessus, mais en l'occurence, on se fait livrer des L2L et du transit sur nos portes à nous.
-
Depuis plusieurs semaines, on bosse sur la nouvelle mouture du réseau de MilkyWan, qui, pour résumer :
- Déplace la partie hébergement dans des datacenters moins interconnectés mais moins chers
- Rend moins critique le coeur de réseau Mikrotik actuel
- L'upgrade en CCR de 2nde génération (ARM64) sur les routeurs critiques (Paris et Lyon)
- Prépare la transition de ceux ci vers autre chose (un jour :) )
- Accompagne la croissance de l'infra système pour que le réseau ne soit pas un point bloquant
Je ferais un post détaillé quand l'infra sera en place, pour l'instant, je vous poste juste la Weathermap ;)
(https://pix.milkywan.fr/c125T2rP.png)
Pour info :
LOG : Lognes, la future salle serveurs d'Appliwave
D2S : DC2Scale, à Velizy-Villacoublay
-
Pour info :
LOG : Lognes, la future salle serveurs d'Appliwave
D2S : DC2Scale, à Velizy-Villacoublay
Tsssssss c'est CBO !!!!!
-
Un hommage ?
-
Un hommage ?
Il parait que c'est lié oui !
Mais bon Croissy-Beaubourg
-
Ah je croyais que c'était pour CamBrOusse ;).
-
Ah je croyais que c'était pour CamBrOusse ;).
je t'insulterais bien, mais pas envi que tu me coupe certains liens :)
-
Ah je croyais que c'était pour CamBrOusse ;).
Non ça c'est moi ;D
-
Non ça c'est moi ;D
Non toi c'est ca
(https://images.caradisiac.com/images/9/7/5/4/169754/S0-france-allemagne-deux-pays-deux-cultures-de-la-route-558274.jpg)
-
Non toi c'est ca
Julien qui part de la frontière française :
(https://media.giphy.com/media/7zuWJTLfuiEQo/giphy.gif)
Julien sur l'autobahn ( vitesse illimitée) :
(https://media.giphy.com/media/GD5xkDtFPUpY4/giphy.gif)
Julien qui arrive au datacenter Equinix FR5 :
(https://media.giphy.com/media/TgQCVpkQSZ81G/giphy.gif)
Bon allez, apéro time :)
-
Julien qui part de la frontière française :
(https://media.giphy.com/media/7zuWJTLfuiEQo/giphy.gif)
Julien sur l'autobahn ( vitesse illimitée) :
(https://media.giphy.com/media/GD5xkDtFPUpY4/giphy.gif)
Julien qui arrive au datacenter Equinix FR5 :
(https://media.giphy.com/media/TgQCVpkQSZ81G/giphy.gif)
Bon allez, apéro time :)
Tu as oublié Julien qui reçoit sont PV de 10€ ;D
Désolé pour le HS Hugues
-
MilkyWan chez Sungard à Lognes, c'est cool ça!
C'était un datacenter plutôt haut de gamme il y a quelques années, et orienté "finance", non?
Avec le téléport Satellite sur le même site, on se prend à rêver de connexions MilkyWan par satellite!
(oui, ça ne fait rêver que moi, je sais...).
https://www.expertmedia.fr/infrastructures/
Leon.
-
Alors pour l'instant c'est sungard lognes, oui !
Mais en fait, vu nos besoins/contraintes de dispo, la salle serveurs d'Appliwave, ça suffira très bien, et le prix du Kwh n'a rien a voir :D
Et si on veut de la haute dispo, on a DC2Scale et HosTELyon :)
-
Alors pour l'instant c'est sungard lognes, oui !
Mais en fait, vu nos besoins/contraintes de dispo, la salle serveurs d'Appliwave, ça suffira très bien, et le prix du Kwh n'a rien a voir :D
Tu parles d'une salle serveurs d'AppliWave à Sungard-Lognes?
Ou alors d'une salle serveur dans les bureaux d'AppliWave?
Leon.
-
Julien a signé pour une sorte de paquebot mothership à Croissy Beaubourg pour en faire le nouveau siège d'Appliwave. Avec une triple adduction, à la fois en n*100G avec son backbone, et des waves vers des DC sympa (notamment sungard). Donc pour nous c'est parfait. Coté élec, ça sera "juste" ondulé, mais bon, si ça coupe, ça coupe, on est pas hébergeur de données critiques, on peut tolérer une coupure :)
https://x.com/JulienOHAYON/status/1313367093799202816
-
OK. Je comprends mieux. Parce que Sungard, c'était plutôt cher et haut de gamme il y a quelques années. Je ne sais pas si ça a changé...
D'ailleurs il y a aussi Euclyde Datacenter à Lognes.
On sait ce qui explique ces multiples datacenters de taille conséquente dans une petite ville de banlieue à 20km de Paris?
Leon.
-
Des prix que j'en ai eu, ça va Sungard franchement. On a du matos là bas, mais on va le déplacer ;)
-
On sait ce qui explique ces multiples datacenters de taille conséquente dans une petite ville de banlieue à 20km de Paris?
C'est que c'est pile poil au bord de l'autoroute...
(https://media.giphy.com/media/d3mlE7uhX8KFgEmY/giphy.gif)
-
Et du RER A :)
-
Pour continuer dans le hors sujet des Datacenter autour de Lognes:
Juste en face des nouveaux locaux d'AppliWave, on trouve un datacenter d'Atos, de taille très correcte.
https://www.google.com/maps/@48.8222419,2.6396573,256a,35y,90h,39.42t/data=!3m1!1e3
Atos chercherait à se séparer de ce datacenter. Peut-être une opportunité à saisir! ;)
https://www.cfdt-atos.org/2019/03/15/actualite-sociale-et-economique-de-lues-atos-france-mars-2019/
Projet hercules
En 2018, la direction avait pourtant promis de préserver l’emploi des salariés des data center par reskilling et upskilling dans le cadre du projet Hercules. Ce projet consiste (pour la France) à fermer le data center de Croissy Beaubourg et arrêter l’activité Data Center sur les sites d’Aubervilliers et Saint-Ouen. La cible étant de consolider l’ensemble de cette activité sur 3 sites : Les Clayes-Sous-Bois (nouveau data center), Marcoussis (hébergé chez le partenaire Data4) et Trélazé.
Leon.
-
On vient de rajouter un transitaire : FiberWay AS49434 ( a k a Harmony Hosting) en 10G à DC2Scale !
C'est routé via TH2 (et DC2 quand on aura la Wave entre les deux).
(https://pix.milkywan.fr/4Sl9JMd5.png)
Ils ont un joli réseau de quelques centaines de gig de capa et les points de peerings importants en France :)
-
Pour continuer dans le hors sujet des Datacenter autour de Lognes:
Juste en face des nouveaux locaux d'AppliWave, on trouve un datacenter d'Atos, de taille très correcte.
https://www.google.com/maps/@48.8222419,2.6396573,256a,35y,90h,39.42t/data=!3m1!1e3
Atos chercherait à se séparer de ce datacenter. Peut-être une opportunité à saisir! ;)
https://www.cfdt-atos.org/2019/03/15/actualite-sociale-et-economique-de-lues-atos-france-mars-2019/
Projet hercules
En 2018, la direction avait pourtant promis de préserver l’emploi des salariés des data center par reskilling et upskilling dans le cadre du projet Hercules. Ce projet consiste (pour la France) à fermer le data center de Croissy Beaubourg et arrêter l’activité Data Center sur les sites d’Aubervilliers et Saint-Ouen. La cible étant de consolider l’ensemble de cette activité sur 3 sites : Les Clayes-Sous-Bois (nouveau data center), Marcoussis (hébergé chez le partenaire Data4) et Trélazé.
Leon.
Olivier MIS à visité ce DC Atos, un très beau DC, ca m'aurait bien tenté mais beaucoup trop gros en cout d'entretien !
Nous ca sera clairement pas un DC, quoi que vu ce qu'annonce certains en DC pour moins bien ^^.
Ce sera un NRO amélioré et on va faire du housing de test chez nous (notre lab).
Sinon pour en revenir à Sungard, les prix y sont vraiment pas délirant et le service et la qualité est top ! En + on peut avoir de la vrai capa élec dans les baies sans pb.
Au niveau adduction possible sur ce DC, il y a déjà 2 chemins via le GCBLO Orange (que nous avons) et 2 chemins via le RER A (que la RATP dispose) ou nous avons des PFON vers d'autres endroits.
Bref un très bon DC qui est en plus modernisé !
-
Nous avons finalisé hier soir avec Alexis le POP de DC2Scale à Vélizy.
Ce POP est le premier de notre nouveau design d'infra Système. Les changements sont d'abord Hardware :
- Passage des Hyperviseurs sur des G8 avec deux Xeon E5-2650v2, 256Go de RAM et du réseau en n*10G (pour l'instant on n'a installé qu'1x10G mais tout est prêt coté conf pour passer à 2)
- Passage du Filer d'une solution propriétaire (Thecus) à une solution libre (serveur Lenovo ex IBM avec TrueNAS, ex FreeNAS)
Coté Système, on a fait quelques changements aussi :
- Proxmox reste, mais sur la nouvelle majeure v6
- Coté Stockage, on passe d'iSCSI sur un NAS Thecus à du NFS sur un NAS TrueNAS. Le NAS a 6 disques de 6To configurés en RAID1+ZFS
- On utilise maintenant le CloudInit intégré à Proxmox, ce qui nous fait provisionner une VM 10x plus vite qu'avant.
- Tous les CPU supportent AES, ce qui donne de très bonnes perfs sur OpenMPTCPRouter
Coté Réseau, on a littéralement tout refait. L'archi précédente était basée sur du routage soft : Les HV étaient directement interco en BGP au coeur de réseau et géraient le routage aux VM, avec une couche de NAT pour les VM sans IPv4 Publique. Il y'avait aussi du VxLAN pour la com inter-HV
Autant le dire clairement : C'était une catastrophe. Coté perfs, tout s'est écroulé à force d'ajouter des VM, à chaque DDoS, le Conntrack des HV se remplissait et un bête Syn-Flood impactait tous les clients de l'hyperviseur. Bref, c'était pas une bonne idée, on aura au moins tenté des trucs.
Maintenant, on a tout cramé pour repartir sur des bases saines :
- Le routage est géré par un vrai routeur Hardware, un Brocade CES2024
- La partie Firewall est gérée en Stateless par Proxmox avec des simples ACL IPSET
- Le NAT est géré par une VM dédiée, uniquement pour les clients sans IPv4 publique
- Il n'y a plus de comm L2 inter-HV, tous les hôtes ont des IP en /128 ou /32 pour que tout passe par le routeur.
Et en termes de perfs, ça bombarde, on atteint la limite de routage des CCR2004 sans offload (environ 4Gbit/s)
Coté Électricité, on a aussi fait quelques changements :
- Tout est double alimenté (mais pour le futur RB4011 il va falloir que je sois créatif, surement en utilisant le PoE passif comme d'une 2è alim)
- Nous avons investi dans des PDU Managés (APC AP7953) 32A, de quoi voir venir l'avenir :)
Coté Automation/Sys :
- Tout est orchestré par Ansible+AWX et un frontend maison, on ne touche plus a la conf des HV/Routeurs, donc c'est archi fiable
Bref, c'est clairement le POP dont je suis le plus fier, on a du joli matos, un design KISS et robuste, une conso élec contenue (La baie consomme environ 700W) et une capa qui nous permettra de voir venir l'avenir sans trop d'inquiétude !
La prochaine étape est de migrer toutes les VM à Bourse sur ce POP (et dans le futur, les VM seront réparties entre D2S, CBO et HosTELyon, mais je n'ai pas encore eu le temps de m'occuper des autres POP ;) )
Je vous laisse sur quelques photos :
(https://pix.milkywan.fr/KZHaZkQU.JPG)
(https://pix.milkywan.fr/A1P0Hz8d.JPG)
(https://pix.milkywan.fr/1d1bivhb.JPG)
(https://pix.milkywan.fr/9ho7MeQ6.JPG)
-
Beau matériel !
Pour le contrôleur HP iLo, c'est toujours de licences limitées dans le temps pour avoir l’accès en iKVM du serveur ? (vs Dell Drac qui est une licence à vie du serveur)
-
Non, c'est à vie (et une recherche sur reddit permet d'avoir les licences qui vont bien ;) )
-
Sur du HP Gen8 (en tout cas chez moi), iLO 4 est présent par défaut en version "gratuite", qu'il est possible d'upgrader avec une licence à vie
Edit : Arf, trop lent :)
-
Et... On vient de changer de logo, ce qui inaugure notre nouvelle charte graphique ;D
-
Dés que https://milkywan.fr/ est mis à jour je récupère les éléments pour mettre à jour le forum.
-
- Proxmox reste, mais sur la nouvelle majeure v5
Erreur ou pas ? Car on en est a la version 6.3 la...
-
Oui on me l'a fait remarquer, on passe bien de la v5 à la v6 :)
-
Salut Hugues.
Quel est l'intérêt de ce nouveau POP DC2Scale pour MilkyWan ? Juste profiter de la présence de vos mécènes (probablement Appliwave pour ne pas le citer) pour faire de l'hébergement?
Ou alors c'est plus que ça?
Leon.
-
J'en avais déjà parlé plusieurs posts avant, l'idée c'est de sortir l'hébergement des POP de connectivité, pour avoir de meilleurs tarifs/conditions.
Et accessoirement, ne travaillant plus chez Leonix, ni eux ni moi n'ont d'intérêt a continuer de collaborer, donc MilkyWan part de Bourse sous peu :)
Là on aura 1/2 baie à CBO, on a 1 baie à DC2Scale et 1/4 de baie à HosTELyon !
Et en l'occurence, on traite direct avec DC2Scale, Olivier est une vieille connaissance ;)
Dans tous les cas, on fait en sorte d'avoir une double adduction avec le moins de SPOF possible. Il n'y a qu'à HosTELyon où je n'ai pas trouvé de solution pour une 2nde adduction pour le moment :)
-
Il n'y a qu'à HosTELyon où je n'ai pas trouvé de solution pour une 2nde adduction pour le moment :)
En passant par chez moi, je suis sur le chemin entre HosTELyon et les bureaux de Rezopole :)
-
Et... On vient de changer de logo, ce qui inaugure notre nouvelle charte graphique ;D
C'est dommage : au lieu d'avoir la Voie Lactée, on a un simple ersatz de Saturne :P Va donc falloir aussi renommer la boîte en SaturnWan ;D
-
C'est déjà compliqué d'avoir de bonnes idées de noms/logos, si en plus faut que ça concorde ;)
-
La Concorde, c'est bien cette antenne relais égyptienne au milieu de Paris?
-
Hello !
Pour info, les POP de CBO (chez Appliwave) et LYN (chez HosTELyon) sont UP depuis quelques jours (ou heures pour ce dernier) :)
On sait faire tout ce qu'on fait ailleurs : Housing, L2L, Transit IP, etc. Les VM arriveront d'ici quelques jours le temps de configurer les hyperviseurs !
Une petite photo de CBO, avec notre premier ASR (qui servira pour les liens FTTH/xDSL) :
(Je précise qu'on a pas encore fait le cable management, les fibres et les câbles élec étant temporaires, le temps qu'on commande les bons sur fs.com)
(https://pix.milkywan.fr/0NnbzdKI.jpg)
-
Salut Hugues.
Il n'y a pas de serveur de stockage sur ce site, contrairement à DC2Scale?
N'hésites pas à nous montrer une mise à jour de ta weathermap, pour comprendre où en est le réseau, car c'est vraiment pas évident à suivre ces évolutions.
Leon.
-
Tu utilises quel hyperviseur ?
Tu as vu des impacts en terme de performance réseau vs "Bare Metal" ?
Bouygues veut virtualiser ses serveurs de test de débit. J'ai eu une mauvaise expérience il y a 6 ans, mais je ne sais pas si le dégradation venait de la virtualisation ou du NAT, la VM étant sur une IP privée, avec des équipement derrière que je ne maîtrisait pas.
-
Salut Hugues.
Il n'y a pas de serveur de stockage sur ce site, contrairement à DC2Scale?
N'hésites pas à nous montrer une mise à jour de ta weathermap, pour comprendre où en est le réseau, car c'est vraiment pas évident à suivre ces évolutions.
Leon.
CBO est entièrement sur SSD, donc il n'y a pas de serveur de stockage.
-
D'ailleurs je ne sait pas si c'est intentionnel mais https://weathermap.milkywan.fr/ est juste une boucle de redirection 302 infinie :)
-
D'ailleurs je ne sait pas si c'est intentionnel mais https://weathermap.milkywan.fr/ est juste une boucle de redirection 302 infinie :)
Il faut avoir vu la dernière vidéo de Vilebrequin pour que ça marche. ;D
Là, no souci pour moi.
-
D'ailleurs je ne sait pas si c'est intentionnel mais https://weathermap.milkywan.fr/ est juste une boucle de redirection 302 infinie :)
Aucun problème chez moi à 12:27.
Tu as une IPV6 ?(De mémoire la map est disponible uniquement en IPV6)
-
D'ailleurs je ne sait pas si c'est intentionnel mais https://weathermap.milkywan.fr/ est juste une boucle de redirection 302 infinie :)
C'est de ton coté :-)
-
Hello ! Que de réponses :)
Salut Hugues.
Il n'y a pas de serveur de stockage sur ce site, contrairement à DC2Scale?
Non, le stockage se fera sur les hyperviseurs directement, en SSD :)
N'hésites pas à nous montrer une mise à jour de ta weathermap, pour comprendre où en est le réseau, car c'est vraiment pas évident à suivre ces évolutions.
Elle est systématiquement à jour et en accès public ! Je la remets ici si tu n’as pas d’IPv6 :
(https://pix.milkywan.fr/PRo9kV9o.png)
Tu utilises quel hyperviseur ?
Proxmox
Tu as vu des impacts en terme de performance réseau vs "Bare Metal" ?
Non, pas vu de grosse différence mais chez MilkyWan ce sont les CCR en cœur de réseau qui limitent le débit global (aux alentours de 3G par client)
Pour un Speedtest, je mettrais ça sur un serveur Baremetal perso, pour avoir la stack la plus simple et perf possible
J’en profite d’ailleurs, si tu veux un VLAN MilkyWan sur ton serveur chez Appliwave, ca doit pouvoir se faire, on est à quelques baies d’écart :)
D'ailleurs je ne sait pas si c'est intentionnel mais https://weathermap.milkywan.fr/ est juste une boucle de redirection 302 infinie :)
Souci de cache, y’avait une redirection avant en effet :)
-
Aucun problème chez moi à 12:27.
Tu as une IPV6 ?(De mémoire la map est disponible uniquement en IPV6)
Oui mais Firefox a décidé de tenter IPv4 seulement, etrange
-
Impossible, il n’y a plus de record A depuis un bail sur ce FQDN :)
-
Impossible, il n’y a plus de record A depuis un bail sur ce FQDN :)
Effectivement, bon je ne sait pas ce que Firefox essaye de faire j'ai flush tout ses caches et maintenant ca marche
-
Pour un Speedtest, je mettrais ça sur un serveur Baremetal perso, pour avoir la stack la plus simple et perf possible
J’en profite d’ailleurs, si tu veux un VLAN MilkyWan sur ton serveur chez Appliwave, ca doit pouvoir se faire, on est à quelques baies d’écart :)
Merci.
Je vais suivre ton conseil qui était aussi ma première idée pour le serveur Appliwave.
Pour Bouygues on pourra tester, la nouvelle architecture (que je ne gère pas du tout) sera en parallèle des serveurs existants (que je gère) pendant au moins quelques mois, ce qui permettra de comparer les performances. J’espère vraiment pour Bouygues que la nouvelle architecture sera a la hauteur, vu l'argent investit. Par exemple pour SpeedTest.net de nouveaux serveurs seront déclarés sous le nom Bouygues Telecom.
-
Et... On vient de changer de logo, ce qui inaugure notre nouvelle charte graphique ;D
Le forum est à jour normalement. Il faut peut-être vider le cache, le nom des logo étant inchangés.
(https://lafibre.info/images/associatif/logo_milkywan_big.png)
-
J'ai plusieurs questions, par curiosité, concernant les branchements, parce que ce n'est pas évident à suivre.
Si on prends l'exemple de D2S récemment publié sur twitter :
(https://pix.milkywan.fr/V76KkuX8.jpg)
(https://pix.milkywan.fr/VRnJ4TP9.jpg)
(https://weathermap.milkywan.fr/images/milkywan.png)
J'ai entouré 4 câbles DAC qui semblent relier le routeur Brocade au Switch Dell, ce qui correspond à la weathermap avec 4x10Gb/s.
Ensuite en 1, 2, 3 on a deux câbles DAC et une FO reliant le switch Dell à hv01.d2s, hv02.d2s et stor01.d2s, donc chacun avec 10 Gb/s.
On voit en 4, 5, 6 des câbles RJ45 (2 oranges et un jaune) qui relient cette fois ci le routeur Brocade à hv01.d2s, hv02.d2s et stor01.d2s : il s'agit là de lien 1 Gb/s ? Car sur la weathermap c'est noté 2x 10 Gb/s mais depuis le switch vers les équipements et pas depuis le routeur
Question : pourquoi il y a un lien être switch et serveur (en DAC et FO) mais aussi entre routeur et serveur (en RJ45) ? Plutot de que brancher les serveurs uniquement sur le switch tel que noté sur la weathermap ? Ca a un intérêt pour du routage ?
Ou alors j'ai pas tout compris.
Et vers ou vont les FO indiquées par une flèche ?
Comment se fait le lien de ces équipement vers le reste du réseau MW (DC2, TH2, CBO) tel que sur la weathermap ?
Merci
-
J'émets une hypothèse : Les liens RJ45 vers les serveurs, c'est pas tout simplement le IDRAC/ILO/IPMI, pour manager les serveurs à distance? Donc sans doute sur un VLAN complètement privé et isolé d'Internet.
Et du coup, côté équipement réseau, ces liens partiraient du seul équipement qui a des ports RJ45, le Brocade NetIron. Peu importe que ça soit un routeur ou un switch.
Les fibres optiques qui partent vers l'extérieur c'est les liens vers le reste du monde
* pour les liens indiqués "Wave" (WaveLength) sur la weathermap, c'est des longueur d'onde (lambda) donc ça va vers un MUX optique WDM de leur fournisseur/prestataire. L'optique est dans ce cas certainement "coloré"
* pour les liens L2L (Lan 2 Lan), ça va vers un équipement actif de leur fournisseur/prestataire.
* il y a aussi le transit FiberWay, qui va vers le routeur FiberWay de DC2Scale
Leon.
-
Alors
- Il n'y a que 1x10G par serveur pour l'instant, parce que j'ai pas assez d'optiques pour tout doubler (j'attends de sortir les serveurs de bourse pour récupérer les optiques)
- Les liens RJ c'est en effet les ILO. Dans le futur on les aura sur un switch dédié et une infra séparée, mais pour le moment c'est sur le core en effet !
-
Ok merci pour la réponse :)
Et où se font les liens vers le reste du réseau/autres DC et vers FiberWay ? Ce sont les flèches que j'ai montré ?
-
Port 5 du N4032 c'est la wave 10G vers TH2
Et y'a rien d'autre pour le moment. L'autre cable c'est le transit fiberway !
-
Ok je comprends. D'où le 0 sur la weathermap vers CBO et DC2, c'est en anticipation du futur branchement ?
Autre question (désolé je veux pas être lourd mais c'est intéressant :) ) : pourquoi mettre des RB4011 (à CBO, D2S et Vénissieux) ? Les tunnel IP y sont gérés, avec probablement d'autres choses, mais pourquoi ne pas mettre ces services sur des serveurs plutôt que sur ces routeur RB4011 ?
-
Oui les liens à 0 sont soit en panne soit pas encore physiquement créés
Autre question (désolé je veux pas être lourd mais c'est intéressant :) ) : pourquoi mettre des RB4011 (à CBO, D2S et Vénissieux) ? Les tunnel IP y sont gérés, avec probablement d'autres choses, mais pourquoi ne pas mettre ces services sur des serveurs plutôt que sur ces routeur RB4011 ?
Meilleures perfs, moins de conso, moins de gestion
-
Ok je comprends. D'où le 0 sur la weathermap vers CBO et DC2, c'est en anticipation du futur branchement ?
Autre question (désolé je veux pas être lourd mais c'est intéressant :) ) : pourquoi mettre des RB4011 (à CBO, D2S et Vénissieux) ? Les tunnel IP y sont gérés, avec probablement d'autres choses, mais pourquoi ne pas mettre ces services sur des serveurs plutôt que sur ces routeur RB4011 ?
Ca arrive, on sera UP d'ici 4 semaines max à DC2Scale.
-
J'ai hâte, parce que je serre un peu les fesses là :P
-
J'ai hâte, parce que je serre un peu les fesses là :P
Vive Sipartech (ou pas) ;D
-
Siparterre :D
-
Ma question est peut être bête mais : pourquoi l'infrastructure serveur n'est pas directement là où il y a le plus de lien ?
Par exemple à DC2 au lieu de de DC2scale qui n'a qu'un lien ? Ou encore à Venissieux au lieu de hosTELyon qui n'a qu'un lien également ?
C'est une question de faisabilité ? De prix de l'hébergement ?
-
Je l'ai déjà expliqué plus tôt, en gros :
- On a plus de place : des baies complètes au lieu de U a l'unité
- C'est moins cher : Au lieu de payer au U, on paie au kW
- Ça fait des POP en plus, donc plus de diversité, et c'est marrant
Il faut savoir que tous les DC de connectivité se torchent complètement sur les prix et que ca serait hors budget de dealer avec eux
-
Salut Hugues.
Autre question : qu'est-ce qui détermine le fait de mettre une liaison L2L ou une wavelength dédiée entre 2 sites? La disponibilité à prix raisonnable d'une wavelength entre les 2 sites? Le débit prévu sur cette liaison?
J'ai pas trop compris le coup du routeur ASR 1002. Tu dis qu'il va servir aux accès FTTH et ADSL. Je suis assez surpris pour 2 raisons
* C'est un POP (AppliWave Croissy Beaubourg) où il ne doit pas y avoir d'autres opérateurs que AppliWave. Du coup, c'est AppliWave votre fournisseur de FTTH/ADSL, qui achète à son tour aux 3 gros opérateurs?
* Le POP de Croissy-Beaubourg n'a de vrai backup d'alimentation électrique, contrairement à un datacenter. C'est pas un peu risqué de terminer les accès utilisateurs ici?
Leon.
-
Salut Hugues.
Autre question : qu'est-ce qui détermine le fait de mettre une liaison L2L ou une wavelength dédiée entre 2 sites? La disponibilité à prix raisonnable d'une wavelength entre les 2 sites? Le débit prévu sur cette liaison?
J'ai pas trop compris le coup du routeur ASR 1002. Tu dis qu'il va servir aux accès FTTH et ADSL. Je suis assez surpris pour 2 raisons
* C'est un POP (AppliWave Croissy Beaubourg) où il ne doit pas y avoir d'autres opérateurs que AppliWave. Du coup, c'est AppliWave votre fournisseur de FTTH/ADSL, qui achète à son tour aux 3 gros opérateurs?
* Le POP de Croissy-Beaubourg n'a de vrai backup d'alimentation électrique, contrairement à un datacenter. C'est pas un peu risqué de terminer les accès utilisateurs ici?
Leon.
Je laisse répondre Hugues pour le reste mais :
- Site Ondulés (en cours)
- on se tâte pour mettre un groupe
- on est en IDF sur une zone assez importante, donc les coupures ça ne dure jamais longtemps quand il y en a.
-
Salut Hugues.
Autre question : qu'est-ce qui détermine le fait de mettre une liaison L2L ou une wavelength dédiée entre 2 sites?
La distance, déjà, et la dispo oui. Le débit, 10G ou 25G ça ne change pas grand chose a notre échelle en vrai :)
* C'est un POP (AppliWave Croissy Beaubourg) où il ne doit pas y avoir d'autres opérateurs que AppliWave. Du coup, c'est AppliWave votre fournisseur de FTTH/ADSL, qui achète à son tour aux 3 gros opérateurs?
Tu sais, une collecte L2TP tu peux la récupérer sur un bête routeur IP, depuis n'importe quel POP.
* Le POP de Croissy-Beaubourg n'a de vrai backup d'alimentation électrique, contrairement à un datacenter. C'est pas un peu risqué de terminer les accès utilisateurs ici?
2 raisons :
- C'est ici que l'élec est la moins chère, et un 1002 ça consomme à mort
- l'ASR 1002 a été récupéré chez Appliwave et j'ai eu 10m à faire avec un chariot pour le racker
Tu peux très facilement faire de l'actif/passif en IP/L2TP donc on peut envisager un Mikrotik de backup partout ailleurs en France, par ex
Du coup même si ça coupe, ça sera pas bien dramatique.
En plus, on ne vise pas vraiment beaucoup d'abonnés en xDSL/FTTH vu les tarifs, donc autant éviter de dépenser des sous en mettant cet ASR sur un site ou l'élec coute plus cher :)
-
- l'ASR 1002 a été récupéré chez Appliwave et j'ai eu 10m à faire avec un chariot pour le racker
Putain, ça déconne pas chez Milky.
La mise en prod la moins carbonnée de l'histoire :o
-
Exact ! Par contre il se rattrape sur la conso :D
-
En plus, on ne vise pas vraiment beaucoup d'abonnés en xDSL/FTTH vu les tarifs,
A quand la presentation des offres d'ailleurs ? ;)
-
Transparence totale : J'ai la flemme de m'occuper des CGV etc du coup ça repousse le reste.
Et là je passe mes journées a migrer des VM vers la nouvelle infra donc c'est pas demain que je me mettrais sur la paperasse =)
-
D'ailleurs puisqu'on parle d'IPv6 chez OrneTHD.
Plus d'IPv4 du tout sur les offres de base en VM et Housing :)
Ajouter une couche de NAT sur tout le routage des VM (ce qui a un impact énorme sur les perfs) pour une poignée d'utilisateurs n'a que peu d'intérêt. Donc on a tranché : Plus de CG Nat !
-
D'ailleurs puisqu'on parle d'IPv6 chez OrneTHD.
Plus d'IPv4 du tout sur les offres de base en VM et Housing :)
Ajouter une couche de NAT sur tout le routage des VM (ce qui a un impact énorme sur les perfs) pour une poignée d'utilisateurs n'a que peu d'intérêt. Donc on a tranché : Plus de CG Nat !
-
Donc je reformule, une VM sans l'option IPv4 (option à 2,5€/mois/ip) n'a plus accès en sortie à l'internet IPv4 ?
Pas de DNS64/NAT64 ?
Si oui, cela se passe comment pour github.com ? (site qui reste en IPv4 only et qui peut être nécessaire pour installer des logiciels)
Il y a également des problèmes dans certains pays comme en Allemagne (pays ou l'IPv6 est plus développé que chez nous) mais où le serveur par défaut pour les mises à jour Ubuntu es uniquement en IPv4.
=> Ticket pour demander qu'IPv6 soit un pré-requis pour les serveurs miroirs d'Ubuntu utilisés par défaut (https://lafibre.info/ipv6/ipv6-miroir-ubuntu/)
-
Donc je reformule, une VM sans l'option IPv4 (option à 2,5€/mois/ip) n'a plus accès en sortie à l'internet IPv4 ?
Yep
Pas de DNS64/NAT64 ?
Nop, on pourra étudier d'en monter un si la demande est suffisante, mais vu le nombre de VM en IPv4 NAT, je doute que ce soit intéressant.
Il y a également des problèmes dans certains pays comme en Allemagne (pays ou l'IPv6 est plus développé que chez nous) mais où le serveur par défaut pour les mises à jour Ubuntu es uniquement en IPv4.
On a un cache APT et de toute façon le miroir FR est dual stack
-
D'ailleurs puisqu'on parle d'IPv6 chez OrneTHD.
Plus d'IPv4 du tout sur les offres de base en VM et Housing :)
Ajouter une couche de NAT sur tout le routage des VM (ce qui a un impact énorme sur les perfs) pour une poignée d'utilisateurs n'a que peu d'intérêt. Donc on a tranché : Plus de CG Nat !
Nom de Dieu ! :o
Du coup ce serait intéressant de communiquer davantage et dans la durée, sur les témoignages des membres qui utilisent vos services, des use-cases, etc. Pour dédramatiser le déploiement IPv6 tout ça.
Le must, c'est que MilkyWan deviennent un BE auprès de l'AFNIC pour déposer des noms de domaines et d'y claquer des AAAA d'office aux fesses. Je ne sais pas si c'est dans vos projets.
@vivien: il y a des conditions (nbre de domaines, nbre de clients) à avoir pour un hébergeur pour figurer au baromètre IPv6 ?
-
Nom de Dieu ! :o
Du coup ce serait intéressant de communiquer davantage et dans la durée, sur les témoignages des membres qui utilisent vos services, des use-cases, etc. Pour dédramatiser le déploiement IPv6 tout ça.
Le must, c'est que MillyWan deviennent un BE auprès de l'AFNIC pour déposer des noms de domaines et d'y claquer des AAAA d'office aux fesses. Je ne sais pas si c'est dans vos projets.
@vivien: il y a des conditions (nbre de domaines, nbre de clients) à avoir pour un hébergeur pour figurer au baromètre IPv6 ?
Après on est pas vraiment hébergeur, nos VM servent pour faire du réseau généralement (et honnêtement on doit avoir 90% des abonnés en Dual Stack sur les VM, moins sur les tunnels)
Registrar, c'est pas prévu non, on préfère faire de la fibre :D
-
Plus d'IPv4 du tout sur les offres de base en VM et Housing :)
Donc je reformule, une VM sans l'option IPv4 (option à 2,5€/mois/ip) n'a plus accès en sortie à l'internet IPv4 ?
Tu nous disais ailleurs que la Weathermap et les API sont également IPv6 only... Donc quand un client doit administrer ses machines depuis un accès IPv4 only (WiFi), il est obligé de monter un tunnel IPv6...
C'est clair que je serais pas prêt d'être client...
C'est votre choix, mais ça va en faire fuir plus d'un. C'est peut-être ton objectif, d'ailleurs : faire fuir les clients normaux et ne garder que les puristes, les vrais, les durs.
Leon.
-
C'est votre choix, mais ça va en faire fuir plus d'un. C'est peut-être ton objectif, d'ailleurs.
Oui, on vise les gens techniques, ça a toujours été le cas, depuis le début. Je pense qu'un utilisateur lambda a mieux fait d'être chez OVH ou un autre :
- Support plus disponible et pédagogique
- Console pour manager/réinstaller/commander
- Moins cher
Mais nous, déjà on ne fait pas d'hébergement en soi, c'est un service annexe, notre service principal, c'est de fournir un bon réseau :)
Et ensuite, chez un OVH, tu n'auras jamais :
- Un support avec que des ingés qui savent parler bgp, protocoles bas niveau, etc
- De routage dynamique inter services
- De BGP DFZ
- Un réseau aux petits oignons (l'avantage d'être petit, certes)
Mais c'est assumé, c'est une niche, et ça nous convient a merveille :)
-
Tu nous disais ailleurs que la Weathermap et les API sont également IPv6 only... Donc quand un client doit administrer ses machines depuis un accès IPv4 only (WiFi), il est obligé de monter un tunnel IPv6...
C'est clair que je serais pas prêt d'être client...
C'est votre choix, mais ça va en faire fuir plus d'un. C'est peut-être ton objectif, d'ailleurs : faire fuir les clients normaux et ne garder que les puristes, les vrais, les durs.
Leon.
Je trouve au contraire la démarche en adéquation avec leurs dires :
(https://pic.laniakea.ovh/hUtE2/heGekoVA84.png/raw)
-
Donc quand un client doit administrer ses machines depuis un accès IPv4 only (WiFi), il est obligé de monter un tunnel IPv6...
Je rebondis juste sur ça. On est en 2021, tous les opérateurs mobile et une bonne partie des FAI fixe grand public font de l'IPv6, donc a mon sens, si tu n'as pas de moyen d'accéder a de l'IPv6, c'est plus de la mauvaise volonté qu'une incapacité matérielle
-
Je rebondis juste sur ça. On est en 2021, tous les opérateurs mobile et une bonne partie des FAI fixe grand public font de l'IPv6, donc a mon sens, si tu n'as pas de moyen d'accéder a de l'IPv6, c'est plus de la mauvaise volonté qu'une incapacité matérielle
Mauvaise volonté de la part des opérateurs ou des utilisateurs?
Tu vis certainement dans ton monde de nerd-geek, avec une vision très déformée de la réalité.
Perso, j'ai du SFR-Numéricâble à la maison, pas d'IPv6.
Les hotspots wifi libres que j'utilise assez souvent ne fournissent pas d'IPv6.
L'accès WiFi "invités" de mon lieu de travail (grande entreprise), que j'utilise aussi très souvent, ne fournit pas d'IPv6.
Je continue?
Leon.
-
Oui, tu n'as pas de v6 chez toi, pas de VPN, etc.
Mais si tu le *voulais*, tu en aurais, tu aurais choisi un fournisseur qui propose de l'IPv6, ou pris une petite VM (chez milkywan ou ailleurs) pour te faire un VPN en mobilité.
Et si tu es chez un des 4 opérateurs mobile, tu peux activer IPv6 (si ce n'est pas fait par défaut).
Bref, oui v6 n'est pas encore disponible partout, mais il n'est pas bien difficile d'en avoir si tu en veux.
Et je considère que les utilisateurs de MilkyWan ont ce mode de pensée, ou alors paient l'option v4.
D'ailleurs, on n'a pas encore de panel pour gérer les services, mais quand on en aura un, ll sera Dual Stack. il suffit que le VPN qui serve a accéder à V6 soit sur une VM qui est plantée pour que l'abonné ne puisse plus se dépanner, et ça n'est pas ce qu'on veut.
-
Si vous voulez mon avis, je trouve déjà fou que le déploiement IPv6 soit arrivé à un tel stade.
Rendez-vous compte, Free a tout allumé sur le fixe, et les opérateurs sur le mobile, le taux d'activation est juste fou, alors qu'on aurait pu s'attendre à des activations nettement plus molles hein !
Maintenant il faut de tout : des gens comme Hugues, moi-même et d'autres qui poussent en avant, des acteurs plus gros qui marquent le coup et des acteurs qui sont un peu plus en retrait. Mais au moins ça bouge dans le bon sens et il faut s'en réjouir, voilà, respirez cette joie de vivre :D
-
Mauvaise volonté de la part des opérateurs ou des utilisateurs?
Tu vis certainement dans ton monde de nerd-geek, avec une vision très déformée de la réalité.
Perso, j'ai du SFR-Numéricâble à la maison, pas d'IPv6.
Les hotspots wifi libres que j'utilise assez souvent ne fournissent pas d'IPv6.
L'accès WiFi "invités" de mon lieu de travail (grande entreprise), que j'utilise aussi très souvent, ne fournit pas d'IPv6.
Je continue?
Pour pleurer :
IPv6 est à peine abordé en DUT RT parce que cela ne sert à rien d'après les industriels.
L'Education Nationnale ne sort pas en IPv6 avec Renater.
Covage 74 a désactivé IPv6 suite à des problèmes qui datent bientôt de 2 ans!
Ibloo et Coriolis ont eu des tas d'emmerdes avec l'IPv6 mal configuré avec Covage.
Quand même fou de devoir passer par MW pour faire ce qui devrait être la norme. ;)
-
Maintenant il faut de tout : des gens comme Hugues, moi-même et d'autres qui poussent en avant, des acteurs plus gros qui marquent le coup et des acteurs qui sont un peu plus en retrait. Mais au moins ça bouge dans le bon sens et il faut s'en réjouir, voilà, respirez cette joie de vivre :D
Yep et ce serait cool d'impliquer l'école car les bonnes habitudes se prennent tôt!
-
Par rapport à ça:
Mais nous, déjà on ne fait pas d'hébergement en soi, c'est un service annexe, notre service principal, c'est de fournir un bon réseau :)
Et ensuite, chez un OVH, tu n'auras jamais :
- Un support avec que des ingés qui savent parler bgp, protocoles bas niveau, etc
- De routage dynamique inter services
- De BGP DFZ
- Un réseau aux petits oignons (l'avantage d'être petit, certes)
Qu'est-ce que tu appelles "routage dynamique inter services", stp?
Leon.
-
Si tu as une VM et un Tunnel GRE par exemple, tu peux monter du BGP Privé avec MilkyWan et annoncer comme tu le veux le pool d'IP qu'on t'attribue. Ce qui te permet de faire du failover ou de l'anycast de tes services par exemple.
Ça marche aussi avec 2 tunnels, 2 VM, un serveur en housing... Bref, tu peux utiliser MilkyWan comme un vrai IGP quasi transparent (on fait quand même de l'URPF Strict)
-
@vivien: il y a des conditions (nbre de domaines, nbre de clients) à avoir pour un hébergeur pour figurer au baromètre IPv6 ?
Voici les conditions pour figurer sur le baromètre IPv6 ;
- Coté hébergeur : On publie le top 100 en nom de domaine coté Afnic (on regarde les enregistrement A du nom de domaine racine pour identifier les hébergeurs)
- Coté FAI grand public : Tous les FAI de plus de 5 000 clients
- Coté Pro : Ceux qui ont un chiffre d'affaire sur les marchés de détail à destination de la clientèle entreprise supérieur à 200 millions d'euros
-
Vous avez un peering avec quels opérateurs sur DC2 ? J'aimerais bien passer chez Bouygues mais apparemment ils ne font pas de collecte IPv6 chez moi. Reste Free mais du coup ça marche comment les tunnels >1Gbps ? Genre 1 Tunnel "Bon père de famille" = 1Gbps donc si je veux être un chieur qui tire éventuellement 5Gbps je peux payer 5 Tunnels ? (en en monter qu'un seul)
-
Vous avez un peering avec quels opérateurs sur DC2 ?
Tout est sur la map, ou alors j'ai pas compris la question
Genre 1 Tunnel "Bon père de famille" = 1Gbps donc si je veux être un chieur qui tire éventuellement 5Gbps je peux payer 5 Tunnels ? (en en monter qu'un seul)
Si tu fais 5G constants, ni moi, ni free, ni mes transitaires ne vont être contents, même avec 20 tunnels :)
On a une limite à quelque chose comme 4Gbit/s a cause des mikrotik en coeur de réseau, donc de toute façon, tu n'auras pas le débit max d'une Freebox Delta si c'était ton envie. Après ça marchera quand même bien :)
-
> Tout est sur la map, ou alors j'ai pas compris la question
Sur la WeatherMap je peux voir que vous peerez avec FranceIX et donc tous les membres open, mais je ne peux pas savoir pour les membres Selective (i.e SFR: non, ça je sais, Orange: je me doute que ca doit etre non aussi, sans payer)
> On a une limite à quelque chose comme 4Gbit/s a cause des mikrotik en coeur de réseau, donc de toute façon, tu n'auras pas le débit max d'une Freebox Delta si c'était ton envie. Après ça marchera quand même bien
Je n'ai même pas besoin de 4gbps ou 3, ou 2. Mais sans rate limiter je "peux" donc pour savoir comment ça marche :)
-
Sur la WeatherMap je peux voir que vous peerez avec FranceIX et donc tous les membres open, mais je ne peux pas savoir pour les membres Selective (i.e SFR: non, ça je sais, Orange: je me doute que ca doit etre non aussi, sans payer)
Tu peux voir nos peerings avec un "Whois AS57199", et j'en ai parlé ici aussi
On peer avec SFR à Lyon uniquement (j'arrive pas à avoir le noc pour ajouter une session à Paris)
Bouygues à Paris et Lyon
Orange/Free c'est via nos transits, eux-même via Hopus ou des PNI.
Je n'ai même pas besoin de 4gbps ou 3, ou 2. Mais sans rate limiter je "peux" donc pour savoir comment ça marche :)
Qu'est-ce que tu cherches à faire, en fait ?
PS : Tu peux utiliser les fonctions "citer" stp ? C'est infernal a lire sinon :)
-
IPv6 est à peine abordé en DUT RT parce que cela ne sert à rien d'après les industriels.
Perso, tout ce que j'ai appris en DUT RT il y a 2-3 ans portait sur l'IPv4 et sur l'IPv6 (on a fait autant l'un que l'autre). Je suis chaud en IPv6 justement grâce à ça.
Après je n'ai pas en tête la gestion des programmes d'enseignement, si c'est national ou si chaque IUT a une marge de manoeuvre.
Je rejoins Hugues sur le sujet : aujourd'hui si on veut de l'IPv6 on peut en avoir, si c'est vraiment un besoin. Et au pire, on fait un tunnel. Et au pire, si on peut vraiment pas se permettre de juste avoir de l'IPv6 sur une VM, on paye une IPv4 publique.
Forcément pour des services en prod dédiées "au monde entier", faut du dual stack. Mais pour de la bidouille perso, c'est pas forcément une nécessité.
-
Perso, tout ce que j'ai appris en DUT RT il y a 2-3 ans portait sur l'IPv4 et sur l'IPv6 (on a fait autant l'un que l'autre). Je suis chaud en IPv6 justement grâce à ça.
Après je n'ai pas en tête la gestion des programmes d'enseignement, si c'est national ou si chaque IUT a une marge de manoeuvre.
Je rejoins Hugues sur le sujet : aujourd'hui si on veut de l'IPv6 on peut en avoir, si c'est vraiment un besoin. Et au pire, on fait un tunnel. Et au pire, si on peut vraiment pas se permettre de juste avoir de l'IPv6 sur une VM, on paye une IPv4 publique.
Forcément pour des services en prod dédiées "au monde entier", faut du dual stack. Mais pour de la bidouille perso, c'est pas forcément une nécessité.
J'ai un tunnel GRE pour l'IPv6 chez Milkywan et je suis très satisfait. Parce que mon FAI, K-net, ne me fournit pas une adresse ipv6. Bon, ce ne serait pas la responsabilité de K-net mais plutôt de l'OI Manche Fibre mais, à la fin, c'est le client final qui trinque.
En vrai, je n'ai pas besoin d'avoir ipv6, tous les sites et services auxquels j'accède ont une adresse ipv4. Mais je préfère commencer dès maintenant à monter en compétences là dessus parce que le jour ou ce sera vraiment indispensable je veux être prêt. On entend régulièrement dans les forums que l'ipv6 n'est pas nécessaire à l'heure actuelle et que je suis trop exigent mais on est en 2021, la spécification ipv6 existe depuis les années 90 et on sait qu'on en aura forcément besoin. Je trouve incroyable que les fournisseurs d'accès et les opérateurs d'infrastructure soient toujours incapables de fournir un accès en ipv6 digne de ce nom.
Heureusement qu'il y a Milkywan ;D
-
On peer avec SFR à Lyon uniquement (j'arrive pas à avoir le noc pour ajouter une session à Paris)
Bouygues à Paris et Lyon
En tout cas, en v4, pour moi, c'est amplement suffisant :)
$ mtr -4zrbwc1 80.67.167.77
Start: 2021-02-19T17:32:11+0100
HOST: od Loss% Snt Last Avg Best Wrst StDev
1. AS??? KAZ (172.16.17.1) 0.0% 1 1.4 1.4 1.4 1.4 0.0
2. AS15557 69gui1-nro-1.nro.gaoland.net (93.17.136.11) 0.0% 1 1.8 1.8 1.8 1.8 0.0
3. AS15557 113.10.3.109.rev.sfr.net (109.3.10.113) 0.0% 1 2.3 2.3 2.3 2.3 0.0
4. AS15557 161.244.5.109.rev.sfr.net (109.5.244.161) 0.0% 1 4.3 4.3 4.3 4.3 0.0
5. AS??? milkywan-l2.peers.lyonix.net (77.95.71.132) 0.0% 1 1.9 1.9 1.9 1.9 0.0
6. AS20766 lafibre.info (80.67.167.77) 0.0% 1 3.4 3.4 3.4 3.4 0.0
Pour les autres users, si tu as un nom à secouer ...
-
En même temps du Lyon -> Lyon entièrement par le réseau SFR j'espère bien que ça marche bien ;D
-
En même temps du Lyon -> Lyon entièrement par le réseau SFR j'espère bien que ça marche bien ;D
Lafibre.info passe par Milkywan ;) (le saut n° 5)
-
Petite question : est ce qu'on sait ce qu'il s'est passé sur le RB4011 de Vénissieux SFR ? J'imagine qu'il a planté et ne démarre pas et qu'il faut le redémarrer physiquement avec quelqu'un sur place ? A moins qu'il n'est grillé ? On a une petite idée s'il va être remplacé ?
PS : question n'ayant pas pour objectif de mettre la pression, juste à titre informatif
-
Aucune idée, il n'est pas reparti après une MAJ. Il faut que j'aille voir, je devais y aller ce week-end, mais mon accès permanent-temporaire (une spécificité SFR) a expiré il y'a 4 jours, et j'avais pas fait gaffe :)
J'y retourne quand je peux !
-
Accès "permanent-temporaire", sont très fort chez SFR ;D
-
Bon, deuxième fois que je vais au Netcenter de Venissieux pour rien à cause de leur politique d'accès pourrie, le RB4011 de Venissieux attendra encore quelques semaines...
-
J'espère que t'as pas fait l'aller-retour depuis Paris juste pour ça...
Leon.
-
Non heureusement, je suis aussi allé dans notre POP d'HosTELyon pour urbaniser un peu la baie et configurer tous les accès à distance (PDU commandés, réseau d'out of band et management ILO) :
(https://pix.milkywan.fr/nzMOf6pB.jpeg)
(https://pix.milkywan.fr/YtiJ9wya.jpeg)
-
Bon, deuxième fois que je vais au Netcenter de Venissieux pour rien à cause de leur politique d'accès pourrie, le RB4011 de Venissieux attendra encore quelques semaines...
Habitant pas très loin du NetCenter, j'y serais bien allé pour redémarrer le Mikrotik mais je suis pas sur qu'en sonnant et en se présentant gentillement ils m'ouvrent ::)
-
question rapide:
En ipv6, pourquoi le réseau de Milkywan me route depuis TH2 vers VNX pour sortir vers Appliwave?
C'est lié aux routes annoncées par Appliwave à TH2 / VNX qui ne sont pas forcément les mêmes? J'essaie de m'intéresser au fonctionnement du routage internet en général et monter en compétences là dessus. ;)
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 2a0e:xxxx:xxxx:1000::1 - 0 | 293 | 293 | 0 | 0 | 0 | 0 |
|gre5.rb4011.col.d2s.infra.ip6.milkywan.xyz - 3 | 265 | 258 | 17 | 19 | 85 | 18 |
|po1.81.ces2024.core.d2s.bb.ip6.milkywan.net - 4 | 257 | 248 | 17 | 19 | 86 | 18 |
|tfe2.150.ccr2004.edge.th2.bb.ip6.milkywan.net - 5 | 249 | 238 | 17 | 20 | 88 | 19 |
|tfe1.2984.ccr2004.edge.vnx.bb.ip6.milkywan.net - 3 | 269 | 263 | 23 | 26 | 93 | 25 |
| 2a05:46c1:0:1000::1 - 4 | 257 | 248 | 23 | 26 | 96 | 25 |
|ham-ic-r-bkb-1.germany.infra.as200780.net - 4 | 261 | 253 | 33 | 36 | 105 | 35 |
| 2001:7f8:bd::5:4113:1 - 6 | 241 | 228 | 33 | 36 | 106 | 35 |
| 2a04:4e42:3::645 - 4 | 257 | 248 | 33 | 36 | 105 | 35 |
|________________________________________________|______|______|______|______|______|______|
-
Je cherche, mais en tout cas la route préférée depuis Paris est bien celle de Lyon, en effet :)
[hugues@ccr2004.edge.th2] > /ipv6 route print where dst-address=2a04:4e42:3::/48
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
# DST-ADDRESS GATEWAY DISTANCE
0 ADb 2a04:4e42:3::/48 2a0b:cbc0:2::3 200
1 Db 2a04:4e42:3::/48 2a05:46c0:100:1000::1 20
2 Db 2a04:4e42:3::/48 fe80::8eb6:4fff:fee8:... 20
3 Db 2a04:4e42:3::/48 fe80::827f:f802:9a6a:... 20
-
C'est corrigé, il manquait le filtre qui régissait la med sur Venissieux :)
-
C'est corrigé, il manquait le filtre qui régissait la med sur Venissieux :)
je confirme!
merci Hugues :D
-
Ça va faire plaisir à Vivien et Cédric, j'ai activé (en beta pour le moment) NAT64 sur toute l'infra de MilkyWan, c'est incroyablement simple :o
➜ ~ host twitter.com
twitter.com has address 104.244.42.1
twitter.com has address 104.244.42.65
twitter.com has IPv6 address 64:ff9b::68f4:2a01
twitter.com has IPv6 address 64:ff9b::68f4:2a41
➜ ~ mtr twitter.com -6rwc1
Start: 2021-04-12T16:53:25+0200
HOST: Atlantis.local Loss% Snt Last Avg Best Wrst StDev
1. AS57199 gw.vpn.licorne.tech 0.0% 1 16.1 16.1 16.1 16.1 0.0
2. AS??? ?? ? 100.0 1 0.0 0.0 0.0 0.0 0.0
3. AS57199 tfe1.2297.ccr2004.core.th2.bb.ip6.milkywan.net 0.0% 1 17.8 17.8 17.8 17.8 0.0
4. AS57199 te1.ces2024.core.cbo.bb.ip6.milkywan.net 0.0% 1 16.2 16.2 16.2 16.2 0.0
5. AS57199 nat64-in.milkywan.net 0.0% 1 18.9 18.9 18.9 18.9 0.0
6. AS57199 nat64-out.milkywan.net 0.0% 1 17.6 17.6 17.6 17.6 0.0
7. AS??? 64:ff9b::5043:a740 0.0% 1 17.1 17.1 17.1 17.1 0.0
8. AS??? ?? ? 100.0 1 0.0 0.0 0.0 0.0 0.0
9. AS??? 64:ff9b::5043:a785 0.0% 1 37.0 37.0 37.0 37.0 0.0
10. AS??? ?? ? 100.0 1 0.0 0.0 0.0 0.0 0.0
11. AS??? ?? ? 100.0 1 0.0 0.0 0.0 0.0 0.0
12. AS??? 64:ff9b::68f4:2a41 0.0% 1 25.4 25.4 25.4 25.4 0.0
-
Oh oh oh ! Très intéressé par les retours !
Bon je doute que je puisse faire pareil si c'est uniquement du web. Maissss intéressé quand même ;D
-
Comment ça web uniquement ? C'est du NAT64 donc ça marche pour TCP/UDP et assimilés, c'est un snat classique derrière :D
-
Comment ça web uniquement ? C'est du NAT64 donc ça marche pour TCP/UDP et assimilés, c'est un snat classique derrière :D
(https://pix.milkywan.fr/fGkaveC2.gif)
-
Ça va faire plaisir à Vivien et Cédric, j'ai activé (en beta pour le moment) NAT64 sur toute l'infra de MilkyWan, c'est incroyablement simple :o
Tayga ?
-
On ne peut rien te cacher 😋
-
La problématique pour pouvoir faire du NAT64/DNS64 pour les clients d'Optix, c'est que le 464XLAT est nécessaire pour éviter les régressions pour ceux qui utilisent des IPv4 littérales (plusieurs applications de domotique par exemple) ou un DNS tiers (certaines consoles par exemple), le DNS tiers étant bien évidement interrogé en IPv4 et donc sans 464XLAT rien ne fonctionne vu qu'il n'y a pas de résolution DNS.
Windows 10 supporte le 464XLAT, mais uniquement pour des connexion WLAN, c'est bien dommage, cela serait utile dans des entreprises qui abandonnent IPv4 sur certains LAN mais qui ont encore des ressources interne qui utilisent des IPv4 littérales.
Une autre solution serait que la box le supporte, c'est proposé par certains routeurs 4G
-
Du coup, la collecte L2TP est en prod :)
https://lafibre.info/milkywan/ftth-milkywan/ (https://lafibre.info/milkywan/ftth-milkywan/)
Et on a déjà commencé à expérimenter des trucs sympa avec benoitc (https://lafibre.info/profile/benoitc), genre Nominal FTTH MilkyWan + Backup FTTH Orange via tunnel L2TP, le tout via BGP pour faire de l'actif actif :)
-
Hello !
Petite mise à jour de ce post, 1 an après ! Les anciennes versions de ce post sont disponibles ici : https://lafibre.info/milkywan/archive-milkywan-as57199
MilkyWan est un opérateur associatif que j’ai fondé en 2015, c’était, pendant quelques années mon terrain de jeu personnel. Au fil du temps, j’ai commencé à ramener du monde autour du projet et à faire grandir l’infrastructure, de quelques routeurs dans ma chambre, on est passés à des serveurs dédiés chez Online, des VM chez Hivane ou K-Net à un vrai réseau national indépendant.
(https://lafibre.info/images/associatif/logo_milkywan_big.png)
1/ Infrastructure
MilkyWan est un réseau associatif expérimental qui fête ses 5 ans cette année, qui a commencé avec des routeurs Linux et des ERL montés en tunnel un peu partout, et qui évolue maintenant vers une infra en propre.
Je ne vais pas parler de l'ancienne infra ici, c'était en gros basé sur : des dédiés Online, GRE,FRR,BGP,et un peu d'L2TP.
En Février 2018, nous avons décidé de passer à l’étape supérieure en devenant un “vrai” opérateur, en exploitant notre propre infrastructure système et réseau, de la bordure aux routeurs de collecte, en passant par les serveurs et les NAS.
Nous avons d'abord commencé avec des routeurs de la marque Mikrotik, gamme CCR et RB, nous sommes progressivement en train de décomissionner ces derniers pour passer sur du matos plus "opérateur" : Cisco, Brocade, Arista, etc
En 2021, MilkyWan s’étend sur de 9 points de présence, sur toute la France.
1.a/ Côté Matos :
L'infra réseau est grosso modo séparée en 3 parties :
- L'infra de backbone (appelée Edge)
- L'infra datacenter (appelée Core)
- L'infra de collecte (Appelée Col)
Coté Edge, nous exploitons pour l'instant uniquement des routeurs Mikrotik :
Dans la gamme, nous exploitons :
- Trois CCR2004 : Sur les sites centraux (TH2, DC2, VNX), ce sont les routeurs les plus rapides de la gamme en convergence
- Un CCR1036 : à Lille, où il ne fait que récupérer LillIX et le renvoyer à Paris
- Un CCR1009 : Dans leur version 1x10G. Ce sont les routeurs avec lesquels on a commencé, et que nous déprovisionnons aujourd’hui, il n'en reste plus qu'un, à Rennes, qui récupère Breizh-IX et fournit un peu de connectivité aux copains :)
Coté Core, on exploite pour l'instant uniquement du Cisco et du Brocade, c'est amené à évoluer. Nous avons :
- Deux Brocade CES2024 : Des routeurs 4x10G + 24x1G SFP, ils servent comme gateway de tout le matériel présent dans nos POP système, ils routent en hardware, bref, c'est un bonheur
- Un Cisco ME3600X : Même usage que les CES2024, mais version Cisco, à Lyon. 2x10G + 24x1G
- Deux Cisco Catalyst 4500X : Des puissants routeurs équivalents en features aux deux routeurs du dessus, mais que nous n'exploitons qu'en switching dans nos POP système, pour relier des serveurs à un routeur d'agreg
- Un Dell N4032 : Un simple switch 24x10G + 2x40G, il relie des serveurs à un routeur d'agreg
Bref, une infra assez simple mais qui marche incroyablement bien :)
En dehors de Mikrotik, nous avons aussi divers équipements :
- FS S5850 : Un gros switch 4x100G, 2x40G et 48x10G, idéal en coeur de réseau sur les gros sites
- Brocade GS648p : Pour les sites avec des ports Cuivre, il permet de les agréger vers ses 2x10G vers un plus gros switch
- Cisco 7301 : Un petit routeur avec seulement 4x1G, il sert de LNS pour les clients ADSL et d’endpoint pour quelques tunnels
- Divers serveurs dont je vous passerais la config, mais avec plus de 100Go de RAM à chaque fois :)
Coté Collecte, nous exploitons deux matériels :
- Cisco ASR1002 : Pour les collectes L2TP / PPPoE, c'est de la bombe, mais il n'a pas de 10G, il faudrait qu'on achète une MPA 10G à l'occasion :)
- Des Mikrotik RB4011 : Des super petits routeurs de collecte, on fait terminer les tunnels L2TP/GRE/IPIP dessus, ça tient super bien la charge et ça fait du 10G
Nous sommes présents dans de nombreux DC, par ordre d’apparition :
- Scaleway DC2 (Vitry, sud de Paris) :
- SFR Venissieux (Venissieux, Sud de Lyon)
- Telehouse 2 (Paris 11)
- Cogent Rennes
- CIV Lille
- DC2Scale Velizy
- Appliwave CBO (Croissy-Beaubourg)
- HosTELyon
Plus de détails et de photos de nos POP ici : https://lafibre.info/milkywan/milkywan-photos-des-pop/
1.b/ Côté Ressources IP :
En IP Legacy, nous avons un /22 alloué par le RIPE : 45.13.104.0/22 et un /24 alloué par Gitoyen : 80.67.167.0/24
Le premier est utilisé pour l'infra, le second pour les clients :)
En IPv6, nous avons un /32 alloué par AppliWave : 2a0b:cbc0::/32 et un /29 alloué par le RIPE : 2a0e:e700::/29
Même principe qu'en v4, le /32 sert surtout à l'infra (et aux premiers clients), le /29 sert aux clients uniquement
Et évidemment, l’AS57199, un AS 16 Bits puisqu’il n’est pas possible de faire de la commu étendue sur un AS32b avec Mikrotik. Et c’est quand même plus classe d’avoir un AS 16b, il faut le dire :)
1.c/ : Coté Interconnexions.
Je pense qu’on peut affirmer sans trop se mouiller que nous sommes l’opérateur associatif le mieux interconnecté de France :-)
Coté Transit, nous avons :
- 75Gbit/s de transit AppliWave (AS200780), sur DC2, TH2 et Vénissieux (Régional), en 25G à chaque fois
- 10Gbit/s de transit partiel Hivane Network (AS34019), qui nous partage ses nombreux peerings
- 10Gbit/s de transit protégé Acorus (AS35280) avec l'anti-DDoS qui va bien :D
- 40Gbit/s de transit FiberWay (AS49434) (parce que pourquoi pas ?)
Coté Peering, nous avons :
- 10G sur le LyonIX à Venissieux, avec comme remote peering activé : TopIX, TouIX, SwissIX, CIXP, NetIX, LoNAP, AuvernIX, GrenoblIX, EuroGIX
- 10G sur LyonIX à TH2
- 10G sur FranceIX Paris à DC2, avec comme remote peering FranceIX Marseille.
- 10G sur le LillIX, à Lille, on peer notamment avec OVH et Ielo-Liazo là bas.
- 10G sur le Breizh-IX à Rennes, IXP dont je suis membre du bureau, et qui sent bon le kouign amann :)
Ce qui nous donne un total de 185Gbit/s de capacité vers internet. Une capacité honorable :-)
D’ailleurs, on est régulièrement dans le top HE France sur le nombre de peers IPv4/v6 <3
1.d/ Le reste :
Nous sommes déclarés à l’ARCEP (code MILK), membres de la Task Force IPv6 (enfin moi), et membres d’aucune association d’opérateurs associatifs, vu que la principale ne correspond pas à notre vision et qu'il n'y en a pas d'autres (mais on bosse quand même avec plaisir avec tous les autres FAI Associatifs ! :-)
2/ Le setup :
Nous exploitons donc un backbone assez varié, avec du 10G et du 25G. Il est pur IP (pas de MPLS, de SR ou autre), Il est drivé par un control plane doté d’une part d’ OSPF en IPv4 et… des routes statiques en IPv6. En effet, l’implémentation de MikroTik d’OSPFv3 étant complètement cassée au niveau des routes récursives et rend le machin impossible à utiliser avec iBGP. OSPFv3 est néanmoins installé et fonctionnel, il sert à l'interco avec les Brocade, Cisco et autres matériels qui fonctionnent correctement. Et d’autre part iBGP, avec les 3 CCR2004 comme RR. Nous n'apprenons plus la fullview, les CCR sont trop peu réactifs avec. Mais quand les 3 CCR2004 auront dégagé des POP centraux, on remettra la full !
Tout ce backbone est relié par des Lan2Lan en 10/25G, des Waves en 10G (sauf Rennes, en 1G), fournis par AppliWave, Rezopole ou Quantic Telecom (merci à eux !)
On essaie d’avoir un backbone le plus redondant possible, mais c’est parfois un peu compliqué, nous faisons donc confiance à la fiabilité de celui de nos sponsors (et on n’a que très rarement eu de coupures).
La démarche en ce moment est de faire en sorte de passer en Wave tout ce qui peut l'être, pour réduire notre dependance à des équipements actifs.
On relie aussi les serveurs, NAS, et les routeurs de collecte en n*10G (quand ils en sont capables) ou en N*1G.
On a de la MTU9k partout, ce qui permet de proposer des tunnels L2 avec une MTU 9k entre tous nos PoP, et aussi simplement qu’avec du MPLS, grâce à EoIP.
Voici la Weathermap du réseau, accessible à cette URL en IPv6 Only : https://weathermap.milkywan.fr/milkywan.html
(https://pix.milkywan.fr/EHXfz4N1.png)
Historiquement on faisait de l’eBGP avec des AS Privés, chaque routeur de collecte ayant un AS, ce qui permet de bénéficier de la qualité du filtrage de BGP
Maintenant nous faisons de l'OSPF jusqu'aux routeurs de collecte et de l'iBGP, ça marche très bien aussi et ça évite d'avoir 15 AS à gérer
Les clients Tunnel ayant demandé une redondance sont également livrés en eBGP avec AS privé, c’est plus simple à gérer, encore une fois :)
3/ L’équipe
Nous sommes actuellement 8 dans l’asso :
- Thibault, développeur et trésorier
- Corentin, Admin Sys
- Guilhem, Responsable Communication et DA
- Alexis, Responsable Support et Delivery
- Jack, Admin système et réseaux
- Maël, Admin système
- Nicolas, Admin système et réseaux
- Moi, Admin Réseau, Sys et Président
4/ Les services
On propose tout ce qu’un “vrai” opérateur peut vous proposer, à peu de choses près.
Pour résumer, on a deux catégories de produits :
4.b/ Pour les particuliers :
- FTTH : Collecte nationale, collectes régionales sur certains réseaux, allez voir le topic dédié : https://lafibre.info/milkywan/ftth-milkywan/
- xDSL : Pareil qu'au dessus, même topic :)
- Tunnels IP : Un simple tunnel (ou VPN) depuis le réseau de MilkyWan. On peut même faire de la redondance avec BGP :)
- Machines virtuelles : On propose plein de VM, je ne vais pas tout détailler ici, mais le point important, c’est que le réseau n’est pas bridé !
4.a/ : Les services Opérateurs
On propose tout un tas de services à destination des opérateurs, dans le lot :
- Transit IP BGP : Le plus connu, on propose du transit, avec un commit démarrant à 7,5Mbit/s jusqu’à 1Gbit/s (voir plus, mais vous n’avez plus besoin de nous, je pense :)), sachant que notre réseau est plutôt très développés (parmi les meilleurs de France selon PeeringDB)
- Lan2Lan : On vous transporte en 100M/1G ou plus, entre tous nos PoP !
- Housing : On vous héberge, à DC2Scale, Appliwave CBO ou Lyon HosTELyon. Et on a des partenariats pour les autres DC, au besoin :)
- Gros blocs IP : Si vous êtes un opérateur qui débute, on peut vous router un bloc d’IP (jusqu’à /25), avec une facturation progressive.
- FTTO : On sait livrer de la FTTO un peu partout en France pour vous livrer tout ce qui est au dessus.
Bref, on reste sur du classique, mais efficace, et avec un excellent réseau :)
4.c / Les services Web :
Principalement des services qu’on utilise en interne, et qu’on ouvre au plus grand nombre :
- Pix (https://pix.milkywan.fr/): Un service d’hébergement d’images
- Hastebin (https://hastebin.milkywan.fr/) : Un service de pastebin plutôt joli
- Pad (https://pad.milkywan.fr/) : Un service de pad collaboratif assez efficace.
Conclusion :
Bref, voilà un petit post sur ce qu’on fait, on est plutôt content du chemin parcouru depuis 2015, et on espère que les 5 prochaines années seront encore plus fructueuses, lancer le FTTH et l'xDSL est pour moi une vraie consécration et je me demande jusqu'où ça nous mênera :)
Si vous voulez voir nos nouvelles, on est sur Twitter (@MilkyWan_net), sur IRC (#milkywan sur freenode, n'hésitez pas à rejoindre #lafibre aussi, on se marre bien :) ).
Le site web est ici : https://milkywan.fr/ (https://milkywan.fr/)
On est sur PeeringDB et je maintiens les objets RIPE à jour :)
Je vous laisse sur quelques photos de l’infra :)
TH2
(https://pix.milkywan.fr/eEHhSF4C.jpg)
DC2
(https://pix.milkywan.fr/90DnUnkP.jpg)
1G !
(https://pix.milkywan.fr/tEgJqelb.JPG)
DC2Scale
(https://pix.milkywan.fr/mboSVGXD.jpg)
CBO
(https://pix.milkywan.fr/LmmqzlEL.jpg)
HosTELyon
(https://pix.milkywan.fr/tRODptxP.jpg)
-
Bravo pour le travail accompli, vous avez de quoi être fier :)
En tant que client, je regrette un peu de ne pas voir la fullview, mais vous n'êtes pas mon seul transitaire donc il n'y a pas mort d'homme ;)
En effet, l’implémentation de MikroTik d’OSPFv3 étant complètement cassée au niveau des routes récursives et rend le machin impossible à utiliser avec iBGP. OSPFv3 est néanmoins installé et fonctionnel, il sert à l'interco avec les Brocade, Cisco et autres matériels qui fonctionnent correctement.
J'en ai fait les frais récemment, et c'est un peu triste. Mais je n'ai clairement pas les moyens de remplacer mon CCR1072 par un équivalent Cisco, alors qu'il arrive à tenir 2 717 167 routes IPv4 et 701 802 routes IPv6 (mais il ne faut pas être pressé pour la convergence ;D )
3/ L’équipe
Nous sommes actuellement 7 dans l’asso :
- Thibault, développeur et trésorier
- Corentin, Admin Sys
- Guilhem, Responsable Communication et DA
- Alexis, Responsable Support et Delivery
- Jack, Admin système et réseaux
- Maël, Admin système
- Nicolas, Admin système et réseaux
- Moi, Admin Réseau, Sys et Président
Par contre, ça fait 8 membres ça ;)
-
Corrigé :P
Pour la full, c'est dans les tuyaux de virer les CCR2004, il nous faut juste un peu de sous, mais ça sera très clairement la prochaine folie :)
-
Corrigé :P
Merci, mais il faut mettre à jour la page 1 aussi ;)
Pour la full, c'est dans les tuyaux de virer les CCR2004, il nous faut juste un peu de sous, mais ça sera très clairement la prochaine folie :)
+1
-
Oula, je suis fatigué... merci :D
-
Le jour ou vous virez les CCR2004 et RB4011 je vous en prends un de chaque ;)
-
Quelle aventure, c'est juste dingue.
Un opérateur associatif avec un vrai réseau WAN, présent sur 8 POPs (pas juste TH2 comme beaucoup), avec des liens backbone de 10Gb/s, c'est assez impressionnant.
Un MAN parisien 100% allumé par vos propres moyens, avec des lambda de 10 ou 25Gb/s, ça serait encore plus dingue.
Si on t'avait dit il y a 5 ans que MilkyWan en serait là aujourd'hui, tu y aurais cru?
Nous exploitons donc un backbone assez varié, avec du 10G et du 25G. Il est pur IP (pas de MPLS, de SR ou autre), Il est drivé par un control plane doté d’une part d’ OSPF en IPv4 et… des routes statiques en IPv6. En effet, l’implémentation de MikroTik d’OSPFv3 étant complètement cassée au niveau des routes récursives et rend le machin impossible à utiliser avec iBGP. OSPFv3 est néanmoins installé et fonctionnel, il sert à l'interco avec les Brocade, Cisco et autres matériels qui fonctionnent correctement. Et d’autre part iBGP, avec les 3 CCR2004 comme RR. Nous n'apprenons plus la fullview, les CCR sont trop peu réactifs avec. Mais quand les 3 CCR2004 auront dégagé des POP centraux, on remettra la full !
Par rapport à ça, j'avoue mon ignorance technique pour pouvoir comprendre le truc.
Les CCR2004 bouffent des liens de transit depuis vos fournisseurs de transit, donc full view, non? Comment est-il possible de "ne pas leur faire apprendre" dans ces conditions ?
Pour la partie Full-View, ils balance juste les info de routage au routeur suivant, sans s'en servir eux mêmes? Un peu comme le ferait un "route reflector"?
Du coup, pour les IP destination que les CCR2004 n'ont pas dans leur table de routage, les CCR2004 ont une route par défaut vers un routeur interne plus "capable" (un Cisco)?
Ou alors c'est encore plus simple, et pour chaque routeur tu mets simplement une "route par défaut" vers un de tes transitaire fiable?
Leon.
-
Un MAN parisien 100% allumé par vos propres moyens, avec des lambda de 10 ou 25Gb/s, ça serait encore plus dingue.
C'est clair :D
On est en train de progressivement bosser sur le sujet, en commençant par les liaisons les plus longues pour voir ce qu'on peut faire :)
Petit teasing : on va faire pareil sur le MAN à Lyon, et avec de la diversité, s'il vous plait !
Si on t'avait dit il y a 5 ans que MilkyWan en serait là aujourd'hui, tu y aurais cru?
Non, clairement pas. On a aussi eu beaucoup de chance de tomber sur Julien d'Appliwave qui a tout de suite cru au projet et nous a plus ou moins fait openbar sur son réseau, ce qui nous a permis de développer rapidement la première mouture du réseau, qui a permis de construire tout le reste :)
Ou alors c'est encore plus simple, et pour chaque routeur tu mets simplement une "route par défaut" vers un de tes transitaire fiable?
C'est quasiment ça, mais en un peu plus élaboré :
- Sur les 3 POP Edge, on prend la default de chacun de nos transitaires (en v4, en v6 c'est fullview)
- AppliWave est privilégié parce qu'il fallait bien définir arbitrairement quelque chose et qu'on a beaucoup de commit chez eux
- J'apprends cependant les routes de certains AS (par exemple Orange, Free) depuis certains transits, pour faire un peu de trafic engineering et sortir par des endroits parfois plus pertinents (Par exemple, sortir Orange depuis le transit OTI de FiberWay et pas par Hopus)
À noter qu'on apprend toutes les routes de tous nos IXP, à l'exception d'HE que j'ai dégagé parce que leurs routes sont trop mauvaises.
Pour te donner une idée, voilà en gros le filtre qu'on a en entrée d'AppliWave à TH2, par exemple :
(https://pix.milkywan.fr/kMLMQDK1.png)
- Free/Orange sont appris avec une localpref de 120 (pour forcer le trafic par là, même si pour Orange ça passe ailleurs, j'ai du mettre plus, je regarderai)
- Les routes originées par AppliWave sont apprises avec une localpref de 400 (identiques à un peering), pour éviter de joindre AppliWave par un IXP
- La route par défaut est apprise avec la localpref la plus basse, 100
-
Et du coup, pourquoi on apprend plus la fullview sur les CCR2004 :
Autant pour converger, c'est super rapide, tu peux bouffer 4 full en 30 secondes, voir moins.
Par contre, pour supprimer les routes, c'est une autre affaire, ça peut prendre jusqu'à 1h dans certains cas (gros flap avec suppression / reconvergence / insertion / reconvergence), et le temps est exponentiel. Là on a 100k routes, ça prend généralement moins de 10s, dans le pire des cas, 2 minutes.
Bref, avoir un réseau qui marche bien quand tout va bien, mais qui ne marche pas quand tout ne va pas bien, ça n'a strictement aucun intérêt, donc autant sacrifier la full, ce qui n'émeut que les clients transit ipv4, qui sont une minorité de nos abonnés.
Pour plus d'infos sur les temps de convergence BGP, mes tests ici sont je pense édifiants : https://forum.mikrotik.com/viewtopic.php?t=161044
-
Que de chemin parcouru ! Franchement chapeau :)
C'est là aussi que je me rends compte que mes compétences en réseau sont ridicules à côté (même en apprenant de nouveaux trucs presque tous les jours).
Et ces photos... je bave littéralement devant ;D
-
Salut.
En regardant les caractéristiques des VM sur le site, je lis
VM SSD
[...]
VM SSD NVMe envisageable si demandes suffisantes
Est-ce qu'il faut comprendre qu'actuellement, vos SSD sont en SATA?
Pourquoi ne pas passer directement en NVMe?
Sur des hosts avec des dizaines de VM, le NVMe apporte quand même un gros plus, non?
C'est parce que c'est trop cher? Plus compliqué de faire du hot-swap en NVMe?
Leon.
-
Est-ce qu'il faut comprendre qu'actuellement, vos SSD sont en SATA?
Oui
C'est parce que c'est trop cher? Plus compliqué de faire du hot-swap en NVMe?
Voilà, pour ces deux raisons. Le nvme hot swap existe, mais il faudrait changer au minimum de carte RAID sur les serveurs.
Et franchement, je trouve que les SSD SATA suffisent largement a nos usages :)
-
C'est plutôt récents les SSD NVMe pour les serveurs.
Il y a 4 ans chez Dell, pour un PowerEdge R330, on avait le choix entre SSD SATA et SSD SAS plus haut de gamme (pas testé, c'était le double de prix).
-
(https://pic.laniakea.ovh/hUtE2/RepUTObU44.png/raw)
Source (https://media.frnog.org/FRnOG_26/FRnOG_26-3.pdf)
-
J'ai été voir chez Dell en 2021, pour un PowerEdge R340, un serveur mono socket Intel 1u populaire : Pas de SSD NVMe
Il est proposé en SSD :
SAS SSD
- 4 015,00 € 3.84TB SSD vSAS Mixed Use 12Gbps 512e 2.5in w/3.5in HYB CARR Hot-Plug AG Drive, 3 DWPD
- 2 047,00 € 1.92TB SSD vSAS Mixed Use 12Gbps 512e 2.5in with 3.5in HYB CARR Hot-Plug AG drive,3 DWPD
- 1 067,00 € 960GB SSD vSAS Mixed Use 12Gbps 512e 2.5in with 3.5in HYB CARR Hot-Plug AG drive,3 DWPD
- 5 798,00 € 7.68TB SSD vSAS Read Intensive 12Gbps 512e 2.5in with 3.5in HYB CARR Hot-Plug AG Drive, 1 DWPD
- 753,00 € 960GB SSD vSAS Read Intensive 12Gbps 512e 2.5in with 3.5in HYB CARR Hot-Plug AG drive, 1 DWPD
SATA SSD
- 2 204,00 € 3.84TB SSD SATA Read Intensive 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 1 DWPD,
- 1 634,00 € 1.92TB SSD SATA Mix Use 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 3 DWPD,
- 1 264,00 € 1.92TB SSD SATA Read Intensive 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 1 DWPD,
- 864,00 € 960GB SSD SATA Mix Use 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 3 DWPD,
- 678,00 € 960GB SSD SATA Read Intensive 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 1 DWPD,
- 424,00 € 480GB SSD SATA Mix Use 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 3 DWPD,
- 367,00 € 480GB SSD SATA Read Intensive 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 1 DWPD,
Je trouve cela super cher, les prix sont HT.
Si on part sur de un mono socket AMD 1u, là oui, le NVMe est proposé :
PCIe/NVMe SSD
- 6 690,00 € 7.68TB, Enterprise, NVMe, Read Intensive, U2, G4, P5500 with carrier
- 6 655,00 € 7.68TB Enterprise NVMe Read Intensive AG Drive U.2 Gen4 with carrier
- 6 156,00 € 6.4TB, NVMe, Mixed Use Express Flash, 2.5 SFF Drive, U.2, G3, P4610 with Carrier
- 6 023,00 € 750GB, NVMe, Ultra Performance Express Flash, 2.5 SFF Drive, U.2, G3, Optane with Carrier
- 5 389,00 € 6.4TB Enterprise NVMe Mixed Use AG Drive U.2 Gen4 with carrier
- 4 490,00 € 3.84TB, Enterprise, NVMe, Read Intensive, U2, G4, P5500 with carrier
- 4 488,00 € 4TB, NVMe, Read Intensive Express Flash, 2.5 SFF Drive, U.2, G3, P4510 with Carrier
- 4 136,00 € 3.2TB, NVMe, Mixed Use Express Flash, 2.5 SFF Drive, U.2, G3, PM1725b with Carrier
- 3 322,00 € 3.84TB Enterprise NVMe Read Intensive AG Drive U.2 Gen4 with carrier
- 3 322,00 € 3.84TB NVMe, Data Center Read Intensive Express Flash, 2.5in with Carrier SFF U.2, G3, AG Drive
- 3 123,00 € 3.2TB, Enterprise, NVMe, Mixed Use, U2, G4, P5600 with carrier
- 3 123,00 € 3.2TB, NVMe, Mixed Use Express Flash, 2.5 SFF Drive, U.2, G3, P4610 with Carrier
- 3 065,00 € 375GB, NVMe, Ultra Performance Express Flash, 2.5 SFF Drive, U.2, G3, Optane with Carrier
- 2 855,00 € 3.2TB Enterprise NVMe Mixed Use AG Drive U.2 Gen4 with carrier
- 2 022,00 € 1.92TB, Enterprise, NVMe, Read Intensive, U2, G4, P5500 with carrier
- 1 933,00 € 1.6TB, Enterprise, NVMe, Mixed Use, U2, G4, P5600 with carrier
- 1 933,00 € 1.6TB, NVMe, Mixed Use Express Flash, 2.5 SFF Drive, U.2, G3, P4610 with Carrier
- 1 723,00 € 1.92TB Enterprise NVMe Read Intensive AG Drive U.2 Gen4 with carrier
- 1 499,00 € 1.6TB Enterprise NVMe Mixed Use AG Drive U.2 Gen4 with carrier
- 848,00 € 960GB NVMe, Data Center Read Intensive Express Flash, 2.5in with Carrier SFF U.2, G3, AG Drive
Si on compare du "Read Intensive", donc un SSD classique, sous-entendu ou les écritures sont limitées, on a pour 960 Go :
- 848,00 € 960GB NVMe, Data Center Read Intensive Express Flash, 2.5in with Carrier SFF U.2, G3, AG Drive
- 753,00 € 960GB SSD vSAS Read Intensive 12Gbps 512e 2.5in with 3.5in HYB CARR Hot-Plug AG drive, 1 DWPD
- 678,00 € 960GB SSD SATA Read Intensive 6Gbps 512 2.5in Hot-plug AG Drive,3.5in HYB CARR, 1 DWPD,
Le NVMe est plus cher que le SAS et le SATA mais cela reste raisonnable. Par contre je ne comprends pas du tout le prix de 678 € HT pour un SSD SATA de 1 To de base.
J'en profite pour raller sur l'interface de configuration d'un serveur Dell, c'est pas accessible. Des options au début change tout et difficile de mettre la configuration que l'on souhaite.
-
C'est plutôt récents les SSD NVMe pour les serveurs.
Il y a 4 ans chez Dell, pour un PowerEdge R330, on avait le choix entre SSD SATA et SSD SAS plus haut de gamme (pas testé, c'était le double de prix).
Je dirais le contraire. Les NVMe sont d'abord apparus pour les serveurs. Bien avant que les NVMe soient accessibles aux particuliers (format M.2).
C'est bien sur les serveurs qu'il est le plus utile de faire des IOPS à gogo, ce qu'offre les NVMe.
Les NVMe sont d'abord apparus sous forme de simples cartes PCIe, avant que des vrais standards apparaissent (U.2).
Ca fait maintenant plus de 5 ans que ces standards sont répandus côté serveurs.
Mais OK, je comprends les contraintes de MilkyWan, pas de problème.
Leon.
-
2 curiosité sur vos outils infra :
Sur le smokeping de Milkywan le module/partie traceroute/mtr c'est fait maison ou c'est un addon officiel ?
Je le trouve bien pratique
Votre weathermap est basé sur quoi ? php weathermap ? Network Weathermap ?
merci
-
Hello,
Addon maison :)
Php-weathermap
-
Dak merci
En tout cas bien pratique votre routage régionalisé sur Lyon avec les FAI
Bouygues m'a donné l'occasion d'en profiter ce matin ;D
(changement soudain de routage chez eux bof bof) et MilkyWan pas impacté du coup ca passe crème
-
Hugues,
je pense que le trafic de TH2 est à nouveau routé via VNX:
pireserver (dead:beef:dead:beef:8313:3231:8528:ce39) -> google.com 2021-05-28T20:35:36+0200
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. AS??? fd10::1 0.0% 2769 0.2 0.1 0.1 0.4 0.1
2. AS57199 gre5.rb4011.col.d2s.infra.ip6.milkywan.xyz 1.0% 2769 18.8 18.6 16.9 61.5 2.4
3. AS57199 po1.81.ces2024.core.d2s.bb.ip6.milkywan.net 0.8% 2769 18.9 19.6 17.3 137.8 7.3
4. AS57199 tfe2.150.ccr2004.edge.th2.bb.ip6.milkywan.net 0.6% 2769 18.9 19.0 17.4 96.3 3.8
5. AS57199 tfe1.2984.ccr2004.edge.vnx.bb.ip6.milkywan.net 1.0% 2769 25.3 25.4 23.7 77.0 4.0
6. AS??? google.peers.lyonix.net 1.1% 2769 31.6 33.2 30.1 204.8 10.4
7. AS15169 2001:4860:0:1015::11 62.5% 2769 32.4 33.0 30.8 79.4 5.0
8. AS15169 2001:4860::c:4000:ce41 22.1% 2768 41.4 39.4 30.9 90.9 8.0
AS15169 2001:4860::c:4000:d9af
AS15169 2001:4860::8:4000:ce26
AS15169 2001:4860::c:4000:d9ab
9. AS15169 2001:4860::c:4002:365d 44.4% 2768 41.5 43.9 40.0 128.7 8.2
AS15169 2001:4860::c:4000:f873
AS15169 2001:4860::c:4002:365b
AS15169 2001:4860::c:4000:f874
10. AS15169 2001:4860::9:4001:31f1 1.0% 2768 41.2 44.3 39.3 128.9 10.1
11. AS15169 2001:4860:0:11e1::1 67.3% 2768 41.8 42.2 40.0 125.9 5.0
AS15169 2001:4860:0:11df::1
12. AS15169 2001:4860:0:1::500f 1.2% 2768 41.1 40.8 39.1 122.0 4.1
AS15169 2001:4860:0:1::500d
13. AS15169 fra24s07-in-x0e.1e100.net 1.1% 2768 40.9 40.8 39.0 100.6 3.8
-
Non, c'est normal là, on peer a VNX avec Google
-
Non, c'est normal là, on peer a VNX avec Google
ok! ;)
je confirme que sur d'autres destinations, ça sort bien par TH2.
-
Dak merci
En tout cas bien pratique votre routage régionalisé sur Lyon avec les FAI
Bouygues m'a donné l'occasion d'en profiter ce matin ;D
(changement soudain de routage chez eux bof bof) et MilkyWan pas impacté du coup ca passe crème
Incident core, reroutage massif mais temporaire. Pas d’ETA à ma connaissance, je bosse pas dans ce service.
-
Hello,
Petite question/curiosité sur le routage vers Zayo AS8218 depuis Milkywan
Je vois que le traffic sortant de Milkywan (au départ de Lyon du moins) passe par LillIX pour tout ce qui routé vers Zayo as8218
Alors que Milkywan et Zayo sont tous les 2 présents sur LyonIX
Les flux entrant Zayo vers Milkywan Lyon passe par LyonIX d'ailleurs
Pourquoi les flux sortants vers Zayo ne sortent via LyonIX soit au plus près de la source ?
J’imagine qu'il y a une raison ? ou c'est indépendant de votre volonté ?
merci
Un exemple
mtr -z 185.6.208.33
1. AS??? _gateway
2. AS20766 te1.100.ccr2004.edge.vnx.bb.ip4.milkywan.net
3. AS20766 tfe1.2983.ccr2004.edge.th2.bb.ip4.milkywan.net
4. AS20766 te1.2983.ccr1036.edge.lil.bb.ip4.milkywan.net
AS57199 te1.2982.ccr1036.edge.lil.bb.ip4.milkywan.net
5. AS??? zayo.lillix.fr
6. AS8218 xe-2-0-0.ter1.ats.lil.core.as8218.eu
7. AS8218 ae1.ter4.eqx2.par.core.as8218.eu
8. AS8218 ae24.tcr2.th2.par.core.as8218.eu
9. AS8218 83.167.57.178.static.neotelecoms.com
10. AS57468 arcadie.mxtls.azatelecom.com
-
Bonne question, on peer sur LyonIX avec Zayo pourtant... tu peux faire un mail à leur NOC si c'est un problème pour toi :-)
-
En vrai c'est pas gênant simple curiosité ;D
on dirait qu'avant le 18 mai on sortait bien par LyonIX et après LillIX
-
Normal la L2L 10G de Lyon qui reste a 0 entre les équipements sur la weathermap quand ya du traffic tout autour ?
https://pix.milkywan.fr/SLdNSFOo?t
-
C'est réparé :)
Pour ce genre de trucs, c'est mieux de faire un mail par contre :)
-
C'est réparé :)
Pour ce genre de trucs, c'est mieux de faire un mail par contre :)
Tu as préparé trop tôt le 100G de la semaine prochaine ? :D
-
Roh, le mec fait du teasing comme ça :P
La légende raconte qu'on va peut-être un peu augmenter la capa de Lyon... ::)
-
C'est réparé :)
Pour ce genre de trucs, c'est mieux de faire un mail par contre :)
merci :)
ta ptet reçu un mail du forum quand j'ai posté ca revient au même ;D
c'est noté
-
Roh, le mec fait du teasing comme ça :P
La légende raconte qu'on va peut-être un peu augmenter la capa de Lyon... ::)
On a juste parlé de Lyon... :D
-
ta ptet reçu un mail du forum quand j'ai posté ca revient au même ;D
Oui mais tu broadcast a tout le monde ^^
-
On a juste parlé de Lyon... :D
*sifflotte*
-
"Ivre, il crée un FAI associatif avec plusieurs centaines de Gbps de capa." :D
-
Sur Lyon, ça serait amusant de voir un POP "Système" MilkyWan chez NetSyst-DataGarage!
Leon.
-
Ca serait rigolo oui, mais on en a pas vraiment besoin, on a déjà 3 POP système et on est loin de les remplir :)
-
Nouveau sur le réseau, FTTH sur le réseau de Bouygues, après avoir pas mal galéré avec l'offload pourri d'ubiquiti sur les edgerouter voilà le résultat :
(https://pix.milkywan.fr/koO64G1A.jpg)
-
Nouveau sur le réseau, après avoir pas mal galéré avec l'offload pourri d'ubiquiti sur les edgerouter voilà le résultat :
Salut. C'est sympa de nous poster un test de débit, mais peux-tu nous dire ce que tu achète à MilkyWan? Ca serait utile pour comprendre.
Un accès VPN?
Un accès FTTH? Si oui sur quel réseau? SFR? Bouygues? SIEA-LiAin?
Leon.
-
Oui excuse-moi j'ai édité mon message
FTTH sur le réseau de Bouygues
-
Hello !
Pour info, on va bientôt passer nos liens TH2-DC2 et DC2-D2S en Wave 10G (tout en gardant les L2L en backup) :-)
Pour CBO, les premiers tests qu'on a fait sur le chemin DC2-CBO ne sont pas concluants, un peu trop d'atténuation :(
On va tester TH2-CBO dans les prochains jours.
-
Pour CBO, les premiers tests qu'on a fait sur le chemin DC2-CBO ne sont pas concluants, un peu trop d'atténuation :(
Ah, c'est vrai que Croissy-Beaubourg c'est un peu loin de tout malheureusement! Ca augmente les distances...
Sur le trajet DC2-CBO, vous avez envisagé de mettre des optiques 10Gb plus puissants? Le budget ne le permet peut-être pas...
En tout cas, c'est une bonne nouvelle. Avoir un réseau de plus en plus indépendant, c'est une bonne chose.
Je ne pense pas qu'il y ait beaucoup de réseaux associatifs qui allument leurs propres lambda-10G!
Leon.
-
Ah, c'est vrai que Croissy-Beaubourg c'est un peu loin de tout malheureusement! Ca augmente les distances...
Alors CBO est à 20Km de Paris, on est pas à TH3 hein
-
Ça reste la campagne, j'hésite à chausser des pneus cloutés sur ma trottinette quand je viens :P
-
Je ne me souviens plus, faut être vacciné contre la fièvre jaune pour y aller ou pas ?
-
Ça reste la campagne, j'hésite à chausser des pneus cloutés sur ma trottinette quand je viens :P
tu as déjà vu la campagne avec autant de fibre ? :)
-
Je ne me souviens plus, faut être vacciné contre la fièvre jaune pour y aller ou pas ?
Seulement contre le Covid ;)
-
Pour les accès FTTH, la remontée ce fait en PPPoE sans vlan côté client j'imagine ?
Le Realm ressemble à quoi après le @ ? Un genre de "my_user@milkywan.appliwave" ?
Appliwave a une collecte Bouygues (Nerim) en directe ?
Je vois mal un login de cette forme : "my_user@milkywan.appliwave.nerim"
-
Pour les accès FTTH, la remontée ce fait en PPPoE sans vlan côté client j'imagine ?
sur les FTTH Bouygues/SFR, il y'a un VLAN, aucune idée de pourquoi.
Le Realm ressemble à quoi après le @ ? Un genre de "my_user@milkywan.appliwave" ?
exactement
Appliwave a une collecte Bouygues (Nerim) en directe ?
Oui, collecte SFR et Bouygues (entre autres) en direct
-
sur les FTTH Bouygues/SFR, il y'a un VLAN, aucune idée de pourquoi.
exactement
Oui, collecte SFR et Bouygues (entre autres) en direct
Pourtant les OLT peuvent être configurés* pour untag le VLAN source et distribuer le tout au client sans VLAN.
*Dans les "services-profiles".
-
En tout cas, dans les STAS Bouygues (je n'ai pas regardé celles de SFR), ils disent que le VLAN est obligatoire...
-
Appliwave a des LAC seulement en région parisienne ?
-
Appliwave a des LAC/LNS dans chaque POP, mais les collectes FTTH ne sont livrables (et donc livrées) qu'en région parisienne. Le jour où il y'aura des collectes en région, on mettra un LNS en région pour collecter.
Et pour le coup, quand on parle de livraison de collecte, le LAC est toujours chez le FAI collecteur, l'interco c'est de l'IP+BGP entre LNS et de l'interco RADIUS dans certains cas.
-
Appliwave a des LAC/LNS dans chaque POP, mais les collectes FTTH ne sont livrables (et donc livrées) qu'en région parisienne. Le jour où il y'aura des collectes en région, on mettra un LNS en région pour collecter.
Et pour le coup, quand on parle de livraison de collecte, le LAC est toujours chez le FAI collecteur, l'interco c'est de l'IP+BGP entre LNS et de l'interco RADIUS dans certains cas.
Cela veut dire que lorsque la requête PADO est reçu dans la séquence, c'est le matériel de Bouygues qui répond et pas celui de Appliwave ?
-
Nop, la session PPP est montée par le LNS final (en l'occurence celui de MilkyWan), les LAC et les LNS sur le chemin ne sont là que pour encapsuler le PPPoE dans un VPDN et forwarder celui-ci jusqu'au LNS final
(https://www.cisco.com/c/dam/en/us/support/docs/dial-access/virtual-private-dialup-network-vpdn/20980-vpdn-20980b.gif)
-
Je parlais du serveur PPPoE qui te répond, sur OVH collecte Kosc par exemple :
(https://i.gyazo.com/b370f6af5391dc2e86ec614e69ff21aa.png)
(https://i.gyazo.com/8f7dc747075ce61b0e1638a1b282c16c.png)
https://lafibre.info/ovh-fai/ftth-ovh-prix/132/ (https://lafibre.info/ovh-fai/ftth-ovh-prix/132/)
Du coup c'est un LAC Orange ou Kosc ? Vu le nom du matériel (sra8) c'est Nokia, et en général Nokia c'est Orange qui aime ce genre de produit.
-
C'est le LAC de Bouygues ou SFR qui répond, les LNS Appliwave/MilkyWan ne sont pas dans le domaine PPPoE
-
Le schéma que tu montres n'est valable que dans le cas où tu as une conf de ce type :
"my_user@milkywan"
Alors que de ce que j'ai compris quand tu as deux realm, c'est :
PPPoe Client <-> LAC (OPT Infra) <-> LAC (Appliwave) <-L2TP-> LNS Milkywan.
-
Le schéma que tu montres n'est valable que dans le cas où tu as une conf de ce type :
"my_user@milkywan"
Alors que de ce que j'ai compris quand tu as deux realm, c'est :
PPPoe Client <-> LAC (OPT Infra) <-> LAC (Appliwave) <-L2TP-> LNS Milkywan.
Oui on est bien dans le schéma que tu indique.
On a des collectes en direct avec tout le monde. Je ne vois pas ce que Nerim viens faire la dedans même si nous avons encore une collecte historique pour leur 10 DSLAM parisiens ;)
-
Oui on est bien dans le schéma que tu indique.
On a des collectes en direct avec tout le monde. Je ne vois pas ce que Nerim viens faire la dedans même si nous avons encore une collecte historique pour leur 10 DSLAM parisiens ;)
Mais comment le realm (le domaine du coup) est t-il redirigé vers le LAC de l'OPT de Collecte ? Via le RADIUS de l'OPT d'Infra ?
D'ailleurs c'est bizarre que les realm sont "lus" à l'envers pour faire la translation...
-
Mais comment le realm (le domaine du coup) est t-il redirigé vers le LAC de l'OPT de Collecte ? Via le RADIUS de l'OPT d'Infra ?
D'ailleurs c'est bizarre que les realm sont "lus" à l'envers pour faire la translation...
Le Radius de l'opérateur nous renvoi tout ce qui est en .ic (on a choisis .ic chez Appliwave pour que ce soit assez générique pour nos partenaires).
Derrière on fait la même avec nos clients, ex : milkywan.ic
Sachant que Bouygues ou SFR aime bien rajouter un quelque choses. Ca fait donc un truc du genre xxxx@xxx.milkywan.ic.dop
Car oui Milkywan peut aussi s'il a envi router un sous domaine. On reste transparent.
Mail tu peux router juste un lien aussi, bref c'est un login quoi
-
Le Radius de l'opérateur nous renvoi tout ce qui est en .ic (on a choisis .ic chez Appliwave pour que ce soit assez générique pour nos partenaires).
Derrière on fait la même avec nos clients, ex : milkywan.ic
Sachant que Bouygues ou SFR aime bien rajouter un quelque choses. Ca fait donc un truc du genre xxxx@xxx.milkywan.ic.dop
Car oui Milkywan peut aussi s'il a envi router un sous domaine. On reste transparent.
Mail tu peux router juste un lien aussi, bref c'est un login quoi
Donc sur Milkywan on est sur 3 realm au final ?
-
Donc sur Milkywan on est sur 3 realm au final ?
Ca dépends de la collecte, Bouygues et SFR oui, Orange non.
En Orange on pourrait même mettre juste un .milkywan
-
Tu es sur du .dop chez Bouygues ? Je crois que ce n'est que chez SFR
-
Alors CBO est à 20Km de Paris, on est pas à TH3 hein
Comme j'étais curieux, j'ai mesuré et à vol d'oiseau par rapport à l'Hôtel de Ville de Paris il n'y a que 3 km de différence entre CBO et TH3. :P
-
Cela confirme que CBO c'est le bout du monde.
-
Alors CBO est à 20Km de Paris, on est pas à TH3 hein
Comme j'étais curieux, j'ai mesuré et à vol d'oiseau par rapport à l'Hôtel de Ville de Paris il n'y a que 3 km de différence entre CBO et TH3. :P
C'est même pire que ça :P
Les distances mesurées à vol d'oiseau par rapport au boulevard périphérique (de Paris, je précise au cas où):
- TéléHouse 3 : 18km
- AppliWave-Croissy-Beaubourg : 17km
C'est kif kif bourricot!
Et dans les 2 cas, les 2 datacenters sont (quasiment) au milieu de la forêt! Si si, je vous jure.
A 17km également, totalement à l'opposé de Paris, on a aussi le très joli datacenter SFR-Achères.
A peine plus éloigné, à ~20km du périph, on trouve DC5 Scaleway, et l'immense Data4 Marcoussis.
Plus loin que ça, en restant en banlieue parisienne, il y a encore des gros datacenters?
Perso, j'habite à 12km du périph, au milieu de la verdure, et j'ai déjà l'impression d'être en province... sauf quand je regarde mes avis de loyer.
Leon.
-
Alors non désolé les gars, on est vraiment plus proche ne serait-ce qu'en temps de l'Hotel de ville !
Puis ici on a pas mal de réseaux fibres, Magny c'est beaucoup + compliqué car eux vraiment campagne et forets.
-
Alors non désolé les gars, on est vraiment plus proche ne serait-ce qu'en temps de l'Hotel de ville !
Je crois qu'on a touché une corde sensible; ne pas critiquer Croisy-Beaubourg en présence de Julien! ;)
Je rappelle que l'origine de la discussion (au moins la partie sérieuse), c'était l'éloignement de Appliwave-CBO en distance fibre parcourue, par rapport aux autres datacenters parisiens, vu que MilkyWan semblait avoir du mal à éclairer un lambda passif entre AppliWave-Croissy-Beaubourg et Scaleway-DC2-Vitry (qui n'est qu'à 4km du périph, bien en dessous des 17km de CBO).
Pour un chemin optique déjà établi (le cas de MilkyWan) les photons se moquent pas mal de savoir combien de temps mets un humain en bagnole pour relier 2 datacenters! Ou en RER d'ailleurs.
Et ils se moquent également de savoir la densité de fibre qu'il y a autour d'eux.
Leon.
-
Je crois qu'on a touché une corde sensible; ne pas critiquer Croisy-Beaubourg en présence de Julien! ;)
Je rappelle que l'origine de la discussion (au moins la partie sérieuse), c'était l'éloignement de Appliwave-CBO en distance fibre parcourue, par rapport aux autres datacenters parisiens, vu que MilkyWan semblait avoir du mal à éclairer un lambda passif entre AppliWave-Croissy-Beaubourg et Scaleway-DC2-Vitry (qui n'est qu'à 4km du périph, bien en dessous des 17km de CBO).
Pour un chemin optique déjà établi (le cas de MilkyWan) les photons se moquent pas mal de savoir combien de temps mets un humain en bagnole pour relier 2 datacenters! Ou en RER d'ailleurs.
Et ils se moquent également de savoir la densité de fibre qu'il y a autour d'eux.
Leon.
Tu charries là, on dirait ;D ;D
20 km, à la vitesse de la lumière, c'est beaucoup ?
-
Je crois qu'on a touché une corde sensible; ne pas critiquer Croisy-Beaubourg en présence de Julien! ;)
Je rappelle que l'origine de la discussion (au moins la partie sérieuse), c'était l'éloignement de Appliwave-CBO en distance fibre parcourue, par rapport aux autres datacenters parisiens, vu que MilkyWan semblait avoir du mal à éclairer un lambda passif entre AppliWave-Croissy-Beaubourg et Scaleway-DC2-Vitry (qui n'est qu'à 4km du périph, bien en dessous des 17km de CBO).
Pour un chemin optique déjà établi (le cas de MilkyWan) les photons se moquent pas mal de savoir combien de temps mets un humain en bagnole pour relier 2 datacenters! Ou en RER d'ailleurs.
Et ils se moquent également de savoir la densité de fibre qu'il y a autour d'eux.
Leon.
Ah non non t'inquiète pas !
En vrai, on devrait pouvoir éclairer CBO en DWDM vers DC2, mais y'a 2 pb, on passe par un mux entre dans Paris, donc 8db de perte et aussi on a je pense quelques soudures pas belle sur cette liaison, on doit s'en occuper, mais comme tu le sais c'est toujours les cordonniers les plus mal chaussés
-
Tu charries là, on dirait ;D ;D
20 km, à la vitesse de la lumière, c'est beaucoup ?
Mais pourquoi tu parles de temps de propagation? Ca n'est pas le débat ici. Essaye de suivre un peu, stp.
Ce qui a posé problème à MilkyWan, pour relier les 2 sites, ça n'est pas le temps de propagation, évidemment; c'est l'atténuation de la fibre sur une distance trop grande. Ils utilisent des modules WDM fibre classiques, sans amplificateur optiques.
En fait, au delà de nos remarques à la con sur le fait que Croissy-Beaubourg est loin de Paris, ça montre bien le problème qu'on évoquait ici.
Pour réaliser un maximum d'interconnexions redondantes entre un maximum de réseaux différents, l'idéal c'est d'avoir une multitude de datacenters assez proches les uns des autres, dans une même agqlomération, avec un réseau dense de fibres. Les faibles distances entre datacenter (une dizaine de km maxi c'est bien), ça permet d'utiliser du matériel très économique/accessible/facile à utiliser pour des gros débits: modules optiques CWDM ou DWDM (SFP+ par exemple) capable de 10 ou 20km.
De mon côté, je persiste à penser que quelques datacenters / carrier hotels dans les grandes mégalopoles, avec un réseau de fibre très dense autour, ça ressemble à une solution optimale pour interconnecter les acteurs entre eux. Regrouper les coeurs de réseaux dans une même zone géographique, c'est quand même très très pratique! Et en parallèle, il est logique d'avoir des datacenters "à la campagne", pour les infrastructure qui n'ont besoin que de peu de liaisons (en nombre) avec l'extérieur.
Ah non non t'inquiète pas !
En vrai, on devrait pouvoir éclairer CBO en DWDM vers DC2, mais y'a 2 pb, on passe par un mux entre dans Paris, donc 8db de perte et aussi on a je pense quelques soudures pas belle sur cette liaison, on doit s'en occuper, mais comme tu le sais c'est toujours les cordonniers les plus mal chaussés
Pour ce genre d'architecture, vous utilisez 2 Mux-Demux au milieu de la liaison? Donc 2 Mux + 2 Demux sur l'ensemble de la liaison? Au milieu de la liaison, un OADM passif, ça devrait générer moins de 8dB, non?
Leon.
-
Mais pourquoi tu parles de temps de propagation? Ca n'est pas le débat ici. Essaye de suivre un peu, stp.
Ce qui a posé problème à MilkyWan, pour relier les 2 sites, ça n'est pas le temps de propagation, évidemment; c'est l'atténuation de la fibre sur une distance trop grande. Ils utilisent des modules WDM fibre classiques, sans amplificateur optiques.
En fait, au delà de nos remarques à la con sur le fait que Croissy-Beaubourg est loin de Paris, ça montre bien le problème qu'on évoquait ici.
Pour réaliser un maximum d'interconnexions redondantes entre un maximum de réseaux différents, l'idéal c'est d'avoir une multitude de datacenters assez proches les uns des autres, dans une même agqlomération, avec un réseau dense de fibres. Les faibles distances (dizaine de km maxi c'est bien), ça permet d'utiliser du matériel très économique/accessible pour des débits: modules optiques CWDM ou DWDM (SFP+ par exemple) capable de 10 ou 20km.
Leon.
;D
Non, mais dis, tu me prends pour une quiche ?
J'ai fait des épissures et jonctions de fibres à la lame de rasoir, et mesures de réflectométrie il y a plus de 30 ans. Mesure de la distance de la jonction à l'émission, avec insertion laser, et c'était pas les lasers d'aujourd'hui. Les soudeuses sont venues plus tard. Sur des bobines de fibres faisant bien plus de 20 km, mesure de la distance la rebond à la soudure, mesurée à l'oscillo et calcul à la "main".
Mesures des différentes longueurs d'ondes, forme des "décalages" optiques et étalements, sur fibres multimodes à gradient et toujours à l'oscillo.
Je veux bien que tu me prennes pour un bleu, mais quand même. ;D
-
Ce qui a posé problème à MilkyWan, pour relier les 2 sites, ça n'est pas le temps de propagation, évidemment; c'est l'atténuation de la fibre sur une distance trop grande. Ils utilisent des modules WDM fibre classiques, sans amplificateur optiques.
Non, ce n'est pas une question de distance "trop grande" et d'amplification sur cette distance, c'est une question de bilan optique, le nombre de jonctions et leur atténuation sur le chemin optique pris.
-
En fait, c’est un peu des deux. Le chemin pourrait être plus court et plus propre.
-
En fait, c’est un peu des deux. Le chemin pourrait être plus court et plus propre.
Non, tu t'en fou que ce soit plus court sur cette distance, ce qu'il faut c'est, que ce ne soit pas atténué par les jonctions. Sur une longueur de 20 km une fibre sans jonctions, tu n'a pas de problèmes de signal avec les fibres monomodes et lasers actuels, ou du moins pas perceptibles pour les longueurs d'ondes utilisées.
A -3db, tu n'as plus que la moitié du signal, si c'est -8db, il y a un vrai soucis.
-
Je ne suis pas ici pour la sodomie drosophilienne, le souci est donc que le tracé n’est pas optimal et qu’on passe pas pas mal de connecteurs et de soudures pas top. Le reste c’est de la théorie que je connais mais qui n’a aucun intérêt dans ce cas.
-
Je ne suis pas ici pour la sodomie drosophilienne, le souci est donc que le tracé n’est pas optimal et qu’on passe pas pas mal de connecteurs et de soudures pas top. Le reste c’est de la théorie que je connais mais qui n’a aucun intérêt dans ce cas.
La théorie te permet de trouver à quelle distance dans le chemin optique se trouve l'atténuation, et par conséquent de demander au fournisseur d'intervenir à cet endroit pour lever cette atténuation.
Cela servira tout le monde, tu ne dois pas être le seul impacté.
D'autant que fonction de la lambda que tu fais passer dessus l'atténuation peut être différente, que le problème ne se détecte pas à certaines lambda mais à d'autres, toi tu ne les utilisent peut-être pas mais le fournisseur, les fournis à d'autres.
Regardes pas que par le bout de ta lorgnette.
-
Appliwave savent ce qu'ils font, je te rassure :)
-
Appliwave savent ce qu'ils font, je te rassure :)
Je n'en doutes pas une seule seconde, Julien dit qu'il a -8db quelque part, c'est un problème à régler, il ne t'impacte pas que toi.
Les conséquences, c'est ce qu'évoquait Léon, devoir mettre des amplificateurs alors que le vrai problème n'est pas l'amplification.
D'autant qu'amplifier, pose d'autres problèmes.
-
Je n'en doutes pas une seule seconde, Julien dit qu'il a -8db quelque part, c'est un problème à régler, il ne t'impacte pas que toi.
Les conséquences, c'est ce qu'évoquait Léon, devoir mettre des amplificateurs alors que le vrai problème n'est pas l'amplification.
D'autant qu'amplifier, pose d'autres problèmes.
En fait non, on passe via 2 liaisons différentes, une pas à totalement à nous et une autre totalement à nous.
En vrai, les deux liaisons séparés il n'y a aucun problème et notre besoin est à la base pour 2 liaisons séparés.
La on veut s'amuser et faire du DWDM en passant à travers 2 mux. Du coup c'est plus compliqué.
En vrai on a de quoi faire beaucoup plus clean aussi en chemin genre gagner 20km au moins MAIS on a pas pénétrer DC2 en propre.
-
Par contre, ce serait bien de pas annoncer le préfixe sur lequel est le site "lafibre.info" sur Lillix.
Il n'y pas un moyen de forcer la route via FranceIX ?
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| overthebox - 0 | 6 | 6 | 0 | 2 | 14 | 0 |
| 10.166.179.1 - 0 | 6 | 6 | 14 | 14 | 15 | 14 |
| Request timed out. - 100 | 2 | 0 | 0 | 0 | 0 | 0 |
| spine-201-12.otb.ovh - 0 | 6 | 6 | 20 | 20 | 20 | 20 |
| 10.22.201.17 - 0 | 6 | 6 | 19 | 20 | 26 | 19 |
| 145.239.153.151 - 0 | 6 | 6 | 20 | 21 | 25 | 25 |
| be50.par-gsw-pb2-nc5.fr.eu - 0 | 6 | 6 | 48 | 69 | 105 | 48 |
| 10.200.2.0 - 0 | 6 | 6 | 20 | 20 | 21 | 20 |
| 10.200.200.5 - 0 | 6 | 6 | 25 | 32 | 42 | 28 |
| 10.200.2.0 - 0 | 5 | 5 | 20 | 21 | 26 | 20 |
| be102.rbx-g2-nc5.fr.eu - 0 | 5 | 5 | 24 | 25 | 28 | 28 |
| be2.rbx-5-a72.fr.eu - 0 | 5 | 5 | 23 | 23 | 24 | 23 |
| milkywan.lillix.fr - 0 | 5 | 5 | 23 | 25 | 31 | 23 |
|tfe1.2983.ccr2004.edge.th2.bb.ip4.milkywan.net - 0 | 5 | 5 | 28 | 28 | 29 | 28 |
|tfe1.2986.ccr2004.edge.vnx.bb.ip4.milkywan.net - 0 | 5 | 5 | 40 | 43 | 55 | 40 |
|te1.rb4011.col.vnx.infra.ip4.milkywan.net - 0 | 5 | 5 | 40 | 50 | 87 | 40 |
| lafibre.cust.milkywan.net - 0 | 5 | 5 | 34 | 35 | 36 | 35 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
Ne faites pas attention à la latence, c'est du OverThebox, c'est un peu crade.
-
En l'occurence pour OVH, la grande majorité de leurs services étant localisés à Roubaix ou Gravelines, vu qu'ils ont un 100G sur LillIX, c'est pertinent en termes de latence et de BP de les joindre à Lille.
Accessoirement, si je les mettais sur France-IX, ça nous couterait 300€/mois car il faudrait upgrader le commit FIX de 200M à 1G.
C'est pareil pour Online qui passe en transit d'ailleurs, et prochainement Hetzner je pense. On a intérêt a ne pas passer par France-IX pour le trafic IN qui se joint bien autrement :)
-
OVH a deux AS.
Quel AS pour les IPv6 chez les offres FAI OVH Télécom ?
OVH a deux AS (Autonomous System) :
- OVH AS16276, qui est la partie hébergeur avec 2,7 millions d'IPv4 annoncées et bien sur de l'IPv6. C'est elle qui a le speering / transit.
- OVH Telecom AS35540 utilisé pour les offres ADSL, VDSL, SDSL ou OverTheBox. OVH AS35540 a pour unique transitaire AS16276, logique. AS35540 annonce 131072 IPv4 (109.190.0.0/16 et 151.127.0.0/16).
Pour la partie hébergement, il n'y a pas de débat : l'écrasante majorité des serveurs OVH joins par le réseau Milkywan sont, je pense, à Roubaix ou ont des connexions solides avec Roubaix (Gravelines, Strasbourg, ...).
Par contre, en sachant que la majorité des clients de la partie Télécom ne doit pas être à Lille, cela ne serait il pas pertinent de peerer avec OVH uniquement pour la partie Télécom / AS35540 à Paris / FranceIX ? Avec une redondance par LillIX en cas de soucis à FranceIX par exemple. Enfin si c'est possible, car OVH AS35540 n'est à priori sur aucun IX, donc il faut passer par l'AS16276 en filtrant les IP de l'AS35540.
-
En sortie, ça serait possible, pas en entrée :/
-
En sortie, ça serait possible, pas en entrée :/
Oui, logique en fait, puisqu'il faudrait qu'OVH configure cette préférence de son côté en même temps.
Du coup mieux vaut laisser les choses comme ça pour éviter d'avoir une route aller/retour différente.
-
Par contre, en sachant que la majorité des clients de la partie Télécom ne doit pas être à Lille,
Il ne semble pas y avoir un routage régional chez OVH Telecom: 15ms pour atteindre le lns de Marseille.
$ mtr4 9.9.9.9
Start: 2021-08-16T18:25:18+0200
HOST: Lyoko.in.ByMe.at Loss% Snt Last Avg Best Wrst StDev
1. AS??? astriaporta.vl106.mrs.in.byme.at (192.168.44.49) 0.0% 10 0.9 1.0 0.9 1.6 0.2
2. AS35540 cpe-ovh.eth1.mrs.byme.at (109.190.103.134) 0.0% 10 1.2 1.4 1.1 3.1 0.6
3. AS16276 145.239.153.11 0.0% 10 17.2 17.7 15.9 21.8 2.2
4. AS16276 145.239.153.135 0.0% 10 16.4 18.2 16.4 23.9 2.5
5. AS??? 10.200.2.73 0.0% 10 18.9 19.4 16.4 28.6 3.7
6. AS??? 10.200.2.0 0.0% 10 20.1 21.5 16.6 32.9 6.4
7. AS??? 10.200.200.9 0.0% 10 33.4 31.9 24.3 38.3 5.4
8. AS??? 10.200.2.0 0.0% 10 34.2 19.4 16.8 34.2 5.5
9. AS??? 10.200.2.77 0.0% 10 19.8 17.9 17.0 19.8 1.0
10. AS??? pch1.par.franceix.net (37.49.236.92) 0.0% 10 18.2 21.4 17.3 35.5 5.6
11. AS19281 dns9.quad9.net (9.9.9.9) 0.0% 10 21.6 25.5 16.9 51.4 11.4
-
Il n'y a pas de LNS à Marseille, car d'après ce que j'ai lu dans les STATS Orange pour la collecte DSL (ça doit être pareil pour le FTTH), il y a la collecte en mode IP et la collecte en mode Ethernet.
Ce qui veut dire que le LAC de Kosc qui répond aux requêtes PPPoE est sûrement basé à Marseille d'après ta ligne. Il y a deux VLAN, le S-VLAN et le C-VLAN.
Le C-VLAN c'est le customer VLAN, en l'occurrence pour Kosc il est en untag côté client. Mais le S-VLAN c'est le VLAN côté service Kosc étant dans ce mode de configuration c'est donc de la collecte Ethernet.
En mode IP ce serait le BAS/LAC d'Orange qui rédirige le trafic sur le bon LNS en fonction du/des realms.
Autre chose aussi que j'ai pu lire, la collecte est par plaques.
Ce qui veut dire que l'on ne peut pas mettre un LNS à Paris en interco avec un BAS/LAC d'Aubervilliers par exemple et collecter toute la France. Dommage..., car il semblerait que chaque BAS/LAC soient dans un VLAN différents pour chaque plaques.
Mais bref, le LNS d'OVH sort donc à TH2 et GSW. Kosc étant aussi à TH2 et Equinix PA2 Saint Denis. (voir weathermap OVH).
Il y a donc bien une collecte au niveau régionale de la part de Kosc (en L2) mais pas en sortie de LNS.
-
Il n'y a pas de LNS à Marseille, car d'après ce que j'ai lu dans les STATS Orange pour la collecte DSL (ça doit être pareil pour le FTTH), il y a la collecte en mode IP et la collecte en mode Ethernet.
Ce qui veut dire que le LAC de Kosc qui répond aux requêtes PPPoE est sûrement basé à Marseille d'après ta ligne. Il y a deux VLAN, le S-VLAN et le C-VLAN.
Le C-VLAN c'est le customer VLAN, en l'occurrence pour Kosc il est en untag côté client. Mais le S-VLAN c'est le VLAN côté service Kosc étant dans ce mode de configuration c'est donc de la collecte Ethernet.
En mode IP ce serait le BAS/LAC d'Orange qui rédirige le trafic sur le bon LNS en fonction du/des realms.
Autre chose aussi que j'ai pu lire, la collecte est par plaques.
Ce qui veut dire que l'on ne peut pas mettre un LNS à Paris en interco avec un BAS/LAC d'Aubervilliers par exemple et collecter toute la France. Dommage..., car il semblerait que chaque BAS/LAC soient dans un VLAN différents pour chaque plaques.
Mais bref, le LNS d'OVH sort donc à TH2 et GSW. Kosc étant aussi à TH2 et Equinix PA2 Saint Denis. (voir weathermap OVH).
Il y a donc bien une collecte au niveau régionale de la part de Kosc (en L2) mais pas en sortie de LNS.
Hein ?
-
Rien compris non plus, le S/Cvlan c’est en archi QinQ et a mon avis leur backbone est plutôt en L3 chez Kosc
-
C'est seulement du L2 Kosc pour la collecte, évidemment qu'après c'est du L3 pour le routage. (Mais on ne le voit pas).
L'architecture c'est du QinQ chez Orange et j'en suis presque sûr à 100%. Tels que les VLAN que l'on connait actuellement chez Orange (835 pour le PPPoE, 832 DHCP + VoIP, 840 TV).
Mais ces VLAN là ne sont pas les mêmes côté infra et selon les plaques.
Ils ont donc appliqué la même chose avec le Bitstream pour Kosc, sauf que côté C-VLAN c'est untagged.
Donc sur Milkywan, ByTel ou SFR aurait pu faire du QinQ avec Appliwave et ainsi untag le trafic côté client.
-
Hum, j'ai du mal à voir le rapport.
La collecte est en L3 chez Orange, que ce soit en IPoE (DHCP) ou en PPPoE (L2TP), il y'a bien un L2 entre le DSLAM et le LAC mais ce L2 est lui même virtualisé sur du VPLS (ou autre mécanisme d'encap).
Concernant KOSC, c'est du BSNRO et donc une collecte très différente de celles utilisées en xDSL. Les clients Kosc sont directement livrés en L2 au NRO, et ensuite KOSC les remonte en VPLS jusqu'à leur LAC, et là, que ce soit a paris ou ailleurs, c'est le problème de KOSC.
-
Il n'y a pas de LNS à Marseille,
15ms pour atteindre le LNS depuis Marseille.
S'il fallait 15ms pour faire OLT=>LNS dans la même ville, j'aurais quitté le FAI depuis longtemps pour incompétence.
-
Hum, j'ai du mal à voir le rapport.
La collecte est en L3 chez Orange, que ce soit en IPoE (DHCP) ou en PPPoE (L2TP), il y'a bien un L2 entre le DSLAM et le LAC mais ce L2 est lui même virtualisé sur du VPLS (ou autre mécanisme d'encap).
Concernant KOSC, c'est du BSNRO et donc une collecte très différente de celles utilisées en xDSL. Les clients Kosc sont directement livrés en L2 au NRO, et ensuite KOSC les remonte en VPLS jusqu'à leur LAC, et là, que ce soit a paris ou ailleurs, c'est le problème de KOSC.
Je confirme ce que dit Hugues. Les collectes Ethernet Orange c’est des aires VPLS.
Après sauf erreur, Kosc n’en a pas en ADSL !
OVH achète soit du Kosc soit du SFR soit du Orange en direct.
Non ?
-
Oui mais tu es d'accord que dans le principe un VLAN c'est du L2 (même si L3 puis VPLS par la suite etc...), Appliwave reçoit donc le trafic en mode Ethernet(L2) ou IP (L3) ?
Le fait de collecter en IP revient plus cher que de le faire en Ethernet. Et ce, peu importe l'opérateur d'infra.
-
Oui mais tu es d'accord que dans le principe un VLAN c'est du L2 (même si L3 puis VPLS par la suite etc...), Appliwave reçoit donc le trafic en mode Ethernet(L2) ou IP (L3) ?
Le fait de collecter en IP revient plus cher que de le faire en Ethernet. Et ce, peu importe l'opérateur d'infra.
Oui c’est du L2 qui est livré si tu as une collecte Ethernet.
C’est récent chez Orange de l’avoir pour toute la France sur 2 collectes. Avant c’était une par région pour l’adsl.
En vrai oui le L3 doit leur coûter plus cher même si à l’échelle d’Orange je ne suis pas sûr.
-
Oui mais tu es d'accord que dans le principe un VLAN c'est du L2 (même si L3 puis VPLS par la suite etc...), Appliwave reçoit donc le trafic en mode Ethernet(L2) ou IP (L3) ?
Si ta question est de savoir pourquoi il y'a un VLAN entre l'ONT et le BAS, je pense que c'est pour simplement différencier le trafic PPPoE du trafic IPoE sans devoir faire des confs spécifiques coté OLT. Ca serait tout a fait possible de faire de l'untag sur le vlan PPPoE comme le fait KOSC ou comme le font beaucoup d'OI de RIP comme Axione.
En tout cas, pas besoin de faire de QinQ pour ça, c'est du simple dot1q entre l'OLT et le LAC.
-
Non ça je sais que c'est pour séparer les flux entre eux.
C'est juste que pour reprendre un exemple, le VLAN 835 en FTTH, le LAC qui répond est à Aubervilliers alors que l'on est depuis une ligne à Lyon.
Si tu dis que c'est du dot1q comment ça ce fait que je ne vois pas les autres LAC/BAS dans le scan PPPoE ?
C'est pour ça que le QinQ et donc S/C-VLAN est utile quand tu veux séparer les plaques (régions) car si tous les LAC/BAS était dans le même S-VLAN ce serait le bordel.
C'est là où je veux en venir. Car au final si tu prends la Livebox, qui est configuré au niveau firmware pour écouter 835, 832, 840 ce serait difficile de devoir changer les VLAN côtés client à chaque fois.
Sachant que je crois que le VLAN 835 est laissé au cas où si le DHCP du 832 tombe en rade.
-
Si tu dis que c'est du dot1q comment ça ce fait que je ne vois pas les autres LAC/BAS dans le scan PPPoE ?
Pourquoi verrais-tu plusieurs LAC dans le VLAN ?
Je ne connais pas précisément l'infra d'Orange mais il n'y a certainement pas qu'un seul VLAN835 dans le backbone orange, il est même très certainement bridgé sur un vpls unique au DSLAM/NRA et transporté en VPLS jusqu'a un BAS. Et si le BAS tombe, la bascule se fait au niveau VPLS et pas au niveau Ethernet.
-
Tiens je prends un exemple, sur un OLT Huawei (après avoir configuré le service profile) tu dois faire un :
service-port 0 vlan 1001 (S-VLAN) gpon 0/1/0 ont 0 gemport 0 multi-service user-vlan 835 inbound traffic ip table index 7 outbound traffic ip table index 7.
Donc imaginons que le VLAN 1001 soit par rapport à une plaque et donc une zone desservie, 1002 serait une autre plaque etc etc.
Tu vois le truc ? C'est à dire que au delà de VPLS, je pensais que les DSLAM/OLT pouvaient tag les trames et que c'était seulement eux qui taggait les trames.
Je vois pas pourquoi le routeur qui se situe après les équipements d'accès devrait tag lui aussi les trames car si tu restes en L2 le tag est toujours présent. Sachant que un routeur fait aussi office de Switch.
Ça impliquerait de devoir indiqué aux routeurs du backbone de la plaque le nouveau VLAN ( quand un opérateur de collecte souscrit une offre Ethernet par exemple) même si c'est automatisé via un outil de supervision c'est chiant.
Alors que de juste pousser une config avec le nouveau VLAN via les outils de supervision juste sur les équipements d'accès (une chaîne d'OLT par exemple) c'est beaucoup plus simple non ?
-
La collecte orange ppp est composée de MSAN, donc dslam ou olt, raccordés à des routeurs de collecte qui sont eux-même raccordés au backbone.
Les msan vont bridger (avec un split horizon - chaque client, chaque vlan 835 est étanche) les vlans "well-known" dans des vlans coté collecte. Le vlan 835 sera transformé en 1234 (exemple) coté collecte, le 832 en 1235, etc, et ce, de la même manière sur tous les msan. Il en va de même avec les vlans des opérateurs tiers pour les collecte multipoints : GP, C2E, CEM2.
Sur le routeur de collecte, le vlan 1234 du dslam X sera bridgé dans un pseudowire vers un BAS, qui va terminer la session ppp. Ce même vlan d'un autre dslam sur le même routeur sera envoyé dans un autre pw mais possiblement vers le même BAS. Les vlans des offres de collecte ethernet seront envoyés de la même manière vers la porte de collecte de l'opérateur tiers. Via un pseudowire pour dslce, un vpls pour c2e et cem2/3.
Dans le cas d'une collecte ppp, alors c'est le BAS Orange qui aura le rôle de LAC, et qui forwardera la session ppp dans un tunnel l2tp vers le LNS de l'opérateur tiers, ou Orange dans le cas historique des clients IP fixe Orange.
Dans le cas d'un OLT, le pseudowire ethernet correspondant au vlan 835 (archi legacy ppp) est envoyé vers un "bas national" en idf. Le vlan 832 quant à lui est terminé sur le routeur de collecte, qui est dhcp relay et gateway IP pour les clients.
-
Donc si je résume,
Les pseudo-wires sont en fait des tunnels VPLS établi avec les remotes peers du réseau MPLS déjà en place.
Au final un réseau L2 dans un réseau L2.5.
Si on prend le cas du Bitstream NRO, cela veut dire qu' un tunnel VPLS est établi entre le routeur de collecte NRO/NRA de la zone (NE/NB chez Orange je crois) et le routeur côté porte de collecte.
Est ce que de ce fait l'opérateur tiers doit à son tour configurer un MPLS entre son routeur et le routeur de la porte de collecte de l'opérateur d'infra ?
Puis établir par la suite un tunnel VPLS entre le routeur de la porte de collecte et son propre routeur pour ensuite ensuite atterrir sur un LAC ?
Ce qui veut dire que le Bitstream ce fait au cas par cas, donc NRO maitre** par NRO maitre** ? On ne peut donc pas collecter une plaque entière ?
**: NRO/NRA contenant le routeur de collecte.
-
Sur l'infra Orange, tu as un routeur de collecte (NE) qui collecte plusieurs DSLAM ou OLTs à l'échelle d'un regroupement de villes. Ces NE construisent à l'échelle d'une région un réseau qu'on appelle "Backbone C2E". Pour se connecter à ce réseau, Orange met en place des NM, qui sont des routeurs capables de dialoguer avec un routeur PE (provider edge) d'un autre opérateur. Il y a au minimum deux sites de collecte par région, et minimum deux routeurs NM d'Orange sont à disposition de l'opérateur par site donc quatre par plaque : https://www.orange.com/sites/orangecom/files/documents/2020-06/plaques_et_points_de_collecte_avril2012.pdf (https://www.orange.com/sites/orangecom/files/documents/2020-06/plaques_et_points_de_collecte_avril2012.pdf).
Ça c'est valable pour la collecte C2E : offres SDSL, FTTO, ... Pour l'ADSL, afin d'ouvrir le marché à plus de concurrence, l'ARCEP a demandé à Orange de proposer une collecte nationale sans coûts supplémentaires (collecte à Paris et Aubervilliers si je ne fais pas erreur), permettant l'entrée de plus petits acteurs en diminuant le coût d'entrée. La collecte ADSL est technologiquement très différente de la collecte C2E car si en C2E c'est l'opérateur tiers qui identifie le CPE du client directement, en collecte ADSL l'identification est faite par le réseau d'Orange, qui interroge un RADIUS de l'opérateur tiers. Et ensuite le trafic monte jusqu'au PE de l'opérateur. La collecte en régional est donc réalisée directement par Orange.
Tout ça se monte en aboutant des "tuyaux virtuels", MPLS ou VPLS, qui permettent d'encapsuler du trafic Ethernet (CELAN/C2E) ou du trafic IP (ADSL) dans du trafic IP.
Le routeur PE de l'opérateur ne voit que des sessions PPP ou autre. Une fois sur son réseau, chaque opérateur fait comme bon lui semble : Free par exemple n'utilise pas de MPLS, sauf erreur de ma part.
-
Les pseudo-wires sont en fait des tunnels VPLS établi avec les remotes peers du réseau MPLS déjà en place.
Non, pas tout à fait, les pseudowires ne sont pas dans des vpls, c'est du VPWS. Bien que le transport soit identique (label de transport, label de service, control-word), la signalisation est différente (sessions tldp statiques vs bgp-ad).
Au final un réseau L2 dans un réseau L2.5.
C'est pas vraiment un réseau L2, il n'y a pas de learning mac. Tout ce qui rentre d'un coté ressort de l'autre.
Si on prend le cas du Bitstream NRO, cela veut dire qu' un tunnel VPLS est établi entre le routeur de collecte NRO/NRA de la zone (NE/NB chez Orange je crois) et le routeur côté porte de collecte.
Presque, VPWS au lieu de VPLS, mais sinon c'est ça.
Est ce que de ce fait l'opérateur tiers doit à son tour configurer un MPLS entre son routeur et le routeur de la porte de collecte de l'opérateur d'infra ?
L'opérateur tiers fait ce qu'il veut, mpls ou non. En tout cas il est livré sur un vlan avec uniquement une encapsulation dot1q (qinq même).
Puis établir par la suite un tunnel VPLS entre le routeur de la porte de collecte et son propre routeur pour ensuite ensuite atterrir sur un LAC ?
Il fait ce qu'il veut. S'il veut terminer les sessions ppp/dhcp sur le routeur sur lequel le port de collecte est raccordé, il le peut. Ou bien le reforwarder avec la techno de son choix vers "plus loin".
Ce qui veut dire que le Bitstream ce fait au cas par cas, donc NRO maitre** par NRO maitre** ? On ne peut donc pas collecter une plaque entière ?
Non, c'est par plaque.
-
Je tiens juste a ajouter que tout ce que dit petrus ne s'applique pas complètement au BSNRO qui ne remonte pas dans le backbone
-
Non, pas tout à fait, les pseudowires ne sont pas dans des vpls, c'est du VPWS. Bien que le transport soit identique (label de transport, label de service, control-word), la signalisation est différente (sessions tldp statiques vs bgp-ad).
C'est pas vraiment un réseau L2, il n'y a pas de learning mac. Tout ce qui rentre d'un coté ressort de l'autre.
Presque, VPWS au lieu de VPLS, mais sinon c'est ça.
L'opérateur tiers fait ce qu'il veut, mpls ou non. En tout cas il est livré sur un vlan avec uniquement une encapsulation dot1q (qinq même).
Il fait ce qu'il veut. S'il veut terminer les sessions ppp/dhcp sur le routeur sur lequel le port de collecte est raccordé, il le peut. Ou bien le reforwarder avec la techno de son choix vers "plus loin".
Non, c'est par plaque.
Attention Petrus, en C2E tu ne passes pas tout ce que tu veux ! Dans les STAS c'est PPPoE et IP only. Pour ca que la plus part qui font du C2E font du PPPoE d'ailleurs.
Pour moi vous apprenez bien les MAC aussi, quand on fait un diag justement, ca check que les macs côté collecte sont bien là et côté client aussi.
-
Attention Petrus, en C2E tu ne passes pas tout ce que tu veux ! Dans les STAS c'est PPPoE et IP only. Pour ca que la plus part qui font du C2E font du PPPoE d'ailleurs.
Oui en effet, je parlais au niveau transport.
Pour moi vous apprenez bien les MAC aussi, quand on fait un diag justement, ca check que les macs côté collecte sont bien là et côté client aussi.
Sur le C2E oui, c'est du multipoint dans un vpls, donc il y a bien du learning (et donc flooding du bum) sur le dslam, sur le NE/NB en entrée de collecte et sur le NM de livraison.
C'est sur celan/dslce qu'il n'y a pas de learning dans la collecte.
-
Oui en effet, je parlais au niveau transport.
Sur le C2E oui, c'est du multipoint dans un vpls, donc il y a bien du learning (et donc flooding du bum) sur le dslam, sur le NE/NB en entrée de collecte et sur le NM de livraison.
C'est sur celan/dslce qu'il n'y a pas de learning dans la collecte.
CELAN serait bien avec du secours. Mais la c’est inutilisable si on veut un peu de redondance
-
CELAN serait bien avec du secours. Mais la c’est inutilisable si on veut un peu de redondance
C'est LE truc sur celan... Le pw redundancy existe pourtant, il est utilisé par ailleurs.
-
C'est LE truc sur celan... Le pw redundancy existe pourtant, il est utilisé par ailleurs.
Voila exactement ;)
Et tu connais la raison du pourquoi il faut tag une COS sur les paquets en C2E ? Excepté pour embêter ? :D
-
Tiens au faite, le transport entre TH2 et VNX (Netcenter je suppose ?) se fait comment ?
C'est du 10G dans un VPLS Appliwave ? Ou alors un DWDM GTT/Zayo/SFR Business ?
-
VxLAN 25G ;-)
-
Depuis quand RouterOS s'est faire du VxLAN ?
Sûrement une fonctionnalité avec le niveau L6.
Donc un VxLAN chez Appliwave ?
Edit : Ah dans la version 7.0, mais c'est une beta non ?
Bon je vais voir ce que ça donne en le simulant dans GNS3.
-
Depuis quand RouterOS s'est faire du VxLAN ?
v7.
https://stubarea51.net/2020/02/15/mikrotik-routerosv7-first-look-vxlan/
-
C'est un peu risqué d'avoir du beta en prod, non ?
-
Je pense que c'est AW qui gère le VXLAN directement sur ses équipements. Je laisse Hugues confirmer, je n'ai fait que répondre à ta question.
-
Je confirme c'est Appliwave qui nous libre en VxLAN
-
Je confirme c'est Appliwave qui nous libre en VxLAN
Mais si c'est Appliwave qui vous livre le VxLAN, cela veut dire que les deux CCR distants doivent savoir gérer le VxLAN aussi non ?
Si on suit la topologie, les deux CCR sont considérés alors comme des "CE" du point de vue d'Appliwave.
-
Non pour nous c'est un L2 classique
-
Une petite remarque pour les équipes MilkyWan:
Je trouve dommage de ne pas faire pointer "www.milkywan.fr" vers votre site. Je me suis fait avoir récemment en tapant l'adresse directement.
C'est sans doute très facile à corriger pour vous.
A vous de voir.
Leon.
-
Cela a du être modifié suite a des attaques DDOS.
Il faudrait mettre un simple CNAME qui pointe vers la racine pour suivre les évolutions IP.
-
C'est un truc de vieux le www ;)
Il n'y en a jamais eu et il n'y en aura jamais, aucun intérêt à part pour les personnes qui veulent taper le site web sans utiliser Google ou l'historique du navigateur, ce qui, convenons en, ne concerne pas grand monde.
-
Et bim, la nouvelle génération chamboule tout :o
-
Un peu de lecture ;) (https://www.yes-www.org/why-use-www/)
-
C'est un truc de vieux le www ;)
Si tu nous traites de vieux le gamin, on va te remonter les bretelles ;)
-
Un peu de lecture ;) (https://www.yes-www.org/why-use-www/)
Rien d'utile dans notre cas ^^
-
C'est un truc de vieux le www ;)
Il n'y en a jamais eu et il n'y en aura jamais, aucun intérêt à part pour les personnes qui veulent taper le site web sans utiliser Google ou l'historique du navigateur, ce qui, convenons en, ne concerne pas grand monde.
Donc je me classe à la fois dans "les vieux" (J'ai le même age que Vivien, c'est dire si je suis vieux LOL), et dans les "quelques personnes qui tapent l'adresse des sites web directement".
J'assume parfaitement ! ;)
Perso, j'essaye au maximum de taper à la main les adresses des sites pour 2 raisons:
* ça exerce la mémoire de retenir tous les sites qui m'intéressent. C'est comme au début des téléphones portables, je faisais exprès de ne pas utiliser la mémoire du téléphone, et de toujours taper les numéros à la main.
* ça évite le phishing. Même avec une recherche Google, il arrive que (temporairement le plus souvent, le temps que Google réagisse) les résultats de recherchent donne des sites pirates assez crédibles. Certes, le risque de phishing avec MilkyWan est faible, vu l'audience.
Voilà, c'est un choix, c'est une habitude que j'ai prise; à tort ou à raison...
Leon.
-
Taper l'adresse directement évite aussi :
- de cliquer sur un résultat sponsorisé sur le moteur de recherche, et donc de te tromper de site ou de faire payer les services de Google à ton fournisseur
- de faire une recherche sur un moteur de recherche, qui génère en temps de traitement machine (clients et serveurs), calcul, et transports de données quelques grammes de Co2 (toutes les actions à tous les niveaux comptes) + une usure de tout ces équipements qui est inutile quand tu connais l'URL.
=> Que de bonnes raisons de taper directement sur une URL.
-
Taper l'adresse directement évite aussi :
- de cliquer sur un résultat sponsorisé sur le moteur de recherche, et donc de te tromper de site ou de faire payer les services de Google à ton fournisseur
- de faire une recherche sur un moteur de recherche, qui génère en temps de traitement machine (clients et serveurs), calcul, et transports de données quelques grammes de Co2 (toutes les actions à tous les niveaux comptes) + une usure de tout ces équipements qui est inutile quand tu connais l'URL.
=> Que de bonnes raisons de taper directement sur une URL.
oui et non, en tapant directement milkywan.fr dans la barre d'adresse, par défaut ca va se faire compléter par un https:// et sans passer par un moteur de recherche... si par contre la personne ne tape que milkywan, ok, la on se tape x requêtes inutiles...
j'avais aussi le reflexe de taper le www. mais par la force des choses, j'évite maintenant :D c'est juste une évolution des usages, mais fondamentalement taper "www.milkywan.fr" ou juste "milkywan.fr" ca revient au même, et c'est même plus rapide et moins fatigant xD
-
- de cliquer sur un résultat sponsorisé sur le moteur de recherche, et donc de te tromper de site ou de faire payer les services de Google à ton fournisseur
On est en 2021, adblock ^^
- de faire une recherche sur un moteur de recherche, qui génère en temps de traitement machine (clients et serveurs), calcul, et transports de données quelques grammes de Co2 (toutes les actions à tous les niveaux comptes) + une usure de tout ces équipements qui est inutile quand tu connais l'URL.
Oui, et il ne faut surtout pas oublier de vider sa boite mail :)
-
Adblock ne bloque pas les liens sponsorisés chez moi, sur Firefox.
Supprimer des vieux mails sur Gmail par exemple consomme de l'énergie en allant fouiller dans du cold storage de Google. Probablement plus que de les laisser en place.
-
Tu as sûrement le mauvais Adblock, installe uBlock origin ;)
-
Je comprends pas très bien pourquoi passer par Appliwave puis Milkywan puis repasser par Appliwave et enfin Milkywan, cf :
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| MKT-GW.lan - 0 | 4 | 4 | 0 | 0 | 0 | 0 |
| 145.239.153.15 - 0 | 4 | 4 | 7 | 7 | 8 | 8 |
| 145.239.153.151 - 0 | 4 | 4 | 8 | 8 | 8 | 8 |
| be51.par-gsw-pb2-nc5.fr.eu - 0 | 4 | 4 | 8 | 62 | 129 | 53 |
| 10.200.2.0 - 0 | 4 | 4 | 8 | 8 | 9 | 8 |
| Request timed out. - 100 | 1 | 0 | 0 | 0 | 0 | 0 |
| 10.200.2.0 - 0 | 4 | 4 | 8 | 8 | 8 | 8 |
| 10.200.2.71 - 0 | 4 | 4 | 8 | 14 | 31 | 31 |
| appliwave-dc3.par.franceix.net - 0 | 4 | 4 | 8 | 8 | 9 | 8 |
|lo0.ccr2004.edge.dc2.bb.ip4.milkywan.net - 0 | 4 | 4 | 8 | 8 | 9 | 8 |
|milkywan.rbgp1-10g.ven.lyon.france.as200780.net - 0 | 4 | 4 | 18 | 18 | 19 | 19 |
|te1.rb4011.col.vnx.infra.ip4.milkywan.net - 0 | 4 | 4 | 18 | 18 | 19 | 19 |
| lafibre.cust.milkywan.net - 0 | 4 | 4 | 19 | 19 | 20 | 20 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
-
C'est un simple traceroute asymétrique, le trafic est en hot potato, donc entre au plus proche du réseau Appliwave, donc par Paris et sort au plus proche du réseau MilkyWan, donc à Venissieux
-
C'est un simple traceroute asymétrique, le trafic entre par Paris et sort par Venissieux.
D'accord mais que fait un routeur d'Appliwave entre DC2 et Vénissieux ?
Bizarre...
-
C'est pas un routeur d'appliwave, c'est un routeur de milkywan qui répond avec son adresse d'interco vers appliwave.
-
En tout cas depuis Orange, il y a du mieux maintenant :
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| MKT-GW.lan - 0 | 9 | 9 | 0 | 0 | 0 | 0 |
| 80.10.235.21 - 0 | 9 | 9 | 0 | 0 | 1 | 1 |
| ae111-0.nclyo202.rbci.orange.net - 0 | 9 | 9 | 0 | 0 | 1 | 1 |
| ae42-0.nrlyo202.rbci.orange.net - 0 | 9 | 9 | 0 | 1 | 4 | 1 |
| ae40-0.nrlyo201.rbci.orange.net - 0 | 9 | 9 | 1 | 2 | 6 | 6 |
| ae43-0.nolyo101.rbci.orange.net - 0 | 9 | 9 | 1 | 1 | 1 | 1 |
| 193.252.227.98 - 0 | 9 | 9 | 1 | 1 | 1 | 1 |
| appliwave.ly1-1.hopus.net - 0 | 9 | 9 | 1 | 1 | 1 | 1 |
|lo0.ccr2004.edge.vnx.bb.ip4.milkywan.net - 0 | 9 | 9 | 0 | 0 | 1 | 1 |
|te1.rb4011.col.vnx.infra.ip4.milkywan.net - 0 | 9 | 9 | 0 | 0 | 1 | 1 |
| lafibre.cust.milkywan.net - 0 | 9 | 9 | 2 | 2 | 3 | 2 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)
-
Du mieux ? Pas de changement du routage IN ou OUT depuis Mars 2021 (passage de AW-Hopus à Fiberway-OTI pour éviter de faire payer plus cher a julien).
-
C'est pas un routeur d'appliwave, c'est un routeur de milkywan qui répond avec son adresse d'interco vers appliwave.
Ok d'accord pour le reverse, mais c'est quand même une IP Appliwave en plein milieu du réseau Milkywan.
Normalement c'est sur les BR/Edge, pas à l'intérieur.
C'est pas habituel.
-
Du mieux ? Pas de changement du routage IN ou OUT depuis Mars 2021 (passage de AW-Hopus à Fiberway-OTI pour éviter de faire payer plus cher a julien).
Avant c'était Lyon -> Paris -> Lyon.
Orange ne passait par Hopus Lyon avec Appliwave, mais sur Hopus Appliwave DC3.
-
Normalement c'est sur les BR/Edge, pas à l'intérieur.
Ça tombe bien, c'est un routeur Edge qui répond
Orange ne passait par Hopus Lyon avec Appliwave, mais sur Hopus Appliwave DC3.
Ça passe par Lyon depuis qu'on a remis l'interco en place, fin 2020.
-
A noter que ce n'est pas parce qu'on envoie à Appliwave au plus proche qu'Orange annonce au plus proche :
(https://pix.milkywan.fr/KJ9rX8jC.png)
-
J'ai cru voir un
NCS 5500 en dessous du CCR, donc un autre client du DC :
(https://pix.milkywan.fr/QCBrWlQj.jpg)
Les baies ne sont pas modulables pour pouvoir être fermées ?
Si le matériel de tout le monde est à l'air libre comme ça, ça craint...
D'ailleurs il n'y a même pas 1U de séparation entre.
-
C'est un arista d'Appliwave, on s'entend bien t'sais :)
-
C'est un arista d'Appliwave, on s'entend bien t'sais :)
Un 7280SR, pardon.
-
Un SR2K surtout
-
Oui je parlais de la Serie.
-
Oui mais en l'occurence les SR et les SR2K ont une face très différente ;)
-
Donc c'est lui qui fournit le VXLAN ?
Je présume qu'a DC2 c'est pareil ? Un Arista puis VXLAN vers CCR ?
CCR VNX <-Bridge VLAN-> <-SR2K VNX-> <-VXLAN dans MPLS ?-> <-SR(2K) DC2/TH2-> <-Bridge VLAN-> CCR DC2/TH2
| |
|------------------------------------------------------<--ETH/L2-->---------------------------------------------------|
-
Notre nouveau bébé, installé à DC2, pour remplacer un Mikrotik CCR2004 !
(https://pix.milkywan.fr/QdhbeX2o.jpeg)
Plus de packet loss, de l'OSPFv3 qui marche, un bon OS... Je suis heureux :-*
Et il mange déjà quelques Gbit/s de trafic :
(https://pix.milkywan.fr/R1FoN6vC.png)
-
L'extermination des Mikrotik continue :)
-
Je pense que c'est beaucoup plus parlant, avec un smokeping. On voit bien un avant-après, preuve en est que le routage hardware fait toute la différence.
Source : https://x.com/huguesdelamure/status/1446937267898040324
-
CQFD oui :)
-
L'extermination des Mikrotik continue :)
Quand je pense qu'Hugues m'a dit récemment (quand je me suis abonné chez MW) que mon routeur Ubiquiti c'était de la bouse, et qu'il valait mieux mettre un Mikrotik, si j'avais su qu'il retournerai sa veste aussi rapidement, j'aurai mis un Arista directement ;D ;D ;D
-
Mikrotik c'est excellent en CPE, c'est ce que j'ai chez moi, nos routeurs de collecte sont également en majorité des mikrotik.
Par contre, en routeur de coeur de réseau, ça montre vite ses limites, c'est tout :) Je le répète depuis 4 ans au moins, pour bosser sur du Mikrotik, du Cisco, de l'Arista, du Brocade, etc...
-
Du coup, on est en train de remplacer tout le coeur de réseau en Mikrotik par du matos plutôt sympa :
CCR2004 -> Arista 7050SX (ça, vous saviez)
CCR1036 -> Juniper MX80 (!!)
On ajoute aussi un ASR1002 à Maxnod pour redonder les clients FTTH/xDSL livrés à CBO
Et du coup, vu que les ASR, le MX et les Arista sont compatibles, on va monter un backbone VxLAN/EVPN sur toute la france d'ici quelques semaines (Oui, même Rennes qu'on va passer en RouterOS7 pour la peine !)
Ah et j'oubliais : On ouvre une nouvelle ville en France et on passe nos intercos 25G avec Appliwave en 40G !
Voilà voilà, from 3 routeurs dans ma chambre to pulvériser des culs ;)
-
Bonjour Milkywan,
Est-ce normal que vous n'annonciez que 3 préfixes sur les RS de FranceIX Paris (et Marseille) ? C'est un choix pour tout faire passer par l'anti-DDoS ?
-
On est en train de tout refaire, les annonces que tu vois aujourd'hui ne sont pas définitives.
-
Quel réseau !
-
On est en train de tout refaire, les annonces que tu vois aujourd'hui ne sont pas définitives.
Merci :)
-
J'ai séparé le hors-sujet sur Full view ou mettre une route par default sur un transitaire ? (https://lafibre.info/transit-ip/full-view/)
-
Merci :)
Hop, c'est de nouveau annoncé :)
J'ai séparé le hors-sujet sur Full view ou mettre une route par default sur un transitaire ? (https://lafibre.info/transit-ip/full-view/)
merci !
-
Hop ! Un petit Juniper MX80 à Lille ! :)
(https://pix.milkywan.fr/BbxdSj3j.jpg)
-
Hop ! Un petit Juniper MX80 à Lille ! :)
(https://pix.milkywan.fr/BbxdSj3j.jpg)
Donc bientôt disponible pour qui dans le coin de Lille ?
-
On est déjà dispo dans le 59/62 depuis quelques mois, mais en l'occurence, ce routeur est destiné au peering sur LillIX, pour le moment il n'est pas prévu de collecte en locale, elle n'existe pas chez Axione :(
-
On est déjà dispo dans le 59/62 depuis quelques mois, mais en l'occurence, ce routeur est destiné au peering sur LillIX, pour le moment il n'est pas prévu de collecte en locale, elle n'existe pas chez Axione :(
Je ne suis pas chez Axione mais chez Xp Fibre, attendons donc. Mais bon au moins ça fait un peering plus "local" pour ceux du coin.
-
Toulouse !
(https://pix.milkywan.fr/eYOavkLk.jpeg)
Du coup, on dit pain au chocolat, ou chocolatine ? ::)
-
Du coup, on dit pain au chocolat, ou chocolatine ? ::)
(https://www.chocoblast.fr/wp-content/uploads/chocolatine-vs-pain-au-chocalat-772x467.jpg)
:P
-
Toulouse !
(https://pix.milkywan.fr/eYOavkLk.jpeg)
Du coup, on dit pain au chocolat, ou chocolatine ? ::)
Chocolatine, bien sûr ;D
Où est-ce que vous êtes installés...?
Je profite de ce message pour féliciter tous les membres de ce beau projet MilkyWan. Je comprends pas tout mais j'admire les efforts, l'abnégation, l'engagement... :D
-
Hop ! Un petit Juniper MX80 à Lille ! :)
(https://pix.milkywan.fr/BbxdSj3j.jpg)
Tu as combien de RAM dessus ?
Chez nous ils sont pas très stable si tu leur pousse des full view avec seulement 2 Go de RAM.
-
Tous les modèles de MX80 ont la même quantité de ram ^^
-
hello!
j'ai remarqué ce matin que pour sortir vers l'AS15169 (google) en ipv4, je passe par DC2 et ensuite VNX
Il n'y a pas une route plus courte? ;)
-
On a choisi de router Google par LyonIX, et ce depuis 2018 :)
Pour des raisons financières en premier lieu
-
On a choisi de router Google par LyonIX, et ce depuis 2018 :)
Pour des raisons financières en premier lieu
Merci Hugues !
-
Ça va faire plaisir à @Leon ça ::)
(https://pix.milkywan.fr/tC6oI35p.png)
-
Ça va faire plaisir à @Leon ça ::)
Merci Hugues. Si Milkywan allume ses propres lambda, effectivement, ça me fait plaisir!
Reste à savoir sur quel "MAN" ça sera déployé : Paris? Lyon?
Leon.
-
Et pourquoi pas les deux ? ;)
-
J'ai mis à jour le post en première page ;)
-
Merci Hugues.
Comme tu le sais, une grosse partie des gens n'ont pas d'IPv6, donc pas accès à ta Weather-Map, pour voir les changements effectués.
Leon.
-
une grosse partie des gens n'ont pas d'IPv6
Il est activé par défaut sur iOS et Android en mobile chez 3 FAI sur 4, et activable chez le dernier
En xDSL/FTTH, il est activé par défaut chez Free et Orange…
Du coup je considère que c’est plus une histoire de volonté que de possibilité :D
-
Il est activé par défaut sur iOS et Android en mobile chez 3 FAI sur 4, et activable chez le dernier
En xDSL/FTTH, il est activé par défaut chez Free et Orange…
Du coup je considère que c’est plus une histoire de volonté que de possibilité :D
Pas tellement
Les abonnés bbox FTTH n’en ont plus depuis presque 1 mois…
-
Suffit de passer en 4G !
En vrai c’est surtout pour les abonnés la weathermap, donc ça fait sens :)
-
Il est activé par défaut sur iOS et Android en mobile chez 3 FAI sur 4, et activable chez le dernier
En xDSL/FTTH, il est activé par défaut chez Free et Orange…
Du coup je considère que c’est plus une histoire de volonté que de possibilité :D
Volonté de quoi?
Regarde ma signature. J'ai un accès SFR FTTLA...
Je te laisse avec ta politique élitiste. C'est ton choix.
Leon.
-
Volontariste, pas élitiste ;)
Tu peux toujours utiliser TOR ou n'importe quel VPN qui a de l'IPv6.
À un moment, c'est pas en mettant du dual stack partout qu'on fera avancer v6 !
-
Hugues suggérait de mettre ton mobile en mode modem (le seul cas où cela ne marche pas c'est quelques MVNO et Free sur iPhone).
-
Hugues suggérait de mettre ton mobile en mode modem (le seul cas où cela ne marche pas c'est quelques MVNO et Free sur iPhone).
Oui, j'ai bien compris.
Mais je ne vois pas l'intérêt de se faire chier à faire ce genre de manip juste pour consulter une Weather-Map.
Si MilkyWan veut rester élitiste, avec des outils de gestion IPv6 only, c'est leur choix. J'espère de tout coeur que ce choix est partagé entre l'ensemble des membres/adhérents de MilkyWan.
Leon.
-
En même temps si tu as besoin d'accéder a notre weathermap, notre looking glass, etc... mais que tu n'as pas d'IPv6, y'a un souci :)
Tu peux trouver notre weathermap ici : https://lafibre.info/reso-liain/milkywan-premier-fai-a-proposer-du-1gbits-sur-le-reseau-active-du-siea/, je la mets à jour quand il y'a des évolutions notables.
-
Sinon, via proxy ... :p
https://fi.hideproxy.me/go.php?u=https%3A%2F%2Fweathermap.milkywan.fr%2Fmilkywan.html&b=4&f=norefer
-
Bref, y'a plein de moyens d'y accéder si tu ne veux vraiment pas avoir d'ipv6 via un FAI de qualité ;)
-
Ce n'est pas une question d'être élitiste ou non. Sacrifier une IPv4 publique juste pour afficher la weathermap me parait pas être une bonne idée.
Sinon moi et mon RIB, nous nous tenons à la disposition de SFR pour déployer IPv6 sur l'infra câble, on l'a fait d'un claquement de doigt.
-
Ce n'est pas une question d'être élitiste ou non. Sacrifier une IPv4 publique juste pour afficher la weathermap me parait pas être une bonne idée.
Au dela de ça, tous nos outils internes sont IPv6 Only, le VPN interne est IPv6... On publie la weathermap parce qu'on est sympa, c'est pas un service en soi
-
Ce n'est pas une question d'être élitiste ou non. Sacrifier une IPv4 publique juste pour afficher la weathermap me parait pas être une bonne idée.
Y'a jamais eu besoin de sacrifier une IP (v4 ou v6) publique pour publier un site web. Le virtualhosting des serveurs webs les plus répandus sert précisément à éviter ça.
Perso un truc qui me dérange un peu, c'est d'avoir sur les pages pros d'une société un lien qui ne fonctionne pas (même pas un petit message "vous ne pouvez pas voir ce site car votre connexion ne le permet pas"): *ça*, pour le client lambda qui s'informe, ça fait pas très bonne impression.
Mais bon, mes 2 sous :)
-
Ça tombe bien, on n'est pas une société et ce n'est pas une page pro :)
-
Nous sommes maintenant présents sur France-IX Toulouse, avec en plus un Remote Peering vers Paris :)
(https://pix.milkywan.fr/qDeO6d5P.png)
-
Tiens, je me rends compte que j'ai oublié de parler ici du recâblage de la baie d'HosTELyon !
On a *tout* refait :
- Changement des jarretières par de l'Uniboot
- Nouveaux câbles RJ45 pour le management
- Optiques de chez PureOptics
- Nouveau routeur de coeur Arista 7050QX 32x40G
- Câbles électriques bleu/rouge de chez fs.com
- Des passe câbles
Bref, on a vraiment cleané le plus possible !
Petit avant/après :
(https://pix.milkywan.fr/8QSYAix1.jpeg)
(https://pix.milkywan.fr/0lGBjDYP.jpeg)
-
Et on a migré cet après midi notre routeur de collecte de Venissieux, finito Mikrotik, bonjour Cisco ASR ! À terme, on n'aura plus que ça en collecte.
Je n'en ai pas parlé ici mais on a déménagé de baie à Venissieux, Appliwave ayant pris une baie en propre. Nous sommes passés en 2x40G avec eux, 40G pour les L2L (donc on a 40G vers Paris maintenant) et 40G pour le transit IP.
Avant :
(https://pix.milkywan.fr/cJNELMSc.jpeg)
Après :
(https://pix.milkywan.fr/RQqgPgY1.jpeg)
-
Et on a migré cet après midi notre routeur de collecte de Venissieux, finito Mikrotik, bonjour Cisco ASR ! À terme, on n'aura plus que ça en collecte.
Sauf indiscrétion, qu'est ce qui a motivé la décision ?
Capacité ? Fiabilité ? Fonctionnalités ?
Sur le papier les nouveautés type CCR2216 (deux ports 100G) semblent intéressantes... pas tant que ça ?
-
C’est pas comparable, tu as plein de limitations sur routeros, et les 2116 n’offloadent quasiment rien (juste le routage, et encore, pas en v6 et pas toutes les routes) la ou un ASR c’est 100% du trafic qui est offload
-
C’est pas comparable, tu as plein de limitations sur routeros, et les 2116 n’offloadent quasiment rien (juste le routage, et encore, pas en v6 et pas toutes les routes) la ou un ASR c’est 100% du trafic qui est offload
Ah oui en effet pas mal de restrictions.
https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading
Le plafond de verre semble atteint de ce côté là...
Même si Mikrotik reste plutôt compétitif pour des usages plus modestes.
-
C’est pas comparable, tu as plein de limitations sur routeros, et les 2116 n’offloadent quasiment rien (juste le routage, et encore, pas en v6 et pas toutes les routes) la ou un ASR c’est 100% du trafic qui est offload
Question bête, les équipements Cisco mit en prod, c'est du reconditionnée pour la plupart ? Ou du neuf avec module proprio ? (je ne crois pas l'avoir vue sur le forum)
-
C’est de l’occasion récupérée ou rachetée à bas prix ;)
-
Tu prends que du matos end of support ?
Aucune mise à jour des IOS ?
-
Avec les smart licences, ça n'existe plus les mises à jour IOS sur du matos pas acheté chez eux avec du support.
Mais on s'en fout un peu non ?
-
Je suppose que ça dépends si tu tombes sur des bogues gênants ou non.
Mais effectivement, le smart account avec le serveur Satellite c'est de la merde mais pas le choix avec Cisco.
-
Au pire y'a des dépôt avec des IOS à jour ::)
mais chut !
-
Ça ne marche plus avec le smart licensing ça
-
Surtout pour Hugues qui a besoin des fonctions de routing.
La plupart des options de routing sont passées dans le smart licensing il me semble.
-
Surtout pour Hugues qui a besoin des fonctions de routing.
La plupart des options de routing sont passées dans le smart licensing il me semble.
Le smart licensing c'est pas quand on demande une image ios à ses pôtes autour d'une bière ?
-
Pas de smart licensing, pas de fonctions L3 c'est tout.
Mais bon ça devient HS là...
-
La porte SIEA est maintenant en 10G au CERN :)
-
La porte SIEA est maintenant en 10G au CERN :)
(https://media.tenor.com/4i_vCC1wVw4AAAAM/homer-simpson-woohoo.gif)
-
Bonjour à tous,
Apparemment, le nouveau POP de MilkyWan dans le datacenter Nexeren (Civrieux, banlieue de Lyon) est actif!
L'expansion continue, bravo.
Vous êtes habitués, voici quelques questions indiscrètes de ma part:
https://x.com/milkywan_net/status/1654933453165453312
Nous sommes maintenant opérationnels dans le datacenter @nexeren
2 à Civrieux dans l'Ain ! Merci @NetSystFR
pour la colocation 😊
[...]
Sur place :
- L2 10G sécurisé via Netsyst
- Collecte 1G de backup vers @Liain01
[...]
On est resté sur une stack classique et éprouvée :
- Arista 7050QX pour le routage/vxlan-evpn
- ASR1001 + SPA 10G pour la collecte FTTH / VPN
Une première question, svp:
Je lis que vous faites du VxLan-eVPN, alors que Hugues disait il y a quelques mois que le réseau était "pur IP".
Je suppose que MilkyWan utilise aussi du VxLAN sur le backbone. Du coup, ça fait du VxLAN over VxLAN quand ça passe par du LAN2LAN AppliWave?
Nous on est en pur IP sur le backbone, on peut utiliser du VxLAN par dessus, mais c'est uniquement si on a besoin de faire passer du traf L2, donc tout ce qui est FTTH, xDSL, VM, VPN, ça ne passe pas par VxLAN non :)
C'est l'avantage selon moi de VxLAN par rapport à MPLS, tu peux très bien faire passer du VxLAN sur un réseau qui n'en fait pas, c'est juste des paquets UDP :)
Ca a donc changé? Vous faites du VXLAN désormais? A quoi vous sert le VXLAN-eVPN ?
L'objectif est de proposer des "LAN2LAN" à vos clients? Ou alors c'est uniquement pour vos besoins internes?
Autre question, je vois que le serveur Lafibre.info est derrière le routeur "a7050qxs.core.lyn". Donc probablement à HosteLyon, et non à Nexeren comme c'était prévu initialement.
10 22 ms 22 ms 22 ms fo36.a7050qxs.edge.th2.bb.ip4.milkywan.net [80.67.167.243]
11 27 ms 26 ms 27 ms fo49.2984.a7050sx.edge.vnx.bb.ip4.milkywan.net [80.67.167.249]
12 26 ms 26 ms 26 ms po2.a7050qxs.core.lyn.bb.ip4.milkywan.net [80.67.167.229]
13 26 ms 27 ms 33 ms lafibre.info [80.67.167.77]
Hello, Ca veut dire que le serveur Lafibre.info sera à Nexeren? Ca sera un nouveau POP de MilkyWan? Pour assurer la collecte SIEA redondante, je suppose, en remplacement de Maxnod. Je vois ça sur la Weathermap MilkyWan.
Pourquoi ne pas mettre le serveur Lafibre.info HosteLyon, où MilkyWan héberge déjà pas mal de serveurs? Vous êtes full à HosteLyon?
Pas spécialement de raison, juste que nexeren est a coté de chez moi et qu'on y monte un petit POP chez NetSyst oui :)
Est-ce que vous confirmez que le serveur Lafibre.info est à HosteLyon? Ou alors c'est juste les reverse-DNS des routeurs qui ne sont pas encore à jour?
Merci d'avance pour les réponses.
Leon.
-
Hello,
Comme je t'écrivais en Janvier (et le réseau n'a pas changé de design depuis) VxLAN c'est sur une fabric IP, donc le réseau est toujours pur IP, VxLAN c'est simplement des paquets UDP.
VxLAN peut servir a livrer des L2, ou bien des intercos privées (VRF), ou encore du transit si le routeur local n'a pas la full table (v6 et la pseudo full en v4). Seuls les Edge ont les routes externes chez nous.
Concernant Lafibre, il est bien à Hostelyon, dans une baie MilkyWan, et pas chez Netsyst comme initialement prévu :)
-
Comme je t'écrivais en Janvier (et le réseau n'a pas changé de design depuis) VxLAN c'est sur une fabric IP, donc le réseau est toujours pur IP, VxLAN c'est simplement des paquets UDP.
VxLAN peut servir a livrer des L2, ou bien des intercos privées (VRF), ou encore du transit si le routeur local n'a pas la full table (v6 et la pseudo full en v4). Seuls les Edge ont les routes externes chez nous.
Merci pour la réponse.
Comme je ne suis pas du tout spécialiste du sujet, j'essaye de comprendre avec quelques questions complémentaires, si tu le veux bien :
- ça veut dire que les routeurs "core" ne connaissent que les adresses IP internes MilkyWan, c'est bien ça? Donc routeur capables de gros débit, mais avec des tables de routage les plus petites possibles?
- Ca veut dire que les interconnexions externes (peering ou transit) rattachées à un "routeur core" sont passées dans un "tunnel VxLAN" vers le "routeur edge" le plus proche, même s'il n'est pas forcément sur le même site? Par exemple, quel "routeur edge" digère le transit FiberWay DC2Scale? TH2? DC2?
- On est d'accord que le "routeur edge" de rattachement d'un transit/peering "déporté" est unique, invariant, tout le temps le même, même en cas de défaillance réseau?
Leon.
-
- ça veut dire que les routeurs "core" ne connaissent que les adresses IP internes MilkyWan, c'est bien ça? Donc routeur capables de gros débit, mais avec des tables de routage les plus petites possibles?
Oui
C'est vrai en général, mais pas chez nous :)
Les routeurs Core et Edge sont identiques (Arista 7050X), la différence réside dans la configuration de leur TCAM :
- Les routeurs Core ont une TCAM qui supporte moins de routes mais qui gère uRPF (Anti-Spoof IP)
- Les routeurs Edge ont une TCAM qui supporte le maximum de routes mais pas uRPF
- Ca veut dire que les interconnexions externes (peering ou transit) rattachées à un "routeur core" sont passées dans un "tunnel VxLAN" vers le "routeur edge" le plus proche, même s'il n'est pas forcément sur le même site? Par exemple, quel "routeur edge" digère le transit FiberWay DC2Scale? TH2? DC2?
Absolument, FBW arrive à TH2, mais on peut le déplacer en quelques mlnutes si on en a besoin un jour
- On est d'accord que le "routeur edge" de rattachement d'un transit/peering "déporté" est unique, invariant, tout le temps le même, même en cas de défaillance réseau?
Pas forcément, tu peux demander à ton transitaire de te fournir sur le même port un /29 / /64 et quatre sessions BGP au lieu de deux, libre a toi de faire atterir le VxLAN sur deux routeurs et de faire ta redondance comme ça.
-
Merci pour ça. C'est très clair. Encore une question:
Les routeurs Core et Edge sont identiques (Arista 7050X), la différence réside dans la configuration de leur TCAM :
- Les routeurs Core ont une TCAM qui supporte moins de routes mais qui gère uRPF (Anti-Spoof IP)
- Les routeurs Edge ont une TCAM qui supporte le maximum de routes mais pas uRPF
Je vois une "collecte" qui arrive directement sur un routeur "edge", sans routeur de collecte attaché en direct.
Il s'agit de la collecte "Altitude Telecom" à TH2.
Ca veut dire qu'il n'y a pas d'anti-spoof-IP sur cette collecte, vu que c'est un routeur Edge?
Ou alors cette collecte est gérée sur un autre site qui n'est pas à TH2? Genre Croissy-Beaubourg ou DC2Scale?
Leon.
-
Non, pas d'anti spoof, mais ce n'est pas un problème car Altitude le fait déjà pour nous (collecte L3 + BGP) ;)
-
Comme je t'écrivais en Janvier (et le réseau n'a pas changé de design depuis) VxLAN c'est sur une fabric IP, donc le réseau est toujours pur IP, VxLAN c'est simplement des paquets UDP.
VxLAN peut servir a livrer des L2, ou bien des intercos privées (VRF), ou encore du transit si le routeur local n'a pas la full table (v6 et la pseudo full en v4). Seuls les Edge ont les routes externes chez nous.
Salut.
Qu'est-ce que tu appelles "interco privées (VRF)", stp?
C'est pour offrir des services "VPN L3", routé, où le client a son propre adressage IP ?
Avec des routeurs virtuels configurables par le clients sur les sites où se "terminent" chacun de ses services? Via une API client dédiée?
C'est accessible sur tous vos services? Y compris FTTH, VPN, VM, housing?
Autre question qui n'a rien à voir: est-ce que vous acceptez les "jumbo frames" sur votre réseau? Je parle bien en restant sur votre réseau. Entre housing et VM par exemple. Voire sur FTTH?
Leon.
-
Qu'est-ce que tu appelles "interco privées (VRF)", stp?
C'est pour offrir des services "VPN L3", routé, où le client a son propre adressage IP ?
Oui. Mais c'était un exemple d'usage, pas un service qu'on fournit. Sur du grand public ça n'a pas vraiment de sens.
Autre question qui n'a rien à voir: est-ce que vous acceptez les "jumbo frames" sur votre réseau? Je parle bien en restant sur votre réseau. Entre housing et VM par exemple. Voire sur FTTH?
Oui, MTU 9000, mais pas sur FTTH, MTU 1500.
-
Petite question en rapport au trafic vidéo et autre: y a-t-il des caches CDN sur votre AS? (Par exemple: OpenConnect, Akamai et autres?)
(J’ai recherché dans le forum mais n’ai pas trouvé le sujet mentionné — désolé d’avance si j’ai loupé quelque chose !)
-
Petite question en rapport au trafic vidéo et autre: y a-t-il des caches CDN sur votre AS? (Par exemple: OpenConnect, Akamai et autres?)
Je doute qu'il y ait assez d'abonnés et donc de trafic pour que ça se justifie.
De mémoire il y a des caches CDN au niveau du CERN Internet eXchange Point (CIXP) avec lequel MilkyWan a une interconnexion, je crois me souvenir que c'est Akamai mais je suis plus tout à fait sûr.
Pour le reste ça doit passer par les transitaires.
-
Si c'est pas sur la weathermap, c'est que ça n'existe pas :)
-
Les "caches" les plus populaires chez les FAI sont Netflix et Google.
Il faut un trafic minimum de 10 Gb/s pour mettre un cache avec un acteur et que cela soit intéressant (l'hébergement des serveurs est à la charge de l'opérateur).
Cela n'apporte pas de gain en termes de qualité de service vs un peering local.
-
Les "caches" les plus populaires chez les FAI sont Netflix et Google.
Il faut un trafic minimum de 10 Gb/s pour mettre un cache avec un acteur et que cela soit intéressant (l'hébergement des serveurs est à la charge de l'opérateur).
Cela n'apporte pas de gain en termes de qualité de service vs un peering local.
Encore faut-il qu'il y ait un peering local ; dans le cas de Netflix justement (qui propose son propre CDN OpenConnect aux FAI), le cache est habituellement utilisé uniquement pour les abonnés du FAI dans lequel il est deployé, ce qui implique que si pas de cache OpenConnect accessible → le contenu est desservi depuis le transit. La latence est impactée (ce qui n'est pas dramatique dans le cas de trafic SVOD), et le bitrate est généralement significativement inférieur.
Après, je n'avais pas vu effectivement le nombre d'abonnés actuels de Milkywan, donc je comprends tout à fait que ce ne soit pas (encore?) possible.
PS: Pour l'anecdote, sur le sujet du traffic CDN en France en 2023 (example récent pour un FAI), le top 5 en trafic:
- GGC (Google)
- Akamai
- OpenConnect (Netflix)
- Facebook
- CloudFront (AWS)
-
le bitrate est généralement significativement inférieur.
Est-ce qu'on est vraiment sûr de ça quand le FAI en question à des transits correctement dimensionnés ?
-
Est-ce qu'on est vraiment sûr de ça quand le FAI en question à des transits correctement dimensionnés ?
non :P
-
Est-ce qu'on est vraiment sûr de ça quand le FAI en question à des transits correctement dimensionnés ?
Pour l’instant je n’ai pas vu de FAI pour lequel ça n’est pas le cas (et je travaille avec pas mal de FAI là-dessus).
J’attends de pouvoir voir l’exception une fois que je peux utiliser MilkyWan :-).
-
Il faut bien comprendre à quoi sert un cache. Il n'est pas là pour améliorer la qualité de service (si si, vraiment), il est là pour faire économiser du pognon aux différents acteurs :
- Aux FAI en leur évitant de payer du transit et/ou devoir surdimensionner leurs intercos externes, voir de transporter le trafic à l'échelle Nationale
- À Netflix en leur faisant économiser de la bande passante, voir points ci dessus.
Deux choses à noter :
- La latence est un point complètement négligeable dans le streaming vidéo. Sur un OS moderne, un contenu chargera de manière similaire avec 1ms de latence qu'avec 100ms. C'est d'ailleurs pour ça que vous pouvez regarder youtube en 4K dès lors que vous êtes en 4G.
- un Netflix ou un Google va toujours chercher a proposer la qualité maximale à leurs abonnés, que ce soit via un cache, via un peering privé, un peering direct, un peering via les RS d'un IXP ou via du transit. La seule limite est une éventuelle congestion sur le chemin, et ce peu importe le "tuyau" emprunté.
Pour l’instant je n’ai pas vu de FAI pour lequel ça n’est pas le cas (et je travaille avec pas mal de FAI là-dessus).
Ça tombe bien, moi aussi je bosse avec (et pour) pas mal de FAI. Il n'y a aucune forme de sélectivité du genre "ce FAI aura droit à la 4K et pas celui là", premièrement parce que c'est complètement stupide sur un réseau construit comme l'est "internet", ensuite parce que ce serait une pratique discriminatoire et contraire à la neutralité du net, et enfin parce que ça ne sert personne : Netflix n'a aucun intérêt a proposer une expérience dégradée aux clients des petits FAI alors que ces mêmes FAI s'interconnectent généralement gratuitement avec Netflix, ce qui n'est pas le cas des gros.
Bref, c'est un peu long pour dire "bullshit" mais c'est bien la réalité. Et croyez moi que si le moindre abonné se plaignait d'une qualité moindre chez MilkyWan que chez Orange ou Free, j'en serais le premier informé. Mais généralement c'est plutôt l'inverse qui se produit :P
-
Encore faut-il qu'il y ait un peering local ; dans le cas de Netflix justement (qui propose son propre CDN OpenConnect aux FAI), le cache est habituellement utilisé uniquement pour les abonnés du FAI dans lequel il est deployé, ce qui implique que si pas de cache OpenConnect accessible → le contenu est desservi depuis le transit. La latence est impactée (ce qui n'est pas dramatique dans le cas de trafic SVOD), et le bitrate est généralement significativement inférieur.
Pour du streaming, à l'échelle de la France, sur un réseau non saturé, avec des interconnexions non saturé, la latence (qui ne dépassera pas les 30ms) n'a absolument aucune importance. Et cette latence raisonnable ne dégradera pas le bitrate, contrairement à ce que tu dis.
Comme l'a dit Hugues, héberger du cache/CDN côté FAI, c'est "juste" une question de
- optimisation des couts
- dimensionnement d'interconnexions et de backbone, pour les 2 types d'acteurs : gros diffuseur de contenu et FAI.
Leon.
-
D'ailleurs...je n'ai jamais vu un utilisateur se plaindre d'un service dégradé ou indisponible quand le cache GGC, Amazon, FB ou Netflix a été mis offline pour maintenance. Et oui, ca arrive très régulièrement! Pourtant, aucun utilisateur ne le remarque!
-
Pour l’instant je n’ai pas vu de FAI pour lequel ça n’est pas le cas (et je travaille avec pas mal de FAI là-dessus).
J’attends de pouvoir voir l’exception une fois que je peux utiliser MilkyWan :-).
C'est un peu faux ça. Quand tes perrings sont correctement dimensionnés. Tu n'as aucun souci.
-
D'ailleurs...je n'ai jamais vu un utilisateur se plaindre d'un service dégradé ou indisponible quand le cache GGC, Amazon, FB ou Netflix a été mis offline pour maintenance. Et oui, ca arrive très régulièrement! Pourtant, aucun utilisateur ne le remarque!
T'as déjà eu une freebox dans les mains ? :D
-
Ça tombe bien, moi aussi je bosse avec (et pour) pas mal de FAI. Il n'y a aucune forme de sélectivité du genre "ce FAI aura droit à la 4K et pas celui là", premièrement parce que c'est complètement stupide sur un réseau construit comme l'est "internet", ensuite parce que ce serait une pratique discriminatoire et contraire à la neutralité du net, et enfin parce que ça ne sert personne : Netflix n'a aucun intérêt a proposer une expérience dégradée aux clients des petits FAI alors que ces mêmes FAI s'interconnectent généralement gratuitement avec Netflix, ce qui n'est pas le cas des gros.
Attention, ça n’est pas ce que je disais ; je ne parlais pas d’un effet par design mais plus d’une conséquence des aléas de congestion sur ces liens de transit. Il n’en reste pas moins que les bitrates mesurés chez ces FAI sont bien inférieurs en offnet que pour du onnet (en tout cas pour les principaux fournisseurs de contenu, notamment Netflix qui reste le leader en volume — notamment en “primetime”). Je m’arrêterai là et reste disponible pour en parler plus longuement en PM.
-
Ben si tu prends notre exemple, on récupère Netflix via FranceIX à Paris, Netflix est interco en 2x100G avec FranceIX, nous en 2x10G... D'ici a ce que ça sature, y'a un peu de marge :)
-
T'as déjà eu une freebox dans les mains ? :D
oui malheureusement (et je me suis bien lavé les mains aprés ;D), mais tu dis ça par rapport à quoi?
-
Les saturations Netflix chez Free, il y a quelques mois de cela...
-
Il parlait de ses abonnés à lui, pas des abonnés d'un BOFS
-
ah! Je ne savais pas. Mais du coup, ca montre bien que le fait d'avoir des cache Netflix ne résout pas forcément les problèmes de service... La root cause était quoi du coup?
-
Ben si tu prends notre exemple, on récupère Netflix via FranceIX à Paris, Netflix est interco en 2x100G avec FranceIX, nous en 2x10G... D'ici a ce que ça sature, y'a un peu de marge :)
Si on regarde la WeatherMap de MilkyWan, je pense qu'on peut dire que les interconnexions (peering+transit) sont sur-dimensionnées d'un facteur 5 à 10 par rapport au trafic réel aux heures de pointes. Donc effectivement, il y a beaucoup de marge.
Leon.
-
PS: Pour l'anecdote, sur le sujet du traffic CDN en France en 2023 (example récent pour un FAI), le top 5 en trafic:
- GGC (Google)
- Akamai
- OpenConnect (Netflix)
- Facebook
- CloudFront (AWS)
Quelle est la source ?
Aujourd'hui, c'est un grand sujet de discussion eu Europe (cf Corée: le peering payant fait que twitch bride la résolution à 720p (https://lafibre.info/peering/twitch-brider-en-coree/12/)). Je suis intéressé par toutes les sources de données.
L'Arcep publiera les données 2022 mi-juin 2023 sur https://www.arcep.fr/cartes-et-donnees/nos-publications-chiffrees/linterconnexion-de-donnees/barometre-de-linterconnexion-de-donnees-en-france.html
-
Si on regarde la WeatherMap de MilkyWan, je pense qu'on peut dire que les interconnexions (peering+transit) sont sur-dimensionnées d'un facteur 5 à 10 par rapport au trafic réel aux heures de pointes. Donc effectivement, il y a beaucoup de marge.
Leon.
120Gbit/s pour 2,5Gbit/s de trafic réel, soit 48x plus ^^ on est large :p
-
Le ratio est < 3 pour les 4 grands opérateurs Français :
(https://lafibre.info/images/peering/202206_interconnexion_04.webp)
Évolution des capacités installées
(https://lafibre.info/images/peering/202206_interconnexion_07.webp)
-
J'ai séparé la suite de la conversation sur l'évolution du baromètre interconnexion de l'Arcep.
=> Arcep: État des lieux de l'interconnexion en France 2012 => 2021 (https://lafibre.info/peering/interconnexion-2021/msg1016268/#msg1016268)
-
Et hop, du 100G :-* #PTDQ
https://x.com/huguesdelamure/status/1691587447275061313
🚀 Et hop ! Début des upgrades estivales de @milkywan_net
! Jour 1 : SFR Vénissieux ! Bye bye Arista 7050SX et bonjour Arista 7280TR ! Vous avez sous les yeux les premiers 100G de MilkyWan ! 100G de transit + 100G de L2 avec Appliwave ! 🥰 w/ @PingexWasTaken
@Fanfwe
(https://pbs.twimg.com/media/F3m5zanWoAAelEy?format=jpg&name=orig)
(https://pix.milkywan.fr/egRP10Lv.jpeg)
-
C'est beau. Ca me donne envie de résilier mon abonnement juste pour le plaisir de pouvoir se ré-abonner :)
-
Et hop, du 100G
Merci pour l'update.
D'autres upgrade à 100Gb sont prévus?
Est-ce que ça veut dire que vous avez des projets qui nécessitent un réseau plus costaud?
Ou alors les liens se remplissaient vite? Grâce aux abonnés SIEA par exemple? Je n'avais pas l'impression, mais je peux me tromper.
Ou alors tout simplement le tarif était suffisamment raisonnable pour ne pas trop se poser de question?
Leon.
-
D'autres upgrade à 100Gb sont prévus?
Oui, on vient de passer l’interco avec Appliwave à TH2 en 2x100G également
Ou alors tout simplement le tarif était suffisamment raisonnable pour ne pas trop se poser de question?
Voilà :D
On change les routeurs pour passer sur des modèles plus costauds, le hasard fait qu’ils ont des ports 100G, du coup j’ai demandé à Appliwave si je pouvais changer les optiques, et hop :)
-
Fin de notre campagne d'upgrades estivale, on a donc remplacé les trois routeurs de VNX/TH2/DC2 par des Arista 7280TR bien costauds, avec fullview et ports 100G :-*
On a donc monté la capacité ridicule de 600Gbit/s avec Appliwave dont 300G de transit 🤣
Les nouveaux routeurs :
VNX :
(https://pix.milkywan.fr/NlET97N8.jpeg)
TH2 :
(https://pix.milkywan.fr/m57sPy5O.jpeg)
DC2 :
(https://pix.milkywan.fr/SjX5d1PP.jpeg)
-
en tous cas bravo
mais sa doit être cher tout ce matériel
bonne soirée
-
Merci :)
On a remplacé le routeur de Toulouse par un Arista 7050QX il y'a quelques jours :
(https://pix.milkywan.fr/EJXLbGlf.jpeg)
-
Modération : J'ai déplacé le hors sujet sur l'interconnexion d'un FAI au reste d'internet.
C'est ici : https://lafibre.info/peering/comment-un-fai-sinterconnecte-au-reste-dinternet/
-
J’ai mon watcher BGP dans ma boîte qui vient de m’hurler à 17h que AS2027 annonçait des préfixes à moi :( (85.190.88.0/22 entre autres). J’ai pas plus d’infos, peut-être fausse alerte, qu’est-ce qu’il s’est passé ?
-
J’ai mon watcher BGP dans ma boîte qui vient de m’hurler à 17h que AS2027 annonçait des préfixes à moi :( (85.190.88.0/22 entre autres). J’ai pas plus d’infos, peut-être fausse alerte, qu’est-ce qu’il s’est passé ?
Pour les problèmes urgents, je pense que tu as intérêt à utiliser l'adresse fournie sur https://as2027.net/ : "Network Operation Center : noc@milkywan.fr".
-
Alors, je suis pas sur a 100% de mon coup, mais je crois qu'on a réannoncé à divers route-collector (BGP.Tools, HE.net, RIPE RIS) des préfixes avec un AS Path malformé... (le path faisait 2027,AS Privé, 2027)
Donc en gros on a pas réellement hijack mais vu des route-collector ça faisait hijack.
On est en pleine migration de la full table dans une VRF, c'est très complexe et on a eu bcp bcp de soucis, on a toujours pas fini la...
-
Alright, merci pour l’explication !
Bon courage, force et honneur :)
-
Boarf, beau fail quand même, je suis pas fier de moi sur ce coup :(
-
Le site Lafibre.info a été indisponible quelques dizaines de minutes le dimanche 22 PM. C'était à cause de ça?
Leon.
-
C'est lié a la migration oui, pas au route leak
-
Pour plus de détails, le serveur LaFibre.info était parfaitement joignable en IPv4 et le contenu statique était disponible (exemple : images / vidéos).
Le trafic IPv6 était coupé pendant cette migration.
Les pages web du forum ne fonctionnaient pas, car il y a une dépendance au DNS pour l'affichage d'une page (je pense dépendance au reverse DNS) et que les requêtes DNS se font en IPv6 (c'est dommage, vu que je n'ai pas de règle de filtrage en fonction du reverse DNS d'une IP utilisée pour se connecter au forum).
J'ai tenté de basculer les DNS en IPv4, mais j'avais oublié que suite à des DDOS, le trafic UDP est bloqué en IPv4 coté réseau.
-
Merci à tous les 2 pour les détails.
Les pages web du forum ne fonctionnaient pas, car il y a une dépendance au DNS pour l'affichage d'une page (je pense dépendance au reverse DNS) et que les requêtes DNS se font en IPv6 (c'est dommage, vu que je n'ai pas de règle de filtrage en fonction du reverse DNS d'une IP utilisée pour se connecter au forum).
C'est possible d'expliquer un peu plus cette dépendance au DNS, stp? En quoi le forum a besoin de faire des requêtes DNS pour fonctionner?
Leon.
-
Merci à tous les 2 pour les détails.C'est possible d'expliquer un peu plus cette dépendance au DNS, stp? En quoi le forum a besoin de faire des requêtes DNS pour fonctionner?
les logs ?
Est-ce que la looking glass sur lg.milkywan.fr fonctionne toujours ? Je n'arrive plus à l'utiliser (show ip bgp <address> => table vide).
Est-ce que ça pourrait être lié aux changements que vous avez fait dans le routage ? Du style la lg qui tape dans la table du routeur au lieu de la VRF ?
-
Oui c'est lié, on réparera ça quand on aura le temps, on a encore quelques trucs pétés plus urgents :)
-
Merci à tous les 2 pour les détails.C'est possible d'expliquer un peu plus cette dépendance au DNS, stp? En quoi le forum a besoin de faire des requêtes DNS pour fonctionner?
C'est cette fonction : https://support.simplemachines.org/function_db/index.php?action=view_function;id=243
Je viens de la désactiver en cochant une case "Désactiver la recherche du nom d'hôte"
Ceci désactive la recherche du nom de l'hôte, fonction parfois lente sur certains serveurs. Notez que sa désactivation rend le système de bannissement moins efficace.
Vivien.
-
C'est cette fonction : https://support.simplemachines.org/function_db/index.php?action=view_function;id=243
Je viens de la désactiver en cochant une case "Désactiver la recherche du nom d'hôte"
Ceci désactive la recherche du nom de l'hôte, fonction parfois lente sur certains serveurs. Notez que sa désactivation rend le système de bannissement moins efficace.
Si je comprends bien, cette fonction ferait une requête reverse-DNS sur l'IP de chaque utilisateur, c'est bien ça?
Leon.
-
Notez que sa désactivation rend le système de bannissement moins efficace.
Pas quand on peut changer son PTR. Sur IRC c'est pareil, les bans de canaux se font sur le host de l'user qui est dérivé de son PTR. Tu changes ton PTR t'es tranquille à nouveau :)
-
Si je comprends bien, cette fonction ferait une requête reverse-DNS sur l'IP de chaque utilisateur, c'est bien ça?
Oui
Et je n'utilise aucun système de ban dessus.
-
Sur un abo OCEN GP, tu peux pas changer le PTR donc ça reste plus ou moins efficace non ?
-
Sur un abo OCEN GP, tu peux pas changer le PTR donc ça reste plus ou moins efficace non ?
Peut-être, mais dans ce cas, pourquoi faire un PTR au lieu de simplement bannir ou établir une réputation sur les IP/ranges ?
-
Sur un abo OCEN GP, tu peux pas changer le PTR donc ça reste plus ou moins efficace non ?
http://free.fr
-
Perso le changement ptr chez free n’a jamais marché pour moi :'(
-
Ça ne fonctionnait plus en fibre, c'est corrigé depuis peu (https://www.universfreebox.com/article/554280/free-active-enfin-une-fonctionnalite-attendue-depuis-beaucoup-trop-longtemps-par-certains-abonnes-fibre).
-
Hello,
Est-ce que vous travaillez toujours sur le routage sur le réseau MilkyWan ? J'ai régulièrement des destinations inatteignables, ou parfois seulement en IPv4 ou IPv6. Comme les derniers messages laissaient entendre que des travaux étaient en cours, je ne m'inquiète pas trop, mais éventuellement une estimation de date pour le retour à un fonctionnement normal ?
D'un autre côté, ça bricole tous les jours dans les armoires fibres de la commune, et je passe régulièrement les refermer correctement le soir (parce que non seulement les sous-traitants de sous-traitants de sous... ne semblent pas avoir les clés, mais en plus ils se contentent de pousser les portes, au premier coup de vent ça se rouvre...)
Patrick
-
Les travaux sont toujours en cours, mais "régulièrement" et "des destinations" c'est pas assez précis pour te dire si le souci vient de là :/
-
Les travaux sont toujours en cours, mais "régulièrement" et "des destinations" c'est pas assez précis pour te dire si le souci vient de là :/
Alors plus spécifiquement :
J'ai deux connexions avec le réseau MilkyWan, l'une en FTTH, l'autre sur un tunnel L2TP, avec un peering BGP sur chacune et priorité sur la FTTH dans les deux sens (MED et local pref).
Quand les deux peerings (FTTH et L2TP) sont établis, je constate que le trafic ne passe pas entre mes adresses IPv4, respectivement mon préfixe IPv6 et deux destinations testées : un VPS chez OVH (extérieur du réseau MilkyWan) et lafibre.info (intérieur du réseau MilkyWan). Il me semble que c'est en sortie seulement parce que je reçois quand même du trafic entrant (mais pour en être certain il faudrait que je me connecte sur mon VPS par un autre moyen que MilkyWan, pas encore essayé). Même constat en IPv4 et IPv6.
J'ai fait ces essais, avec ce résultat, entre 16h30 et 17h. A cet instant ça refonctionne, également avec les deux peerings BGP montés.
Ces pertes de connectivité sont sporadiques et ont commencé le week-end dernier, au moment même où ce message : https://lafibre.info/milkywan/milkywan-as57199/msg1040363/#msg1040363 (https://lafibre.info/milkywan/milkywan-as57199/msg1040363/#msg1040363) a été posté. C'est pour ça que je pensais à des modifications en cours sur le réseau, et comme tu as toi-même laissé entendre que vous aviez eu des problèmes...
-
Est-ce que vous travaillez toujours sur le routage ? En tout cas, il me semble que c'est stable depuis une petite semaine.
La looking glass ne fonctionne toujours pas (ou alors c'est moi qui ne sais plus m'en servir ?), c'était pratique mais on peut vivre sans...
-
On continue de bosser mais pas sur des trucs que vous pouvez voir, pour l'instant on fait un peu de cooldown sur les opérations impactantes :)
-
bonjour, je me demandais à quoi ressemblent vos OLT et vos DSLAM ?
bonne journée
-
Milkywan passe par de la collecte, donc ils n'ont pas de DSLAM / OLT, ça passe par ceux de leur fournisseur (Orange, SFR ou Bouygues pour 99% du temps)
-
Orange, SFR ou Bouygues pour 99% du temps
Euh... Tu oublies les RIP, c'est quand même la majorité de nos abos !
-
On a donc monté la capacité ridicule de 600Gbit/s avec Appliwave dont 300G de transit 🤣
ridicule ? Pas trop même très rapide ;D
je suis déjà content de mes 500 mégabits de fibre orange ;D
mais je sais que chez les FAI faut plus de débit
-
C'était ridicule dans le sens "complètement surdimensionné"...
-
Ce week-end, avec Julien, Gary et les deux Nicolas, nous avons fait une petite opération commando pour changer 4 de nos routeurs principaux :
TH2 : Passage d'un Arista 7280TR (6x100G et 48x10G Copper) à un 7280QR (12x100G et 24x40G)
(https://pix.milkywan.fr/jSW2VbHF.jpeg)
DC2 : Passage d'un Arista 7280TR (6x100G et 48x10G Copper) à un 7280QR (12x100G et 24x40G)
(https://pix.milkywan.fr/4Fq8ItqS.jpeg)
VNX : Passage d'un Arista 7280TR (6x100G et 48x10G Copper) à un 7280QR (12x100G et 24x40G)
(https://pix.milkywan.fr/R1sZj4a4.jpeg)
GVA : Passage d'un Arista 7050SX (4x40G et 48x10G) à un 7280TR (6x100G et 48x10G Copper)
(https://pix.milkywan.fr/IPFZcATd.jpeg)
L'intérêt de cette migration a été de profiter de la baisse des prix sur les Arista 7280QR pour améliorer notre capacité en ports (Q)SFP/QSFP28. Un investissement a quasi 10k€ tout de même, mais qui nous permet de passer la limite de 6 ports fibre des 7280TR. :)
Les anciens routeurs (7280QR) vont partir dans de plus petits POP, on a commencé par en mettre un à Genève, et dans les prochaines semaines, on dispatchera les autres à Toulouse, Lille... Rien ne se perd dans notre réseau :)
On a pas encore prévu de faire de 100G sur ces POP là mais au moins, le matos est prêt pour :)
Bref, on s'occupe par ces longs weekend pluvieux et froids :p
Hugues
-
Merci pour l'info sur ces upgrades.
Pour le long terme, il pourrait être intéressant d'avoir des données à date fixe, par exemple tous les 6 mois sur la capacité du réseau (nb de Gb/s d'interconnexion en additionnant tous les peering / transit) et le trafic réel, afin de voir l'augmentation.
Peut-être suivre le nombre de clients avec une collecte FttH dans le temps.
-
Il me semble qu'on envoie ces données à l'ARCEP justement ;)
-
Oui, cela permet à l'Arcep de publier des données agrégées, mais les données par opérateur ne sont jamais divulguées (et seul un petit nombre de personnes ont accès à ces informations sensibles pour éviter des fuites).
MilkyWan diffuse de temps en temps ces informations ou c'est récupérable via la Weathermap en regardant la capacité de liens et le trafic lors des pics.
Bref, si l'information est disponible pour ceux qui cherchent à l'avoir, peut-être faudrait-il la rendre publique (ou pas).
-
Félicitations pour les upgrades :)
Finalement vous commencez à avoir un rythme sympa. Janvier la capta TV, Février l'upgrade des routeurs... 8)
-
Oui, cela permet à l'Arcep de publier des données agrégées, mais les données par opérateur ne sont jamais divulguées (et seul un petit nombre de personnes ont accès à ces informations sensibles pour éviter des fuites).
MilkyWan diffuse de temps en temps ces informations ou c'est récupérable via la Weathermap en regardant la capacité de liens et le trafic lors des pics.
Bref, si l'information est disponible pour ceux qui cherchent à l'avoir, peut-être faudrait-il la rendre publique (ou pas).
De mémoire sur la WM c'est mis a jour donc je dirait que la capa totale est bonne
et elle est en V6 only mais bien accesible hors du reseau MW
-
MilkyWan diffuse de temps en temps ces informations ou c'est récupérable via la Weathermap en regardant la capacité de liens et le trafic lors des pics.
J'en parle généralement ici ou sur twitter a chaque upgrade ou ajout :)
Pour le nombre d'abonnés, c'est pas un truc que je publie généralement mais au jour d'aujourd'hui on a environ 500 abonnés dont 300 FTTH :)
-
500 abonnés, ça doit faire un chiffre d'affaire de plus de 200k€. C'est bien.
Vous avez des salariés? Temps partiel ou temps plein?
Si ça reste 100% bénévole, la charge de travail doit être conséquente!
Leon.
-
500 abonnés, ça doit faire un chiffre d'affaire de plus de 200k€. C'est bien.
Un peu moins quand même, faut enlever la TVA déjà :)
Vous avez des salariés? Temps partiel ou temps plein?
Si ça reste 100% bénévole, la charge de travail doit être conséquente!
C'est 100% bénévole, on est 16 dans l'équipe d'admin, la majorité des actions sont automatisées et on se répartit bien les tâches qu'il reste ensuite, même si Marc fait le plus gros du support / delivery :)
-
C'est 100% bénévole, on est 16 dans l'équipe d'admin, la majorité des actions sont automatisées et on se répartit bien les tâches qu'il reste ensuite, même si Marc fait le plus gros du support / delivery :)
Yes on a une super équipe de bénévoles ! 8)
Pour la partie support / delivery certains choses sont automatisées ou vont l’être.
Mais une bonne partie du support reste le contact humain, et on essaye dans la mesure du possible de prendre le temps de bien faire les choses :)
C’est la partie la plus chronophage, mais aussi la plus intéressante je trouve !
Cela me prend en moyenne 2h/jour, soit autant que quand j’étais modo sur des forums/communautés.