Re: [ovs-discuss] SSH over GRE tunnel, MTU 1500 devices in VMs on same physical host

[Gregory Rose]

On 11/29/2017 12:12 PM, Orabuntu-LXC wrote:

Hi,

I have what is probably a dumb question so it should be an easy one 
for gurus.


I built two VM's on VirtualBox using my Orabuntu-LXC software.  The VM 
VNIC's are ports on OvS sw1 on each VM.  The VM's are on the same 
physical host.  I have LXC containers on the sw1 switch also.  What 
has surprised me with this setup is that I can ssh between containers 
that are on different VMs and all the network devices, the VNIC's and 
the OvS switches, and the physical interface on the host, are all set 
to MTU 1500.  Not anywhere in this setup is MTU 1420 used.  My 
understanding was, and what I have found in all previous cases, was 
that I had to use MTU 1420 for ssh over a GRE tunnel to allow for 
encapsulation, so my question is I am wondering how can ssh be working 
over this GRE tunnel when all the MTU of all devices is set to 1500?


ssh will use smaller packets  for most terminal oriented applications.  
Perhaps you're not exchanging traffic with larger packet sizes.


Try iperf or something like that which will use maximum size MTUs

- Greg



TIA

--
Gilbert Standen
Creator Orabuntu-LXC
914-261-4594
gilb...@orabuntu-lxc.com 



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Idea of an ovn native "rally"

[Han Zhou]

Hi folks,

Yes, this project is based on Rally. We had to modify it a little bit for
it to work without OpenStack. It is mentioned in the installation guide
here: http://ovn-scale-test.readthedocs.io/en/latest/install.html

We started the project in 2016. Lei released an initial version, and then
it became a joint effort with IBM folks. This project helped a lot in
identifying scaling issues of ovn, and also verified many improvements. We
talked about this in Austin OS summit (
https://www.openstack.org/videos/austin-2016/practical-ovn-architecture-deployment-and-scale-of-openstack-networking
slides:
https://docs.google.com/presentation/d/1HGQLHDLgHBAPjayKDZv0lIxfWhbSRGTsGSBRhvC1Ofw/edit#slide=id.g12c8454d5b_3_88
)

Current existing test scenarios are mainly creating NB port, binding on HV,
and wait for sync, and it was focusing on L2 mode (no lrouters), but it
should be easy to extend to more scenarios and add lrouter support, ACLs,
etc.

Our priority changed after the L2 mode scale tests was done, so the repo
has been in hibernation mode. I am so glad Miguel come up with this before
we are able to switch back on it. Scalability is really important for OVN
to thrive. Miguel, please try it and feel free to ping us for any issues or
any help needed from us.

Thanks,
Han

On Fri, Dec 1, 2017 at 5:23 AM, Russell Bryant  wrote:

>
>
> On Fri, Dec 1, 2017 at 4:35 AM, Miguel Angel Ajo Pelayo <
> majop...@redhat.com> wrote:
>
>> Oh, thank you Ben,
>>
>> That's fantastic, I didn't know that was based on rally.
>>
>> I have to give it a try, and sync with mr Mestery.
>> Russell, were you involved in this?
>>
>
> ​Not involved, but aware of it.
>
> It helps simulate larger scale by running many instances of OVN on a
> single host using ovs-sandbox (or at least a similar technique).​
>
> ​I've added Han Zhou and Lei Huang​, where the project originally came
> from.
>
>
>
>>
>> Best regards,
>> Miguel Ángel.
>>
>>
>>
>> On Tue, Nov 28, 2017 at 7:39 PM, Ben Pfaff  wrote:
>>
>>> On Thu, Nov 23, 2017 at 12:01:33PM +0100, Miguel Angel Ajo Pelayo wrote:
>>> > Today during coffee I was discussing with Jakub the idea of having
>>> > some sort of "rally" [1] [2] like project to measure the native reponse
>>> > of OVN at scale, measuring things like:
>>> >
>>> >   * NB object creation to SB update
>>> >   * Tap creation to SB port binding, and to connectivity.
>>> >   * dnat NAT association to dnat connectivity
>>> >
>>> >   * any other ideas?
>>> >
>>> >
>>> > This project has been specially helpful (in OpenStack) to detect race
>>> > conditions and bottlenecks. But I'm afraid that the OpenStack overhead
>>> > hide the real OVN numbers.
>>>
>>> I support adding some OVN testing, especially scale testing.  There is a
>>> dormant ovn scale testing project that might be a place to start (I've
>>> never looked at it personally):
>>> https://github.com/openvswitch/ovn-scale-test
>>>
>>
>>
>
>
> --
> Russell Bryant
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS with DPDK - Setup issue

