La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Opérateurs grand public alternatifs => 
MilkyWan => Discussion démarrée par: Leon le 10 octobre 2021 à 13:52:56
-
1ère partie : les POP Réseau
Les POP réseau sont des Datacenter ou nous allons chercher de la connectivité, mais ou nous n'hébergeons pas (à une exception près) de serveurs.
Auparavant Mikrotik, notre nouveau Backbone est majoritairement composé d'Arista 7050. D'excellents petits routeurs, qui, s'il ne tiennent pas une fullview IPv4, tiennent la full v6 et convergent super vite, le tout en ayant une communation hardware, donc une latence et un packetloss incomparables à ce qu'on avait avant :)
Nous avons aussi du Brocade et du Juniper en Edge.
Scaleway DC2 :
(https://pix.milkywan.fr/60sED5dI.jpg)
- Un petit Arista 7050SX d'Edge avec une interco 10G avec Appliwave, un transit 10G avec Appliwave, une wave DWDM 10G vers TH2, un port FranceIX, et dans le futur, des waves vers DC2/CBO :)
Telehouse 2 :
(https://pix.milkywan.fr/UfSZsCfo.jpg)
Comme à DC2, un Arista 7050SX d'Edge, avec une interco 40G avec Appliwave, un transit 40G Appliwave, une wave 10G DWDM vers DC2Scale, une wave 10G DWDM vers DC2, et tout plein de transits/peerings/custs
Ce genre de switch Arista 7050SX, ça sait digérer plusieurs "full view IPv4", et continuer à router en hardware?
Vu que MilkyWan utilise ça comme "routeur de coeur".
Leon.
-
Ca peut manger 400k routes (v4 et v6 mélangées)
On n'a plus de full view depuis plusieurs années, ça coute trop cher en matériel pour un intérêt très faible, voir inexistant.
-
Tu utilise la même stratégie que celle qui sert à garder les Cisco 6500: filtrer les annonces à une certaine taille et mettre une route par default sur un transitaire?
-
Du tout, je n'accepte quasiment aucune route de mes transits, juste une default et quelques AS genre Orange, Free, Amazon.
Par contre, les peerings, c'est grand ouvert :)
Le trafic sort donc toujours sur la default la plus proche
-
On est d'accord que ça fonctionne bien car tu as des transitaire Tier-2 de qualité (AppliWave, FiberWay), que tu utilises comme "default route".
Ces transitaire font déjà le travail de sélectionner les bons "tier-1" pour chaque plage IP, y compris lors d'incidents, avec des gros routeurs qui digèrent des full-views. Donc pas besoin que tu le refasse derrière.
Si tu te connectais exclusivement avec des tier-1 et des peerings locaux, il te faudrait des routeurs capable de gérer des "full views", pour avoir une bonne qualité vers tout internet, y compris vers les petites plages IP lointaines à l'autre bout de la planète.
Leon.
-
Ah non pas du tout.
Si je ne me connectais qu'avec des Tier-1, je pourrais utiliser la même méthode : Default route, et accepter certaines routes de certains AS ou je veux sélectionner par quel transit ils sortiront.
Pour rappel, l'algo de sélection de BGP te permet de connaitre le chemin le plus court en nombre d'AS, tu ne peux donc pas :
- Connaître la route la plus qualitative
- Connaître la route la plus courte géographiquement
Pour résumer, mixer plein de tier-1 pour espérer obtenir la route la plus courte (et qualitative) vers chaque AS, c'est un voeu pieux, pas un gage d'efficacité :)
La seule chose efficace, c'est de choisir de bons transitaires, puisque tu ne peux pas contrôler la route retour, et que tu es bien incapable de connaitre la qualité de chaque route apprise à l'instant T.
-
J'ajoute aussi qu'on doit faire 90% de notre trafic avec 30 AS, c'est donc relativement simple de savoir vers lesquels on veut avoir une bonne qualité et donc lesquels on accepte dans nos filtres.
-
Si je ne me connectais qu'avec des Tier-1, je pourrais utiliser la même méthode : Default route, et accepter certaines routes de certains AS ou je veux sélectionner par quel transit ils sortiront.
Pour rappel, l'algo de sélection de BGP te permet de connaitre le chemin le plus court en nombre d'AS, tu ne peux donc pas :
- Connaître la route la plus qualitative
- Connaître la route la plus courte géographiquement
Pour résumer, mixer plein de tier-1 pour espérer obtenir la route la plus courte (et qualitative) vers chaque AS, c'est un voeu pieux, pas un gage d'efficacité :)
La seule chose efficace, c'est de choisir de bons transitaires, puisque tu ne peux pas contrôler la route retour, et que tu es bien incapable de connaitre la qualité de chaque route apprise à l'instant T.
Tu veux dire que l'époque où les tier-1 ne voyaient pas réellement tout internet est révolue?
Il me semble que du transit Cogent, notamment, ne permettait pas de voir tout Internet, il y a 10-15 ans.
Leon.
-
De ce que j'en sais, oui, c'est révolu, en IPv4 en tout cas !
Et en IPv6, vu le nombre de routes, on prend la full, rien qu'HE sur franceIX c'est déjà 80% de la full...
a7050sx.edge.dc2#show ip route summary
Operating routing protocol model: multi-agent
Configured routing protocol model: multi-agent
VRF: default
Route Source Number Of Routes
-------------------------------------- -------------------------
connected 9
static (persistent) 1
ospf 22
bgp 125535
External: 87411 Internal: 38124
internal 27
attached 457
Total Routes 126051
Number of routes per mask-length:
/0: 1 /8: 4 /9: 2 /10: 5 /11: 14
/12: 45 /13: 71 /14: 173 /15: 231 /16: 1482
/17: 970 /18: 1764 /19: 2651 /20: 4500 /21: 5427
/22: 14994 /23: 13726 /24: 78786 /25: 384 /28: 5
/29: 4 /30: 53 /31: 10 /32: 749
a7050sx.edge.dc2#show ipv6 route summary
Operating routing protocol model: multi-agent
Configured routing protocol model: multi-agent
VRF: default
Route Source Number Of Routes
----------------------------- ----------------
connected 9
ospf 18
bgp 128852
internal 15
attached 707
Total Routes 129601
Number of routes per mask-length:
/0: 1 /10: 1 /16: 1 /19: 1 /20: 12
/21: 3 /22: 7 /23: 7 /24: 28 /25: 8
/26: 15 /27: 21 /28: 120 /29: 3698 /30: 513
/31: 207 /32: 20681 /33: 2335 /34: 2012 /35: 756
/36: 4624 /37: 884 /38: 1489 /39: 950 /40: 9386
/41: 699 /42: 2802 /43: 722 /44: 11432 /45: 1136
/46: 2252 /47: 1905 /48: 59896 /49: 4 /56: 6
/60: 1 /64: 140 /96: 2 /104: 1 /126: 100
/127: 1 /128: 742
Et on a de la FIB Compression pour ré-agréger les gros porcs qui annoncent 30 /24 ou /48 contigus
-
Normalement n’importe quel Tier 1 IPv4 te donne une « full view ».
En v6 on a que HE et Cogent qui font chier comme acteurs de transit.
-
Tu veux dire que l'époque où les tier-1 ne voyaient pas réellement tout internet est révolue?
Il me semble que du transit Cogent, notamment, ne permettait pas de voir tout Internet, il y a 10-15 ans.
Normalement n’importe quel Tier 1 IPv4 te donne une « full view ».
Il y a 20 ans PSINet, devenu Cogent, avait dépeeré ATDN (AOL). Ils l'ont regretté par la suite.
À partir de là en effet les routes n'étaient plus toujours forcément échangées entre les deux, au fur et à mesure des manœuvres de Cogent.
Il y a presque 14 ans Cogent est devenu Tier1 en récupérant son peering avec ATDN.
Et puis ATDN qui était Tier1 a disparu avec AOL (ils n'étaient déjà plus Tier1, TimeWarner a vendu ce qui pouvait l'être, et l'AS 1668 n'est même plus présent sur Internet).
https://blogs.oracle.com/internetintelligence/cogent-becomes-transit-free
-
J'ai souvenir que quand tu étais client AOL au début, en RTC, tout le trafic partait aux USA, probablement par absence de peering en Europe.
-
J'ai souvenir que quand tu étais client AOL au début, en RTC, tout le trafic partait aux USA, probablement par absence de peering en Europe.
Mieux. C'était pas du tout de l'IP. Ca partait aux US où avait lieu la conversion protocolaire entre le giga-BBS et IP.
D'ailleurs de mémoire installer un kit AOL c'était le meilleur moyen de véroler son ordi avec une winsock.dll custom qui trafiquait autre chose que de l'IP normal.
-
Mieux. C'était pas du tout de l'IP.
En tous cas en 2001 ça partait de NAS/LACs en France en PPP (avec un protocol proprio AOL: P3) sur L2TP (donc sur IP) vers des LNS AOL aux US ou à Londres (via le réseau AOL).
-
En tous cas en 2001 ça partait de NAS/LACs en France en PPP (avec un protocol proprio AOL: P3) sur L2TP (donc sur IP) vers des LNS AOL aux US ou à Londres (via le réseau AOL).
Du coup tu es vieux ? ;D ;D
-
En tous cas en 2001 ça partait de NAS/LACs en France en PPP (avec un protocol proprio AOL: P3) sur L2TP (donc sur IP) vers des LNS AOL aux US ou à Londres (via le réseau AOL).
Ouhla 2001 c'est un AOL qui a 5 ans d'âge.
Du coup tu es vieux ? ;D ;D
C'est un djeunz. Les terminologie NAS/LAC et autres BAS ou LNS ca existait pas encore. Pour donner un repère temporel RFC 2661 L2TP c'est août 99
-
Ca peut manger 400k routes (v4 et v6 mélangées)
On n'a plus de full view depuis plusieurs années, ça coute trop cher en matériel pour un intérêt très faible, voir inexistant.
Hello, je me vois mal vendre du réseau à un opérateur qui a plusieurs transitaires, avec une défaut route....
Car si l'opérateur parent perd la fullview, le routeur du client converge vers un autre opérateur, même si la Session BGP reste connectée.
Alors que si tu donnes du réseau en défaut route, que le réseau en amont marche ou pas, la session sera connectée avec la default route... ce qui rend pas très automatique en terme de redondance :)
-
C'est un choix financier, soit on achetait des routeurs à 10k€ et on avait la full, soit on achetait des routeurs à 1k€ sans la full.
Chacun voit midi à sa porte, je préfère avoir un backbone redondé multi-villes sans full que me limiter à 1 ou 2 PoP avec.
Sachant qu'en plus, l'absence de full ne concerne qu'IPv4 et que ça n'a aucun impact pour 95% des abonnés (notre activité principale n'est pas de vendre du transit)
Les gens ayant besoin d'une full v4 sont amicalement redirigés vers nos amis d'appliwave par exemple
-
C'est un choix financier, soit on achetait des routeurs à 10k€ et on avait la full, soit on achetait des routeurs à 1k€ sans la full.
Chacun voit midi à sa porte, je préfère avoir un backbone redondé multi-villes sans full que me limiter à 1 ou 2 PoP avec.
Sachant qu'en plus, l'absence de full ne concerne qu'IPv4 et que ça n'a aucun impact pour 95% des abonnés (notre activité principale n'est pas de vendre du transit)
Les gens ayant besoin d'une full v4 sont amicalement redirigés vers nos amis d'appliwave par exemple
Du coup, la prestation de "transit IP" fournie par MilkyWan, ça n'est pas vraiment du transit IP tel qu'on l'entend habituellement.
Pour un client, impossible de faire du vrai "multi homing" avec du transit IP fourni par MilkyWan.
J'espère que tu le signales bien aux futurs clients. Ne faudrait-il pas l'ajouter sur le site web?
Si vous vouliez vraiment fournir du transit IPv4 full view, avec l'infra actuelle, ça serait sans doute possible. Avec des routeurs de faible capacité de trafic mais capacité de calcul (machine X86), qui vivraient en parallèle des routeurs "gros trafic" pré-existants juste à côté. . Voire des route-servers. Mais bon, si vous n'avez que très peu de clients transit-IP, le jeu n'en vaut sans doute pas la chandelle.
Leon.
-
Du coup, la prestation de "transit IP" fournie par MilkyWan, ça n'est pas vraiment du transit IP tel qu'on l'entend habituellement.
Pour un client, impossible de faire du vrai "multi homing" avec du transit IP fourni par MilkyWan.
Si, simplement qu'au lieu de t'annoncer 800k routes, on en annonce ~200k + une route par défaut.
On t'annonce quand même à tous nos peers et tu as un accès complet à internet, simplement pas toutes les routes dans ta RIB/FIB.
Je rappelle quand même une chose très importante. Notre offre de transit IP n'est pas là pour concurrencer un Cogent, un Zayo ou un Appliwave.
On fournit du transit avec de très petits commits pour les homelabs. Nous sommes très souvent le principal transitaire de nos abonnés, en parallèle d'un tunnel gratuit type hurricane electric ou freetransit (ou pas, on a quelques AS monohomés chez nous, même si je préfère que mes abonnés aient un backup ailleurs). Ces gens là n'ont en outre généralement pas d'IPv4. Avoir la fullview ce n'est pas forcément utile à tous les réseaux. Je sais que cette rumeur a la vie dure, mais nous sommes un certain nombre à avoir réussi à passer outre, ça me permet d'ailleurs de proposer des solutions techniques bien moins couteuses à mes clients (dans mon vrai métier).
Bref, on a peut-être pas la fullview, mais on certainement un des meilleurs réseaux accessibles à un homelab, avec des tarifs cohérents.
-
Si, simplement qu'au lieu de t'annoncer 800k routes, on en annonce ~200k + une route par défaut.
[...]Je sais que cette rumeur a la vie dure, mais nous sommes un certain nombre à avoir réussi à passer outre, ça me permet d'ailleurs de proposer des solutions techniques bien moins couteuses à mes clients (dans mon vrai métier).
Bref, on a peut-être pas la fullview, mais on certainement un des meilleurs réseaux accessibles à un homelab, avec des tarifs cohérents.
Merci pour ta réponse. C'est très clair. Effectivement, tu as raison, pour des petits réseaux, ne pas avoir de "full view", ça n'est absolument pas gênant, même pour des réseaux "pro" comme tu le dis.
Manipuler des "full view BGP", ça donne certainement l'impression de jouer dans la cour des grands, mais c'est sans doute surtout utile quand on administre un réseau d'envergure internationale avec pleins points d'interconnexion.
Leon.
-
Manipuler des "full view BGP", ça donne certainement l'impression de jouer dans la cour des grands, mais c'est sans doute surtout utile quand on administre un réseau d'envergure internationale avec pleins points d'interconnexion.
Disons que si on pouvait on le ferait, mais pour te donner un ordre d'idée, un Arista 7050SX comme ce qu'on a mis en coeur, c'est environ 2000€
Un Arista 7280-SR3K comme ce qu'Appliwave met, et qui tient une fullview, c'est environ 12000€
Vu qu'avec la fibre, notre besoin c'est d'avoir beaucoup de petits POP pour récupérer le trafic au plus près, l'équation financière n'était pas tenable.
Par contre, d'ici 3 ans, j'ai bon espoir de réintroduire la fullview dans le réseau, au moins pour la gloire :)
Hugues
-
- Connaître la route la plus courte géographiquement
Tu fais comment cette partie? Longueur du chemin par rapport à toi? Il y a des outils pour ça ?
-
smokeping et les retours des utilisateurs. C'est justement ce qui différencie BGP du vrai boulot d'optimisation d'un NOC :)
-
Tiens pour info, on a de nouveau la full sur le réseau depuis le passage aux Arista 7280R.
Et ça n'a pas changé grand chose, à part un temps de convergence plus long sur les routeurs :)
-
Par contre, d'ici 3 ans, j'ai bon espoir de réintroduire la fullview dans le réseau, au moins pour la gloire :)
En avance sur le délai annoncé... Incroyable
-
Je m'attendais pas a ce que le prix du matos baisse si vite :D
-
Tiens pour info, on a de nouveau la full sur le réseau depuis le passage aux Arista 7280R.
Et ça n'a pas changé grand chose, à part un temps de convergence plus long sur les routeurs :)
Aussi, à part la full view, le passage aux A7280 apportent d’autres bénéfices très agréables 😊
-
Oui bien sur, c'était loin d'être le seul bénéfice :p
-
Aussi, à part la full view, le passage aux A7280 apportent d’autres bénéfices très agréables 😊
C'est à dire?
Leon.
-
Du 100G, du sflow pas buggé, plus de RAM...
-
Félicitations
-
J'ajoute aussi qu'on doit faire 90% de notre trafic avec 30 AS, c'est donc relativement simple de savoir vers lesquels on veut avoir une bonne qualité et donc lesquels on accepte dans nos filtres.
Question bête : comment identifiez-vous ces 30 AS en ayant une route par défaut ? Avec sFlow (ou autre), les infos d'ASN source/destination peuvent être échangées mais si les routeurs n'ont pas la full table, ces infos ne remonteraient pas (uniquement l'ASN du transitaire).
-
Les ip source/dest tout simplement :)
-
Alors je pensais surtout au mapping IP/AS. :P
-
https://github.com/JackSlateur/perl-ip2as :)
-
Ça aussi c'est pas mal : https://www.team-cymru.com/ip-asn-mapping
-
Celui là, je l'avais, avec une requête WHOIS ou API, ça a l'air pas mal. Mais je comprends que c'est un traitement basé sur une liste en entrée. Travail un peu manuel ;)
-
Ben ça dépend comment tu génères ta liste :)