[ovs-discuss] Open vSwitch Open Source Days at OpenStack Summit Boston, May 8-11: call for participation

[Ben Pfaff]

[reposted from ovs-announce, apologies to anyone who has already seen
this]

The Open vSwitch project is participating in Open Source Days at
OpenStack Summit Boston.  During the summit, Open vSwitch will have
dedicated use of a room for a full day.  We are seeking participation
for talks and tutorials for this event.

OpenStack Summit Boston will be held May 8 to 11.  We do not yet know
which day the Open Source Days event will be held.

Talks
-

We are seeking talks on topics including the following:

 * Deploying and using OVN.

 * End-user or service provider experiences with OVN or Open vSwitch.

 * Testing and scaling OVN.

 * Troubleshooting and debugging Open vSwitch or OVN installations.

 * Using Open vSwitch or OVN with OpenStack.

 * Container integration with Open vSwitch or OVN, including usage
   with container orchestration systems such as Kubernetes and Mesos.

 * Using OVN to realize NFV and service chaining.

 * Integrating OVN with Linux distributions, with Windows, or other
   operating systems.

 * Open vSwitch relationship with other open source projects.

 * Increasing the size and diversity of the Open vSwitch user
   and developer base.

 * Demos.

 * Other topics likely to be of interest to attendees.

We expect most talks to last 20 minutes, with added time for
questions.  We are also open to requests for longer or shorter time
blocks.  

To propose a talk, submit the title, abstract, and speakers' names and
email addrsses to ovs...@openvswitch.org by Feb. 22.  Please put
"TALK:" at the beginning of the subject line.  We will notify speakers
of acceptance by Feb. 24.

Speakers must add their own bios and headshots at
https://www.openstack.org/profile/speaker, using their own unique
email addresses.

We can provide free OpenStack registration to up to 10 speakers.
Speakers should plan to attend OpenStack Summit Boston in person.
Travel and accommodations are the responsibility of the participants.

We will record audio for talks and make it available online along with
slides.

Tutorial


We are organizing a hands-on OVN tutorial as part of the Open Source
Days event.  Before the event, we could use the help of a few people
to design and write the tutorial.  During the event, we also need help
to run the tutorial and to assist attendees.  To volunteer for any of
these roles, please let us know about it at ovscon@openvswitch.

We may be able to provide free OpenStack registration to on-site
volunteers, out of our quota of 10 free registrations.  Travel and
accommodations are the responsibility of the volunteers.  Volunteers
must add their own bios and headshots at
https://www.openstack.org/profile/speaker, using their own unique
email addresses.

How to attend
-

The event is open to any attendee of OpenStack Summit Boston.

More information


For more information about Open Source Days, please visit:
https://www.openstack.org/summit/boston-2017/open-source-days/
(The Open vSwitch logo isn't up there as of this writing, but it
should be there soon.)

To reach the organizers, email ovs...@openvswitch.org.  For general
discussion of the Open vSwitch Open Source Days event, please use the
ovs-discuss mailing list at disc...@openvswitch.org.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding on VLAN

[Felipe Arturo Polanco]

Ok I get it, change the VLAN of the bridge internal port.

Try with:
ovs-vsctl set port br0 tag=40 vlan_mode=native-untagged  <- I have not
tested this but let us know if it works.

On Wed, Feb 1, 2017 at 11:04 PM, Joo Yong-Seok 
wrote:

> Sorry. I think that my question was wrong. What I meant for "local-port"
> was,
>
> - if we create "br0" as ovs bridge, ovs will create br0 (internal port) in
> br0 bridge.
> - We can assign IP address on br0 (port) interface to use it as "regular
> bridge".
> - What I want was, assign VLAN on that port - br0 which is "internal" or
> "local" port of "br0" bridge.
>
> Best regards,
>
> - yongseok
>
> On Wed, Feb 1, 2017 at 6:33 PM,  wrote:
>
>> Hi Joo,
>>
>>
>>
>>1. To assign an eth1 port inside a bridge to a vlan 40 use “ovs-vsctl
>>set port eth1 tag=40 vlan_mode=native-untagged”
>>This way you can avoid the use of fake bridges for this purpose, this
>>command is equivalent to “switchport access vlan 40” in the fabric world.
>>2. The packets that are sent out using br0 interface will be
>>untagged, the device connected to the other side of p3 will receive it in
>>it’s native vlan, so if you have other hosts running in this native vlan
>>then yes you can communicate.
>>3. Yes, you can see all the packets in the bridge but use the -e
>>option to also see the VLAN Tag in layer 2 frame “tcpdump -i br0 -e”
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>>
>>
>> *From: *Joo Yong-Seok 
>> *Sent: *Wednesday, February 1, 2017 9:30 PM
>> *To: *ovs-discuss@openvswitch.org
>> *Subject: *[ovs-discuss] Regarding on VLAN
>>
>>
>>
>> Hi,
>>
>>
>>
>> Quick questions in regard of VLANs
>>
>>
>>
>> 1) Are we able to assign VLAN to local-port? (not sure whether it is
>> really required...) If so, how? (without using "fake-bridge").
>>
>>
>>
>> 2) If not, I have following situation.
>>
>>
>>
>>  - br0(ovs-bridge) has p1, p2, p3 and p4 as a bridge port.
>>
>>> p1 - tag 10
>>
>>> p2 - tag 20
>>
>>> p3 - trunk port
>>
>>> local-port (br0).
>>
>>
>>
>>  - with above config, am I able to communicate to other host by using the
>> IP address on br0?
>>
>>
>>
>> 3) If I run tcpudmp -i br0, am I able to see all the packets from every
>> port?
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> - yongseok
>>
>>
>>
>>
>>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding on VLAN

[Joo Yong-Seok]

Sorry. I think that my question was wrong. What I meant for "local-port"
was,

