Domaines de routage F5 et VRF MPLS : cartographier la remise du locataire
Deux locataires, une adresse, deux domaines de routage. Épinglez chaque objet avec %ID, utilisez le VRF et les cibles de route du fournisseur et vérifiez chaque locataire séparément.
Deux locataires exploitent la même application à l'adresse 10.50.0.10. Le fournisseur les sépare dans des VPN MPLS distincts, et le BIG-IP conserve leur trafic local dans des domaines de routage distincts. Cet arrangement fonctionne jusqu'à la remise, où un suffixe manquant ou une cible de route copiée place discrètement le paquet d'un locataire dans le contexte de l'autre. Ce guide relie les deux modèles et se termine par un test par locataire.
Feuille de travail : une ligne par locataire
Remplissez-la avant de changer quoi que ce soit. Chaque étape ultérieure renvoie à une cellule de la feuille, et une cellule vide est une décision que personne n'a encore prise.
| Tenant | BIG-IP side | Provider side |
|---|---|---|
| A | VLAN or tunnel, route domain, self address, virtual server | VRF, attachment, route targets for import and export |
| B | Separate VLAN or tunnel, separate route domain, separate self address | Separate VRF, separate route targets |
Étape 1 : épingler chaque objet à son domaine de routage
La documentation des domaines de routage de F5 décrit des contextes de trafic isolés, des adresses en double et la notation address%ID pour les objets de configuration. Une adresse écrite sous la forme 10.50.0.10%2 nomme le contexte local du domaine de routage, et ce suffixe n'est pas une étiquette MPLS transportée dans le paquet IP du client.
Un VLAN ou un tunnel pris en charge appartient à un seul domaine de routage dans le modèle documenté, donc l'interface et l'adresse doivent concorder. Inspectez aussi le domaine de routage par défaut de la partition administrative, car un suffixe omis ne signifie pas absence de contexte ; il signifie le contexte que la partition utilise par défaut. Ce seul paramètre explique la plupart des incidents où un nouvel objet répondait discrètement au mauvais locataire. Vérifiez-le avant d'ajouter une adresse propre.
tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vsÉtape 2 : utiliser le VRF et les cibles de route du fournisseur
À la bordure MPLS, le locataire est identifié par le VRF du fournisseur et le service de routage client convenu. Les cibles de route contrôlent quelles routes le fournisseur importe et exporte entre VRF, et choisir un numéro de domaine de routage BIG-IP d'apparence similaire ne crée rien de cette relation.
Les deux identifiants vivent dans des systèmes différents et signifient des choses différentes. Un ID de domaine de routage est un contexte local sur l'appliance. Une cible de route est un attribut de politique côté fournisseur qui décide de la distribution des routes, et un distinguishateur de route est encore une troisième chose, utilisée pour garder distincts des préfixes autrement identiques.
Étape 3 : décider si les contextes peuvent partager l'accessibilité
Examinez délibérément les réglages de recherche dans le domaine parent et d'isolation stricte, car ils changent ce qu'un contexte peut atteindre. Le guide F5 autorise un transfert contrôlé via ces relations, et c'est précisément pourquoi un domaine de routage ne doit pas être traité seul comme une politique de sécurité complète du locataire.
Si les deux locataires ont besoin d'un service partagé, précisez le chemin et les autorisations approuvés au lieu de pointer négligemment un locataire vers le contexte de routage de l'autre. Préservez l'identité de l'application et toute traduction de source intentionnelle avec la destination réseau, sinon le service partagé verra un locataire comme l'autre.
Une remise routée ordinaire connecte le BIG-IP à un routeur de bordure du fournisseur sans faire du BIG-IP un PE MPLS. Si une intégration directe MPLS ou de la famille de routes VPN est réellement nécessaire, obtenez un support explicite pour la plateforme et la version exactes, car l'isolation locale du domaine de routage n'établit pas cette capacité.
Étape 4 : vérifier un locataire à la fois
Testez le locataire A depuis un point de terminaison du contexte de A vers l'adresse d'application de A, puis répétez pour B. Utilisez la forme %ID dans les diagnostics pour prouver quel contexte a répondu, et confirmez qu'une requête issue du mauvais contexte échoue au lieu d'atterrir quelque part de plausible.
Vérifiez le côté fournisseur dans la même passe : le préfixe est présent dans le bon VRF, les cibles de route correspondent à la feuille de travail, et le chemin de retour utilise l'attachement prévu. Un ping qui fonctionne depuis l'appliance elle-même prouve le contexte de l'appliance, pas celui du locataire.
Consignez le mappage final dans la feuille de travail, y compris le domaine de routage par défaut de chaque partition et toute relation de domaine parent que vous avez activée. La prochaine modification de cet environnement sera faite par quelqu'un qui lit ce tableau, pas par quelqu'un qui lit cet article.