Fråga en ingenjör hur mycket som ska läggas till för MPLS och du hör en siffra, oftast trettio, sagt med självförtroende. Siffran är inte så mycket fel som förankringslös: den beror helt på vad utgångssiffran räknar och vad leverantörens kant faktiskt skickar. På en Ethernet-pseudowire är antagandena synliga, och när du väl skriver ner dem ersätter aritmetiken folksägnen.

Tre olika saker mäts under ett namn. Det finns kundens IP-paket, Ethernet-ramen som bärs över pseudowiren och leverantörens egen yttre länkinramning. En budget som blandar dem ger ett värde som inget enhetsfält förväntar sig.

En uträknad budget med varje antagande uttalat

Ta ett kund-IP-paket på 1500 byte, en vanlig Ethernet-header som bärs över pseudowiren utan kundens FCS, ingen bevarad VLAN-tagg, en etikettstack med två poster och ett kontrollord på fyra byte. Den burna Ethernet-headern lägger till 14, bevarade taggar lägger till ingenting, de två etikettposterna lägger till 8 eftersom varje post är 4 byte, och kontrollordet lägger till 4. Det ger 1526 byte MPLS-inkapslat paket.

Läs resultatet noggrant. Det utesluter leverantörslänkens yttre Ethernet-header och dess FCS, och det är ett exempel, inte en konstant att skriva in i ett fält med namnet MTU. Två etiketter är också ett antagande: den verkliga stacken kan bära en transportetikett, en tjänsteetikett och ibland mer, och varje post kostar samma 4 byte.

Vad som faktiskt korsar pseudowiren

RFC 4448 definierar hur Ethernet-ramar färdas inne i MPLS, och i dess vanliga modell tas kundens preamble och FCS bort vid ingress och återskapas vid egress. Därför syns inte FCS i budgeten ovan. VLAN-hantering beror på tjänsteläget: ett läge som bevarar kundens taggar lägger tillbaka deras byte, och ett läge som mappar dem gör det inte. Extra bevarande eller extra inkapsling måste räknas ovanpå.

Kontrollordet är en del av aritmetiken varje gång det används. RFC 8469 rekommenderar det för Ethernet-pseudowires, så en äldre text som beskriver det som valfritt är inte bevis för att din väg utelämnar det. Bekräfta det faktiska tjänsteläget hos leverantören i stället för att sluta dig till det från ett diagram.

Jämför siffran med rätt fält

Håll nu den krävda inkapslade storleken mot varje relevant länk och mot leverantörens definition av den gräns du konfigurerar. Vissa fält beskriver ett IP-paket, andra beskriver en ram eller en annan inkapslingsgräns. Två tal kan se identiska ut och beskriva olika kapaciteter, och det är så en konfiguration som verkar passa ger förluster i produktion.

Det är också därför det är riskabelt att kopiera ett värde mellan orelaterade plattformar. Fältets namn är specifikationen, inte det decimaltal du minns från en annan leverantörs konsol.

Ping-nyttolaster är inte MTU-värden

En IPv4-ping-nyttolast är inte en IP-MTU. IP-headern och ICMP-headern förbrukar också byte, så en nyttolaststorlek som lyckas motsvarar ett större paket på tråden. En sond som passerar vid en storlek säger heller ingenting om en tjänst med ett annat VLAN-läge eller en djupare etikettstack. Testet mäter en väg, en storlek och en nyttolastform, och tjänsten kan variera alla tre.

Värre än så, en ping kan lyckas medan stora ramar misslyckas, eftersom sonden provade en väg och en storlek som den verkliga trafiken aldrig använder. Behandla det som en enda datapunkt om nåbarhet, inte som en specifikation för en lager-2-tjänst.

När ramen inte får plats

Om överstora ramar inte kan bäras och det inte finns någon stödd fragmenterings- eller återmonteringsmekanism, slängs de, vanligtvis utan ett tydligt fel i någon ände. Applikationer visar då tidsgränser vid bulköverföringar medan interaktiva sessioner förblir friska, vilket skickar folk att titta på brandväggar och rutter i stället för att räkna byte.

Klargör den faktiska budgeten med leverantören: tjänsteläge, tagghantering, etikettdjup, kontrollord och den exakta gräns din enhet upprätthåller. Skriv antagandena bredvid talet, för annars ärver nästa ingenjör trettio-byte-regeln och en gåta.

Relaterade artiklar