You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Windows platform, we run containers/VMs on host, and use OVS tunnel to support the container/VMs connections inter two Nodes. We use "ping" command to test the connectivity between the containers/VMs accross the Windows hosts. Then we find several packets are lost. After some capturing the packets, we find that the first packet which expected to be transferred over the tunnel is actually dropped, if the tunnel peer' MAC is not existing on the Windows host's ARP cache.
With tests, we got some output like this,
Pinging 192.168.2.5 with 32 bytes of data:
Request timed out.
Reply from 192.168.2.5: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.2.5:
Packets: Sent = 2, Received = 1, Lost = 1 (50% loss),
To reproduce it, the steps include,
create tunnel port on OVS on each Windows host (there should be 2 Windows hosts at least in the setup)
run one container per Windows host
clear ARP cache on each Windows host
login to the one container, and ping peer container
The text was updated successfully, but these errors were encountered:
wenyingd
changed the title
[Windows] Packet is dropped over the tunnel when not found dst MAC in ARP cache
[Windows] Packet is dropped over the tunnel when the tunnel peer MAC is not found in ARP cache
Apr 28, 2022
when traffic is sent through tunnel, it will drop untile MAC is learned.
I tested with installingw ovsext driver, normally after driver installed and
all is setup, the first ping packet will drop, with this patch, the first
ping packet is OK.
Reported-at:openvswitch/ovs-issues#253
Signed-off-by: Frank Guo <frankg@vmware.com>
Signed-off-by: 0-day Robot <robot@bytheb.org>
On Windows platform, we run containers/VMs on host, and use OVS tunnel to support the container/VMs connections inter two Nodes. We use "ping" command to test the connectivity between the containers/VMs accross the Windows hosts. Then we find several packets are lost. After some capturing the packets, we find that the first packet which expected to be transferred over the tunnel is actually dropped, if the tunnel peer' MAC is not existing on the Windows host's ARP cache.
With tests, we got some output like this,
To reproduce it, the steps include,
The text was updated successfully, but these errors were encountered: