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 <mic...@arneill-py.sacramento.ca.us> 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/
