Hi Ian,
Thank you for working on this.
This feature is going to be very useful in OVS-DPDK deployment.
I also did some basic testing of this implementation.
Here are the comments,
1) The dpctl show still shows the port as vxlan. It must be changed to
vxlan-ipsec
2) Its mentioned in the cover letter, however I see the flows stats are
looks ok. Only the port stats are need to be properly handled.
3) The dpctl/dump-flows says the actions as vxlan. It should be
vxlan-ipsec .
4) I think the ovs-vsctl show should be extended to show the SPI
information.(Even its static for now)
5) Similarly the ipsec port should provided with security association
it is using. This should be in the options.
6) I tried to do run a following test on the ipsec tunnel
implementation and it looks like there is some issue with rule translation as I
don’t see the packets are forwarding.
PKT-IN -->BR1--(ENCAP)-->BR2 -->(MOD-PKT 'patch
port')---->BR3-->(DECAP) -->BR4.
I see the encap is happening and but nothing afterwards. It works fine
on normal VxLAN.
Regards
_Sugesh
> -----Original Message-----
> From: [email protected] [mailto:ovs-dev-
> [email protected]] On Behalf Of Ian Stokes
> Sent: Friday, August 25, 2017 5:40 PM
> To: [email protected]
> Subject: [ovs-dev] [RFC PATCH v2 00/10] RFC for Userspace IPsec Interface
>
>
[snip]
>
> The flow structer has been modified to allow the storing of the ESP SPI value
[Sugesh] structure?
> of a packet. The Minflow extract process has been modified accordingly.
>
> Base IPsec functionality has been detailed in 'Docs: Update releases with
> IPsec feature support info.'
>
> A proposed design of a new IPsec interface is included with its options in the
> 'vswitch.xml: Detail ipsec user interface' RFC. Note this is the final target
> the
> patch series should resemble as development continues.
>
> A `how-to` guide has been added to provide some context of how the IPsec
> interface would be configured by a user in the 'Docs: Add userspace-ipsec
> how to guide.'
>
> Please note this is a early approach and is not intended for upstreaming,
> instead it is to provide an insight into some of the requirements the work
> will
> have. It is subject to change following feedback from the community and
> ongoing investigation during future RFC implementations.
>
>
> (ii) Known Issues
>
> As investigation progresses I'm sure there will be more opens to be added to
> the list below, but from the outset there are a few issues I'd like to flag
> at this
> stage as the patch the feature is still in development.
>
> (1) Cipher/Authentication Algorithms: The current RFC is limited in that the
> algorithm used for cipher/authentication are hard coded to 128 AES-CBC and
> HMAC-SHA1-96 respectively. Keys are also hardcoded. I will add the ability to
> read keys from a user in the next revision along with selection of algorithms
> for the operations. The current series should provide a feel for how crypto
> operations work with DPDK.
>
> (2) Crypto device: Currently only software crypto devices are supported,
> specifically the AESN-NI vdev PMD in DPDK.
>
> (3) Single PMD support within OVS: The current RFC is limited to running on a
> single PMD.
> Running it with more than 1 PMD will (probably) cause a segfault. Multiple
> pmd support will be added in the next revision after some discussion on how
> cryptodevs should be accessed on a multi core system.
>
> (4) Use of DPDK crypto devs requires installing the Intel(R) Multi-Buffer
> Crypto for IPSec library. This is an opensource library available on github
> and
> is used by DPDK to perform crypto operations when with a vdev such as the
> AESN-NI PMD. Setup instructions have been included in the patch series.
>
> (5) Stats: I haven’t looked into how this will affect stats within OVS yet
> but
[Sugesh] There are some special characters.
> this is another item I will look at for the next revision in the series.
>
> (6) OVS mode: The series has been tested with OVS with DPDK only. A few
> rte libraries have been introduced to areas where DPDK previously was not
> active, for instance the tunneling code. I'm aware that this will break
> compilation if a user compiles OVS without DPDK. How the libraries should be
> introduced to prevent this is an item I would be interested in receiving
> feedback on as I will be working on this for the next revision.
[Sugesh] I think this shouldn’t be a problem as you are not using any of
existing tunnel interface.
May be its worth to considering enabling ipsec only when DPDK support is
available in OVS.
Also the changes are on only on native tunnel, this shouldn’t break non DPDK
build.
[snip]
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