- if we create "br0" as ovs bridge, ovs will create br0 (internal port) in
br0 bridge.
- We can assign IP address on br0 (port) interface to use it as "regular
bridge".
- What I want was, assign VLAN on that port - br0 which is "internal" or
"local" port of "br0" bridge.

Best regards,

- yongseok

On Wed, Feb 1, 2017 at 6:33 PM,  wrote:

> Hi Joo,
>
>
>
>1. To assign an eth1 port inside a bridge to a vlan 40 use “ovs-vsctl
>set port eth1 tag=40 vlan_mode=native-untagged”
>This way you can avoid the use of fake bridges for this purpose, this
>command is equivalent to “switchport access vlan 40” in the fabric world.
>2. The packets that are sent out using br0 interface will be untagged,
>the device connected to the other side of p3 will receive it in it’s native
>vlan, so if you have other hosts running in this native vlan then yes you
>can communicate.
>3. Yes, you can see all the packets in the bridge but use the -e
>option to also see the VLAN Tag in layer 2 frame “tcpdump -i br0 -e”
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> *From: *Joo Yong-Seok 
> *Sent: *Wednesday, February 1, 2017 9:30 PM
> *To: *ovs-discuss@openvswitch.org
> *Subject: *[ovs-discuss] Regarding on VLAN
>
>
>
> Hi,
>
>
>
> Quick questions in regard of VLANs
>
>
>
> 1) Are we able to assign VLAN to local-port? (not sure whether it is
> really required...) If so, how? (without using "fake-bridge").
>
>
>
> 2) If not, I have following situation.
>
>
>
>  - br0(ovs-bridge) has p1, p2, p3 and p4 as a bridge port.
>
>> p1 - tag 10
>
>> p2 - tag 20
>
>> p3 - trunk port
>
>> local-port (br0).
>
>
>
>  - with above config, am I able to communicate to other host by using the
> IP address on br0?
>
>
>
> 3) If I run tcpudmp -i br0, am I able to see all the packets from every
> port?
>
>
>
> Thanks in advance.
>
>
>
> Best regards,
>
>
>
> - yongseok
>
>
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Regarding on VLAN

[felipeapolanco]

Hi Joo,

1) To assign an eth1 port inside a bridge to a vlan 40 use “ovs-vsctl set port 
eth1 tag=40 vlan_mode=native-untagged”
This way you can avoid the use of fake bridges for this purpose, this command 
is equivalent to “switchport access vlan 40” in the fabric world.
2) The packets that are sent out using br0 interface will be untagged, the 
device connected to the other side of p3 will receive it in it’s native vlan, 
so if you have other hosts running in this native vlan then yes you can 
communicate.
3) Yes, you can see all the packets in the bridge but use the -e option to also 
see the VLAN Tag in layer 2 frame “tcpdump -i br0 -e”

Sent from Mail for Windows 10

From: Joo Yong-Seok
Sent: Wednesday, February 1, 2017 9:30 PM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] Regarding on VLAN

Hi, 

Quick questions in regard of VLANs

1) Are we able to assign VLAN to local-port? (not sure whether it is really 
required...) If so, how? (without using "fake-bridge").

2) If not, I have following situation.

 - br0(ovs-bridge) has p1, p2, p3 and p4 as a bridge port. 
   > p1 - tag 10
   > p2 - tag 20
   > p3 - trunk port 
   > local-port (br0).

 - with above config, am I able to communicate to other host by using the IP 
address on br0?

3) If I run tcpudmp -i br0, am I able to see all the packets from every port?

Thanks in advance.

Best regards,

- yongseok


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

Re: [ovs-discuss] netdev_linux_update_flags() needs seq_change() ?

[Brandon Cheng]

Hi, Ben

Sorry I replied too late. Because I'm busy for other jobs during these
weeks.

I use openvswitch 2.1.2, so no  netdev_change_seq_changed() API to be used.

Could I use seq_change() instead of netdev_change_seq_changed()?

BR.

Brandon


2017-02-01 7:14 GMT+08:00 Ben Pfaff :

> On Fri, Jan 13, 2017 at 01:03:32PM -0800, Ben Pfaff wrote:
> > On Wed, Jan 11, 2017 at 04:05:51PM +0800, Brandon Cheng wrote:
> > > After all statements of netdev_linux_update_flags() executed
> successfully,
> > > it also executes seq_change() to tell ofproto_run() something changed
> to
> > > update ovsdb.
> > >
> > > And in order to config port to linkup can update ovsdb.
> > > it needs to use "a->config == b->config" instead of "&& !((a->config ^
> > > b->config) & OFPUTIL_PC_PORT_DOWN)" in the ofport_equal() of ofproto.c.
> > >
> > > For example:
> > > step1: # ovs-ofctl mod-port br0 14 down -O openflow13 >although
> port 16
> > > is actually down, it doesn't update ovsdb, so config of port 16 is
> still up
> > > in the ovsdb.
> > > step2: # ovs-ofctl mod-port br0 14 up -O openflow13   > because
> config
> > > of port 16 in the ovsdb is still up, this up action will not be
> executed.
> > > So that this port can't be up forever.
> > >
> > > Is this a bug?
> >
> > Please test this patch.
> >
> > diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
> > index a5a9ec1..1eadbbd 100644
> > --- a/lib/netdev-linux.c
> > +++ b/lib/netdev-linux.c
> > @@ -2742,6 +2742,7 @@ update_flags(struct netdev_linux *netdev, enum
> netdev_flags off,
> >  if (new_flags != old_flags) {
> >  error = set_flags(netdev_get_name(&netdev->up), new_flags);
> >  get_flags(&netdev->up, &netdev->ifi_flags);
> > +netdev_change_seq_changed(&netdev->up);
> >  }
> >
> >  return error;
>
> Brandon, does this fix the problem?
>
> Thanks,
>
> Ben.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Regarding on VLAN

[Joo Yong-Seok]

Hi,

Quick questions in regard of VLANs

1) Are we able to assign VLAN to local-port? (not sure whether it is really
required...) If so, how? (without using "fake-bridge").

