Domini di routing F5 e VRF MPLS: mappare la consegna del tenant

Due tenant eseguono la stessa applicazione su 10.50.0.10. Il provider li tiene separati in VPN MPLS distinte, e il BIG-IP mantiene il loro traffico locale in domini di routing distinti. Questa disposizione funziona fino alla consegna, dove un suffisso mancante o una route target copiata mette silenziosamente il pacchetto di un tenant nel contesto dell'altro. Questa guida collega i due modelli e termina con un test per tenant.

Foglio di lavoro: una riga per tenant

Compilatelo prima di cambiare qualsiasi cosa. Ogni passo successivo fa riferimento a una cella del foglio, e una cella vuota è una decisione che nessuno ha ancora preso.

Passo 1: fissare ogni oggetto al suo dominio di routing

La documentazione sui domini di routing di F5 descrive contesti di traffico isolati, indirizzi duplicati e la notazione address%ID per gli oggetti di configurazione. Un indirizzo scritto come 10.50.0.10%2 indica il contesto locale del dominio di routing, e quel suffisso non è un'etichetta MPLS trasportata nel pacchetto IP del cliente.

Una VLAN o un tunnel supportato appartiene a un solo dominio di routing nel modello documentato, quindi l'interfaccia e l'indirizzo devono concordare. Esaminate anche il dominio di routing predefinito della partizione amministrativa, perché un suffisso omesso non significa assenza di contesto; significa il contesto che la partizione usa per impostazione predefinita. Quell'unico valore predefinito spiega la maggior parte degli incidenti in cui un nuovo oggetto rispondeva silenziosamente al tenant sbagliato. Verificatelo prima di aggiungere un indirizzo proprio.

tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vs

Passo 2: usare il VRF e le route target del provider

Al bordo MPLS, il tenant è identificato dal VRF del provider e dal servizio di routing concordato per il cliente. Le route target controllano quali rotte il provider importa ed esporta tra VRF, e scegliere un numero di dominio di routing BIG-IP dall'aspetto simile non crea nulla di quella relazione.

I due identificatori vivono in sistemi diversi e significano cose diverse. Un ID di dominio di routing è un contesto locale sull'appliance. Una route target è un attributo di policy lato provider che decide la distribuzione delle rotte, e un route distinguisher è ancora una terza cosa, usata per mantenere separati prefissi altrimenti identici.

Passo 3: decidere se i contesti possono condividere la raggiungibilità

Esaminate deliberatamente le impostazioni di ricerca nel dominio padre e di isolamento rigoroso, perché cambiano ciò che un contesto può raggiungere. La guida F5 consente l'inoltro controllato attraverso queste relazioni, ed è proprio per questo che un dominio di routing non va trattato da solo come una politica di sicurezza completa del tenant.

Se entrambi i tenant hanno bisogno di un servizio condiviso, specificate il percorso e i permessi approvati invece di puntare sbadatamente un tenant al contesto di routing dell'altro. Conservate l'identità dell'applicazione e qualsiasi traduzione di origine intenzionale insieme alla destinazione di rete, altrimenti il servizio condiviso vedrà un tenant come l'altro.

Una consegna routed ordinaria collega il BIG-IP a un router di bordo del provider senza rendere il BIG-IP un PE MPLS. Se è davvero necessaria un'integrazione diretta MPLS o della famiglia di rotte VPN, ottenete un supporto esplicito per la piattaforma e la release esatte, perché l'isolamento locale del dominio di routing non stabilisce quella capacità.

Passo 4: verificare un tenant alla volta

Provate il tenant A da un endpoint nel contesto di A all'indirizzo dell'applicazione di A, poi ripetete per B. Usate la forma %ID nella diagnostica per dimostrare quale contesto ha risposto, e confermate che una richiesta dal contesto sbagliato fallisce invece di atterrare in un punto plausibile.

Controllate il lato provider nella stessa passata: il prefisso è presente nel VRF corretto, le route target corrispondono al foglio di lavoro, e il percorso di ritorno usa l'attachment previsto. Un ping che funziona dall'appliance stessa dimostra il contesto dell'appliance, non quello del tenant.

Registrate la mappatura finale nel foglio di lavoro, incluso il dominio di routing predefinito di ogni partizione e qualsiasi relazione di dominio padre abbiate abilitato. La prossima modifica a questo ambiente la farà qualcuno che legge quella tabella, non qualcuno che legge questo articolo.