Boiler BIGIP LTM V13.1 FR

En réunissant une structure de
commutation haute performance, un

matériel et un logiciel spécifiques, F5 offre
la flexibilité nécessaire pour prendre les
bonnes décisions concernant le trafic
applicatif sans créer de goulot
d’étranglement. Les performances élevées
qu’apportent les plates-formes BIG-IP vous
permettent de consolider l’infrastructure –
et de réduire les coûts en termes
d’administration, d’énergie, d’espace et de
refroidissement – et d’en faciliter la
croissance future.
BIGIP LTM
Version 13.1
F5 Networks
Table des Matières
1. Description de la solution BIGIP LTM .................................................................................................... 4
1.1. Les Plateformes BIG-IP .................................................................................................................. 4
1.2. Cas d’usages du BIG-IP LTM .......................................................................................................... 5
1.3. Le Système d’Exploitation TMOS .................................................................................................. 6
1.4. Architecture Modulaire................................................................................................................. 7
2. Descriptif Technique ............................................................................................................................. 9
2.1. Réseau ........................................................................................................................................... 9
2.1.1. Commutation ........................................................................................................................ 9
2.1.2. Redondance .......................................................................................................................... 9
2.1.3. Routage ............................................................................................................................... 10
2.1.4. Sécurité ............................................................................................................................... 10
2.2. Haute disponibilité et synchronisation des configurations ........................................................ 13
2.2.1. Description du Device Service Clustering (DSC) .................................................................. 13
2.2.2. Les composants du DSC ...................................................................................................... 16
2.2.3. Les SYNC-FAILOVER DEVICE GROUPS.................................................................................. 18
2.2.4. Les SYNC-ONLY DEVICE GROUPS......................................................................................... 20
2.2.5. Détection de Failover .......................................................................................................... 21
2.2.6. Serial et Network Failover................................................................................................... 22
2.2.7. Exemples d’architectures de haute disponibilité ................................................................ 23
2.3. Proxy Applicatifs.......................................................................................................................... 28
2.4. Partage de charge ....................................................................................................................... 29
2.4.1. Description des méthodes de partage de charge ............................................................... 29
2.5. Modèles d’architecture............................................................................................................... 30
2.5.1. Architecture en mode Bridge (niveau 2) ............................................................................. 30
2.5.2. Architecture routage ou niveau 3 ....................................................................................... 30
2.5.3. Architecture dite en manchot (ou One Leg) ....................................................................... 31
2.5.4. Mutualisation du BIG-IP LTM sur plusieurs sous-réseaux................................................... 32
2.5.5. Retour direct des serveurs .................................................................................................. 32
2.6. Tests de vie.................................................................................................................................. 33
2.7. Mécanismes de persistance ........................................................................................................ 34
2.8. Translations d’adresses IP ........................................................................................................... 35
1 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS
2.9. Fonctions d’optimisations ........................................................................................................... 36
2.9.1. Terminaison SSL .................................................................................................................. 36
2.9.2. Optimisation TCP ................................................................................................................ 39
2.9.3. Compression HTTP .............................................................................................................. 41
2.9.4. Caching ................................................................................................................................ 44
2.9.5. Passerelle HTTP/2 ............................................................................................................... 46
2.9.6. Rate Shaping ....................................................................................................................... 47
2.9.7. Contrôle de bande passante ............................................................................................... 47
2.9.8. TCP Request Queueing ........................................................................................................ 48
2.9.9. Multiplexage de connexions ............................................................................................... 49
2.9.10. Prioritisation des Flux.......................................................................................................... 49
2.10. Gestion des tunnels................................................................................................................. 51
2.10.1. Tunnels IP ............................................................................................................................ 51
2.10.2. IPSEC.................................................................................................................................... 51
2.10.3. Ether IP ................................................................................................................................ 52
2.11. Les policies .............................................................................................................................. 52
2.12. Les iRules ................................................................................................................................. 53
2.13. Virtualisation des Solutions BIG-IP LTM .................................................................................. 55
2.13.1. Partition d’administration ................................................................................................... 55
2.13.2. Segmentation réseau, Route-domain ................................................................................. 55
2.13.3. Virtualisation (vCMP) .......................................................................................................... 56
3. Exploitation de la solution LTM .......................................................................................................... 61
3.1. Statistiques et Reporting granulaires : module AVR ................................................................... 61
3.2. Facilité de Configuration et de Gestion des Applications : iApp ................................................. 64
3.2.1. Templates............................................................................................................................ 66
3.2.2. Application Services ............................................................................................................ 67
3.3. Log des Requêtes et Réponses à haut débit (High Speed Logging) ............................................ 68
3.4. Administration et supervision ..................................................................................................... 71
3.4.1. Interface de commande en ligne ........................................................................................ 71
3.4.2. Interface graphique sécurisée :........................................................................................... 71
3.4.3. Supervision SNMP ............................................................................................................... 73
3.4.4. iControlREST........................................................................................................................ 73
3.4.5. Outils de diagnostique ........................................................................................................ 73
3.4.6. Gestion des fichiers configurations..................................................................................... 74
3.4.7. Résolution d’incidents......................................................................................................... 74
3.4.8. Historisation des événements ............................................................................................ 75
3.4.9. Historisation des configurations ......................................................................................... 76
4. Points forts de la solution F5 .............................................................................................................. 77
5. Mise à jour du document et releases ................................................................................................. 79
5.1. Version 11.0 ................................................................................................................................ 79
5.2. Version 11.1 ................................................................................................................................ 79
5.3. Version 11.2 ................................................................................................................................ 79
5.4. Version 11.5 ................................................................................................................................ 80
5.5. Version 12.0 ................................................................................................................................ 80
5.6. Version 13.1 ................................................................................................................................ 80

1. Description de la solution BIGIP LTM
1.1. Les Plateformes BIG-IP
Les plateformes d’Application Delivery Controller (ADC), BIG-IP Local Traffic Manager (LTM) sont
capables de gérer les trafics les plus importants de la couche 4 à la couche 7. En réunissant une structure
de commutation haute performance, un matériel et un système d’exploitation spécifiques, F5 offre la
souplesse nécessaire pour prendre les bonnes décisions concernant le trafic applicatif sans congestion.
Les performances élevées qu’apportent les plates-formes BIG-IP permettent de consolider

l’infrastructure – et de réduire les coûts en termes d’administration, d’énergie, d’espace et de
refroidissement – et d’en faciliter la croissance future.
Les équipements BIG-IP permettent de bâtir l’infrastructure critique de l’entreprise sur un matériel
fiable, avec des composants échangeables à chaud, des alimentations et des ventilateurs redondants, le
multi-boot et une administration toujours disponible.
La gamme des plateformes BIG-IP est homogène et couvre des besoins variés en termes de performance
et d’évolutivité. Il existe des BIG-IP sous différents formats :
▪ Appliances BIG-IP
▪ Chassis VIPRION
▪ Edition Virtuelle (Virtual Edition – VE)
25M 200M 1Gbps 3Gbps 5Gbps 10Gbps
i2000 series i4000 series i5000 Series i7000 Series i10000 Series i11000 Series
VIPRION 2200 VIPRION 2400 VIPRION 4480 VIPRION 4800
Figure 1 : gamme de plateformes F5

L’architecture des boitiers est composée de plusieurs éléments :
▪ Une partie Switching

▪ Une partie accélération hardware dédiée
▪ Une partie intelligence applicative
▪ Surveillance du système intégrée
1.2. Cas d’usages du BIG-IP LTM

La solution BIG-IP LTM a été conçue comme une plateforme de répartition de charge en mode proxy.
Elle termine les sessions et les réémets à destination des serveurs applicatifs. Les évolutions de
l’operating system TMOS décrit plus bas ont permises d’apporter un niveau de contrôle inégalé sur les
flux transitant à travers le BIG - IP LTM. On retrouve aujourd’hui la solution BIG-IP LTM dans des
modèles d’utilisations éloignées du positionnement historique de répartiteur de charge. En voici
quelques exemples :
▪ Répartition de charge sur les serveurs d’application : le LTM surveille en permanence la

disponibilité des matériels et logiciels qui composent une application pour assurer une
continuité de service et une répartition de la charge
▪ Répartition de charge de liens WAN : aussi bien utilisé pour des liens WAN qu’Internet ce type
de topologie permet d’agréger la bande passante de plusieurs liens WAN ou encore d’utiliser un
mode de fonctionnement actif/passif.
▪ Solution de NAT 44 : utilisée dans les grands réseaux d’entreprise, les fonctions de NAT, log à
haut débit et grande capacité de sessions simultanées font du BIG-IP LTM une plateforme de
NAT très intéressante.
▪ Solution de NAT 64 : Employée principalement dans les réseaux d’opérateurs mobiles, la double
pile réseau du BIG-IP V4/V6 permet d’ouvrir vôtre infrastructure à des utilisateurs en IPV6 et
faire cohabiter ainsi les deux populations.
▪ Solution de Reverse Proxy Web : BIG-IP LTM permet de consolider les zones de hosting Internet
et Intranet en supprimant la couche de reverse proxy web logicielle traditionnelle. LTM propose
toutes les fonctions nécessaires : cache, réécriture d’url et contenu, compression http,
terminaison SSL …
▪ Outil de traffic steering : Encore une fois déployé dans les réseaux opérateur mobiles, BIP-IP
LTM offre la capacité d’appliquer des critères de niveau 7 pour gérer les flux. La capacité
d’adaptation du produit lui permet également d’interagir avec des services extérieurs pour
récupérer un profil d’utilisateur afin de prendre ses décisions d’aiguillage.
▪ Firewall de Data Center Internet : la gestion de l’IPSEC et la certification ICSA Network Firewalls,
couplés aux fonctions anti-DDOS et la capacité de monter des dans les couches du modèle OSI
pour apporter des fonctions de sécurité permettent de positionner BIG-IP LTM en amont du
DataCenter afin de remplacer un firewall traditionnel.

1.3. Le Système d’Exploitation TMOS
Le système d’exploitation de F5, TMOS (Trafic Management Operating System) permet d’allier à la fois la
performance au niveau paquet (profils de performance Fast.L4 par exemple, ASIC/FPGA), tout en
permettant le traitement de type proxy/full-proxy.
Les coûts associés au développement de composants permettant de travailler principalement en mode

paquet, est bien inférieur à ceux permettant de créer des solutions de type proxy/full proxy.
Dans le mode proxy, l’ensemble de la connexion client est gérée différemment de la connexion serveur,
ce qui permet à la fois de prendre des décisions de répartition de charge en fonction de critères fournis
par le client et/ou le serveur, pour chaque connexion, pour chaque requête ou réponse, etc.
Ce mode nécessite la gestion du niveau 4 à 7 des échanges entre les clients et les serveurs.
TMOS est :
▪ Constitué de modules logiciels granulaires permettant d’assembler les fonctions nécessaires du

niveau réseau au niveau applicatif. Tout nouveau protocole applicatif (SMTP, RTSP, SIP, IIOP,
XML, …) est ainsi intégré à l’ensemble des modules (Ethernet, IP, proxy TCP, …) afin de
bénéficier des fonctionnalités des autres composants, sans augmenter la complexité globale de
la solution.
▪ Un système d’exploitation type « linux » indépendant du micro noyau « temps réel » en charge
de la gestion du trafic. Le système d’exploitation est en charge des taches d’administration. Cet
environnement n’est jamais sollicité par les flux qui traversent l’équipement (répartition de
charge, optimisation, sécurisation, …).
▪ Un système d’exploitation temps-réel, constitué de composants matériels et logiciels. Cette
conception permet d’allier les performances et l’intelligence du logiciel, à des fonctionnalités
matérielles permettant de ne pas surcharger le système de taches complexes pouyant être
réalisées en hardware (ASICs SSL, ASICs de compression HTTP, ASICs de traitement niveau 4 des
flux, …)
▪ Un système d’exploitation orienté « événements ». La gestion temps réel des flux, associé à des
routines de traitement de ces flux, permet de déclencher des événements tout le long d’une
connexion applicative, entre le client et le serveur, mais également entre le serveur et le client
(décision de répartition de charge en fonctions d’informations dans le payload IP d’un paquet,
dans une URI, un user FTP, une adresse email dans un flux SMTP, modification des bannières
d’un serveur Web, renvoi d’une page d’erreur en lieu et place d’une page http 404 d’un serveur
Web, …)
▪ Pile TCP/IP en mode « proxy ». Cette fonctionnalité intégrée à TMOS, permet de réaliser une
adaptation entre le client et le F5 BIG-IP, et le F5 BIG-IP et le serveur, au niveau TCP, afin de
prendre en compte les clients « WAN » (bas débit, réseau de qualité moindre que le LAN, tailles
de fenêtres TCP différentes, congestion, …) et les clients/serveurs LAN (haut débit, taille de
fenêtres TCP importante, …).

1.4. Architecture Modulaire
TMOS inclut l’ensemble des fonctionnalités F5. Celles-ci sont organisées par module et accessible par
licence.
VMWare
Plugin Ecosystem
Container
BIG-IQ Centralized Management™ orchestrator
Azure
BIG-IP® BIG-IP® BIG-IP® WebSafe et BIG-IP® BIG-IP® BIG-IP®
Link Local DNS MobileSafe Application Advanced Access Policy
Controller Traffic Security Firewall Manager OpenStack
Manager Manager Manager (APM)
(LTM) (ASM) (AFM)
AWS
Programmability iRules® , iApps® , iCall, iStats and iControlREST

TMOS Managem ent RBAC, Logging, SNMP, CLI, GUI
Operating System
Performance / Scalability CMP, VCMP, ScaleN, Firmware, FPGA
ADC
Fabric
Security
Appliances Chassis Software Management
Cloud
Orchestration
Figure 2 : ensemble des modules fonctionnels F5 networks
Les modules sont organisés de la manière suivante :
▪ Haute disponibilité et répartition de charge : LTM ou Local Traffic Manager. Ce module est un
répartiteur de charge L4/L7 (répartition de charge, test de vie,…) qui offre en complément des
fonctions de reverse-proxy : réécriture d’URL et de contenu, cache & compression HTTP, gestion
du SSL, NAT et SNAT.
▪ Haute Disponibilité / Equilibrage de charge des accès aux applications situées sur plusieurs sites
géographiques, PRA/PCA : DNS : ce module permet de rediriger, automatiquement et de façon
transparente, les utilisateurs vers le data center le plus disponible et le plus rapide pour un
service particulier.
▪ Haute Disponibilité / Equilibrage de charge de plusieurs liaisons ISP : Link Controller : dans le
cadre d’infrastructure de type multi-home, le Link Controller permet d’aiguiller,
automatiquement et de façon transparente, le trafic à travers le lien le plus disponible et rapide
pour joindre une destination spécifique.
▪ Protection contre la fraude Web : Websafe/Mobilesafe

