Comprendre F5 · LTM

F5 LTM : DNS, FTP, SIP et protocoles à plusieurs flux

Pourquoi un seul port ne décrit pas toujours l’application : transport DNS, canaux FTP, signalisation SIP et profils spécialisés.

Thomas SAUTIER · Publié le · Révisions de certification

Références et objectifs de certification (2)
  • Certification : F5 301A · Référence consultée le · Objectifs abordés : F5 301A 1.02, F5 301A 1.04, F5 301A 1.07.
  • Certification : F5 301B · Référence consultée le · Objectifs abordés : F5 301B 2.10, F5 301B 2.13.

Ce guide concerne BIG-IP sur TMOS. Vérifiez les noms et les options dans la documentation de votre version.

Comprendre en imageUne application peut ouvrir plusieurs types de flux
Une application peut ouvrir plusieurs types de flux DNS doit être pensé en UDP et TCP. FTP sépare le contrôle et les données. SIP assure la signalisation tandis que les médias peuvent suivre d’autres flux. Le port de contrôle ne décrit donc pas à lui seul le service complet. transport flux distinct flux distinct Objets, conditions et comparaisons du guide DNS Requêtes et réponses FTP Session de contrôle SIP Signalisation UDP et TCP Prévoir les deux Données FTP Active ou passive Média RTP selon le déploiement Lister tous les échanges del’application Un besoin « publier le port du service » peutcacher plusieurs transports ou connexions.Relevez les flux de contrôle, les flux de données,les connexions initiées par le serveur et lesinformations d’adresse contenues dans leprotocole. DNS peut utiliser UDP et TCP Une publication DNS uniquement en UDP nedécrit pas l’accès en TCP au même service.Vérifiez que les VS et le transport permettent lesdeux échanges attendus. Si vous activez unesélection par datagramme, assurez-vous que lebesoin tolère cette indépendance.

DNS doit être pensé en UDP et TCP. FTP sépare le contrôle et les données. SIP assure la signalisation tandis que les médias peuvent suivre d’autres flux. Le port de contrôle ne décrit donc pas à lui seul le service complet.

Télécharger le schéma en SVG · version claire

Lister tous les échanges de l’application

Un besoin « publier le port du service » peut cacher plusieurs transports ou connexions. Relevez les flux de contrôle, les flux de données, les connexions initiées par le serveur et les informations d’adresse contenues dans le protocole.

Le profil TCP ou UDP traite le transport. Un profil de service ajoute une connaissance applicative. La présence de l’un ne fournit pas automatiquement toutes les fonctions de l’autre.

Sources : F5, Protocol Profiles ; F5, Services Profiles.

DNS peut utiliser UDP et TCP

Une publication DNS uniquement en UDP ne décrit pas l’accès en TCP au même service. Vérifiez que les VS et le transport permettent les deux échanges attendus. Si vous activez une sélection par datagramme, assurez-vous que le besoin tolère cette indépendance.

Équilibrer des serveurs DNS avec LTM n’est pas la même chose que déployer BIG-IP DNS pour une décision globale. Anycast, iQuery et la découverte de VS appartiennent à un périmètre DNS distinct de ce guide LTM.

Sources : F5, ltm profile udp ; F5, ltm virtual.

FTP : connexion de contrôle et connexion de données

FTP sépare contrôle et données. Les modes actif et passif diffèrent dans l’initiation du flux de données. Une connexion de contrôle réussie n’exclut donc pas une panne de transfert due au routage, à la traduction ou au filtrage d’un deuxième flux.

Le profil FTP et ses réglages doivent correspondre au montage. SFTP est un protocole sur SSH : il ne doit pas être traité comme du FTP passif simplement parce qu’il transfère des fichiers. Relevez précisément le protocole utilisé.

Sources : F5, ltm profile ftp.

SIP : ne pas confondre signalisation et média

Un service SIP peut nécessiter un traitement de signalisation, une persistance cohérente et des flux média distincts. Vérifiez le transport, les adresses annoncées, les moniteurs et la topologie de traduction.

Une application qui fonctionne avec un seul membre et échoue à plusieurs peut dépendre d’un état non partagé. Cela invite à examiner l’affinité et le dialogue, pas à conclure automatiquement que le deuxième serveur est défectueux.

Sources : F5, ltm profile sip.

DHCP relay et ICAP répondent à des rôles spécifiques

Un relais DHCP permet un traitement de relais entre réseaux selon la configuration prévue. ICAP peut intervenir dans une chaîne d’adaptation de contenu. Ces usages exigent des objets et profils propres à leur traitement ; un simple pool TCP ne décrit pas tout le service.

Le guide des types de VS présente les VS spécialisés, notamment DHCP Relay et Internal. Utilisez-le pour vérifier le rôle de l’objet avant de traiter un problème de routage.

Sources : F5, ltm virtual ; F5, Services Profiles.

Confronter configuration et échanges

Les commandes ci-dessous montrent les profils de service et le VS. Remplacez le nom par votre objet ; les profils FTP et SIP ne sont à examiner que pour les services correspondants. Capturez ensuite les flux de contrôle et de données séparément.

Inventorier les profils de serviceShell · commandes de lecture
tmsh list ltm virtual /Common/vs_service all-properties
tmsh list ltm profile ftp all-properties
tmsh list ltm profile sip all-properties

Sources : F5, ltm profile ftp ; F5, ltm profile sip.

Sources et portée

Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.

Retrouver le parcours de lecture F5 LTM

Continuer la série F5

Explorer tous les guides du parcours F5 LTM

Découvrir l’expertise F5 de Samhan

Échange

Besoin d’éclaircir votre architecture F5 ?

Échangeons sur vos flux, vos contraintes de disponibilité et vos services applicatifs.