STP BPDU帧是生成树协议维持网络拓扑稳定的关键控制报文，它的目的MAC地址被固定为01:80:c2:00:00:00，属于IEEE 802.1D定义的保留组播地址。当客户网络被运营商网络分隔成多个站点时，这个组播MAC不会被普通二层交换机转发到远端，导致两侧交换机的生成树计算互相隔离。要解决这个问题，比较直接的办法是在两侧部署隧道，把BPDU帧从一端捕获后封装到三层报文里送到另一端，再还原成原始二层帧注入。本文将用Ruby实现一个简单的BPDU隧道，核心逻辑只有捕获、封装、传输、解封装和注入这几个步骤。
一、为什么BPDU帧无法直接跨运营商网络透传
BPDU帧使用IEEE 802.3封装，目的MAC是01:80:c2:00:00:00，源MAC是发送端口自身的MAC地址。以太网类型字段在BPDU帧中并不是常见的0x0800或0x86DD，而是表示长度的数值，后面紧跟着LLC头部0x42 0x42 0x03，再后面才是BPDU协议数据单元。这种帧格式让很多普通二层设备并不把它当作可转发的数据帧处理，而把它识别为本地控制帧。
按照802.1D的规定，目的地址落在01:80:c2:00:00:00到01:80:c2:00:00:0F范围内的帧属于桥接协议数据单元，交换机不应转发这些帧。因此，即使运营商网络内部存在二层透传通道，中间的设备看到这个组播地址后仍然可能直接丢弃或交给本地STP进程处理，根本不会送到远端端口。再加上运营商网络通常由三层路由设备组成，二层广播域在物理上就是隔离的，BPDU帧无法跨越IP网络到达对端站点。
如果尝试修改BPDU帧的目的MAC来绕过过滤，又会破坏STP的语义，因为生成树协议要求所有交换机都能识别固定的组播地址。正确的做法不是修改帧内容，而是把整个原始帧作为载荷封装到另一个可以正常路由的报文里，例如UDP数据报。这样运营商网络只看到普通的IP流量，不会对内部的BPDU帧做特殊处理，接收端再把它还原并注入本地二层网络。
二、基于Ruby的BPDU隧道整体设计
首先需要明确隧道的两个端点：一端负责从本地交换机的接入端口捕获BPDU帧，另一端负责接收封装后的数据并注入到远端交换机的端口。捕获端需要工作在二层原始套接字模式下，能够读取完整的以太网帧，而不仅仅是IP包。Ruby标准库虽然提供了Socket类，但在Linux上使用AF_PACKET原始套接字并不像C语言那样直观，因此这里引入pcaprub这个gem，它是libpcap的Ruby绑定，可以方便地抓包和注入原始帧。
封装格式需要双方事先约定一致。为了简单，我们设计一个轻量头部：前4个字节写入固定魔数BPDU，用来快速识别隧道报文；接着2个字节表示原始帧的长度，用网络字节序；后面紧跟完整的原始以太网帧。接收端收到UDP报文后，先检查魔数，再读取长度字段，最后取出原始帧并通过pcaprub的inject方法写入本地网卡。这种封装方式没有引入额外加密或校验，但对实验环境已经足够。
选UDP作为隧道传输协议是因为它简单、无连接，而且BPDU帧本身对时延敏感，TCP的重传机制反而可能引入不必要的抖动。当然UDP也有丢包风险，不过生成树协议自身有超时和重传机制，偶尔丢失一两个BPDU不会导致拓扑崩溃，只是会延长收敛时间。如果隧道穿越公网，建议在UDP外层再套一层加密隧道，例如WireGuard或IPsec，这里不展开。
三、发送端实现：捕获BPDU帧并封装转发
发送端代码使用pcaprub打开本地网卡，并设置BPF过滤器只捕获目的MAC为01:80:c2:00:00:00的帧，这样可以大幅减少用户态处理的数据量。捕获到的每一帧都是完整的以太网帧，从第0字节开始是目的MAC，第6字节开始是源MAC。我们只需要检查目的MAC是否等于BPDU保留地址，确认后就把原始帧封装到UDP数据报里发送出去。
require 'pcaprub'
require 'socket'
IFACE = 'eth0'
REMOTE_IP = '192.168.1.20'
REMOTE_PORT = 4789
BPDU_DST_MAC = "\x01\x80\xc2\x00\x00\x00".b
capture = Pcap.open_live(IFACE, 65535, true, 0)
capture.setfilter('ether dst 01:80:c2:00:00:00')
udp_sock = UDPSocket.new
capture.each_packet do |pkt|
frame = pkt.data
dst_mac = frame[0, 6]
next unless dst_mac == BPDU_DST_MAC
payload = "BPDU".b + [frame.bytesize].pack('n') + frame
udp_sock.send(payload, 0, REMOTE_IP, REMOTE_PORT)
puts "Forwarded BPDU frame, length=#{frame.bytesize}"
end
代码中pack('n')将帧长度转换为2字节网络字节序，这符合隧道头部的约定。发送UDP时使用UDPSocket的send方法，目标地址和端口在变量中定义。注意这段代码需要在root权限下运行，因为打开原始套接字和注入帧都需要系统权限。如果本机有多个网卡，IFACE需要改成实际连接客户交换机的接口名称。
pcaprub的setfilter使用tcpdump兼容的BPF语法，这里过滤条件可以让内核只把目的MAC匹配的帧交给用户态，避免循环处理大量无关流量。如果没有安装pcaprub，可以使用gem install pcaprub命令安装，但需要系统中已有libpcap开发库。
四、接收端实现：解封装并注入二层网络
接收端首先监听UDP端口，收到隧道报文后解析魔数和长度字段。魔数用来快速丢弃非隧道流量，长度用来从UDP负载中切出完整的原始帧。之后调用pcaprub的inject方法将原始帧从指定网卡发送出去，完成BPDU帧的还原注入。
require 'pcaprub'
require 'socket'
LISTEN_IP = '0.0.0.0'
LISTEN_PORT = 4789
IFACE = 'eth0'
udp_sock = UDPSocket.new
udp_sock.bind(LISTEN_IP, LISTEN_PORT)
injector = Pcap.open_live(IFACE, 65535, true, 0)
loop do
payload, addr = udp_sock.recvfrom(2048)
magic = payload[0, 4]
next unless magic == 'BPDU'
frame_len = payload[4, 2].unpack1('n')
frame = payload[6, frame_len]
injector.inject(frame)
puts "Injected BPDU frame, length=#{frame_len}, from=#{addr[3]}"
end
注入时需要注意网卡的选择，必须把帧发送到连接远端交换机的接口，而且该接口所在的端口不能启用了BPDU过滤或BPDU Guard。很多交换机默认会对接收到的BPDU帧进行特殊处理，如果端口启用了BPDU Guard，它会直接把端口置为errdisable状态，所以在实验环境中要提前关闭这些安全特性。
另一个容易忽略的问题是MTU。原始以太网帧最大约为1518字节，封装进UDP后再加上IP头和隧道头会超过普通以太网接口的1500字节MTU。如果隧道中间网络不允许分片，可能造成丢包。解决方法是降低客户侧交换机的接口MTU，或者把隧道路径上的MTU调大，例如启用巨型帧。在实验室里一般不会出现大量大帧，BPDU帧本身长度很小，影响不大。
五、测试方法与实际部署注意事项
验证隧道是否工作，可以在两台Linux主机上分别运行发送端和接收端脚本，并在远端主机的二层接口上使用tcpdump抓包。抓包命令可以指定BPDU的目的MAC，例如tcpdump -i eth0 ether dst 01:80:c2:00:00:00，观察是否有原始BPDU帧被注入。同时检查发送端日志中打印的转发数量是否与接收端日志一致，如果一致说明隧道传输稳定。
实际部署时还要考虑隧道端点与客户交换机的连接方式。发送端主机需要和客户交换机直连，并且最好使用一个独立端口做镜像或分光，避免影响现有链路。接收端注入时必须使用能发送原始帧的网卡，某些虚拟网卡并不支持注入功能，建议使用物理网卡。如果两端主机都运行Linux并安装了pcaprub，整体部署成本非常低。
这种基于Ruby的隧道方案优点是实现简单、不依赖厂商专用特性，适合在实验环境或临时应急场景下快速打通跨运营商的STP BPDU传输。生产环境需要的高可用性、加密传输、带宽保证等需求，还是建议使用运营商提供的L2VPN、VPLS或EVPN服务。本文的代码提供了一个理解BPDU隧道原理的起点，可以根据实际网络环境进行扩展。