▪ Sécurité des applications WEB : ASM ou Application Security Manager : ce module est un
firewall applicatif web (WAF) qui permet de mettre en œuvre une sécurité jusqu’au niveau
applicatif et de se protéger contre les DDoS de niveau 7, la manipulation des paramètres et des
cookies, les attaques de SQL Injection, de Cross Site Scripting, etc…
▪ Filtrage réseau et protection DDoS : AFM ou Advanced Firewall Manager. Ce module est pare-
feu réseau qui permet d’offrir une sécurité réseau périmétrique en tête de datacenter (DCFW :
Data Center Firewall) et de protéger le datacenter des attaques DDoS grâce à 60 vecteurs de
détection accélérés matériellement.
▪ sécurité et authentification centralisé des accès distants aux applications : APM ou Access Policy
Manager : ce module permet de mettre en œuvre des accès aux application et ressources
internes via des tunnels SSL VPN. Il permet aussi de configurer des politiques d’authentification
(Radius, LDAP, Active Directory, Tacacs+, délégation Kerberos, SSO) centralisée. Enfin, APM peut
valider dans quel contexte se connecte un utilisateur (type et version d’OS, antivirus, firewall
personnel, etc).

2. Descriptif Technique
2.1. Réseau
2.1.1. Commutation
Les plateformes F5 supportent des fonctions de niveau 2, celles-ci sont assurées par une architecture
non bloquante, en Hardware :
▪ Nombre maximal d’adresses MAC : 4 096. Cette valeur est valable pour tous les modèles de
boitiers F5. Elle est stockée dans la table ARL (Address Resolution List) des ASIC de la matrice de
commutation, donc est assurée en Hardware.
▪ Le support des protocoles 802.1d (spanning tree), 802.1w (rapid spanning tree protocol), 802.1p
(priorisation), 802.1q (VLANs) et 802.3ad (LACP) est assuré en Hardware. La solution de
« trunk » F5 est compatible avec le PaGP des switchs Cisco.
▪ Il est possible de définir plusieurs VLANs par ports dans la limite maximale de 4095 VLANs. Le
traitement de cette fonction est assuré en Hardware.
▪ Le boitier BIG-IP LTM peut présenter des adresses MAC identiques pour tous les VLANs déclarés,
ou bien des MAC différentes par VLAN, suivant la compatibilité des équipements de switching
connectés. Il est aussi possible, pour chaque VLAN, de configurer du « MAC Masquerading »
permettant de présenter une adresse MAC créé de toute pièce par l’administrateur, à la fois
pour les adresses IP virtuelles portées par le F5, mais également les adresses IP des serveurs
virtuels hébergés par le F5.
2.1.2. Redondance
La redondance réseau est assurée par un mécanisme propriétaire de type VRRP/HSRP vis-à-vis des
équipements réseau tiers :
▪ En mode actif/passif, seul l’équipement actif communique les adresses MAC correspondant aux
VS hébergés, ainsi que les adresses MAC des adresses IP flottantes (principe similaire au VRRP,
HSRP). Lorsqu’il y a une bascule, le boitier de backup reprend les adresses IP correspondantes et
émet des « gratuitous ARP » vers l’ensemble des VLANS ou sont connectées ces adresses IP. Si
du « MAC masquerading » est configuré, l’adresse MAC qui est émise dans les « gratuitous
ARP », est la même que sur le boitier qui était actif.
▪ En mode actif/actif, les VS sont répartis en groupe logique (Traffic Group). Chaque boîtier est
actif pour un ou plusieurs Traffic Group et publie ainsi les adresses MAC associées aux VS des
Traffic Group. Le mode de fonctionnement est détaillée au paragraphe 2.2.
▪ Dans les 2 cas, les boitiers disposent d’une adresse IP dite « flottante » permettant aux solutions
connectées sur les différents VLANs (serveurs, routeurs, firewalls, …) de communiquer au
travers des répartiteurs de charge, indépendamment du boitier physique actif à l’instant t. C’est
un mécanisme similaire aux protocoles HSRP/VRRP.
▪ Le nombre maximal d’adresses IP configurables est de 65 000 et il n’y a pas de limitations quant
au nombre maximal d’adresses IP par interface. Il est possible de faire de l’IP aliasing (ajout de

plusieurs plages d’adresses IP sur la même interface logique : VLAN, trunk ou interface
physique).
▪ Taille maximale de la table ARP : 8 192. Cette valeur est valable pour tous les modèles de
boitiers F5. Elle est assurée en hardware.
2.1.3. Routage
Il est possible de router spécifiquement les flux, vers des serveurs ou des passerelles spécifiques, en
fonction de la source (VLAN source, adresse IP source, adresse MAC source). Cela permet par
exemple de réagir à une attaque provenant d’un VLAN ou une adresse IP particulier, et le
transmettre à un serveur de type « honeypot ».
Toutes les fonctions de routage statique sont supportées et il est possible d’effectuer de façon
optionnelle des fonctions de routage dynamique :
▪ RIPv2 (RFCs 1058 et 1723),

▪ OSPF (RFC 1247)
▪ BGP4 (RFCs 1771 et 1654) et BGP (RFCs 1105, 1163 et 1267)
▪ IS-IS
Par défaut, le boitier F5 BIG-IP LTM n’effectue pas de routage. Lorsqu’un flux doit traverser
l’équipement, il doit avoir au préalable été « déclaré » au travers d’un serveur virtuel de type Host
(adresse IP unicast /32) ou bien de type réseau (adresse IP de type network). Le routage peut
également être réalisé, non pas uniquement par adresse IP, mais également en fonction d’un port
applicatif donné (comme par exemple, router les flux http au travers du répartiteur de charge à
destination de proxys, et tous les autres flux, au travers de firewalls).
Il est possible de créer des serveurs virtuels dédiés au routage. Configurés généralement de façon
spécifique, par Vlan(s). Le routage peut donc être réalisé en fonction de critère de VLAN origine,
pour un même réseau destination.
2.1.4. Sécurité
2.1.4.1 Filtrage IP par ACLs
Il est possible d’activer un pare feu (stateful firewall) pour le filtrage des flux routés/bridgés (adresses
source, destination, protocole, service, …). Chaque ligne de filtrage peut être configurée pour logguer
l’événement (soit paquet par paquet, soit par connexion). Ce log est horodaté, et est préfixé dans le
message du log, par le nom de la ligne de filtrage s’étant déclenchée.

Figure 3 : Interface de configuration du filtrage IP
Figure 4 : création d'une règle de filtrage IP
Le filtrage des flux peut être réalisé de type « white list » ou « black list », par le biais des filtres de type
ACLs. Ces filtres sont nommés, configurables en ligne de commande (CLI) ou par l’interface graphique.

2.1.4.2 Mécanismes de protection contre le déni de service
De par sa conception le BIG-IP LTM est capable de résister aux attaques par déni de service simples
telles que :
▪ Attaques par déni de service combattues (suppression des connexions passives à l’aide d’un
timer d’inactivité)
▪ Attaque par IP Spoofing (remontée jusqu’à la route source)
▪ Résistance au SYN non reconnu sans buffers ACK (inondations SYN)
▪ Attaques par “ teardrop ” et “ Land ”
▪ Auto-protection et protection des serveurs contre les attaques ICMP
▪ Non-exécution de SMTPd, FTPd, Telnetd et d’aucun autre démon attaquable
2.1.4.3 Base de réputation IP (IP Intelligence)

Il est possible de souscrire à un service de réputation IP qui va permettre de catégoriser les IP sources
des clients (lorsqu’elles sont publiques) en fonction de critères de dangerosité.
Les catégories suivantes sont disponibles :
▪ Windows exploits :
▪ Web attacks
▪ Botnets
▪ Scanners
▪ Denial of Service
▪ Infected Source
▪ Phishing
▪ Proxy

