企业官网建设流程全解析

最近有做边缘网关的同行丢给我一个现场问题：两台设备中间串一台旁路设备，旁路设备上跑的是VPP，要求所有报文穿过去的时候 VLAN 不能丢、MAC 不能改、延迟还得压在微秒级。他最开始拿 bridge domain 硬怼，流量一上来 MAC 学习表就开始抖，然后开始怀疑人生。后来换成xconnect做二层互联，两条命令下去世界清净了。这件事让我觉得值得把 VPP 里 xconnect 这套东西完整讲一遍——它看着简单，就两个接口对接，但坑全藏在接口状态、方向配置、MTU 对齐和 worker 绑定这些边角上。这篇内容适合三类人：一是在 VPP 上做透明串接、旁路引流、跨主机二层打通的同学；二是刚接触 VPP、被 bridge domain 和 xconnect 搞混的新手；三是线上已经跑起来了、但遇到偶发丢包想回头查根因的运维。下面按我实际踩坑的顺序来讲，先拆思路，再上命令，最后把排查表摊开。

1. 先把边界划清楚：xconnect 到底解决什么问题

1.1 二层互联的四种典型需求

说 xconnect 之前得先说清楚"二层互联"这四个字在不同场景里压根不是一个意思。第一种是透明串接，设备像一根网线插在两个网络之间，对两端完全不可见，报文进一个口出一个口，中间不做任何三层处理，常见于安全设备旁路、流量采集、协议分析这类部署。第二种是跨主机二层打通，两台宿主机上的容器或者虚拟机需要处在同一个广播域里，中间隔着物理网络，靠隧道或者共享内存把二层帧搬过去。第三种是链路汇聚与分流，一个口进多个口出，或者多个口进一个口出，做流量复制和负载分担。第四种是VLAN 转换，进来带 tag 100，出去要剥掉或者换成 tag 200，用于对接不同厂家的设备。

这四种需求对转发的诉求完全不同。透明串接要求的是"零改写、零学习、零泛洪"，你多学一个 MAC 都是浪费；跨主机打通要求的是"可靠搬运 + 会话保持"；分流要求的是"复制能力 + 规则匹配"；VLAN 转换要求的是"能在转发路径上改包"。VPP 里能覆盖这些的组件有好几个，bridge domain、l2 patch、l2 xconnect、还有 memif 加 bridge 的组合拳，选错了不是性能问题，是功能压根对不上。

我见过最常见的误用，就是拿 bridge domain 去做透明串接。bridge domain 本质是一台完整的二层交换机，它会学 MAC、会老化、会泛洪未知单播、会处理 BUM 流量。你只是想让报文穿过去，它却在后台拼命维护一张你根本不需要的表。流量小的时候看不出来，一旦广播包多或者 MAC 地址数量超过表容量，行为就开始不可控。这不是 bridge domain 的错，是工具选错了。

1.2 为什么这类场景必须绕开三层

有人会问，两个接口之间转发，直接配个 IP 做路由不行吗？不行，而且原因是硬的。做过三层转发就必须改 MAC：进来的帧目的 MAC 是网关的，出去的帧目的 MAC 要换成下一跳的。对于透明串接场景，两端的设备可能在做 MAC 绑定、802.1X 认证、或者是某种基于 MAC 的准入控制，你中间把 MAC 改了，链路上的策略立刻失效。

还有一个更隐蔽的点：三层转发会终止广播域。ARP 请求、DHCP 发现、LLDP、STP 这些二层协议报文，三层设备要么自己消费掉，要么直接丢弃，不会透传。而透明串接设备的一个基本要求就是"二层协议也要透传"，因为对端设备可能正在跑生成树，你把它掐了，环路保护就没了。

所以这类场景的技术路线只有一条：在二层做转发，不改包，不终止广播域，不参与协议。VPP 里符合这个描述的，就是 xconnect 和 l2 patch。

1.3 xconnect 在 VPP 里的定位

