Cisco IOS, Juniper Junos, Arista EOS dominent encore le coeur de réseau enterprise, mais une part croissante des opérateurs et des équipes DevOps tourne sur des routeurs logiciels open source. VyOS est l'un des plus matures du segment. Distribution Linux dédiée routage, basée sur Debian, FRRouting et iproute2, exposée derrière une CLI structurée à la Junos.
L'argument n'est pas la performance brute (les ASICs Cisco et Juniper restent imbattables sur certains workloads). L'argument est l'opérabilité : commit/rollback transactionnel, configuration en YAML/CLI, intégration Ansible et Terraform, prix nul sur la licence. Pour un DC qui pilote ses propres bordures, VyOS est devenu un outil sérieux.
On opère du VyOS chez nos clients depuis plusieurs années. Voici ce qu'on regarde côté prod.
Plan de l'article
- Pourquoi un routeur software dans un DC
- Architecture VyOS et stack underlying
- Modèle de configuration commit/rollback
- BGP, OSPF, et fabric IP/MPLS
- VPN IPsec et WireGuard
- Performance et limites
- Intégration GitOps et automation
- Cas d'usage et anti-patterns
Pourquoi un routeur software dans un DC
Trois familles de cas où VyOS gagne contre une appliance commerciale.
Bordure cloud / VPN site-to-site. Concentrateur VPN entre un DC et plusieurs sites distants, peering avec un fournisseur cloud. Une appliance Cisco ASA ou un Juniper SRX coûte cher pour une fonction qu'un VyOS sur serveur x86 fait aussi bien.
BGP edge / DC interconnect. Routeur de bordure peer avec quelques transitaires, route shaping, RPKI validation, prefix filtering. Un VyOS sur du x86 récent tient 5-20 Gbps en BGP, ce qui suffit pour la majorité des PME.
Lab et préprod. Reproduire un fabric multi-zone à coût zéro, tester les configs avant push prod sur l'équipement physique. C'est probablement le premier cas d'usage qui a popularisé VyOS chez les ops réseau.
Pour les coeurs DC haute performance (>40 Gbps par port, >5M de routes en RIB, MPLS L2/L3VPN), on reste sur du Cisco/Juniper/Arista. Le silicium spécialisé n'a pas d'équivalent software à isofonction.
Architecture VyOS et stack underlying
VyOS empile :
- Debian comme base. Kernel Linux récent. Hardening minimal mais sain.
- FRRouting (FRR) pour les protocoles de routage : BGP, OSPF, IS-IS, RIP, MPLS-LDP. Voir notre article frr-bgp pour le contexte FRR.
- iproute2 et nftables pour la pile réseau de base.
- strongSwan pour IPsec.
- WireGuard intégré au kernel.
- OpenVPN comme backup.
- CLI propriétaire : un wrapper en Perl/Python qui transforme une config YAML interne en commandes Linux. C'est cette couche qui fait l'identité VyOS.
L'utilisateur tape set interfaces ethernet eth0 address 192.0.2.1/24. La CLI valide la syntaxe, écrit dans une config en cours, attend commit. Au commit, elle applique les changements et conserve un historique pour rollback.
Côté licence, VyOS est open source mais le projet vend les images "rolling LTS" (binaires testés et supportés) sous abonnement. Les versions "rolling" restent gratuites, builds maison possibles depuis les sources.
Modèle de configuration commit/rollback
C'est la fonctionnalité qui justifie à elle seule l'utilisation de VyOS plutôt que d'une Debian + FRR à la main.
Workflow typique :
configure
set interfaces ethernet eth0 address 203.0.113.1/30
set protocols bgp 65000 neighbor 203.0.113.2 remote-as 65001
set protocols bgp 65000 address-family ipv4-unicast network 203.0.113.0/24
compare # affiche le diff
commit-confirm 5 # commit, rollback auto si pas confirmé sous 5 min
# valide depuis le poste de travail
confirm
save
exit
Le commit-confirm est central. Il pousse une config et l'annule automatiquement si on perd la session ou si la modification a fait sauter la connexion. Sans ça, on bricole un firewall depuis distance et on se déconnecte de soi-même. Tous les opérateurs réseau l'ont vécu.
Le compare donne un diff lisible avant commit. La config est versionnée localement (/config/archive/). Rollback à n'importe quel commit historique avec rollback N.
Pour une équipe qui gère 30 routeurs en parallèle, la combinaison "config déclarative + commit-confirm" élimine 80% des outages dus à des fat-finger. C'est l'argument principal vs. un Debian + FRR ad hoc.
BGP, OSPF, et fabric IP/MPLS
VyOS via FRR couvre les protocoles de routage standards.
BGP. iBGP, eBGP, route reflectors, confederations, communities, RPKI validation, BFD, multipath. Suffisant pour un edge multi-transitaire avec quelques milliers de préfixes.
set protocols bgp 65000 neighbor 198.51.100.1 remote-as 65001
set protocols bgp 65000 neighbor 198.51.100.1 address-family ipv4-unicast \
soft-reconfiguration inbound
set protocols bgp 65000 neighbor 198.51.100.1 capability extended-nexthop
set protocols bgp 65000 address-family ipv4-unicast \
redistribute connected
OSPF / OSPFv3. Multi-areas, virtual links, NSSA, summary routes. Couvre les besoins de fabric IGP datacenter.
MPLS / LDP. Disponible mais à valider en lab avant prod : la maturité MPLS sur FRR n'égale pas Cisco/Juniper. Sur des fabriques L3VPN actives, la prudence reste de mise.
EVPN / VXLAN. Supporté via FRR, utilisable pour des fabriques data center spine-leaf. À aligner avec Proxmox VXLAN SDN si on opère du compute Proxmox derrière.
Pour un peer BGP avec un AS public et de la full-table internet, VyOS sur un serveur x86 16 coeurs / 32 Go RAM tient confortablement. La RIB FIB tient en RAM, le forwarding via netfilter/eBPF dépasse 10 Gbps facilement.
VPN IPsec et WireGuard
VyOS supporte les deux principaux protocoles VPN production.
IPsec via strongSwan. IKEv2, PSK ou cert, NAT-T, route-based ou policy-based. Configuration verbose mais standard. Compatible avec n'importe quel pair Cisco / FortiGate / pfSense / pfSense ou OPNsense.
WireGuard. Configuration trivialement simple. Tunnel point-à-point, pas de phase 1/phase 2 à débuguer. Pour du site-à-site moderne, on préfère WireGuard quand on contrôle les deux extrémités. Voir notre article wireguard-vpn pour les bases.
set interfaces wireguard wg0 address 10.255.0.1/30
set interfaces wireguard wg0 private-key '<base64>'
set interfaces wireguard wg0 peer remote1 public-key '<base64>'
set interfaces wireguard wg0 peer remote1 allowed-ips 10.0.0.0/8
set interfaces wireguard wg0 peer remote1 endpoint 198.51.100.50:51820
OpenVPN. Toujours supporté pour les setups historiques. À ne plus déployer en neuf.
Côté performance, sur du x86 récent avec accélération AES-NI, IPsec tient 2-5 Gbps par tunnel. WireGuard plafonne à des valeurs similaires côté kernel mais consomme moins de CPU.
Performance et limites
Quelques ordres de grandeur, validés sur du matériel courant :
| Hardware | Throughput typique routing | BGP routes |
| Mini PC quad-core 8 Go RAM | 1-2 Gbps | 50k |
| Serveur Xeon 8c 16 Go RAM | 5-8 Gbps | 500k |
| Serveur Xeon 16c 32 Go RAM | 10-15 Gbps | 1M |
| Serveur Epyc 32c 64 Go RAM, DPDK | 25-40 Gbps | 1M+ |
Limites à connaître :
- Pas d'ASIC. Le forwarding plane est le kernel Linux. Sur des bursts de petits paquets (DDoS volumétrique), VyOS tient moins que du hardware dédié. Les pare-feu hardware sont préférables en bordure publique exposée.
- Pas de hot-restart routing daemon. Un upgrade FRR peut couper les peers BGP brièvement. Planifier la fenêtre.
- HA limitée. VRRP supporté pour la HA active/passive, mais pas de stack équivalent à VSS Cisco ou MC-LAG/Virtual Chassis Juniper. Pour de la HA convergée multi-chassis, prévoir l'architecture autrement (routing, pas L2).
Intégration GitOps et automation
C'est ici que VyOS prend son avantage face aux équipements legacy.
Ansible. Module vyos.vyos officiel, riche, qui gère l'arborescence de config. Push de config en idempotent. Compatible avec pratiques Ansible standards.
Terraform. Provider vyos communautaire pour piloter la config en IaC. Encore moins mature que Ansible mais utilisable.
REST API. Depuis VyOS 1.4+, exposition d'une API HTTP (HTTPS via reverse proxy) qui permet de lire la config et appliquer des changements. Idéal pour pipelines CI/CD.
Pattern recommandé : config dans un repo Git, validation par un runner qui pousse en lab, merge sur main = déploiement prod via Ansible. Le diff entre deux commits Git reflète exactement le diff réseau, audité par PR. Pas de "qui a touché à ce routeur la semaine dernière".
Cas d'usage et anti-patterns
Cas où VyOS marche bien :
- Concentrateur VPN multi-sites : 50 tunnels IPsec ou WireGuard, BGP par dessus, monitoring centralisé.
- Routeur de bordure PME : 1-2 transitaires, full table BGP, RPKI, route shaping.
- Routeur edge cloud : VPC AWS/GCP, peering inter-cloud, traffic shaping vers DC.
- Fabric data center modeste : spine-leaf avec EVPN/VXLAN sur du compute commodity, complément à des VRRP gateways.
- Lab et formation : reproduire un environnement Cisco/Juniper en VM pour formation et test.
Cas où ne pas mettre du VyOS :
- Coeur de réseau >40 Gbps avec QoS strict : le kernel Linux ne tient pas la latence ni le burst. Hardware ASIC indispensable.
- MPLS L2VPN à grande échelle : FRR n'a pas la maturité du Junos. Ne pas pousser ce périmètre en prod neuve.
- Conformité réglementaire stricte (telco) qui exige des équipements certifiés. VyOS reste un projet community.
Sur les bordures que l'on opère, VyOS a remplacé du pfSense vieillissant, du Juniper SRX en fin de support, ou du Cisco ISR en sortie de bail. La trajectoire est presque toujours la même : audit du périmètre, design avec le client, lab de validation 2 semaines, bascule en fenêtre de maintenance, intégration au monitoring central. Pour les opérateurs qui hésitent à passer une bordure sur du software, on peut auditer votre coeur de réseau et chiffrer le coût d'une migration vers VyOS avant que vous engagiez un renouvellement appliance.
Sources
- VyOS documentation officielle : référence configuration, exemples, troubleshooting.
- GitHub vyos/vyos-1x : code source CLI et glue layer.
- FRRouting documentation : moteur de routage sous-jacent.
- strongSwan documentation : référence IPsec utilisée par VyOS.
- WireGuard official site : protocole et implémentation kernel.
- VyOS Ansible collection : automation officielle pour pipelines GitOps.
