尧图网站建设 
1. 为什么会有QinQ1.1 当4096个VLAN不够用的时候刚接触网络的人可能很难理解VLAN怎么还会有不够用的时候IEEE 802.1Q定义的VLAN Tag只有12个bit理论上最多4096个VLAN。这个数字看起来很充裕但放到运营商城域网、园区汇聚、专线接入这些场景里会非常尴尬。想象一下一个电信运营商要承载几十万甚至几百万个家庭宽带用户每个用户划分一个VLAN4096个根本不够分。就算一个光口下面只放几百个用户汇聚上去之后VLAN数量也会碰撞。更麻烦的是不同客户可能自己内部就用了VLAN 1到4094这些客户名下的二层流量一旦进入运营商网络所有VLAN ID都会混在一起互相冲突。QinQ802.1Q in 802.1Q也叫VLAN Stacking或VLAN嵌套就是为了解决这个问题而出现的。它的做法非常直接用户报文进来时我不关心你里面打了什么VLAN标签我只在你的标签外面再套一层运营商自己的VLAN标签。这样内层的客户VLAN ID随便怎么冲突都无所谓外层标签把不同客户隔离开。我第一次看到这个概念时觉得挺朴素的——不就是一个标签套一个标签嘛。但真到配置环境里会发现这个套字的讲究非常多套在哪一层、怎么区分客户、外层标签怎么分配、组播和DHCP报文怎么处理、环路保护怎么做每一个环节踩过的坑都能写出一堆总结。1.2 QinQ到底解决什么问题QinQ本质上是给二层网络加了一层隧道能力。注意这里我特意加了引号因为在网络术语里隧道通常指的是L2TP、GRE、VXLAN这种通过封装IP头实现的技术而QinQ并没有新增外层IP头它只是在原有以太网报文中再插入一个VLAN Tag。它承载的仍然是纯粹的以太网帧只是帧头变大了。在运营商和园区网的实际部署里QinQ主要干三个方面的事第一是VLAN数量扩容。内外两层标签各12个bit理论组合是4096×4096接近1677万个VLAN空间。虽然实际部署中不会真的有人把它用满但把客户侧VLAN和网络侧VLAN彻底分层之后4096的限制就退到了外层内层完全由客户自己控制。第二是客户隔离与安全。两个客户就算用完全相同的VLAN ID外层标签不同二层流量也不会互相串扰。运营商不需要去协调所有客户都改成不一样的VLAN号这让交接变得非常省事。第三是让客户自己的二层网络可以透明延伸到远端。比如一个企业总部和分支都在运营商网络覆盖范围内两边各有一个三层汇聚交换机中间不想跑三层路由希望像一个局域网一样二层互联那运营商可以在两个接入点分别打上同一个外层VLAN中间报文就按VLAN转发了客户感觉不到运营商网络的存在。明白了这一点你就能理解QinQ不是被发明出来炫技的它就是在VLAN数量枯竭和网络分层需求双重压力下一个给VLAN再套一层VLAN的朴素答案。2. QinQ的核心原理与报文结构2.1 两个标签是怎么叠加的先明确一个基础概念传统802.1Q报文里只有一个VLAN Tag包含TPIDTag Protocol Identifier默认0x8100和TCITag Control Information包含优先级、CFI、VLAN ID三部分。而QinQ报文里有两个VLAN Tag分内层和外层。外层标签叫Service Tag也叫S-TAG、运营商标签由运营商在接入设备上通过配置添加标识的是运营商网络里的一个业务VLAN或用户隧道。内层标签叫Customer Tag也叫C-TAG、客户标签是客户自己的交换机打上去的原生VLAN标签。客户报文进来的时候如果本身带Tag交换机根据接口工作在隧道模式还是灵活模式来决定怎么加外层标签如果本身不带Tag用户直接接了一个电脑交换机一般会给它打一个默认的客户VLAN然后再套外层。在实际抓包时你会看到这种报文结构以太网目的MAC加源MAC后面跟两个VLAN Tag然后才是EtherType0x0800表示IPv40x0806表示ARP再往后是IP头和数据。需要特别注意的是标准802.1ad也就是IEEE在2006年前后发布的QinQ标准规定外层TPID用0x88a8内层保留0x8100。但很多厂商设备默认的隧道封装还是外层0x8100跟传统单层VLAN报文混在一起。所以排查问题时别一看两个0x8100就懵了要先确认设备的封装模式。说到TCP/IP里的术语in这个说法很形象——一个802.1Q的帧里面再塞了一个802.1Q的帧。从逻辑上来看客户侧感知到的是自己的VLAN空间而运营商侧感知到的是外层S-VLAN空间。两者解耦彼此不需要知道对方的VLAN规划。2.2 报文长度、MTU与分片问题QinQ报文比普通帧多了一个4字节的标签所以在很多老设备上会碰到一个很隐蔽的问题接口MTU默认是1500字节客户发来的一个帧如果是1504字节已经带了一个Tag接入交换机再套一层4字节就变成1508字节。如果中间设备只认1500直接丢帧表现为典型的小包通、大包不通。这个坑在真实环境里特别常见。很多运维排查了两三天最后发现是接口MTU不一致导致的。规避办法通常是两层同时调整加入外层标签前的路径上客户侧交换机尽量把MTU改为至少1504甚至更大运营商接入设备到汇聚设备这一段尽量把所有接口的MTU统一调成不低于1522字节即1500字节普通帧加两个Tag。如果中间还要叠加PPPoE之类的协议头还得再留余量。更保险的办法是在客户侧三层设备上调整IP MTU或者开启TCP MSS clamping。但是二层透传场景下很多报文是组播、广播没法用TCP MSS去规避所以调大接口MTU才是根本方案。3. QinQ的两种实现方式端口模式与灵活模式3.1 端口模式Port-based QinQ端口模式也叫基本QinQBasic QinQ是所有支持QinQ的设备都具备的能力也是门槛最低的一种。配置逻辑一句话就能讲清楚在接入设备的这个接口上开启QinQ隧道功能凡是这个接口进来的报文不管里面带了什么VLAN标签统一在外面打一层指定的外层VLAN标签。这种方式适合接入侧边界特别清晰的场景。比如一个客户的接入端口只接了一个客户那这个端口进来的流量全都归属同一个外层VLAN根本不需要做区分。对应到实际操作里就是端口Port模式常见的厂商产品线一般是一条命令就能开启。端口模式的好处是转发快、配置简单、消耗资源少。它不用去查内层VLAN所以对交换芯片的处理压力很小。但它的缺点同样明显同一条物理链路如果有多个客户环境端口模式下无法区分这些客户只能对端口内所有流量套同一个外层标签客户隔离根本无从谈起。所以端口模式用的是端口作为客户边界而不是VLAN。哪些场景适合端口模式呢我接触过的实际案例里最常见的是FTTH接入。一个OLT的PON口下面挂了多个家庭用户每个家庭用户通过一台光猫接入运营商在OLT或者上层汇聚交换机上给一个PON口下所有用户分配同一外层VLAN把不同家庭隔离到不同QinQ路径。因为家庭用户体量小、业务简单上网、IPTV、语音一个外层VLAN就能覆盖。3.2 灵活QinQFlex QinQ / Selective QinQ端口模式的局限逼出了灵活QinQ。灵活模式一般基于三层维度做外层标签映射可以按照内层VLAN的编号、报文的802.1p优先级、源MAC、甚至ACL匹配结果来给进来的报文打上不同的外层VLAN标签。最常见的需求是一个接入端口上接了一个客户的交换机客户交换机里同时跑了办公网VLAN 10、监控网VLAN 20、语音网VLAN 30客户希望运营商分别套上外层VLAN 100、200、300方便后面的三层网关之间做隔离和策略。如果用端口模式VLAN 10/20/30全都套同一个外层标签到汇聚设备上就没法区分业务类型了。改用灵活模式按内层VLAN映射就可以实现同一个物理端口进来的流量按内层VLAN进入不同外层VLAN管道。灵活QinQ在运营商大客户专线接入中非常普遍。比如一个写字楼里的企业客户运营商给他一根物理光纤这个企业内部又有多个独立部门或子公司各自VLAN规划完全独立。运营商如果想要细分服务等级或独立计费灵活QinQ就派上用场了。实际配置的时候要注意灵活QinQ匹配的是报文进入设备时的原始内层标签这个标签可能来自客户交换机也可能来自客户下面的终端通过802.1Q直接打的标签。配置错误最常见的原因就是把映射的触发条件理解错了——你以为配的是从外层映射其实设备是从内层映射的。4. 配置实操与典型场景搭建4.1 华为设备的基本QinQ配置这里用华为的VRP平台举例交换机型号无关紧要比如S系列都能用。假设接入交换机叫SW_A汇聚交换机叫SW_B客户的二层交换机接在SW_A的GE0/0/1口上客户内部有VLAN 10和VLAN 20运营商规划给这个客户的外层VLAN是100。SW_A上做基本QinQ接口配置如下interface GigabitEthernet0/0/1 port link-type dot1q-tunnel port default vlan 100 dot1q-tunnel enable这段配置里port link-type dot1q-tunnel把端口改成隧道模式port default vlan 100指定外层VLAN的编号dot1q-tunnel enable开启QinQ封装。配置完以后从GE0/0/1进来的所有报文只要是带Tag的都会在原有标签外面再加一层Tag 100。你说那不带Tag的报文怎么办在dot1q-tunnel模式下不带Tag的报文会被打上port default vlan指定的VLAN ID作为单层标签也就是说默认情况下它不会给你套两层。如果希望未打标签的报文也套上外层标签部分产品形态下要继续开启两层穿透或untagged处理。我在实际调试中的习惯是先让客户侧把所有端口都设置成Access或Trunk并强制打Tag然后运营商这边只关注带Tag报文的QinQ效果。SW_A往SW_B方向的链路配置成Trunk放行外层VLAN 100interface GigabitEthernet0/0/24 port link-type trunk port trunk allow-pass vlan 100这里有一个容易被忽略的点Trunk口放行的VLAN必须是外层VLAN ID不是客户的内层VLAN。因为报文在进入Trunk口之前已经带上了双层标签Trunk口看到的只有外层。如果只放行了VLAN 10和20而没放行VLAN 100那QinQ报文全都被过滤掉了表现为完全不通。4.2 华为设备的灵活QinQ配置灵活QinQ在华为上常用qinq mapping或vlan-translation实现。以按内层VLAN映射为例interface GigabitEthernet0/0/1 port link-type hybrid port hybrid untagged vlan 300 qinq mapping vlan 10 inner-vlan 10 service-vlan 300 qinq mapping vlan 30 inner-vlan 30 service-vlan 400这段配置表示从该接口进来的报文如果内层VLAN是10就封装外层VLAN 300如果内层VLAN是30就封装外层VLAN 400。做灵活QinQ之前务必要确认设备型号与软件版本是否支持。很多盒式交换机在低版本上只支持固定端口模式不支持按内层VLAN映射。如果不支持就只能通过升级软件或换用框式设备来满足需求不要在现场硬配。另外灵活QinQ的映射表项数量是有限的一个端口支持几百到几千条映射不等。做整个城域网规划时要对客户数量、每个客户的VLAN数量做一个上限评估。别到验收时突然发现映射表项超了又得重新设计。4.3 思科与常见二线品牌配置参考思科的QinQ配置叫dot1q-tunnel早年或service instance新的EVC模型。老的接入交换机上配置如下interface FastEthernet0/1 switchport access vlan 100 switchport mode dot1q-tunnel这就是端口模式把端口作为隧道口进来的报文统一打外层VLAN 100。启用后还需要在Spanning Tree上做处理spanning-tree bpdufilter enable否则客户侧的STP报文会干扰运营商网络。思科新平台更推荐用EVC模型interface GigabitEthernet1/0/1 service instance 10 ethernet encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric bridge-domain 100rewrite ingress tag pop 1 symmetric表示进来的报文剥掉一层客户标签后进入业务域对称方向则再打回来。这套理念更像封装/解封装比起老式dot1q-tunnel更灵活。其他品牌里面锐捷、H3C、中兴的配置命令基本与华为同源都是port link-type dot1q-tunnel加dot1q-tunnel enable的路子没有太大学习成本。真正要注意的是每个厂家的外层VLAN默认值和Tag处理方式有细微差异建议在测试环境先跑一遍报文头确认封装结果。5. 部署QinQ时必须重视的几个隐患5.1 TPID引发的抓包误会TPIDTag Protocol Identifier用来标识VLAN标签的类型。标准QinQ外层标签的TPID是0x88a8内层标签是0x8100。但很多设备为了兼容老交换机默认外层TPID还是0x8100。这样一来抓包就会看到两个连续的0x8100标签很多人误以为客户报文打了两个普通VLAN其实一个已经算外层了。判断技巧很简单如果一个报文里连续出现两个VLAN头第一个VLAN头的TPID如果是0x88a8或者厂商自定义的0x9100、0x9200之类铁定是QinQ如果两个都是0x8100则要看第一个标签里的VLAN ID是不是运营商规划的S-VLAN。这个细节在现网排查中高压线级别别搞混。某些运营商网络里还会出现0x9100这种TPID这是当年各厂商为扩展标签而搞的自定义实现后来被802.1ad标准化为0x88a8。如果你在一片区域里混用多种厂商设备一定要把所有设备的TPID配置统一否则外层标签封装出来不兼容两侧设备都会解析失败。5.2 广播域放大与MAC学习QinQ把不同客户隔离到不同的外层VLAN从这个角度看它抑制了广播域。但另一个层面同一个外层VLAN里面的所有报文共享一个广播域。在运营商的接入汇聚网上一个外层VLAN如果挂了几百个家庭客户任何一个客户发出的ARP广播都会被交换机在整个外层VLAN范围内泛洪客户A甚至能看到客户B的MAC地址和IP地址在做ARP询问。这个坑在开通初期不明显因为用户量少。等用户量上去组播、ARP风暴、未知单播泛洪都会指数级增长。所以运营商层面的规划设计一定要控制每个外层VLAN内承载的客户数量。建议的做法是每个外层VLAN最多承载几十到一百个客户不要贪多否则一个客户端私接交换机产生环路就会拖垮整片区域所有同S-VLAN用户的网络。从MAC学习角度讲QinQ的MAC表项是关联在外层VLAN下的。客户交换机学习的是内层VLAN的MAC对应端口运营商交换机学习的是外层VLAN下MAC对应端口。这两层网络设备学习的表项互不干扰。5.3 安全功能失效的风险DHCP Snooping、IP Source Guard、Dynamic ARP Inspection这些安全特性都是基于哪一个接入端口能发出什么报文来工作的。在QinQ隧道模式下接入端口看到的是客户发出的原始报文但报文到了汇聚设备后源MAC和源IP没变VLAN却变了。如果安全策略写的是某个VLAN下的MAC可信任在自定义VLAN映射不匹配时可能直接放行或直接误杀需要逐一适配。典型做法是把安全信任边界往外放一层全部放在客户接入的隧道口上做而上联方向信任来自客户侧的报文。风险在于如果客户侧有设备被攻陷伪造任意MAC或IP运营商侧很难拦截这就是QinQ方案的固有弱点之一。如果环境对安全等级要求较高建议的选择是不要走纯QinQ透传而是在客户接入点直接用三层路由汇聚或者采用VXLAN Overlay至少你的VXLAN VNI概念还能跟云网络无缝对接安全策略也好部署。6. QinQ故障排查实录6.1 两边通不了可能卡在哪我前面说过的案例里最典型的QinQ不通有五种情况外层VLAN没有放行客户内部VLAN 10和20都通了但运营商Trunk口没放行外层VLAN 100于是QinQ报文直接被过滤。排查时先看接入设备上联口的Trunk放行列表。内层VLAN与外层VLAN重号客户内层用了VLAN 100运营商外层也用了VLAN 100某些设备的映射表会解析冲突出现丢包或转发异常。解决办法是规划时外层VLAN段独立隔离比如专门划一块S-VLAN段禁止客户内层与之冲突或者不冲突时也要明确区分映射关系。上行口与下行口模式不一致接入端口做了dot1q-tunnel上联口却还是Access报文没法正常进Trunk链路。一定要把上联口改成Trunk并且放行对应外层VLAN。MTU不够客户侧1500字节大包在两层标签加持下超过中间链路MTU产生丢包。典型表现就是小包能通、Ping大包不通或者传输大文件卡顿。STP/RSTP没关干净客户侧的生成树报文跑到运营商网络后被交换机学习到异常路径回程流量绕路或直接被丢弃。一般业务口关闭STP或配置BPDU Filter。6.2 客户设备能通组播和DHCP有问题QinQ层层封装后组播也会有收敛问题。IPTV业务普遍要用到组播而组播转发依赖特定表项如果外层S-VLAN的组播行为没有设计好客户会看到VOD点播正常但直播频道非常卡或直接黑屏。经验做法是在汇聚层单独规划组播标签比如给视频业务一个独立的S-VLAN段并且在汇聚设备上对组播流量单独做复制与转发不要跟普通数据流量混用外层标签。DHCP的问题更常见。QinQ链路下客户主机发出DHCP Discover广播DHCP服务器回包时怎么知道应该往哪个S-VLAN回标准做法是使用DHCP Relay并在中继时把外层VLAN信息带在Option 82里服务器根据Option 82里的电路ID确定用户位置再通过中继把Offer返回给相应S-VLAN。如果不加Relay直接让DHCP服务器接在交换机上服务器根本不知道多了一层标签容易导致地址分配失败。在实际工程项目中我最常提醒的一句话就是QinQ不是把两层标签加上去就完事了业务层面的DHCP、组播、STP、链路层安全全都要跟着重新设计和验证。7. QinQ与后续Overlay技术的关系7.1 QinQ与PBBMAC-in-MAC的取舍QinQ能够隔离用户的VLAN但它并不能隔离用户的MAC地址。两个客户如果内部MAC地址空间产生了冲突比如两边都有一个伪造出来的MAC对应到了不同主机在运营商网络里仍然会出现学习混乱。为了把MAC地址也隔离开IEEE提出了802.1ah也就是PBBProvider Backbone Bridge俗称MAC-in-MAC。PBB在QinQ的外层标签之上再套一个运营商骨干MAC地址和骨干VLAN这样运营商网络只学习到客户边缘设备的骨干MAC根本看不到客户内部主机的MAC。相比QinQPBB的隔离能力更彻底但带来的协议复杂度和设备成本也更高。现在在电信级以太网里PBB的部署范围远远不如QinQ。原因很简单大多数客户的MAC冲突概率在真实环境中并不高用QinQ就够用了而PBB需要全网一致的设备和运维经验中小网络扛不住。7.2 数据中心里的VXLAN为什么更香数据中心场景下VXLAN基本取代了QinQ作为大二层承载技术。VXLAN把二层帧封装在UDP/IP里面VNI有24位理论隔离数量1600万远大于QinQ的两层VLAN组合。VXLAN还能跨三层物理网络传输而QinQ只能在二层链路里传递。但VXLAN不是万能的它需要Underlay IP网络就绪对设备性能要求也高。很多园区网和运营商汇聚网根本没有完整的IP Fabric基础如果只是为了做二层透传硬上VXLAN反而舍本逐末。这也是为什么直到今天园区汇聚和城域专线里QinQ依然大量存在有它的合理性。从我个人的技术选型观感来说数据中心内部优先考虑VXLAN广域/城域二层专线/接入网优先考虑QinQ它们两个并不是替代关系而是服务不同层次的网络。8. 最后分享几个我自己的实战经验说几个真实踩过坑的经验。第一个是关于STP的。QinQ隧道模式下客户侧交换机如果跑了STPBPDU报文进入运营商网络后运营商交换机如果不做过滤处理STP根桥很容易跨过运营商网络互相影响最终导致两栋楼的业务在几台汇聚设备上出现环路震荡。不管配置文档里有没有写我建议所有隧道口上都开BPDU Filter就算客户封装了BPDU也直接丢掉把生成树隔离在客户侧。第二个是关于外层VLAN规划的。给客户分S-VLAN时不要按客户名称或者IP段去拍脑袋分配要按接入位置或物理链路来分。不然以后做故障定位时你看到外层VLAN却查不到它的地理位置整个排查链路都要多走好几步。第三个是关于抓包习惯的。很多人配置完QinQ后不抓包以为数据通了就完事了。我建议无论通不通都在接入端口和汇聚端口各抓一次包确认标签的TPID、内外层VLAN ID、优先级字段是否符合预期。一次抓包能帮你发现TPID不兼容、映射配置反了、带里和没带里的问题不要省这个时间。QinQ在很长一段时间里就是电信级二层网络的事实标准。哪怕今天有更多花哨的技术理解QinQ的报文结构、映射逻辑和各种隐含问题对任何一个做网络的人都是必修课。这个东西不复杂但是细节极多越多接触现网越能感受到里面的设计智慧。 QinQ技术详解：VLAN嵌套原理、配置与故障排查实战
1. 为什么会有QinQ1.1 当4096个VLAN不够用的时候刚接触网络的人可能很难理解VLAN怎么还会有不够用的时候IEEE 802.1Q定义的VLAN Tag只有12个bit理论上最多4096个VLAN。这个数字看起来很充裕但放到运营商城域网、园区汇聚、专线接入这些场景里会非常尴尬。想象一下一个电信运营商要承载几十万甚至几百万个家庭宽带用户每个用户划分一个VLAN4096个根本不够分。就算一个光口下面只放几百个用户汇聚上去之后VLAN数量也会碰撞。更麻烦的是不同客户可能自己内部就用了VLAN 1到4094这些客户名下的二层流量一旦进入运营商网络所有VLAN ID都会混在一起互相冲突。QinQ802.1Q in 802.1Q也叫VLAN Stacking或VLAN嵌套就是为了解决这个问题而出现的。它的做法非常直接用户报文进来时我不关心你里面打了什么VLAN标签我只在你的标签外面再套一层运营商自己的VLAN标签。这样内层的客户VLAN ID随便怎么冲突都无所谓外层标签把不同客户隔离开。我第一次看到这个概念时觉得挺朴素的——不就是一个标签套一个标签嘛。但真到配置环境里会发现这个套字的讲究非常多套在哪一层、怎么区分客户、外层标签怎么分配、组播和DHCP报文怎么处理、环路保护怎么做每一个环节踩过的坑都能写出一堆总结。1.2 QinQ到底解决什么问题QinQ本质上是给二层网络加了一层隧道能力。注意这里我特意加了引号因为在网络术语里隧道通常指的是L2TP、GRE、VXLAN这种通过封装IP头实现的技术而QinQ并没有新增外层IP头它只是在原有以太网报文中再插入一个VLAN Tag。它承载的仍然是纯粹的以太网帧只是帧头变大了。在运营商和园区网的实际部署里QinQ主要干三个方面的事第一是VLAN数量扩容。内外两层标签各12个bit理论组合是4096×4096接近1677万个VLAN空间。虽然实际部署中不会真的有人把它用满但把客户侧VLAN和网络侧VLAN彻底分层之后4096的限制就退到了外层内层完全由客户自己控制。第二是客户隔离与安全。两个客户就算用完全相同的VLAN ID外层标签不同二层流量也不会互相串扰。运营商不需要去协调所有客户都改成不一样的VLAN号这让交接变得非常省事。第三是让客户自己的二层网络可以透明延伸到远端。比如一个企业总部和分支都在运营商网络覆盖范围内两边各有一个三层汇聚交换机中间不想跑三层路由希望像一个局域网一样二层互联那运营商可以在两个接入点分别打上同一个外层VLAN中间报文就按VLAN转发了客户感觉不到运营商网络的存在。明白了这一点你就能理解QinQ不是被发明出来炫技的它就是在VLAN数量枯竭和网络分层需求双重压力下一个给VLAN再套一层VLAN的朴素答案。2. QinQ的核心原理与报文结构2.1 两个标签是怎么叠加的先明确一个基础概念传统802.1Q报文里只有一个VLAN Tag包含TPIDTag Protocol Identifier默认0x8100和TCITag Control Information包含优先级、CFI、VLAN ID三部分。而QinQ报文里有两个VLAN Tag分内层和外层。外层标签叫Service Tag也叫S-TAG、运营商标签由运营商在接入设备上通过配置添加标识的是运营商网络里的一个业务VLAN或用户隧道。内层标签叫Customer Tag也叫C-TAG、客户标签是客户自己的交换机打上去的原生VLAN标签。客户报文进来的时候如果本身带Tag交换机根据接口工作在隧道模式还是灵活模式来决定怎么加外层标签如果本身不带Tag用户直接接了一个电脑交换机一般会给它打一个默认的客户VLAN然后再套外层。在实际抓包时你会看到这种报文结构以太网目的MAC加源MAC后面跟两个VLAN Tag然后才是EtherType0x0800表示IPv40x0806表示ARP再往后是IP头和数据。需要特别注意的是标准802.1ad也就是IEEE在2006年前后发布的QinQ标准规定外层TPID用0x88a8内层保留0x8100。但很多厂商设备默认的隧道封装还是外层0x8100跟传统单层VLAN报文混在一起。所以排查问题时别一看两个0x8100就懵了要先确认设备的封装模式。说到TCP/IP里的术语in这个说法很形象——一个802.1Q的帧里面再塞了一个802.1Q的帧。从逻辑上来看客户侧感知到的是自己的VLAN空间而运营商侧感知到的是外层S-VLAN空间。两者解耦彼此不需要知道对方的VLAN规划。2.2 报文长度、MTU与分片问题QinQ报文比普通帧多了一个4字节的标签所以在很多老设备上会碰到一个很隐蔽的问题接口MTU默认是1500字节客户发来的一个帧如果是1504字节已经带了一个Tag接入交换机再套一层4字节就变成1508字节。如果中间设备只认1500直接丢帧表现为典型的小包通、大包不通。这个坑在真实环境里特别常见。很多运维排查了两三天最后发现是接口MTU不一致导致的。规避办法通常是两层同时调整加入外层标签前的路径上客户侧交换机尽量把MTU改为至少1504甚至更大运营商接入设备到汇聚设备这一段尽量把所有接口的MTU统一调成不低于1522字节即1500字节普通帧加两个Tag。如果中间还要叠加PPPoE之类的协议头还得再留余量。更保险的办法是在客户侧三层设备上调整IP MTU或者开启TCP MSS clamping。但是二层透传场景下很多报文是组播、广播没法用TCP MSS去规避所以调大接口MTU才是根本方案。3. QinQ的两种实现方式端口模式与灵活模式3.1 端口模式Port-based QinQ端口模式也叫基本QinQBasic QinQ是所有支持QinQ的设备都具备的能力也是门槛最低的一种。配置逻辑一句话就能讲清楚在接入设备的这个接口上开启QinQ隧道功能凡是这个接口进来的报文不管里面带了什么VLAN标签统一在外面打一层指定的外层VLAN标签。这种方式适合接入侧边界特别清晰的场景。比如一个客户的接入端口只接了一个客户那这个端口进来的流量全都归属同一个外层VLAN根本不需要做区分。对应到实际操作里就是端口Port模式常见的厂商产品线一般是一条命令就能开启。端口模式的好处是转发快、配置简单、消耗资源少。它不用去查内层VLAN所以对交换芯片的处理压力很小。但它的缺点同样明显同一条物理链路如果有多个客户环境端口模式下无法区分这些客户只能对端口内所有流量套同一个外层标签客户隔离根本无从谈起。所以端口模式用的是端口作为客户边界而不是VLAN。哪些场景适合端口模式呢我接触过的实际案例里最常见的是FTTH接入。一个OLT的PON口下面挂了多个家庭用户每个家庭用户通过一台光猫接入运营商在OLT或者上层汇聚交换机上给一个PON口下所有用户分配同一外层VLAN把不同家庭隔离到不同QinQ路径。因为家庭用户体量小、业务简单上网、IPTV、语音一个外层VLAN就能覆盖。3.2 灵活QinQFlex QinQ / Selective QinQ端口模式的局限逼出了灵活QinQ。灵活模式一般基于三层维度做外层标签映射可以按照内层VLAN的编号、报文的802.1p优先级、源MAC、甚至ACL匹配结果来给进来的报文打上不同的外层VLAN标签。最常见的需求是一个接入端口上接了一个客户的交换机客户交换机里同时跑了办公网VLAN 10、监控网VLAN 20、语音网VLAN 30客户希望运营商分别套上外层VLAN 100、200、300方便后面的三层网关之间做隔离和策略。如果用端口模式VLAN 10/20/30全都套同一个外层标签到汇聚设备上就没法区分业务类型了。改用灵活模式按内层VLAN映射就可以实现同一个物理端口进来的流量按内层VLAN进入不同外层VLAN管道。灵活QinQ在运营商大客户专线接入中非常普遍。比如一个写字楼里的企业客户运营商给他一根物理光纤这个企业内部又有多个独立部门或子公司各自VLAN规划完全独立。运营商如果想要细分服务等级或独立计费灵活QinQ就派上用场了。实际配置的时候要注意灵活QinQ匹配的是报文进入设备时的原始内层标签这个标签可能来自客户交换机也可能来自客户下面的终端通过802.1Q直接打的标签。配置错误最常见的原因就是把映射的触发条件理解错了——你以为配的是从外层映射其实设备是从内层映射的。4. 配置实操与典型场景搭建4.1 华为设备的基本QinQ配置这里用华为的VRP平台举例交换机型号无关紧要比如S系列都能用。假设接入交换机叫SW_A汇聚交换机叫SW_B客户的二层交换机接在SW_A的GE0/0/1口上客户内部有VLAN 10和VLAN 20运营商规划给这个客户的外层VLAN是100。SW_A上做基本QinQ接口配置如下interface GigabitEthernet0/0/1 port link-type dot1q-tunnel port default vlan 100 dot1q-tunnel enable这段配置里port link-type dot1q-tunnel把端口改成隧道模式port default vlan 100指定外层VLAN的编号dot1q-tunnel enable开启QinQ封装。配置完以后从GE0/0/1进来的所有报文只要是带Tag的都会在原有标签外面再加一层Tag 100。你说那不带Tag的报文怎么办在dot1q-tunnel模式下不带Tag的报文会被打上port default vlan指定的VLAN ID作为单层标签也就是说默认情况下它不会给你套两层。如果希望未打标签的报文也套上外层标签部分产品形态下要继续开启两层穿透或untagged处理。我在实际调试中的习惯是先让客户侧把所有端口都设置成Access或Trunk并强制打Tag然后运营商这边只关注带Tag报文的QinQ效果。SW_A往SW_B方向的链路配置成Trunk放行外层VLAN 100interface GigabitEthernet0/0/24 port link-type trunk port trunk allow-pass vlan 100这里有一个容易被忽略的点Trunk口放行的VLAN必须是外层VLAN ID不是客户的内层VLAN。因为报文在进入Trunk口之前已经带上了双层标签Trunk口看到的只有外层。如果只放行了VLAN 10和20而没放行VLAN 100那QinQ报文全都被过滤掉了表现为完全不通。4.2 华为设备的灵活QinQ配置灵活QinQ在华为上常用qinq mapping或vlan-translation实现。以按内层VLAN映射为例interface GigabitEthernet0/0/1 port link-type hybrid port hybrid untagged vlan 300 qinq mapping vlan 10 inner-vlan 10 service-vlan 300 qinq mapping vlan 30 inner-vlan 30 service-vlan 400这段配置表示从该接口进来的报文如果内层VLAN是10就封装外层VLAN 300如果内层VLAN是30就封装外层VLAN 400。做灵活QinQ之前务必要确认设备型号与软件版本是否支持。很多盒式交换机在低版本上只支持固定端口模式不支持按内层VLAN映射。如果不支持就只能通过升级软件或换用框式设备来满足需求不要在现场硬配。另外灵活QinQ的映射表项数量是有限的一个端口支持几百到几千条映射不等。做整个城域网规划时要对客户数量、每个客户的VLAN数量做一个上限评估。别到验收时突然发现映射表项超了又得重新设计。4.3 思科与常见二线品牌配置参考思科的QinQ配置叫dot1q-tunnel早年或service instance新的EVC模型。老的接入交换机上配置如下interface FastEthernet0/1 switchport access vlan 100 switchport mode dot1q-tunnel这就是端口模式把端口作为隧道口进来的报文统一打外层VLAN 100。启用后还需要在Spanning Tree上做处理spanning-tree bpdufilter enable否则客户侧的STP报文会干扰运营商网络。思科新平台更推荐用EVC模型interface GigabitEthernet1/0/1 service instance 10 ethernet encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric bridge-domain 100rewrite ingress tag pop 1 symmetric表示进来的报文剥掉一层客户标签后进入业务域对称方向则再打回来。这套理念更像封装/解封装比起老式dot1q-tunnel更灵活。其他品牌里面锐捷、H3C、中兴的配置命令基本与华为同源都是port link-type dot1q-tunnel加dot1q-tunnel enable的路子没有太大学习成本。真正要注意的是每个厂家的外层VLAN默认值和Tag处理方式有细微差异建议在测试环境先跑一遍报文头确认封装结果。5. 部署QinQ时必须重视的几个隐患5.1 TPID引发的抓包误会TPIDTag Protocol Identifier用来标识VLAN标签的类型。标准QinQ外层标签的TPID是0x88a8内层标签是0x8100。但很多设备为了兼容老交换机默认外层TPID还是0x8100。这样一来抓包就会看到两个连续的0x8100标签很多人误以为客户报文打了两个普通VLAN其实一个已经算外层了。判断技巧很简单如果一个报文里连续出现两个VLAN头第一个VLAN头的TPID如果是0x88a8或者厂商自定义的0x9100、0x9200之类铁定是QinQ如果两个都是0x8100则要看第一个标签里的VLAN ID是不是运营商规划的S-VLAN。这个细节在现网排查中高压线级别别搞混。某些运营商网络里还会出现0x9100这种TPID这是当年各厂商为扩展标签而搞的自定义实现后来被802.1ad标准化为0x88a8。如果你在一片区域里混用多种厂商设备一定要把所有设备的TPID配置统一否则外层标签封装出来不兼容两侧设备都会解析失败。5.2 广播域放大与MAC学习QinQ把不同客户隔离到不同的外层VLAN从这个角度看它抑制了广播域。但另一个层面同一个外层VLAN里面的所有报文共享一个广播域。在运营商的接入汇聚网上一个外层VLAN如果挂了几百个家庭客户任何一个客户发出的ARP广播都会被交换机在整个外层VLAN范围内泛洪客户A甚至能看到客户B的MAC地址和IP地址在做ARP询问。这个坑在开通初期不明显因为用户量少。等用户量上去组播、ARP风暴、未知单播泛洪都会指数级增长。所以运营商层面的规划设计一定要控制每个外层VLAN内承载的客户数量。建议的做法是每个外层VLAN最多承载几十到一百个客户不要贪多否则一个客户端私接交换机产生环路就会拖垮整片区域所有同S-VLAN用户的网络。从MAC学习角度讲QinQ的MAC表项是关联在外层VLAN下的。客户交换机学习的是内层VLAN的MAC对应端口运营商交换机学习的是外层VLAN下MAC对应端口。这两层网络设备学习的表项互不干扰。5.3 安全功能失效的风险DHCP Snooping、IP Source Guard、Dynamic ARP Inspection这些安全特性都是基于哪一个接入端口能发出什么报文来工作的。在QinQ隧道模式下接入端口看到的是客户发出的原始报文但报文到了汇聚设备后源MAC和源IP没变VLAN却变了。如果安全策略写的是某个VLAN下的MAC可信任在自定义VLAN映射不匹配时可能直接放行或直接误杀需要逐一适配。典型做法是把安全信任边界往外放一层全部放在客户接入的隧道口上做而上联方向信任来自客户侧的报文。风险在于如果客户侧有设备被攻陷伪造任意MAC或IP运营商侧很难拦截这就是QinQ方案的固有弱点之一。如果环境对安全等级要求较高建议的选择是不要走纯QinQ透传而是在客户接入点直接用三层路由汇聚或者采用VXLAN Overlay至少你的VXLAN VNI概念还能跟云网络无缝对接安全策略也好部署。6. QinQ故障排查实录6.1 两边通不了可能卡在哪我前面说过的案例里最典型的QinQ不通有五种情况外层VLAN没有放行客户内部VLAN 10和20都通了但运营商Trunk口没放行外层VLAN 100于是QinQ报文直接被过滤。排查时先看接入设备上联口的Trunk放行列表。内层VLAN与外层VLAN重号客户内层用了VLAN 100运营商外层也用了VLAN 100某些设备的映射表会解析冲突出现丢包或转发异常。解决办法是规划时外层VLAN段独立隔离比如专门划一块S-VLAN段禁止客户内层与之冲突或者不冲突时也要明确区分映射关系。上行口与下行口模式不一致接入端口做了dot1q-tunnel上联口却还是Access报文没法正常进Trunk链路。一定要把上联口改成Trunk并且放行对应外层VLAN。MTU不够客户侧1500字节大包在两层标签加持下超过中间链路MTU产生丢包。典型表现就是小包能通、Ping大包不通或者传输大文件卡顿。STP/RSTP没关干净客户侧的生成树报文跑到运营商网络后被交换机学习到异常路径回程流量绕路或直接被丢弃。一般业务口关闭STP或配置BPDU Filter。6.2 客户设备能通组播和DHCP有问题QinQ层层封装后组播也会有收敛问题。IPTV业务普遍要用到组播而组播转发依赖特定表项如果外层S-VLAN的组播行为没有设计好客户会看到VOD点播正常但直播频道非常卡或直接黑屏。经验做法是在汇聚层单独规划组播标签比如给视频业务一个独立的S-VLAN段并且在汇聚设备上对组播流量单独做复制与转发不要跟普通数据流量混用外层标签。DHCP的问题更常见。QinQ链路下客户主机发出DHCP Discover广播DHCP服务器回包时怎么知道应该往哪个S-VLAN回标准做法是使用DHCP Relay并在中继时把外层VLAN信息带在Option 82里服务器根据Option 82里的电路ID确定用户位置再通过中继把Offer返回给相应S-VLAN。如果不加Relay直接让DHCP服务器接在交换机上服务器根本不知道多了一层标签容易导致地址分配失败。在实际工程项目中我最常提醒的一句话就是QinQ不是把两层标签加上去就完事了业务层面的DHCP、组播、STP、链路层安全全都要跟着重新设计和验证。7. QinQ与后续Overlay技术的关系7.1 QinQ与PBBMAC-in-MAC的取舍QinQ能够隔离用户的VLAN但它并不能隔离用户的MAC地址。两个客户如果内部MAC地址空间产生了冲突比如两边都有一个伪造出来的MAC对应到了不同主机在运营商网络里仍然会出现学习混乱。为了把MAC地址也隔离开IEEE提出了802.1ah也就是PBBProvider Backbone Bridge俗称MAC-in-MAC。PBB在QinQ的外层标签之上再套一个运营商骨干MAC地址和骨干VLAN这样运营商网络只学习到客户边缘设备的骨干MAC根本看不到客户内部主机的MAC。相比QinQPBB的隔离能力更彻底但带来的协议复杂度和设备成本也更高。现在在电信级以太网里PBB的部署范围远远不如QinQ。原因很简单大多数客户的MAC冲突概率在真实环境中并不高用QinQ就够用了而PBB需要全网一致的设备和运维经验中小网络扛不住。7.2 数据中心里的VXLAN为什么更香数据中心场景下VXLAN基本取代了QinQ作为大二层承载技术。VXLAN把二层帧封装在UDP/IP里面VNI有24位理论隔离数量1600万远大于QinQ的两层VLAN组合。VXLAN还能跨三层物理网络传输而QinQ只能在二层链路里传递。但VXLAN不是万能的它需要Underlay IP网络就绪对设备性能要求也高。很多园区网和运营商汇聚网根本没有完整的IP Fabric基础如果只是为了做二层透传硬上VXLAN反而舍本逐末。这也是为什么直到今天园区汇聚和城域专线里QinQ依然大量存在有它的合理性。从我个人的技术选型观感来说数据中心内部优先考虑VXLAN广域/城域二层专线/接入网优先考虑QinQ它们两个并不是替代关系而是服务不同层次的网络。8. 最后分享几个我自己的实战经验说几个真实踩过坑的经验。第一个是关于STP的。QinQ隧道模式下客户侧交换机如果跑了STPBPDU报文进入运营商网络后运营商交换机如果不做过滤处理STP根桥很容易跨过运营商网络互相影响最终导致两栋楼的业务在几台汇聚设备上出现环路震荡。不管配置文档里有没有写我建议所有隧道口上都开BPDU Filter就算客户封装了BPDU也直接丢掉把生成树隔离在客户侧。第二个是关于外层VLAN规划的。给客户分S-VLAN时不要按客户名称或者IP段去拍脑袋分配要按接入位置或物理链路来分。不然以后做故障定位时你看到外层VLAN却查不到它的地理位置整个排查链路都要多走好几步。第三个是关于抓包习惯的。很多人配置完QinQ后不抓包以为数据通了就完事了。我建议无论通不通都在接入端口和汇聚端口各抓一次包确认标签的TPID、内外层VLAN ID、优先级字段是否符合预期。一次抓包能帮你发现TPID不兼容、映射配置反了、带里和没带里的问题不要省这个时间。QinQ在很长一段时间里就是电信级二层网络的事实标准。哪怕今天有更多花哨的技术理解QinQ的报文结构、映射逻辑和各种隐含问题对任何一个做网络的人都是必修课。这个东西不复杂但是细节极多越多接触现网越能感受到里面的设计智慧。