[Shivaram Mysore]

You may want to consider reading the presentation and using the scripts
from this:
https://github.com/shivarammysore/faucetsdn-intel/tree/master/src/ubuntu/zesty/ovs_281
to setup and configure DPDK on your  machine.

BTW, you don't have to compile DPDK, etc

On Fri, Dec 1, 2017 at 1:23 AM, Kumar Sanjay10 
wrote:

>
> Hi,
>
> I am trying to work on DPDK with OVS. But, getting an error during the
> "setup DPDK devices using VFIO". List of commands executed as follows:
>
> *DPDK Building: * #export DPDK_DIR=/home/tcs/dpdk-17.11
>
>
> #export DPDK_TARGET=x86_64-native-linuxapp-gcc
>
> #export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
>
> #make install T=$DPDK_TARGET DESTDIR=install
>
>
> *OVS Building: * #cd openvswitch-2.8.0/ #./boot.sh
>
> #./configure –with-dpdk=$DPDK_BUILD #make && make install
>
>
> #echo 'vm.nr_hugepages=2048' > /etc/sysctl.d/hugepages.conf
>
> #sysctl -w vm.nr_hugepages=10 #grep HugePages_ /proc/meminfo
>
> #mkdir -p /dev/hugepages #mount -t hugetlbfs none /dev/hugepages``
>
>
> #dmesg | grep -e DMAR -e IOMMU
>
> #cat /proc/cmdline | grep iommu=pt #cat /proc/cmdline | grep
> intel_iommu=on *- No Response*
>
>
> *#modprobe vfio-pci *#chmod a+x /dev/vfio #chmod 0666 /dev/vfio/*
>
>
> #$DPDK_DIR/usertools/dpdk-devbind.py --bind=vfio-pci eth1
>
> *Routing table indicates that interface :1c:00.1 is active. Not
> modifying *
>
>
> #$DPDK_DIR/usertools/dpdk-devbind.py --status
>
> Network devices using DPDK-compatible driver
>
> 
>
> 
>
>
> Network devices using kernel driver
>
> ===
>
> :1c:00.0 'Device 37d2' if=eth0 drv=i40e unused=vfio-pci *Active*
>
> :1c:00.1 'Device 37d2' if=eth1 drv=i40e unused=vfio-pci *Active*
>
>
> *#ifconfig :1c:00.1 down *
>
> :1c:00.1: ERROR while getting interface flags: No such device
>
>
> *#$DPDK_DIR/usertools/dpdk-devbind.py --status*
>
> Network devices using kernel driver
>
> ===
>
> :1c:00.0 'Device 37d2' if=eth0 drv=i40e unused=vfio-pci *Active*
>
> :1c:00.1 'Device 37d2' if=eth1 drv=i40e unused=vfio-pci
>
>
> #*$DPDK_DIR/usertools/dpdk-devbind.py --bind=vfio-pci eth1 *
>
> Error: bind failed for :1c:00.1 - Cannot bind to driver vfio-pci
>
> Error: unbind failed for :1c:00.1 - Cannot open
> /sys/bus/pci/drivers//unbind
>
>
> #$DPDK_DIR/usertools/dpdk-devbind.py --status
>
> Network devices using kernel driver
>
> ===
>
> :1c:00.0 'Device 37d2' if=eth0 drv=i40e unused=vfio-pci *Active*
>
>
> #ifconfig :1c:00.1 up
>
> :1c:00.1: ERROR while getting interface flags: No such device
>
>
> #$DPDK_DIR/usertools/dpdk-devbind.py –status (eth1 is not up)
>
>
> *Note: I have tried with other version, but response is same as above.*
>
> Please let me know the way to resolve this issue.
>
> Thanks & Regards,
>
> Sanjay Kumar
> Synergy Park, ODC5
> Hyderabad - 500032
> Mobile Phone : +91 9394 829 881 <+91%2093948%2029881>
>
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS Patch Ports

[Fouad Hallal]

Ben,  thank you for your prompt reply.  Is there an easy way to preserve
packet information? Or do we need to make code changes?  BTW, do you have a
pointer to the logic, in code, that is updating these fields for the patch
ports?

Thank you,

On Fri, Dec 1, 2017 at 12:03 PM, Ben Pfaff  wrote:

