Re: [ovs-discuss] Openflow Port Status
Hi Ben, My reply inlined. >Or are you saying that, when >you take the link down, you get an "up" and then a "down" message >quickly in succession? YES. I see when i bring the link down, i get UP and then DOWN message. Thanks Suresh. > On Mon, Jul 22, 2019 at 09:34:46PM +0530, S Suresh wrote: > > Hi Ben, > > > > My test environment is, > > Mininet, RYU SDN Controller. > > > > 2) Mininet shell provides the "link" command , which brings downs the > link > > between two switches(port interfaces). > > mininet>link s1 s2 down > > which brings the s1 to s2 link down (s1 port connected to s2) > > > > 3) Captured the open flow messages in Wire shark, as well as in RYU SDN > > Controller. > > > > Thanks > > Suresh > > > > > > > > > > > > > > > > On Mon, Jul 22, 2019 at 9:15 PM Ben Pfaff wrote: > > > > > On Mon, Jul 22, 2019 at 10:02:33AM +0530, S Suresh wrote: > > > > I am testing the Openflow Port Status message. > > > > > > > > My observations are as follows, > > > > 1) > > > > When the port(switch s1, port 1) is down. > > > > (Note: i was expecting only one PORT Status message with PORT DOWN > set) > > > > But I have received two OpenFlow Port Status messages. > > > > The first message shows PORT UP (for S1 , port 1). > > > > Immediately , the second message show PORT DOWN (for S1 , port1). > > > > > > > > Is it correct behavior? > > > > > > It's surprising behavior. > > > > > > Can you explain how to reproduce it? > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Open vSwitch balance-slb bond mode with two upstream switches
On Fri, Jul 19, 2019 at 02:22:18PM -0700, Dan Sneddon wrote: > On Fri, Jul 19, 2019 at 7:46 AM Grzegorz > wrote: > > > Hi Jason > > > > I have the same doubts - I would like to connect balance-slb in OpenStack > > Rocky to two separate switches. > > > > I see you wrote this post a few years ago. > > Have you figured it out finally? > > > > Thank you in advance for your reply > > > > BR > > Grzegorz Juszczak > > > > This only works if the two switches are clustered, i.e. two or more chassis > running as a single logical switch. > > The issue is that balance-slb will only use one link for a MAC+VLAN, but > when rebalancing happens the traffic may start using the other port. If the > switch attached to the original port doesn't know that the traffic is now > using the other port/different switch, then traffic to the OVS bond may be > lost. > > You can use active-backup with OVS bonds and two switches, or attach a > bond/team using a different bonding technique (Linux kernel bonds, teamd > adapter teams, etc.) that supports disparate switches and then attach that > bond to OVS. There aren't many good options for attaching to multiple > switches, so I try to use switches that can be clustered when I'm not using > a chassis switch. > > Look into teamd, it has more options for controlling how your traffic is > load balanced, and you can choose your own hash combinations. I've > configured OpenStack deployments with teams attached to OVS bridges for > Neutron. The best documentation I've found so far is here, but you may need > to adjust depending on Linux distribution: > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-configure_network_teaming This is a helpful email. Is there a chance you'd be willing to rephrase it as a FAQ question and answer? Then it'd be useful to lots of people. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Openflow Port Status
At what point do you see the "port status up" message? Is it when you originally add the link and bring it up? Or are you saying that, when you take the link down, you get an "up" and then a "down" message quickly in succession? On Mon, Jul 22, 2019 at 09:34:46PM +0530, S Suresh wrote: > Hi Ben, > > My test environment is, > Mininet, RYU SDN Controller. > > 2) Mininet shell provides the "link" command , which brings downs the link > between two switches(port interfaces). > mininet>link s1 s2 down > which brings the s1 to s2 link down (s1 port connected to s2) > > 3) Captured the open flow messages in Wire shark, as well as in RYU SDN > Controller. > > Thanks > Suresh > > > > > > > > On Mon, Jul 22, 2019 at 9:15 PM Ben Pfaff wrote: > > > On Mon, Jul 22, 2019 at 10:02:33AM +0530, S Suresh wrote: > > > I am testing the Openflow Port Status message. > > > > > > My observations are as follows, > > > 1) > > > When the port(switch s1, port 1) is down. > > > (Note: i was expecting only one PORT Status message with PORT DOWN set) > > > But I have received two OpenFlow Port Status messages. > > > The first message shows PORT UP (for S1 , port 1). > > > Immediately , the second message show PORT DOWN (for S1 , port1). > > > > > > Is it correct behavior? > > > > It's surprising behavior. > > > > Can you explain how to reproduce it? > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Openflow Port Status
Hi Ben, My test environment is, Mininet, RYU SDN Controller. 2) Mininet shell provides the "link" command , which brings downs the link between two switches(port interfaces). mininet>link s1 s2 down which brings the s1 to s2 link down (s1 port connected to s2) 3) Captured the open flow messages in Wire shark, as well as in RYU SDN Controller. Thanks Suresh On Mon, Jul 22, 2019 at 9:15 PM Ben Pfaff wrote: > On Mon, Jul 22, 2019 at 10:02:33AM +0530, S Suresh wrote: > > I am testing the Openflow Port Status message. > > > > My observations are as follows, > > 1) > > When the port(switch s1, port 1) is down. > > (Note: i was expecting only one PORT Status message with PORT DOWN set) > > But I have received two OpenFlow Port Status messages. > > The first message shows PORT UP (for S1 , port 1). > > Immediately , the second message show PORT DOWN (for S1 , port1). > > > > Is it correct behavior? > > It's surprising behavior. > > Can you explain how to reproduce it? > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [OVN] ovn-controller Incremental Processing scale testing
Neat! Thanks folks :)
I'll try to get an OSP setup where we can patch this and re-run the
same tests than previous time to confirm but looks promising.
On Fri, Jul 19, 2019 at 11:12 PM Han Zhou wrote:
>
>
>
> On Fri, Jul 19, 2019 at 12:37 PM Numan Siddique wrote:
>>
>>
>>
>> On Fri, Jul 19, 2019 at 6:19 PM Numan Siddique wrote:
>>>
>>>
>>>
>>> On Fri, Jul 19, 2019 at 6:28 AM Han Zhou wrote:
On Tue, Jul 9, 2019 at 12:13 AM Numan Siddique wrote:
>
>
>
> On Tue, Jul 9, 2019 at 12:25 PM Daniel Alvarez Sanchez
> wrote:
>>
>> Thanks Numan for running these tests outside OpenStack!
>>
>> On Tue, Jul 9, 2019 at 7:50 AM Numan Siddique
>> wrote:
>> >
>> >
>> >
>> > On Tue, Jul 9, 2019 at 11:05 AM Han Zhou wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Jun 21, 2019 at 12:31 AM Han Zhou wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Jun 20, 2019 at 11:42 PM Numan Siddique
>> >> > wrote:
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Fri, Jun 21, 2019, 11:47 AM Han Zhou
>> >> > > wrote:
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> On Tue, Jun 11, 2019 at 9:16 AM Daniel Alvarez Sanchez
>> >> > >> wrote:
>> >> > >> >
>> >> > >> > Thanks a lot Han for the answer!
>> >> > >> >
>> >> > >> > On Tue, Jun 11, 2019 at 5:57 PM Han Zhou
>> >> > >> > wrote:
>> >> > >> > >
>> >> > >> > >
>> >> > >> > >
>> >> > >> > >
>> >> > >> > > On Tue, Jun 11, 2019 at 5:12 AM Dumitru Ceara
>> >> > >> > > wrote:
>> >> > >> > > >
>> >> > >> > > > On Tue, Jun 11, 2019 at 10:40 AM Daniel Alvarez Sanchez
>> >> > >> > > > wrote:
>> >> > >> > > > >
>> >> > >> > > > > Hi Han, all,
>> >> > >> > > > >
>> >> > >> > > > > Lucas, Numan and I have been doing some 'scale' testing
>> >> > >> > > > > of OpenStack
>> >> > >> > > > > using OVN and wanted to present some results and issues
>> >> > >> > > > > that we've
>> >> > >> > > > > found with the Incremental Processing feature in
>> >> > >> > > > > ovn-controller. Below
>> >> > >> > > > > is the scenario that we executed:
>> >> > >> > > > >
>> >> > >> > > > > * 7 baremetal nodes setup: 3 controllers (running
>> >> > >> > > > > ovn-northd/ovsdb-servers in A/P with pacemaker) + 4
>> >> > >> > > > > compute nodes. OVS
>> >> > >> > > > > 2.10.
>> >> > >> > > > > * The test consists on:
>> >> > >> > > > > - Create openstack network (OVN LS), subnet and router
>> >> > >> > > > > - Attach subnet to the router and set gw to the
>> >> > >> > > > > external network
>> >> > >> > > > > - Create an OpenStack port and apply a Security Group
>> >> > >> > > > > (ACLs to allow
>> >> > >> > > > > UDP, SSH and ICMP).
>> >> > >> > > > > - Bind the port to one of the 4 compute nodes
>> >> > >> > > > > (randomly) by
>> >> > >> > > > > attaching it to a network namespace.
>> >> > >> > > > > - Wait for the port to be ACTIVE in Neutron ('up ==
>> >> > >> > > > > True' in NB)
>> >> > >> > > > > - Wait until the test can ping the port
>> >> > >> > > > > * Running browbeat/rally with 16 simultaneous process
>> >> > >> > > > > to execute the
>> >> > >> > > > > test above 150 times.
>> >> > >> > > > > * When all the 150 'fake VMs' are created, browbeat
>> >> > >> > > > > will delete all
>> >> > >> > > > > the OpenStack/OVN resources.
>> >> > >> > > > >
>> >> > >> > > > > We first tried with OVS/OVN 2.10 and pulled some
>> >> > >> > > > > results which showed
>> >> > >> > > > > 100% success but ovn-controller is quite loaded (as
>> >> > >> > > > > expected) in all
>> >> > >> > > > > the nodes especially during the deletion phase:
>> >> > >> > > > >
>> >> > >> > > > > - Compute node: https://imgur.com/a/tzxfrIR
>> >> > >> > > > > - Controller node (ovn-northd and ovsdb-servers):
>> >> > >> > > > > https://imgur.com/a/8ffKKYF
>> >> > >> > > > >
>> >> > >> > > > > After conducting the tests above, we replaced
>> >> > >> > > > > ovn-controller in all 7
>> >> > >> > > > > nodes by the one with the current master branch
>> >> > >> > > > > (actually from last
>> >> > >> > > > > week). We also replaced ovn-northd and ovsdb-servers
>> >> > >> > > > > but the
>> >> > >> > > > > ovs-vswitchd has been left untouched (still on 2.10).
>> >> > >> > > > > The expected
>> >> > >> > > > > results were to get less ovn-controller CPU usage and
>> >> > >> > > > > also better
>> >> > >> > > > > times due to the Incremental Processing feature
>> >> > >> > > > > introduced recently.
>> >> > >> > > > > However, the results don't look very good:
>> >> > >> > > > >
>> >> > >> > >