VPP 的转发图是一个一个有向节点串起来的流水线。报文从dpdk-input或者af-packet-input这类收包节点进来，经过ethernet-input解析，然后按接口配置的模式分流到l2-input或者ip4-input。xconnect 做的事情，是在接口上打一个标记，让这个接口收到的所有帧，在l2-input这一层就直接被扔到对端接口的interface-output，中间不查表、不学 MAC、不做任何决策。

这个定位带来两个直接后果。第一是快，转发路径短，缓存友好，单核轻松跑满万兆线速。第二是死板，接口一旦进入 xconnect 模式，它就不再是一个"普通接口"了，你不能在上面配 IP，不能把它挂到 bridge domain，不能做 ACL 之外的大部分 feature。这种死板在透明串接场景里恰恰是优点——它保证了这个接口绝对不会偷偷干别的事。

2. 三条路的选择：bridge domain、l2 patch、l2 xconnect

2.1 三者的转发路径差异

这三个东西经常被混着叫"二层转发"，但它们在 VPP 转发图里走的路完全不一样，搞清楚这个差异，选型就不用背文档了。

bridge domain 走的是完整路径：interface-input→l2-input→l2-fwd节点。l2-fwd是核心，它拿目的 MAC 去查l2fib表，查到就转发，查不到就泛洪到同广播域的所有口。这个节点还负责 MAC 学习、老化、BVI 处理、ARP 代答等等。功能全，开销也全。

l2 xconnect 走的是：interface-input→l2-input→ 直接转到配对的 tx 接口。l2-fwd这个节点根本不进。所以没有查表，没有学习，没有泛洪。它本质上是一根"虚拟网线"，两端插上就通了。

l2 patch 更极致，它在接口的 rx 上直接挂一个 patch 节点，连l2-input的 feature 框架都绕开了。你可以把它理解成在收包节点后面开了一个后门，报文进来直接送到对端 output。这是三者里路径最短的。

我用一个不太严谨但很好记的类比：bridge domain 是一台交换机，它得知道每个口后面挂着谁；l2 xconnect 是一根网线，它不需要知道任何事；l2 patch 是焊死的一根线，连插拔的机会都不给你。

2.2 选型对照表

实际操作里我按下面这张表来选，基本不会错。

表格里"双向配置"这一行特别值得说。set interface l2 xconnect是单向语义的，你把 A 的 xconnect 指向 B，只代表 A 收到的帧从 B 出去，B 收到的帧去哪还得单独配一条。这是我见过最高频的配置错误，后面会专门讲。

2.3 xconnect 的代价：接口被独占

xconnect 最容易被低估的成本是"接口被独占"。一个接口进入 xconnect 状态之后，你不能再给它配 IP，不能把它加到 bridge domain，不能在上面挂策略路由。如果业务方临时说"这个口我想顺便抓个包看看到底有没有流量"，你会发现常规手段全用不了，只能靠 VPP 自己的 trace 或者镜像功能。

更麻烦的是状态耦合。xconnect 配对之后，两个接口的链路状态是联动的。如果对端接口 down 了，本端即使物理上 link up，转发也会停。这在排查时会制造假象——你以为链路是好的，实际上 xconnect 的 peer 挂了。

所以我的习惯是：只要这个接口未来有可能需要承担三层功能，就不要上 xconnect，宁可多花点开销用 bridge domain 加两个口的 BD。xconnect 适合那种"定位极其明确、这辈子就干这一件事"的接口。

3. 环境准备：接口从哪来

3.1 物理网卡绑 DPDK 的前置条件

用物理口做 xconnect 是最常见的，因为透明串接往往要接真实的链路。VPP 通过 DPDK 接管网卡，接管之后内核就看不到这块卡了，ip link里会消失。这一步很多人第一次做会慌，其实正常。

接管前要确认三件事。第一是大页内存，DPDK 需要它，一般配 2MB 页 1024 个或者 1GB 页 4 个，取决于你的机器和 VPP 的启动参数。大页不够的表现是 VPP 起来了但网卡初始化失败，show hardware-interfaces里能看到错误。第二是驱动绑定，网卡要从内核驱动解绑，绑到 VFIO 或者 UIO 上。不同网卡的绑定命令不一样，通用做法是走dpdk-devbind这类工具，绑之前先用状态查询确认网卡当前的驱动归属。第三是IOMMU，用 VFIO 模式的话要确认 BIOS 里开了 VT-d，否则绑不上。