> On Fri, Dec 01, 2017 at 11:57:22AM -0500, Fouad Hallal wrote:
> > I have tested OVS patch ports functionality in a simple 3 bridges network
> > by using Mininet custom topology.  I configured macro flows by cross
> > connecting the different bridge ports.  Packets passed between the
> > different bridges and I was able to confirm by inspecting OVS flows
> > counters.
> >
> > I have been looking for documentation about OVS implementation of patch
> > ports.  Specifically, I need to learn about the metadata that is passed
> > between the different bridges as packets proceed from one bridge to
> > another.  Is their a data structure (other than the skb) that is passed
> > along?  Are the input ports and output ports values, that a given packet
> > traversed for different bridges, kept around through the life of the
> > packet?  Any pointers are much appreciated.
>
> Traversing a patch port is supposed to be analogous to traversing a
> veth.  The same fields should be preserved.  This is similar to
> traversing a physical Ethernet cable from port to port, except that one
> or two metadata fields should be preserved; skb_priority is the one that
> comes to mind.
>
> The input port isn't preserved; it changes to the patch port.
>
> Output port isn't usually a field.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS Patch Ports

[Ben Pfaff]

On Fri, Dec 01, 2017 at 11:57:22AM -0500, Fouad Hallal wrote:
> I have tested OVS patch ports functionality in a simple 3 bridges network
> by using Mininet custom topology.  I configured macro flows by cross
> connecting the different bridge ports.  Packets passed between the
> different bridges and I was able to confirm by inspecting OVS flows
> counters.
> 
> I have been looking for documentation about OVS implementation of patch
> ports.  Specifically, I need to learn about the metadata that is passed
> between the different bridges as packets proceed from one bridge to
> another.  Is their a data structure (other than the skb) that is passed
> along?  Are the input ports and output ports values, that a given packet
> traversed for different bridges, kept around through the life of the
> packet?  Any pointers are much appreciated.

Traversing a patch port is supposed to be analogous to traversing a
veth.  The same fields should be preserved.  This is similar to
traversing a physical Ethernet cable from port to port, except that one
or two metadata fields should be preserved; skb_priority is the one that
comes to mind.

The input port isn't preserved; it changes to the patch port.

Output port isn't usually a field.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS Patch Ports

[Fouad Hallal]

Hello,

I have tested OVS patch ports functionality in a simple 3 bridges network
by using Mininet custom topology.  I configured macro flows by cross
connecting the different bridge ports.  Packets passed between the
different bridges and I was able to confirm by inspecting OVS flows
counters.

I have been looking for documentation about OVS implementation of patch
ports.  Specifically, I need to learn about the metadata that is passed
between the different bridges as packets proceed from one bridge to
another.  Is their a data structure (other than the skb) that is passed
along?  Are the input ports and output ports values, that a given packet
traversed for different bridges, kept around through the life of the
packet?  Any pointers are much appreciated.

Thank you,
Fouad Hallal
Digital Ocean
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS with DPDK - Setup issue

[Kumar Sanjay10]

 
Hi,

I  am trying to work on DPDK with OVS. But, getting an error during the  "setup 
DPDK devices using VFIO". List of commands executed as follows:

DPDK Building: #export DPDK_DIR=/home/tcs/dpdk-17.11 



#export DPDK_TARGET=x86_64-native-linuxapp-gcc#export 
DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET   #make install T=$DPDK_TARGET 
DESTDIR=install   
  OVS Building:   #cd openvswitch-2.8.0/#./boot.sh   #./configure 
with-dpdk=$DPDK_BUILD   #make && make install   
  #echo 'vm.nr_hugepages=2048' > /etc/sysctl.d/hugepages.conf   #sysctl -w 
vm.nr_hugepages=10 #grep HugePages_ /proc/meminfo   #mkdir -p 
/dev/hugepages #mount -t hugetlbfs none /dev/hugepages``   
  #dmesg | grep -e DMAR -e IOMMU   #cat /proc/cmdline | grep iommu=pt 
#cat /proc/cmdline | grep intel_iommu=on - No Response 
  #modprobe vfio-pci #chmod a+x /dev/vfio 
#chmod 0666 /dev/vfio/*   
  #$DPDK_DIR/usertools/dpdk-devbind.py --bind=vfio-pci eth1   Routing table 
indicates that interface :1c:00.1 is active. Not modifying   
  #$DPDK_DIR/usertools/dpdk-devbind.py --status   Network devices using 
DPDK-compatible driver    
  Network devices using kernel driver   ===  
