| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the recent upstream OVS Geneve IPV6 tunnel coding job, it is only supportting the case when the uplink offload
(UDP v6 offload parameter setting on the network adapter configuration) is disabled.
For Geneve IPV6 header setting, it needs set Transmit.IpHeaderChecksum in NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO
to be 0. Elsewise we could observe the found issue on the report page.
After this patch, even the uplink UDP v6 offload is enabled(On WindowsServer 2019) by default the IPV6 Geneve tunnel
could send/receive packets without issues now. I have tested four kinds of network adapter drivers( E1000e ,vmxnet3 and
physical network adapter "Intel(R) Ethernet 10G X710 rNDC " and "Mellanox ConnectX-5 Adapter”. On the default offload
setting for the network adapter(Windows server2019) the IPV6 Geneve tunnel could be setup.
This patch needs to be applied to master and branch-3.0.
Test topo,
Setup one IPV6 Geneve Tunnel between 1 Windows VM and 1 Ubuntu server.
Windows VM(Windows server2019), vif0( 6000::2/40.1.1.10) vif1(5000:ed4d::2) ------
Ubuntu VM Eth2(5000:ed4d::9), name space ns1 with interface ns1_link(6000::9/40.1.1.2)
WinVM: ovs-vsctl.exe add-port br-int bms-tun0 -- set interface bms-tun0 type=geneve options:key=flow options:csum=true
options:local_ip="5000:ed4d::2" options:remote_ip="5000:ed4d::9" options:tos=inherit
Ubuntu VM:ovs-vsctl add-port br-int dst_tunnel -- set interface dst_tunnel type=geneve options:local_ip="5000:ed4d::1"
options:remote_ip="5000:ed4d::2"
Reported-at: https://github.com/openvswitch/ovs-issues/issues/260
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the first step OVS Windows will support IPv6 tunnel(Geneve IPv6 tunnel).
Implementation on Windows
-------------------------
1. For the IPv6 tunnel support, OvsIPTunnelKey will replace original
OvsIPv4TunnelKey in the related flow context handing.
2. The related src and dst address will be changed to SOCKADDR_INET type from UINT32.
3. For the IPv6 tunnel, one node running OVS-Windows could encapsulate IPv4/IPv6
Packets via IPV6 Geneve Tunnel, and the node could also encapsulate IPv4/IPv6 packet
Via IPv4 Geneve tunnel.
4. Related IPHelper data structure will be adapted to support IPv6 Tunnel. In the IPHelper
part the related Windows API(such as GetUnicastIpAddressTable/GetBestRoute2/GetIpNetEntry2/
ResolveIpNetEntry2) and Windows data structure(MIB_IPFORWARD_ROW2/MIB_IPNET_ROW2/IP_ADDRESS_PREFIX)
Have already supported both IPv4 and IPV6. Now OVS Windows has been adjusted some functions
And data structured to support IPV6 tunnel also.
5. OVS_TUNNEL_KEY_ATTR_IPV6_SRC and OVS_TUNNEL_KEY_ATTR_IPV6_DST filed will be supported in
OVS-Windows kernel for IPV6 tunnel.
Testing done.
-------------------------
Related topo, 1 Windows VM(Win2019) and 2 Ubuntu 16.04 server. Both VMs
Are running on one ESX host.
1. Setup one IPV6 Geneve Tunnel between 1 Windows VM and 1 Ubuntu server.
Windows VM, vif0( 6000::2/40.1.1.10) vif1(5000::2)—— Ubuntu VM Eth2(5000::9), name space ns1
with interface ns1_link_peer(6000::9/40.1.1.2)
Related tunnnel,
ovs-vsctl.exe add-port br-int bms-tun0 -- set interface bms-tun0 type=Geneve options:csum=true
options:key=flow options:local_ip="5000::2" options:remote_ip=flow
In this topo, traffic from Vif0(Win) to ns1_link_peer(Ubuntu) will be gone through the Geneve tunnel
(5000::2—>5000::9) for both IPv4 traffic(40.1.1.10-->40.1.1.2) and IPv6 traffic(6000::2—>6000::9)
2. Setup one IPV4 Geneve Tunnel between Windows VM and 1 Ubuntu server.
Windows VM, vif0( 6000::2/40.1.1.10) vif1(50.1.1.11)—— Ubuntu, Eth2(50.1.1.9), name space ns1
with interface ns1_link_peer(6000::19/40.1.1.9)
Related tunnnel,
ovs-vsctl.exe -- set Interface bms-tun0 type=geneve options:csum=true options:key=flow
options:local_ip="50.1.1.11" options:remote_ip=flow
In this topo, traffic from Vif0(Win) to ns1_link_peer(Ubuntu) will be gone through the Geneve Tunnel
(50.1.1.11—>50.1.1.9) for both IPv4 traffic(40.1.1.10-->40.1.1.9) and IPv6 traffic(6000::2—>6000::19).
3.Regression test for IpV4 in Antrea project (about 60 test case) is PASS
Future Work
-----------
Add other type IPv6 tunnel support for Gre/Vxlan/Stt.
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Use only non-executable memory when using MmGetSystemAddressForMdlSafe.
Introduce a new function called OvsGetMdlWithLowPriority for readability.
Found using WDK 10 static code analysis.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Shashank Ram <shashank08@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Decap functions for tunneling protocols do not compute
the packet header offsets correctly when there is a VLAN
tag in the L2 header. This results in incorrect checksum
computation causing the packet to be dropped.
This patch adds support to account for the VLAN tag in the
packet if its present, and makes use of the OvsExtractLayers()
function to correctly compute the header offsets for different
layers.
Testing done:
- Tested Geneve, STT, Vxlan and Gre and verified that there
are no regressions.
- Verified that packets with VLAN tags are correctly handled
in the decap code of all tunneling protocols. Previously,
this would result in packet drops due to invalid checksums
being computed.
- Verified that non-VLAN tagged packets are handled correctly.
Signed-off-by: Shashank Ram <rams@vmware.com>
Acked-by: Anand Kumar <kumaranand@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the OvsLookupFlow fails for the decap packet,
when the Geneve options are present in the packet as the OvsIPv4TunnelKey
flags are not set in the Geneve decap.
Set the OvsIPv4TunnelKey flags OVS_TNL_F_OAM and OVS_TNL_F_CRT_OPT
in OvsDecapGeneve based on the geneve header. Also set OVS_TNL_F_GENEVE_OPT
if the packet has geneve options.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Sairam Venugopal <vsairam@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With this patch, OvsTcpSegmentNBL not only supports fragmenting NBL
to TCP segments but also Ipv4 fragments.
To reflect the new changes, renamed function name from OvsTcpSegmentNBL
to OvsFragmentNBL and created a wrapper for OvsTcpSegmentNBL.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Change the UDP destination port(GENEVE header) to check if it was set by
the userspace, use it if it was set.
If the userspace did not specify a destination port, use the configured
vport destination port.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Sairam Venugopal <vsairam@vmware.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds multiple internal ports support to the windows datapath.
All tunnels types have been updated to accommodate this new functionality.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Co-authored-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com>
Acked-by: Paul Boca <pboca@cloudbasesolutions.com>
Acked-by: Sairam Venugopal <vsairam@vmware.com>
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
The purpose of this patch is to make the code more readable and
fix a static analyzer warning.
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Acked-by: Sairam Venugopal <vsairam@vmware.com>
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
|
|
|
Signed-off-by: Yin Lin <linyi@vmware.com>
Acked-by: Nithin Raju <nithin@vmware.com>
Signed-off-by: Gurucharan Shetty <guru@ovn.org>
|