提示：绑定网卡属于破坏性操作，做之前一定确认这块卡上没有正在跑的 SSH 或者管理流量。远程操作时绑错网卡直接失联，只能去机房。

启动参数里 DPDK 段大概长这样，具体设备白名单按你机器上的 PCI 地址填：

dpdk { dev 0000:3b:00.0 dev 0000:3b:00.1 dev default { num-rx-queues 2 num-tx-queues 2 num-rx-desc 1024 num-tx-desc 1024 } }

num-rx-queues这个参数值得单独说。它决定了一个物理口能同时被几个 worker 处理。如果配成 1，那这个口的所有流量都压在一个核上，万兆线速下小包场景容易成为瓶颈。配成 2 或者 4 让多个 worker 分担，但要注意 xconnect 的一对接口最好落在同一个 worker 上，否则跨核转发要走 handoff，性能掉得厉害。

3.2 纯软件接口：veth、tap、memif

不是所有场景都有物理口可用。做功能验证、跑单元测试、或者在容器环境里搭拓扑，基本都是软接口。

veth pair是最像"网线"的东西，一对虚拟网卡，一头在 VPP 里，一头在主机内核里。主机侧看到的就是一块普通网卡，可以配 IP、可以挂网桥、可以跑抓包工具。创建命令在不同版本里写法有变化，常见的是：

vppctl create interface veth host-if-name vpp-host-1

老一点的版本可能是create veth pair id 1 host-if-name xxx这种形式，具体以你的vppctl help输出为准。创建完主机侧会多出一个同名接口，记得ip link set vpp-host-1 up，否则 VPP 侧看到的一直是 down，xconnect 配上去也不转发。这个坑我踩过不止一次。

tap接口用途类似，但它模拟的是二层设备，在多队列和高吞吐场景下表现不如 veth。老版本里 tap 是默认选择，新版本推荐 veth。

memif是共享内存接口，不走内核协议栈，两个 VPP 实例之间、或者 VPP 和容器里的应用之间用它对接，延迟极低。做跨主机的二层打通时，常见组合是 memif 接容器 + xconnect 接隧道口。

vppctl create memif socket id 1 filename /tmp/memif-1.sock vppctl create interface memif id 1 socket-id 1 master

master 和 slave 角色要分清楚，一端 master 一端 slave，两边都配 master 会起不来。

3.3 接口命名与状态确认

VPP 的接口命名规则跟版本关系很大。物理口一般叫GigabitEthernet3b/0/0这种带 PCI 位置的格式，软接口叫veth0、tap0、memif0/1。做配置脚本的时候尽量不要硬编码接口名，先用show interface拿一遍，或者用show hardware-interfaces确认物理口和 PCI 的对应关系。

vppctl show interface vppctl show hardware-interfaces vppctl show interface address

配 xconnect 之前，接口必须满足两个条件：admin state 是 up，link state 也是 up。admin up 靠set interface state <name> up，link up 取决于物理链路或者对端软接口的状态。这两个状态在show interface里是分开显示的，很多人只看 admin 不看 link，然后奇怪为什么不通。

4. 动手：一次完整的 xconnect 联调

4.1 拓扑与规划

假设一个最典型的透明串接场景：两台业务设备分别接在 VPP 的两个物理口上，VPP 要在中间做一个完全透明的二层通道，同时这两台设备之间跑的是带 VLAN tag 200 的流量。

拓扑大致是这样：业务设备 A 接GigabitEthernet3b/0/0，业务设备 B 接GigabitEthernet3b/0/1，A 和 B 之间需要二层互通，VLAN 200 的 tag 必须原样保留。

接口规划定下来：两个物理口直接做 xconnect，不做 VLAN 子接口，不做 tag 改写，让所有帧原样透传。这种情况下 VLAN 200 的 tag 天然保留，因为 VPP 根本没碰它。如果需求变成"进来带 tag 100，出去剥掉"，那就得上子接口加 tag rewrite，那是另一套配法，后面单独说。