:1c:00.0 'Device 37d2' if=eth0 drv=i40e unused=vfio-pci *Active*   
:1c:00.1 'Device 37d2' if=eth1 drv=i40e unused=vfio-pci *Active*   
  #ifconfig :1c:00.1 down   :1c:00.1: ERROR while getting interface 
flags: No such device   
  #$DPDK_DIR/usertools/dpdk-devbind.py --status   Network devices using kernel 
driver   ===  :1c:00.0 'Device 37d2' 
if=eth0 drv=i40e unused=vfio-pci *Active*   :1c:00.1 'Device 37d2' if=eth1 
drv=i40e unused=vfio-pci   
  #$DPDK_DIR/usertools/dpdk-devbind.py --bind=vfio-pci eth1   Error: bind 
failed for :1c:00.1 - Cannot bind to driver vfio-pci   Error: unbind failed 
for :1c:00.1 - Cannot open /sys/bus/pci/drivers//unbind   
  #$DPDK_DIR/usertools/dpdk-devbind.py --status   Network devices using kernel 
driver   ===  :1c:00.0 'Device 37d2' 
if=eth0 drv=i40e unused=vfio-pci *Active*   
  #ifconfig :1c:00.1 up   :1c:00.1: ERROR while getting interface 
flags: No such device   
  #$DPDK_DIR/usertools/dpdk-devbind.py status  (eth1 is not up)  

Note: I have tried with other version, but response is same as above.

Please let me know the way to resolve this issue.

Thanks & Regards,

Sanjay Kumar 
Synergy Park, ODC5
Hyderabad - 500032
Mobile Phone : +91 9394 829 881
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you




OVS with DPDK Build issue.odt
Description: Binary data
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Idea of an ovn native "rally"

[Russell Bryant]

On Fri, Dec 1, 2017 at 4:35 AM, Miguel Angel Ajo Pelayo  wrote:

> Oh, thank you Ben,
>
> That's fantastic, I didn't know that was based on rally.
>
> I have to give it a try, and sync with mr Mestery.
> Russell, were you involved in this?
>

​Not involved, but aware of it.

It helps simulate larger scale by running many instances of OVN on a single
host using ovs-sandbox (or at least a similar technique).​

​I've added Han Zhou and Lei Huang​, where the project originally came from.



>
> Best regards,
> Miguel Ángel.
>
>
>
> On Tue, Nov 28, 2017 at 7:39 PM, Ben Pfaff  wrote:
>
>> On Thu, Nov 23, 2017 at 12:01:33PM +0100, Miguel Angel Ajo Pelayo wrote:
>> > Today during coffee I was discussing with Jakub the idea of having
>> > some sort of "rally" [1] [2] like project to measure the native reponse
>> > of OVN at scale, measuring things like:
>> >
>> >   * NB object creation to SB update
>> >   * Tap creation to SB port binding, and to connectivity.
>> >   * dnat NAT association to dnat connectivity
>> >
>> >   * any other ideas?
>> >
>> >
>> > This project has been specially helpful (in OpenStack) to detect race
>> > conditions and bottlenecks. But I'm afraid that the OpenStack overhead
>> > hide the real OVN numbers.
>>
>> I support adding some OVN testing, especially scale testing.  There is a
>> dormant ovn scale testing project that might be a place to start (I've
>> never looked at it personally):
>> https://github.com/openvswitch/ovn-scale-test
>>
>
>


-- 
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Idea of an ovn native "rally"

[Miguel Angel Ajo Pelayo]

Oh, thank you Ben,

That's fantastic, I didn't know that was based on rally.

I have to give it a try, and sync with mr Mestery.
Russell, were you involved in this?


Best regards,
Miguel Ángel.



On Tue, Nov 28, 2017 at 7:39 PM, Ben Pfaff  wrote:

> On Thu, Nov 23, 2017 at 12:01:33PM +0100, Miguel Angel Ajo Pelayo wrote:
> > Today during coffee I was discussing with Jakub the idea of having
> > some sort of "rally" [1] [2] like project to measure the native reponse
> > of OVN at scale, measuring things like:
> >
> >   * NB object creation to SB update
> >   * Tap creation to SB port binding, and to connectivity.
> >   * dnat NAT association to dnat connectivity
> >
> >   * any other ideas?
> >
> >
> > This project has been specially helpful (in OpenStack) to detect race
> > conditions and bottlenecks. But I'm afraid that the OpenStack overhead
> > hide the real OVN numbers.
>
> I support adding some OVN testing, especially scale testing.  There is a
> dormant ovn scale testing project that might be a place to start (I've
> never looked at it personally):
> https://github.com/openvswitch/ovn-scale-test
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss