NPB隧道封装实战：GRE与VXLAN如何打通三层流量转发

在早期网络报文代理（NPB）部署里，分析工具通常直接连在NPB物理端口上。NPB从交换机镜像口收流量，做过滤后从本地端口甩给IDS、探针或排障平台，路径很短，也不需要额外封装。但是这种传统直连方案有以下弊端：

• 端口消耗快：每接一个工具占一个NPB端口，工具多了端口立刻吃紧
• 布线耦合高：工具迁移、扩容都要改物理连线
• 采集点受限：只能在中心NPB旁挂工具，边缘点位没法轻量部署

但是隧道方案下，NPB只需保留到生产交换机的上联链路，工具侧增删不改拓扑，只在配置里绑定新隧道指向分析平台即可。

NPB隧道封装的典型场景

集中式NPB + 三层转发到远端工具

NPB仍在中心节点，镜像流量进来后不匹配直连输出，而是绑定GRE或VXLAN隧道，封装后发往交换机。交换机按外层目的IP路由，流量穿越现有L2/L3网络到达远端工具。

优势很直接：

• NPB上联端口数量固定
• 工具侧扩容零布线变更
• 可利用现有生产三层网络，不另建监控专网

分布式采集点回传集中分析平台

另一种用法更适合边缘场景。比如铁路信令分析、分支机房、空间受限的采集点：每个点位只放一台NPB，做本地过滤，然后把所需流量通过GRE/VXLAN隧道回传中心平台。

这类架构的前提是NPB与工具侧存在三层可达，且单点流量规模不大——它不适合替代传统Leaf-SPAN汇聚模型，但非常适合"采完即传"的轻量点位。

GRE与VXLAN封装原理对比

NPB收到原始镜像报文后，先走ACL过滤，命中转发策略再决定是否加隧道。两者封装结构差异在于"原始MAC留不留"。

GRE封装结构：去原始MAC

原始报文的MAC层不保留，外层MAC和IP由隧道参数决定。GRE本身只描述"里面装的是什么"，真正驱动转发的是外层IP。

这也是为什么NPB配GRE时要填：

• 隧道源IP / 目的IP
• 目的MAC（当前多数实现需手动填）
• 可选VLAN标签

VXLAN封装结构：保留原始二层帧

VXLAN本质是MAC-in-UDP，原始二层帧原样塞进内层，外层靠VTEP式IP/UDP转发，目的端口默认4789。

NPB侧需要额外配：

• VNI
• UDP源/目的端口
• 外层MAC/IP

NPB隧道配置关键点

以常见Web管理界面为例，路径通常是：转发策略 → 全局配置 → Tunnel Handler → 添加隧道。

目的MAC、源MAC与隧道IP

• 目的MAC：多为必填。填对端下一跳设备MAC
• 源MAC：可不填，默认用NPB系统MAC
• 源/目的IP：决定外层IP头，交换机靠目的IP路由
• IP版本：IPv4或IPv6均可配

后续演进方向是"只配下一跳IP、NPB自行ARP学MAC"，可减少手工维护。

VLAN标签与VXLAN UDP端口

可选VLAN字段会在"外层IP头与前层以太头之间"再插一层VLAN tag，用于给封装报文打运输标记。

VXLAN需指定：

• VNI
• UDP目的端口（默认4789）
• UDP源端口（不填则按实现取默认值）

转发策略绑定限制

隧道建好后，在转发策略里关联封装名称，经该策略输出的所有流量都会额外叠加一层隧道头，由三层网络按隧道目的IP完成转发。

【配置注意事项：只能删除重建】

• 隧道不支持修改，只能删除后重建：隧道绑定后底层关联关系已固化，修改会导致异常；
• 隧道若已绑定策略，需先在策略中解绑，才能删除隧道；
• 外层封装字段务必与对端网络规划核对一致，避免转发黑洞。