F5-retdomajnoj kaj MPLS-VRF: mapu la transdonon de la luanto

Du luantoj funkciigas la saman aplikaĵon ĉe 10.50.0.10. La provizanto tenas ilin aparte en apartaj MPLS-VPN, kaj la BIG-IP tenas ilian lokan trafikon en apartaj retdomajnoj. Tiu aranĝo funkcias ĝis la transdono, kie mankanta sufikso aŭ kopiita retocelo silente metas la paketon de unu luanto en la kuntekston de la alia. Ĉi tiu manlibro kunigas la du modelojn kaj finiĝas per testoj por ĉiu luanto.

Laborfolio: unu linio por luanto

Plenigu ĝin antaŭ ol vi ŝanĝos ion ajn. Ĉiu posta paŝo referencas ĉelon en ĝi, kaj malplena ĉelo estas decido, kiun ankoraŭ neniu faris.

Paŝo 1: fiksu ĉiun objekton al ĝia retdomajno

La dokumentaro de F5 pri retdomajnoj priskribas izolitajn trafikajn kuntekstojn, duoblajn adresojn kaj la notacion address%ID por agordaj objektoj. Adreso skribita kiel 10.50.0.10%2 nomas la lokan retdomajnan kuntekston, kaj tiu sufikso ne estas MPLS-etikedo portata en la IP-paketo de la kliento.

VLAN aŭ subtenata tunelo apartenas al unu retdomajno en la dokumentita modelo, do la interfaco kaj la adreso devas kongrui. Kontrolu ankaŭ la defaŭltan retdomajnon de la administra sekcio, ĉar forlasita sufikso ne signifas neniun kuntekston; ĝi signifas tiun kuntekston, kiun la sekcio uzas defaŭlte. Tiu sola defaŭlto klarigas la plej multajn incidentojn, en kiuj nova objekto silente respondis en la malĝusta luanto. Kontrolu ĝin antaŭ ol aldoni propran adreson.

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

Paŝo 2: uzu la VRF kaj retocelojn de la provizanto

Ĉe la MPLS-rando, la luanto estas identigata per la VRF de la provizanto kaj la interkonsentita klienta enkursiga servo. Retoceloj regas, kiujn vojojn la provizanto importas kaj eksportas inter VRF-oj, kaj elekti simile aspektan BIG-IP-retdomajnan numeron kreas nenion el tiu rilato.

La du identigiloj vivas en malsamaj sistemoj kaj signifas malsamajn aferojn. Retdomajna ID estas loka kunteksto sur la aparato. Retocelo estas politika atributo ĉe la provizanta flanko, kiu decidas la distribuadon de vojoj, kaj vojdiskriminanto estas ankoraŭ tria afero, uzata por teni alie identajn prefiksojn aparte.

Paŝo 3: decidu, ĉu kuntekstoj rajtas kunhavigi atingeblon

Revizuu intence la agordojn por serĉado en gepatra domajno kaj strikta izolado, ĉar ili ŝanĝas kion kunteksto povas atingi. La gvidilo de F5 permesas kontrolitan plusendadon tra tiuj rilatoj, kaj ĝuste tial retdomajno ne devus esti traktata sola kiel kompleta sekureca politiko de luanto.

Se ambaŭ luantoj bezonas komunan servon, specifu la aprobitan vojon kaj permesojn anstataŭ simple direkti unu luanton al la enkursiga kunteksto de la alia. Konservu la aplikaĵan identecon kaj ajnan intencan fontan tradukadon kune kun la reta celo, alie la komuna servo vidos unu luanton kiel la alia.

Ordinara enkursigita transdono ligas BIG-IP al randa enkursigilo de la provizanto sen igi BIG-IP MPLS-PE. Se rekta integriĝo de MPLS aŭ de la VPN-voja familio estas vere bezonata, akiru eksplicitan subtenon por la preciza platformo kaj eldono, ĉar loka retdomajna izolado ne starigas tiun kapablon.

Paŝo 4: kontrolu unu luanton samtempe

Testu luanton A de finpunkto en la kunteksto de A al la aplikaĵa adreso de A, poste ripetu por B. Uzu la formon %ID en diagnozoj por povi pruvi, kiu kunteksto respondis, kaj konfirmu, ke peto el la malĝusta kunteksto malsukcesas anstataŭ surteriĝi ie kredeble.

Kontrolu ankaŭ la provizantan flankon en la sama pasado: la prefikso ĉeestas en la ĝusta VRF, la retoceloj kongruas kun la laborfolio, kaj la revena vojo uzas la celitan alligaĵon. Ping, kiu funkcias de la aparato mem, pruvas la kuntekston de la aparato, ne tiun de la luanto.

Notu la finan mapadon en la laborfolio, inkluzive de la defaŭlta retdomajno de ĉiu sekcio kaj ajna gepatra domajna rilato, kiun vi ebligis. La venontan ŝanĝon en ĉi tiu medio faros iu, kiu legas tiun tabelon, ne iu, kiu legas ĉi tiun artikolon.