[FRnOG] [TECH] Message de service
Plop,
Juste une brève réaction et rappel suite à un tweet de Bortz qui a vu
des /64 trainer dans la DFZ (enfin via BGPmon) :
- IPv6 ne se désagrège pas en dessous de /48. Jamais. Et en pratique
n'annoncer que le /32-29 suffit.
- IPv4 ne se désagrège que dans trois cas :
* sous-allocation,
* load-balancing pour un réseau d'eyeball mal géré et/ou avec de mauvais
équilibres entre transits,
* protection contre le hijacking sur des infra critiques.
L'exemple même de ce qu'il ne faut PAS faire :
http://bgp.he.net/AS43142#_prefixes
http://bgp.he.net/AS43142#_prefixes6
('tin, en allocation séquentielle en plus. Ca se découpe par dichotomie
l'IPv6 !!!)
Bref, s'il vous plait, ce serait sympa de pas contribuer à l'explosion
des TCAM et au broutage des naimix. Sinon ça va se finir à coup de
repair-kit au prochain apérézo ou FRnOG.
@+
--
Jérôme Nicolle
06 19 31 27 14
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] Message de service
Hello Jérôme,
Il suffit d'avoir les filtres adéquats, et filtrer le longer than /48...
comme tout le monde filtre probablement jusqu'au /24 (voire moins) dans
le pretty old legacy IPv4...
En ce qui me concerne, j'ai pas vu la différence, donc ca m'est égal...
--
Clément Cavadore
On Mon, 2014-11-03 at 14:05 +0100, Jérôme Nicolle wrote:
Plop,
Juste une brève réaction et rappel suite à un tweet de Bortz qui a vu
des /64 trainer dans la DFZ (enfin via BGPmon) :
- IPv6 ne se désagrège pas en dessous de /48. Jamais. Et en pratique
n'annoncer que le /32-29 suffit.
- IPv4 ne se désagrège que dans trois cas :
* sous-allocation,
* load-balancing pour un réseau d'eyeball mal géré et/ou avec de mauvais
équilibres entre transits,
* protection contre le hijacking sur des infra critiques.
L'exemple même de ce qu'il ne faut PAS faire :
http://bgp.he.net/AS43142#_prefixes
http://bgp.he.net/AS43142#_prefixes6
('tin, en allocation séquentielle en plus. Ca se découpe par dichotomie
l'IPv6 !!!)
Bref, s'il vous plait, ce serait sympa de pas contribuer à l'explosion
des TCAM et au broutage des naimix. Sinon ça va se finir à coup de
repair-kit au prochain apérézo ou FRnOG.
@+
---
Liste de diffusion du FRnOG
http://www.frnog.org/
[FRnOG] Re: [TECH] Message de service
On Mon, Nov 03, 2014 at 02:37:04PM +0100, Clement Cavadore clem...@cavadore.net wrote a message of 54 lines which said: Il suffit d'avoir les filtres adéquats, et filtrer le longer than /48... Un /20 fait 2^28 /48. Désagrégé, cela fera mal... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Message de service
Le 03/11/2014 14:05, Jérôme Nicolle a écrit :
[...]
http://bgp.he.net/AS43142#_prefixes6
('tin, en allocation séquentielle en plus. Ca se découpe par dichotomie
l'IPv6 !!!)
Tu pourrais préciser cette remarque, je n'arrive pas à la saisir. Pour
moi, le problème est au contraire qu'il y a eu un découpage dichotomique
avec le 33e bit, ce qui coupe un nibble de façon crade. Mais les /48 en
séquentiel, ça paraît plutôt cohérent. Tu t'es planté, ou je t'ai pas
compris ?
Merci,
ju.
--
http://ju.vg
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Message de service
On Mon, 2014-11-03 at 14:44 +0100, Stephane Bortzmeyer wrote: Un /20 fait 2^28 /48. Désagrégé, cela fera mal... Le débat est donc: Quel est le bon curseur pour les filtres entre /32 et /48 ? -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Message de service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/11/2014 14:46, Clement Cavadore wrote: On Mon, 2014-11-03 at 14:44 +0100, Stephane Bortzmeyer wrote: Un /20 fait 2^28 /48. Désagrégé, cela fera mal... Le débat est donc: Quel est le bon curseur pour les filtres entre /32 et /48 ? /48, indubitablement, car tu n'as aucun moyen de décréter qu'un /48 n'est pas légitime. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRXnV0ACgkQJBGsD8mtnRGbPAEApnLTLJ7EhJgiSq+Jx4AG2KPd 2KJ/ncCpqZanBzY+3NAA/jrag/85Ka339IiKr/6Dg7zKLJFaYH1KrmhEyBUHWb5l =Dea1 -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Message de service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bonjour, On 03/11/2014 14:05, Jérôme Nicolle wrote: - IPv4 ne se désagrège que dans trois cas : * sous-allocation, * load-balancing pour un réseau d'eyeball mal géré et/ou avec de mauvais équilibres entre transits, * protection contre le hijacking sur des infra critiques. Tu sembles oublier le multihoming classique. J'aurais bien rajouté le blackholing mais je concède que c'est un usage temporaire, mais dans ce cas le préfixe est souvent très long voire un /32. Mais ipv4 ne se désagrège pas tout seul, est-ce que tu es en train de parler d'annonces de LIR ou de End-User ? NB: Refs needed. Cdlt, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRXn6cACgkQJBGsD8mtnRERVwD/XeyP1denWbxEGrbiF3E7z6yV pYtXDA36QmlgFlvH2loBAMMOuRe0rnTtXmAAT0AE2qMuWcE9p6EylypipkBrww7N =/NFq -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Message de service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 03/11/2014 16:30, Sylvain Vallerot a écrit : Tu sembles oublier le multihoming classique. Couvert par la sous allocation. Si tu as un /21 utilisé d'un bloc par le(s) même(s) routeur(s), même multihomé, les bonne pratiques (en mode bon sens paysan quoi) limitent les cas de désagrégation aux deux autres cas, sachant que le cas du load-balancing de trafic entrant est critiquable. - -- Jérôme Nicolle 06 19 31 27 14 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlRXo+IACgkQbt+nwQamihu4LgCfZJ4SogyiXszB+m5UO6erf8f7 1+4AnRbLH/VSH3DqtvtyLLnWrnVZJCJg =xPkI -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Message de service
Le 03/11/2014 14:44, Julien VAUBOURG a écrit : Tu pourrais préciser cette remarque, je n'arrive pas à la saisir. Pour moi, le problème est au contraire qu'il y a eu un découpage dichotomique avec le 33e bit, ce qui coupe un nibble de façon crade. Mais les /48 en séquentiel, ça paraît plutôt cohérent. Tu t'es planté, ou je t'ai pas compris ? Je crois que tu as bien compris et que je ne me suis pas planté, en fait. Le problème de l'allocation IPv6 c'est qu'on ne sait pas comment ça va évoluer faute de retours opérationnels suffisants. Où plus exactement, c'était le cas il y a encore quelques années, et on a toujours très peu de personnes capables de définir une politique d'allocation qui tienne sur le long terme. L'allocation séquentielle signifie allouer les blocs adjacents l'un après l'autre. Si un client/routeur/ensemble de machines évolue pour avoir besoin de plus que ce que tu as alloué initialement, alors tu vas devoir allouer un autre bloc non adjacent ou déplacer le bloc pour en allouer un plus gros, et donc renuméroter. L'allocation dichotomique permet d'éviter ce problème en allouant des blocs répartis dans l'espace d'adressage tout en gardant de quoi les étendre. Tu as raison concernant les nibbles, c'est pratique de fonctionner par pallier de 4 bits. Dans cette optique, voilà ce que ça donne : J'ai mon /32 tous frais sorti du ripe : 2001:db8::/32. J'ai besoin de 4 /48 dedans pour commencer : un backbone, un d'interco pour un PE et deux pour des clients. La mauvaise méthode est : 2001:db8:1::/48 : backbone 2001:db8:2::/48 : intercos 2001:db8:3::/48 : client 1 2001:db8:4::/48 : client 2 Alors que la bonne méthode est : 2001:db8::/48 : backbone 2001:db8:4000::/48 : intercos 2001:db8:8000::/48 : client 1 2001:db8:C000::/48 : client 2 Que tu vas en réalité justifier par : 2001:db8::/33 : réseau backbone / intercos / loopbaks / monitoring / whatever de ton réseau 2001:db8:8000::/33 : les clients Sauf que les /33 n'apparaissent nul part dans la table de routage. Après tu peux moduler ça de plein de façon : un /40 ou /44 par PoP, avec les clients et intercos dedans pour pouvoir agréger dans ton IGP, par exemple. Ou encore un double plan par famille de services. Perso j'ai un faible pour l'approche TeraStream, mais les docs accessibles sont incomplets. @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Message de service
A lire un grand classique : https://tools.ietf.org/html/rfc3531 Ca fait quand même 11 ans qu'on explique que l'allocation séquentielle, c'est pas bon. En ce qui concerne l'allocation par nibble : http://www.slideshare.net/cwestin63/ipv6-address-planning-30305109 A noter que ceci est valable pour ARIN, je ne connais pas bien les détails pour les autres RIRs. La politique d'ARIN est que on te donnera suffisamment d'IPv6 y compris de gaspiller en faisant des allocations par nibble. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Outils pour stress d'équipements réseaux
Bonjour à tous, Dans le cadre d'évaluation d'équipements réseau (en l’occurrence : Switch niveau 3); Nous souhaiterions pouvoir simuler du trafic réseau à travers ces équipements afin de voir notamment comment se comportent les tables ARP et la TCAM avec un grand nombre de machines dialoguant sur le réseau (adresses MAC et IP différentes) et sur des VLAN différents. La mesure du débit entre deux machines, même si cela fait forcément partie de la démarche, n'est pas nécessairement le point primordial à mesurer ; Ce qui nous intéresse surtout, c'est que l'équipement ne se mette pas à freezer, à jeter du paquet, ou à faire n'importe quoi avec les paquets à cause d'une limite quelconque qui ne serait pas précisée (ou qui serait erronée) dans les specs constructeur. Auriez vous connaissance d'outils ou de techniques, de préférence libres permettant de mener à bien ce genre de tests ? En vous remerciant par avance de toute suggestion ;) . @+ Christophe. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Message de service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/11/2014 16:48, Jérôme Nicolle wrote: Le 03/11/2014 16:30, Sylvain Vallerot a écrit : Tu sembles oublier le multihoming classique. Couvert par la sous allocation. Mais tu peux multihomer un bloc assigné sans le sous-allouer, donc qu'est-ce que tu entends par sous-allocation du coup, ta définition ne semble pas être celle du Ripe ? Si tu as un /21 utilisé d'un bloc par le(s) même(s) routeur(s), même multihomé, les bonne pratiques (en mode bon sens paysan quoi) limitent les cas de désagrégation aux deux autres cas, sachant que le cas du load-balancing de trafic entrant est critiquable. Et qu'est-ce que tu entends par désagréger : un LIR qui annonce des subnets du bloc alloué par la RIR seulement, ou un LIR qui annoncer des subnets en plus d'annoncer le bloc alloué par le RIR ? A ma connaissance, il n'y qu'un seul cas qui puisse légitimer le premier, c'est le cas d'un LIR qui n'annonce rien (ni le bloc alloué par le RIR, ni des morceaux de ce bloc). Et les annonces de subnets n'étant pas forcément faites par le LIR mais pouvant être faites par ses clients (cas du multihoming), j'en viens à me demander à qui s'applique la règle que tu édictes. Bref, tes docs de référence m'intéressent. Bonne soirée, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRXzCAACgkQJBGsD8mtnREETQD/TyIsNCtQsXJPulj0KJCJOrT7 Xtg2vqywFjsxMDb4jWwBAJM2sP7W1ucGuPlRVDAJhcfNZ3iF/L4V8NW4S7OAYyqs =rpEe -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Message de service
Le 03/11/2014 19:40, Sylvain Vallerot a écrit : Mais tu peux multihomer un bloc assigné sans le sous-allouer, donc qu'est-ce que tu entends par sous-allocation du coup, ta définition ne semble pas être celle du Ripe ? Parce que tu vas oser annoncer un inetnum pas enregistré dans les IRR ?! T'es un grand malade !! Et qu'est-ce que tu entends par désagréger : un LIR qui annonce des subnets du bloc alloué par la RIR seulement, ou un LIR qui annoncer des subnets en plus d'annoncer le bloc alloué par le RIR ? A ma connaissance, il n'y qu'un seul cas qui puisse légitimer le premier, c'est le cas d'un LIR qui n'annonce rien (ni le bloc alloué par le RIR, ni des morceaux de ce bloc). Et les annonces de subnets n'étant pas forcément faites par le LIR mais pouvant être faites par ses clients (cas du multihoming), j'en viens à me demander à qui s'applique la règle que tu édictes. Bref, tes docs de référence m'intéressent. Bref, tu pinaille, comme d'hab, donc ça m'intéresse pas. Pour les docs de référence, t'as bien du lire toutes les docs du RIPE et les BCOP, non ? @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Message de service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/11/2014 19:56, Jérôme Nicolle wrote: Le 03/11/2014 19:40, Sylvain Vallerot a écrit : Mais tu peux multihomer un bloc assigné sans le sous-allouer, donc qu'est-ce que tu entends par sous-allocation du coup, ta définition ne semble pas être celle du Ripe ? Parce que tu vas oser annoncer un inetnum pas enregistré dans les IRR ?! T'es un grand malade !! Un bloc assigné est présent dans le Whois (pour ainsi dire par définition), tu crées un objet route associé et il est parfaitement multihomable. Bref, tu pinaille, comme d'hab, La précision n'est effectivement pas de ce qui encombre ta petite note. En attendant avec des termes corrects et des références tu serais peut-être mieux placé pour nous balancer tes petites leçons. Bref, assez perdu de temps. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRX2LsACgkQJBGsD8mtnREmRAEAxhY22lm1/aArtC28qms4lBx+ V5QEClCFWHkXS+vnsuoA/00fD2J8X2ueD7pwcOi8CugXiZ0pWLlRbqDPwRkgdnM2 =zqun -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Outils pour stress d'équipements réseaux
Essaye avec testpmd du DPDK. Tu peux l'ajuster pour de nombreux scenarios de traffic. C'est également du C abordable. Le 3 nov. 2014 18:57, Christophe t...@stuxnet.org a écrit : Bonjour à tous, Dans le cadre d'évaluation d'équipements réseau (en l’occurrence : Switch niveau 3); Nous souhaiterions pouvoir simuler du trafic réseau à travers ces équipements afin de voir notamment comment se comportent les tables ARP et la TCAM avec un grand nombre de machines dialoguant sur le réseau (adresses MAC et IP différentes) et sur des VLAN différents. La mesure du débit entre deux machines, même si cela fait forcément partie de la démarche, n'est pas nécessairement le point primordial à mesurer ; Ce qui nous intéresse surtout, c'est que l'équipement ne se mette pas à freezer, à jeter du paquet, ou à faire n'importe quoi avec les paquets à cause d'une limite quelconque qui ne serait pas précisée (ou qui serait erronée) dans les specs constructeur. Auriez vous connaissance d'outils ou de techniques, de préférence libres permettant de mener à bien ce genre de tests ? En vous remerciant par avance de toute suggestion ;) . @+ Christophe. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Content Delivery Network (CDN) à la francaise
Bonsoir, Je ressors un vieux sujet de 2006 :)https://www.mail-archive.com/frnog@frnog.org/msg00854.html Nous sommes en 2014, il me paraît intéressant de faire le point / l'état des lieux sur les différents sujets abordés à l'époque (évolution du trafic (plus particulièrement trafic des plateformes de vidéo), peering, transit, déploiement du GPON dans les zones moyennement denses, etc etc) En fait ce qui m'intéresse principalement c'est de savoir comment les différents acteurs et la technologie se sont adaptés à l'évolution du web. Merci. Je pense que les grosses plate-formes de vidéo ont déployé leurs propres réseaux, car les offres de CDN sont quand même de grosses boites opaques assez chères, et il est possible de faire mieux et moins cher en « interne » quand on atteint une certaine masse critique. Voir par exemple Google Caches, Netflix OpenConnect, Dailymotion Caches, etc. … En ce qui concerne le routage du traffic, la méthode évoquée par Damien (GSLB DNS / GeoDNS) s’avère beaucoup trop « simpliste » et ne permet pas de gérer finement la popularité des contenus et l’affinité de caches : un « director » plus évolué (et généralement basé sur des redirections HTTP), couplé à des remontées statistiques de saturation des liens et serveurs est souvent plus pratique pour faire cela de manière fine. Cordialement, Pierre-Yves --- Liste de diffusion du FRnOG http://www.frnog.org/
