Domenii de rutare F5 și VRF MPLS: cartografiați predarea chiriașului
Doi chiriași, o adresă, două domenii de rutare. Fixați fiecare obiect cu %ID, folosiți VRF-ul și țintele de rută ale furnizorului și verificați fiecare chiriaș separat.
Doi chiriași rulează aceeași aplicație la 10.50.0.10. Furnizorul îi ține separați în VPN-uri MPLS distincte, iar BIG-IP le păstrează traficul local în domenii de rutare distincte. Această amenajare funcționează până la predare, unde un sufix lipsă sau o țintă de rută copiată pune în liniște pachetul unui chiriaș în contextul celuilalt. Acest ghid leagă cele două modele și se încheie cu un test pentru fiecare chiriaș.
Foaie de lucru: un rând pe chiriaș
Completați-o înainte de a schimba ceva. Fiecare pas ulterior face referire la o celulă din ea, iar o celulă goală este o decizie pe care încă nimeni nu a luat-o.
| 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 |
Pasul 1: fixați fiecare obiect la domeniul său de rutare
Documentația F5 despre domeniile de rutare descrie contexte de trafic izolate, adrese duplicate și notația address%ID pentru obiectele de configurare. O adresă scrisă ca 10.50.0.10%2 numește contextul local al domeniului de rutare, iar acel sufix nu este o etichetă MPLS transportată în pachetul IP al clientului.
Un VLAN sau un tunel acceptat aparține unui singur domeniu de rutare în modelul documentat, așa că interfața și adresa trebuie să coincidă. Verificați și domeniul de rutare implicit al partiției administrative, pentru că un sufix omis nu înseamnă lipsa unui context; înseamnă contextul pe care partiția îl folosește implicit. Acea singură valoare implicită explică majoritatea incidentelor în care un obiect nou răspundea în liniște chiriașului greșit. Verificați-o înainte de a adăuga o adresă proprie.
tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vsPasul 2: folosiți VRF-ul și țintele de rută ale furnizorului
La marginea MPLS, chiriașul este identificat prin VRF-ul furnizorului și serviciul de rutare convenit pentru client. Țintele de rută controlează ce rute importă și exportă furnizorul între VRF-uri, iar alegerea unui număr de domeniu de rutare BIG-IP asemănător nu creează nimic din acea relație.
Cele două identificatoare trăiesc în sisteme diferite și înseamnă lucruri diferite. Un ID de domeniu de rutare este un context local pe echipament. O țintă de rută este un atribut de politică din partea furnizorului care decide distribuția rutelor, iar un distingător de rută este încă un al treilea lucru, folosit pentru a ține separate prefixe altfel identice.
Pasul 3: decideți dacă contextele pot împărtăși accesibilitatea
Revedeți în mod deliberat setările de căutare în domeniul părinte și de izolare strictă, pentru că schimbă ceea ce poate atinge un context. Ghidul F5 permite redirecționarea controlată prin aceste relații și exact de aceea un domeniu de rutare nu trebuie tratat singur ca o politică completă de securitate a chiriașului.
Dacă ambii chiriași au nevoie de un serviciu partajat, specificați calea și permisiunile aprobate în loc să îndreptați neglijent un chiriaș către contextul de rutare al celuilalt. Păstrați identitatea aplicației și orice traducere intenționată a sursei împreună cu destinația de rețea, altfel serviciul partajat va vedea un chiriaș drept celălalt.
O predare rutată obișnuită conectează BIG-IP la un router de margine al furnizorului fără a face din BIG-IP un PE MPLS. Dacă integrarea directă MPLS sau a familiei de rute VPN este cu adevărat necesară, obțineți suport explicit pentru platforma și versiunea exacte, pentru că izolarea locală a domeniului de rutare nu stabilește acea capacitate.
Pasul 4: verificați un chiriaș pe rând
Testați chiriașul A dintr-un punct final din contextul lui A către adresa de aplicație a lui A, apoi repetați pentru B. Folosiți forma %ID în diagnostice pentru a putea dovedi ce context a răspuns, și confirmați că o cerere din contextul greșit eșuează în loc să ajungă într-un loc plauzibil.
Verificați partea furnizorului în aceeași trecere: prefixul este în VRF-ul corect, țintele de rută corespund foii de lucru, iar calea de întoarcere folosește atașamentul prevăzut. Un ping care funcționează de pe echipamentul însuși dovedește contextul echipamentului, nu pe cel al chiriașului.
Notați maparea finală în foaia de lucru, inclusiv domeniul de rutare implicit al fiecărei partiții și orice relație de domeniu părinte pe care ați activat-o. Următoarea modificare în acest mediu va fi făcută de cineva care citește acel tabel, nu de cineva care citește acest articol.