2) If not, I have following situation.

 - br0(ovs-bridge) has p1, p2, p3 and p4 as a bridge port.
   > p1 - tag 10
   > p2 - tag 20
   > p3 - trunk port
   > local-port (br0).

 - with above config, am I able to communicate to other host by using the
IP address on br0?

3) If I run tcpudmp -i br0, am I able to see all the packets from every
port?

Thanks in advance.

Best regards,

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

[ovs-discuss] Add logical flows with OVN

[Shuaijun Zhang]

Hi Guys,

I am newbie with using OVS and now need to set up a test environment with
Docker+OVN on 4 VMs (Openstack instances)

OVS version 2.6.1
VM0: OVN central controller (NB database & SB database & northd) + Docker
cluster-store Consul
VM1: OVN node 1 where the docker containers will run
VM2: OVN node 2 where the docker containers will run
VM3: OVN node 3 where the docker containers will run

By following the document of
https://github.com/openvswitch/ovs/blob/v2.6.1/INSTALL.Docker.md, I got it
working: the docker containers on these VMs can ping each other via geneve
tunnel.

Now come to my basic test:
C1: container1 on VM1
C2: container2 on VM2
C3: container3 on VM3

Originally, if ping from C1 to C3, it directly gets there (C1->C3). Now I
want to route the ping traffic from C1 to C3 through C2, means all the ping
traffic must be C1->C2->C3. It looks very simple, but quite hard to
newbies. how to do it with OVN? :(

I have used floodlight as the SDN controller (by "ovs-vsctl set-controller"
on VM1, VM2 & VM3), but I can't manage it to control the traffic across
multiple switches (those switches are on different VMs).

I also checked the OVN utilities, ovn-nbctl allows you to add ACLs, but
those ACLs are for access control, not for the traffic control.
The way it may work (I guess) is using ovn-sbctl to add the logical flows
directly to SB database, but I am not sure if it is the right way.

So can anyone point me out how to control the ping traffic.
Thank you so much


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

Re: [ovs-discuss] OVS - High Availability plan

[Erez Segev]

Is it implemented or just a concept?

 Original Message 
From: Ben Pfaff 
Date: Wed, February 01, 2017 9:42 PM +0200
To: Erez Segev 
CC: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] OVS - High Availability plan

Are you talking about OVN gateways or something else?  The document that
you cited is about OVN gateways.

On Wed, Feb 01, 2017 at 07:27:34AM +, Erez Segev wrote:
> Hi Ben,
>
> Thank you very much for your help.
>
> Is there an related implementation which supports HA solution for the OVS 
> networking?
> And to be more specific, I'm looking for a specific solution which implements 
> a kind of controlled Router that acts as s gate between physical to virtual 
> network.
> From the perspective of the physical network the router represented as single 
> IP address while two entities run it (a VRRP protocol shall run between the 
> routers)
>
> Thanks,
> Erez
>
>
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Tuesday, January 31, 2017 6:15 PM
> To: Erez Segev 
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] OVS - High Availability plan
>
> On Mon, Jan 30, 2017 at 07:56:44AM +, Erez Segev wrote:
> > Hi All,
> >
> > There is a document describing High availability solution in the following 
> > link:
> > http://docs.openvswitch.org/en/latest/topics/high-availability/
> >
> > Is there an implementation/installation guide for it as well?
> > Is it a future work?
>
> It's essentially a description of a plan.  I don't know whether it's still 
> accurate--perhaps we should remove it, if not.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS - High Availability plan

[Ben Pfaff]

The cited document is only about OVN gateways.  It is not implemented.

On Wed, Feb 01, 2017 at 09:04:27PM +, Erez Segev wrote:
> Is it implemented or just a concept?
> 
>  Original Message 
> From: Ben Pfaff 
> Date: Wed, February 01, 2017 9:42 PM +0200
> To: Erez Segev 
> CC: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] OVS - High Availability plan
> 
> Are you talking about OVN gateways or something else?  The document that
> you cited is about OVN gateways.
> 
> On Wed, Feb 01, 2017 at 07:27:34AM +, Erez Segev wrote:
> > Hi Ben,
> >
> > Thank you very much for your help.
> >
> > Is there an related implementation which supports HA solution for the OVS 
> > networking?
> > And to be more specific, I'm looking for a specific solution which 
> > implements a kind of controlled Router that acts as s gate between physical 
> > to virtual network.
> > From the perspective of the physical network the router represented as 
> > single IP address while two entities run it (a VRRP protocol shall run 
> > between the routers)
> >
> > Thanks,
> > Erez
> >
> >
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Tuesday, January 31, 2017 6:15 PM
> > To: Erez Segev 
> > Cc: ovs-discuss@openvswitch.org
> > Subject: Re: [ovs-discuss] OVS - High Availability plan
> >
> > On Mon, Jan 30, 2017 at 07:56:44AM +, Erez Segev wrote:
> > > Hi All,
> > >
> > > There is a document describing High availability solution in the 
> > > following link:
> > > http://docs.openvswitch.org/en/latest/topics/high-availability/
> > >
> > > Is there an implementation/installation guide for it as well?
> > > Is it a future work?
> >
> > It's essentially a description of a plan.  I don't know whether it's still 
> > accurate--perhaps we should remove it, if not.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS - High Availability plan

[Ben Pfaff]

Are you talking about OVN gateways or something else?  The document that
you cited is about OVN gateways.

