OpenStack跨节点实例流量未在patch-int/patch-tun接口显示排查
问题背景
当前环境为基于Open vSwitch部署的OpenStack运营商网络，测试场景为同一租户网络下、分布在不同计算节点的两台云主机互ping，对应网络拓扑如下：
经多节点抓包观测，已确认以下现象：
- qbr Linux网桥上的tap接口、qvb接口可正常捕获双向ICMP流量
- OVS集成网桥br-int上的qvo接口可正常捕获双向ICMP流量
- 预期中br-int与br-tun互联的patch-int、patch-tun接口始终抓不到对应流量
- vxlan类型隧道接口可正常捕获经过overlay网络的双向ICMP流量
- 两个计算节点的抓包现象完全一致
核心待确认问题：
- 该场景下流量通过什么路径转发到vxlan接口进入overlay网络
- patch-int、patch-tun接口无流量的原因，是否存在配置错误或抓包方法错误
具体解答
1. 实际端到端流量路径
你当前环境的流量转发路径和旧版传统OVS架构有区别，实际转发路径为：
云主机vNIC → tap设备 → qbr安全组网桥（Linux网桥，负责处理iptables类型的安全组规则）→ qvb设备 → qvo设备 → br-int集成网桥 → 直接匹配br-int上的二层转发流表，转发到本地vxlan隧道端口 → 封装VXLAN报文头后通过物理网卡进入overlay网络，发送到对端计算节点。
反向流量路径对称：对端计算节点发来的VXLAN报文到达本地物理网卡后，经OVS解封装进入vxlan端口，匹配br-int流表转发到对应云主机的qvo口，依次经过qvb、qbr、tap设备回到云主机vNIC。
整个转发过程不需要经过独立的br-tun隧道网桥，也不需要经过网络节点中转，同网段跨节点流量直接在计算节点本地完成封装转发。
2. patch-int、patch-tun接口无流量的原因
绝大多数情况是架构差异导致的正常现象，剩余情况为抓包方法问题，可按以下顺序排查：
（1）架构原因：新版OVS组网已废弃独立br-tun网桥
从OpenStack Train版本开始，Neutron的OVS驱动默认支持将VXLAN/GRE等隧道端口直接创建在br-int网桥上，省去了br-int和br-tun之间patch口转发的性能开销，部署效率和转发性能都更高。
你可以执行以下命令验证vxlan端口所属网桥：
# 查看br-int上的所有端口 ovs-vsctl list-ports br-int # 查看br-tun上的所有端口 ovs-vsctl list-ports br-tun
如果vxlan-ac100186这类隧道端口列在br-int的端口列表里，说明你的环境用的是新版单集成桥架构，br-tun网桥和对应的patch-int、patch-tun端口要么是旧版本部署残留的闲置资源，要么是部署时默认创建但未加入转发流表的无效端口，本来就没有流量经过，抓不到包是完全正常的，不存在配置错误。
（2）抓包方法问题：patch端口默认无法被常规抓包工具捕获
如果你执行上面的命令确认vxlan端口确实在br-tun网桥上，说明你用的还是传统br-int+br-tun的双网桥架构，这时候抓不到patch口流量是抓包方法的问题：
patch端口是OVS实现的两个网桥之间的逻辑直连接口，流量在内核态OVS datapath层直接完成跨网桥转发，不会经过普通网络协议栈的抓包挂载点，默认的tcpdump、ovs-tcpdump工具如果不做特殊配置，无法捕获这两个端口的转发流量。如果开启了OVS内核流表快转、硬件卸载功能，流量会直接跳过patch端口的netdev统计点，更难被常规工具抓到。
这种情况你可以通过查看OVS流表确认流量实际走向，不需要强行抓patch口的包：
# 查看br-int上的转发流表，确认从qvo口进入的流量转发目的端口 ovs-appctl dpctl/dump-flows | grep qvoe0109961-57
如果流表动作里明确写了output:patch-int的端口号，说明流量确实经过patch口转发，只是抓包工具看不到，配置没有问题。
内容的提问来源于stack exchange，提问作者amh9412
