S ohledem na 802.1Q uznáváme dva režimy provozu portů na síťových zařízeních – jednak tzv. přístupové (access porty), po nichž teče provoz již „netagovaný“ (typicky switch u odchozího frame tag odstraní a naopak příchozí frame tagem označí), a pak tzv. trunky, tedy porty, po nichž veškerý provoz (s výjimkou native VLAN) naopak „otagovaný“ teče.
Normu 802.1Q podporují víceméně všichni výrobci jen trochu sofistikovanějšího síťového hardware, byť u některých musíte při koupi menších či středně velkých boxů investovat také do rozšířenějších verzí firmware. Z volně šiřitelných operačních systémů 802.1Q podporuje nyní Linux a FreeBSD a pravděpodobně i další. Jestli tuto funkci podporuje i některý systém z produkce Microsoftu, netuším, a je to ostatně irelevantní, neboť u serverů tato funkce není nezbytná a provozovat softwarový router na takové platformě nelze považovat za smysluplné.
Za jediný problém lze považovat délku rámce, která může překročit velikost bufferu ovladače síťových karet, jehož obvyklá velikost u běžných karet pro 10/100Base-T činí 1518 bajtů. Kupříkladu při implementaci 802.1Q v Linuxu je nezbytné zvýšit velikost tohoto bufferu na 1522 bajtů, nebo použít gigabitové síťové karty, jejichž ovladače již většinou podporují jumbo frames až do velikosti 9218 bajtů. Zařízení komerčních výrobců s touto záležitostí obvykle již počítají a zmíněný buffer mívá 1530 až 1600 bajtů, některá komerční gigabitová zařízení počítají i s rámci až do velikosti cca 14 kB.
Když poskytovatel, který vlastní 802.1Q infrastrukturu, prodá zákazníkovi ethernetový spoj v rámci své sítě, prodává mu vlastně jen jednu VLAN. Nicméně stále častěji nastává stav, že zákazník také využívá 802.1Q a chce přes tento spoj přenášet své, již tagované, rámce. Existují samozřejmě polovičatá řešení tohoto problému, jako je varianta nabídnout zákazníkovi k dotyčnému spoji více VLAN (a fyzickou realizaci přípojky provést jako trunk), ale to je záležitost z hlediska administrace a zejména koordinace se zákazníkem poměrně náročná – a to jak při samotné instalaci, tak samozřejmě i při řešení provozních problémů či údržbě. Takové řešení není ideální pro zákazníka a už vůbec ne pro poskytovatele, mimo jiné i proto, že VLAN tag je pouze dvanáctibitové číslo a může tedy nabývat hodnot jen od 0 do 4096. K dispozici je tedy pouhých 4096 VLAN (na zařízení řady výrobců, mezi něž se ostatně řadí i Cisco Systems, jich může být k dispozici výrazně méně, kupříkladu třeba jen 1000).
Řešení problému však existuje – je jím technologie 802.1Q over 802.1Q, zkráceně Q-in-Q. O co jde? Myšlenka je poměrně jednoduchá – když mohu označit frame jednou, proč jej neoznačit vícekrát? Již otagovaný rámec je tedy otagován znovu. První otagování rámce provede kupříkladu zařízení zákazníka, druhé otagování zařízení poskytovatele.
Co je na celé věci zajímavé, je skutečnost, že Q-in-Q nemusejí podporovat ani zařízení zákazníka, ani všechna zařízení poskytovatele na trase, ale pouze ta zařízení, která provádějí druhé označení rámce (a pochopitelně zároveň jeho odznačení v opačném směru, tzv. edge). Ostatní zařízení si přečtou pouze druhý (tedy přesněji v dotyčném frame v pořadí první, jako druhý byl přidán) tag, považují tento rámec za součást jedné VLAN (přidělené dotyčnému zákazníkovi) a další obsah rámce je nezajímá. Na edge zařízeních přibývá kromě režimu trunk a access další režim fungování – režim dot1q-tunnel, v němž se port switche chová víceméně jako v režimu access, jen již otagované příchozí rámce nezahazuje, ale otaguje všechny rámce nezávisle na tom, zda již nějaký tag mají či nikoli (čili již otagované rámce otaguje znovu), a naopak všechny odchozí rámce dotyčného konkrétního tagu zbaví. Zařízení zákazníka, zapojené proti portu v režimu dot1q-tunnel, je nakonfigurováno v běžném režimu trunk.
To je pochopitelně jedna možnost využití Q-in-Q. Druhou možností je ukončení Q-in-Q tunelu na jedné straně přímo ve směrovači, nicméně dvojí otagovaní zatím, pokud vím, podporuje jen jedna verze IOSu pro směrovače řady Cisco 10000 a pak shodou okolností šikovně napsaný 802.1Q subsystém v Linuxu (který umožňuje vytvořit tagovaný subinterface na jakémkoli rozhraní, včetně již otagovaného).
Jediné, co je nezbytné vyladit, je tak délka rámců, která nám o další čtyři byty roste. Na portu switche, nastaveného v režimu dot1q-tunnel, je možné zapnout tunelování různých L2 protokolů, jako je spanning-tree, Cisco discovery protocol, pagp apod., takže pro zákazníka se Q-in-Q tunel může tvářit jako čistý ethernetový spoj bez další L2 infrastruktrury na trase. Další příjemnou věcí může být integrace Q-in-Q a VPLS či AToM (resp. EoMPLS), kde je možné přes jeden vytvořený L2 VC přenášet celý trunk (což v některých případech může přinést značné úspory, a to jak za vyšší typy směrovačů, tak i za jednotlivé porty těchto směrovačů – a tedy i pro zákazníka snížit cenu služby), opět je nezbytné pouze „poladit“ MTU.
Teď se pochopitelně nabízí otázka, zda je možné otagovat rámec ještě vícekrát (tedy Q-in-Q-in-Q nebo Q-in-Q-in-Q-in-Q atd). Pochopitelně to možné je a víceméně v dalším tagování nikomu nic nebrání, kromě nutnosti postupného rozbalování rámců v kaskádě switchů a také maximální délka rámce. Teoreticky je tedy při MTU 9 kB možné 1518 bajtů dlouhý netagovaný rámec otagovat zhruba 1750×, přičemž overhead v takovém případě činí cca 800 procent, u kratších rámců i mnohem více. Pokud budete chtít mnohokrát tagovaný spoj ukončit například v linuxovém boxu, kde konvence pojmenování vícekrát tagovaných subinterface je eth0.a.b.…z, není od věci začít se poohlížet i po tom, jaký je limit pro délku jména rozhraní… ;-) Otázka pochopitelně zní, k čemu je to dobré. Dovedu si představit případ, kdy má smysl použít Q-in-Q-in-Q, ale pro další otagování již nevidím žádný rozumný důvod, v takovém případě je již výhodnější použít některý ze způsobů přenosu L2 přes infrastrukturu postavenou na MPLS nebo celé řešení navrhnout jinak.
