Comprendre les types de Virtual Server sur F5 BIG-IP

1. Les notions à distinguer

Un Virtual Server (VS) est un objet de traitement du trafic. Dans le cas courant, il associe une destination IP et un port à un comportement. Par exemple, 192.0.2.10:443 peut représenter le point d’entrée d’une application.

• Adresse virtuelle : l’IP associée au VS ; plusieurs VS peuvent partager cette IP avec des ports différents.
• Pool : les destinations entre lesquelles BIG-IP peut répartir le trafic.
• Type : le mode de traitement, par exemple Standard ou Forwarding (IP).
• Profils : les réglages de protocole ou d’application, par exemple TCP, HTTP ou Client SSL.

« VS HTTPS » décrit le service publié, pas un type supplémentaire du menu. FastL4 est un profil, utilisé notamment par Performance (Layer 4) et les types Forwarding. Une adresse ou un port seuls ne décrivent donc pas le fonctionnement du VS.

Sources : F5, About Virtual Servers et K09948701, FastL4.

2. Les dix types en un tableau

Repérez la famille de traitement, puis lisez les limites du type concerné. Ce tableau ne remplace pas une matrice de compatibilité de votre version.

3. Standard : le traitement applicatif polyvalent

Standard est le type généraliste. Dans une publication classique, il répartit le trafic vers un pool. Avec un profil TCP, BIG-IP fonctionne en full proxy : une connexion TCP relie le client à BIG-IP, une autre relie BIG-IP au serveur. Leur traitement est distinct.

Les profils déterminent les fonctions disponibles. Pour interpréter HTTP, il faut un profil HTTP ; pour terminer TLS côté client, un profil Client SSL. Le choix « Standard » n’active pas à lui seul le déchiffrement ou l’analyse HTTP.

Exemple de conception : publier un site HTTPS, déchiffrer la requête sur BIG-IP, appliquer le traitement HTTP nécessaire puis transmettre au serveur. Standard constitue un point de départ cohérent lorsque le besoin est applicatif ; les profils restent à définir.

Sources : F5, K93017176, Standard, K8082, établissement TCP et SSL Traffic Management.

4. Performance (Layer 4) : répartir les flux avec FastL4

Ce type utilise FastL4 et privilégie le traitement des paquets plutôt que le full proxy TCP de Standard. Il peut répartir le trafic vers un pool sans interpréter le contenu applicatif.

Exemple de conception : répartir un service TCP sans modifier HTTP ni terminer TLS sur BIG-IP. L’accélération matérielle éventuelle dépend de la plateforme et des fonctions activées ; le nom « Performance » ne garantit pas un débit donné.

Nuance : FastL4 peut recevoir un profil HTTP pour des fonctions limitées. Cela ne lui donne pas les capacités de transformation HTTP de Standard. F5 documente notamment l’impossibilité de modifier les en-têtes dans cette combinaison. Évitez les raccourcis « FastL4 ne voit jamais HTTP » et « ajouter HTTP suffit pour tout faire ».

Sources : F5, K01155812, Performance L4, K09948701, FastL4, K16446, HTTP limité et K41110335, en-têtes HTTP.

5. Performance (HTTP) : le cas spécialisé FastHTTP

Ce type utilise FastHTTP, un traitement HTTP allégé optimisé pour certaines conditions de trafic. Ce n’est pas Standard avec davantage de puissance.

F5 documente des restrictions, dont l’absence de SSL offload, d’IPv6, de compression et de cache. FastHTTP impose aussi la traduction de l’adresse source des clients. Ces contraintes doivent être compatibles avec l’application.

Pour décider : ne choisissez pas ce type uniquement pour son nom. Pour le trafic Internet, F5 recommande généralement le profil HTTP classique. Comparez d’abord les fonctions nécessaires et les conditions réseau aux limites de FastHTTP.

Source : F5, K8024, FastHTTP.

6. Forwarding (IP) : acheminer sans pool

BIG-IP transmet le paquet vers sa destination IP à l’aide de sa table de routage. Le VS ne choisit pas un membre de pool et ne traduit pas la destination vers un serveur sélectionné.

Exemple de conception : permettre à un réseau derrière BIG-IP d’atteindre d’autres réseaux. Destination, masque, protocole et VLANs d’entrée doivent correspondre au périmètre voulu.

Piège : forwarding ne signifie pas automatiquement « sans état ». FastL4 détermine le suivi des connexions. Examinez aussi le chemin retour et les traductions de source éventuelles.

Source : F5, K7595, Forwarding IP et paramètres FastL4.

7. Forwarding (Layer 2) : le contexte VLAN group

Ce type utilise FastL4, sans pool de répartition. Il s’inscrit dans une configuration de VLAN group et peut partager l’IP d’un nœud du VLAN concerné. La MAC source est conservée ; la MAC de destination dépend de la décision d’acheminement.

Son nom ne suffit pas à le traiter comme un simple commutateur transparent. Examinez les prérequis de VLAN group avant de l’utiliser ou de modifier une architecture existante.

Source : F5, K10371011, Forwarding Layer 2.

8. Stateless : du traitement UDP sans état durable

Stateless répartit les paquets UDP sans les rattacher durablement à une connexion préexistante. Un pool est requis. Ce mode vise des situations limitées où ce traitement suffit.

Exemple à étudier : des requêtes UDP indépendantes. Vérifiez que l’application n’a pas besoin des fonctions absentes : F5 exclut notamment persistance, iRules, mirroring de connexion, SNAT Automap et traduction de port.

Ce type est distinct d’un VS Standard avec profil UDP et de l’option Datagram LB d’un profil UDP : le transport UDP ne rend pas tous les traitements identiques.

Sources : F5, K13675, Stateless et K3605, Datagram LB.