2.2. Haute disponibilité et synchronisation des configurations
2.2.1. Description du Device Service Clustering (DSC)
Figure 5 : modèles de groupe de synchronisations
Le système d’exploitation TMOS (Traffic Management Operating System inclut une nouvelle architecture
appelée Device Service Clustering (DSC). Le DSC est une technologie qui permet de mettre en place plus
de deux équipements redondants en parallèle. Ces équipements se partagent un pool d’applications
pour un maximum de disponibilité et d’évolutivité. Le DSC permet de gérer plusieurs équipements
comme si vous n’en aviez qu’un. En plus de la facilité de management, le DSC fourni la possibilité de
distribuer, application par application, la charge à travers les ADCs. Cette architecture met en œuvre la
synchronisation de la configuration et un système de haute disponibilité à plusieurs niveaux définis par
l’administrateur. Plus spécifiquement, un Big-IP peut être configuré pour :
▪ Synchroniser une partie ou toute sa configuration vers plusieurs Big-IPs distants.

▪ En cas de Fail-Over, basculer le trafic vers un ou plusieurs Big-IP disponibles
▪ Synchroniser la table des connexions vers un autre équipement du cluster afin de prévenir toute
interruption de service pendant une bascule (Fail-Over).
Dans le cas d’une paire de Big-IP, une configuration de type actif/standby ou actif/actif est possible.
Avec plus de deux équipements, on peut mettre en place une configuration dans laquelle plusieurs Big-
IP sont actifs et peuvent basculer vers un des autres équipements.

Ce système assure que les objets de la configuration sont synchronisés et que la bascule se fait de façon
granulaire vers les Big-IP appropriés. De plus, la bascule d’un équipement à un autre se fait avec un
minimum d’interruption des services applicatifs.
Il est donc possible de mettre en œuvre une architecture de type N+M, dans laquelle on a N BIG-IP actifs
et M Big-IP Standby. Les propriétés ci-dessous sont données pour deux équipements et se déclinent sur
plus de deux dans le cas N+M :
▪ Actif/Standby : un BIG-IP LTM est actif et le deuxième est passif. Le BIG-IP LTM en Standby
devient Actif en cas failover, et le second deviendra Standby après un reboot ou la résolution du
failover. Il est possible d’indiquer quel BIG-IP LTM doit être Actif en priorité, dans la paire en
Haute Disponibilité
▪ Actif/Actif : Les deux BIG-IP sont actifs au même instant. Les performances sont alors
dédoublées en répartissant les serveurs virtuels entre les deux boîtiers BIG-IP LTM.
Le DSC se configure via la fonction appelée Device Management. Cette fonction, peut être accédée via
les menus Device Management :

Figure 6 : configuration du DSC
La solution de Haute Disponibilité du BIG-IP fournit les fonctionnalités suivantes :
▪ Synchronisation des configurations : Cette fonctionnalité permet de configurer un BIG-IP LTM et

de synchroniser tout ou partie de sa configuration vers d’autres BIG-IPs.
▪ Mirroring des tables de connexions et de persistance : Cette fonctionnalité permet de
synchroniser en temps réel les tables de connexions et les informations de persistance en cours
sur deux BIG-IP en Haute Disponibilité. En cas de failover du BIG-IP LTM Actif, les connexions et
les informations de persistance de celui-ci ne sont pas perdues ; il n’y a donc aucune rupture de
session pour les utilisateurs. On parle de stateful failover. Le mirroring est supporté entre une
paire de BIG-IP uniquement.
▪ Mirroring des sessions SSL : les sessions SSL sont transférées de l’équipement actif vers
l’équipement passif au niveau 4 et au niveau 7. Cela signifie que le client n’a pas besoin de
renégocier une session SSL en cas de bascule. Il est recommandé de n’activer cette fonction que
pour les connexions SSL de longue durée (ATM, Video over HTTPS, gaming, …)

2.2.2. Les composants du DSC
L’architecture du système de redondance s’appuie sur plusieurs concepts clés :
▪ Un device group est un ensemble de Big-IP qui partagent une relation de confiance commune et
peuvent synchroniser leur configuration et/ou basculer les uns sur les autres en cas de failover.
Il existe deux types de device groups :
▪ Sync-Failover : ce device group contient des équipements qui synchronisent toute leur
configuration et supporte les traffic groups pour les besoin du failover quand un
équipement devient indisponible. Les équipements membres d’un même Sync-Failover
device group doivent être du même model, avoir les mêmes licences et provisionner les
mêmes modules. Ceci pour éviter un mauvais comportement dans le cas d’une bascule
d’un équipement à l’autre.
▪ Sync-Only : un Sync-Only device group contient des équipements qui synchronisent
certains objets de leur configuration (iRules, iApps et Profiles par exemple), et ne
synchronisent pas les objets de failover.
Figure 7 : Notion de Trust Domain
Un BIG-IP peut être membre d’un seul Sync-Failover device group. Cependant, un BIG-IP peut appartenir
aux deux types de device group à la fois.
▪ Un traffic group est un ensemble relatif à des objets de la configuration (tels que les adresses IP
virtuelles et les adresses de selfIP), qui tournent sur un Big-IP et prennent en charge un trafic
applicatif particulier. Quand un équipement devient indisponible, un traffic group peut flotter
vers un autre équipement du device group afin de s’assurer que le trafic applicatif continue de
fonctionner correctement.
Les objets qui peuvent être inclus dans un traffic group sont :
▪ Applications iApp
▪ Virtuals Servers
▪ NATs
▪ SNAT
▪ Adresses de selfIP (adresses des interfaces physiques)
Sur les Big-IPs, chaque traffic group est dans un état actif ou standby. Un traffic group en état
actif sur un équipement veut dire que l’équipement prend en charge le trafic applicatif attaché à
ce traffic group. Dans le cas standby, l’équipement est inactif pour le trafic applicatif attaché au
traffic group.
Quand un équipement, avec un traffic group actif, devient indisponible, le traffic group flotte
vers un autre équipement (le plus disponible dans le device group). Le terme flotte veut dire que
sur l’équipement cible, le traffic group passe de l’état standby à l’état actif.
Le schéma suivant montre une configuration typique avec deux BigIP et un traffic group (appelé
my_traffic_group). Dans cette illustration, le traffic group est actif sur le BigIP A et standby sur le
BigIP B.
Figure 8 : gestion des traffic groups
Si une bascule a lieu, le traffic group flotte vers l’autre équipement. Dans le schéma suivant, le
BigIP A devient indisponible, ayant pour conséquence de basculer le traffic group vers le BigIP B.
Le traffic group est alors actif sur le BigIP B et standby sur le BigIP A.

Figure 9 : bascule d'un traffic group
Il est possible de forcer un traffic group actif à passer en état standby. Forcer un traffic group à
passer dans un état standby, a pour conséquence de passer le traffic group en mode actif sur un
autre membre du device group. En général, on force un traffic group à passer en état standby
quand :
▪ L’équipement doit être mis offline pour des questions de maintenance

▪ Vous souhaitez utiliser un équipement pour la création d’un traffic group, mais le traffic
group doit normalement être actif sur un autre équipement du device group.
▪ La mise en œuvre opérationnelle des device groups et traffic groups fait appel à un autre
concept appelé device trust. Le Device Trust permet d’établir une relation de confiance entre
plusieurs Big-IPs, à travers l’utilisation de certificats. On a alors un domaine de confiance.
▪ Les folders et sub folders sont des containeurs d’objets. Pour chaque partition administrative, il
y a cinq niveaux de folders (dossiers). Le folder appelé root représente le plus haut niveau de la
hiérarchie. Le Big-IP utilise les folders pour contrôler quels objets de la configuration doivent
être synchronisés avec les autres équipements dans le device group.
2.2.3. Les SYNC-FAILOVER DEVICE GROUPS

2.2.3.1 DEFINITION
Un Sync-Failover device group contient des Big-IPs qui synchronisent toute leur configuration et
basculent entre eux quand un équipement devient indisponible. Ce type de groupe est donc utiliser pour
mettre en œuvre une haute disponibilité de type N+M entre plusieurs BIG-IPs (8 maximum).
Les bascules se font de manière automatique ou manuelle (il est possible de forcer une bascule). La
synchronisation de configuration ne peut se faire que de façon manuelle.
Un équipement dans un domaine de confiance peut appartenir à un seul Sync-Failover device group.

Les équipements membres d’un même Sync-Failover device group doivent être du même model, avoir
les mêmes licences et provisionner les mêmes modules. Ceci pour éviter un mauvais comportement
dans le cas d’une bascule d’un équipement à l’autre.
Figure 10 : Exemple de Sync Failover Device Group
2.2.3.2 EXEMPLE D’UNE ARCHITECTURE DE TYPE SYNC-FAILOVER
Cet exemple montre deux Sync-Failover device groups dans un domaine de confiance local. Device
Group A est une configuration classique actif/standby. En temps normal, seul Bigip1 prend en charge le
trafic pour l’application A. Bigip1 et Bigip2 synchronisent leurs configurations, et Bigip1 bascule vers
Bigip2 si Bigip1 devient indisponible. Bigip1 ne peut pas basculer vers Bigip3 ou Bigip4 car ces
équipements sont dans un autre device group.
Device Group B est aussi une configuration classique de type actif/standby, dans laquelle seul Bigip3
prend en charge le trafic pour l’application B. Bigip3 et Bigip4 synchronisent leurs configurations, et
Bigip3 bascule vers Bigip4 si Bigip3 devient indisponible. Bigip3 ne peut pas basculer vers Bigip1 ou
Bigip2 car ces équipements sont dans un autre device group.

Figure 11 : Trust Domain et double Device Group
2.2.4. Les SYNC-ONLY DEVICE GROUPS

2.2.4.1 Definition
Un Sync-Only device group contient les Big-IPs qui synchronisent leur configuration. Cependant, les
équipements ne basculent pas entre eux.
Un équipement dans un domaine de confiance peut être membre de plusieurs Sync-Only device groups.
Un équipement peut aussi être membre à la fois d’un Sync-Only device group et d’un Sync-Failover
device group.
Une utilisation typique d’un Sync-Only device group est lorsque vous désirez synchroniser des objets
spécifiques (type iRule, iApp, profiles, etc) vers d’autres BIG-IPs.
Il est possible de configurer jusqu’à 32 BIG-IPs dans un même Sync-Only devic e group.
Il n’est pas nécessaire d’avoir une homogénéité de plateforme, licences ou modules pour les BIG-IPs
d’un même Sync-Only device group.
2.2.4.2 Synchronisation automatique

Pour les Sync-Failover device groups, vous pouvez activer la fonction de synchronisation automatique
(Automatic Sync).
Une fois activée, tous les Big-IP dans le device group synchronisent leur configuration vers les autres
membres du device group dès qu’une donnée est modifiée.

2.2.4.3 Exemple d’une architecture de type SYNC-ONLY
Un Sync-Only device group est communément utilisé pour synchroniser un dossier spécifique contenant
des objets de type politique (exemple iRule) et que vous souhaitez partager entre tous les équipements
dans un domaine de confiance local.
Dans le même temps, un Sync-Failover device group peut être utilisé pour assurer la bascule des autres
objets de configuration vers un sous ensemble d’équipement dans le domaine.
Dans cette configuration, l’attribut Sync-Only device group est utilisé sur un dossier afin de remplacer
l’attribut Sync-Failover device group hérité par défaut.
Dans l’exemple ci-dessous, Bigip1 et Bigip2 sont membres, à la fois, des Sync-Only et Sync-Failover
device groups.
Figure 12 : Exemple de Synch only Device Group
2.2.5. Détection de Failover

Pour assurer la continuité de service, le BIG-IP LTM peut être configuré en failover automatique sous
certaines conditions. Ces conditions sont une rupture au niveau du réseau, une panne de commutateur,
une panne de l’interface réseau et une panne au niveau du BIG-IP lui-même.
▪ VLAN Failsafe : Le BIG-IP LTM supporte la détection de panne sur tous les adaptateurs réseaux
et éléments réseaux associés. Quand la fonction de VLAN failsafe est activée sur un VLAN, le
BIG-IP LTM analyse le trafic réseau à travers le VLAN. Si le BIG-IP LTM ne détecte pas de trafic
sur ce VLAN durant la moitié du timeout de failover, il entreprend de générer du trafic à partir
de requêtes ARP sur les éléments réseaux connus. Si le BIG-IP LTM ne reçoit pas de trafic avant

l’expiration du timeout, un failover est initialisé. Le BIG-IP LTM en Standby détecte la perte de
signal avec le BIG-IP LTM Actif, et passe en mode Actif pour assurer la continuité de service.
▪ Gateway Failsafe : La fonction Gateway Failsafe génère du trafic entre le BIG-IP LTM actif et un
élément réseau, comme par exemple le routeur par défaut. Ceci permet d’indiquer la perte de
connexion vers l’extérieur, quand le routeur n’est pas accessible durant une période spécifiée.
Le BIG-IP LTM est configuré pour l’interroger à un intervalle régulier. Si le BIG-IP LTM ne reçoit
pas de réponse avant l’expiration du timeout, il passe en mode Standby. Le BIG-IP LTM en
Standby détecte la perte de signal avec le BIG-IP LTM Actif, et passe en mode Actif pour assurer
la continuité de service.
▪ HA group : Cette fonction permet au BIG-IP de surveiller les trunks, pools ou clusters (châssis
VIPRION) pour définir un score de disponibilité pour chaque BIG-IP appartenant à un groupe. Ce
score est défini par Traffic Group. A chaque fois qu’un de ces éléments n’est plus disponible, le
score est décrémenté. L’équipement avec le score le plus haut devient l’actif pour le Traffic
Group.
2.2.6. Serial et Network Failover

Lors de la création d’un device group, il est possible de spécifier si le Big-IP doit utiliser le câble série ou
le réseau pour les opérations de failover.
Cependant, l’utilisation du câble série n’est possible que dans un device group qui contient un maximum
de deux Big-IPs. Pour un groupe avec plus de deux équipements, le network failover est requis. Enfin, si
la plateforme est un VIPRION, il est obligatoire d’utiliser le network failover.
▪ Hardware Failover : Ce mode utilise une connexion directe à partir d’un câble de failover (fourni)
deux BIG-IP LTM. Cette fonctionnalité permet de relier deux BIG-IP LTM sans aucun lien réseau.
C’est un système simple permettant de relier deux BIG-IP LTM pour détecter sur le serveur Actif
une variation de courant à travers le câble. Le BIG-IP LTM en Standby devient Actif en moins de
200ms après la détection du changement de courant du BIG-IP Actif. Le hardware failover est
validé par défaut. Le Hardware failover est limité à 50 feet (env. 16m) ; au-delà de cette distance
l’atténuation du signal est trop forte. Pour éviter le point de défaillance du câble série, il est
possible d’utiliser un second câble failover de type « network failover » en complément.
▪ Network failover : Ce mode utilise le réseau pour les communications entre les BIG-IP LTM.
L’utilisation du réseau permet ainsi d’installer les boîtiers dans des zones éloignées sans
limitation comparable au Hardware Failover. Ils doivent cependant être configurés dans le
même sous réseau. Comme pour le Hardware Failover, la perte de signal due à une rupture du
réseau déclenche le basculement d’un des BIG-IPs en mode Standby en mode Actif.

2.2.7. Exemples d’architectures de haute disponibilité
2.2.7.1 Mode Actif/Passif
Figure 13 : Exemple d'architecture en actif passif
Dans cette architecture, un Sync-Failover Device Group est créé et contient l’équipement LTM1 et
l’équipement LTM2 en tant que membres.
Le Traffic-Group 1 contient tous les objets en charge du traffic (SelfIPs, VIPs, NAT, etc).

2.2.7.2 Mode Actif/Actif
Figure 14 : Exemple d'architecture en actif actif
Dans cette architecture, un Sync-Failover Device Group est créé et contient l’équipement LTM1 et
l’équipement LTM2 en tant que membres.
Deux Traffic-Groups sont créés et contiennent leurs propres objets.
Pour chaque traffic group, il est désigné un BigIP différent en tant qu’équipement Actif et équipement
standby.

2.2.7.3 Mode Actif/ Actif/ Actif
Figure 15 : Exemple d'architecture avec cluster de trois boitiers
Cette architecture est la même que précédemment mais en ajoutant un troisième traffic group et un
troisième équipement.
La configuration est la même que pour l’exemple Actif/Actif. Il faut juste ajouter un troisième
équipement (LTM3) dans le Sync-Failover device group ; et créer un nouveau traffic-group sur lequel
l’équipement Actif sera le LTM3.
2.2.7.4 Mécanismes d’élection de l’équipement actif pour un traffic-group avec

plus de deux équipements dans le cluster
Les deux méthodes d’élection décrites ci-dessous peuvent utiliser le mécanisme appelé HA Group
Monitor qui permet de savoir si un équipement est disponible pour prendre la gestion du traffic group
(cf 2.2.5). La méthode HA Score nécessite l’utilisation du HA Group Monitor.
a. Preffered Device Order and then Load Aware
Avec cette méthode, le prochain équipement actif pour un traffic group est le premier BIG-IP disponible
de la liste. Si aucun BIG-IP n’est disponible dans la liste « Preferred Order », la méthode Load Aware est
alors utilisée.
La méthode Load Aware fait en sorte que les Traffic Group qui génèrent le plus de trafic soient
automatiquement gérés par les boîtiers les plus puissants. Pour cela, on définit une « HA Capacity » qui
représente la capacité de charge du boîtier. Cette charge est définie relativement aux autres éléments
du groupe (ex : un équipement avec une « HA Capacity » de 4 pourra traiter deux fois plus de trafic

qu’un équipement avec une « HA Capacity » de 2 et quatre fois plus de trafic qu’un équipement avec
une « HA Capacity » de 1).
De la même manière, il faut définir un « HA Load Factor » sur chaque trafic group qui représente la
charge de trafic générée par un Traffic Group relativement aux autres.
Ces deux valeurs permettent de déterminer le « Next Active Device » qui représente l’équipement qui
devra reprendre un ou plusieurs Traffic Group en cas d’indisponibilité d’un des équipements.
Figure 16 : Ecran de configuration « Preffered Device Order and then Load Aware »
b. HA Score
La méthode HA Score utilise le score calculé par la fonction HA Group pour déterminer l’équipement
actif pour un Traffic Group.

Figure 17 : Ecran de configuration « HA Score »
c. Automatic failback
Il est possible d’ajouter la fonction Automatic failback à la méthode de sélection de l’équipement actif
pour faire en sorte que le traffic group rebascule sur l’ancien BIG-IP actif dès que celui-ci est disponible.
d. Recommandations
Voici quelques recommandations sur les méthodes de sélection de l’équipement actif pour un traffic
group en fonction des besoins :
• Faible nombre de traffic group : Preferred Device Order

• Garder le contrôle sur la répartition des traffic group : Preferred Device Order avec automatic
failback
• Configuration complexe (trop de traffic groups pour une gestion manuelle) : Load Aware
• Matériels non homogènes dans un cluster : Laod Aware (avec HA Capacity) ou Preferred Device
Order avec automatic failback

2.2.7.5 Haute disponibilité et synchronisation de configuration
Figure 18 : exemple d'architecture complète
Cette architecture met en œuvre tous les concepts du Device Management :
Deux Sync-Failover groups sont créés : le groupe A qui contient LTM1 et LTM2 ; le groupe B qui contient
LTM3 et LTM4.
Chaque groupe se voit attribuer son propre Traffic-Group pour la bascule du trafic applicatif.
Un Sync-Only device group est créé sur un répertoire particulier dans chaque LTM. Ce répertoire
contient les objets à partager entre tous les équipements.
2.3. Proxy Applicatifs

Pour prendre en compte la spécificité de chaque application et permettre une répartition des requêtes
en fonction de critères de niveaux 7, BIG-IP LTM dispose de différents proxys applicatifs. Ces proxys sont
particulièrement utiles lorsque des règles de NAT sont implémentées pour permettre de modifier le
contenu applicatif des échanges lorsque les IP des serveurs sont masquées aux utilisateurs.
L’application de l’intelligence de niveau 7 sur un service porté par le BIG-IP LTM passe par l’utilisation
d’un profile. 8 profils sont aujourd’hui disponibles pour gérer les applications les plus utilisées dans le
monde de l’entreprise. Voici la liste des applications supportées :
▪ HTTP
▪ HTTPs
▪ FTP
▪ DNS
▪ Radius
▪ Diameter
▪ SIP
▪ SMTP

SI une application propriétaire n’est pas présente dans la liste, le BIG-IP LTM peut à minima se
comporter en tant que proxy TCP ou UDP. Des irules peuvent ensuite être implémentées pour prendre
en compte la spécificité du protocole et prendre des décisions intelligentes de niveau 7.
2.4. Partage de charge

Le système full-proxy du TMOS permet de s’affranchir de la plupart des contraintes présentes dans les
environnements applicatifs et systèmes :
▪ Il est possible de répartir un service sur des ports applicatifs différents ou non.
▪ Il n’y a pas de limite spécifique au nombre de serveurs réels par serveur virtuel
▪ Il est possible de définir plusieurs serveurs virtuels associés à un serveur réel
2.4.1. Description des méthodes de partage de charge

2.4.1.1 Static LB (algorithmes statiques)
▪ Round Robin: Les nouvelles connexions sont envoyées séquentiellement aux serveurs
disponibles.
▪ Ratio : Un poids est donné à chaque serveur. Cette valeur déterminera le nombre de connexions
qui seront envoyées à ce serveur par rapport aux autres.
▪ Priority : BIG-IP LTM orientera uniquement les connexions vers les serveurs disponibles et ayant
la priorité la plus haute. Cette méthode est combinable avec tous les autres algorithmes.
▪ Dans le cas d’un service WEB, il est possible de définir une URL de repli ou « sorry page »
(fallback URL)
2.4.1.2 Dynamic LB (algorithmes dynamiques)

▪ Least connection: Le BIG-IP LTM envoie la prochaine connexion au serveur qui actuellement en
traite le moins (mesuré toutes les secondes).
▪ Fastest : Le BIG-IP LTM transmet la nouvelle connexion au serveur actuellement le plus
« rapide » au niveau applicatif (mesure effectuée au niveau 7 et non au niveau 4).
▪ Observed : La méthode Observed est basée sur la méthode Ratio mais ici le Ratio est calculé
dynamiquement en comptant le nombre de connexions L4 établies avec le serveur. Le ratio est
recalculé à intervalle régulier.
▪ Predictive : Le BIG-IP LTM envoie la prochaine connexion au serveur qui a la plus faible montée
en charge. Le nombre de connexions de chaque serveur est calculé à intervalle régulier et un
ratio de progression est calculé dynamiquement à chaque mesure et est attribué à chaque
serveur.
▪ Dynamic Ratio : Le BIG-IP LTM envoie la prochaine connexion au serveur actuellement le plus
performant ou disponible, selon la combinaison de critères récupérés via SNMP (OID) ou WMI
(windows) de votre choix. Plusieurs variables SNMP/WMI peuvent être récupérées et
pondérées, afin d’obtenir un ratio par membre.
▪ Least Sessions : Le serveur choisi par le BIG-IP LTM pour recevoir une nouvelle connexion est
celui disposant du plus petit nombre de sessions persistantes établies.

2.5. Modèles d’architecture
2.5.1. Architecture en mode Bridge (niveau 2)

Cette architecture permet de connecter les clients et serveurs sur le même réseau IP, tout en
permettant au répartiteur de charge de répartir la charge de se comporter en commutateur standard
pour tous les flux, hormis ceux destinés à des adresses IP déclarés dans l’équipement pour répartir la
charge vers des serveurs et/ou routeur/firewalls. Pour cela, un vlan client et un vlan serveur sont créés.
Cela permet d’isoler les domaines de collision, afin que le BIG-IP LTM agisse comme un pont transparent
ou non transparent suivant la configuration réalisée (mode opaque, mode transparent, mode
translucent).
Figure 19 : Exemple d'architecture de niveau 2
Le BIG-IP agira comme une passerelle de niveau 2 en réémettant tout paquet avec sa propre adresse
MAC.
2.5.2. Architecture routage ou niveau 3

C’est le mode de déploiement le plus simple. La configuration du BIG-IP LTM, permet d’insérer les
fonctions de haute disponibilité et d’équilibrage de charge, en séparant au niveau du plan d’adressage IP
de votre réseau les réseaux externes (routeurs ISP, firewalls) des équipements internes (serveurs, etc.).
Dans ce mode, le BIG-IP LTM est positionné en coupure des flux. Il vient protéger les réseaux internes en
n’autorisant uniquement les connexions des clients au travers des Serveurs Virtuels configurés. Ainsi
aucun accès direct aux serveurs n’est possible (sauf ouverture de flux spécifiques configurés).

Figure 20 : Exemple d'architecture de niveau 3
2.5.3. Architecture dite en manchot (ou One Leg)

BIG-IP LTM peut s’intégrer dans une architecture de type one leg ou en manchot. En effet les clients
s’adressent à une adresse IP virtuelle se trouvant sur le BIG-IP LTM. Le BIG-IP LTM oriente la connexion
directement vers les serveurs se trouvant sur le même sous-réseau ou possède la route pour joindre les
serveurs ne se trouvant pas directement connectés. Une architecture de type manchot est donc
réalisable. Cependant tout le trafic entre le client et le BIG-IP LTM ainsi qu’entre le BIG-IP LTM et les
serveurs passera par la même interface réseau. Dans ce type d’architecture il est nécessaire de veiller
régulièrement que l’interface n’arrive pas à saturation de capacité de bande passante, auquel cas il
conviendra de constituer une agrégation de liens.

Figure 21 : Equilibrage d’un réseau IP distant
2.5.4. Mutualisation du BIG-IP LTM sur plusieurs sous-réseaux

Par défaut, le BIG-IP LTM fonctionne de manière similaire à un firewall, c’est à dire qu’il n’autorise aucun
trafic à passer d’un VLAN à un autre. Les VLANs sont dits étanches. Il faut donc lui spécifier quel type de
trafic va être autorisé à le traverser en créant un/des serveur(s) virtuel(s). Ceux-ci indiquent au BIG-IP
LTM le trafic à intercepter. Parmi les paramètres des serveurs virtuels, il est possible de définir la liste
des VLANs autorisés à accéder au Serveur Virtuel. Ceci permet de mutualiser le service de Load
Balancing sur plusieurs VLANs. S’il est nécessaire de conserver la sécurisation des VLANs, il est alors
nécessaire de ne donner l’accès au serveur virtuel qu’au VLAN sur lequel celui-ci a été créé. De plus il
s’avère nécessaire de sécuriser au maximum l’administration du BIG-IP LTM.
2.5.5. Retour direct des serveurs

BIG-IP LTM supporte l’équilibrage de charge de serveurs se trouvant sur le même sous-réseau IP que lui
avec un retour direct par les serveurs. Dans ce mode les réponses des serveurs ne repassent pas par le
BIG-IP mais vont directement vers le client. Pour ce faire, il est nécessaire de configurer le serveur virtuel
afin qu’il n’effectue pas de translation d’adresse et de port destination. De plus sur les serveurs il est
nécessaire de configurer une adresse de loopback afin que les serveurs puissent répondent aux requêtes
des utilisateurs. Dans ce mode BIG-IP LTM surveille la disponibilité des serveurs, oriente les connexions
vers les serveurs en modifiant l’adresse MAC de destination des paquets. Le retour des serveurs ne
passant pas par les serveurs, les timeouts de sessions doivent être plus élevés.

Figure 22 : Architectuer avec retour direct
2.6. Tests de vie

BIG-IP LTM permet d'éviter les pannes en détectant rapidement les pannes serveurs et applicatives et
en dirigeant le trafic vers les serveurs et les applications opérationnels. Ainsi, il garantit la disponibilité
permanente des sites en vérifiant le bon fonctionnement de tous les composants réseau. Ce mécanisme
autrement appelé Health Check peut s’effectuer à différents niveaux :
▪ Address checks (pings) : BIG-IP LTM envoie une requête ICMP à l’adresse du serveur spécifiée
(node). Cette vérification est par défaut active et réalisée sur la totalité des serveurs configurés.
Ce test permet de vérifier si l’adresse IP est joignable.
▪ Service checks (Connexion TCP) : BIG-IP LTM essaye d’établir une connexion TCP sur les serveurs
spécifiés. Une fois la connexion établie, elle est immédiatement fermée. Ce test permet de
vérifier si le service écoute correctement sur un serveur donné.
▪ Enhanced Content Verification (ECV ou Vérification avancée du contenu) : BIG-IP LTM ne se
contente pas uniquement d’établir une connexion TCP sur les serveurs spécifiés, il vérifie aussi
que la réponse du service correspond à un format de requête donné. Ce test permet de vérifier
si le service répond correctement à une simple requête. Tous les protocoles TCP sont supportés.
▪ Enhanced Application Verification (EAV ou Vérification avancée de l’application) : BIG-IP LTM ne
se contente pas uniquement d’établir une connexion TCP sur les serveurs spécifiés, il interagît
avec ceux-ci en respectant le protocole. BIG-IP LTM exécute un script (Shell ou Perl pouvant
faire appel à des applications externes) qui lui retournera un résultat positif ou négatif. Ce test
permet de simuler un scénario utilisateur avec une application spécifique. Les scripts supportés

et fournis en standard sont : HTTP, FTP, POP3, SMTP, NNTP, SQL, Radius, LDAP, IMAP, SQL. Il est
possible de créer ses propres EAV pour tous les protocoles TCP et UDP en développant des
scripts spécifiques.
La fréquence (nombre de tentatives) ainsi que le time-out des Health checks pour les différents modes
présentés ci-dessus sont totalement configurables. BIG-IP LTM orientera les nouvelles connexions
uniquement vers les serveurs détectés comme disponibles.
Tous les health checks sont réalisés à chaque intervalle de test configuré (pas de test cyclique), et le
nombre de serveurs et de services n’impacte pas l’intervalle d’un ou plusieurs serveurs. Le rythme de
chaque test est déterminé par un temps « intervalle » et un temps « limite » configurable par test. En
cas de non réponse, le boitier F5 retente 3 fois en patientant le temps de « l’intervalle » configuré et
jusqu'au temps « limite ». Si durant cette période aucune réponse correspondant n’est reçue, le test est
considéré comme échoué et l’élément auquel il était associé est marqué comme tel. Il est possible de
définir des health checks globaux qui seront utilisés de manière dynamique sur les différents serveurs ou
services associés à un même pool sans avoir à définir pour chaque serveur un objet health check
spécifique.
Plusieurs Healthcheck peuvent être positionnés sur les mêmes serveurs. Cela permet par exemple de
faire une requète http et une requète LDAP sur un serveur pour valider une application intégrant http et
LDAP. Mais il est également possible de valider que le serveur 1 est actif, si il répond aux requètes http
et que le serveur 2 répond aux requètes SQL. Les moniteurs applicatifs permettent en cela de valider
une chaine applicative complète distribuée sur des serveurs différents, pour un seul membre.
2.7. Mécanismes de persistance

Selon les caractéristiques, le fonctionnement ou l’implémentation des protocoles il peut s’avérer
nécessaire que lorsqu’un utilisateur a ouvert une connexion sur l’un des serveurs d’un pool, celui-ci
persiste sur ce même serveur pendant la totalité de la session, voire pendant une période de temps
déterminée. Ainsi, si l’on désire faire persister un utilisateur sur un serveur réel, il est nécessaire de
l’identifier. Pour cela, BIG-IP LTM propose plusieurs méthodes :
▪ Persistance Simple (basée sur adresse IP) : Basée sur l’adresse IP source ou destination
▪ SSL persistence : Basée sur l’identifiant de session SSL (Session ID)
▪ Windows Terminal Server Persistence : Basée sur le numéro de session msrdp
▪ SIP persistence : Basée sur le champ Call-Id
▪ Cookie persistence :
▪ Insert mode : BIG-IP LTM insère un cookie sur le navigateur client
▪ Rewrite mode : BIG-IP LTM réécrit le cookie serveur et l’insère sur le navigateur client
▪ Passive mode : BIG-IP LTM base sa table de persistance sur le contenu du cookie déclaré
▪ Hash mode : BIG-IP LTM « hashe » un cookie afin d’en extraire un identifiant unique par
utilisateur

▪ Hash : Persistance basée sur une information (URI, information dans le payload UDP / TCP, …).
Le résultat de ce hash permet de persister vers le même serveur. Cette méthode est employée
par exemple pour répartir la charge à destination de proxy/cache. Le hash est réalisé sur la parti
Hostname et/ou path des URI http, afin de garantir que tous les objets Web récupérés sur un
site Web au travers des proxy/cache, sont stockés dans un seul de ces proxy/cache, afin de ne
pas récupérer plusieurs fois l’objet sur Internet, et donc optimiser l’usage de la liaison Internet.
Il est également possible de configurer le BIG-IP LTM afin de faire persister l’ensemble des connexions
d’un même utilisateur vers le même serveur réel quel que soit le service auquel il veut accéder. Ainsi un
utilisateur accédant à une page d’un service VIP : HTTP persistera sur le même serveur s’il accède
ensuite au service VIP : HTTPS (fonction : Persistance Accross Services).
Il en est de même si l’on souhaite associer une persistence entre 2 adresses de services applicatifs sur
des adresses IP différentes (Fonction : persist accross virtuals).
2.8. Translations d’adresses IP

La fonction de translation d’adresses IP est réalisée suivant plusieurs modes :
▪ NAT : le BIG-IP LTM convertit l’adresse IP déclarée, vers une autre adresse IP, quel que soit le
traitement effectué par le boitier (routage, répartition de charge, …). Cette fonctionnalité peut
être limité aux VLAN sur lesquels arrivent le trafic. Il est donc possible de faire du NAT 1 vers 1,
seulement dans le cas ou le flux arrive par un des VLANs déclarés dans la configuration.
Figure 23 : Configuration du SNAT
▪ SNAT global : Le BIG-IP LTM effectue une translation de type PAT (Port and Adress Translation).
Dans ce cas, un groupe d’adresses IP est converti en une seule et unique adresse de

« translation ». Cette option peut également être configurée en fonction des vlans recevant les
requètes à « translater ».
▪ SNAT automap: Le BIG-IP LTM reçoit les flux sur un Virtual Server et les converti avec l’adresse IP
de son interface du VLAn de sorti à destination des serveurs. Dans ce cas, il est possible de faire
des translations différentes, pour les mêmes adresses IP source et destination, en fonction du
VLAN choisi en sorti. Cette option permet par exemple de faire une translation spécifique
lorsque l’on utilise plusieurs ISP pour accéder à Internet. Bien que les IP source et destination
soient identiques, le répartiteur de charge choisira un ISP le plus « disponible » par exemple, et
la fonction de SNAT Automap, si elle est configurée, permettra en sorti d’utiliser l’IP de l’ISP1 ou
l’ISP2 et ainsi garantir les flux aller et retour par l’ISP choisi.
▪ SNAT Pool: Le BIG-IP LTM reçoit les flux sur un Virtual Server et les convertit avec une des
adresses IP contenues dans le pool de SNAT associé à ce virtual server. Non seulement il est
alors possible de translater plusieurs IP en une seule, mais dans le cas ou il y aurait un nombre
important de ports ouverts simultanément en sorti, de pouvoir faire de « l’overload » en
distribuant le trafic sur plusieurs adresses de translation.
▪ iSNAT (Intelligent SNAT): Le BIG-IP LTM reçoit des flux sur un virtual server, et à l’aide d’une
iRule, une translation est effectuée. Cela permet de faire sur SNAT en fonction de critères niveau
4 à 7.
2.9. Fonctions d’optimisations
2.9.1. Terminaison SSL

Le TMOS permet de terminer les sessions SSL/TLS, afin d’augmenter les performances d’accélération SSL
et d’inspecter les données pour effectuer une décision au niveau de l’application :
▪ Décision de répartition de charge au niveau de l’application

▪ Persistance. Ex : cookies, expression
▪ Gestion du trafic : Redirection
▪ Filtrage
▪ Authentification
▪ Modification du contenu
▪ Limiter le nombre de sessions SSL sur le proxy
▪ Il est possible au TMOS d’ajouter les informations du certificat (cipher) dans le header http, s’ils
sont nécessaires à l’application
2.9.1.1 Tunnel SSL/TLS entre le TMOS et le serveur :

Le TMOS permet de chiffrer ou re-chiffrer les sessions avec les services afin de créer un chiffrement de
bout en bout de celles-ci.
▪ Re-chiffre les requêtes déchiffrées sur TMOS vers le service

▪ Permet de réaliser une continuité SSL/TLS du l’utilisateur jusqu’au service, tout en assurant les
fonctions de gestion de trafic au niveau l’application.
▪ Utiliser une autre taille de clé entre le TMOS et le serveur.

▪ Authentification du TMOS à partir d’un certificat X509 vis-à-vis du serveur.
Les avantages de ce type d’architecture sont les suivants :
▪ Élimine le besoin de serveur WEB avec du SSL

▪ Simplifie la gestion des certificats SSL, seul un certificat est nécessaire sur la passerelle TMOS
SSL.
▪ Réduit fortement la charge CPU des serveurs web et augmente le nombre max. de connexions
/sec.
▪ Permet de gérer les listes de révocation sur le TMOS.
▪ Permet de gérer les Certificats Authorities sur le TMOS.
▪ Permet de connecter le TMOS à un serveur LDAP ou serveur OCSP pour vérifier le certificat des
utilisateurs souhaitant accéder au site dans le cas d’une architecture PKI centralisée de ceux-ci.
2.9.1.2 Proxy SSL

Une des limitations de la terminaison SSL est l’impossibilité pour l’utilisateur de présenter un certificat
SSL client au serveur. En effet dans ce type d’architecture le BIG-IP LTM établit deux sessions sécurisées
une entre lui et le client, la seconde avec le serveur.
Pour permettre au BIG-IP de gérer au niveau 7 les flux chiffrés et à la fois permettre une authentification
de l’utilisateur avec certificat, il est possible d’implémenter la technologie Proxy SSL.
Dans ce mode de fonctionnement le BIG-IP dispo des clefs privées des serveurs afin de déchiffrer la
session avec l’utilisateur mais reste transparent sur la phase d’établissement de la session entre
l’utilisateur et le serveur. De cette façon si le serveur demande une authentification mutuelle, le client
aura la possibilité d’envoyer son certificat.
2.9.1.3 Accélération matérielle

Les BIG-IP intègrent en standard un ASIC d’accélération SSL/TLS accélérant les chiffrements
asymétriques et symétriques. Cette solution permet de ne jamais utiliser de ressources CPU pour
réaliser le chiffrement des sessions à leur initialisation et durant le transfert de données a travers le BIG-
IP. Le chiffrement asymétrique (TPS) et symétrique (Bulk) n’a aucun impact sur les performances de
répartition de charge du TMOS.
2.9.1.4 Protocoles Supportés

▪ SSL v2, v3
▪ TLS v1.0, v1.1, v1.2
▪ DTLS
▪ Il est possible d’obliger l’utilisation d’une et une seule ou plusieurs version SSL et/ou TLS.

Figure 24 : Déchiffrement SSL
Step Description
La session HTTPS (SSL) est négociée entre le Client et le BIG-IP LTM. Le BIG-IP LTM
1
termine la session SSL et la décrypte.
La répartition de charge est effectuée par le BIG-IP LTM (éventuellement au niveau 7) sur
2
la session HTTP.
3 La session HTTP est envoyée vers un des serveurs.

2.9.1.5 Fonction Crypto Offload
Afin d’améliorer les capacités des Virtual Edition, cette fonction permet de déporter la partie
asymétrique (négociation de la clé de session symétrique) vers un équipement physique F5.
User
SSL Crypto Offload
SSL Acceleration All Application Services

+ SSL Crypto Offload Except SSL
SSL Traffic Only

for Offload
BIG-IP 12250v
F5 Hardware Multiple
BIG-IP Virtual Editions
High Performance
High Capacity SSL
Applications
Figure 25 : Crypto Offload
La partie symétrique du chiffrement, moins coûteuse en ressources, reste traitée par la Virtual Edition.
2.9.1.6 HTTP Strict Transport Security

La fonction HSTS (RFC 6797) permet de forcer un navigateur à initier toutes les requêtes vers un site en
HTTPS même si la référence à un objet est explicitement définie en HTTP
2.9.2. Optimisation TCP

Le système d’exploitation TMOS intègre une gestion avancée du protocole TCP. TMOS est construit
autour d’un proxy TCP : l’équipement F5 gère deux connexions TCP différentes, une vers le client et une
autre vers le serveur. Il est ainsi possible d’appliquer des propriétés TCP différentes à ces deux

connexions (taille de fenêtres, MSS, SACK, Timestamps, …). Le principal bénéfice est de s’adapter aux
vitesses de dialogue du client et du serveur. Ainsi, si le serveur est connecté sur un LAN Gigabit et que le
client est connecté à une liaison ADSL, l’équipement F5 est capable de dialoguer à la vitesse du serveur
pour libérer au plus vite la connexion TCP et fournir le contenu à la vitesse du client.
Cette fonctionnalité utilise un ensemble d’améliorations propres à TCP/IP :
▪ Delayed and Selective Acknowledgements (RFC 2018)

▪ Explicit Congestion Notification ECN (RFC 3168)
▪ Limited and Fast Retransmits (RFC 3042 and RFC2582)
▪ Slow Start with Congestion Avoidance (RFC 2581)
▪ Adaptive Initial Congestion Windows (RFC 3390)
▪ TimeStamps and Windows Scaling (RFC 1323)
▪ TCP Slow Start (RFC 3390)
▪ Bandwidth Delay Control
▪ Contournements de problèmes connus sur les piles TCP de plusieurs solutions (Windows 98, XP,
2000, IBM AIX, Sun Solaris, etc)
▪ Reno asymmetric optimizations (RFC2582)
▪ TCP extensions for high-speed networks (RFC1323)
Cela permet des optimisations symétriques et asymétriques, sans nécessiter aucun client particulier.
Figure 26 : Pile TCP optimisée TCP Express

BIG-IP dispose de plusieurs profiles TCP pré-configurés :
Figure 27 : Exemple de profiles TCP disponibles
Les profils commençant par le préfixe « f5 » sont ceux à utiliser de préférence lors des déploiements.
Figure 28 : Détail de la configuration d'un profil TCP
2.9.3. Compression HTTP

BIG-IP est en mesure de compresser les flux HTTP et les flux HTTPS (si la fonctionnalité d’accélération
SSL est utilisée) afin de réduire la bande passante utilisée entre le poste client et le Web Accelerator. La
compression de ces flux se fait en respectant totalement le protocole http 1.1 (RFC 2616).

Les flux sont compressés à l’aide des algorithmes gzip ou deflate. Ces protocoles sont supportés
nativement par tous les navigateurs respectant le protocole HTTP 1.1. La compression ne nécessite donc
pas l’installation d’un composant logiciel sur le poste client.
Seuls les objets HTTP de type texte sont compressés : html, css, javascript,… La reconnaissance du type
de fichier à compresser se fait en analysant le MIME-Type des objets renvoyés par le serveur.
Figure 29 : Compression HTTP
Note : Les objets HTTP mis en cache sont stockés sous forme compressés afin d’optimiser les temps de
traitement. Il existe certains bugs connus des navigateurs dans l’implémentation de la compression. Afin
de faciliter le déploiement de la solution, BIG-IP implémente des mécanismes de contournement afin de
respecter la compatibilité avec ces navigateurs.
Quand la compression HTTP est activée dans un environnement Client/Server, le browser insère dans le
header HTTP le paramètre Accept-Encoding spécifiant les algorithmes de compression supportés par le
browser. Le serveur lit le header http en provenance de l’utilisateur et compresse le contenu de la
réponse avec un des algorithmes supportés. Le serveur insère dans le header http de la réponse le
paramètre Content-Encoding pour informer le browser que le contenu a été compresse et avec quel
algorithme.
Les avantages d’utiliser la compression http sur BIG-IP sont les suivants :
▪ Compression selon le contenu
▪ Compresse uniquement les types de fichiers nécessaires
▪ Basée sur des listes d’URI ou de types MIME
▪ Compression en fonction du client
▪ Le TMOS compresse le contenu sur la base du temps de latence TCP.
▪ Le TMOS a la capacité d’observer le RTT du client.
▪ Activation granulaire selon des règles iRule : il est possible de réaliser la compression à partir de
critères applicatifs.
▪ Allocation de ressources réglable : TMOS permet l’allocation de plus de ressource mémoire

et/ou CPU pour les tâches de compression prioritaires.

▪ Transparente : la fonction permettant de réaliser la compression est standard au protocole HTTP
version 1.1. Cette fonction est donc supportée par la plupart des navigateurs et elle est
totalement transparente pour les utilisateurs.
Figure 30 : Exemple de configuration de la compression HTTP

2.9.4. Caching
La mise en cache des objets HTTP permet de réduire de manière importante le nombre de requêtes sur
les serveurs HTTP. En effet, le BIG-IP va délivrer le contenu à la place des serveurs selon la cinématique
suivante :
▪ Première connexion : le contenu n’est pas dans le cache du BIG-IP. Le client initie la requête (1).
Le BIG-IP la transfère au serveur (le serveur est choisi en fonction de la méthode de répartition
de charge configurée) (2). Le serveur répond au BIG-IP (3). Ce dernier stocke le contenu de la
réponse dans son cache (4) ainsi que les informations de validité renvoyées par le serveur et
renvoie le contenu au serveur (5).
Figure 31 : Cache HTTP
▪ Deuxième connexion ; le contenu est dans le cache du BIG-IP. Le client initie la requête (1). Le
BIG-IP récupère le contenu à partir de son cache (2) tout en vérifiant que le contenu est toujours
valide. Si le contenu est valide le contenu est renvoyé au client (3) sinon la requête est
acheminée vers le serveur. TMOS possède une solution de RAM cache, pour augmenter les
temps de réponse des serveurs Web.
Figure 32 : Cache HTTP
Les avantages apportés par le cache http sont les suivants :
▪ Utilisée pour réduire le trafic vers les serveurs en back-end
▪ Très spécialisée et peut être utilisé avec les iRules

▪ Utiles pour les objets les plus demandes et le contenu statique
▪ Augmente les performances, si elle est utilisée en conjonction avec la compression
▪ Les données seront stockées dans le cache déjà compressée.
▪ Support dans sa totalité du RFC 2616.
▪ Possibilité de cacher les contenus suivant : 200, 203, 206, 300, 301, et 410 responses
▪ Response GET methods
▪ Contenu basée sur le User-Agent et Accept-Encoding values.
Figure 33 : Ecran de configuration du Ram cache

2.9.5. Passerelle HTTP/2
Le protocole HTTP/2 est défini dans la RFC 7540. Le LTM peut faire office de passerelle entre un client et
un serveur Web en transformant les requêtes HTTP/2 en HTTP/1.1 ou 1.0. Cela permet de proposer
rapidement le support de HTTP/2 sans avoir à mettre à jour les serveurs Web.
Figure 34 : Passerelle HTTP/2
Les principales différences entre HTTP/1.1 et HTTP/2 sont listées ci-dessous :
Figure 35 : Principales différences HTTP/1.1 et HTTP/2

2.9.6. Rate Shaping
Le TMOS possède la fonction d’allocation dynamique de bande passante sur différents critères qui vont
du niveau 3, 4 et applicatif.
Contrôle de la bande passante sophistiqué :
▪ Limitation flexible de la bande passante

▪ Allocation dynamique de la bande passante
▪ Traffic queuing (stochastic fair queue, FIFO ToS priority queue)
Classification granulaire du trafic du L2 à travers le L7. Le support d’iRules permet de classifier tous types
de trafic
Solution de contrôle multi directionnel :
▪ Contrôle la bande passante dans toutes les directions: VLAN, VIP, Serveurs, Users, …
▪ Définition d’une classe de trafic selon
▪ Débit de base
▪ Débit Crête
▪ Burst
▪ Direction: Client side, Server side, Any
▪ Discipline dans la file :
– Stochastic Fair
– Priority Fifo
2.9.7. Contrôle de bande passante

La fonction de contrôle de bande passante permet d’appliquer un contrôle de débit sur un trafic
spécifique ou de marquer un trafic qui dépasserait la limite.
Les politiques de contrôle de bande passante peuvent être statiques ou dynamiques (par session
utilisateur lorsque le module APM est utilisé ou activées par iRules). Elles contiennent une valeur
maximum de débit. Le trafic qui dépasse la limite est stocké en file d’attente puis droppé si la file
d’attente est pleine. Une politique de contrôle par défaut est créée automatiquement pour traiter le
trafic non traité par les autres politiques (valeur par défaut de 320 Gbps, modifiable par configuration).
Un équipement peut supporter jusqu’à 1024 politiques.

2.9.8. TCP Request Queueing
Cette fonction permet de mettre en file d’attente les connexions qui dépassent la capacité de
connexions (champs connection limit dans la configuration) définie pour un pool, un membre ou un
nœud. Par conséquent, au lieu d’abandonner des connexions qui dépassent la limite définie, la fonction
TCP Request queueing met en attente ces connexions en accord avec des conditions configurées, et les
prend en charge lorsqu’on redescend sous la limite maximale.
Lorsque la persistance de session est utilisée, une requête est mise en file d’attente quand la limite de
connexion du membre est atteinte.
Sans persistance, quand tous les membres du pool ont une limite de connexions spécifiée, une requête
est mise en file d’attente quand tous les membres ont atteint leur limite de connexions.
Figure 36 : Exemple de la configuration au niveau d’un pool

2.9.9. Multiplexage de connexions
La fonction OneConnect permet de réduire le nombre de connexions TCP gérées par les serveurs Web
afin de libérer les ressources physiques (notamment la consommation CPU).
Son fonctionnement est le suivant :
1. Le client ouvre une connexion vers le BIG-IP
2. BIG-IP choisit un serveur pour lui envoyer la connexion
3. BIG-IP cherche une connexion déjà établie sur ce serveur pour la réutiliser
4. Si aucune connexion préétablie n’est disponible, une nouvelle connexion est créée vers le
serveur choisi
Figure 37 : optimisation OneConnect
Lorsque les connexions clientes utilisent le protocole HTTP/1.0, il est possible de convertir en HTTP1.1
les requêtes à destination des serveurs.
2.9.10. Prioritisation des Flux

BIG-IP permet de gérer la priorité des flux de différentes façons.
2.9.10.1 BIG-IP point de marquage de la QoS/ToS
Les champs QoS et ToS des parquets peuvent server aux équipements réseaux en amont et aval à
identifier et traiter des flux différemment en y appliquant des politiques de gestion de bande passante
différentes.
Le BIG-IP peut marquer ou réécrire les champs QoS et ToS d’un paquet entrant ou sortant du BIG-IP(côté
client et côté serveur), en se basant sur les critères définis dans le pool. Ainsi le BIG-IP peut marquer le
trafic selon la priorité des applications.
Par exemple, il est possible de configurer un flux applicative sur le BIG-IP afin qu’un paquet envoyé du
BIG-IP vers les serveurs soit marquer avec un champ QoS de 4 et côté client avec un champ QoS de 3.

Figure 38 : configuration de la gestion de la QOS dans un pool
2.9.10.2 BIG-IP : gestion du load balancing selon la QoS/ToS
BIG-IP est capable d’effectuer des décisions d’équilibrage de charge basées sur les champs:
▪ Niveau de QoS
▪ Niveau de ToS
Ainsi à l’aide des iRules, ll est par exemple possible, selon le champ QoS ou ToS du paquet d’envoyer le
flux vers une ferme de serveurs différente.

2.10. Gestion des tunnels
2.10.1. Tunnels IP
En utilisant les technologies de tunneling F5, vous pouvez configurer un tunnel entre deux équipements
sur différents réseaux de niveau 2, ou implémenter une architecture multi-sites à travers des réseaux
routés. Lorsque vous connaissez l'adresse IP des équipements aux deux extrémités du tunnel, vous
pouvez créer un tunnel d'encapsulation point-à-point entre un BIG-IP et un autre équipement.
BIG-IP fournit différents mécanismes d’encapsulation IP qui sont listés ci-dessous :
▪ GRE
▪ DSLITE
▪ IPIP
▪ IPv4IPv4
▪ IPv4IPv6
▪ IPv6IPv4
▪ IPv6IPv6
▪ PPP
▪ WCCPGRE
▪ VXLAN (avec ou sans OVSDB)
▪ EtherIP
▪ Geneve
2.10.2. IPSEC
Vous pouvez configurer les protocoles IPsec et IKE lorsque vous souhaitez utiliser un autre protocole que
le protocole SSL pour sécuriser le trafic qui traverse un réseau étendu (WAN), d'un système BIG-IP à un
autre. Avec cette mise en œuvre, vous devez configurer le protocole IKE pour établir un canal sécurisé
lors de la phase 1 des négociations.
Figure 39 : Illustration d'un tunnel IPSEC
2.10.2.1 Tunnel mode

Dans le mode tunnel IPsec chiffre l'ensemble du paquet (la charge utile plus l'en-tête IP). Ce paquet
chiffré est ensuite inclus dans la charge utile d’un autre paquet avec un nouvel en-tête. Le trafic envoyé

