在问题排查之前我们先搞清楚HCI虚拟机接入分布式交换机的时候转发机制是怎样的 HCI分布式交换机转发机制当两个互访的虚拟机在同一个网段,并且运行在同一主机时才会经过同一交换机(即:最终的互访流量只到达交换机,不会到物理出口) 如果是同一网段不同主机上的两个虚拟机互访,是通过物理出口来互访的(即:最终的互访流量会到达物理出口) 在HCI上建一个网络拓扑如下 其中1.2和1.3是运行在同一个主机2上,1.1是运行在另一个主机1上的 对应HCI上的网络拓扑如下 实际针对转发来说对应的拓扑如下 具体的流量转发路径如下:
192.168.1.1访问192.168.1.2/192.168.1.3路径如下 192.168.1.2访问192.168.1.3路径如下
问题现象HCI版本:6.0.0R5
问题现象:2台同网段虚拟机(1.1和1.2)连接在同一分布式虚拟交换机下,虚拟交换机直连物理出口,虚拟机1.1ping1.2第一个包丢掉(配置了分布式防火墙策略,拒绝了1.2主动访问1.1的全部服务)
排查步骤1、 确定这两台交换机为同一网段、运行在不同主机上的虚拟机 2、 在对应的虚拟机上抓包分析 抓包查看1.1的请求报到达了主机2上的交换机1,并且1.2收到了请求包并发送了应答包 1.2发送的应答包到达了主机1上的交换机1,但是主机1上的交换机1没有将应答包专转发给1.1 3、在HCI上开启全量debug,并验证等现象复现,最终查出来发现是旧版本HCI分布式虚拟交换机转发机制的问题 debug看首个丢包的ping包在丢包交换机上处理如下:
1、1.1上发出的icmp request包在交换机上创建了session,但创建session时没有fdb(没有关于目的MAC的表项),导致创建的session的outport值是0;
没有fdb原因与交换机上fdb老化时间有关(默认HCI虚拟交换机MAC老化时间大概为10分钟) 2、1.2响应1.2的icmp reply包回到1.1的交换机上以后 查找session时 inport是1是有值的,导致与正向icmp request创建的session匹配不上,导致匹配了drop acl丢包了;
最终结论是由于老架构HCI虚拟交换机转发机制的问题导致的(由于MAC表老化加上转发机制造成的——正常来说只要有流量经过交换机,MAC表都会刷新;上述情况时因为关于1.2的所有流量都没有经过主机1的交换机1,进而导致该交换机没过一段时间关于1.2的MAC表项就老化了,导致首次ping包丢失)。 600R5版本 交换机是flow转发模式(新版本交换机不是sesion转发的了,新版本跟外部交换机转发模式一样packet模式,直接查mac转发) 交换机上收包没有fdb情况下,首次ping时候 icmp request包触发创建的session上没有outport信息(默认为0);此时回来的应答包有inport信息,导致session不匹配,丢包
交换机上收包有fdb情况下,ping时候 icmp request包触发创建的session上有outport信息;此时回来的应答包也有inport信息,session能够成功匹配,正常转发。 |