Vai VPNv4 kodolā ir nepieciešams MPLS? Ne obligāti
BGP VPNv4 pārrunā maršrutu sadales kontekstu, nevis pārsūtīšanas ceļu. Atdaliet importu, nākamā lēciena atrisinājumu un iekapsulējumu, ko varat izmantot.
VPNv4 adrešu saimes ieslēgšana starp diviem maršrutētājiem rada tikai maršrutu sadales kontekstu un neko vairāk. Tas neinstalē pārsūtīšanas ceļu un nepasaka, kurš iekapsulējums nogādās klienta paketi līdz attālajam galapunktam. Kad šie divi fakti ir atdalīti, jautājums «vai tam kodolā vajag MPLS» kļūst šaurāks un atbildams jautājums par platformas atbalstīto datu plakni.
Ko adrešu saime patiesībā pārrunā
Daudzprotokolu BGP saskaņā ar AFI 1 un SAFI 128 pārnēsā VPNv4 tīkla slāņa sasniedzamības informāciju, un katrs ieraksts savieno maršruta atšķirēju ar prefiksu un etiķeti. Sesija pārrunā, ka abas puses spēj šo informāciju kodēt un atkodēt. Ko tā nepārrunā, ir datu plakne. Viss pēc šīs rindkopas attiecas uz pārsūtīšanu, un neko no tā nenosaka sesijas pacelšanās.
Tātad veiksmīga sesija ir vadības plaknes spēju pierādījums, nevis pārsūtīšanas. Maršrutētājs var turēt tūkstošiem VPNv4 ierakstu un tomēr nomest katru klienta paketi, un tieši tāpēc šīs divas kļūdu klases sākumā tiek sajauktas.
Pievērsiet uzmanību etiķetei NLRI. Tā ir pakalpojuma etiķete, piesaistīta prefiksam VRF iekšienē, un tai ir pārsūtīšanas loma, kad pakete sasniedz izejas galapunktu. Vai kāda tranzīta ierīce to lasa, ir atsevišķs projektēšanas lēmums.
Saņemšana, imports un pārsūtīšana ir trīs soļi
Maršruta saņemšanu, atļauju to izmantot un spēju ar to pārsūtīt veic dažādas ierīces daļas. BGP glabā to, ko dzird; importa politika un maršruta mērķa atbilstība nosaka, kura VRF drīkst to izskatīt; pēc tam pārsūtīšanas plaknei ir jāatrisina izsludinātais nākamais lēciens kaut kam, ko tā tiešām var izstumt uz vadu.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
Tieši šajā vidējā solī mīt visnegaidītākās kļūdas. Maršruts var būt BGP tabulā, derīgs un pat labākais, kamēr VRF maršrutu tabula paliek tukša, jo neviens maršruta mērķis neatbilda importa sarakstam. Nekas nefiksē protokola kļūdu, jo protokola kļūda nav notikusi.
Pēdējais solis ir vieta, kur parādās platformas atbalsts. Apakšslānī sasniedzams nākamais lēciens nav automātiski atrisināms kā VPN pakalpojuma transports, un ierīce var prasīt konkrētu tuneļa tipu, konkrētu etiķetes darbību vai abus. Atrisinājuma statusa lasīšana ir informatīvāka nekā maršrutu skaita lasīšana.
IP kodols var pārnēsāt steku, ko tas nekad nepārslēdz
Atšķirība, ko ir vērts saglabāt, ir starp «kodols neizpilda MPLS» un «pakalpojumā nekur nav etiķetes». Tie ir dažādi apgalvojumi, un tikai pirmais attiecas uz tranzīta ierīcēm. RFC 4023 definē MPLS pārnēsāšanu pa IP vai GRE tuneļiem, un tieši šis mehānisms padara otro apgalvojumu iespējamu pilnīgi IP kodolā.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulTranzīta maršrutētāji pārsūta pēc ārējā IP galamērķa un neprasa ne klienta prefiksus, ne vietējo etiķešu pārslēgšanu. Attālajā galā ārējais tunelis tiek noņemts, un pakalpojuma etiķete turpina savu darbu. Kodols pārvietoja necaurspīdīgu kravu, un tieši tas ir tas, kuros IP tīkls ir labs.
Ko šis projekts jums nedod, ir universāla garantija. Tas nav pierādījums, ka katrs maršrutētājs atrisina katru VPNv4 nākamo lēcienu pa jebkuru GRE saskarni, un tas nav iemesls dzēst strādājošu vietējo MPLS konfigurāciju. Tas ir universālā apgalvojuma pretpiemērs, un praktiskais jautājums paliek lokāls platformai. Pierakstiet šo jautājumu kā platformas ierobežojumu, nevis kā protokola noteikumu.
Izejiet ķēdi ierīcē, līdz tā pārtrūkst
Sāciet ar saņemto maršrutu un apstājieties pie pirmā soļa, kas neizdodas, jo vēlākos soļus nevar diagnosticēt, kamēr iepriekšējais ir salauzts. Četras komandas aptver lielāko daļu no tā tipiskā ieviešanā.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_ALasiet tos kā secību, nevis kā četras neatkarīgas pārbaudes. Pirmais apstiprina, ka saime ir aktīva un partneris apmainās ar maršrutiem; otrais parāda, vai prefikss ieradās ar lietojamu nākamo lēcienu; trešais pierāda importa atbilstību; ceturtais parāda, vai pārsūtīšanas plakne tam piesaistīja etiķeti vai tuneli.
Pēc tam pārbaudiet darba slodzes ceļu abos virzienos ar MTU, kas pārdzīvo iekapsulējumu. GRE pievieno galvenes baitus, un ceļš, kas iztur mazus zondes, var neizdoties pilna izmēra paketēs tikai vienā virzienā, kas izskatās pēc lietojumprogrammas, nevis transporta kļūdas.
Divas ekspluatācijas piezīmes noslēdz ciklu. GRE ir iekapsulējums, nevis konfidencialitāte, tāpēc neuzticamam tranzīta tīklam virsū vajag atbalstītu drošības kārtību, nevis pieņēmumu. Un pirms projektēšanas apskates pierakstiet, kādu iekapsulējumu platforma patiešām atbalsta, jo šī vienīgā atbilde izšķir, vai tikai IP kodols ir derīga izvēle vai plāns, kas nevar pārsūtīt.