9. Reject : refuser les nouveaux flux

Ce VS refuse les paquets qui créeraient de nouveaux flux sur son périmètre. F5 décrit notamment l’exclusion d’une IP ou d’un port dans un périmètre couvert par un VS wildcard ou forwarding.

Dans le cas TCP décrit par F5, BIG-IP répond au SYN initial par un RST. Un refus explicite ne produit donc pas le même comportement qu’un abandon silencieux. Vérifiez aussi que le trafic sélectionne bien ce VS.

Sources : F5, K93100324, usages de Reject et K9812, réponse TCP RST.

10. DHCP : relayer les demandes d’adresses

BIG-IP relaie les messages entre clients et serveurs DHCP situés sur des réseaux différents. L’attribution des adresses reste le rôle du serveur DHCP.

Ce n’est pas une répartition web classique : la référence TMSH décrit l’envoi des requêtes reçues à tous les membres du pool. Le guide du relais détaille les interfaces d’écoute et les objets nécessaires.

Sources : F5, guide du relais DHCP et TMSH, dhcp-relay.

11. Internal : un service appelé par un VS parent

Internal reçoit des demandes d’un VS parent, sans connexions externes directes. Il ne signifie pas simplement « accessible depuis le LAN ».

Exemple documenté : un VS Standard fait traiter une requête ou réponse HTTP par un service ICAP via un VS Internal. Le flux revient ensuite au VS Standard. Les profils Request Adapt, Response Adapt et ICAP structurent ce fonctionnement.

Source : F5, K15819, Internal et adaptation de contenu.

12. Message Routing : acheminer des messages applicatifs

Ce type s’adresse notamment aux échanges SIP ou Diameter. Le routage porte sur des messages applicatifs, avec des profils et objets spécialisés.

La conception demande d’examiner profils de session et de routeur, pairs et transports adaptés. Un pool TCP seul ne décrit pas cette architecture.

Source : F5, Message Routing Profiles.

13. TLS ne constitue pas un type supplémentaire

Le type et le traitement TLS sont deux choix distincts. Trois architectures aident à poser le besoin :

• Passthrough : le flux reste chiffré jusqu’au serveur. Sans déchiffrement, BIG-IP ne lit pas le contenu HTTP en clair. Standard TCP ou Performance L4 peuvent transmettre ce trafic selon les fonctions requises.
• Terminaison côté client : Client SSL permet à BIG-IP de terminer TLS. Le trafic vers le serveur peut rester en clair sans rechiffrement configuré.
• Terminaison et rechiffrement : Client SSL côté client et Server SSL côté serveur forment deux segments TLS. La validation des certificats serveur se règle dans la configuration correspondante.

Le port 443 ne prouve pas qu’un VS déchiffre. Lisez ses profils et le protocole attendu par les serveurs.

Sources : F5, SSL Traffic Management et K14343463, passthrough.

14. Une démarche pour choisir et comprendre

Cette démarche est une synthèse pédagogique des comportements documentés, pas une prescription universelle.

1. Exprimez le besoin : traiter une application, répartir des flux, acheminer, refuser ou relayer un protocole spécialisé.
2. Listez les fonctions : interprétation HTTP, terminaison TLS, transformation d’en-têtes, persistance ou adaptation.
3. Confrontez-les au type et aux profils : Standard pour le traitement applicatif généraliste ; FastL4 si ses fonctions suffisent ; forwarding pour acheminer sans pool ; types spécialisés pour leur rôle précis.
4. Vérifiez la topologie : VLANs d’entrée, routes, retour des réponses, traduction de destination et SNAT restent des décisions complémentaires.
5. Validez dans votre version : fonctions, erreurs, supervision et performances utiles à votre cas.

Wildcard décrit un périmètre de destination large, pas un onzième type. Plusieurs VS peuvent correspondre au trafic ; ne supposez pas que l’ordre de création décide lequel est sélectionné.

Sources : F5, wildcard et retour des réponses et K93100324, sélection des VS.

Lire une configuration existante

Dans l’interface, ouvrez Local Traffic → Virtual Servers, puis l’objet concerné. Examinez Type, destination, protocole, profils et ressources. Ces commandes TMSH affichent configuration et statistiques sans modifier le VS :

tmsh list ltm virtual /Common/nom_du_vs all-properties
tmsh show ltm virtual /Common/nom_du_vs

Remplacez nom et partition par ceux de votre objet. Dans l’export, les options ip-forward, l2-forward, internal, reject ou dhcp-relay, ainsi que les profils, renseignent le fonctionnement. Une adresse et un pool ne suffisent pas à conclure.

Source : F5, référence TMSH, ltm virtual — version v17.0.0 affichée lors de la consultation.

15. Sources et références

Références de l’éditeur F5 consultées le 2 octobre 2026. Les liens après chaque section permettent de retrouver les explications. Les articles MyF5 peuvent nécessiter un navigateur capable de charger leur interface.

• About Virtual Servers — mise à jour annoncée le 7 juillet 2026 ; versions applicables en tête du document.
• K8082, établissement TCP — mise à jour annoncée le 26 août 2026.
• K09948701, FastL4 — mise à jour annoncée le 21 novembre 2025.
• K01155812, Performance L4 — mise à jour annoncée le 26 février 2025.
• K10371011, Forwarding Layer 2 — mise à jour annoncée le 16 mai 2025.

Avant une modification, confrontez le guide à la configuration, à la version et aux tests de votre environnement.

Approfondir la chaîne du trafic

• F5 : choisir le load balancing des pool members
• Comprendre le SNAT sur F5 : None, Automap et SNAT Pool
• Comprendre les route domains sur F5 BIG-IP
• Comprendre les HA groups sur F5 BIG-IP