Reprise du message précédent :
à chaque fois que je vois que google met un pied dans le domaine des télécoms je serre un peu les fesses  

la pieuvre s'étend, on va tous y passer

Mais un jour (avec beaucoup de vaseline), tu auras l'ADSL / Fibre by Google chez toi

http://www.nextinpact.com/news/892 [...] obleme.htm
 
Un lien un peu plus détaillé

http://www.zdnet.com/internet-hicc [...] 000032566/

 
 
En complément, le nombre de routes a augmenté d'un coup de pas mal suite à l'annonce par Verizon de plein de nouvelles routes (désagrégées d'un gros préfixe) qui a ajouté d'un coup plusieurs dizaines de milliers de routes dans la table de routage globale.
 
Certains opérateurs ont eu la surprise de dépasser ce seuil bien avant l'estimation par rapport à la croissance normale, d'autres ont eu la surprise de se rendre compte de cette limite.
 
Beaucoup de routeurs d'ancienne génération sont concernés par cette limitation à 512 000 routes et si pour une partie une reconfiguration du profil mémoire permet d'augmenter cette limite (Cisco 7600/6500 avec 3BXL par exemple) en rebootant le routeur derrière pour la prise en compte, pour d'autres c'est une limite hardware et là ça fait mal.
 

il serait temps de migrer sur IPV6 plus sérieusement...

 
D'un côté des gens vont rogner sur IPv6 pour augmenter la limite IPv4 et ça ça pue
D'un autre côté c'est bien parce que ça aide à rappeler qu'il serait temps d'y penser pour de bon et pas laisser les choses en l'état comme actuellement.

Dans le futur ça restera avec un mix ipv4/ipv6 ?
Ou éradication de l'ipv4 ?

je pense qu'on va entrer dans une phase de cohabitation des 2 pendant un moment (ça implique du changement de matos pas compatible actuellement avec v6 = $$)

Donc en fait les plages attribués en ipv4 resteront actives

Puis après les nouvelles adresses passeront en ipv6,avec cohabitation pendant plusieurs années avec les ipv4 ?

Aucun intérêt pour nous simple utilisateurs d'activer l'ipv6 ?

Bah si, avoir 12milliards d'ip pour la maison
 
XaT

Ça fait bcp d'équipements tout ça

J'ai toujours rêvé d'avoir mon frigo et mes chiottes en ipv6 direct' sur le net keuouah
Faire un iperf sur ses chiottes depuis l'extérieur

XaT

Tu sais que tu ramènes une fille à la maison, pas sur de l'état de tes toilettes, tu tires la chasse d'eau à distance  

Si tes chiottes sont raccordés au réseau je te conseille vivement de ne pas ramener de fille à la maison Elle fuira avant même de voir les chiottes

XaT

 
Oui, surement pendant encore au moins 10 ans je dirais. Tant que tout le monde ne sera pas passé à IPv6 en tout cas.
 

 
La majorité du matériel actuel est compatible IPv6, il reste surtout le problème des "box" chez les FAI mais sinon ça fait 10 ans que les constructeurs ont intégré IPv6 à leurs produits, on en est plus trop là. Ce qui freine ce sont les routeurs chez les abonnés surtout pour les FAI et la couche applicative pour les sites webs.
 

 
Oui c'est ça. Il n'y a pas d'intérêt aujourd'hui pour l'utilisateur, mais il n'y a pas de contrainte non plus, c'est un peu ce qui est bien foutu. Tu devrais avoir une IPv6 assigné à ton PC sans même que tu y réfléchisses et tu devrais aller sur Facebook en IPv6 sans même t'en rendre compte. C'est comme ça que ça devrait se passer, de manière transparente.

Un arduino caché derrière la chasse d'eau, elle ne se rendra compte de rien

Merci pour les détails

drap

Est-ce que 2 bonnes âmes pourraient faire un test pour moi svp depuis les FAIs Free et Orange ?
 
Faire un traceroute vers 80.70.223.124 ? (si vous pouvez m'envoyer en MP pour ne pas polluer le sujet, j'expliquerai ici derrière quand j'aurai les infos )
 
Merci
 

Je t'envoie ça pour Orange

je peux faire ça pour free

MP dans 10 mns maxi

Merci pour les traceroutes
 
Amusant en fait 2 cas différents mais un résultat similaire. Bon voilà l'histoire :  
 
Sur les points d'échange il y a ce qu'on appelle des route server, sur lesquels les opérateurs membres décident ou pas d'annonce leur routes et d'apprendre celle des autres.
 
J'ai constaté que pour certains, j'apprenais leurs routes depuis ces RS sur des points d'échange, mais que eux ne passaient pas par là pour me joindre mais par du transit.  
 
J'ai donc essayé hier de diviser une route en 2 plus petites et d'annoncer uniquement aux peerings et route server ces 2 routes en plus de la normale. C'est une manière de forcer le routage entrant dans le réseau, car on peut mettre le poids qu'on veut à une route, s'il y en a une plus petite apprise à côté, elle sera toujours prioritaire sur la plus grosse.
 
Et ça m'a permis de voir plusieurs choses :
 
- Les opérateurs qui m'intéressent annoncent leurs routes aux RS mais ne les apprennent pas (rien n'a changé pour eux)
 
- Orange : Orange est connecté aux RS d'Equinix IX Paris et n'annonce pas ses préfixes dessus (normal parce qu'il faut payer pour peerer avec eux), mais en revanche ils apprennent les routes des RS même s'ils ne les utilisent pas en temps normal. Donc en forçant un préfixe plus court, Orange m'envoie maintenant son trafic par ce point d'échange. C'est amusant, même si le sens le plus important pour un fournisseur de contenu avec un FAI est le sortant.
 
- Free : J'ai un transit qui me sert pour joindre Free, il a un peering payant avec eux et ça m'assure d'avoir de la qualité en ces temps merdiques. Cependant bien que Free ne soit pas présent sur les points d'échange, d'un coup mon trafic entrant passe aussi par Equinix IX Paris ou FranceIX. En fait c'est mon fournisseur de transit avec qui je peere qui du coup se voit "forcé" de m'envoyer le trafic mon entrant par le point d'échange. Ca veut dire que si mon trafic était majoritairement entrant (comme un FAI), je pourrais forcer le trafic par là et ne plus payer de volume chez eux (bon ils s'en apercevraient je pense quand même au bout d'un moment)
 
Bref, en voulant forcer des opérateurs d'autres pays à passer par les IX, je me retrouve avec le trafic des 2 principaux FAI en France qui passe par là
 
/ pour ceux que ça intéresse le routage BGP

http://tinyurl.com/k9otetd

Un peu déçu que l'auteur se soit plus concentré sur les aspects responsabilité et problème sans laisser une porte ouverte vers les évolutions et IPv6. On préfère parler des problèmes que des solutions =) Cependant c'est un bon article pour expliquer ce qui s'est passé aux gens.

Intéressant
 
XaT

Pas de réaction sur FranceIX ?
 
XaT

Pas grand chose à dire, un problème de tempête de broadcast/multicast d'un client FranceIX (a priori HE d'après les différents logs) a généré 2 Gbps et quelques millions de paquets par seconde sur le point d'échange.
 
Le réseau du FranceIX a été changé il y a peu de temps par du Juniper, la configuration prévoyait des filtres pour limiter le broadcast et interdire le multicast, également pour limiter le nombre de MAC par port client.
 
Les protections n'ont pas fonctionné, le la table VPLS est partie en vrille. La raison n'est pas encore complètement élucidée mais a priori le comportement des filtres serait un peu vicieux, les règles d'un port pourraient être annulées/overridées par celle du port suivant sur le chemin dans la conception Juniper. Bug ou feature, c'est pas encore clair mais c'est assez vicieux comme truc.
 
De mon côté j'ai coupé toutes les sessions de peering quand le problème s'est déclaré, j'avais 1,5 Gbps de trafic anormal en entrant sur le port pour 2,3 millions de paquets par seconde. Le routeur Cisco ASR9K (dernière génération) où est raccordé le FranceIX est monté à 20% de CPU. Ca pourrait expliquer que certains opérateurs avec du matériel moins récent aient subi un downtime de leur routeur entier. Engalement sur des erreurs de configuration (proxy ARP) ça pourrait avoir causé des effets de bord.
 
Les principaux impactés :  
- Les abonnés Bouygues Telecom, Numericable et OVH vers une bonne partie des sites francophones

http://jssnews.com/2014/08/17/inte [...] m-le-flop/
Ça m'a fait marrer, surtout quand on sait qui est derrière Golan Télécom

Ca vaut quoi openbgpd ?
 
XaT

Je ne sais pas, mais j’entende beaucoup parlé de bird.

Du coup, ca vaut quoi bird ?
 
XaT

Je ne sais pas, mais j'entende beaucoup parlé de quagga.

Du coup... BON CA VA.

Sinon

Ca doit dater un peu https://www.nanog.org/meetings/nano [...] al_N48.pdf

XaT

300K routes, rofl, il en faut le double maintenant

510k la non ?
Oui m'enfin ça date un peu mais ça montre grossièrement le truc, attendons les retours de gens qui savent
 
XaT

Hello,
 
J'ai pas une grosse expérience d'utilisation en propre des daemon BGP, mais BIRD est assez différent des 2 autres car il n'est pas prévu pour "router" au sens traversant, il a vraiment été conçu pour faire "route server", c'est à dire collecter, calculer et distribuer des routes à des routeurs qui forwardent le trafic et pour ça il est très très performant. C'est je pense aujourd'hui le meilleur pour ça.
 
Quagga est un daemon historique très utilisé sous Linux (quasi le seul jusqu'à ces dernières années), un peu moins stable que ses concurrent (enfin je sais pas ces dernières années j'ai pas trop suivi les évolutions)
 
OpenBGPd c'est le daemon OpenBSD (classique avec ce nom) et c'est comme beaucoup de produits OpenBSD : Robuste, stable, efficace et assez performant.
 
J'utilise depuis peu OpenBGPd pour des services particuliers, c'est fonctionnel et assez bien fait. Par contre c'est pas forcément très utilisé pour des fonctionnalités avancées, par exemple cette semaine on a trouvé un bug sur l'IPv6 avec l'option next-hop qui fonctionne mal (c'est une option qui permet de définir manuellement la gateway suivante d'une route)
 
Donc en gros pour moi c'est surtout une histoire de contexte :  
 
- BIRD : Route server pur qui ne fait pas passer le trafic
- Quagga : Quand on veut pas mal de fonctionnalités pour jouer
- OpenBGPd : Pour du stable efficace en prod sur du forwarding
 
Après faut être clair sur un point : Le problème du routage sur serveur, ce sont les bus et le fait que tout remonte en CPU pour le calcul du routage contrairement à un routeur hardware. Ca fonctionne de mieux en mieux avec les serveurs modernes, mais ça reste le goulot d'étranglement avant le calcul BGP. Les PPS peuvent écrouler plus facilement un serveur qu'un routeur hardware.
 
Pour une solution à petit budget sur une petite infra ça peut très bien tenir la route et les limitations de mémoire ne sont pas un problème avec ça.

 
Je capte pas la fin, c'est pas possible sur serveur de ne pas passer par le CPU
Et si le serveur c'est un routeur hw sous linux ?
 
XaT

 
Déjà je pense que ce serait plus facilement un BSD qu'un Linux pour un routeur  
 
Sinon Juniper à la base c'est ça, un Unix sur un routeur hardware. Techniquement c'est possible bien sûr, mais ça veut dire qu'il faut des ASICs ou FPGA sur les cartes PCIe/réseaux et qu'elles sachent parler entre elles sans passer par le CPU. Ca reviendrait à faire comme les cartes graphiques en SLI avec leurs propres CPU et leur bus de communication sans passer par la carte mère.
 
Un paquet qui arrive dans un routeur doit être traité pour le forwarding. Ca veut dire qu'il faut calculer sur quel port l'envoyer en sortie, gérer tout ce qui modifie le paquet (QoS, ACL, etc), donc il faut forcément une unité de calcul pour traiter la donnée. Sur un serveur traditionnel, le chipset de la carte réseau est incapable de faire ces traitements et n'a aucune connaissance des cartes voisines, donc ça remonte forcément en CPU par les bus.

Avec des cartes réseaux qui gèrent le TOE, on ne limite pas grandement (voire on l’élimine) le problème ?
 
Et les cartes réseaux multi ports qui peuvent router sans que ça remonte au CPU, ça n'existe pas ?

Il n'y a pas dell qui veut faire le chemin "inverse" ? cad proposer un unix-like sur ses routeurs / switch (je crois que c'est passé au dernier frnog, mais j'ai pas regardé)

Oui mais sur les switch, pas routers je crois, et c'est linux (cumulus). Ce qui est cool dans le tas c'est ONIE
 
XaT