Bonjour Xavier,

C'est marrant j'ai le même raisonnement...
> Pour un client qui n'as pas besoin de bande passante ni de gigue stable
> (quoique)...
> On a essayé 6wind (parce qu'il y a du support).... dans de VM.
>

C'est dommage de continuer à penser qu'on ne peut pas atteindre de débits
intéressants sur du serveur générique.
En routage, on peut faire des centaines de Gbps sans aucun problème. Même
avec de l'IPsec, du CGNAT, etc.
Quant à la gigue, pas de problème notoire de ce côté là. L'application qui
s'occupe du traitement des paquets est basée sur DPDK.
On s'assure que ce process soit bien isolé du reste via des mécanismes de
l'OS, et les résultats de latence / gigue sont stables grâce à cela.



> Outre la syntaxe qui est un peu zarb, mais ayant fait du Krotik, c'est pas
> pire...
>

Nous sommes preneurs de retour sur le sujet. N'hésite pas à me faire un
message sur ce qui t'a surpris.
Le data model est un peu calqué sur du Linux, ça peut être un peu
particulier au début, mais nous avons en général de bons retours sur
l'aspect management.
La CLI est un client NETCONF local, et donc l'intégralité de la
configuration du VSR peut être automatisée via ces mêmes APIs NETCONF.


>
> Par contre y a un truc qui m'as complétement refroidis.. et assez
> gravement c'est
> le fait que ce machin est basé sur une ubuntu... qui garde encore ses
> conneries
> entre autre de cloud-init.
>
> Qu'on utilise du Linux, soit... (après si les dev aiment se faire mal...
> c'est
> pas moi), mais garder certains délires des distributions linux... là par
> contre
> ça passe moyen...
>

C'est pourtant utile pour du provisioning initial en VM, et utilisé par
certains de nos clients. Qu'est-ce qui te bloque avec ce mécanisme ?
cloud-init peut se désactiver très simplement au besoin (
https://doc.6wind.com/new/vsr-3/latest/vsr-guide/user-guide/command-reference/cloud-init.html#cloud-init
)
L'intérêt d'être basé sur une distribution, c'est que ça nous permet de
rester à jour sur toute la sécurité des éléments fournis par la
distribution (kernel, et applications classiques de la distribution type
SSH).
Cela nous permet de concentrer nos efforts sur notre valeur ajoutée
(notamment le fast path pour la partie traitement de paquets, le management
plane, etc.).


> Et honnêtement entre un MX204 ou l'arista cité au dessus, et un machin
> soft...
> Mon coeur balance...
>

Un autre intérêt, c'est de pouvoir sélectionner un hardware approprié à son
besoin.
Il y a différents types de serveurs supportés, et pas que des serveurs qui
consomment 700W. Par exemple, pour le besoin de David, un Atom avec
contrôleur ethernet intégré ferait très bien l'affaire.
On se positionne sur de la complémentarité à l'ASIC pour des services
additionnels, type IPsec, L3/L4 firewall, CGNAT. On travaille aussi
activement sur le BNG.
Je ne dis pas que le soft peut remplacer n'importe quel besoin. Mais il
fait sens pour certaines choses.

Nicolas


>
> Xavier
>
>

---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à