| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | datapath-windows: Add IPv6 conntrack ip fragment support on windows | ldejing | 2022-09-20 | 1 | -2/+4 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add IPv6 conntrack support on Windows. | ldejing | 2022-04-22 | 1 | -0/+1 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Use only non executable memory | Alin Serdean | 2017-11-29 | 1 | -2/+1 |
| | | | | | | | | | | | | 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> | ||||
| * | datapath-windows: Improved offloading on STT tunnel | Paul Boca | 2016-06-07 | 1 | -42/+55 |
| | | | | | | | | | | | | | | | | | | *Added OvsExtractLayers - populates only the layers field without unnecessary memory operations for flow part *If in STT header the flags are 0 then force packets checksums calculation on receive. *Ensure correct pseudo checksum is set for LSO both on send and receive. Linux includes the segment length to TCP pseudo-checksum conforming to RFC 793 but in case of LSO Windows expects this to be only on Source IP Address, Destination IP Address, and Protocol. *Fragment expiration on rx side of STT was set to 30 seconds, but the correct timeout would be TTL of the packet Signed-off-by: Paul-Daniel Boca <pboca@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org> | ||||
| * | datapath-windows: Removed double initialization on local variables | Paul Boca | 2016-04-21 | 1 | -1/+0 |
| | | | | | | | 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: Support for OVS_KEY_ATTR_MPLS attribute | Sorin Vinturis | 2016-02-02 | 1 | -6/+6 |
| | | | | | | | | | | | | | This patch adds OVS_KEY_ATTR_MPLS to the OVS flow mechanism. Tested using ping. Tested using iperf (TCP and UDP). Tested using DriverVerifier. Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Gurucharan Shetty <guru@ovn.org> | ||||
| * | datapath-windows: Support for OVS_KEY_ATTR_SCTP attribute | Sorin Vinturis | 2015-11-24 | 1 | -0/+15 |
| | | | | | | | | | This patch adds OVS_KEY_ATTR_SCTP to the OVS flow mechanism. Signed-off-by: Sorin Vinturis <svinturis@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Ben Pfaff <blp@ovn.org> | ||||
| * | Revert "datapath-windows: Support attribute OVS_KEY_ATTR_TCP_FLAGS" | Alin Serdean | 2015-10-27 | 1 | -1/+0 |
| | | | | | | | | | | | | | | | This reverts commit a26b2023ce33fed1ef962012dc2c03765d2e92cb. This patch punishes performance without the implementation of megaflows on Windows. Once megaflows is implemented in the flow logic this patch will be revisited. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Sairam Venugopal <vsairam@vmware.com> Signed-off-by: Gurucharan Shetty <gshetty@nicira.com> | ||||
| * | datapath-windows: Support attribute OVS_KEY_ATTR_TCP_FLAGS | Alin Gabriel Serdean | 2015-10-23 | 1 | -0/+1 |
| | | | | | | | | | | | | | This patch adds OVS_KEY_ATTR_TCP_FLAGS to our flow mechanism. Also clean unecesarry parts of code. 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: Nithin Raju <nithin@vmware.com> Signed-off-by: Gurucharan Shetty <gshetty@nicira.com> | ||||
| * | datapath-windows: Fix IP fragmentation | Alin Serdean | 2015-10-02 | 1 | -3/+3 |
| | | | | | | | | | | | | | | Currently in the case of IP fragmentation we send to the userspace that the flag for the last fragment is 3 when it actually should be a value between 0..2. This patch fixes the problem and also uses the values used in the common header of the datapath. Signed-off-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Nithin Raju <nithin@vmware.com> Signed-off-by: Ben Pfaff <blp@nicira.com> | ||||
| * | datapath-windows: Rename files. | Samuel Ghinet | 2014-08-29 | 1 | -0/+303 |
| This patch includes the file renaming and accommodations needed for the file renaming to build the forwarding extension for Hyper-V. This patch is also a follow-up for the thread: http://openvswitch.org/pipermail/dev/2014-August/044005.html Signed-off-by: Samuel Ghinet <sghinet@cloudbasesolutions.com> Co-authored-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com> | |||||
 |
index : delta/openvswitch.git | |
| github.com: openvswitch/ovs.git |
| summaryrefslogtreecommitdiff |