Packets dropped in br-int bridge
This bug report will be marked for expiration in 53 days if no further activity occurs. (find out why)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
Hello,
We have two VMs that communicate with each other. Like VM-A and VM-B, on different hosts, host-A and host-B.
Now, we encountered one problem:
VM-A sends one burst packets like 300K packets(each packet is less than 100 bytes) per seconds to VM-B. But VM-B could only receive about 100K packets. The burst last about 2 seconds.
We did tracing where the packet got dropped. And found on host-B, the virtual port "patch-tun" in br-int could receive all packets.
But the "qvoxxx" interface on br-int couldn't receive all packets.
We tried to dump: ovs-appctl bridge/dump-flows br-int and ovs-ofctl dump-ports br-int.
But no significant drop counter could match such number of the packets drop.
Need your expertise to check where could the packets got lost. Any configuartion could impact on such situation?
Thanks,
Mark
Changed in neutron: | |
status: | New → Incomplete |
Hello Mark:
The first thing I would propose you is to switch from hybrid plug to native. That will improve the performance avoiding the veth pair to a Linux Bridge to plug the TAP port there. With native plug type you'll connect the TAP device directly to the OVS br-int. It could be possible that the packet lost is happening in the Linux Bridge.
In order to change this, you should swap from "firewall_ driver= iptables_ hybrid" to "firewall_ driver= openvswitch" or None. Then you'll need to restart the agent and re-plug the VMs (stop or migrate them).
That will, for sure, improve the performance and will make shorter the datapath. Now OVS will be the only backend levering the data packets.
Regards.