Analyse basique du truc :
- un MX204, ça va couter autour de 15-20k€ full feature
- tu as 8 x 10G + 4 x QSFP28, au max tu peux avoir 4 x 100G ou 24 x 10G
avec 32 millions de routes, 6500 VRF
BGP, c'est du control plane, donc OSEF, tu ne dimensionnes pas un routeur
sur ça, mais sur sa RIB et sa
> Nicolas Harnois a écrit :
> https://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering
Il n'y a rien qui parle de la gestion des paquets qui ont une entrée dans la
FIB. D'après ce que je comprends, les paquets qui ont une entrée dans la FIB
qui pointe vers null0 vont être
Michel,
en effet, la FIB est stockée en mémoire, et c'est le data plane software
qui y accède.
Ca n'est pas le NIC qui stocke la FIB, on reviendrait certainement au même
problème de scalabilité qu'avec les ASICs.
Dans notre cas, FRR insère la FIB dans le kernel, et nous synchronisons
>> VPP avec 2 millions de routes tient ~20Mpps par coeur avec des paquets
>> de 64-bytes sur Xeon/Skylake, je dirais qu'avec uRPF ça doit tenir
>> ~15Mpps par coeur. Avec 10 coeurs tu tiens 100Gbps ;)
> À condition d’avoir dix flux différents, chaque flux ne passera que par
> un seul cœur, et
Bonsoir Florent,
je vois mal l'intérêt d'utilser des cartes d'offload spécifiques pour ce
cas d'utilisation de routage simple.
Le data plane ne fait que du forwarding IP, et les offloads des NICs
standards (RSS, classification, checksum, etc.) suffisent à mon avis.
Il peut être néanmoins
> Benoît Ganne a écrit :
> Si je me trompe pas, uRPF c'est juste vérifier qu'il y a bien une route
> qui permet d'atteindre la source. Donc c'est juste un lookup de FIB
> supplémentaire : il faut faire un lookup sur la destination et sur la source.
Exactement.
> Si le lookup de la source ne
On lun. 11 nov. 21:02:49 2019, Benoît Ganne wrote:
> VPP avec 2 millions de routes tient ~20Mpps par coeur avec des paquets
> de 64-bytes sur Xeon/Skylake, je dirais qu'avec uRPF ça doit tenir
> ~15Mpps par coeur. Avec 10 coeurs tu tiens 100Gbps ;)
À condition d’avoir dix flux différents, chaque
> C'est bien là ou tous les routeurs soft s'effondrent : si ce qu'on
> fait peut être off-loadé par la carte réseau tout est bon, sinon
> c'est la cata.
> Dans ton expérience, est-ce qu'il y a une carte réseau
> sur le marché qui fait uRPF à line-rate ? uRPF, c'est forcément
> regarder la FIB
On 11/11/2019 19:23, Michel Py wrote:
> Est-ce que l'addresse _source_ est dans la FIB ?
>Non : ==> drop. On ne sait pas d’où çà vient -> c'est spoofé.
Tu vas te retrouver à rejeter des IPs légitimes. Il y a quelques
backbones qui utilisent des IPs publiques non annoncées et qui envoient
> Olivier Cochard-Labbé a écrit :
Merci pour ton retour.
> Je ne suis pas sûr que de se lancer dans une solution de routeur logiciel
> «DIY» (c'est-à-dire autre qu'un
> 6Wind/Netgate TNSR ou équivalent acheté clé en main) dans une optique de
> faire essentiellement des économies
> soit une
On Mon, Nov 11, 2019, at 17:38, Michel Py wrote:
> Le paquet arrive.
> Qui c'est qui décode l'adresse _source_ et regarde si elle est dans la FIB ?
> Combien de cycles çà prend ?
Le kernel ou DPDK.
FRR calcule la FIB et la pousse au bon endroit.
---
Liste de diffusion du
> Radu-Adrian Feurdean a écrit :
> Repete apres moi Michel, :
> FRR ne touche pas les paquets !!!
> FRR c'est control plane
FRR ne touche pas les paquets !!! FRR c'est control plane.
FRR ne touche pas les paquets !!! FRR c'est control plane.
FRR ne touche pas les paquets !!! FRR c'est control
On Sat, Nov 9, 2019 at 7:22 AM Michel Py
wrote:
>
> > PS2: Netflix utilisent également des AMD et surprend sur les
> performances réseaux :
> >
> https://www.phoronix.com/scan.php?page=news_item=Netflix-NUMA-FreeBSD-Optimized
>
>
Bonjour,
je suis dans l'équipe qui travaille sur ce sujet chez
On Mon, Nov 11, 2019, at 02:09, Michel Py wrote:
> 2. C'est droppé par DPDK ? Ou çà va remonter jusqu'à FRR et là je veux
Repete apres moi Michel, :
FRR ne touche pas les paquets !!!
FRR c'est control plane
Si FRR injecte les routes dans la table de routage DPDK, c'est forcement DPDK
qui va
Bonjour Florent,
> Florent CARRÉ a écrit :
> et Arbor restera de la partie au niveau des transitaires.
Cà c'est un très bon argument pour se pencher vers un routeur soft. Si t'as
Harbor devant, çà devient plus glop.
Il y a une partie de moi qui dit que donner le fric à Arbor tous les mois au
Salut Nicolas,
> Nicolas Harnois a écrit :
> D'autant plus que pour du border router, on ne se pose pas la question du
> temps de convergence
> sur un XEON avec FRR, ni du nombre de routes qu'on va pouvoir installer dans
> la FIB en 2023...
Et on est tous très appréciatifs d'un vendeur qui
Hello Nicolas et Matthieu,
Intéressantes informations, merci à vous 2.
@Matthieu:
C'est plus complexe que cela (pas seulement de l'hébergement de sites web)
et Arbor restera de la partie au niveau des transitaires.
@Nicolas:
Je préfère poser les questions en public parce que ça pourrait servir
J’approuve aussi ce design de routeur logiciel. C’est une bonne solution que
l’on doit positionner à bon escient ce qui semble être le cas ici. Le rapport
cout / performance / souplesse est un avantage dans ce type de situation. On
peut même faire de la télémétrie sur ce type de configuration
Hello,
> DDOS == routeur hard. Sans critiquer les gens très motivés come 6wind qui
font des trucs sympas avec FRR et DPDK, il n'y a aucun routeur soft qui ne
va pas s'effondrer avec une attaque DDOS basée sur PPS. Pas à 40G.
Mais pourquoi? Un peu lassé d'entendre cela!
Un routeur software peut
Effectivement, niveau support vendor, ça ne se fera pas sans.
Ensuite le débat Cisco/Juniper, c'est perso. Je préfère Juniper mais pour
autant je ne peux pas crier si je vois un Ciena ou Arista ou autre tant que
ça fait ce pourquoi c'est fait sans coûter un bras par an (license et
facture
> Florent CARRÉ a écrit :
> Merci tout le monde et surtout ça confirme ce que je pensais, il faut
> rester sur du hardware en 2020-2021 dès qu'on le peut.
Junisco est une marque populaire, voir plus bas.
Il y a une bonne raison de prendre du Junisco : quand on choisit de ne pas
l'avoir sous
Hello,
Merci tout le monde et surtout ça confirme ce que je pensais, il faut
rester sur du hardware en 2020-2021 dès qu'on le peut.
Non, ce n'est pas pour de la vidéo et ce n'est pas pour moi.
Je n'ai aucun intérêt à part vouloir aider un ami.
La question était plus personnelle pour avoir un
Le sam. 9 nov. 2019 à 08:11, Michel Py
a écrit :
>
> On peut faire un control-plane de qualité avec un raspi. Les veaux qui
> écrivent un control-plane en Java, leur machin va merder.
Je ne sais pas. Des control-plane en java j'en connais qu'un, et a
priori il n'est pas si pire.
> Raphaël Jacquot a écrit :
> a la fin de la journée, les questions à se poser, c'est plutôt :
> "quel indien a (mal) écrit le code du routeur de $société" et
> "quel indien te répondra au téléphone quand ton routeur déconnera"
> pour ajouter de la complexité dans le choix :
> "y aura t'il une
Le 09/11/2019 à 04:40, Florent CARRÉ a écrit :
> Hello tout le monde,
>
> Je lis attentivement la mailling list et au lieu de risquer un troll sur un
> sujet existant, je préfère en lancer un dédié.
>
> Dans l'hypothèse d'une structure qui pense se lancer en 2020-2021,
> qu'est-ce qui serait
> Florent CARRÉ a écrit :
> En fait, il y a 2M€ déjà prêt pour l'infra totale de base
Pour la modeste somme de 400K€ je propose mes services :P
> Ça en dit long : entreprise sans équipe réseau.
On a un acronyme pour çà sur cette liste : Cloud Hosted Infrastructure As A
Service (C.H.I.A.A.S)
Hello Michel,
En fait, il y a 2M€ déjà prêt pour l'infra totale de base
(routeurs,switches,serveurs) et bien évidemment les travaux dans le premier
bâtiment (2 bâtiments avec fibres entre eux).
Le budget global maximum est de 4M€, pour les bâtiments ça sera plus
ventilation et sécurité en terme
> Florent CARRÉ a écrit :
> Dans l'hypothèse d'une structure qui pense se lancer en 2020-2021, qu'est-ce
> qui serait le mieux en routeur BGP : hardware or software ?
Hardware sans aucun doute. Mais tu ne poses pas la bonne question :
Quelle bande passante, combien d'interfaces, et combien de
28 matches
Mail list logo
