Spørg en ingeniør, hvor meget der skal lægges til for MPLS, og du vil høre et tal, normalt tredive, sagt med selvtillid. Tallet er ikke så meget forkert som det er løsrevet: det afhænger helt af, hvad starttallet tæller, og hvad udbyderens kant faktisk sender. På en Ethernet-pseudowire er antagelserne synlige, og når du først skriver dem ned, erstatter aritmetikken folkloren.

Tre forskellige ting måles under ét navn. Der er kundens IP-pakke, Ethernet-rammen der bæres over pseudowiren, og udbyderens egen ydre linkindramning. Et budget der blander dem, giver en værdi som intet enhedsfelt forventer.

Et gennemregnet budget med hver antagelse udtrykt

Tag en kunde-IP-pakke på 1500 byte, en almindelig Ethernet-header båret over pseudowiren uden kundens FCS, ingen bevaret VLAN-tag, en labelstak med to poster og et kontrolord på fire byte. Den bårede Ethernet-header tilføjer 14, bevarede tags tilføjer intet, de to labelposter tilføjer 8, fordi hver post er 4 byte, og kontrolordet tilføjer 4. Det giver 1526 byte MPLS-indkapslet pakke.

Læs resultatet omhyggeligt. Det udelukker udbyderlinkets ydre Ethernet-header og dets FCS, og det er et eksempel, ikke en konstant der skal skrives i et felt med navnet MTU. To labels er også en antagelse: den virkelige stak kan bære en transportlabel, en servicelabel og af og til mere, og hver post koster de samme 4 byte.

Hvad der faktisk krydser pseudowiren

RFC 4448 definerer, hvordan Ethernet-rammer rejser inde i MPLS, og i dens almindelige model fjernes kundens preamble og FCS ved indgangen og gendannes ved udgangen. Derfor optræder FCS ikke i budgettet ovenfor. VLAN-håndtering afhænger af tjenestetilstanden: en tilstand der bevarer kundens tags, lægger deres byte tilbage, og en tilstand der mapper dem, gør det ikke. Yderligere bevarelse eller ekstra indkapsling skal tælles oveni.

Kontrolordet er en del af aritmetikken, hver gang det bruges. RFC 8469 anbefaler det til Ethernet-pseudowires, så en ældre tekst der beskriver det som valgfrit, er ikke bevis for, at din sti udelader det. Bekræft den faktiske tjenestetilstand hos udbyderen i stedet for at udlede den fra et diagram.

Sammenlign tallet med det rigtige felt

Hold nu den krævede indkapslede størrelse op mod hvert relevant link og op mod leverandørens definition af den grænse, du konfigurerer. Nogle felter beskriver en IP-pakke, andre beskriver en ramme eller en anden indkapslingsgrænse. To tal kan se identiske ud og beskrive forskellige kapaciteter, og det er sådan en konfiguration, der ser ud til at passe, giver tab i produktion.

Det er også derfor, det er risikabelt at kopiere en værdi mellem ubeslægtede platforme. Feltets navn er specifikationen, ikke det decimaltal du husker fra en anden leverandørs konsol.

Ping-nyttelaster er ikke MTU-værdier

En IPv4-ping-nyttelast er ikke en IP-MTU. IP-headeren og ICMP-headeren bruger også byte, så en nyttelaststørrelse der lykkes, svarer til en større pakke på ledningen. En sonde der passerer ved én størrelse, siger heller intet om en tjeneste med en anden VLAN-tilstand eller en dybere labelstak. Testen måler én sti, én størrelse og én nyttelastform, og tjenesten kan variere alle tre.

Værre endnu, en ping kan lykkes, mens store rammer fejler, fordi sonden prøvede en sti og en størrelse, som den virkelige trafik aldrig bruger. Behandl det som ét datapunkt om tilgængelighed, ikke som en specifikation for en lag-2-tjeneste.

Når rammen ikke passer

Hvis overstore rammer ikke kan bæres, og der ikke er nogen understøttet fragmenterings- eller genopbygningsmekanisme, bliver de kasseret, normalt uden en klar fejl i nogen ende. Applikationer viser derefter timeouts på bulkoverførsler, mens interaktive sessioner forbliver sunde, hvilket sender folk til at kigge på firewalls og ruter i stedet for bytetal.

Afklar det faktiske budget med udbyderen: tjenestetilstand, taghåndtering, labeldybde, kontrolord og den præcise grænse, din enhed håndhæver. Skriv antagelserne ved siden af tallet, for ellers arver den næste ingeniør tredive-byte-reglen og et mysterium.

Relaterede artikler