F5-rutedomener og MPLS-VRF-er: kartlegg leietakeroverleveringen

To leietakere kjører den samme applikasjonen på 10.50.0.10. Leverandøren holder dem atskilt i separate MPLS-VPN-er, og BIG-IP holder deres lokale trafikk i separate rutedomener. Denne ordningen fungerer helt frem til overleveringen, der et manglende suffiks eller et kopiert rutemål stille plasserer den ene leietakerens pakke i den andres kontekst. Denne runbooken knytter de to modellene sammen og avslutter med en test per leietaker.

Regneark: én rad per leietaker

Fyll dette ut før du endrer noe. Hvert senere trinn viser til en celle i det, og en tom celle er en beslutning ingen har tatt ennå.

Trinn 1: fest hvert objekt til sitt rutedomene

F5s dokumentasjon om rutedomener beskriver isolerte trafikkontekster, dupliserte adresser og address%ID-notasjonen for konfigurasjonsobjekter. En adresse skrevet som 10.50.0.10%2 navngir den lokale rutedomenekonteksten, og det suffikset er ikke en MPLS-etikett som bæres i kundens IP-pakke.

En VLAN eller en støttet tunnel tilhører ett rutedomene i den dokumenterte modellen, så grensesnittet og adressen må stemme overens. Undersøk også den administrative partisjonens standard rutedomene, fordi et utelatt suffiks ikke betyr ingen kontekst; det betyr den konteksten partisjonen bruker som standard. Den ene standardverdien forklarer de fleste hendelsene der et nytt objekt stille svarte i feil leietaker. Kontroller det før du legger til en egen adresse.

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

Trinn 2: bruk leverandørens VRF og rutemål

Ved MPLS-kanten identifiseres leietakeren av leverandørens VRF og den avtalte kunderutingstjenesten. Rutemål styrer hvilke ruter leverandøren importerer og eksporterer mellom VRF-er, og å velge et lignende BIG-IP-rutedomenenummer skaper ingenting av den relasjonen.

De to identifikatorene lever i forskjellige systemer og betyr forskjellige ting. En rutedomene-ID er en lokal kontekst på apparatet. Et rutemål er en policy-attributt på leverandørsiden som avgjør rutefordelingen, og en routedistinguisher er ennå en tredje ting, brukt for å holde ellers identiske prefikser atskilt.

Trinn 3: avgjør om kontekster kan dele rekkevidde

Gå bevisst gjennom innstillingene for oppslag i overordnet domene og streng isolasjon, fordi de endrer hva en kontekst kan nå. F5-veiledningen tillater kontrollert videresending gjennom disse relasjonene, og nettopp derfor bør et rutedomene ikke behandles alene som en fullstendig sikkerhetspolicy for leietakeren.

Hvis begge leietakerne trenger en delt tjeneste, angi den godkjente veien og tillatelsene i stedet for å peke den ene leietakeren tilfeldig mot den andres rutingkontekst. Bevar applikasjonsidentiteten og enhver bevisst kildeoversettelse sammen med nettverksdestinasjonen, ellers vil den delte tjenesten se den ene leietakeren som den andre.

En vanlig rutet overlevering kobler BIG-IP til en leverandørkantruter uten å gjøre BIG-IP til et MPLS PE. Hvis direkte MPLS- eller VPN-rutefamilieintegrasjon virkelig er nødvendig, skaff eksplisitt støtte for den nøyaktige plattformen og versjonen, fordi lokal rutedomeneisolering ikke etablerer den egenskapen.

Trinn 4: verifiser én leietaker om gangen

Test leietaker A fra et endepunkt i A sin kontekst til A sin applikasjonsadresse, og gjenta deretter for B. Bruk %ID-formen i diagnostikk slik at du kan bevise hvilken kontekst som svarte, og bekreft at en forespørsel fra feil kontekst feiler i stedet for å lande et plausibelt sted.

Kontroller leverandørsiden i samme gjennomgang: prefikset finnes i riktig VRF, rutemålene stemmer med regnearket, og returveien bruker den tiltenkte tilkoblingen. En ping som virker fra selve apparatet beviser apparatets kontekst, ikke leietakerens.

Noter den endelige kartleggingen i regnearket, inkludert standard rutedomene for hver partisjon og enhver overordnet domenerelasjon du aktiverte. Den neste endringen i dette miljøet vil bli gjort av noen som leser den tabellen, ikke av noen som leser denne artikkelen.