4.2 核心配置步骤

第一步，确认两个接口起来。

vppctl set interface state GigabitEthernet3b/0/0 up vppctl set interface state GigabitEthernet3b/0/1 up vppctl show interface

确认输出里两个口都是up up，并且 rx/tx counters 已经开始跳。如果 counters 不动，说明链路上没有流量或者光模块没协商上，先解决物理层再往下走。

第二步，配双向 xconnect。注意这里是两条命令，不是一条。

vppctl set interface l2 xconnect GigabitEthernet3b/0/0 GigabitEthernet3b/0/1 vppctl set interface l2 xconnect GigabitEthernet3b/0/1 GigabitEthernet3b/0/0

第一条的意思是"从 3b/0/0 收到的帧，全部从 3b/0/1 发出去"，第二条反过来。少配一条就是单向通，A 能到 B 但 B 回不来，表现出来就是 ping 不通但抓包能看到一边有包。这个现象太经典了，我每次带新人都会专门演示一遍。

第三步，确认配置生效。

vppctl show interface vppctl show l2fib verbose vppctl show interface features GigabitEthernet3b/0/0

show interface里，配了 xconnect 的接口在 output 那一列会显示成类似l2 xconnect GigabitEthernet3b/0/1的样子，这是最直观的确认方式。show l2fib在 xconnect 场景下是空的，因为压根不走 MAC 表——如果里面有大量表项，说明你的接口其实挂在某个 bridge domain 上，配错了。

4.3 验证与抓包

验证分三层做，一层比一层细。

第一层看计数。show interface里两个口的 rx 和 tx 应该是对称增长的，0 口的 rx 大约等于 1 口的 tx，反之亦然。如果 rx 涨了 tx 不涨，说明转发路径断了，常见原因是 peer 接口 down 或者方向配反。

第二层看 trace。VPP 自带的 trace 是排查利器，比在外面抓包快得多。

vppctl trace add dpdk-input 50 # 此时在业务设备上打流量，比如 ping 或者发包 vppctl show trace

trace 输出里能看到每一个报文经过了哪些节点。正常应该看到dpdk-input→ethernet-input→l2-input→interface-output，然后直接到对端。如果中间出现l2-fwd，说明这个接口其实是 bridge 模式；如果出现error-drop，后面的 reason 就是答案，比如l2 xconnect peer interface is down这种一眼明了的提示。

第三层才是外部抓包。在主机侧用 veth 搭拓扑的话，可以直接tcpdump -i vpp-host-1 -e看原始帧，确认 MAC 没被改、VLAN tag 还在。这一层主要是给业务方交差用的，证明透明性真的做到了。

注意：trace 会消耗性能，生产环境用完记得vppctl trace clear或者重启 trace 配置，别长期挂着。

4.4 需要改写 tag 的进阶配法

前面说的是原样透传。但现实里经常要处理 VLAN 转换，比如上游设备发的是 tag 100，下游设备只认 untagged。这种需求不能直接配 xconnect，得先用子接口把 tag 剥下来，再在子接口上做 tag rewrite。

大致思路是这样：

vppctl create sub-interfaces GigabitEthernet3b/0/0 100 dot1q 100 vppctl set interface state GigabitEthernet3b/0/0.100 up vppctl set interface l2 tag-rewrite GigabitEthernet3b/0/0.100 pop 1

子接口创建命令在不同版本里语法有差异，老版本是create sub <interface> <id>再单独配 encapsulation，新版本直接带 dot1q 参数。tag-rewrite那一条是把进入子接口的帧里的 VLAN tag 剥掉一层。

反过来的 push 操作是：

vppctl set interface l2 tag-rewrite GigabitEthernet3b/0/1 push dot1q 200 1

意思是出去的帧打上 tag 200。这个命令要挂在发起方向的接口上，方向搞反了会不生效，判断方法还是看 trace，看 tag-rewrite 节点到底有没有被执行到。

