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/
signature.asc
Description: Message signed with OpenPGP
