Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 FIB (surtout la FIB), pas sur comment tu les mets à jour (qui ne fait pas de BGP en 2019 honnetement). - un serveur Intel avec du dual CPU cadencé à 4Ghz+, en comptant la RAM (minimum 128Go), les disques, les interfaces c'est autour de 8-10k€ - la carte max que tu peux utiliser en PCI3,c'est une dual 40Gbit, que tu peux splitter en 8 x 10G. Pour arriver à l'équivalent du MX, il t'en faut 4, donc 64 lignes PCI (4 x 16) dispo. Du coup la majorité des Xeon W et Scalable sont hors courses, car ils n'ont pas les 32 lignes PCI minimum chacun, ça réduit vachement le choix en CPU. Coté AMD, c'est bon tu as les lignes PCI, mais aucun carte mère pour les exploiter (super les design de CM). Tu n'auras pas de cartes 100G, car le bus PCI3 est limité à 128Gbit pour 16 lignes, mais vu que c'est pour du routage, encore faut-il que tu puisses tenir 1 x 100G en forwarding entre les cartes (ce qui n'est pas le cas). - ok, tu peux mettre des cartes SOC / FPGA et forwarder en local dessus ... mais y a aucune solution catalogue, donc tu es parti pour des mois de dev avec des mecs qui maitrisent bien le sujet (et ça, ça coute toujours plus cher qu'un ASIC sur étagère). Surtout que du dev kernel/bas niveau, ça court pas non plus les rues. Sur le papier, une solution serveur + carte Kalray (Tilera n'existe plus depuis 2014, et EZchip qui les a racheté a ensuite été racheté par Mellanox, eux même absorbé par Nvidia, donc on pourrait éventuellement parler de cartes Nvidia, si elles existaient encore), ça peut marcher. Dans la pratique, ça coutera largement plus cher qu'un ASR ou un MX neuf, licences comprises. Donc, si tu vas sur du soft, il ne faut pas y aller pour l'argent, mais pour le produit, et développer des trucs qui n'existent pas sur du matos hardware Junisco. vMX ou IOSXRv, c'est top pour certains usage : RR, LNS, ce genre de truc ou le CPU est sur le chemin critique. Pour du forwarding N x 10G c'est ... passable. Les perfs du vMX par exemple, si tu fais du L2VPN, ça morfle pas mal. Par contre du LNS sur vMX, c'est vraiment sympa, du RR aussi. Tu as aussi la solution d'un NOS sur du switch baremetal, notamment le Qmran qui peut (pourrait) tenir 1 million de routes v4. Bon, là, pareil, si tu as de quoi payer 20 dev à plein temps, ça ne se reflechit pas, sinon, si tu peux juste acheter le matos, ben un gros QFX ou Nexus ou Arista ... voilà quoi. L'antiDDOS, pareil, super sujet. Faire une diode IPTable pour dropper les attaques par amplification, whynot, mais là encore faut des devs pour 1/ coder /2 maintenir le truc. Alors que pour moins cher, tu as un A10 qui fera le job sur un NP/ASIC line rate, et si tu as pris du Junisco, tu auras du flowspec pour filtrer à la volée 99% des attaques ... sous réserve que tu as les tuyaux pour prendre le traf avant filtre, ce qui, vu les stat des derniers DDOS, est de plus en plus rare. L'antiDDOS c'est un métier maintenant, tu as des pures players sur le sujet, c'est plus un microsujet service provider qu'on peut traiter entre le "je mets du 802.1X sur ma bureautique" et "je mets des ACL pour respecter BCP38". Faut du matos et BEAUCOUP de blé (bien plus que 4 M€). Rien que tes transitaires en N x 100G pour tenir le DDOS, ça te coutera plus que ça sur un ROI 36mois ! Donc choisir du soft ou du hard ? Impossible de répondre simplement, sinon que le hardware full feature est souvent bien moins cher à débit et feature equivalente que les solutions soft. Je ne connais pas de solution soft au niveau d'un Junisco (sauf evidemment IOSXRv et vMX) d'un point de vue nombre de features possibles et utilisables. Après pour faire des routeurs pur BGP, pas de MPLS, pas de flowspec and co, oui les solutions soft fonctionnent, et même pas mal du tout, et jusqu'à N x 10Gbit. L'énorme intérêt d'une solution soft, c'est le TTM quand tu veux LA feature qui existent pas, et que tu as LES devs kernel/C qui savent te la sortir. Vu que tu n'es pas limité par ce que sait faire l'ASIC dessous, ça se compte en semaines là où chez Junisco tu risques d'avoir un lead time à 2 ans voire un "no go car non supporté par l'ASIC". Vu la feature list d'un ASR / MX, c'est quand même vachement rare ce cas là, sauf à être un GAFA avec des fonctionnalités de malade mental genre SDN ultra avancé car chaque POP crache N x 100G de traf (coucou Twitch). Y a pas de hasard si les boites qui bossent sur ces sujets ont 1/ du blé à plus savoir quoi en foutre 2/ une puissance de frappe coté dev inimaginable pour une boite FR. Le sam. 9 nov. 2019 à 04:41, 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é. > >
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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 routées (puisqu'ils passent le test) au lieu d'être droppés, je me trompe ? Le coup du reboot pour changer la config, c'est carrément pas glop. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 l'information dans notre stack, qui agit comme un offload du kernel Linux (comme un ASIC pourrait le faire, sauf que c'est un offload software, qui tourne sur des coeurs dédiés à cela du CPU). Je n'ai pas regardé les perfos non plus avec uRPF activé vs désactivé, mais complétement d'accord avec l'analyse de Benoît sur l'impact de performance (un lookup de plus). C'est bien la stack qui filtre, pas le control plane. uRPF, ca s'active au niveau du data plane (en tout cas c'est comme ca dans le kernel et chez nous: https://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering), donc ca me semble normal de ne rien trouver au niveau FRR. Quelques commentaires pour la compréhension. Je ne vois pas DPDK comme une stack réseau, plus un ensemble de librairies (drivers, gestion de la mémoire, etc.) pour le développement d'applications de data plane, même si le projet contient quelques exemples de stack. Le router de 6WIND n'est pas basé sur VPP, mais sur une stack réseau maison (développée depuis 2005). Ces deux stacks utilisent (ou peuvent utiliser) DPDK. Nicolas Le lun. 11 nov. 2019 à 22:00, Michel Py a écrit : > > 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 renvoie rien ou renvoie null0, tu drop. > > On est bien d'accord. > > [en mode strict : si le lookup de la source renvoie quelque chose d'autre > que l'interface par laquelle le paquet est arrivé] > > > Un lookup de fib se fait à budget à peu près constant (modulo les effets > de cache etc.) > > et ce n'est pas si coûteux : pour prendre un exemple que je connais, le > forwarding path > > IPv4 de VPP avec 2 millions de routes prend ~85 cycles/paquet en > moyenne, c'est ~30% du > > total, ex-aequo avec la gestion du rx/tx de la NIC. Je n'ai pas de > résultats de perf > > sous la main avec uRPF activé, mais je m'attends à avoir le même coût. > > Donc, activer uRPF çà ferait perdre 1/3 ou 1/4 en performance ? C'est pas > si pire. > > > 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 ;) > > Encore des questions bêtes : > Est-ce que VPP c'est dans 6wind ? > > Est-ce que VPP tient des stats pour uRPF (combien de paquets droppés par > interface) ? > Si oui, est-ce qu'il y a une MIB ou un OID pour çà ? > > Est-ce que uRPF c'est dans FRR (c'est bien beau d'avoir le data-plane qui > le fait si le control-plane ne le fait pas). J'ai gouglé et çà n'a pas > donné grand-chose. > > > > >> Michel Py a écrit : > >> Est-ce que l'addresse _source_ est dans la FIB ? > >>Non : ==> drop. On ne sait pas d’où çà vient -> c'est spoofé. > > > Alarig Le Lay a écrit : > > 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 légitimement > des ICMP. > > Dans ce cas là tu mets une route par défaut chez vers un de tes > transitaires, ou tu acceptes la route par défaut d'un de tes transitaires. > > Personellement, je configure ip route 0.0.0.0 0.0.0.0 null0. Non seulement > je ne l'accepte pas, mais en plus je la blackliste. > Si le préfixe n'est pas dans ma FIB, je veux pas en entendre parler. > Avoir un timeout venant d'un réseau non annoncé sur un trace, c'est pas > pire comparé à dropper le spoofing dès l'interface d'entrée. > > > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
>> 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 sera donc limité à 10G. > De plus, je pense que tu perds en perf si tu n’as pas un nombre rond de > cœurs, car tu auras plusieurs queues de la carte par cœur (genre si ta > carte a 16 queues). C'est vrai que ça dépend de la façon dont le trafic est réparti, typiquement sur les headers L3/L4. Un gros tunnel IPIP peut être limité à ce que sait faire un seul coeur si on ne fait pas attention. Dans ce cas on va avoir tendance à faire la répartition sur le trafic encapsulé mais ça nécessite une configuration spécifique. ben --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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É 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 > 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 > > 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
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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 renvoie rien ou renvoie null0, tu drop. On est bien d'accord. [en mode strict : si le lookup de la source renvoie quelque chose d'autre que l'interface par laquelle le paquet est arrivé] > Un lookup de fib se fait à budget à peu près constant (modulo les effets de > cache etc.) > et ce n'est pas si coûteux : pour prendre un exemple que je connais, le > forwarding path > IPv4 de VPP avec 2 millions de routes prend ~85 cycles/paquet en moyenne, > c'est ~30% du > total, ex-aequo avec la gestion du rx/tx de la NIC. Je n'ai pas de résultats > de perf > sous la main avec uRPF activé, mais je m'attends à avoir le même coût. Donc, activer uRPF çà ferait perdre 1/3 ou 1/4 en performance ? C'est pas si pire. > 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 ;) Encore des questions bêtes : Est-ce que VPP c'est dans 6wind ? Est-ce que VPP tient des stats pour uRPF (combien de paquets droppés par interface) ? Si oui, est-ce qu'il y a une MIB ou un OID pour çà ? Est-ce que uRPF c'est dans FRR (c'est bien beau d'avoir le data-plane qui le fait si le control-plane ne le fait pas). J'ai gouglé et çà n'a pas donné grand-chose. >> Michel Py a écrit : >> Est-ce que l'addresse _source_ est dans la FIB ? >>Non : ==> drop. On ne sait pas d’où çà vient -> c'est spoofé. > Alarig Le Lay a écrit : > 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 légitimement des > ICMP. Dans ce cas là tu mets une route par défaut chez vers un de tes transitaires, ou tu acceptes la route par défaut d'un de tes transitaires. Personellement, je configure ip route 0.0.0.0 0.0.0.0 null0. Non seulement je ne l'accepte pas, mais en plus je la blackliste. Si le préfixe n'est pas dans ma FIB, je veux pas en entendre parler. Avoir un timeout venant d'un réseau non annoncé sur un trace, c'est pas pire comparé à dropper le spoofing dès l'interface d'entrée. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 flux ne passera que par un seul cœur, et sera donc limité à 10G. De plus, je pense que tu perds en perf si tu n’as pas un nombre rond de cœurs, car tu auras plusieurs queues de la carte par cœur (genre si ta carte a 16 queues). -- Alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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 entière. 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. Si le lookup de la source ne renvoie rien ou renvoie null0, tu drop. Un lookup de fib se fait à budget à peu près constant (modulo les effets de cache etc.) et ce n'est pas si coûteux : pour prendre un exemple que je connais, le forwarding path IPv4 de VPP avec 2 millions de routes prend ~85 cycles/paquet en moyenne, c'est ~30% du total, ex-aequo avec la gestion du rx/tx de la NIC. Je n'ai pas de résultats de perf sous la main avec uRPF activé, mais je m'attends à avoir le même coût. 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 ;) ben --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 légitimement des ICMP. Regarder si c’est en null0 suffit largement (même si faire de l’uRPF sur les liens vers l’extérieur est une source d’ennuis à mon avis). -- Alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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 bonne idée. Car il va falloir embaucher un profil capable de > comprendre et de débugger: le fonctionnement > matériel d'un serveur/CPU moderne, le noyau, les drivers réseau et le FRR ou > Bird. Donc oui vous allez économiser > en licence, mais je ne pense pas qu'un profil «kernel C» soit au même prix > qu'un admin Cisco/Juniper. +1 Je suis dans ce cas d'ailleurs : je n'ai ni le temps ni la compétence, ni la taille pour justifier un ingé qui fait du kernel C. Au premier problème, faut que je demande de l'aide. > Par contre dans le cas d'un routeur, avant la notion de bande passante c'est > le nombre de paquets par > seconde (pps) routé qui est l'unité de base. C'est-à-dire que si j'installe 2 > interfaces 100Gb sur > serveur, le premier exercice va être de vérifier comment il réagit, non pas > en recevant un flux à > 100Gb/s, mais plutôt 148 Millions pps en cas de DoS… et ce n'est pas la même > chose. Exactement. > 3. Concernant la gestion d'un DoS, à partir de 10Mpps va falloir utiliser des > cartes réseau disposant de > fonctionnalités d'assistance matérielle comme un firewall supportant le > line-rate. Je l'ai testé sur une > carte Chelsio 40Gb en lui envoyant un DoS d'environ 50Mpps et elle a fait > parfaitement le boulot (j'ai > juste eu besoin d'aide de Chelsio pour le paramétrage car la documentation > est très rare sur le sujet). > Maintenant il y a d'autre problématique concernant la limite des règles de ce > firewall en elle même. 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 entière. Le Paquet arrive. Est-ce que l'addresse _source_ est dans la FIB ? Non : ==> drop. On ne sait pas d’où çà vient -> c'est spoofé. Oui : ==> Est-ce que la FIB pointe vers null0 ? ==> Oui : Drop. C'est un bogon, un martien, ou un préfixe blacklisté. ==> Non : Continue. >> Michel Py a écrit : >> Le paquet arrive. >> Qui c'est qui décode l'adresse _source_ et regarde si elle est dans la FIB ? > Combien de cycles çà prend ? > Radu-Adrian Feurdean a écrit : > Le kernel ou DPDK. > FRR calcule la FIB et la pousse au bon endroit. Est-ce que DPDK supporte uRPF ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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 plane. FRR ne touche pas les paquets !!! FRR c'est control plane. Regardons la logique : Le paquet arrive. Qui c'est qui décode l'adresse _source_ et regarde si elle est dans la FIB ? Combien de cycles çà prend ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 Netflix… mais je viens de l'ancien monde (Cisco/Juniper chez gros telco) et je passe mon temps libre à jouer avec du routeur logiciel. Donc je vais en profiter pour quelques précisions et avertissements: 1. Oui il est possible de servir du 200Gb/s TLS sur des serveurs classiques. Les améliorations étant reversées dans FreeBSD -head (branche de dev) c'est dispo pour tout le monde. Ensuite il ne s'agit que de la partie OS, reste maintenant à faire les bons choix matériels et l'optimisation du serveur web (nginx dans notre cas). 2. Servir de la VOD est assez simple car les paquets émis font la taille maximale permise, donc le travail d'optimisation se concentre essentiellement sur les problèmes de bande passante (disque -> carte réseau). Par contre dans le cas d'un routeur, avant la notion de bande passante c'est le nombre de paquets par seconde (pps) routé qui est l'unité de base. C'est-à-dire que si j'installe 2 interfaces 100Gb sur serveur, le premier exercice va être de vérifier comment il réagit, non pas en recevant un flux à 100Gb/s, mais plutôt 148 Millions pps en cas de DoS… et ce n'est pas la même chose. 3. Concernant la gestion d'un DoS, à partir de 10Mpps va falloir utiliser des cartes réseau disposant de fonctionnalités d'assistance matérielle comme un firewall supportant le line-rate. Je l'ai testé sur une carte Chelsio 40Gb en lui envoyant un DoS d'environ 50Mpps et elle a fait parfaitement le boulot (j'ai juste eu besoin d'aide de Chelsio pour le paramétrage car la documentation est très rare sur le sujet). Maintenant il y a d'autre problématique concernant la limite des règles de ce firewall en elle même. 4. Et le dernier point: 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 bonne idée. Car il va falloir embaucher un profil capable de comprendre et de débugger: le fonctionnement matériel d'un serveur/CPU moderne, le noyau, les drivers réseau et le FRR ou Bird. Donc oui vous allez économiser en licence, mais je ne pense pas qu'un profil «kernel C» soit au même prix qu'un admin Cisco/Juniper. Cordialement, Olivier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 router les paquets. Si les routes vont dans la table du kernel, ca sera le kernel, avec 2-5 fois moins de perf. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 lieu de le donner à Junisco c'est kif-kif, mais d'un autre coté si tu as décider de payer Arbor de toute façon, çà a de l'allure de ne pas payer le loyer à Junisco aussi. Matthieu là t'as eu l'argument massue. Dans tous les gens que je connais qui regarde du coté 6Wind, il n'y en a aucun qui peuvent s'offrir Arbor. Tu es un cas intéressant. Bienvenue à poser des questions techniques sur la liste du FRnOG. Avant de demander, tu ne savais pas quoi faire. Maintenant, il y a tellement de solutions que tu ne sais toujours pas quoi faire :P Au lieu de tirer à pile ou face, maintenant tu décides. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 n'essaie pas de nous empapaouter en vendant un routeur jetable a 500K routes qu'il va falloir jeter pour acheter un autre 1M routes qu'il va falloir jeter aussi pour acheter le 2M routes Ceci dit, j'ai quand même bien des doutes techniques. Je prends un exemple que je vais tester bientôt en hard : uRPF. 2 Questions : 1. Comment se comporte ton produit quand un paquet arrive, qu'il y a une route en FIB pour la source du paquet qui pointe vers null0, et que uRPF est activé en mode loose ? Est-ce que le paquet est jeté par terre dès que possible ? Sur Cisco il y a une exception dans l'implémentation uRPF même en mode loose disant que si la route dans la FIB pointe vers null0 le paquet est droppé. 2. C'est droppé par DPDK ? Ou çà va remonter jusqu'à FRR et là je veux bien voir comment çà se comporte à 50 Mpps avec un botnet de sources innombrables et 100K routes vers null0 dans la FIB (cas courant chez moi). Ton produit est sympa. J'ai pas entendu tellement de critiques, et sur cette liste quand on pense qu'un produit c'est de la merde on ne se gêne pas pour le dire. Ceci étant dit, il y a des cas de figure ou tu peux pas te battre contre la TCAM et les ASIC qui vont avec. Les cartes réseau qui supportent DPDK, est-ce qu'elles contiennent toute la FIB ? est-ce qu'elles implémentent Null0 en hardware ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 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 > 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 > >>
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 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 > 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
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 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=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/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 électrique : quitte à investir, qu'il le fasse pour du long terme). Encore merci On Sat, Nov 9, 2019, 13:56 Michel Py wrote: > > 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 contrat et qu'on supporte en interne, il y a gougleu. Le > problème que tu as, il y a pas mal de chance que quelqu'un d'autre l'ai eu > aussi, avec Junisco to augmentes largement tes chances que la résolution > soit déjà connue. Et si tu as besoin de support externe, c'est plus facile > à trouver pour Junisco que pour raspi. > > La CHIAAS, tout le monde ne l'a pas; çà a du sens de travailler sur > quelque chose de répandu. > Dans ta situation, j'aurais tendance à mettre du Cisco ASR9001. Pas parce > que j'aime Cisco, parce que je comprends comment çà marche. > > Michel. > > J'ai fait les maths pour dessous : Junisco = 71% > > > On Thu, Nov 7, 2019 at 11:59 AM Edward Dore < > edward.d...@freethought-internet.co.uk> wrote: > > I just grabbed the following from our routers connected to LINX LON1, > > LINX LON2, LINX Manchester and LONAP (so this data is very UK centric): > > 557 Cisco Systems, Inc > 553 Juniper Networks > 51 Routerboard.com > 51 Brocade Communications Systems, Inc. > 49 Arista Networks > 40 Unknown > 38 Intel Corporate > 36 HUAWEI TECHNOLOGIES CO.,LTD > 31 Globalscale Technologies, Inc. > 20 Super Micro Computer, Inc. > 20 Alcatel-Lucent IPD > 15 Nokia > 14 Hewlett Packard > 10 VMware, Inc. > 10 Ubiquiti Networks Inc. > 10 Sunrich Technology Limited > 10 Extreme Networks, Inc. >7 Dell Inc. >5 IEEE Registration Authority >4 Intel Corporation >4 HotLava Systems, Inc. >3 FireBrick Limited >2 Raspberry Pi Foundation >2 Nexcom International Co., Ltd. >2 Microsoft Corporation >2 Mellanox Technologies, Inc. >2 ICP Electronics Inc. >2 Hewlett Packard Enterprise >2 BSkyB Ltd >1 Xensource, Inc. >1 XEROX CORPORATION >1 Solarflare Communications Inc. >1 SILICOM, LTD. >1 MIX s.r.l. >1 LANNER ELECTRONICS, INC. >1 GIGA-BYTE TECHNOLOGY CO.,LTD. >1 DriveCam Inc >1 DIGITAL EQUIPMENT CORPORATION >1 Agile Systems Inc. > On Sat, Nov 9, 2019, 13:56 Michel Py wrote: > > 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 contrat et qu'on supporte en interne, il y a gougleu. Le > problème que tu as, il y a pas mal de chance que quelqu'un d'autre l'ai eu > aussi, avec Junisco to augmentes largement tes chances que la résolution > soit déjà connue. Et si tu as besoin de support externe, c'est plus facile > à trouver pour Junisco que pour raspi. > > La CHIAAS, tout le monde ne l'a pas; çà a du sens de travailler sur > quelque chose de répandu. > Dans ta situation, j'aurais tendance à mettre du Cisco ASR9001. Pas parce > que j'aime Cisco, parce que je comprends comment çà marche. > > Michel. > > J'ai fait les maths pour dessous : Junisco = 71% > > > On Thu, Nov 7, 2019 at 11:59 AM Edward Dore < > edward.d...@freethought-internet.co.uk> wrote: > > I just grabbed the following from our routers connected to LINX LON1, > > LINX LON2, LINX Manchester and LONAP (so this data is very UK centric): > > 557 Cisco Systems, Inc > 553 Juniper Networks > 51 Routerboard.com > 51 Brocade Communications Systems, Inc. > 49 Arista Networks > 40 Unknown > 38 Intel Corporate > 36 HUAWEI TECHNOLOGIES CO.,LTD > 31 Globalscale Technologies, Inc. > 20 Super Micro Computer, Inc. > 20 Alcatel-Lucent IPD > 15 Nokia > 14 Hewlett Packard > 10 VMware, Inc. > 10 Ubiquiti Networks Inc. > 10 Sunrich Technology Limited > 10 Extreme Networks, Inc. >7 Dell Inc. >5 IEEE Registration Authority >4 Intel Corporation >4 HotLava Systems, Inc. >3 FireBrick Limited >2 Raspberry Pi Foundation >2 Nexcom International Co., Ltd. >2 Microsoft Corporation >2 Mellanox Technologies, Inc. >2 ICP Electronics Inc. >2 Hewlett Packard Enterprise >2 BSkyB Ltd >1 Xensource, Inc. >1 XEROX CORPORATION >1 Solarflare Communications Inc. >1 SILICOM, LTD. >1 MIX s.r.l. >1 LANNER ELECTRONICS, INC. >1 GIGA-BYTE TECHNOLOGY CO.,LTD. >1 DriveCam Inc >1 DIGITAL EQUIPMENT CORPORATION >1 Agile
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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 contrat et qu'on supporte en interne, il y a gougleu. Le problème que tu as, il y a pas mal de chance que quelqu'un d'autre l'ai eu aussi, avec Junisco to augmentes largement tes chances que la résolution soit déjà connue. Et si tu as besoin de support externe, c'est plus facile à trouver pour Junisco que pour raspi. La CHIAAS, tout le monde ne l'a pas; çà a du sens de travailler sur quelque chose de répandu. Dans ta situation, j'aurais tendance à mettre du Cisco ASR9001. Pas parce que j'aime Cisco, parce que je comprends comment çà marche. Michel. J'ai fait les maths pour dessous : Junisco = 71% > On Thu, Nov 7, 2019 at 11:59 AM Edward Dore > wrote: > I just grabbed the following from our routers connected to LINX LON1, > LINX LON2, LINX Manchester and LONAP (so this data is very UK centric): 557 Cisco Systems, Inc 553 Juniper Networks 51 Routerboard.com 51 Brocade Communications Systems, Inc. 49 Arista Networks 40 Unknown 38 Intel Corporate 36 HUAWEI TECHNOLOGIES CO.,LTD 31 Globalscale Technologies, Inc. 20 Super Micro Computer, Inc. 20 Alcatel-Lucent IPD 15 Nokia 14 Hewlett Packard 10 VMware, Inc. 10 Ubiquiti Networks Inc. 10 Sunrich Technology Limited 10 Extreme Networks, Inc. 7 Dell Inc. 5 IEEE Registration Authority 4 Intel Corporation 4 HotLava Systems, Inc. 3 FireBrick Limited 2 Raspberry Pi Foundation 2 Nexcom International Co., Ltd. 2 Microsoft Corporation 2 Mellanox Technologies, Inc. 2 ICP Electronics Inc. 2 Hewlett Packard Enterprise 2 BSkyB Ltd 1 Xensource, Inc. 1 XEROX CORPORATION 1 Solarflare Communications Inc. 1 SILICOM, LTD. 1 MIX s.r.l. 1 LANNER ELECTRONICS, INC. 1 GIGA-BYTE TECHNOLOGY CO.,LTD. 1 DriveCam Inc 1 DIGITAL EQUIPMENT CORPORATION 1 Agile Systems Inc. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 avis si ce côté software (FRR, vMX & co) peut décoller grâce aux cartes comme Tilera, Kalray & co; et finalement remplacer le hardware. Pour le moment, c'est out et elles restent encore dédiée à Suricata/Kargus/Haetae. Pour l'acronyme, c'est pas faux. Le lien de Netflix c'était surtout la surprise de l'optimisation faite par eux pour atteindre de telles valeurs. @Michel: je lui transmets après c'est lui qui décidera. Ne pas confondre entre les 2M déjà débloqués et un global de 4M€ pour la phase de lancement infra de l'extension d'activité (comprendre uniquement Europe) : étape par étape, l'argent est là mais pas tous les chantiers en même temps. On remplace le raspi par un Intel devenu asthmatique à cause des patchs et on voit le résultat. Peut-être que le raspi s'en sort mieux. Bonne journée à tous --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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. http://freerouter.nop.hu/screen.html --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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 license annuelle a payer pour l'usage du routeur", Tu serais pas un peu langue de pute, sur les bords ? :P +1000 > politique commercial vers laquelle Cisco (et peut etre d'autres) semblent > s'orienter C'est pas pire que la C.H.I.A.A.S :P Je n'approuve pas, mais faut aussi comprendre l'écosystème dans lequel on vit. > la partie BGP est faite en software, quel que soit le fabriquant. > le seul truc ou la distinction hardware/software se fait, c'est le fait > d'avoir un accélérateur de manipulation de l'entête du paquet, qui est > configuré par le software, et réalise la fonction de routage du paquet C'est très vrai, mais le control-plane n'est que la moitié de l'équation. On peut faire un control-plane de qualité avec un raspi. Les veaux qui écrivent un control-plane en Java, leur machin va merder. Le problème, c'est que même les gens qui écrivent un control-plane de qualité, le data-plane en soft çà sera jamais à la hauteur de l'ASIC de Junisco. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 le mieux en routeur BGP : hardware or software ? en fait, la question est compliquée par le fait qu'il n'existe pas de BGP en hardware. la partie BGP est faite en software, quel que soit le fabriquant. le seul truc ou la distinction hardware/software se fait, c'est le fait d'avoir un accélérateur de manipulation de l'entête du paquet, qui est configuré par le software, et réalise la fonction de routage du paquet 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 license annuelle a payer pour l'usage du routeur", politique commercial vers laquelle Cisco (et peut etre d'autres) semblent s'orienter Raph --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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=Netflix-NUMA-FreeBSD-Optimized C'est de la VOD, ton truc ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
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 de travaux. Grosse particularité : 0 RJ45 excepté pour les BMC et les bureaux (POE inclus). 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. Activité actuelle : infra louée avec IP, anti-DDOS, bande passante, absolument 0 possibilité de mettre les mains dans le moteur. Un changement sur l'anti-DDOS = ticket pour demander et le pire c'est qu'il faut absolument tout expliquer de 0 sans voir l'interface de configuration ainsi que les possibilités offertes. Très pratique si c'est pour une personne qui ne l'a jamais vue. Même le DNS est managé par le fournisseur... Ça en dit long : entreprise sans équipe réseau. 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. 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. Lieu des DC : USA (historique), Europe (historique + nouvelle) et Brésil (à l'étude juste pour le stockage des backups et infra virtualisation locale pour arrêter de remonter aux USA). Pour le raspi, j'oserais pas même si je me demande ce qu'il est possible de faire avec un RISC-V comme le HiFive Unleashed ( https://www.sifive.com/boards/hifive-unleashed) ou les prochains plus puissant. 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 ? 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 ) Thanks On Fri, Nov 8, 2019, 22:52 Michel Py wrote: > > 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 full-feed ? > Budget ? S'il y a les sous, faut être ouf pour prendre du soft. > > Parce que si c'est 100M et 2 full-feed, un raspi4 avec 4 Gigs de mémoire > çà passe (juste). > > Michel. > > --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Routeur BGP matériel ou logiciel
> 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 full-feed ? Budget ? S'il y a les sous, faut être ouf pour prendre du soft. Parce que si c'est 100M et 2 full-feed, un raspi4 avec 4 Gigs de mémoire çà passe (juste). Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