par ce mode est plus sûr que le trafic envoyé en mode Transport, parce que l'en-tête IP d'origine est
crypté ainsi que les données originales.
2.10.2.2 Transport mode

Le mode de transport utilise le protocole IPSec pour crypter uniquement les données utiles d'un paquet
IP puis insert la charge utile cryptée dans un paquet IP normal. Le trafic envoyé en mode de transport
est moins sûr que le trafic envoyé en mode tunnel, car l'en-tête IP dans chaque paquet n'est pas chiffré.
2.10.3. Ether IP
Dans certaines architectures réseau, le BIG-IP LTM est configuré pour envoyer le trafic des applications
sur des serveurs qui sont mises en œuvre en tant que machines virtuelles VMware (VM). Ces machines
virtuelles peuvent subir une migration en direct, à l'aide de VMware vMotion à travers un réseau étendu
(WAN) sur un hôte dans un autre centre de données.
Afin de préserver toutes les connexions existantes entre le système BIG-IP et une machine virtuelle
pendant que la machine virtuelle migre vers un autre centre de données, vous pouvez créer un tunnel
EtherIP.
Un tunnel EtherIP est un objet que vous créez sur chacun des deux systèmes BIG-IP qui sont installés de
chaque côté d'un WAN. Le tunnel EtherIP utilise le protocole standard de l'industrie EtherIP au tunnel
Ethernet et IEEE 802.3 Media Access Control (MAC) des trames sur un réseau IP. Les deux objets tunnel
EtherIP forment ensemble un tunnel qui relie logiquement deux centres de données. Lorsque le trafic
des applications qui passe entre l'un des BIG-IP et la MV est acheminé à travers le tunnel EtherIP, les
connexions sont conservées pendant et après la migration VM.
Après avoir configuré le système BIG-IP pour préserver les connexions aux machines virtuelles
migrantes, vous pouvez créer un moniteur pour localiser la ressource applicative. Ce moniteur garantit
que le système BIG-IP envoie les connexions à un membre du groupe local plutôt que sur un serveur à
distance, quand quelques-uns des membres du pool ont migré vers un centre de données distant.
2.11. Les policies

