La RSVP-TE-tunelo funkcias, sed la L3VPN de la kliento havas neniun vojon
Transporto kaj servo estas apartaj decidoj. Legu la etikedan stakon, kontrolu aparte la solvon de la sekva salto kaj la VRF-alkroĉon, poste testu unu realan klientan fluon.
Du teamoj povas ambaŭ pravi, kiam la kliento raportas, ke la VPN estas malsupra, kaj la transporta teamo raportas, ke la tunelo estas en ordo. LSP kun trafika inĝenierado kaj MPLS L3VPN respondas al malsamaj demandoj: unu movas etikeditajn pakojn tra la kerno, la alia decidas, al kiu enkursiga kunteksto pako apartenas. Kiam ili estas konfuzitaj, la diskuto rondiras, ĉar ĉiu flanko mezuras malsaman objekton kaj ambaŭ mezuroj validas.
Transporto supre kaj servo malsupre estas normala stato
LSP povas esti establita, porti trafikon kaj esti videbla en ĉiu monitora sistemo, dum la klienta servo restas neuzebla. Nenio en tiu kombinaĵo estas kontraŭdira, ĉar la tunelo havas neniun opinion pri tio, ĉu fora prefikso ekzistas, ĉu importa politiko akceptis ĝin, aŭ ĉu la alkroĉita cirkvito pasigas kadrojn.
La simptomo, kiu kutime malkaŝas la konfuzon, estas nesimetria: pingoj el la PE-loopback sukcesas, dum gastiganto en la klienta LAN ricevas nenion, aŭ male. Notu, kiuj adresoj funkciis, antaŭ ol formi teorion. Post kiam vi rimarkas, ke vi testas du malsamajn objektojn, la sekva paŝo estas legi la etikedan stakon anstataŭ disputi, kies grafeo estas ĝusta. Du adresoj, du posedantoj kaj kutime du malsamaj homoj, kiuj ĉiu kredas, ke la alia rompis ion.
Legu la stakon kiel du respondecojn
La malsupra etikedo apartenas al la servo kaj la supra etikedo apartenas al la vojo. RFC 4364 priskribas la sinsekvon simple: unue oni surmetas la etikedon de la VPN-vojo, poste tiu etikedita pako estas tuneligita al la sekva BGP-salto, kie trafika inĝenierada tunelo puŝas sian propran etikedon supre.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
Ĉe la fora PE la serva etikedo elektas la traktadon, kiu povas esti VRF-serĉo aŭ alkroĉa decido. Tiu etikedo ne povas esti anstataŭigita per unu, kiu nur transiras la kernon, kaj la du ne estas interŝanĝeblaj eĉ kiam ambaŭ aperas en la sama stako sur la sama interfaco.
Kion pruvas RSVP-sukceso kaj kion ne
RSVP-TE establas eksplicite enkursigitajn LSP-ojn, kun aŭ sen rimedaj rezervoj, kio estas konkreta kaj utila garantio pri la vojo, kiun pako prenas tra la kerno. Ĝi ne estas aserto pri klientaj vojoj, kaj agordita tunela nomo tute ne estas vojo.
Ankaŭ la ĉeesto de RSVP ne donas promeson de fin-al-fina rendimento. Banda rezervo sur unu LSP diras nenion pri la alkroĉita cirkvito, la propra alirlinio de la kliento aŭ la atendvica konduto ĉe la fora rando. Trakti ĝin kiel garantion produktas memfidajn respondojn al demandoj, kiujn neniu demandis. Se la postulo vere estas devontigo pri bendolarĝo, ĝi devas esti kunmetita el la partoj, kiuj efektive devigas ĝin, kaj la LSP estas nur la mezo de tiu ĉeno.
Kontrolu laŭvice, poste haltu
Laboru de la transporto eksteren kaj haltu ĉe la unua paŝo, kiu malsukcesas, ĉar ĉiu posta paŝo supozas, ke la antaŭaj teniĝis. Unue konfirmu, ke la LSP estas establita kaj ke la plusenda ero por la serva prefikso efektive montras al ĝi. Poste konfirmu, ke la VPN-vojo ekzistas en la ĝusta tabelo, ke ĝia etikeda ligo estas ĉeesta kaj ke la importa politiko akceptis ĝin. Poste konfirmu la alkroĉon: la interfacon, la enkapsuligon kaj, kie ĝi aplikiĝas, la VLAN-identigilon, kiu apartenas al tiu kontrakto.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERKomanda sintakso varias laŭ platformo, do traktu tiujn kvar liniojn kiel la kvar demandojn, ne kiel skripton. La grava parto estas, ke ĉiu el ili pridemandas malsaman objekton, kaj tio igas fiaskon montri al specifa posedanto.
Sekvu unu permesitan peton kaj konservu la bonajn pruvojn
Finu per unu reala klienta peto, permesita de politiko, kaj ĝia respondo. Unu funkcianta fluo de fino al fino solvas pli ol paĝo da nombrilaj legadoj, kaj ĝi ekzercas la kombinaĵon anstataŭ ĉiun parton izolite.
Kiam posta stadio malsukcesas, konservu la sukcesan LSP-observon anstataŭ rekonstrui la transporton. Rekonstrui funkciantan tunelon ne povas ripari forestantan foran prefikson, malĝustan VRF-alkroĉon aŭ celan alirregulon, kaj ĝi detruas la pruvon, kiu unue diris al vi, ke la transporto sanas.