/24 moja kwa wateja wawili? VPNv4 inahitaji RD na lebo

Wapangaji wawili wanahesabu tawi lao kwa 10.50.0.0/24 moja, na baada ya mabadiliko njia ya mmoja inatoweka kwenye ukingo wa mtoa huduma wakati nyingine inaendelea kufanya kazi. Urahisishaji nyuma ya tikiti hilo kwa kawaida ni kuacha kitenganishi cha njia (RD) kwa sababu „lebo tayari inamtambua mteja“. Haifanyi hivyo. RD na lebo zinajibu maswali mawili tofauti, na pengo hilo linaonekana tu wakati anwani zinazopishana zinalazimisha.

Njia moja mahali inapopaswa kuwa mbili

IPv4 unicast ya kawaida hulinganisha njia mbili kwa kiambishi sawa na kuweka bora. 10.50.0.0/24 kutoka mpangaji A na 10.50.0.0/24 kutoka mpangaji B ni ufunguo mmoja, kwa hivyo mmoja unashinda na mwingine unaendelea kuishi kama njia mbadala pekee. Itifaki ilifanya ilichoambiwa; safu ya udhibiti iliombwa kuhifadhi njia mbili tofauti chini ya kitambulisho kimoja.

Matokeo yanaonekana kama njia iliyokosekana badala ya hitilafu: PE iliyoshindwa shindano bado inapeleka mbele mpangaji wake kwa ndani, hivyo jaribio la ndani ya tovuti linafanikiwa na jaribio kati ya tovuti linashindikana. Hesabu maingizo ya kiambishi hicho kwenye jedwali la VPNv4 kabla ya kugusa sera yoyote.

RD inabadilisha ufunguo mmoja kuwa mbili

Kitenganishi cha njia cha baiti nane huwekwa mbele ya kiambishi cha IPv4, na kitu ambacho BGP hubeba kinakuwa anwani ya VPN-IPv4 badala ya kiambishi cha IPv4. Wapangaji wawili wanaweza kushikilia biti 32 zilezile kwa sababu biti 64 za mbele zinatofautiana. Kuna aina za muundo kwa RD inayotegemea AS na kwa ile inayotegemea anwani, na uchaguzi ni wa PE ya asili. RD inayotegemea AS ni ya kawaida wakati PE zinashiriki AS moja, na inayotegemea anwani wakati hazishiriki.

Usisome RD kama lebo ya uanachama. Malengo ya njia yanasimamia uagizaji na usafirishaji nje na yanaamua ni VRF zipi zinazoweza kuweka njia hiyo; RD inahakikisha tu kwamba njia ina utambulisho wake. Kumupa kila VRF RD yake mwenyewe ni desturi ya kawaida kwa sababu huweka ramani hiyo ikisomeka kwenye kionyeshi cha njia.

Lebo ni maagizo ya ndani ya kupeleka mbele

Kila tangazo pia hubeba lebo ya MPLS, na maana yake imezuiwa kwa kipanga njia kilichogawa. PE nyingine inaweza kutoa nambari hiyo hiyo kwa marudio yasiyohusiana. Ndiyo sababu lebo haiwezi kuchukua nafasi ya utambulisho wa mteja: nambari ni sahihi tu kando ya hop inayofuata na hali ya kupeleka mbele iliyoiweka.

Ufafanuzi wa ugawaji unatofautiana kwa utekelezaji na muundo: majukwaa mengine hutoa lebo moja kwa kila VRF, mengine kwa kila kiambishi, na lebo inaweza kutambua kitendo cha kupeleka mbele badala ya mteja. Lebo mbili tofauti zinazofikia marudio sawa si ukinzani, na nambari moja ya lebo kwenye PE mbili pia si ukinzani.

Kwa nini moja haiwezi kuchukua nafasi ya nyingine

Kusoma tangazo ni kuangalia mambo manne pamoja: kiambishi kilichohitimu RD, malengo ya njia, hop inayofuata na lebo. Kusoma pakiti ya mtumiaji ni kuangalia mrundikano uliowekwa kutoka kwa taarifa hizo. Muundo mzuri unaonyesha pande zote mbili zikilingana, na ule uliovunjika kwa kawaida una upande mmoja sahihi na mwingine uliopitwa na wakati. Ulinganisho huo hutenganisha tatizo la utambulisho na tatizo la kupeleka mbele.

Tofauti iliyopangwa kati ya safu ya udhibiti na safu ya data ni zana ya kufundishia, si maelezo ya usimbaji. RFC 8277 huweka lebo ndani ya NLRI iliyowekwa lebo, kwa hivyo tangazo lenyewe hubeba kiungo; kuitumia kwa kupeleka mbele ni hatua ya baadaye, tofauti.

Wakati njia ya mpangaji haipo, angalia kwa mpangilio huu: maingizo mawili ya VPNv4 kwa kiambishi, lengo sahihi la njia kwa kila moja, hop inayofuata inayoweza kutatuliwa, na lebo ambayo PE inayopokea ina hali yake. Kurekebisha utambulisho kwa thamani ya kupeleka mbele, au kinyume chake, kutapita ukaguzi mmoja na kushindikana kwenye ule unaofuata.