Otherwise it's hard to keep track of all the scripts we have.
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Reviewed-By: Ihar Hrachyshka <ihar@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
If ovs node running on Windows is processing NAT action on the RX side, it will
reset pseudo header checksum only if the L4 checksum is same as the calculated
pseudo header checksum before NAT action.
Without the fix, if the L4 header checksum is filled with a pseudo header checksum
(sourceip, dstip, protocol, tcppayloadlen+tcpheaderlen) OVS will still do the
checksum update(replace some IP and port and recalculate the checksum). It will
lead to incorrect L4 header checksum.
Reported-at:https://github.com/openvswitch/ovs-issues/issues/265
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
When icmp error code send back to sender, currently ovs ct can't create
conntrack for the error code properly, this patch mainly fix the bug.
icmp error code test case:
1) packet too big.
2) network unreachable
3) parameter problem
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
This patch implemented meter action, currently, meter only support drop
method and only support one band. The overall implementation is, when a
packet comes in, it will first lookup meter according to the meter id,
then get the band->rates and delta time since last access the same meter
from the meter struct. Add the multiply result(band->rates * delta_time)
to bucket, finally bucket minus the packet size, if the result larger
than zero, allow the packet go through, otherwise deny the packet go
through.
Test case:
1. Setting the size meter size 3M, then the bandwidth was limit
around 3M;
ovs-ofctl -O OpenFlow13 add-meter br-test meter=2,kbps,\
band=type=drop,rate=3000
ovs-ofctl add-flow br-test "table=0,priority=1,ip \
actions=meter:2,normal" -O OpenFlow13
2. Setting the meter size 8M, then the bandwidth was limit
around 8M;
ovs-ofctl -O OpenFlow13 add-meter br-test meter=2,\
kbps,band=type=drop,rate=8000
ovs-ofctl add-flow br-test "table=0,priority=1,ip\
actions=meter:2,normal" -O OpenFlow13
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Implementation on Windows:
IPv6 conntrack ip fragment feature use a link list to store ip
fragment. When ipv6 fragment module receives a fragment packet,
it will store length of the fragment, until to the received length
equal to the packet length before fragmented, it will reassemble
fragment packet to a complete packet and send the complete packet
to conntrack module. After conntrack processed the packet, fragment
module will divide the complete packet into small fragment and send
it to destination. Currently, ipv6 was implemented in a indenpent
module, for the reason it can reduce the risk of introduce bug to
ipv4 fragmenb module.
Testing Topology:
On the Windows VM runs on the ESXi host, two hyper-v ports attached
to the ovs bridge; one hyper-v port worked as client and the
other port worked as server.
Testing Case:
1.UdpV6
a) UdpV6 fragment with multiple ipv6 extension fields.
b) UdpV6 fragment in normal scenario.
c) UdpV6 fragment in nat scenario.
2.IcmpV6
a) IcmpV6 fragment in normal scenario.
b) IcmpV6 fragment in nat scenario.
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
This patch mainly support alg field in ct action when process
ftp/tftp traffic. Tftp with alg mainly parse the tftp packet
(IPv4/IPv6), extract connect info from the tftp packet and
create the related connection. For ftp, previous version has
supported process of ftp traffic. However, previous version
regard traffic from or to port 21 as ftp traffic, this is
incorrect in some scenario. This version adds alg field in ct for
ftp traffic, we could use ct(alg=ftp) to process any ftp traffic
from/to any port.
IPv4/IPv6.
Test cases:
1) ftp ipv4/ipv6 use alg field in the normal and nat scenario.
2) tftp ipv4/ipv6 use alg field in the normal and nat scenario.
Signed-off-by: ldejing <ldejing@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
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>
Update the necessary make and configure files to remove the Linux
datapath and then remove the datapath.
Move datapath/linux/compat/include/linux/openvswitch.h to
include/linux/openvswitch.h because it is needed to generate header
files used by the userspace switch.
Also remove references to the Linux datapath from auxiliary files
and utilities since it is no longer supported.
Signed-off-by: Greg Rose <gvrose8192@gmail.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
While testing OVS-windows for multiple IPV6 Geneve tunnels on Windows2019VM,
for the broadcast/mutlicast packets, it needs to flood out via configured
multiple Geneve tunnels. Then in some flow pipeline processing, it may have
at least two tunnel processing in OVS_ACTION_ATTR_SET action. When processing
the second tunnel setting it may need flush out the packet out via tunnel before
setting new tunnel parameter in tunKey. We found in this case, after flushing out
the packet out via tunnel, the related layers pointer does not update. In our
test setup on Windows2019VM, it will cause BSOD which is triggered in other Windows
processes. We suspect it may be related to memory overwriting. When we apply the
fix in the patch, no BSOD is observed on the same VM and same packet/tunnel settting.
Another thing needs to be mentioned is for multiple Geneve IPv4 tunnels, the same
kind broadcase/multicast packet will not cause BSOD.
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
GRE/Vxlan/STT tunnel RX is broken due to incorrecly checking the
'tunKey->dst.si_family != AF_INET', which is actually
set later after parsing the GRE header. Removing such
chunk makes tunnel works.
Fixes: edb2335861d6 ("datapath-windows: Add IPv6 Geneve tunnel support in Windows")
Cc: Alin-Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: William Tu <u9012063@gmail.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
OvsExtSendNBLComplete always release NBLs with flag SINGL_SOURCE, this is an
efficient way, which requires all the NBLs having the same source port, when
cloned/fragment NBLs are released, the parent NBLs will be released as well,
the problem is that a parent NBL may have a different source port from the
cloned/fragment NBL, so releasing the parent NBLs with flag SINGLE_SOURCE
is not corrct, see:
https://github.com/microsoft/hcsshim/issues/1056
When this happens, commands 'Get-NetAdapter' and 'Get-HnsEndpoint' in the
Windows node show that one net-adapter/hns-endpoint is in 'disconnected'
state, meanwhile, following processes are affected, ecah of them has one
thread pending on a lock:
vmcompute.exe
containerd.exe
antrea-agent.exe
To fix this issue, we may check SourcePortId in each parent NBLs before
released.
A simple way to reprodue this issue:
1, Enable encap mode
2, create 2 nodes, nodeA and nodeB
3, create podA with image k8s.gcr.io/e2e-test-images/agnhost:2.21 on
nodeA, run 'iperf/iperf.exe -s -p 9000 -D'
4, create podB with same image on nodeB, run command
'iperf/iperf.exe -c <podA-ip> -p 9000'
5, delete podB
6, run 'Get-NetAdapter' on nodeB, you will find the leaked net adapter.
Signed-off-by: Hongsheng Xie <hxie@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Implementation on Windows:
Currently, IPv4 conntrack was supported on the windows platform.
In this patch we have implemented ipv6 conntrack functions according
to the current logic of the IPv4 conntrack. This implementation has
included TcpV6(nat and normal scenario), UdpV6(nat and normal scenario),
IcmpV6 conntrack of echo request/reply packet and
FtpV6(nat and normal scenario).
Testing Topology:
On the Windows VM runs on the ESXi host, two hyper-v ports attached
to the ovs bridge; one hyper-v port worked as client and the
other port worked as server.
Testing Case:
1. TcpV6
a) Tcp request/reply conntrack for normal scenario.
In this scenario, 20::1 as client, 20::2 as server, it will generate
following conntrack entry:
(Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556),
reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=tcp)
b) Tcp request/reply conntrack for nat scenario.
In this scenario, 20::1 as client, 20::10 as floating ip, 21::3 as server,
it will generate following conntrack entry:
(Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556),
reply(src=21::3, src_port=1556, dst=20::1, dst_port= 1555),protocol=tcp)
2. UdpV6
a) Udp request/reply conntrack for normal scenario.
(Origin(src=20::1, src_port=1555, dst=20::2, dst_port=1556),
reply(src=20::2,src_port=1556,dst=20::1,dst_port=1555),protocol=udp)
b) Udp request/reply conntrack for nat scenario.
(Origin(src=20::1, src_port=1555, dst=20::10, dst_port=1556),
reply(src=21::3, src_port=1556, dst=20::1, dst_port= 1555),protocol=udp)
3. IcmpV6:
a) Icmpv6 request/reply conntrack for normal scenario.
Currently Icmpv6 only support to construct conntrack for
echo request/reply packet, take (20::1 -> 20::2) for example,
it will generate following conntrack entry:
(origin(src = 20::1, dst=20::2), reply(src=20::2, dst=20::1), protocol=icmp)
b) Icmp request/reply conntrack for dnat scenario,
for example (20::1->20::10->21::3), 20::1 is
client, 20::10 is floating ip, 21::3 is server ip.
It will generate flow like below:
(origin(src=20::1, dst=20::10), reply(src=21::3, dst=20::1), protocol=icmp)
4. FtpV6
a) Ftp request/reply conntrack for normal scenario.
In this scenario, take 20::1 as client, 20::2 as server, it will generate
two conntrack entries:
Ftp active mode
(Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21),
reply(src=20::2, src_port=21, dst=20::1, dst_port=1555), protocol=tcp)
(Origin(src=20::2, src_port=20, dst=20::1, dst_port=1556),
reply(src=20::1, src_port=1556, dst=20::2, dst_port=20), protocol=tcp)
Ftp passive mode
(Origin(src=20::1, src_port=1555, dst=20::2, dst_port=21),
reply(src=20::2,src_port=21,dst=20::1,dst_port=1555),protocol=tcp)
(Origin(src=20::1, src_port=1556, dst=20::2, dst_port=1557),
reply(src=20::2,src_port=1557, dst=20::1, dst_port=1556) protocol=tcp)
b) Ftp request/reply conntrack for nat scenario.
Ftp passive mode,
In this secnario, 20::1 as client, 20::10 as floating ip, 21::3 as server
ip. It will generate following flow:
(Origin(src=20::1, src_port=1555, dst=20::10, dst_port=21),
reply(src=21::3, src_port=21, dst=20::1, dst_port= 1555),protocol=tcp)
(Origin(src=20::1, src_port=1556, dst=20::10, dst_port=1557),
reply(src=21::3, src_port=1557, dst=20::1, dst_port= 1556),protocol=tcp)
5. Regression test for IpV4 in Antrea project (about 60 test case)
Future work:
1) IcmpV6 redirect packet conntrack.
2) IpV6 fragment support on Udp.
3) Support napt for IPv6.
4) FtpV6 active mode for nat.
Signed-off-by: ldejing <ldejing@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>
Currenlty Ovs-windows can not change tos using NXM_OF_IP_TOS, this patch fixes it.
1, test with the following flow :
ovs-ofctl.exe add-flow br-int "table=0,priority=300,in_port=antrea-gw0,icmp actions=mod_nw_tos:28,load:0x1->NXM_NX_REG0[0..3],resubmit(,SpoofGuard)"
2, capture packet trace on destination side :
02:23:30.625049 IP (tos 0x1c, ttl 128, id 15237, offset 0, flags [none], proto ICMP (1), length 60)
192.168.250.1 > 192.168.248.1: ICMP echo request, id 1, seq 10, length 40
Reported-at:openvswitch/ovs-issues#244
Signed-off-by: Frank Guo <frankg@vmware.com>
Acked-by: Mike Pattrick <mkp@redhat.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
CT marks which are loaded in non-first commit will be lost in ovs-windows.In linux OVS,
the CT mark setting with same flow could be set successfully.
Currenlty Ovs-windows will create one new CT with the flowKey(Extracted from the packet itself)
If the packet is already done DNAT action after the 1st round flow processing. So the ct-mark
Set on previous Conntrack will be lost.In the fix, it will make use of CT tuple src/dst address
stored in the flowKey if the value is not zero and zone in the flowKey is same as the input zone.
In the fix, it is also to adjust function OvsProcessDeferredActions to make it clear.
//DNAT flow
cookie=0x1040000000000, duration=950.326s, table=EndpointDNAT, n_packets=0, n_bytes=0, priority=200,tcp,reg3=0xc0a8fa2b,reg4=0x20050/0x7ffff
actions=ct(commit,table=AntreaPolicyEgressRule,zone=65520,nat(dst=192.168.250.43:80),exec(load:0x1->NXM_NX_CT_MARK[2])
// Append ct_mark flow
cookie=0x1000000000000, duration=11980.701s, table=SNATConntrackCommit, n_packets=6, n_bytes=396, priority=200,ct_state=+new+trk,ip,reg0=0x2
00/0x200,reg4=0/0xc00000 actions=load:0x3->NXM_NX_REG4[22..23],ct(commit,table=SNATConntrackCommit,zone=65520,exec(load:0x1->NXM_NX_CT_MARK[4
],load:0x1->NXM_NX_CT_MARK[5]))
// SNAT flow
cookie=0x1000000000000, duration=11980.701s, table=SNATConntrackCommit, n_packets=6, n_bytes=396, priority=200,ct_state=+new+trk,ip,reg0=0x6
00/0x600,reg4=0xc00000/0xc00000 actions=ct(commit,table=L2Forwarding,zone=65521,nat(src=192.168.250.1),exec(load:0x1->NXM_NX_CT_MARK[2]))
Reported-at:https://github.com/openvswitch/ovs-issues/issues/237
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
While testing OVS-windows flows for the Ip fragments, the traffic will be dropped
As it may match incorrect OVS flow. From the code, after the Ipv4 fragments are
Reassembled, it willl still use the flow key of the last Ipv4 fragments to match
CT causing match error.
Reported-at:https://github.com/openvswitch/ovs-issues/issues/232
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
While testing OVS-windows flows for the DNAT/SNAT action, the checksum in
TCP header is set incorrectly when TCP offload is enabled by default. As a
result,the packet will be dropped on the Windows VM when processing the packet
from Linux VM which has included correct checksum at first. On the Windows VM,
it has gone through two NAT actions and OVS Windows kernel will reset the
checksum to PseudoChecksum and then it will lose the original correct checksum
value which is set outside.
Back to the Nat TCP/UDP checksum value reset logic,it should reset it TCP checksum
To be PseudoChecksum value only on Tx direction for TCP Offload case. For the packet
From the outside, OVS Windows Kernel does not need reset the TCP/UDP checksum as
It should be the job of the received network driver to get out a correct checksum
Value.
>>>sample flow on default configuration on both Windows VM and Linux VM
(src=192.168.252.1,dst=10.110.225.146)-->dnat/snat-> (src=169.254.169.253,
Dst=10.176.26.107) Without the fix the return back packet(src=10.176.26.107,
Dst=169.254.169.253) will have the correct TCP checksum. After the reverse NAT
Actions, it will be changed to be packet (src=10.110.225.146, Dst=192.168.252.1)
But with incorrect TCP checksum 0xa97a which is
The PseudoChecksum. Related packet is put on the reported issue below.
Reported-at:https://github.com/openvswitch/ovs-issues/issues/231
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Currently the layers info propogated to ProcessDeferredActions may be
incorrect. Because of this, any subsequent usage of layers might result
in undesired behavior. Accordingly in this patch it will add the related
layers in the deferred action to make sure the layers consistent with
the related NBL.
In the specified case 229, we have encountered one issue when doing
the decap Geneve Packet and doing the twice NAT(via two flow tables)
and found the HTTP packet will be changed the TCP sequence.
After debugging, we found the issue is caused by the not-updated
layers value isTcp and isUdp for Geneve decapping case.
The related function call chains are listed below,
OvsExecuteDpIoctl—>OvsActionsExecute—>OvsDoExecuteActions->OvsTunnelPortRx
——>OvsDoExecuteActions——〉nat ct action and recircle action
->OvsActionsExecute->defered_actions processing for nat and recircle action
For the Geneve packet decaping, it will firstly set the layers for Udp packet.
Then it will go on doing OVS flow extract to get the inner packet layers and
Processing the first nat action and first recircle action. After that datapath
Will do defered_actions processing on OvsActionsExecute. And it does inherit
The incorrect geneve packet layers value( isTCP 0 and isUdp 1).So in the second
Nat action processing it will get the wrong TCP Headers in OvsUpdateAddressAndPort
And it will update related TCP check field value but in this case it will change
The packet Tcp seq value.
Reported-at:https://github.com/openvswitch/ovs-issues/issues/229
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
This patch specifies the file digest algorithm for signtool on the package
and ovsext VS projects.
Fixes broken appveyor build.
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Acked-by: Aaron Conole <aconole@redhat.com>
In one typical setup, on the Windows VM running OVS Windows Kernel, a Geneva
packet with 8021.q VLAN tag is received. Then it may do POP_VLAN action
processing in Actions.c, if the packet does not have Ieee8021QNetBufferListInfo
in the oob of the packet, it will be processed by function OvsPopVlanInPktBuf().
In the function it will go on remove VLAN header present in the nbl, but related
layers is never readjusted for the offset value at this moment. As a result, it
will cause function OvsValidateIPChecksum drop the packet.
Reported-at:https://github.com/openvswitch/ovs-issues/issues/225
Signed-off-by: wilsonpeng <pweisong@vmware.com>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
While testing OVS-windows flows for the DNAT action, the checksum
In TCP header is set incorrectly when TCP offload is enabled by
Default. As a result, the packet will be dropped on receiver linuxVM.
>>>sample flow default configuration on both Windows VM and Linux VM
(src=40.0.1.2,dst=10.150.0.1) --dnat--> (src=40.0.1.2,dst==30.1.0.2)
Without the fix for some TCP packet(40.0.1.2->30.1.0.2 with payload
len 207) the TCP checksum will be pseduo header checksum and the value
is 0x01d6. With the fix the checksum will be 0x47ee, it could be got
the correct TCP checksum on the receiver Linux VM.
Signed-off-by: Wilson Peng<pweisong@vmware.com>
Signed-off-by: Anand Kumar<kumaranand@vmware.com>
Acked-by: Alin-Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin-Gabriel Serdean <aserdean@ovn.org>
It is useful to build the latest supported version of the driver using the
`make` command.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Ilya Maximets <i.maximets@ovn.org>
The flow key is not updated when process OVS_ACTION_ATTR_SET action.
It will impact follow-up actions, such as, conntrack module cannot
find created conntrack entry if passing old flow key to it.
Reported-by: Rui Cao <rcao@vmware.com>
Signed-off-by: Jinjun Gao <jinjung@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
The ct_mark/ct_label setting on related connection keep the same
behavior with Linux datapath. If one CT entry has parent/master entry,
its ct_mark and ct_label should inherit from the corresponding part
of parent/master entry at initialization.
Signed-off-by: Jinjun Gao <jinjung@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
Add helper and master if existing to a conntrack entry:
1, For CTA_HELP, only support FTP/TFTP;
2, For CTA_TUPLE_MASTER, only support FTP.
Signed-off-by: Jinjun Gao <jinjung@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
On windows, if we send a connection setup packet in one direction
twice, it will make the connection to be in established state. The
same issue happened in Linux userspace conntrack module and has
been fixed.
This patch port the following previous fixes to windows datapath to
fix the issue:
- a867c010ee9183885ee9d3eb76a0005c075c4d2e
- ac23d20fc90da3b1c9b2117d1e22102e99fba006
Acked-by: Yi-Hung Wei <yihung.wei@gmail.com>
Signed-off-by: Rui Cao <rcao@vmware.com>
Signed-off-by: William Tu <u9012063@gmail.com>
Formerly, there is no tunnel information appended in the upcall’s
packet data, which is expected by IPFIX in userspace to calculate
the template for exporting the sampled flow record of on egress
tunnel port.
To fix this, during performing OvsOutputUserspaceAction(), we
would check whether it is initiated by the sampling on egress
tunnel which would be indicated by the attribute as
OVS_USERSPACE_ATTR_EGRESS_TUN_PORT in the nested attribute
list. If so, we would append the tunKey in OvsForwardingContext
indexed by OVS_PACKET_ATTR_EGRESS_TUN_KEY to the upcall.
Besides, at this point, the source transport port and source ip
address are not available in the structure, so we have to fill it in the
way how the packet would be capsulated during performing
OvsEncapGeneve(), which is following the
OvsOutputUserspaceAction() unfortunately.
I have tested the IPFIX functionality with the change, we could see the
template is correct and the expected tunnel information could be
packed in the IPFIX packet finally. The traffic for test is generated by
PING utility.
>From d727d051c9a44a4a93e5ee5f3da3ca9b125aad29 Mon Sep 17 00:00:00 2001
From: Amber Hu <qhu@vmware.com>
Date: Thu, 30 Jan 2020 18:01:32 -0800
Subject: [PATCH v3] datapath-windows: Append tunnel info to upcall for correct
template
Signed-off-by: Amber Hu <qhu@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
According to the microsoft doc:
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/hyper-v-extensible-switch-port-and-network-adapter-states
Below OID request sequence is validation:
OID_SWITCH_NIC_CONNECT -> OID_SWITCH_NIC_DISCONNECT
^ |
| V
OID_SWITCH_NIC_CREATE <- OID_SWITCH_NIC_DELETE
In above sequence, the windows extensible switch interface assumes the
OID_SWITCH_PORT_CREATE has issued and the port has been created
successfully. If delete the internal port in HvDisconnectNic(),
HvCreateNic() will fail when received OID_SWITCH_NIC_CREATE late because
there is no corresponding port.
Signed-off-by: Jinjun Gao <jinjung@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
This patch first defines the dpif interface for a datapath to support
adding, deleting, getting and dumping conntrack timeout policy.
The timeout policy is identified by a 4 bytes unsigned integer in
datapath, and it currently support timeout for TCP, UDP, and ICMP
protocols.
Moreover, this patch provides the implementation for Linux kernel
datapath in dpif-netlink.
In Linux kernel, the timeout policy is maintained per L3/L4 protocol,
and it is identified by 32 bytes null terminated string. On the other
hand, in vswitchd, the timeout policy is a generic one that consists of
all the supported L4 protocols. Therefore, one of the main task in
dpif-netlink is to break down the generic timeout policy into 6
sub policies (ipv4 tcp, udp, icmp, and ipv6 tcp, udp, icmp),
and push down the configuration using the netlink API in
netlink-conntrack.c.
This patch also adds missing symbols in the windows datapath so
that the build on windows can pass.
Appveyor CI:
* https://ci.appveyor.com/project/YiHungWei/ovs/builds/26387754
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Justin Pettit <jpettit@ovn.org>
When an existing label needs to be changed by specifing bits to be
updated using mask, instead of updating only the masked bits,
new label was getting overridden. This patch fixes this issue.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
When a nbl is cloned, mru value stored in the original nbl
context is lost, which skips refragemting the cloned nbls.
This patch fixes it.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
This patch adds a new target called `Win10Analyze` to the driver solution.
It enables us to trigger static analysis over the Win10 target.
Since the location of the ruleset of drivers is somewhat random
starting from 1803:
https://www.osr.com/blog/2018/05/21/wdk-1803-ca/
Commit the ruleset inside our repository. This is the same ruleset used for
8,8.1 and 10.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Anand Kumar <kumaranand@vmware.com>
As per MSDN documentation, "As soon as a filter driver calls the
NdisFSendNetBufferLists function, it relinquishes ownership of
the NET_BUFFER_LIST structures and all associated resources.
A filter driver should never try to examine the NET_BUFFER_LIST
structures or any associated data after calling NdisFSendNetBufferLists".
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ndis/nf-ndis-ndisfsendnetbufferlists
When freeing up memory of a cloned nbl, parent's nbl and context
is being accessed, which is incorrect can cause BSOD.
With this patch, original nbl is sent out only when cloned nbl is done
with packet processing and its memory is freed.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Update flowkey to set vlan information in network byte order.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Protect internal adapter up/down calls with a dispatch lock. It was
observed that the InternalAdapter bind calls could happen out of order
thereby causing encap packets to not be sent properly.
Add assert around the IpHelper bind calls to ensure Up/Down gets called
only for the appropriate vports.
Signed-off-by: Sairam Venugopal <vsairam@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
With current implementation, when nbl pool is allocated, context size is
specified as 64 bytes, while the OVS_BUFFER_CONTEXT size is only 32 bytes.
Since context size is never changed, additional memory is not required.
This patch makes it simpler to allocate memory for OVS_BUFFER_CONTEXT so
that it is always aligned to MEMORY_ALLOCATION_ALIGNMENT.
This is acheived by updating "value" field in the context
structure, so that number of elements in array is always a multiple of
MEMORY_ALLOCATION_ALIGNMENT.
Also change the DEFAULT_CONTEXT_SIZE to accomodate OVS_BUFFER_CONTEXT size.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Add annotations to find vport functions to check if the dispatch lock is
held.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Sairam Venugopal <vsairam@vmware.com>
When using a vport we need to guard its usage with the dispatch lock.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Sairam Venugopal <vsairam@vmware.com>
Hold the dispatch lock until port-add operations are completed.
Found by inspection.
Signed-off-by: Sairam Venugopal <vsairam@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Move the EventQueue lock acquisition after the dispatchLock to prevent a
potential deadlock in port creation pipeline. There could be a case where
a port event could try to take up the Dispatch Lock before the Event Queue
lock and the subscription queue event could take up the event queue lock
before the dispatch lock.
Found while testing with Driver Verifier enabled.
Signed-off-by: Sairam Venugopal <vsairam@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
StartNblIngressError should be called only when an NBL hasn't been
modified. In this case the nbl context was initialized. Rely on existing
packet completion mechanism to cleanup the NBL.
Found while testing with DriverVerifier with limited memory setting
enabled.
Signed-off-by: Sairam Venugopal <vsairam@vmware.com>
Acked-by: Anand Kumar <kumaranand@vmware.com>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Add a new structure in l2 header to accomodate vlan header,
based of commit "d7efce7beff25052bd9083419200e1a47f0d6066
datapath: 802.1AD Flow handling, actions, vlan parsing, netlink attributes"
Also reset vlan header in flow key, after deleting vlan tag from nbl
With this change a sample vlan flow would look like,
eth(src=0a:ea:8a:24:03:86,dst=0a💿fa:4d:15:5c),in_port(3),eth_type(0x8100),
vlan(vid=2239,pcp=0),encap(eth_type(0x0800),ipv4(src=13.12.11.149,dst=13.12.11.107,
proto=1,tos=0,ttl=128,frag=no),icmp(type=8,code=0))
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
We need to hold the port lock until all the operations with a port are
completed.
Found by inspection.
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Acked-by: Anand Kumar <kumaranand@vmware.com>
- Rely on layers l3Offset field to get offset of IP header.
- Aslo fix passing 'newNbl' to IP fragment which is not required.
- Fixed including a header file twice.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
OVS_BUFFER_CONTEXT gets cleared as part of NdisFreeNetBufferListContext
function call. This causes an invalid reference error.
Found while testing with driver verifier enabled.
Signed-off-by: Sairam Venugopal <vsairam@vmware.com>
Acked-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Remove the IP neighboring entries when adapter is down,
so that when 'OVS_IPHELPER_INSTANCE' is deleted, no stale entries
are present
Also fix accessing iphelper instance without acquiring the lock.
Signed-off-by: Anand Kumar <kumaranand@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Tested-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
Move the IPHelper Instance to the main header file and update the usage to
explicitly point to POVS_IPHELPER_INSTANCE instead of PVOID. Also rename
the ipn->context to ipn->instance to make it more readable.
Found by inspection.
Signed-off-by: Sairam Venugopal <vsairam@vmware.com>
Acked-by: Alin Gabriel Serdean <aserdean@ovn.org>
Signed-off-by: Alin Gabriel Serdean <aserdean@ovn.org>
