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 intéressant d'utiliser des cartes d'offload pour d'autres cas, comme IPsec, OVS, de la QoS, etc. Au passage, Tilera ne me semble plus d'actualité (racheté par EZChip, puis Mellanox). Nous sommes en train regarder pour supporter d'AMD (Epyc 2). Ca devrait arriver courant 2020. Pour la RAM, 16GB suffiront pour ce besoin. Tu peux prévoir 24GB ou 32GB si le but n'est pas d'optimiser au max le coût du hardware. Idéalement, il faut N barrettes, N étant le nombre de canaux mémoires du CPU. Sur un Skylake, en général 6 canaux, donc je conseillerais 6x4=24GB (largement suffisant pour deux full route) ou 6x8=48GB. Nicolas Le dim. 10 nov. 2019 à 23:23, Florent CARRÉ <colund...@gmail.com> a écrit : > 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 à > d'autres. > > Est-ce que 6wind peut utiliser de la Tilera, Kalray ou autre afin d'offload > sur la carte? > > Qu'en est-il si au lieu de mettre du Xeon, on part sur de l'AMD > (Threadripper ou plutôt Epyc) ? > > En terme de ram, que recommanderais tu ? > Imaginons pour 2 liens fibre optique donc full view... (chaques ports de la > carte réseau en 10/25/40 GB). > Sur les routeurs hardware, il y a toujours du manque de ram, ici, on peut > facilement mettre 64 voir 128GB. > > Encore merci > > On Sun, Nov 10, 2019, 16:59 Matthieu Texier <matth...@pragma-security.com> > wrote: > > > 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 > > de manière tout à fait honorable (mieux que sur un Mikrotik dont la stack > > netflow est pour le moins étonnante). > > > > De plus, je crois comprendre qu’il s’agit d’hébergement de sites qui > > prennent du DDoS régulièrement auquel cas, il faudra prendre un > protection > > anti-DDoS permanente en amont et pas en mode BGP off ramp lors de > > détection. Donc le trafic arrivant sur ce routeur sera purgé des > attaques à > > saturation. > > > > Maintenant, il faut prendre la problématique dans son ensemble, en > déduire > > une architecture de bout en bout et un TCO … > > > > Prêchant aussi pour ma paroisse et n’ayant pas toutes les considérations > à > > prendre en compte, c’est un avis purement informatif ! > > > > My 2 cents, > > Matthieu. > > > > > > > On 10 Nov 2019, at 22:15, Nicolas Harnois <nicolas.harn...@6wind.com> > > wrote: > > > > > > 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 sans aucun problème de nos jours tenir 40Gbps > de > > > trafic, et ce avec des paquets de 64B. > > > D'une part, la capacité de forwarding d'une stack bien écrite basée sur > > > DPDK comme la nôtre (6WIND) ou VPP dépasse les 10Mpps par coeur dédié > au > > > data plane. > > > 40Gbps, c'est 60Mpps @ 64B, donc un XEON pas trop cher fait le job pour > > ce > > > type de débit. > > > > > > Ensuite, pour résister à un DDoS, on peut mettre en place des > mécanismes > > de > > > protection d'overload. > > > On a déjà implémenté de la QoS ingress software dans notre routeur. En > > > gros, on monitore le remplissage de la queue hardware de réception, et > si > > > on dépasse un threshold, on choisit de préserver les paquets de > contrôle > > > (BGP, ARP, VRRP, etc.). > > > Nous sommes en train d'implémenter un offload hardware de cette QoS > > ingress > > > (quand les NICs le supporte). C'est à dire que c'est le NIC qui fait la > > > classification des protocoles à protéger, et met ces paquets dans une > > queue > > > dédiée, dépilée par le software en priorité. Une API très complète a > été > > > développée dans DPDK pour cela (rte_flow pour les connaisseurs). > > > > > > Bref, en presque 2020, il est grand temps de considérer des routeurs > > > software comme alternative crédible au hardware. > > > Je prêche évidemment pour ma paroisse, mais le produit pouvant être > > évalué > > > gratuitement, vous pouvez vous faire vous-même votre opinion. > > > 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... > > > > > > Nicolas > > > > > > Le sam. 9 nov. 2019 à 07:21, Michel Py < > > mic...@arneill-py.sacramento.ca.us> > > > a écrit : > > > > > >>> 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) > > >> (c) (TM) Kevin Chailly, si je me rappelle correctement. > > >> La phonétique de l'acronyme a résonné avec pas mal d'entre nous ! > > >> > > >> 2M€ c'est des cacahouètes sur un campus de taille. Un réseau dans 3 > RIR > > >> différentes et tu parles de routeur soft ? > > >> > > >>> Pour le raspi, j'oserais pas > > >> > > >> A 10 G, moi non plus :P a 100M, je le ferais pas pour la prod, je le > > >> ferais à grand risque pour un bouchon de Stroh, si j'ai le temps. > > >> > > >>> La seule info qu'il a eu de l'infra actuellement louée, c'est qu'elle > > est > > >>> full Cisco et date d'il y a pas mal de temps (+ de 10 ans) et 0 IPv6. > > >> > > >> Zéro surprise. Et le problème n'est ni Cisco ni l'âge ni le 0 IPv6. > Ton > > >> problème, c'est la culture d'entreprise. > > >> Infra _louée_ ? Cà me fait bien rigoler, par Toutatis. Oh dans mon > > paquet > > >> poste ce matin, La fille de Vercingétorix. Il était temps. > > >> > > >> > > >>> Petite histoire, l'extension d'activité c'est le fils qui la prend en > > >> main (la > > >>> lance en Europe pour commencer) et surtout il ne veut plus que la > > partie > > >>> historique de son père soit hors contrôle donc tout reprendre de 0 en > > >> interne. > > >> > > >> Je veux pas être méchant, mais je suis pas convaincu par ce que tu as > > >> expliqué de ton business model. > > >> > > >> > > >>> PS: Quel est l'avantage d'utiliser vMX vs FRR out autre dans le cas > où > > >> il n'y > > >>> aurait pas l'argent de disponible ou petit trafic ? Lequel serait le > > >> mieux ? > > >> > > >> Dans ma logique, vMX n'a pas de place (sans taper sur le vendeur, > pareil > > >> pour tout le monde). Soit tu as les sous et tu prends du hard, soit tu > > as > > >> des centimes et tu prends 6Wind, soit tu vends ton slip pour acheter > un > > >> serveur d'occase et tu fais FRR. > > >> > > >> > > >>> Trafic: 10G (mais prévoir évolution en 40G) en terme de trafic comme > > >> c'est pour > > >>> récupérer et étendre l'activité actuelle sachant qu'il y a des ddos > en > > >> non-stop. > > >> > > >> 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. > > >> > > >> > > >>> PS2: Netflix utilisent également des AMD et surprend sur les > > >> performances réseaux : > > >>> > > >> > > > https://www.phoronix.com/scan.php?page=news_item&px=Netflix-NUMA-FreeBSD-Optimized > > >> > > >> C'est de la VOD, ton truc ? > > >> > > >> Michel. > > >> > > >> > > >> --------------------------- > > >> Liste de diffusion du FRnOG > > >> http://www.frnog.org/ > > >> > > > > > > --------------------------- > > > Liste de diffusion du FRnOG > > > http://www.frnog.org/ > > > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