On Wed, Feb 01, 2017 at 07:27:34AM +, Erez Segev wrote:
> Hi Ben,
> 
> Thank you very much for your help.
> 
> Is there an related implementation which supports HA solution for the OVS 
> networking?
> And to be more specific, I'm looking for a specific solution which implements 
> a kind of controlled Router that acts as s gate between physical to virtual 
> network.  
> From the perspective of the physical network the router represented as single 
> IP address while two entities run it (a VRRP protocol shall run between the 
> routers) 
> 
> Thanks,
> Erez
> 
> 
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org] 
> Sent: Tuesday, January 31, 2017 6:15 PM
> To: Erez Segev 
> Cc: ovs-discuss@openvswitch.org
> Subject: Re: [ovs-discuss] OVS - High Availability plan
> 
> On Mon, Jan 30, 2017 at 07:56:44AM +, Erez Segev wrote:
> > Hi All,
> > 
> > There is a document describing High availability solution in the following 
> > link:
> > http://docs.openvswitch.org/en/latest/topics/high-availability/
> > 
> > Is there an implementation/installation guide for it as well?
> > Is it a future work?
> 
> It's essentially a description of a plan.  I don't know whether it's still 
> accurate--perhaps we should remove it, if not.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] after setting ovs-vsctl set open . external-ids:ovn-encap-ip=, eth0 stops tansmitting any packets in docker container

[Ben Pfaff]

Wow, that was quick.  Thanks a lot for testing and confirming the fix.
I applied these patches to master and branch-2.7.