Les policies permettent de définir graphiquement des règles avancées de traitement du trafic. Elles
peuvent remplacer les iRules (cf ci-dessous) pour réaliser les manipulations de niveau 7 les plus
fréquentes : router du trafic vers un pool ou un serveur en fonction de critères de niveau 7 (host, url, …),
choisir un profil de persistance à la volée, activer/désactiver le cache et la compression,
activer/désactiver ASM, ajouter ou supprimer des headers, …
Une policy est attachée à un Virtual Server et est composée de règles. Chaque règle contient un ou
plusieurs conditions et une ou plusieurs actions :

Figure 40 : Ecran de configuration d’une policy LTM
Les règles peuvent être appliquées soit dans l’ordre et dans ce cas, la première règle qui correspond au
trafic est appliqué ou avec algorithme de ‘best-match’ et dans ce cas, toutes les règles sont évaluées et
la plus précise par rapport au trafic est activée.
Les capacités des policies ne se limitent pas à HTTP, il est aussi possible de déclencher des actions sur du
trafic TCP (adresses IP, vlan, port, route domain, …) et SSL (vérification de la version de protocole utilisée
et des cipher suites négociées).
2.12. Les iRules

Irule est un langage de scripting orienté évènements qui permet de modifier complètement le
comportement du boitier dans sa façon de traiter les flux et les informations. Basées sur une syntaxe de
type TCL, les irules permettent d’aller encore plus loin dans la gestion des flux et dépasser les options
proposées dans la GUI. Voici quelques exemples d’utilisation des irules :
▪ Choisir un paramètre dans le contenu de la transaction pour prendre une décision de load
balancing
▪ Modifier le contenu des échanges
▪ Appliquer une règle de NAT en fonction de critères de niveau 7
▪ Appliquer un profil de log spécifique à une transaction
▪ Réécrire des urls http
▪ Renvoyer un contenu spécifique à l’utilisateur
▪ Utiliser la base de géolocalisation pour prendre des décisions
▪ Implémenter un proxy applicatif pour une application non connue du BIG-IP
▪ Aller chercher une information sur un service externe pour prendre une décision locale
Ces règles possèdent la structure suivante :
if (condition == TRUE ) { use (pool1) }