这种配法下，xconnect 是配在子接口和物理口之间的，不是两个物理口之间。子接口本身是一个独立的逻辑接口，有自己独立的 xconnect 关系。另外要特别注意 MTU：剥了一层 tag 之后帧变短了，push 一层变长了，如果对端 MTU 卡在 1500 这种临界值上，push 之后超长会被丢，现象是 ping 大包不通小包通。

5. 常见问题与排查实录

5.1 接口状态与方向类问题

单向通是最高频的问题，没有之一。前面说过 xconnect 是单向语义，必须配两次。判断方法很简单：show interface里两个口都看一遍，output 列是不是各自指向对方。如果 0 口的 output 显示的是 1 口，1 口的 output 显示正常 L3 或者空，那就是漏了一条。

接口 down 导致不转发排第二。这个问题的欺骗性在于，物理上光模块是亮的，show interface里 link 也显示 up，但 xconnect 就是不工作。原因是 xconnect 的状态跟 peer 绑定，peer down 了本端也停。排查时一定要把两端的 admin 和 link 状态都看一遍。软接口场景更常见，veth 的主机侧如果没ip link set up，VPP 侧看到的永远是 down。

接口上有残留 IP会直接导致 xconnect 配置失败。VPP 里一个接口要么 L3 要么 L2，不能兼得。如果之前给这个口配过 IP，需要先清掉：

vppctl set interface ip address del GigabitEthernet3b/0/0 192.0.2.1/24

有时候清完还报错，那就把接口 down 一下再 up，让状态机重新走一遍。这个操作在线上要谨慎，down 的瞬间流量会断，得挑窗口。

5.2 MTU 与分片问题

VPP 物理接口的默认 MTU 通常是 9000，这个默认值是从追求吞吐的角度定的，但在透明串接场景里会带来麻烦。如果两端设备都是 1500，中间 VPP 是 9000，看起来"大能容小"应该没问题，实际上有个隐患：VPP 不会主动分片，如果链路上某一段只支持 1500，超过的帧会在那一跳被丢，而且丢得无声无息，因为你这边计数器全正常。

我的做法是把 VPP 的 MTU 显式对齐到链路最小值，不要依赖默认值：

vppctl set interface mtu 1500 GigabitEthernet3b/0/0 vppctl set interface mtu 1500 GigabitEthernet3b/0/1

这样超长帧会在入口就被计数或者丢弃，问题暴露在你这儿，而不是漂到下游去查。另外如果做了 tag push，记得留出 4 个字节的余量，MTU 卡 1500 的话实际能过的 payload 会少 4 字节。

5.3 性能相关：worker 绑定与队列

xconnect 单对接口在单核上的吞吐是相当可观的，但多接口场景下如果 worker 分配不当，性能会莫名其妙掉一半。原因是 VPP 的架构里，一个报文如果从 worker A 的接口进来、需要从 worker B 的接口出去，中间要做一次 handoff，这个操作的代价比想象中大。

判断方法：

vppctl show interface rx-placement vppctl show runtime

rx-placement看每个接口的收包队列绑在哪个 worker 上，runtime看各个节点的耗时和 handoff 次数。如果handoff节点的计数很高，基本就是这个原因。解决办法有两个：一是用set interface rx-placement把成对的接口绑到同一个 worker；二是调整启动参数里的corelist-workers和每个接口的num-rx-queues，让分配更均衡。

vppctl set interface rx-placement GigabitEthernet3b/0/0 queue 0 worker 1 vppctl set interface rx-placement GigabitEthernet3b/0/1 queue 0 worker 1

还有一个容易被忽略的点是描述符数量。num-rx-desc配得太小，在突发流量下会丢包，show interface里的 rx-miss 计数会涨。万兆口我一般至少给 1024，流量抖动大的场景给 2048。这个值不是越大越好，太大会占用更多内存并且影响缓存局部性。

5.4 排查速查表

下面这张表是我自己贴在工位上的，遇到问题按顺序过一遍，八成能定位。

show errors这个命令单独拿出来说，它能按节点列出丢弃原因，比 trace 更适合长期观察。常见的 reason 有l2 xconnect peer interface is down、interface is down、no error，最后一个最气人——没有错误但也没转发，说明报文进了某个不输出的节点，得回去查接口模式。

