QinQ技术实战：双层VLAN标签原理、配置与跨域排障

前阵子帮一家客户做分部专线割接两边交换机的VLAN规划一对比问题就来了A分部把财务网放在VLAN 10B分部也把访客网放在VLAN 10。按常规二层专线接起来两个广播域直接打架业务还没跑起来故障电话先到了。这个场景在数通圈太常见了而解决它最常见也最朴素的手段就是QinQ——VLAN的双层标签技术也叫VLAN Stacking或802.1ad。这篇内容适合正在处理跨地域组网、运营商专线接入或者刚入门数通想搞懂“双层标签到底是什么”的工程师我会把机制、配置、排障和选型一起讲透。我自己第一次真正研究QinQ不是从标准文档里学的而是被一个“时通时不通”的故障逼着去翻报文。当时客户两个厂区走运营商二层专线互访交换机和服务器配置都检查过VLAN也统一改成了一样可流量总是不稳定后来抓包才发现运营商在网络中间给帧加了一层额外的标签。从那之后我就意识到QinQ不是书本里那种可有可无的概念它就在运营商骨干和客户侧设备之间频繁出现搞清楚之后很多玄学故障都变成了明牌。1. 一次VLAN编号冲突暴露了单层标签的极限1.1 从4096说起VLAN编号空间到底哪里不够用标准的802.1Q VLAN标签里VLAN ID字段只占12个比特所以取值范围是0到4095。其中0和4095都不能正常使用0表示不携带VLAN ID4095是保留值实际能用来划分业务的VLAN空间差不多就是1到4094。听起来有四千多个编号小型园区肯定够用但一旦放到运营商或者跨地域大网里这个空间就很紧张了。一台汇聚设备上可能同时承载几十个客户的二层专线每个客户内部又有自己的VLAN规划如果给每个客户都分配一段独立的VLAN段4094这个数字很快就会吃紧。而且很多设备内部还要预留一些VLAN给管理、语音、组播等特殊用途真正能自由规划的空间又打折。所以单纯靠“把VLAN编号加宽”的思路在802.1Q框架里走不通必须另想办法在不改变客户内部VLAN编号的前提下让不同客户共享同一条骨干链路。1.2 真正难的是“重叠”不是“不够多”比VLAN数量不够更麻烦的是不同客户或不同分部的VLAN规划完全重叠。拿最简单的场景举例客户A和客户B都是普通企业各自内部都有VLAN 10、VLAN 20他们分别接入运营商的同一台汇聚交换机。如果不做任何处理两个客户的VLAN 10在物理链路上就是同一个广播域数据帧会互相串ARP表也会乱套。这个问题的本质有点像邮政编码同一个城市里“人民路1号”可以有很多个但只要套上不同的省份或者城市编码就不会混淆。QinQ的思路就是给每个客户一个“外层编码”客户自己内部的VLAN编号是“内层编码”运营商骨干网络只关心外层编码不关心内层到底是什么。这样一来客户A的VLAN 10和客户B的VLAN 10虽然长得一模一样但因为外层标签不同在骨干网络里就被隔离开了。1.3 QinQ一句话定义与它在二层网络里的定位QinQ全称是“802.1Q in 802.1Q”就是在原来已经带有802.1Q标签的以太网帧外面再封装一层802.1Q标签。外层标签也叫服务提供商标签S-VLANService VLAN内层标签是客户自己的标签C-VLAN, Customer VLAN。在工程现场大家通常叫法更直接外层叫公网标签或运营商标签内层叫私网标签或客户标签。它的本质作用有两个第一扩展VLAN数量把原来单层4094的限制通过“外层乘内层”的方式扩宽第二隔离不同租户让多个客户可以在同一台设备、同一条链路上并行跑互不干扰。需要注意QinQ仍然工作在二层它解决的是以太网帧格式和标签转发的问题不是路由问题。2. 一张以太网帧被贴了两层标签QinQ的报文机制拆解2.1 拆开一个QinQ报文一个标签接着一个标签标准以太网帧原本没有802.1Q标签只有目的MAC、源MAC、类型/长度和载荷。引入802.1Q之后帧里多了一个4字节的Tag其中2字节是TPIDTag Protocol Identifier默认是0x8100另外2字节是TCI里面包含优先级和VLAN ID。QinQ就是在客户原有的802.1Q Tag外面再插入一个4字节的S-Tag。所以如果客户已经打了内层标签QinQ相对于客户原帧只是多增加了4字节如果客户发过来的是不带标签的普通帧那QinQ整帧会增加8字节开销。整个帧从外到里依次是最外层S-Tag外层TPID常见值是0x8100、0x88a8或0x9100具体看运营商和设备配置。第二层C-TagTPID基本是0x8100表示这是客户自己的VLAN标签。之后才是源MAC、目的MAC和载荷数据。抓包的时候最直观的感受就是一个数据帧里出现了两个VLAN ID字段。如果你看到外层是VLAN 100、内层是VLAN 10那就是典型的QinQ封装S-VLAN是100C-VLAN是10。2.2 谁是“公网标签”谁是“私网标签”外层S-VLAN的作用是决定这份数据在运营商骨干网络里怎么走。运营商在接入设备上收到客户的帧后会根据客户接入端口或内层VLAN规则打上这个外层标签骨干交换机就只按这个外层标签做转发决策根本不看内层。内层C-VLAN则是客户自己网络里的真实区域划分。比如客户内部有VLAN 10是财务VLAN 20是办公这些信息对客户自己的交换机是有意义的但对运营商设备来说只是“需要透传的内容”。QinQ非常巧妙的一点就是运营商设备不解析内层标签的语义只把它当作数据的一部分原样搬移到了对端接入设备再剥掉外层标签把原本的客户帧还回去。这就可以想象成寄快递时客户自己先给文件袋上贴了一个小标签C-VLAN快递公司收件后在外面再套一个印着大单号的袋子S-VLAN中间运输只看大单号到了目的地撕掉大袋子里面的文件和小标签原封不动继续走客户自己的内部流程。2.3 封装与解封装的动作顺序从客户交换机到运营商骨干围绕一条完整的专线链路QinQ的动作其实只有三步客户交换机把带C-VLAN标签的帧发到运营商接入设备。运营商接入设备根据接入端口或匹配规则在帧头添加S-VLAN标签然后通过上行口进入骨干网。骨干网设备按S-VLAN转发到达对端运营商接入设备后剥掉S-VLAN把保留了C-VLAN的原始帧交给对端客户交换机。这个过程里有一个容易被忽略的点大多数字段如MAC地址、C-VLAN、载荷在骨干传输过程中都是不可见的运营商设备只维护“S-VLAN 目的MAC”的转发表。这意味着客户内部即使存在MAC地址冲突只要外层S-VLAN隔离做得足够彻底问题就不会暴露。但反过来如果外层标签规划或设备配置有误内层冲突就会直接蔓延到整个骨干网。3. 三种封装玩法端口QinQ、选择性QinQ和灵活QinQ怎么选3.1 端口QinQ一端口一标签简单粗暴端口QinQ是最基础的模式。运营商接入设备的某个客户侧端口开启QinQ功能后从该端口收到的所有帧不管内层是什么VLAN也不管有没有标签都会被统一打上同一个外层S-VLAN。这种模式的优点是配置简单、思路清晰适合一个客户独占一个接入端口的情况。比如一栋商务楼里每一层或每一个租户对应接入交换机的一个端口那给每个端口指定一个S-VLAN就等于给每一户发了一个独立的信箱。缺点是粒度太粗一个端口只能对应一个外层VLAN如果同一个端口下混着多个业务域就没法区分了。实际工程里很多运营商给企业开专线都是这个模式因为企业侧只需要一台普通交换机接到运营商提供的接入端口上后续内层VLAN无论怎么调整运营商都不用改配置。3.2 选择性QinQ把不想封装的流量捞出来选择性QinQ也叫基于内层VLAN的QinQ它比端口QinQ多了一个判断条件只有匹配指定C-VLAN范围的帧才会额外打外层标签其他VLAN的帧要么原样转发要么做别的处理。这种模式在企业专线里非常实用。举个例子客户接了一条专线需要把VLAN 10到VLAN 20的业务透传到异地但VLAN 1的管理流量希望留在本地或者希望原样上送到运营商做远程维护。这时就可以用选择性QinQ只给VLAN 10到20打上外层标签VLAN 1放行不处理。这样既保证了核心业务透传又不影响管理通道。配置上比端口QinQ多一张匹配表但原理仍然是“匹配客户标签 → 决定是否加外层标签”并不复杂。3.3 灵活QinQ映射表驱动适合多租户灵活QinQ的主体思想是按内层VLAN的不同把流量映射到不同的外层VLAN。这就意味着同一个客户接入端口下不同的C-VLAN可以被封装成不同的S-VLAN从而在运营商骨干网络里走不同的路径、享受不同的QoS策略或隔离等级。举一个典型的酒店场景一家酒店接入运营商网络同一个端口下既要传客房宽带又要传监控还要传前台管理系统。这时可以给客房宽带对应的C-VLAN映射到S-VLAN 100监控映射到S-VLAN 200管理系统映射到S-VLAN 300。对酒店自己来说这些流量都是本地VLAN但进入运营商网络后各自独立。灵活QinQ的本质就是一张“内层VLAN → 外层VLAN”的映射表通常用流策略或映射命令实现。3.4 三种模式的选型对照表模式封装规则外层标签来源典型场景配置复杂度端口QinQ端口下所有帧统一封装固定为端口PVID单客户独占端口、业务透传低选择性QinQ仅匹配指定C-VLAN才封装固定但需匹配内层管理流量与业务流量共存中灵活QinQ按C-VLAN映射不同S-VLAN根据映射表变化多租户、多业务共享端口较高选型建议很简单如果端口只服务一个客户或一个业务直接端口QinQ如果同一端口下混合了需要透明和管理流量用选择性QinQ如果是运营商分租场景或酒店、园区多业务并存的场景就用灵活QinQ虽然配置繁琐一些但后期排障和扩展都舒服很多。4. 实战把QinQ部署进网络的配置与验证流程4.1 拓扑角色划分接入侧、汇聚侧、骨干侧各唱什么戏部署QinQ之前先要理清楚网络里每个角色。以一个简单的跨地域二层专线为例拓扑可以理解为客户交换机A → 运营商接入设备CE-A → 运营商骨干交换机P → 运营商接入设备CE-B → 客户交换机B客户交换机只管自己的C-VLAN完全感知不到S-VLAN的存在。CE-A和CE-B主要做封装和解封装客户侧的端口配置成QinQ模式面向骨干侧的端口用Trunk或特殊QinQ口放行S-VLAN。骨干交换机P只认S-VLAN本质上就是一台二层转发设备但接口MTU、TPID这些参数必须配合QinQ调整。很多人在配置时容易搞混的是端口角色。CE上连接客户交换机的端口才是需要开启QinQ的接口面向骨干网络的端口只需要正常放行外层S-VLAN即可不需要对客户侧接口设置双层标签。如果两头搞反了就会出现“客户流量到了骨干侧根本没打上公网标签或者打了标签却放不出去”的奇怪现象。4.2 一台设备上的最小配置与验证步骤说一个最简化的配置思路。在CE-A上假设客户从GE0/0/1进来外层规划为S-VLAN 100上行口GE0/0/2接骨干网络。基础的端口QinQ配置看起来像这样interface GigabitEthernet0/0/1 port link-type dot1q-tunnel port default vlan 100这个配置的实际含义是GE0/0/1口进入的所有带有标签的帧统一再封装外层VLAN 100没有标签的帧也会被打上VLAN 100的外层标签。不同厂商、不同版本的命令有差异但逻辑一致客户侧接口要设置成QinQ隧道模式并指定外层VLAN。上行口GE0/0/2需要配置为Trunk并放行VLAN 100interface GigabitEthernet0/0/2 port link-type trunk port trunk allow-pass vlan 100如果是灵活QinQ或选择性QinQ就需要在内层VLAN匹配和外层VLAN映射上多写几条规则但最小起步配置一定是端口QinQ先把链路跑通再逐步细化。验证基本分三步在CE上查看QinQ接口状态确认端口已经工作在隧道模式外层VLAN是100。从客户交换机A ping客户交换机B的地址同时在CE-A的上行口做抓包能看到一个帧里有外层100、内层客户原有VLAN。在CE-B连接客户交换机B的接口上抓包确认外层标签已经被剥掉交到客户B手里的还是只有内层标签的原始帧。这三点都满足基本可以证明QinQ链路在转发层面没有问题。4.3 外层VLAN编号规划一张表管住全网QinQ本身不复杂但外层S-VLAN的规划一旦乱掉后面排障会非常痛苦。我习惯的做法是建立一张“S-VLAN分配表”字段包含S-VLAN编号、客户名称、接入设备名称、接入端口、内层VLAN范围、业务类型、对端接入设备、TPID值。几个规划时容易踩的坑先提前说不要用VLAN 1作为外层S-VLAN很多接口默认PVID就是1容易跟未配置端口的流量混在一起。S-VLAN编号在同一个汇聚域内要全局唯一不要一个城市用一个编号逻辑跨到另一个城市就重复。如果运营商侧已经分配了S-VLAN段那客户侧设备接入时就要确认双方约定的TPID值是多少是0x8100还是0x88a8这个值必须保持一致。外层VLAN规划不是一次性工作它要在项目交付后跟着客户变更持续维护。所以我一直建议把这张表做成文档和开局配置一起交给运维团队别只存在自己电脑里。5. 排错实录MTU、TPID和MAC学习这三个坑最磨人5.1 坑一MTU默认为1500QinQ一加4字节就超了很多人在开局时就把IP地址配好VLAN放行也做了但业务一跑大包就断小包却正常。这种半通不通的状态八成是MTU问题。QinQ给帧增加的开销是实打实的客户原本有C-VLAN标签再加S-VLAN标签整个帧会比标准1518字节的以太网最大帧多出4字节如果客户原本是无标签的普通帧那增加的是8字节。交换机接口默认MTU如果是1500字节收到这种超长帧直接丢弃。解决办法也简单在参与QinQ转发链路的设备上把接口MTU调大或者在设备系统层面开启支持超长帧、巨型帧的功能具体参数一般需要大于1504习惯上直接配置成9216或者设备支持的最大值。我见过不少故障最后都是因为在QinQ链路上少调了一个MTU值导致大文件传输和视频流全部卡顿。5.2 坑二TPID两边不一致外层标签变“乱码”TPID是识别标签类型的标志。标准802.1Q的TPID通常是0x8100而802.1ad规定的QinQ外层标签TPID是0x88a8还有一些厂商设备默认用0x9100或者其他值。如果两端设备对TPID的理解不一致就会闹出一个很有意思的现象甲方设备把某个字段识别为“外层S-VLAN标签”乙方设备却把它当成普通数据的一部分或者当成另一种标签来处理。结果就是上层业务怎么调都不通抓包看起来却都是带着VLAN的表面正常实际语义完全错位。排查方法是抓包确认外层TPID值然后逐段核对两端设备上的“TPID”配置。这个问题在跨运营商、跨厂商组网时格外常见开局前一定要和对接方对清楚别默认大家都是0x8100。毕竟有的运营商内部规范就是0x88a8。5.3 坑三MAC地址漂移QinQ把冲突藏到了外层QinQ的隔离能力建立在“外层S-VLAN MAC”的学习和转发基础上。正常情况下不同S-VLAN之间的MAC学习是互不干扰的但如果设备配置不当或者网络上有一处把S-VLAN标签剥离掉再重新学习MAC地址表就会出问题。最典型的故障场景是两个分部的客户网络里都有一台相同MAC地址的终端这台终端可能是同一个品牌型号甚至可能是克隆配置的镜像设备。如果骨干侧设备在学习MAC时没有把S-VLAN作为隔离维度二层表就会反复刷新同一个MAC对应不同端口导致流量在两个端口之间来回抖动。现象就是ping一会儿通一会儿不通业务时好时坏核心设备的CPU还可能因为MAC漂移而飙升。排查链路一般是这样先看汇聚交换机日志里有没有MAC地址在两个端口之间漂移的记录再查二层转发表里目标MAC的出口是否频繁变化最后顺着转发表找到哪些端口下出现了相同MAC。定位之后要么启用以S-VLAN为维度的MAC隔离要么在接入侧限制同一MAC只能从固定端口进入。5.4 排查链路QinQ业务不通时按什么顺序查QinQ出问题时我建议按“从边缘到核心再从核心到边缘”的顺序排查比乱抓包有效得多。最简单有效的方法是分层验证先在CE-A客户侧接口抓包确认客户原来的帧带不带C-VLAN标签不带的话从客户交换机开始查。再在CE-A上行口抓包确认外层S-VLAN是否被成功打上S-VLAN值是否和规划一致。接着在骨干交换机P抓包确认帧仍然是双层标签并且外层VLAN在骨干设备的放行列表里。最后在CE-B下行口抓包确认外层标签已经被正确剥离交到客户B手里的帧带的是客户B期望的内层VLAN。哪一步和预期不符故障点就在哪一段。我自己处理大部分QinQ故障靠的就这一套抓包思路。相比直接翻配置文件抓包更能反映真实转发路径尤其是在涉及第三方运营商设备时非常有用。6. QinQ不是终点VXLAN解决那些更难的问题6.1 QinQ和VXLAN的对比视角QinQ解决了“SWOT分析 VIN”不对是解决了单层VLAN不够使用和客户VLAN重叠的问题但它本身仍然受限于二层转发的规则。外层S-VLAN最多也只有4094个在大规模数据中心或云平台场景中这种数量级就显得不够灵活。这时候自然会转向VXLAN。VXLAN的全称是Virtual Extensible LAN它把二层数据帧封装在UDP/IP包里通过三层网络承载二层流量。VXLAN的隔离标识叫VNI有24个比特理论可以支持超过1600万个隔离网络比QinQ的外层VLAN空间大得多。两者的取舍可以粗略用一个比喻理解QinQ是在信封外面再套一个信封快递公司靠大信封上的编号转运VXLAN则是把信件放进一个带编号的塑料箱这个箱子坐飞机还是坐火车取决于underlay的IP网络路线。维度QinQVXLAN封装基础二层802.1Q标签叠加UDP/IP隧道封装隔离标识空间S-VLAN最多4094个VNI可达1600万以上对骨干网络要求二层转发或运营商协议配合需要三层IP可达配置复杂度相对低接口级配置高涉及VTEP、VNI、控制器或EVPN适用环境运营商专线、园区接入、VLAN透传数据中心互联、云环境、大规模多租户6.2 什么时候坚持用QinQ什么时候升级到VXLAN如果是传统的运营商二层专线、企业跨地域组网、楼宇多租户接入QinQ仍然是性价比最高、维护门槛最低的方案。它不需要控制面协议不需要Underlay路由设计几台接入交换机对端口做一下配置就能跑起来运维理解起来也很快。但如果网络已经变成以数据中心为枢纽骨干本身是IP路由网络业务需要在多个机房之间做二层灵活调度甚至要对接公有云私有云那么VXLAN才是更合适的方向。VXLAN的优势是能把VLAN空间和物理位置解耦业务部署在哪个机架、哪个机房不再影响二层域的设计。不过有一点很现实VXLAN虽然强大却解决不了“一个TPID不匹配就让人查半天”这种事反而因为多了VTEP、VNI、Underlay这些环节对排障能力要求更高。所以我的态度一直是能用QinQ解决的需求不急着上VXLAN只有QinQ明显不够用了再迁移到VXLAN。技术选型不是越高级越好而是越贴合当前网络形态越好。写到最后说一点我自己的实际体会。QinQ这套东西真正值钱的地方反而在开场之前。设备上敲的命令可能就三五行但外层VLAN怎么分、TPID跟对端怎么约、MTU要不要调、客户内层有哪些VLAN需要透传这些全得在方案阶段定死。我见过太多现场割接到半夜最后发现只是两边TPID不一致的情况。所以建议你动手前先画一张拓扑标注每段链路的标签形态再配合S-VLAN分配表去挨个核对端口绝大多数QinQ故障都能在设计阶段提前拦住。这个习惯比背任何一条配置命令都管用。