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 de
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" a écrit :
> Bonjour à tous,
>
> Dans le cadre d'évaluation d'équipements réseau (en l’occurrence : Switch
> niveau 3); Nous souhaiterions pouv
-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
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
-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
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
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
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
-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
-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
-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 ?
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/
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
On Mon, Nov 03, 2014 at 02:37:04PM +0100,
Clement Cavadore 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://ww
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-1
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
16 matches
Mail list logo