else { use (Pool2) }
Les conditions peuvent être multiples et peuvent s’imbriquées les unes avec les autres :
if (condition1== TRUE and condition2== TRUE)
{ if (condition3== TRUE OR condition4== FALSE) { use (pool1) }
else { use (Pool2) }
else { discard }
Les applications du langage irule sont virtuellement infinies.
La programmation d’une irule est orienté évènement car on définit des actions lorsque la transaction de
l’utilisateur passe une certaine étape dans le traitement de la transaction fait par le BIG-IP LTM. Par
exemple, lorsque la session TCP est établie, lorsque l’on a choisi un serveur pour envoyer la transaction
ou encore lorsque l’on vient de recevoir une requête http.
Figure 41 : évènements irules
Toutes les informations relatives aux Irules sont disponibles sur un site communautaire utilisé par 40000
ingénieurs, développeurs, clients. Ce site est accessible à l’url suivante : https://devcentral.f5.com/

2.13. Virtualisation des Solutions BIG-IP LTM
F5 Networks dispose depuis plusieurs années des fonctionnalités liées à la virtualisation. En plus des
offres virtualisées (BIG-IP VE), les solutions F5 disposent de fonctions de segmentation de trafic et
d’administration afin de faire fonctionner plusieurs partitions sur une plateforme matérielle F5 BIGIP.
Les chassis Viprion ainsi que les BIG-IP 5250v, 7250v et 10250v permettent, quant à eux, d’émuler des
instances de BIG-IP indépendants les unes des autres et ayant chacune leurs ressources matérielles
dédiées (fonction vCMP).
2.13.1. Partition d’administration

Le système d’exploitation des solutions F5 Networks (TMOS) le Traffic Management Operating System,
dispose nativement d’une fonction de partitionnement des configurations.
Le principe des partitions d’administration est la création de silos étanches contenant les objets de la
configuration.
Il n’existe dans ce mode qu’un fichier de configuration et chaque objet est identifié (notation /<partition
name>/<object name>) comme appartenant à une unique partition d’administration.
Lorsqu’un compte administrateur est défini sur le TMOS, il est associé à une unique partition. A la
connexion à la CLI ou à la GUI des équipements, l’administrateur ne voit que les objets appartenant à sa
partition.
VLan1 User Manager App. Editor Operator
VS1 VS3 Partition 1 Partition 2 Partition 3

VS2 VS4
VS4 Pool1 Node8
Pool1 Pool2
VS5 Pool2 Node9
Node1 Node2
Administrator Rule2 Node1
Assigns objects to Node3 Node4
Pool3 Node2
partitions Node5 Node6
Node10 Mon1
Assigns users a
Node7 Node8
role to a given Node11
partition Node9 Node10
Prof1 Prof2
Rule1 Rule2
WIP1 SPool1
Common Partition
(Read Only for all – Admin can R/W)
Figure 42 : Virtualisation de l'administration
2.13.2. Segmentation réseau, Route-domain

En complément des partitions d’administration, le TMOS dispose d’une fonction de création de silos
réseau appelé « Route Domain ».

Les « Route Domains » permettre de créer des conteneurs réseaux étanches qui peuvent être associés à
des partitions d’administration.
Il est aussi possible d’avoir le même plan d’adressage réseau dans deux « Route Domain »
(chevauchement ou overlapping IP) en cas de mutualisation des boitiers.
Figure 43 : Virtualisation du routage
Un Route Domain est composé de 1 ou plusieurs VLANs autorisés à échanger du trafic. Lors de la
création d’un objet IP (VIP, serveurs,…), ce dernier est associé à un unique Route Domain soit de
manière explicite si aucune partition administrative n’est définie en rajoutant la notation ‘%x’ (x étant
l’ID du Route Domain) à la fin de l’adresse IP soit de manière implicite si le Route Domain est associé à
une partition administrative. Dans cette configuration, tout objet IP créé dans une partition
administrative est automatiquement créé dans le Route Domain associé à cette partition. Il est possible
de limiter la bande passante consommée par chaque Route Domain (Bandwith Control).
2.13.3. Virtualisation (vCMP)

2.13.3.1 Définition
vCMP (Virtualized Clustered Multi Processing) est une fonction qui permet de faire tourner plusieurs
instances de BIG-IP sur le même équipement physique. vCMP alloue et réserve des ressources
matérielles à chaque instance appelée guest vCMP. Chaque guest créé se comporte comme un
équipement BIG-IP, ayant sa propre CPU, mémoire, espace disque et version de firmware.
vCMP est basé sur la technologie CMP de F5 Networks. CMP permet aux membres d’un cluster (c’est-à-
dire les lames dans un chassis ou les instances TMM sur une appliance) de travailler ensemble, afin de

former un système cohérent et distribué pour partager la charge du trafic. vCMP va un pas plus loin en
permettant de créer et d’utiliser un module BIG-IP virtualisé, en utilisant un hyperviseur propriétaire.
Cet hyperviseur permet de faire bénéficier à chaque guest des cartes d’accélération matérielle
disponibles sur les machines physiques.
Cette fonction est disponible sur les équipements suivants :
• Blades B4450, B4340, B2250, B2150

• BIG-IP i11800, i10800, i7800, i5800, 12250v, 10350v, 10200v-SSL, 10200v, 10250v, 7200v-SSL,
7200v, 7250v, 5200v, 5250v
2.13.3.2 Les composants vCMP

Un système vCMP fait appel aux composants suivants :
▪ Hôte vCMP : c’est le système sur lequel repose l’hyperviseur et qui permet de gérer tous
les guest. L’hôte vCMP est en charge d’allouer les ressources matérielles à chaque guest.
▪ Guest : c’est une instance créée sur le système vCMP dans le but de prendre en charge
un ou plusieurs modules BIG-IP. Chaque guest consiste en une instance de TMOS, plus
un ou plusieurs modules BIG-IP. Chaque guest a ses propres ressources matérielles que
l’hôte vCMP lui alloue. Par conséquent, chaque guest fonctionne comme un équipement
BIG-IP indépendant.
▪ VM : une VM est une portion de guest qui réside sur un slot. Par exemple, un guest qui
utilise quatre slots est composé de quatre VMs.
▪ Cluster BIG-IP : un cluster est un ensemble de slots (appelé aussi membre du cluster)
disponibles sur le chassis.
▪ Cluster Virtuel : un cluster virtuel est similaire à un cluster sur un chassis, excepté que
contrairement à ce dernier, un cluster virtuel est créé pour chaque guest. Un cluster
virtuel contient uniquement la portion des slots qui appartiennent à un guest individuel.
Par exemple, si un guest utilise deux slots, alors ces deux slots représentent un cluster
virtuel. Un guest correspond à un cluster virtuel spécifique.
▪ Disque virtuel : c’est une portion de l’espace disque que le système a alloué à un guest.
Par exemple, si un guest utilise trois slots, le système crée trois disques virtuels pour ce
guest.
▪ Adresse IP de cluster : c’est l’adresse IP de management assignée à un cluster pour
accéder au système. Sur un système vCMP, il y a plusieurs adresses IP de cluster. Une
pour le cluster BIG-IP (pour accéder à l’hôte vCMP), et une pour chaque cluster virtuel
(pour accéder à chaque guest).
L’illustration suivante montre un VIPRION dans lequel trois guests ont été provisionnés. Le guest 1 utilise
uniquement un slot. Les guests 2 et 3 utilisent les quatres slots à disposition.

Figure 44 : Illustration du provisionning du VCMP
A la création d’un guest, il faut spécifier l’image ISO à utiliser.
De plus, un guest peut être bridgé ou isolé du réseau de management de l’hôte vCMP.
Dans le cas bridgé, un accès niveau deux entre les guests, l’hôte vCMP et els équipements connectés à
l’interfaces de management de l’hôte existe. Cela permet de monter des connexions de l’extérieur ou de
l’hôte vers les guests et réciproquement. Malgré le fait que les guests et l’hôte partage la même
interface réseau, chaque guest est vu avec sa propre adresse MAC et IP sur le réseau.
Dans le cas isolé, un guest ne peut pas communiqué avec d’autres guests ou avec l’hôte. La seule façon
qu’ils ont de communiquer est d’utiliser une interface de production configurée explicitement pour
accepter le trafic de management.
Enfin, un guest se voit allouer une liste de VLANs auxquels il a accès pour communiquer avec les réseaux
extérieurs.

Figure 45 : Exemple de configuration d'un guest
Un guest peut être dans un des états suivants :
▪ Configured : c’est l’état pas défaut lorsqu’un guest est créé. Dans cet état, le guest n’est
pas lancé et aucune ressource ne lui est allouée. Il n’est pas non plus possible de
configurer les modules qui lui sont assignés. Pour cela, il faut provisionner et déployer le
guest, et ensuite, provisionner les modules BIG-IP dans le guest.
▪ Provisioned : quand un guest est passé dans cet état, le système alloue les ressources
(cœurs CPU, mémoire physique, etc) pour ce guest. Le système créé aussi les disques
virtuels pour le guest et installe l’image ISO sélectionnée. Tant qu’il est dans l’état
provisionned, un guest ne peut pas être utilisé. Pour cela, il faut le passer dans l’état
Deployed.
▪ Deployed : Après avoir provisionné un guest, on peut le déployer. Quand on déploie un
guest pour la première fois, le système installe une instance du guest sur son disque
virtuel. Dans cet état, le système démarre et maintient une VM sur chaque slot pour
laquelle le guest a des ressources allouées. Par la suite, toute modification (host name,
adresse IP de cluster et liste des VLANs autorisés) est propagée à toutes les VM du
guest.
Les modules BIG-IPs (tels que Local Traffic Manager) peuvent être configurés lorsque le guest est dans
l’état Deployed. De plus, chaque guest hérite de la licence de l’hôte vCMP.
2.13.3.3 Allocation des ressources

Les ressources que le système alloue à chaque guest sont les cœurs CPU, la mémoire physique et
l’espace pour le disque virtuel. L’allocation des ressources se fait lorsque le guest passe à l’état
Provisioned.

Un guest peut être de type « single slot » ou « All-slot ». Pour un guest single slot, le système détermine
le meilleur slot pour guest, c’est à dire celui ayant le moins de cœurs déjà alloués. Ce quest est fixe et ne
peut pas prendre des ressources d’autres slots. Pour un guest all slots, le système alloue les cœurs de
tous les slots disponibles. Ainsi, à chaque nouvelle lame insérée, le système alloue les nouvelles
ressources aux guest all-slot.
Type de guest Allocation des cœurs CPU
Single slot Le système alloue un ou deux cœurs (dépend du modèle de

lame)
All slot Le système alloue un ou deux cœurs (dépend du modèle de

lame) sur chaque slot disponible. Par exemple, si trois slots sont
disponibles, le système alloue les cœurs de chaque slot, c’est-à-
dire trois ou six cœurs au total.
Il est possible d’allouer des ressources SSL par Guest. Trois modes d’allocation sont possibles :
▪ Dedicated – chaque guest n’utilise qu’un coeur SSL

▪ Shared (default) – les guests partagent tous les coeurs SSL
▪ None – tout le SSL est fait en CPU
Cette fonction n’est disponible que sur les équipements suivants :
▪ BIGIP séries 12000, 10000, 7000, 5000

▪ Blade VIPRION B2250
De la même manière, il est possible de limiter la bande passante par Guest. Le principe est le même que
celui du Rate Shaping décrit plus haut. Une politique de shaping appelée « Color Policer » est crée avec
les valeurs de débit minimum, maximum et de burst. Le « Color Policer » est ensuite appliqué au Guest.

3. Exploitation de la solution LTM
3.1. Statistiques et Reporting granulaires : module AVR
Le module AVR (Application Visibility and Reporting) permet d’analyser, de façon extrêmement fine, le
niveau de performance des applications web. Il fournit des métriques détaillées tels que le nombre de
transaction par seconde, les temps de latence, les débits, etc. Ce module est inclus par défaut avec le
module LTM. Il n’a donc pas besoin de licence mais nécessite d’être provisionné pour l’utiliser. De plus,
la brique LTM est obligatoire.
Les métriques sont visibles par application, par Virtual Server, par membre de pool, par URLs, par
géolocalisation de pays, etc. AVR permet aussi de voir des statistiques sur le trafic applicatif qui passe à
travers le système telles que des compteurs au niveau des codes de réponse, des user-agents, des
méthodes HTTP, des pays et des adresses IP.
Ainsi, l’administrateur a une visibilité granulaire sur le trafic et à la vue sur :
▪ Temps de latence serveur et client

▪ Temps de chargement des pages
▪ Bande passante des requêtes et des réponses
▪ Codes de réponses
▪ Sessions utilisateurs
▪ Transactions Par Seconde
▪ Méthodes HTTP
▪ URLs
▪ IPs des clients
▪ Geolocalisation
▪ Navigateur
Ce module vous donne aussi la capacité de capturer du trafic pour l’examiner plus finement, et
positionner des alertes afin d’être prévenu à l’avance de comportement spécifiques. Enfin, le module
AVR peut être configuré pour envoyer les statistiques sur un serveur distant de type Syslog. Vous pouvez
alors utiliser un outil de centralisation (Splunk par exemple) afin de corréler toutes les statistiques et les
analyser.

Figure 46 : Module de Reporting Web Embarqué AVR
Le module se configure via des profils de type «Analytics» que l’on peut ensuite utiliser au niveau des
différentes applications. Un profile Analytics est un ensemble de définitions qui détermine les
circonstances sous lesquelles le système recueille, log, alerte et affiche graphiquement les informations
en rapport à une application. Un seul profile Analytics peut être configuré par application. Dans un
profile Analytic, on peut spécifier :
▪ Quelles sont les statistiques à collecter

▪ Où collecter les données (en local et/ou sur un serveur distant syslog)
▪ S’il faut capturer du trafic et lequel
▪ S’il faut envoyer des alertes et sous quelle condition

Figure 47 : Exemple de configuration du module AVR
Figure 48 : Création d’alertes dans un profile Analytic
Les statistiques et rapports peuvent être vus dans l’interface graphique d’administration. Les
informations affichées peuvent être filtrées, par exemple, par application ou URL.
En résumé, AVR aide les administrateurs à :
▪ Suivre et assurer le Capacity Planning

▪ Détecter des dégradations de performances et envoyer des alertes
▪ Avoir des informations de performance pour aider le troubleshooting
▪ Centraliser les informations
Les captures d’écran suivantes montrent quelques exemples de résultats.
Figure 49 : Géolocalisation des clients et nombre total de TPS Figure 50 : Top 10 des URLs et moyenne des TPS associées
associées
Figure 51 : Temps de latence serveur par URLs
3.2. Facilité de Configuration et de Gestion des Applications : iApp

iApp est un framework qui permet de déployer et maintenir en condition opérationnelle des
applications de façon simple. iApp permet de configurer et maintenir le BIG-IP d’un point de vue
applicatif, afin de réduire les temps de configuration et améliorer les configurations d’applications
complexes.
A des fins de compréhension, on peut comparer le mode de comparaison sans iApp et avec iApp. Sans
iApp, l’administrateur doit configurer et maintenir tous les objets de manière indépendante les uns des
autres. A titre d’exemple, pour une application Exchange 2010, cela donnerait :

Figure 52 : Gestion de la configuration sans IApp
Avec l’aide d’iApp, la configuration devient orientée application et cela donne :
Figure 53 : Gestion de la configuration avec IApp
Ainsi, il n’est plus nécessaire de se souvenir qu’un objet de la configuration est utilisé pour plusieurs
services. Toute modification se fait à un niveau applicatif et les éléments qui doivent être modifiés sont
modifiés sans impact sur d’autres services.
iApp est composé de deux composants : Les Templates et les Applications Services.

3.2.1. Templates
Un template définit les éléments nécessaires à la construction de la configuration. Il inclut la
présentation de ces éléments à l’utilisateur et l’implémentation des données saisies. Un template peut
être :
▪ Copié
▪ Importé
▪ Exporté
▪ Personnalisé
Un template supporte les modules suivants :
▪ LTM
▪ GTM
▪ APM
▪ WAM
▪ WOM
Il existe plus de 20 templates fournis dans la première version 11 de BIG-IP. Des templates sont
disponibles au fur et à mesure sur le portail DevCentral. Ces templates permettent de mettre à jour la
liste de templates sans avoir à faire une mise à jour de firmware.
A chaque nouveau déploiement d’application, l’administrateur pourra utiliser un template afin de

faciliter, accélérer et sécuriser la configuration. Tous les objets seront créés automatiquement et seront
rassemblés au sein d’un même containeur (cf les dossiers dans la partie synchronisation de
configuration).
Une fois un template utilisé, un Application Service est créé. Liste des Templates disponibles dans la
version 13.1 :
▪ F5.bea_weblogic
▪ f5.cifs
▪ f5.diameter
▪ f5.dns
▪ f5.ftp
▪ f5.http
▪ f5.ip_forwarding
▪ f5.ldap
▪ f5.microsoft_sharepoint_2010
▪ f5.npath
▪ f5.oracle_as_10g
▪ f5.oracle_ebs
▪ f5.peoplesoft_9
▪ f5.radius

▪ f5.replication
▪ f5.sap_enterprise_portal
▪ f5.sap_erp
D’autres templates pour d’autres versions ou des versions plus récentes (Sharepoint 2016, Outlook
2016, ..) sont disponibles ici : https://devcentral.f5.com/codeshare/topic/iapps
Un template est composé de trois parties qui représentent respectivement la présentation,

l’implémentation et l’aide en ligne. La capture d’écran suivante montre un template avec ses trois
parties customisables via des langages particuliers.
3.2.2. Application Services

Un Application Service est une application (ensemble d’objets) créée par l’intermédiaire d’un template.
Dans un Application Service, on peut :
▪ Voir les propriétés de l’application

▪ Voir les propriétés des objets qui construisent l’application
▪ Modifier à la volée la configuration d’une application
▪ Changement de la configuration initiale
▪ Voir les composants avec une vue hiérarchique
▪ Voir les statistiques AVR associées à l’application
Enfin, toute application déployée via iApp peut être protégée contre les modifications accidentelles : les
modifications devront être faites via l’application service et ne pourront pas être faites directement sur
les objets.

Figure 55 : Objets composant une application déployée via iApp
Figure 54 : Fenêtre de reconfiguration d’une application déployée

via iApp
3.3. Log des Requêtes et Réponses à haut débit (High Speed Logging)
Il est possible de configurer le BIG-IP pour loguer, en temps réel, toutes les requêtes et/ou réponses qui
traversent l’équipement. Cela se fait via la configuration d’un profile appelé Request Logging (malgré
son nom, ce type de profile permet bien de loguer les réponses si besoin). Comme tous les profiles, vous
pouvez créer autant de profile Request Logging que nécessaire (chacun avec ses propres propriétés) ;
puis utiliser ces profiles au niveau des différentes applications déployées. Ainsi, le format de logs, les
serveurs de logs et le type de données à loguer (requêtes et/ou réponses) peuvent être différents selon
les applications et les flux.

Figure 56: High Speed Logging
Le principe de base est d’envoyer des logs à partir des instances TMM vers plusieurs serveurs de log. Le
fait d’utiliser plusieurs serveurs de logs et de ne pas utiliser le disque local permet de maintenir un haut
niveau de requêtes par seconde et de pouvoir loguer une grande quantité de données (Jusqu’à 200,000
messages HSL par seconde).
Il est possible d’utiliser ces profils de log, aussi bien pour des applications HTTP, que pour des
applications TCP ou UDP. Quel que soit le cas, les requêtes sont loguées lorsqu’elles sortent du BIG-IP
pour aller vers les serveurs ; et les réponses sont loguées lorsqu’elles sortent du BIG-IP pour aller vers
les clients.
La configuration peut se faire entièrement via l’interface graphique comme le montre la capture d’écran
suivante.

Figure 57 : Ecran de configuration d’un profile Request Logging
Deux sections principales composent le profile : Request Logging et Response Logging. Chacune de ces
sections supporte les mêmes fonctions et peuvent activées ou désactivées (pour loguer les réponses
et/ou les réponses).
Les possibilités sont les suivantes :
▪ Définir quelles données doivent être loguées via des template

▪ Définir le pool de serveurs de log à utiliser et quel protocole utiliser (TCP ou UDP)
▪ Répondre au client en cas d’impossibilité de logguer (« Respond on Error »). En effet, dans
certains cas, il peut être préférable de couper le service lorsque l’on ne peut plus logguer
(problématiques légales et d’audit par exemple).
▪ Utiliser un pool de serveurs pour loguer les erreurs au cas où le serveur de log choisi dans le
pool de base n’est pas joignable.

3.4. Administration et supervision
BIG-IP LTM offre une large palette de méthodes d’administration :
▪ Interface de commandes en ligne sécurisée

▪ Interface graphique sécurisée
▪ SNMP
▪ I-Control
▪ Partitions d’administration
▪ BIG-IQ
3.4.1. Interface de commande en ligne

Le BIG-IP fournit en standard la commande en ligne TMSH, disponible sous forme de commandes ou via
un Shell dédié, qui permet d’accéder à l’ensemble des fonctions de configuration, d’administration, de
statistiques et de monitoring du BIG-IP.
L’interface de commande en ligne est accessible par le port console ainsi qu’en SSH (shell sécurisé).
Chaque accès SSH est authentifié par login/mot de passe. Cette authentification peut être
éventuellement déléguée à un serveur LDAP.
Les accès SSH peuvent être restreints en limitant le nombre de stations pouvant se connecter par
l’intermédiaire d’une access list. Dans une configuration où le BIG-IP est mutualisé sur plusieurs sous-
réseaux il convient de limiter l’accès soit au VLAN d’administration s’il en existe un soit à une liste de
machines sélectionnées.
3.4.2. Interface graphique sécurisée :

BIG-IP intègre une interface utilisateur graphique Web à la fois intuitive, conviviale et sécurisée. Les
tâches de configuration courantes sont regroupées de manière logique pour simplifier les opérations de
configuration et d’administration tout en réduisant le coût de la mise en œuvre et la maintenance
permanente de l’infrastructure. Cette interface est accessible uniquement en HTTPS en standard.

Figure 58 : Interface graphique Web
Elle est très ergonomique et elle permet d’effectuer toutes les fonctions de configuration,
d’administration et de monitoring. L’accès à l’interface graphique est spécifié par VLAN. Dans le cas où
le BIG-IP LTM est mutualisé sur plusieurs VLAN, il convient soit d’interdire l’accès à l’interface graphique
à partir de tout VLAN sauf le VLAN d’administration, soit de lister les machines autorisées à y accéder.
De plus, pour chaque compte d’administration créé, il est nécessaire de spécifier les droits d’accès de
cet utilisateur parmi :
▪ Read/write : accès complet en lecture/écriture

▪ Partial Read/Write : accès lecture/ modification de la disponibilité des serveurs
▪ Read only : accès en lecture uniquement
Il est également possible de procéder à l’authentification des utilisateurs via des serveurs externes :
▪ Radius
▪ Tacacs
▪ LDAP
▪ MS Active Directory

L’interface Web permet de sauvegarder plusieurs versions de configuration. La limite est liée à l’espace
en NVRAM (flash) ou sur le disque suivant la partition système utilisée (parmi 3 disponibles). Ces
configurations peuvent être restaurées à tout moment.
3.4.3. Supervision SNMP

Il est possible d’administrer le BIG-IP LTM à l’aide du protocole SNMP(V1, V2c, V3). L’agent SNMP du
BIG-IP LTM peut être interrogé par votre solution de management du réseau (Network Management
Station). BIG-IP LTM peut être configuré afin de générer des alertes SNMP Trap vers le NMS.
Les informations collectées par l’agent SNMP sont sécurisées par le nom de communauté, ainsi qu’un
contrôle d’accès des stations autorisées à manager le BIG-IP LTM en SNMP.
Les MIBS sont disponibles à partir de l’interface web :
▪ LOAD-BAL-SYSTEM-MIB.txt: load balancing, NAT, et SNAT informations,

▪ UCD-SNMP-MIB.txt: RFC1213 – informations et metriques sur la CPU, RAM Disks, ...
▪ Etherlike-MIB.txt: Statistiques liées à l’interface Ethernet. RFC2665.
▪ If-MIB.txt: Version étendue de la ifTable incluant les compteurs 64 bits.
▪ RMON-MIB.txt: Statistiques historiques et temps réels de l’interface Ethernet. Elle permet aussi
de configurer des seuils d’alerte et de traps. RFC 2819.
▪ rfc1525.mib: Description des objets pour le management MAC bridges based du standard IEEE
802.1D-1990. RFC 1463 et RFC 1525
3.4.4. iControlREST
L’APl iControlREST est la couche logicielle, développée par F5 Networks, commune à l’ensemble des
produits de la gamme F5 leur permettant de communiquer avec des outils tiers. Basée sur des
standards ouverts (REST/JSON), cette couche de communication est accessible gratuitement.
Cette API peut être utilisée pour automatiser des déploiements de configuration, automatiser les tâches
et récupérer des statistiques.
Une description complète de l’API est disponible ici :

https://devcentral.f5.com/wiki/iControlREST.HomePage.ashx
3.4.5. Outils de diagnostique

Au-delà du diagnostic visuel, F5 BIG-IP LTM offre des options avancées de debugging et de prise de
traces tels que :
▪ Liste l’état des interfaces physiques

▪ Liste les connexions actives

▪ « tcpdump » pour capture de traffic
▪ « ssldump » pour capture de traffic SSL
▪ « curl », « telnet », « netcat », « dig », etc. tests de service Web, TCP ou UDP
Tous ces outils sont disponibles en mode CLI (CLI ou Web pour tcpdump).
Un mécanisme de réplication de trafic (port mirroring) est disponible pour les interfaces. Les
fonctionnalités suivantes sont supportées :
▪ recopie simultanée des deux sens du trafic (Tx et Rx),

▪ recopie du trafic par VLAN.
▪ Recopie du trafic pour un service donné (clone pool). Cette technique permet par exemple de
dupliquer les flux reçus par un service réparti vers plusieurs serveurs de messagerie ou FTP, vers
une solution d’analyse d’attaques type IDS.
3.4.6. Gestion des fichiers configurations

Afin de disposer d’une souplesse maximale dans la configuration des équipements réseaux, les fichiers
de configuration sont au format texte, exportables, modifiables et importables dans ce format à partir
de l’équipement. Les équipements disposent de plusieurs niveaux de configuration (active, sauvegardée,
backup) avec la possibilité de stocker trois versions de configuration et d’OS dans la mémoire. Ces
fichiers sont être chiffrables dans leur ensemble ou, au moins pour les parties sensibles telles que les
mots de passe.
Le protocole NTP, de préférence en mode sécurisé (authentification MD5), est supporté (pour le réglage
de la date et de l’heure). Le passage à l’heure d’hiver et à l’heure d’été est automatique.
Un mécanisme de retour à la configuration d’usine existe. Il s’agit de se connecter en mode terminal sur
le boitier (connexion série), de s’authentifier avec un compte ayant les droits d’administration en mode
cli, de passer le boitier en mode single user (init 1), puis d’exécuter la commande « Sys-reset ».
La solution dispose d’une solution permettant de remettre à zéro les mots de passe « administrateur ».
Permettant de mettre en œuvre plusieurs comptes utilisateurs, F5 recommande d’utiliser une gestion
des accès par utilisateur.
Enfin, les équipements BIG-IP LTM permettent la sauvegarde des configurations par connexion depuis le
boitier vers un serveur TFTP, FTP, SFTP ou SCP, ou depuis un serveur vers le boitier en SCP et HTTPS.
3.4.7. Résolution d’incidents

Pour permettre une résolution rapide et efficace des incidents, les équipements F5 BIG-IP LTM offrent
des moyens de diagnostic et d’aide à la résolution d’incidents. Le diagnostic, effectué localement ou à
distance, permet d’identifier facilement la ressource en défaut ainsi que son état.
Visuellement, les différents états sont distingués par un voyant lumineux pour chaque interface. Le
schéma ci-dessous représente les interfaces physiques de type Gigabit Cuivre et Gigabit SFP.

1000 █ 1000 █ 1000 █ 1000 █
L █ L █ L █ L █
1000 █ 1000 █ 1000 █ 1000 █
Le voyant Gigabit Cuivre différencie les états suivants :
▪ Inactif : le voyant est éteint (noir, sur le schéma)

▪ en activité : le voyant est allumé en jaune suivant la vitesse détectée sur le port (10, 100 ou
1000)
▪ trafic : lorsque du trafic est détecté, le voyant carré clignote en orange
Le voyant Gigabit SFP différencie les états suivants :
▪ Inactif : le voyant est éteint (noir, sur le schéma)

▪ en activité : le voyant est allumé en jaune avec la lettre « L »
▪ trafic : lorsque du trafic est détecté, le voyant carré clignote en orange
3.4.8. Historisation des événements

Les équipements F5 proposent une historisation (logging) des événements. Cette historisation peut se
faire localement ou vers un ou plusieurs serveurs Syslog. Plusieurs niveaux de granularité sont indiqués
en fonction de la gravité des événements (warning, notification, critical, information, Debug).
Basé sur le produit référence du marché Syslog-NG, l’ensemble de l’historisation des événements F5
peut être personnalisée pour refléter au mieux les besoins.
Nativement les événements sont classés suivant 4 catégories :
▪ System : événements lié au hardwore ou a l’operating system

▪ Packet filter : événements liés au Firewall
▪ Local traffic : événements liés à la gestion du trafic load balancé
▪ Audit : événements liés à l’administration du boitier
L’accès à ces informations peut se faire via l’interface Web ou via une consultation des fichiers
directement stockés sur les BIG-IP LTM. Un mécanisme de rotation et de compression automatisé des
fichiers d’historisation des événements est paramétré par défaut à un fichier par jour. Il est possible de
modifier ce mécanisme pour y ajouter l’exportation de ces fichiers.

3.4.9. Historisation des configurations
Les fonctions de backup/restauration sont intégrées à l’équipement et accessible à la fois en ligne de
commande et via l’interface graphique locale au boitier BIG-IP LTM.
Il est possible de créer plusieurs packages de configuration, incluant la totalité des éléments nécessaires
à la restauration de la configuration sur le même boitier ou un boitier de spare.
Comme les éléments de cette configuration peuvent intégrer des certificats SSL (clefs privées et
publiques), la sauvegarde peut intégrer ces certificats ou on (choix de l’administrateur), et cela de façon
chiffré, via une clef symétrique (type passphrase).
Figure 59 : Gestion des backups de configuration
L’archive ainsi réalisée intègre la référence de la version logicielle correspondant.
Il est également possible de créer des configurations qui incluent la totalité de la configuration et du
système d’exploitation : « les SNAPSHOT ». Cela permet par exemple de dupliquer complètement une
configuration existante vers un autre boitier, sans toutefois devoir installer sur le boitier cible, la même
version d’OS, puisque l’OS est intégré dans ce backup.
De plus, chaque boitier bénéficie en standard de 3 partitions, permettant de basculer d’une version d’OS
à une autre. L’on dispose donc en standard sur les boitiers de 3 images d’OS, ainsi que 3 configurations
différentes.
Lors d’un upgrade, il est possible de réaliser l’upgrade d’une partition vers une autre, cela afin de
rapidement valider la nouvelle version, sans toutefois devoir faire un downgrade en cas de problème lié
à cette mise à jour.

4. Points forts de la solution F5
▪ Performances de la solution / Architecture Interne Unique. La conception matérielle et logicielle
des plateformes F5 est optimisée et dédiée aux fonctions ADC leur permettant des
performances de premiers rangs :
▪ ASICs de commutation et de traitement niveau 4 (sur les plateformes supportées)
▪ Carte accélératrice SSL
▪ Carte de Compression (sur les plateformes supportées)
▪ OS TMOS performant, temps réel et modulaire
▪ Fonctionnement Full Proxy (2 connexions par client : 1 entre le client et le load balancer,
1 entre le load balancer et le serveur)
▪ CPU puissants de dernière génération (utile pour les traitements applicatifs intelligents)
▪ Mémoire importante (table de connexions et de persistance)
▪ Clustered Multiprocessing: fonction de l’OS TMOS qui grâce à un matériel (FPGA)

permet d’utiliser l’ensemble de la puissance CPU de la machine pour traiter le trafic.
▪ Evolutivité de la solution
▪ Gamme complète de 5 Gbps à plus de 80 Gbps de capacité
▪ Plateformes On Demand : VIPRION
▪ Modules complémentaires de disponibilité, de sécurité, de gestion des accès et

d’optimisation des applications sur la même plateforme (Link Controller, DNS, ASM,
AAM, APM etc.)
▪ Management
▪ Interface graphique ergonomique
▪ Interface en Commande en ligne complète
▪ Outils de Troubleshooting utiles dont Tcpdump, ssldump, telnet, ssh, etc.
▪ Interface d’administration dédiée permettant de garder le contrôle à distance sur

l’équipement même en cas de reboot
▪ Gestion de plusieurs environnements de configuration (partitions)
▪ Outil d’administration Centralisée (BIG-IQ)

▪ API iControl permettant d’automatiser ou d’intégrer le pilotage de tâches
d’administration depuis une application tierce.
▪ Véritable Load Balancer Applicatif
▪ Connaissance Native de protocoles tels que http, SIP, FTP, RTSP (pas uniquement http)
▪ Gestion de trafic applicatif intelligente (iRules, persistance)
▪ Nombreux tests de vie applicatifs intégrés et possibilité d’intégration de nouveaux tests

de vie
▪ API iControl permettant d’intégrer les équipements F5 dans l’écosystème applicatif
▪ F5 édite de nombreux guides de solutions permettant de faciliter l’installation des

équipements F5 dans le cadre d’architecture applicative telles que Microsoft Exchange,
Oracle Business Suite, SAP, etc.
▪ Pérennité de la société
▪ F5 est une société focalisé dans le domaine de l’ADC et un leader de ce marché (vu
comme leader par les différents analystes de ce marché, part de marché et croissance
annuelle importante).
▪ F5 dispose d’une forte stabilité financière (cash important, pas de dettes)
▪ De nombreux éditeurs importants ont tissé des partenariats forts avec la société F5
(Oracle, Microsoft, IBM, BEA, VMWare,etc.).

5. Mise à jour du document et releases
5.1. Version 11.0
▪ Device Service Clustering : nouveau mécanisme de gestion des clusters
▪ iApps : template de configuration personnalisable
▪ Analytics : module de reporting embarqué
▪ IPv4-to-IPv6 Gateway
▪ TCP Request Queuing in Pools : mise en attente des transactions lorsque surcharge serveur
▪ Certificate Administrator Role
▪ Per Module Statistics/Per Virtual Server Statistics
▪ Out of Band TCP Connections : irule pour générer du trafic vers l’extérieur
▪ Read and Write Access to TCP Options : irule pour altérer les champs TCP options
▪ TLS 1.2 Support
▪ Request Logging Profile : nouveau profile de génération de log dans la GUI
▪ Proxy SSL Support
5.2. Version 11.1

▪ DNS iRules
▪ Link Layer Discovery Protocol
▪ SSL SAN Certificates
▪ Dynamic Host Configuration Protocol Relay
▪ Jumbo Frame Support
▪ NTLM/NTLMv2 Authentication Support for HTTP/HTTPS Monitors
5.3. Version 11.2

▪ Google Chrome support
▪ SPDY protocol
▪ TLS 1.1 en hardware,
▪ Protection contre la vulnérabilité SSL 3.0/TLS 1.0 BEAST Exploit
▪ DNS cache
▪ MIBs SNMP personalables
▪ DHCP Relay renewal forwarding
▪ Sflow
▪ Amélioration LDAP pour le management
▪ Support SCTP
▪ Certification BIG-IP IPsec
▪ Support du module Advanced routing dans plusieurs route domains
▪ SIP OneConnect
▪ Base de réputation IP avec souscription

5.4. Version 11.5
▪ Nouvelle gamme matérielle et virtuelle
5.5. Version 12.0

▪ Description HA Group et load-aware failover
▪ Suppression de paragraphes redondants sur les Route Domain
▪ Suppression du contenu « Appliances » pour un boiler plateformes séparé
▪ Ajout de la description du Bandwith Control
▪ Ajout de limites SSL et bande passante par Guest vCMP
▪ Mirroring SSL
▪ HTTP/2
▪ LTM policy
▪ Mise à jour des points forts
5.6. Version 13.1

▪ Description nouvelles méthodes de failover
▪ Mise à jour des captures d’écran

Boiler BIGIP LTM V13.1 FR

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Boiler BIGIP LTM V13.1 FR

Transféré par

Droits d'auteur :

Formats disponibles

En réunissant une structure de

commutation haute performance, un

3 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Les performances élevées qu’apportent les plates-formes BIG-IP permettent de consolider

25M 200M 1Gbps 3Gbps 5Gbps 10Gbps

VIPRION 2200 VIPRION 2400 VIPRION 4480 VIPRION 4800

Figure 1 : gamme de plateformes F5

4 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

▪ Une partie Switching

1.2. Cas d’usages du BIG-IP LTM

▪ Répartition de charge sur les serveurs d’application : le LTM surveille en permanence la

5 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Les coûts associés au développement de composants permettant de travailler principalement en mode

▪ Constitué de modules logiciels granulaires permettant d’assembler les fonctions nécessaires du

6 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Programmability iRules® , iApps® , iCall, iStats and iControlREST

Appliances Chassis Software Management

Figure 2 : ensemble des modules fonctionnels F5 networks

Les modules sont organisés de la manière suivante :

▪ Protection contre la fraude Web : Websafe/Mobilesafe

7 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

8 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

9 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

▪ RIPv2 (RFCs 1058 et 1723),

10 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Figure 4 : création d'une règle de filtrage IP

11 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

▪ Attaque par IP Spoofing (remontée jusqu’à la route source)

▪ Résistance au SYN non reconnu sans buffers ACK (inondations SYN)

▪ Attaques par “ teardrop ” et “ Land ”

▪ Auto-protection et protection des serveurs contre les attaques ICMP

▪ Non-exécution de SMTPd, FTPd, Telnetd et d’aucun autre démon attaquable

2.1.4.3 Base de réputation IP (IP Intelligence)

Les catégories suivantes sont disponibles :

12 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

2.2.1. Description du Device Service Clustering (DSC)

Figure 5 : modèles de groupe de synchronisations

▪ Synchroniser une partie ou toute sa configuration vers plusieurs Big-IPs distants.

13 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

14 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

La solution de Haute Disponibilité du BIG-IP fournit les fonctionnalités suivantes :

▪ Synchronisation des configurations : Cette fonctionnalité permet de configurer un BIG-IP LTM et

15 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Figure 7 : Notion de Trust Domain

Figure 8 : gestion des traffic groups

17 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

▪ L’équipement doit être mis offline pour des questions de maintenance

2.2.3. Les SYNC-FAILOVER DEVICE GROUPS

18 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Figure 10 : Exemple de Sync Failover Device Group

2.2.3.2 EXEMPLE D’UNE ARCHITECTURE DE TYPE SYNC-FAILOVER

19 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

2.2.4. Les SYNC-ONLY DEVICE GROUPS

2.2.4.2 Synchronisation automatique

20 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Figure 12 : Exemple de Synch only Device Group

2.2.5. Détection de Failover

21 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

2.2.6. Serial et Network Failover

22 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Figure 13 : Exemple d'architecture en actif passif

23 Solution BIGIP LOCAL TRAFFIC MANAGER V13.1 | F5 NETWORKS

Figure 14 : Exemple d'architecture en actif actif

Deux Traffic-Groups sont créés et contiennent leurs propres objets.