Två misslyckanden står för de flesta trasiga QinQ-överlämningar till en VSI, och ingen av dem visas som ett nedåtriktat gränssnitt. Antingen äter ingångsporten upp kundtaggen innan klassificeringen kan se den, eller så är anslutningskretsen bunden till en VSI som den bortre änden aldrig gick med. Från kundsidan ser de två identiska ut: kretsen rapporterar och ingen ram korsar. Arbeta igenom de fyra kontrollerna nedan i ordning och sluta vid den första där ramen du observerar skiljer sig från ramen du skrev ner.

Skriv ned etiketten innan du rör vid enheten

Välj en representativ tjänst och beskriv den som ramar, inte som konfiguration. För en tjänst som håller kundens VLAN 100 och 200 inom leverantören VLAN 900 är kontraktet kort: ingångsramar bär en kundtagg, leverantören lägger till en servicetagg och kundens egen tagg överlever orörd undertill.

customer to provider:  [ C-tag 100 | payload ]
provider inside:       [ S-tag 900 ][ C-tag 100 | payload ]
provider to customer:  [ C-tag 100 | payload ]

Skriv returriktningen också, eftersom ett kontrakt som bara beskriver inträde kommer att klara ett envägstest och misslyckas i produktionen. Den bortre änden måste ge kunden den ram kunden förväntar sig, vilket innebär att dess egen popoperation måste vara den exakta motsatsen till din push. Allt som inte är symmetriskt i den beskrivningen är ett designbeslut som du inte har fattat ännu.

Kontrollera ingångsmatchningen först

Klassificering sker före någon taggoperation, och den kan bara matcha det som kommer. Bekräfta om porten är konfigurerad som åtkomst, trunk eller hybrid, vilka ramtyper den accepterar och vad portens VLAN-identifierare gör med en omärkt ram. På en accessport tas kundtaggen bort vid ankomst, så en senare regel som matchar C-tag 100 har inget kvar att matcha och tjänsten ansluter sig till fel sändningsdomän utan några fel.

En fångst på leverantörssidan löser detta på några sekunder: en korrekt klassificerad QinQ-ram visar två taggar, och en enkeltaggad ram där betyder att den inre taggen förbrukades.

Kontrollera vad taggåtgärden faktiskt gör

Stapling och översättning är olika operationer och plattformar exponerar dem som olika objekt. Stapling trycker på en yttre tagg och lämnar den inre ifred, vilket är vad kontraktet ovan behöver. Translation skriver om en tagg till en annan, vilket är en giltig design men ger en annan ram på tråden. Vissa familjer behöver också QinQ aktiverat explicit på porten innan en stackningsregel träder i kraft, och det yttre TPID kan vara konfigurerbart mellan 802.1Q- och 802.1ad-värdena.

Returvägen förtjänar lika stor uppmärksamhet. Om utträdesregeln visar den yttre taggen på ett undergränssnitt men ett annat undergränssnitt bär svaret utan matchningsregel, ser kunden fungerande sändning och död mottagning.

Kontrollera tjänstebindningen, inte gränssnittsnumret

En VSI identifieras av sina egna tjänste- och virtuella kretsidentifierare, och peer måste använda matchande värden innan en pseudowire bildas. Anslutningskretsen binder sedan den VSI till en specifik port och VLAN, vilket är ett separat uttalande från regeln som klassificerade ramen. Ett undergränssnittsnummer som ser rätt ut bevisar ingenting om någon av bindningarna.

Kontrollera pseudotrådens tillstånd och anslutningskretsens tillstånd separat, och kontrollera signaleringssessionen som bär pseudotråden. Två av dessa tre kan vara friska medan den tredje inte är det, och den som är nere talar om för dig vilken sida du ska fixa.

Isolering är ett separat löfte. Att hålla kundtaggar intakta i en VSI segmenterar inte kunder från varandra, eftersom MAC-inlärning sträcker sig över hela instansen; om kontraktet säger isolering behöver det separata instanser eller en explicit per-VLAN-policy.

Kontrollera storleksbudgeten och bevisa sedan kontraktet

Den yttre taggen lägger till fyra byte, och pseudowire-inkapslingen lägger till en etikettstack och möjligen ett kontrollord ovanpå det. Lägg in allt i MTU- och MRU-budgeten på båda leverantörernas kantenheter och stäng inte av ett kontrollord enbart för att tysta en storleksvarning, eftersom den bortre änden kan kräva det. Håll en förvaltningsväg som inte beror på tjänsten du ändrar.

Testa sedan tre fall vid kundbilagan: det första godkända C-VLAN i båda riktningarna, det andra godkända C-VLAN och ett VLAN som enligt kontraktet måste vägras. Observera ramar istället för att läsa gränssnittstillstånd och upprepa efter varje ändring av taggregeln.

En upp-VSI säger bara att pseudotråden bildades. Det står ingenting om huruvida ramen som korsar den är ramen kunden betalat för.

Relaterade artiklar