On Wed, Feb 01, 2017 at 06:42:09PM +, Hexin Wang wrote:
> Hi Ben,
> 
> Thanks for the patch. The fix looks good. We’ve also verified the fix. Eth0 
> qos is left intact.
> 
> root@59c90586bd96:/# /usr/share/openvswitch/scripts/ovn-ctl start_controller
>  * Starting ovn-controller
> root@59c90586bd96:/# 
> root@59c90586bd96:/# 
> root@59c90586bd96:/# 
> root@59c90586bd96:/# !ping
> ping 10.4.163.185
> PING 10.4.163.185 (10.4.163.185) 56(84) bytes of data.
> 64 bytes from 10.4.163.185: icmp_seq=1 ttl=63 time=0.525 ms
> 64 bytes from 10.4.163.185: icmp_seq=2 ttl=63 time=0.368 ms
> ^C
> --- 10.4.163.185 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1000ms
> rtt min/avg/max/mdev = 0.368/0.446/0.525/0.081 ms
> root@59c90586bd96:/# 
> root@59c90586bd96:/# 
> root@59c90586bd96:/# tc qdisc show
> qdisc noqueue 0: dev lo root refcnt 2 
> qdisc noqueue 0: dev eth0 root refcnt 2 
> qdisc noqueue 0: dev vxlan_sys_4789 root refcnt 2 
> root@59c90586bd96:/# ps aux|grep ovn-controller
> root 22611  0.0  0.0  27336  2212 ?S ovn-controller: monitoring pid 22612 (healthy)
> root 22612  0.0  0.0  27468  3832 ?S<   18:37   0:00 
> ovn-controller unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err 
> -vfile:info --no-chdir --log-file=/var/log/openvswitch/ovn-controller.log 
> --pidfile=/var/run/openvswitch/ovn-controller.pid --detach --monitor
> root@59c90586bd96:/# 
> 
> 
> Regards,
> 
> 
> 
> Hexin
> 
> On 2/1/17, 9:23 AM, "Ben Pfaff"  wrote:
> 
> >Thanks for locating the root cause.
> >
> >I sent out a pair of patches that, together, I expect would at least
> >work around the problem in the common case:
> >https://patchwork.ozlabs.org/patch/722628/
> >https://patchwork.ozlabs.org/patch/722629/
> >Do you think you could try them out?
> >
> >Thanks,
> >
> >Ben.
> >
> >On Wed, Feb 01, 2017 at 07:43:53AM +, Hexin Wang wrote:
> >> So this is a docker issue, 
> >> http://stackissue.com/openshift/origin/sdn-set-veth-tx-queue-length-to-unblock-qos-11126.html
> >> Basically docker creates interface with an explicit 0 txqlen which causes 
> >> the problem when QoS is switched to htb.
> >> 
> >> Thanks.
> >> 
> >> Hexin
> >> 
> >> 
> >> 
> >> 
> >> On 1/31/17, 6:18 PM, "ovs-discuss-boun...@openvswitch.org on behalf of 
> >> Hexin Wang"  >> hexin.w...@nutanix.com> wrote:
> >> 
> >> >Looks like the problem is because ovn is trying to touch eth0 qos. The 
> >> >moment it changes qos_type from “linux-other” to “linux-htb”. Traffic 
> >> >stops working.
> >> >
> >> >setup_qos (queue_map=0x7fffc230, egress_iface=0x63ae10 "eth0") at 
> >> >ovn/controller/binding.c:240
> >> >240 int error = netdev_open(egress_iface, NULL, &netdev_phy);
> >> >(gdb) n
> >> >241 if (error) {
> >> >(gdb) 
> >> >251 smap_init(&qdisc_details);
> >> >(gdb) 
> >> >252 if (netdev_get_qos(netdev_phy, &qdisc_type, &qdisc_details) 
> >> >!= 0 ||
> >> >(gdb) 
> >> >253 qdisc_type[0] == '\0') {
> >> >(gdb) 
> >> >252 if (netdev_get_qos(netdev_phy, &qdisc_type, &qdisc_details) 
> >> >!= 0 ||
> >> >(gdb) 
> >> >257 if (strcmp(qdisc_type, OVN_QOS_TYPE)) {
> >> >(gdb) print qdisc_type
> >> >$12 = 0x778ef8ec "linux-other"
> >> >(gdb) print qdisc_details
> >> >$13 = {map = {buckets = 0x7fffc258, one = 0x0, mask = 0, n = 0}}
> >> >(gdb) n
> >> >258 error = netdev_set_qos(netdev_phy, OVN_QOS_TYPE, 
> >> >&qdisc_details);
> >> >(gdb) n 
> >> >259 if (error) {
> >> >(gdb) print error
> >> >$14 = 0
> >> >
> >> >
> >> >Thanks.
> >> >
> >> >Hexin
> >> >
> >> >
> >> >
> >> >On 1/31/17, 6:12 PM, "Ritesh Rekhi"  wrote:
> >> >
> >> >>+ Hexin 
> >> >>
> >> >>-Original Message-
> >> >>From: Ben Pfaff [mailto:b...@ovn.org] 
> >> >>Sent: Tuesday, January 31, 2017 3:49 PM
> >> >>To: Ritesh Rekhi 
> >> >>Cc: ovs-discuss@openvswitch.org
> >> >>Subject: Re: [ovs-discuss] after setting ovs-vsctl set open . 
> >> >>external-ids:ovn-encap-ip=, eth0 stops tansmitting any packets in 
> >> >>docker container
> >> >>
> >> >>OK, what is OVN doing to the routing table or IP address configuration 
> >> >>for the docker container?
> >> >>
> >> >>On Tue, Jan 31, 2017 at 11:12:40PM +, Ritesh Rekhi wrote:
> >> >>> That is what I am not able to find.If I have only 1 chassis connected 
> >> >>> things work fine. Looks like OVN is doing something to the docker eth0 
> >> >>>  interface .Again this problem does't happen on a Vm.
> >> >>> 
> >> >>> It only happens on a docker container (:.
> >> >>> 
> >> >>> Thx
> >> >>> Ritesh
> >> >>> 
> >> >>> -Original Message-
> >> >>> From: Ben Pfaff [mailto:b...@ovn.org]
> >> >>> Sent: Tuesday, January 31, 2017 1:38 PM
> >> >>> To: Ritesh Rekhi 
> >> >>> Cc: ovs-discuss@openvswitch.org
> >> >>> Subject: Re: [ovs-discuss] after setting ovs-vsctl set op

Re: [ovs-discuss] after setting ovs-vsctl set open . external-ids:ovn-encap-ip=, eth0 stops tansmitting any packets in docker container

[Hexin Wang]

Hi Ben,

Thanks for the patch. The fix looks good. We’ve also verified the fix. Eth0 qos 
is left intact.

root@59c90586bd96:/# /usr/share/openvswitch/scripts/ovn-ctl start_controller
 * Starting ovn-controller
root@59c90586bd96:/# 
root@59c90586bd96:/# 
root@59c90586bd96:/# 
root@59c90586bd96:/# !ping
ping 10.4.163.185
PING 10.4.163.185 (10.4.163.185) 56(84) bytes of data.
64 bytes from 10.4.163.185: icmp_seq=1 ttl=63 time=0.525 ms
64 bytes from 10.4.163.185: icmp_seq=2 ttl=63 time=0.368 ms
^C
--- 10.4.163.185 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.368/0.446/0.525/0.081 ms
root@59c90586bd96:/# 
root@59c90586bd96:/# 
root@59c90586bd96:/# tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2 
qdisc noqueue 0: dev eth0 root refcnt 2 
qdisc noqueue 0: dev vxlan_sys_4789 root refcnt 2 
root@59c90586bd96:/# ps aux|grep ovn-controller
root 22611  0.0  0.0  27336  2212 ?S wrote:

>Thanks for locating the root cause.
>
>I sent out a pair of patches that, together, I expect would at least
>work around the problem in the common case:
>https://patchwork.ozlabs.org/patch/722628/
>https://patchwork.ozlabs.org/patch/722629/
>Do you think you could try them out?
>
>Thanks,
>
>Ben.
>
>On Wed, Feb 01, 2017 at 07:43:53AM +, Hexin Wang wrote:
>> So this is a docker issue, 
>> http://stackissue.com/openshift/origin/sdn-set-veth-tx-queue-length-to-unblock-qos-11126.html
>> Basically docker creates interface with an explicit 0 txqlen which causes 
>> the problem when QoS is switched to htb.
>> 
>> Thanks.
>> 
>> Hexin
>> 
>> 
>> 
>> 
>> On 1/31/17, 6:18 PM, "ovs-discuss-boun...@openvswitch.org on behalf of Hexin 
>> Wang" > hexin.w...@nutanix.com> wrote:
>> 
>> >Looks like the problem is because ovn is trying to touch eth0 qos. The 
>> >moment it changes qos_type from “linux-other” to “linux-htb”. Traffic stops 
>> >working.
>> >
>> >setup_qos (queue_map=0x7fffc230, egress_iface=0x63ae10 "eth0") at 
>> >ovn/controller/binding.c:240
>> >240 int error = netdev_open(egress_iface, NULL, &netdev_phy);
>> >(gdb) n
>> >241 if (error) {
>> >(gdb) 
>> >251 smap_init(&qdisc_details);
>> >(gdb) 
>> >252 if (netdev_get_qos(netdev_phy, &qdisc_type, &qdisc_details) != 
>> >0 ||
>> >(gdb) 
>> >253 qdisc_type[0] == '\0') {
>> >(gdb) 
>> >252 if (netdev_get_qos(netdev_phy, &qdisc_type, &qdisc_details) != 
>> >0 ||
>> >(gdb) 
>> >257 if (strcmp(qdisc_type, OVN_QOS_TYPE)) {
>> >(gdb) print qdisc_type
>> >$12 = 0x778ef8ec "linux-other"
>> >(gdb) print qdisc_details
>> >$13 = {map = {buckets = 0x7fffc258, one = 0x0, mask = 0, n = 0}}
>> >(gdb) n
>> >258 error = netdev_set_qos(netdev_phy, OVN_QOS_TYPE, 
>> >&qdisc_details);
>> >(gdb) n 
>> >259 if (error) {
>> >(gdb) print error
>> >$14 = 0
>> >
>> >
>> >Thanks.
>> >
>> >Hexin
>> >
>> >
>> >
>> >On 1/31/17, 6:12 PM, "Ritesh Rekhi"  wrote:
>> >
>> >>+ Hexin 
>> >>
>> >>-Original Message-
>> >>From: Ben Pfaff [mailto:b...@ovn.org] 
>> >>Sent: Tuesday, January 31, 2017 3:49 PM
>> >>To: Ritesh Rekhi 
>> >>Cc: ovs-discuss@openvswitch.org
>> >>Subject: Re: [ovs-discuss] after setting ovs-vsctl set open . 
>> >>external-ids:ovn-encap-ip=, eth0 stops tansmitting any packets in 
>> >>docker container
>> >>
>> >>OK, what is OVN doing to the routing table or IP address configuration for 
>> >>the docker container?
>> >>
>> >>On Tue, Jan 31, 2017 at 11:12:40PM +, Ritesh Rekhi wrote:
>> >>> That is what I am not able to find.If I have only 1 chassis connected 
>> >>> things work fine. Looks like OVN is doing something to the docker eth0  
>> >>> interface .Again this problem does't happen on a Vm.
>> >>> 
>> >>> It only happens on a docker container (:.
>> >>> 
>> >>> Thx
>> >>> Ritesh
>> >>> 
>> >>> -Original Message-
>> >>> From: Ben Pfaff [mailto:b...@ovn.org]
>> >>> Sent: Tuesday, January 31, 2017 1:38 PM
>> >>> To: Ritesh Rekhi 
>> >>> Cc: ovs-discuss@openvswitch.org
>> >>> Subject: Re: [ovs-discuss] after setting ovs-vsctl set open . 
>> >>> external-ids:ovn-encap-ip=, eth0 stops tansmitting any packets in 
>> >>> docker container
>> >>> 
>> >>> OK, well then, what is happening to the networking stack that causes the 
>> >>> problem?  OVN doesn't do anything to the host routing table or IP 
>> >>> address configuration, at least not intentionally.  What's happening to 
>> >>> the host?
>> >>> 
>> >>> On Tue, Jan 31, 2017 at 06:36:10PM +, Ritesh Rekhi wrote:
>> >>> > Hi Ben,
>> >>> > 
>> >>> > Thx for the reply
>> >>> > 
>> >>> > To repro this issue we don't need any entries in North bound  and 
>> >>> > south bound database.
>> >>> > 
>> >>> > Here are the steps
>> >>> > 
>> >>> > 1) run my docker container
>> >>> > 
>> >>> > docker run -itd  --privileged -e CTL=10.4.163.249   
>> >>> > riteshrekhi/ovnstuff:2.6.90
>> >>> > 
>> >>> > do docker attach and go inside docker container , there

Re: [ovs-discuss] after setting ovs-vsctl set open . external-ids:ovn-encap-ip=, eth0 stops tansmitting any packets in docker container

[Ben Pfaff]

Thanks for locating the root cause.

I sent out a pair of patches that, together, I expect would at least
work around the problem in the common case:
https://patchwork.ozlabs.org/patch/722628/
https://patchwork.ozlabs.org/patch/722629/
Do you think you could try them out?

Thanks,

Ben.

On Wed, Feb 01, 2017 at 07:43:53AM +, Hexin Wang wrote:
> So this is a docker issue, 
> http://stackissue.com/openshift/origin/sdn-set-veth-tx-queue-length-to-unblock-qos-11126.html
> Basically docker creates interface with an explicit 0 txqlen which causes the 
> problem when QoS is switched to htb.
> 
> Thanks.
> 
> Hexin
> 
> 
> 
> 
> On 1/31/17, 6:18 PM, "ovs-discuss-boun...@openvswitch.org on behalf of Hexin 
> Wang"  hexin.w...@nutanix.com> wrote:
> 
> >Looks like the problem is because ovn is trying to touch eth0 qos. The 
> >moment it changes qos_type from “linux-other” to “linux-htb”. Traffic stops 
> >working.
> >
> >setup_qos (queue_map=0x7fffc230, egress_iface=0x63ae10 "eth0") at 
> >ovn/controller/binding.c:240
> >240 int error = netdev_open(egress_iface, NULL, &netdev_phy);
> >(gdb) n
> >241 if (error) {
> >(gdb) 
> >251 smap_init(&qdisc_details);
> >(gdb) 
> >252 if (netdev_get_qos(netdev_phy, &qdisc_type, &qdisc_details) != 0 
> >||
> >(gdb) 
> >253 qdisc_type[0] == '\0') {
> >(gdb) 
> >252 if (netdev_get_qos(netdev_phy, &qdisc_type, &qdisc_details) != 0 
> >||
> >(gdb) 
> >257 if (strcmp(qdisc_type, OVN_QOS_TYPE)) {
> >(gdb) print qdisc_type
> >$12 = 0x778ef8ec "linux-other"
> >(gdb) print qdisc_details
> >$13 = {map = {buckets = 0x7fffc258, one = 0x0, mask = 0, n = 0}}
> >(gdb) n
> >258 error = netdev_set_qos(netdev_phy, OVN_QOS_TYPE, 
> >&qdisc_details);
> >(gdb) n 
> >259 if (error) {
> >(gdb) print error
> >$14 = 0
> >
> >
> >Thanks.
> >
> >Hexin
> >
> >
> >
> >On 1/31/17, 6:12 PM, "Ritesh Rekhi"  wrote:
> >
> >>+ Hexin 
> >>
> >>-Original Message-
> >>From: Ben Pfaff [mailto:b...@ovn.org] 
> >>Sent: Tuesday, January 31, 2017 3:49 PM
> >>To: Ritesh Rekhi 
> >>Cc: ovs-discuss@openvswitch.org
> >>Subject: Re: [ovs-discuss] after setting ovs-vsctl set open . 
> >>external-ids:ovn-encap-ip=, eth0 stops tansmitting any packets in 
> >>docker container
> >>
> >>OK, what is OVN doing to the routing table or IP address configuration for 
> >>the docker container?
> >>
> >>On Tue, Jan 31, 2017 at 11:12:40PM +, Ritesh Rekhi wrote:
> >>> That is what I am not able to find.If I have only 1 chassis connected 
> >>> things work fine. Looks like OVN is doing something to the docker eth0  
> >>> interface .Again this problem does't happen on a Vm.
> >>> 
> >>> It only happens on a docker container (:.
> >>> 
> >>> Thx
> >>> Ritesh
> >>> 
> >>> -Original Message-
> >>> From: Ben Pfaff [mailto:b...@ovn.org]
> >>> Sent: Tuesday, January 31, 2017 1:38 PM
> >>> To: Ritesh Rekhi 
> >>> Cc: ovs-discuss@openvswitch.org
> >>> Subject: Re: [ovs-discuss] after setting ovs-vsctl set open . 
> >>> external-ids:ovn-encap-ip=, eth0 stops tansmitting any packets in 
> >>> docker container
> >>> 
> >>> OK, well then, what is happening to the networking stack that causes the 
> >>> problem?  OVN doesn't do anything to the host routing table or IP address 
> >>> configuration, at least not intentionally.  What's happening to the host?
> >>> 
> >>> On Tue, Jan 31, 2017 at 06:36:10PM +, Ritesh Rekhi wrote:
> >>> > Hi Ben,
> >>> > 
> >>> > Thx for the reply
> >>> > 
> >>> > To repro this issue we don't need any entries in North bound  and south 
> >>> > bound database.
> >>> > 
> >>> > Here are the steps
> >>> > 
> >>> > 1) run my docker container
> >>> > 
> >>> > docker run -itd  --privileged -e CTL=10.4.163.249   
> >>> > riteshrekhi/ovnstuff:2.6.90
> >>> > 
> >>> > do docker attach and go inside docker container , there execute 
> >>> > script test.sh which starts ovsdb-server, ovs-vswitchd and 
> >>> > ovn-controller.After that it will connect to the south-db
> >>> > 
> >>> > using command
> >>> > 
> >>> > ovs-vsctl set open . external-ids:system-id=$uuid ovs-vsctl set open . 
> >>> > external-ids:ovn-remote=tcp:$CTL:6642
> >>> >  ovs-vsctl set open . external-ids:ovn-encap-type=vxlan  ovs-vsctl 
> >>> > set open . external-ids:ovn-encap-ip=$IP
> >>> > 
> >>> > 
> >>> > Right after you execute this script and if connection to south-db 
> >>> > establishes, you won't be able to ping out of eth0
> >>> > 
> >>> > 
> >>> > 2) For version which is working you can do the same thing instead 
> >>> > use riteshrekhi/ovnstuff
> >>> > 
> >>> > Ritesh
> >>> > 
> >>> > ===
> >>> > 
> >>> > South-bound DB
> >>> > 
> >>> > [root@controller ~]# ovn-sbctl show
> >>> > Chassis "0b50e2f7-7421-4536-9441-447af46c4cc4"
> >>> > hostname: "fe11f7697841"
> >>> > Encap vxlan
> >>> > ip: "10.4.150.6"
> >>> > options: {csum="true"}
> 

Re: [ovs-discuss] any help from Python experts? (was: Re: Branch v2.6.1 repo does not make (github))

[Ben Pfaff]

On Wed, Feb 01, 2017 at 09:45:56AM -0500, Robert Wojciechowicz wrote:
> On Tue, Jan 31, 2017 at 03:45:48PM -0800, Ben Pfaff wrote:
> > OK, so looking closer...
> > 
> > The OVS build process runs a few Python programs using syntax like this:
> > PYTHONPATH=$(srcdir)/python:$(PYTHONPATH) python program.py
> > 
> > This means that sys.path ends up looking like:
> > 
> > ['/dir/for/program.py', ..., '/usr/lib/python2.7/dist-packages', ...
> >  '$(srcdir)/python', ...]
> 
> Not really, sys.path is initialized by current working dir, PYTHONPATH 
> and then followed by installation-dependent default paths.

You make it sound like I'm making this up!  But my remarks were based on
observation.  Here's a simple example:

blp@sigabrt:~/nicira/ovs/_build(0)$ PYTHONPATH=$PWD/python python
Python 2.7.13 (default, Dec 18 2016, 20:19:42) 
[GCC 6.2.1 20161215] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.path
['',
'/home/blp/.local/lib/python2.7/site-packages/p4_hlir-0.9.30-py2.7.egg',
'/usr/lib/python2.7/dist-packages',

'/home/blp/.local/lib/python2.7/site-packages/p4c_behavioral-0.9.4-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/PyYAML-3.11-py2.7-linux-x86_64.egg',
'/home/blp/.local/lib/python2.7/site-packages/protobuf-3.0.0b3-py2.7.egg',
'/home/blp/nicira/ovs/_build/python', '/usr/lib/python2.7',
'/usr/lib/python2.7/plat-i386-linux-gnu',
'/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/home/blp/.local/lib/python2.7/site-packages',
'/usr/local/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages/PILcompat',
'/usr/lib/python2.7/dist-packages/gtk-2.0',
'/usr/lib/pymodules/python2.7']
>>> 

As you can see, /usr/lib/python2.7/dist-packages is well ahead of
/home/blp/nicira/ovs/_build/python.

Why does your Python act different from mine in this respect?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] cannot read config file

[Avi Cohen (A)]

Hi,
I'm failing  to read some config file from a vswitchd thread .
Reading this file from the main process vswitchd is OK - any idea why ?
Regards avi 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] any help from Python experts? (was: Re: Branch v2.6.1 repo does not make (github))

[Robert Wojciechowicz]

On Tue, Jan 31, 2017 at 03:45:48PM -0800, Ben Pfaff wrote:
> OK, so looking closer...
> 
> The OVS build process runs a few Python programs using syntax like this:
> PYTHONPATH=$(srcdir)/python:$(PYTHONPATH) python program.py
> 
> This means that sys.path ends up looking like:
> 
> ['/dir/for/program.py', ..., '/usr/lib/python2.7/dist-packages', ...
>  '$(srcdir)/python', ...]

Not really, sys.path is initialized by current working dir, PYTHONPATH 
and then followed by installation-dependent default paths.

https://docs.python.org/2/library/sys.html#sys.path

$ python -V
Python 2.7.5

$ python -c "import sys; print '\n'.join(sys.path)"

/usr/lib64/python27.zip
/usr/lib64/python2.7
/usr/lib64/python2.7/plat-linux2
/usr/lib64/python2.7/lib-tk
/usr/lib64/python2.7/lib-old
/usr/lib64/python2.7/lib-dynload
/usr/lib64/python2.7/site-packages
/usr/lib/python2.7/site-packages

$ PYTHONPATH=./python python -c "import sys; print '\n'.join(sys.path)"

/home/rwojciex/src/ovs/python
/usr/lib64/python27.zip
/usr/lib64/python2.7
/usr/lib64/python2.7/plat-linux2
/usr/lib64/python2.7/lib-tk
/usr/lib64/python2.7/lib-old
/usr/lib64/python2.7/lib-dynload
/usr/lib64/python2.7/site-packages
/usr/lib/python2.7/site-packages

$ PYTHONPATH=./python:/tmp/old_python python -c "import sys; print 
'\n'.join(sys.path)"

/home/rwojciex/src/ovs/python
/tmp/old_python
/usr/lib64/python27.zip
/usr/lib64/python2.7
/usr/lib64/python2.7/plat-linux2
/usr/lib64/python2.7/lib-tk
/usr/lib64/python2.7/lib-old
/usr/lib64/python2.7/lib-dynload
/usr/lib64/python2.7/site-packages
/usr/lib/python2.7/site-packages

So PYTHONPATH directories are always searched after current working directory,
but before system default paths.


> 
> where /usr/lib/python2.7/dist-packages is the distro's Python package
> installation directory, which is where the python-openvswitch package
> installs its .py files.  This has the effect that these installed files
> override the ones in the source directory.
> 
> Python experts, what's the best way to get $(srcdir)/python ahead of
> /usr/lib/python2.7/dist-packages in sys.path?

In such strange cases like this I always use python "-v" option
which shows exactly from what directory modules I loaded (in error stream) e.g.:


$ PYTHONPATH=./python:/tmp/old_python /usr/bin/python -v ./ovsdb/ovsdb-idlc.in 
c-idl-source lib/vswitch-idl.ovsidl 2>&1 | grep ovs.db.types
# /home/rwojciex/src/ovs/python/ovs/db/types.pyc matches 
/home/rwojciex/src/ovs/python/ovs/db/types.py
import ovs.db.types # precompiled from 
/home/rwojciex/src/ovs/python/ovs/db/types.pyc
# cleanup[2] ovs.db.types

$ PYTHONPATH=/tmp/old_python:./python /usr/bin/python -v ./ovsdb/ovsdb-idlc.in 
c-idl-source lib/vswitch-idl.ovsidl 2>&1 | grep ovs.db.types
# /tmp/old_python/ovs/db/types.pyc matches /tmp/old_python/ovs/db/types.py
import ovs.db.types # precompiled from /tmp/old_python/ovs/db/types.pyc
# cleanup[2] ovs.db.types

Somehow in this case ovs.db.types module was loaded from different location 
than expected.


> 
> Thanks,
> 
> Ben.

HTH,
Robert

> 
> On Sun, Jan 29, 2017 at 05:16:29PM +, Logu J wrote:
> > Ben,
> > 
> > Thanks for the tip. make succeeded after removing 'python-openvswitch'
> > package.
> > 
> > ubuntu@sdnhubvm:openvswitch[22:32] (master)$ dpkg -l | grep openvswitch
> > rc  openvswitch-controller2.0.1+git20140120-0ubuntu2
> >amd64Open vSwitch controller implementation
> > ii  openvswitch-datapath-source   2.3.90-1
> >all  Open vSwitch datapath module source - module-assistant
> > version
> > rc  openvswitch-ipsec 2.1.0-1
> >   amd64Open vSwitch GRE-over-IPsec support
> > rc  openvswitch-pki   2.3.90-1
> >all  Open vSwitch public key infrastructure dependency
> > package
> > rc  openvswitch-switch2.3.90-1
> >amd64Open vSwitch switch implementations
> > rc  openvswitch-vtep  2.1.0-1
> >   amd64Open vSwitch VTEP utilities
> > ii  python-openvswitch2.3.90-1
> >all  Python bindings for Open vSwitch
> > 
> > Regards,
> > Logu
> > 
> > On Sun, Jan 29, 2017 at 10:16 AM Ben Pfaff  wrote:
> > 
> > Perhaps you have some old version of the Python libraries for Open
> > vSwitch installed somewhere?  In older versions of OVS, the function in
> > question did have fewer arguments.
> > 
> > I don't know why a system installation of a Python library would
> > override the version in the OVS tree.  Probably need help from a Python
> > expert on that.
> > 
> > On Sun, Jan 29, 2017 at 03:27:52AM +, Logu J wrote:
> > > Ben,
> > >
> > > checked out latest code from github and compiling.
> > >
> > > I was getting same error on master branch, so I was trying to compile with
> > > v2.6.1. Thanks for pointing out my mistake.
> > >
> > > Now I switched to v2.6.1 with 'git checkout tags/v2.6.1', still make fails
> > > with same er