来自 以太网帧格式
以太帧类型
以太帧有很多种类型。不同类型的帧具有不同的格式和MTU值。但在同种物理媒体上都可同时存在。
以太网第二版[note 3] 或者称之为Ethernet II 帧，DIX帧，是最常见的帧类型。并通常直接被IP协议使用。
Novell的非标准IEEE 802.3帧变种。
IEEE 802.2 逻辑链路控制 (LLC) 帧
子网接入协议(SNAP)帧
所有四种以太帧类型都可包含一个IEEE 802.1Q选项来确定它属于哪个 VLAN 以及他的IEEE 802.1p优先级(QoS)。这个封装由IEEE 802.3ac定义并将帧大小从64字节扩充到1522字节(注：不包含7个前导字节和1个字节的帧开始符以及12个帧间距字节)。
IEEE 802.1Q标签，如果出现，需要放在源地址字段和以太类型或长度字段的中间。这个标签的前两个字节是标签协议标识符(TPID)值0x8100。这与没有标签帧的以太类型/长度字段的位置相同，所以以太类型0x8100就表示包含标签的帧，而实际的以太类型/长度字段则放在Q-标签的后面。TPID后面是两个字节的标签控制信息(TCI)。(IEEE 802.1p 优先级(QoS)和 VLAN ID)。Q标签后面就是通常的帧内容。
Ethernet II
以太 II 帧 (也称作DIX以太网，是以这个设计的主要成员，DEC,Intel和Xerox的名字命名的。[1]),把紧接在目标和源MAC地址后面的这个两字节定义为以太网帧数据类型字段。
例如，一个0x0800的以太类型说明这个帧包含的是IPv4数据报。同样的，一个0x0806的以太类型说明这个帧是一个ARP帧，0x8100说明这是一个IEEE 802.1Q帧，而0x86DD说明这是一个IPv6帧。
当这个工业界的标准通过正式的IEEE标准化过程后，在802.3标准中以太类型字段变成了一个(数据)长度字段。(最初的以太包通过包括他们的帧来确定它们的长度，而不是以一个明确的数值。)但是包的接收层仍需知道如何解析包，因此标准要求将IEEE802.2头跟在长度字段后面，定义包的类型。多年之后，802.3x-1997标准，一个802.3标准的后继版本，正式允许两种类型的数据包同时存在。实际上，两种数据包都被广泛使用，而最初的以太数据包在以太局域网中被广泛应用，因为他的简便和低开销。
为了允许一些使用以太II版本的数据报和一些使用802.3封装的最初版本的数据包能够在同一个以太网段使用，以太类型值必须大于等于1536(0x0600)。这个值比802.3数据包的最大长度1500byte (0x05DC)要更大。因此如果这个字段的值大于等于1536，则这个帧是以太II帧，而那个字段是类型字段。否则(小于1500而大于46字节)，他是一个IEEE 802.3帧，而那个字段是长度字段。1500～1536(不包含)的数值未定义。[2]
Part 2
前阵子去处理一个无线局域网的接入故障问题，组网结构是二层旁挂隧道转发组网，反映的问题是无线终端接入慢，甚至连接不上 WIFI，在查看了设备后，发现有大量的无线终端获取不到IP地址，我想问题的根本在此。
组网结构如上图，AP地址段 VLAN 和 STA 地址段 VLAN 不同，AP 的 STA 的 DHCP server 在汇聚交换机上（DHCP 的网关均设置在汇聚交换机上？），汇聚连接各楼层的非网管 PoE 交换机，查看了汇聚交换机配置，虽说是隧道转发，但连接楼层交换机的接口全放行了业务 STA 的 VLAN（我觉得这是个错误配置），
决定改直接转发，扩大 STA 地址池范围，修改租期为更短时间，手动调优一次（该单位因装修调整过线路和AP，再加上AP布放相当不合理（壁挂安装，楼层里 AP 相隔两三米斜对角线安装））
修改完配置后，问题更大了，仅有少数无线终端能获取IP正常接入，绝大多无线终端无法接入无线网络，长时间处在获取 IP 地址，然而修改成隧道转发后，可正常接入。最终排查出最大的可能性是这非网管交换机的问题，无法转发透传包含两个及以上的 802.1Q 的数据帧到汇聚交换机，这就触及本人知识盲区了，折腾了许久。
接下来有两种方案，一是修改 AP 和 STA 的地址网段和 VLAN 为同一个，二是还是使用隧道转发，第一个方案改动太大了，最终使用第二方案。
回来后一顿搜索非网管交换机的工作原理，有说非网管交换机所有口都是属于 VLAN 1 的说法，这简直是胡说八道的。有说能否转发带 VLAN tag 数据和该交换机支持转发的最大传输单元（MTU）有关系，我查了各大非网管交换机的特性参数，均没有提及这一个参数。理论上这个参数确实会影响转发，就是说非网管交换机设定了一个转发的最大帧长度，当交换机接收到大于这个设定的帧长度就丢弃不转发，毕竟支持更大帧转发意味着消耗更多的硬件资源，基于成本控制我是可以理解硬件厂商这么做的原因。而且像 Jambo frame 这种格式在我接触到的项目中毕竟小众，使用场景比标准的802.3要少的多。
也翻看了一些做了测试的网站文章，也没有一个定论说肯定支持转发或不支持转发802.1q的数据帧，看多了都使我抑郁了，更多的是论坛下的一些讨论。
长教训了，这哪怕换成工作在物理层的 HUB 都能正常工作，反而……，看来将来再遇到这种非网管PoE交换机接入的情况要相当注意了，别再踩坑了。
还有个别 AP 未上线问题，查看原因 Negotiation CAPWAP tunnel failed ，就去检查物理线路吧，特别是使用光收发这种设备的，【能不能通，能通有丢包，AP就是不上线】
Ending
- 文中可能有些内容术语表述的不规范，请见谅。
- 欢迎“
来电”来函探讨。
