summaryrefslogtreecommitdiff
path: root/datapath-windows/ovsext/Actions.c
Commit message (Collapse)AuthorAgeFilesLines
* datapath-windows: Check the condition to reset pseudo header checksum on Rx sideWilson Peng2022-11-241-4/+23
| | | | | | | | | | | | | | | 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>
* datapath-windows: support meter action initial versionldejing2022-09-201-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* datapath-windows: Add IPv6 conntrack ip fragment support on windowsldejing2022-09-201-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* datapath-windows: Alg support for ftp and tftp in conntrackldejing2022-09-201-1/+0
| | | | | | | | | | | | | | | | | | | | | 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>
* datapath-windows: Update layers for multiple tunnels processingWilson Peng2022-06-221-1/+20
| | | | | | | | | | | | | | | | | | | 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>
* datapath-windows: Add IPv6 conntrack support on Windows.ldejing2022-04-221-0/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* datapath-windows: Add IPv6 Geneve tunnel support in WindowsWilson Peng2022-04-101-25/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* datapath-windows: Fix NXM_OF_IP_TOS issueFrank Guo2022-02-231-0/+9
| | | | | | | | | | | | | | | 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>
* datapath-windows: Pickup Ct tuple as CT lookup key in function ↵Wilson Peng2022-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OvsCtSetupLookupCtx 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>
* datapath-windows:Reset PseudoChecksum value only for TX direction offload caseWilson Peng2021-10-281-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* datapath-windows: add layers when adding the deferred actionsWilson Peng2021-10-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* datapath-windows:adjust Offset when processing packet in POP_VLAN actionwilsonpeng2021-09-301-3/+15
| | | | | | | | | | | | | | 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>
* datapath-windows:Correct checksum for DNAT actionWilson Peng2021-07-211-0/+12
| | | | | | | | | | | | | | | | | | 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>
* datapath-windows: Update flow key in SET actionJinjun Gao2020-07-291-7/+24
| | | | | | | | | | 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>
* datapath-windows: Append tunnel info to upcall for correct templateAmber Hu via dev2020-02-101-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* datapath-windows: Add support for 'OVS_KEY_ATTR_ENCAP' key attribute.Anand Kumar2019-01-281-0/+3
| | | | | | | | | | | | | | | | | 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:cd: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>
* datapath-windows: Add support for handling DEI bit of VLAN headerAnand Kumar2018-06-111-0/+1
| | | | | | | | | | The Drop eligible indicator(DEI) is 1 bit wide and it is part of Tag control information (TCI) in VLAN header, which indicates that the frame can be dropped during congestion. 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>
* datapath-windows: Add assert to ethHdr in OvsActionMplsPushAlin Serdean2017-11-291-0/+1
| | | | | | | | | `ethHdr` cannot be NULL because we did a partial copy before it. Add an assert to keep the static analysis happy. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Shashank Ram <shashank08@gmail.com>
* datapath-windows: Remove the workaround in NAT for TCP checksumAnand Kumar2017-10-161-49/+11
| | | | | | | | | When checksum offload is enabled, compute checksum using the TCP pseudo header. 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>
* datapath-windows: Remove unnecessary call to OvsInitForwardingCtxAnand Kumar2017-09-041-8/+1
| | | | | | | | | | | Only curNbl in the forwarding context needs to be updated with fragmented NBL. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Acked-by: Shashank Ram <rams@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>
* datapath-windows: Add an assert in recirculationAlin Serdean2017-08-021-0/+1
| | | | | | | | | `ovsFwdCtx.switchContext` can't be null since it is passed from actions. Add an assert to keep the static analyzer happy. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Shashank Ram <rams@vmware.com>
* datapath-windows: Add validations in fragmentation moduleAnand Kumar2017-07-101-1/+1
| | | | | | | | | | | | | | | - Minimum valid fragment size is 400 bytes, any fragment smaller is likely to be intentionally crafted (CVE-2000-0305). - Validate maximum length of an Ip datagram - Added counters to keep track of number of fragments for a given Ip datagram. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com>
* windows-datapath: Temporary workaround checksum issue with NATAlin Gabriel Serdean2017-06-121-0/+38
| | | | | | | | | | There is a known bug with NAT where checksum computation is wrong on the RX path if offload is enabled. This patch works around the problem by always computing a software checksum and should be reverted once we figure out the root cause of checksum error. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: NAT integration with conntrackYin Lin2017-06-121-3/+116
| | | | | | | | | This patch integrates NAT module with existing conntrack module. NAT action is now supported. Signed-off-by: Yin Lin <linyi@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Update the key after defragmentationAlin Serdean2017-05-231-0/+1
| | | | | | | | | | | Update the key used by the actions which follow up defragmentation, with no fragment set in the IP header. Found while testing OVN with two VMs on the same host. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Anand Kumar kumaranand@vmware.com Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Report success for conntrack actions over fragsAlin Serdean2017-05-231-0/+5
| | | | | | | | | | | | When a conntrack action is applied over an IP fragment we pend the fragment which will be consumed later. This should be transparent to the userspace. Report that the action was applied successfully so it does not spam the ovs-vswitchd log. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Anand Kumar <kumaranand@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Fix alignment in actionsAlin Serdean2017-05-231-12/+12
| | | | | | | | Found by inspection. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org> Acked-by: Anand Kumar <kumaranand at vmware.com>
* datapath-windows: Fragment NBL based on MRU sizeAnand Kumar2017-05-081-1/+50
| | | | | | | | | | This patch adds support for Fragmenting NBL based on the MRU value. MRU value is updated only for Ipv4 fragments, if it is non zero, then fragment the NBL and send out the new NBL to the vnic. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
* datapath-windows: Added Ipv4 fragments support in ConntrackAnand Kumar2017-05-081-2/+19
| | | | | | | | | | | This patch adds support for tracking Ipv4 fragments in conntrack module. Individual fragments are not tracked and are consumed by the fragmentation/reassembly. Only the reassembled Ipv4 datagram is tracked and treated as a single ct entry. Signed-off-by: Anand Kumar <kumaranand@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com>
* datapath-windows: Pass fwdCtx to conntrackYin Lin2017-04-211-59/+2
| | | | | | | | | | There are dependencies in Contrack module such as NAT and fragmentation on OvsForwardingContext. This patch will make OvsForwardingContext public in order to implement these functionalities. Signed-off-by: Yin Lin <linyi@vmware.com> Acked-by: Alin Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Allow tunnel action to modify destination portAlin Serdean2017-02-021-2/+2
| | | | | | | | | | | | 'OvsTunnelAttrToIPv4TunnelKey' modifies 'tunkey' with the received netlink attributes(i.e. OVS_TUNNEL_KEY_ATTR_IPV4_DST). Change the order of the value assignment to reflect the values received via userspace. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@ovn.org> Acked-by: Sairam Venugopal <vsairam@vmware.com>
* datapath-windows: Add a wrapper to retreive external vportShashank Ram2017-01-271-4/+4
| | | | | | | | This wrapper is to simplify readability. Signed-off-by: Shashank Ram <rams@vmware.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Add support for OVS_KEY_ATTR_TCP set actionAlin Serdean2017-01-271-0/+48
| | | | | | | | | | | | | | This patch adds support for set action with OVS_KEY_ATTR_TCP attribute (change TCP source or destination port). If the source or destination TCP port was changed, update the TCP checksum. A sample flow can look like the following: set(tcp(src=80,dst=443)) Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Add support for OVS_KEY_ATTR_UDP set actionAlin Serdean2017-01-271-1/+51
| | | | | | | | | | | | | | This patch adds support for set action with OVS_KEY_ATTR_UDP attribute (change UDP source or destination port). If the source or destination UDP port was changed, update the UDP checksum. A sample flow can look like the following: set(udp(src=67,dst=68)) Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Add function to get continuous buffer from contextAlin Serdean2017-01-271-38/+62
| | | | | | | | | | | | | This patch extracts the code that tries to get a continuous IPv4 header buffer from the function 'OvsUpdateIPv4Header' and moves it to a new function 'OvsGetHeaderBySize'. The new function can be used later when trying to change the UDP/TCP/MPLS etc., headers. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: OvsUpdateIPv4Header remove unnecessary additionAlin Serdean2017-01-271-4/+4
| | | | | | | | | bufferStart can be used directly to access the data of the net buffer. Add the MDL offset to save unnecessary additions. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Fix typo in OvsUpdateIPv4HeaderAlin Serdean2017-01-061-1/+1
| | | | | | | Found by inspection. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* datapath-windows: Add multiple switch internal portsAlin Serdean2016-12-201-28/+21
| | | | | | | | | | | | 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>
* datapath-windows: Fix issues related to packet completionShashank Ram2016-12-151-5/+20
| | | | | | | | | | | | | | | In OvsTunnelPortTx() function, for packets coming from the VIF port, the srcVportNo, srcPortId and srcNicIndex were getting modified for the original NBL prior to creation of newNbl. This is not correct since modifying the original packet's forwarding detail can cause completion issues. Instead, we should keep the forwarding detail of the original packet as is, and only update the forwarding detail for the newNbl. Signed-off-by: Shashank Ram <rams@vmware.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: pop buffer from packet / pop_vlan bugAlin Serdean2016-11-291-5/+10
| | | | | | | | | | | | | | | | Switch too memmove(RtlMoveMemory) instead of copy and predefined allocated buffer. Currently if we receive a pop_vlan action, and the vlan tag is inside the Ethernet frame(not in the net buffer list information) we change the frame without checking if the it was a vlan tagged or not. This patch checks if it a vlan tagged frame and makes the action a non-operation. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Encapsulate packet when src port is tunnel portSairam Venugopal2016-09-021-2/+3
| | | | | | | | | | | | | | | | | | | | If a packet arrives on a tunnel port and is again transmitted on a tunnel port, the packet needs to be encapsulated. Eg: Sample flow which arrives on a tunnel port and gets encapsulated again. eth(src=00:15:5d:ae:b7:b1,dst=ff:ff:ff:ff:ff:ff),in_port(5),eth_type(0x0806), arp(sip=192.168.1.12,tip=192.168.1.78,op=1,sha=00:15:5d:ae:b7:b1,tha=00:00:00:00:00:00), tunnel(tun_id=0x5b88,dst=192.165.226.191,src=192.166.255.253,tos=0,ttl=63, geneve({class=0x104,type=0x80,len=4,0x11680100}),flags(key)) actions:set(tunnel(tun_id=0x5b88,dst=192.165.226.190,ttl=64, geneve({class=0x104,type=0x80,len=4,0x1680100}),flags(df|csum|key))),5,4 Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Add Geneve supportYin Lin2016-06-241-52/+20
| | | | | | Signed-off-by: Yin Lin <linyi@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: use ip proto for tunnel port lookupNithin Raju2016-06-171-21/+21
| | | | | | | | | | | | | | | | | | In Actions.c, based on the IP Protocol type and L4 port of the outer packet, we lookup the tunnel port. The function that made this happen took the tunnel type as an argument. Semantically, is is better to pass the IP protocol type and let the lookup code map IP protocol type to tunnel type. In the vport add code, we make sure that we block tunnel port addition if there's already a tunnel port that uses the same IP protocol type and L4 port number. Signed-off-by: Nithin Raju <nithin@vmware.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Yin Lin <linyi@vmware.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org>
* datapath-windows: Sample action support.Sorin Vinturis2016-06-141-33/+148
| | | | | | | | | | | | | This patch adds support for sampling to the OVS extension. The following flow was used for generating sample actions: ovs-ofctl add-flow tcp:127.0.0.1:9999 "actions=sample( probability=12345,collector_set_id=23456,obs_domain_id=34567, obs_point_id=45678)" Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* datapath-windows: remove extract flow in OvsDoRecirc()Nithin Raju2016-05-251-9/+0
| | | | | | | | | | | | | It is not necessary to do a flow extract in OvsDoRecirc(). In fact, doing it would overwrite the tunnel key within 'key'. So, let's remove the call. Signed-off-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Co-Authored-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Paul-Daniel Boca <pboca@cloudbasesolutions.com> Signed-off-by: Joe Stringer <joe@ovn.org>
* datapath-windows: Fix recirculation when it is not the last attributeSairam Venugopal2016-04-271-2/+6
| | | | | | | | | | When the recirc action is in middle, the current code creates a clone of the NBL. However, it overwrites the pointer to point to the cloned NBL without completing it. This causes a memory leak that crashes the kernel. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* datapath-windows: Removed double initialization on local variablesPaul Boca2016-04-211-5/+5
| | | | | | Signed-off-by: Paul-Daniel Boca <pboca@cloudbasesolutions.com> Acked-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* datapath-windows: Add Connection Tracking SupportSairam Venugopal2016-04-141-0/+23
| | | | | | | | | | | | | | | | | | | | Enable support for Stateful Firewall in Hyper-V by adding a Connection Tracking module. The module has been ported over from the userspace implementation patch of a similar name. The current version of the module supports ct - zone, mark and label for TCP packets. Support for other packet formats will be added in subsequent patches. The conntrack-tcp module is adapted from FreeBSD's pf subsystem and hence the BSD license. It has been ported over to match OVS Hyper-V coding style. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Daniele Di Proietto <diproiettod@vmware.com> Co-Authored-by: Daniele Di Proietto <diproiettod@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* datapath-windows: Update Recirculation to use portId instead of portNoSairam Venugopal2016-03-311-1/+1
| | | | | | | | | | Fix OvsDoRecirc to use the right PortId when there is a flow miss. This is used to determine if a packet is received or transmitted by comparing against the virtualExternalPortId. Signed-off-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* datapath-windows: Support for OVS_ACTION_ATTR_HASH attributeSorin Vinturis2016-03-251-0/+38
| | | | | | | Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
View Lorry Controller Status