6. 性能调优与长期运维的几个抓手

6.1 把转发路径固定下来

xconnect 的性能优势来自路径短，但前提是路径真的短。有几个东西会悄悄把路径变长，值得定期检查。第一是 feature 挂载，如果你在接口上挂了 ACL、 policing、或者某种 inspection，这些 feature 会在l2-input之后逐个执行，哪怕流量根本不匹配规则也要过一遍。定期show interface features看一眼有没有历史遗留的配置。

第二是 trace 和监控。VPP 的 trace 是有开关的，但有些监控方案会常驻开启某种形式的 per-packet 计数，这在高速率下影响不小。第三是接口类型的选择，同样是 xconnect，物理口直连比经过 veth 再进内核要快一个数量级，因为后者多了一次上下文切换。做性能对比测试的时候一定要把接口类型这个变量控制住。

我在一台中等配置的机器上做过粗略对比：单对万兆物理口做 xconnect，64 字节小包能跑到线速的八成以上，换成一端是 veth 的话直接掉到三成。这个差距不是 VPP 的问题，是内核协议栈的固有成本。

6.2 监控指标怎么选

VPP 暴露的指标很多，但做透明串接的时候真正需要盯的就那几个。第一个是两个方向的收发包差值，rx 和对应方向的 tx 如果长期不相等，说明中间在丢，差值本身就是一个告警信号。第二个是rx-miss，这个反映的是描述符不够或者 worker 处理不过来。第三个是接口状态变化次数，如果链路频繁 up/down，说明物理层有问题，光模块、线缆、对端网卡都值得查一遍。

第四个是handoff 计数，前面说过它影响性能。第五个是每个 worker 的负载分布，show runtime里能看出某个核是不是明显比别人忙，不均衡往往意味着接口到 worker 的映射没规划好。

这些指标不需要全部做成图，但至少要能查历史。VPP 本身有个统计段，可以通过接口或者命令行拉走，接到你现有的监控体系里。我一般会做一个很简单的脚本，定时把show interface和show errors落到文件里，出问题时能回溯到具体时间点。

6.3 变更时的安全操作顺序

xconnect 的变更不像普通接口配 IP 那么随意，顺序错了会断流量。我总结的稳妥顺序是：先 down 掉要改的接口，再删旧配置，再配新配置，最后 up。中间的 down 窗口尽可能短，但不要省。

具体来说，如果是把接口从 xconnect 改成普通三层口，先执行：

vppctl set interface l2 xconnect GigabitEthernet3b/0/0 GigabitEthernet3b/0/0

这个写法看起来有点怪，实际上是把 xconnect 指向自己，起到解除配对的作用。也有版本支持用no set interface l2 xconnect的形式，具体看你版本的支持情况。解除之后再配 IP、配路由。

如果是把接口从 bridge domain 改成 xconnect，要先从 BD 里摘出来：

vppctl set interface l2 bridge GigabitEthernet3b/0/0 0

BD 0 是特殊值，表示不属于任何广播域。摘出来之后再配 xconnect。

提示：VPP 的配置默认不持久化，重启就没了。生产环境一定要用启动配置文件或者外部编排工具把配置固化成可重放的脚本，并且这个脚本要经过验证。我吃过一次亏，机器重启之后只恢复了一半配置，单向通了两天才被发现。

配置持久化这块，VPP 支持从启动配置文件加载 CLI，也支持通过 API 由外部控制器下发。小规模部署用配置文件最省事，把上面那些vppctl命令原样写进/etc/vpp/startup.conf的cli段里就行，注意顺序不能乱——接口 up 一定要在 xconnect 之前，否则配置会报错。

最后分享一个我自己用着很顺手的习惯：每次配完 xconnect，不管业务方说通没通，我都会自己跑一遍三个检查——show interface看双向计数的对称性、show interface features确认没有意外挂载的 feature、show errors确认没有持续增长的错误。这三步加起来不到十秒，但拦下来过好几次"业务说通了但其实只通了一个方向"的假象。透明串接这种东西，最怕的就是半通状态被当成正常，等到某个方向的会话超时了才发现问题，那时候排查成本就高了。