Re: [ovs-discuss] Failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel 3.10.0-514.2.2.el7.x86_64)

2017-01-11 Thread LIU Yulong 
Great, that patch works for me.
After cherry-picked that patch to 2.6.1, we can also build the 2.6.1 ovs
kmod.
Thank you very much.

On Thu, Jan 12, 2017 at 10:21 AM, Joe Stringer  wrote:

> Does your master include this commit?
>
> https://github.com/openvswitch/ovs/commit/6ccf21ca77ec092aa6
> 3b3daff66dc9f0d0e1be93
>
> On 11/01/2017 18:14, "liu yulong"  wrote:
>
> Thanks Joe and Ben, actually the master branch we also got such error.
> The doc we followed is "Fedora, RHEL 7.x Packaging for Open vSwitch" [1].
> The conflicting shown in [2] was basically same.
>
> [1] https://github.com/openvswitch/ovs/blob/master/Documentation
> /intro/install/fedora.rst
> [2] http://paste.openstack.org/show/594350/
>
> On Thu, Jan 12, 2017 at 7:51 AM, Joe Stringer  wrote:
>
>> On 11 January 2017 at 15:38, Ben Pfaff  wrote:
>> > On Wed, Jan 11, 2017 at 03:03:45PM -0800, Joe Stringer wrote:
>> >> On 9 January 2017 at 19:01, liu yulong  wrote:
>> >> > Hi experts,
>> >> >
>> >> > We have failed to build Open vSwitch Kernel Modules on CentOS 7
>> (kernel
>> >> > 3.10.0-514.2.2.el7.x86_64).
>> >> >
>> >> > Here are some traces we got:
>> >> > http://paste.openstack.org/show/594350/
>> >> >
>> >> > Steps:
>> >> > 1. download the current openvswitch release:
>> >> > http://openvswitch.org/releases/openvswitch-2.6.1.tar.gz
>> >> >
>> >> > 2. rpmbuild
>> >> > (1) prepare the SOURCE
>> >> > cp openvswitch-2.6.1.tar.gz ~/rpmbuild/SOURCES/
>> >> > tar -zxvf openvswitch-2.6.1.tar.gz
>> >> > cp ./openvswitch-2.6.1/rhel/* ~/rpmbuild/SOURCES/
>> >> > cp ./openvswitch-2.6.1/rhel/*.spec ~/rpmbuild/SPECS/
>> >> >
>> >> >
>> >> > (2) edit ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec
>> >> > change the #%define kernel to:
>> >> > #%define kernel 3.10.0-514.2.2.el7.x86_64
>> >> >
>> >> > (3) start build
>> >> > rpmbuild -bb --without check ~/rpmbuild/SPECS/openvswitch-k
>> mod-fedora.spec
>> >> >
>> >> > Then we get that error. So can anyone help to solve such issue?
>> >> > Thank you.
>> >>
>> >> If you want to use the kernel module from the OVS tree, you need to
>> >> use master or wait for the next version of OVS. Alternatively you can
>> >> skip using the kernel module from OVS tree and only compile the
>> >> userspace programs, then use the kernel module that is provided with
>> >> Centos 7.
>> >
>> > Maybe liu is confused because the FAQ that comes with OVS 2.6.1 says
>> > that the kernel module should work with Linux 3.10.  Maybe it does not
>> > work because Centos kernels diverge from upstream.
>>
>> True, it's a bit confusing. The FAQ distributed with 2.6 specifically
>> states the supported versions, with this caveat:
>>
>> "The Linux kernel versions are upstream kernel versions, so Linux
>> kernels modified from the upstream sources may not build in some cases
>> even if they are based on a supported version. This is most notably
>> true of Red Hat Enterprise Linux (RHEL) kernels, which are extensively
>> modified from upstream."
>>
>> https://github.com/openvswitch/ovs/blob/branch-2.6/FAQ.md#q-
>> what-linux-kernel-versions-does-each-open-vswitch-release-work-with
>>
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel 3.10.0-514.2.2.el7.x86_64)

2017-01-11 Thread Ben Pfaff 
On Wed, Jan 11, 2017 at 03:03:45PM -0800, Joe Stringer wrote:
> On 9 January 2017 at 19:01, liu yulong  wrote:
> > Hi experts,
> >
> > We have failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel
> > 3.10.0-514.2.2.el7.x86_64).
> >
> > Here are some traces we got:
> > http://paste.openstack.org/show/594350/
> >
> > Steps:
> > 1. download the current openvswitch release:
> > http://openvswitch.org/releases/openvswitch-2.6.1.tar.gz
> >
> > 2. rpmbuild
> > (1) prepare the SOURCE
> > cp openvswitch-2.6.1.tar.gz ~/rpmbuild/SOURCES/
> > tar -zxvf openvswitch-2.6.1.tar.gz
> > cp ./openvswitch-2.6.1/rhel/* ~/rpmbuild/SOURCES/
> > cp ./openvswitch-2.6.1/rhel/*.spec ~/rpmbuild/SPECS/
> >
> >
> > (2) edit ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec
> > change the #%define kernel to:
> > #%define kernel 3.10.0-514.2.2.el7.x86_64
> >
> > (3) start build
> > rpmbuild -bb --without check ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec
> >
> > Then we get that error. So can anyone help to solve such issue?
> > Thank you.
> 
> If you want to use the kernel module from the OVS tree, you need to
> use master or wait for the next version of OVS. Alternatively you can
> skip using the kernel module from OVS tree and only compile the
> userspace programs, then use the kernel module that is provided with
> Centos 7.

Maybe liu is confused because the FAQ that comes with OVS 2.6.1 says
that the kernel module should work with Linux 3.10.  Maybe it does not
work because Centos kernels diverge from upstream.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel 3.10.0-514.2.2.el7.x86_64)

2017-01-11 Thread Joe Stringer 
On 9 January 2017 at 19:01, liu yulong  wrote:
> Hi experts,
>
> We have failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel
> 3.10.0-514.2.2.el7.x86_64).
>
> Here are some traces we got:
> http://paste.openstack.org/show/594350/
>
> Steps:
> 1. download the current openvswitch release:
> http://openvswitch.org/releases/openvswitch-2.6.1.tar.gz
>
> 2. rpmbuild
> (1) prepare the SOURCE
> cp openvswitch-2.6.1.tar.gz ~/rpmbuild/SOURCES/
> tar -zxvf openvswitch-2.6.1.tar.gz
> cp ./openvswitch-2.6.1/rhel/* ~/rpmbuild/SOURCES/
> cp ./openvswitch-2.6.1/rhel/*.spec ~/rpmbuild/SPECS/
>
>
> (2) edit ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec
> change the #%define kernel to:
> #%define kernel 3.10.0-514.2.2.el7.x86_64
>
> (3) start build
> rpmbuild -bb --without check ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec
>
> Then we get that error. So can anyone help to solve such issue?
> Thank you.

If you want to use the kernel module from the OVS tree, you need to
use master or wait for the next version of OVS. Alternatively you can
skip using the kernel module from OVS tree and only compile the
userspace programs, then use the kernel module that is provided with
Centos 7.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] clear interface statistics

2017-01-11 Thread Ben Pfaff 
On Wed, Jan 11, 2017 at 09:48:47AM +, Avi Cohen wrote:
> Is  it possible to clear interface stats ?

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

[ovs-discuss] Failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel 3.10.0-514.2.2.el7.x86_64)

2017-01-11 Thread liu yulong 
Hi experts,

We have failed to build Open vSwitch Kernel Modules on CentOS 7 (kernel
3.10.0-514.2.2.el7.x86_64).

Here are some traces we got:
http://paste.openstack.org/show/594350/

Steps:
1. download the current openvswitch release:
http://openvswitch.org/releases/openvswitch-2.6.1.tar.gz

2. rpmbuild
(1) prepare the SOURCE
cp openvswitch-2.6.1.tar.gz ~/rpmbuild/SOURCES/
tar -zxvf openvswitch-2.6.1.tar.gz
cp ./openvswitch-2.6.1/rhel/* ~/rpmbuild/SOURCES/
cp ./openvswitch-2.6.1/rhel/*.spec ~/rpmbuild/SPECS/


(2) edit ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec
change the #%define kernel to:
#%define kernel 3.10.0-514.2.2.el7.x86_64

(3) start build
rpmbuild -bb --without check ~/rpmbuild/SPECS/openvswitch-kmod-fedora.spec

Then we get that error. So can anyone help to solve such issue?
Thank you.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] how many queues in openvswitch?

2017-01-11 Thread 杨润垲 
Dear friend:
hello,I am a graduated student in BJTU, China, my major is CS. I'm interested 
in openvswitch, and i have a question. Could you tell me how many queues or 
buffer are there in  openvswitch , and what they are? I'm looking forward to 
your reply. Thanks!
Sincerely yours,
Aaron___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Re： On OVNDB-HA using pacemaker two issues discussed

2017-01-11 Thread Babu Shanmugam 
When /etc/openvswitch/ovn-northd-db-params.conf is present in the 
machine(s) that northd is starting, northd service will not launch the 
ovsdb servers. You can have a look at 
https://review.openstack.org/#/c/372274/3/manifests/profile/pacemaker/neutron/plugins/ml2/ovn.pp 
to know how its done in openstack deployments.


--

Babu

On Thursday 08 December 2016 07:30 AM, 李国帅 - 姜尚0387 wrote:

Systemd also manages the ovsdb process, will there be a conflict?

--
发件人：Babu Shanmugam 
发送时间：2016年12月8日(星期四) 09:26
收件人：姜尚0387 ; discuss
; Andy Zhou ; blp

主　题：Re: [ovs-discuss] On OVNDB-HA using pacemaker two issues
discussed



On Wednesday 07 December 2016 08:58 AM, 姜尚0387 wrote:

I am learning OVNDB-HA using pacemaker, I feel this is a good design.

At the same time I have two questions and would like to discuss:

  1,  we have two resources, one is the master node of the OVNDB,
one is VIP.

   Pacemaker resource constraints are dependencies, not
symbiotic, so we must consider who depends on who.


http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/s-resource-colocation.html

   If the master node OVNDB dependence VIP,  VIP or VIP
network down, OVNDB master node will follow the VIP migration, But
the OVNDB process of the master node is dead and there is no
migration.

   If the VIP is dependent on the OVNDB master process,  When
the OVNDB master process down, all will migrate. And VIP or VIP
network down Indicating that the node is down, all will migration.

   Is it better to configure the resource constraints ？

   pcs constraint order ovndb_servers-master then VirtualIP
   pcs constraint colocation add VirtualIP with master ovndb_servers-master 
score=INFINITY


  2,  OVN nodes in a total of three processes, the South to the
database, north to the database, northd process.

   But only in the OCF script to start and monitor the
database process, there is no northd process.

 How to ensure high reliability northd process?

 My idea is OCF script at the same time start and monitor
northd process, because I think these three processes is together.



We have the systemd resource for ovn-northd. One can create
primitive systemd pacemaker resource for northd which will start
ovn-north in another in cluster when the node in which it runs fails.




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

Re: [ovs-discuss] On OVNDB-HA using pacemaker two issues discussed

2017-01-11 Thread Babu Shanmugam 



On Wednesday 07 December 2016 08:58 AM, 姜尚0387 wrote:


I am learning OVNDB-HA using pacemaker, I feel this is a good design.

At the same time I have two questions and would like to discuss:

  1,  we have two resources, one is the master node of the OVNDB, one 
is VIP.


   Pacemaker resource constraints are dependencies, not symbiotic, 
so we must consider who depends on who.


http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/s-resource-colocation.html

   If the master node OVNDB dependence VIP,  VIP or VIP network 
down, OVNDB master node will follow the VIP migration, But the OVNDB 
process of the master node is dead and there is no migration.


   If the VIP is dependent on the OVNDB master process, When the 
OVNDB master process down, all will migrate. And VIP or VIP network 
down Indicating that the node is down, all will migration.


   Is it better to configure the resource constraints ？

   pcs constraint order ovndb_servers-master then VirtualIP
   pcs constraint colocation add VirtualIP with master ovndb_servers-master 
score=INFINITY


  2,  OVN nodes in a total of three processes, the South to the 
database, north to the database, northd process.


   But only in the OCF script to start and monitor the database 
process, there is no northd process.


 How to ensure high reliability northd process?

 My idea is OCF script at the same time start and monitor 
northd process, because I think these three processes is together.





We have the systemd resource for ovn-northd. One can create primitive 
systemd pacemaker resource for northd which will start ovn-north in 
another in cluster when the node in which it runs fails.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] kernel panic when setting QoS parameters more than once

2017-01-11 Thread Joe Stringer 
On 10 January 2017 at 05:46, Riccardo R.  wrote:
> Hi,
>
> By setting QoS parameters more than once on an OpenvSwitch bridge, we caused
> kernel panic on our machine. This is
> reproducible with the following commands:
>
> $ ovs-vsctl add-br mybridge
> $ ovs-vsctl add-port mybridge myiface
> $ ovs-vsctl set interface myiface  ingress_policing_rate=100
> # with the command below the kernel will crash, regardless of the value
> given as input:
> $ ovs-vsctl set interface myiface  ingress_policing_rate=1000
>
> We tried this with openvswitch 2.4 and 2.6.1 on a 4.6 Linux kernel.
> Interestingly, it works correctly on openvswitch 2.3.0 installed on a 3.16
> kernel.

Are you able to get the kernel backtrace from the console when it crashes?

Most likely this is a regression in upstream Linux for the kernel that
you are seeing the problem. Can you provide more details? Eg, where
did you get your 4.6 kernel from? What is the full "uname -r" version
for it? What .config was used when compiling it? Are you able to also
try other versions, eg 4.4 or 4.9?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] VXLAN support in OVS 2.5.0

2017-01-11 Thread Scott Lowe 
On 01/11/2017 03:54 AM, Shravan S K wrote:
> Like this?
> vm01---|  
>   
> |--vm03
>  
> br1(vxlanport1)br-int1=br-int2--(vxlanport2)br2
> vm02---|  
>
> |---vm04
> 
> What is the need for the bridges br-int1 and br-int2? Why is it not
> possible without them(as the topology shown earlier in this thread)?


[SL] No, I don't think this is the configuration you'd want to use. The
"br-int" bridges aren't strictly required; you could use br1 and br2.
The trick here---as you're trying to create a VXLAN tunnel within a
host---would be that you'll need 2 IP endpoints (one for each end of the
tunnel), and you'd need each bridge with a VXLAN port to be associated
with one of those IP endpoints.

As I said, though, I haven't tested a configuration like this. Further,
to be honest, I'm not really sure what you're trying to accomplish with
such a configuration.


> Shravan
> 
> On 11 January 2017 at 11:59, Scott Lowe  > wrote:
> 
> Please see my response inline, prefixed with [SL].
> 
> 
> On 01/10/2017 09:50 PM, Shravan S K wrote:
>> I am asking if that can be done on a single physical host having
>> OVS. Say, as mininet creates bridges which act as switches. Can
>> vxlan be setup using Mininet?
> 
> 
> [SL] I don't know if it's possible for Mininet to set up VXLAN;
> that's a question best asked on a Mininet-related forum.
> 
> As for whether it can be done on a single host, I suppose if you were
> to use 2 separate bridges for physical connectivity along with 2
> separate bridges for the tunnels, it might work. I've never tried it,
> though, so this is just conjecture.
> 
> 
>> Shravan
>>
>> On 10 January 2017 at 23:33, Scott Lowe > 
>> >> wrote:
>>
>> Please see my response below.
>>
>>
>> On 01/10/2017 02:26 AM, Shravan S K wrote:
>>> Is it possible to create a VXLAN setup using just bridges created
>>> by OVS? (using ovs-vsctl to create these bridges,ports and vxlan
>>> config)
>>>
>>> vm01---| |--vm03
>>>   br1---br2
>>> vm02---| |---vm04
>>
>>
>> Yes, this is possible. On each hypervisor where OVS is running and
>> where you have VMs you'd like to connect over VXLAN tunnels, create
>> a bridge ("br-tun", for example). Create and configure a VXLAN port
>> appropriately on br-tun on each hypervisor, and then connect your
>> VMs. You should be good to go. My website has an example of doing
>> this with GRE; VXLAN should be nearly identical.
>>
>> Hope this helps,


-- 
Scott




signature.asc
Description: OpenPGP digital signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-bonded igb nics flopping

2017-01-11 Thread Ben Pfaff 
On Wed, Jan 11, 2017 at 01:15:10PM +, Matias Vara wrote:
> Hi everyone and sorry for the multiple emails, we are facing a flopping of
> igb (5.3.4.4) nics which are bonded by using openvswitch. I am in XenServer
> which is based on CentOS. I am not sure if the problem is the driver or
> openvswitch. We have six nics that are bonded into two groups of three. The
> issue appers after some time that the nics are bonded. The *kern.log* shows
> (part of):

OVS just sends and receives packets on interfaces.  It's hard to imagine
how it would cause a link to flap at the driver level.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] ovs-bonded igb nics flopping

2017-01-11 Thread Matias Vara 
Hi everyone and sorry for the multiple emails, we are facing a flopping of
igb (5.3.4.4) nics which are bonded by using openvswitch. I am in XenServer
which is based on CentOS. I am not sure if the problem is the driver or
openvswitch. We have six nics that are bonded into two groups of three. The
issue appers after some time that the nics are bonded. The *kern.log* shows
(part of):

Nov  1 15:39:56 AxenD1 kernel: [1017001.797897] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:39:56 AxenD1 kernel: [1017001.887470] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:40:00 AxenD1 kernel: [1017005.577876] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:00 AxenD1 kernel: [1017005.781865] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:10 AxenD1 kernel: [1017015.861861] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:10 AxenD1 kernel: [1017015.959454] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:40:14 AxenD1 kernel: [1017019.689864] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:14 AxenD1 kernel: [1017020.157869] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:25 AxenD1 kernel: [1017030.837873] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:25 AxenD1 kernel: [1017030.919331] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:40:28 AxenD1 kernel: [1017034.205864] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:29 AxenD1 kernel: [1017034.829864] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:39 AxenD1 kernel: [1017044.837856] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:39 AxenD1 kernel: [1017044.931369] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:40:43 AxenD1 kernel: [1017048.649860] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:43 AxenD1 kernel: [1017048.841867] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:53 AxenD1 kernel: [1017058.853860] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:53 AxenD1 kernel: [1017058.943421] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:40:56 AxenD1 kernel: [1017062.329849] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:40:57 AxenD1 kernel: [1017063.217873] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:00 AxenD1 kernel: [1017066.032048] vif vif-537-0 vif537.0:
Guest Rx stalled
Nov  1 15:41:08 AxenD1 kernel: [1017073.845863] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:08 AxenD1 kernel: [1017073.935291] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:41:11 AxenD1 kernel: [1017077.133868] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:12 AxenD1 kernel: [1017077.841902] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:22 AxenD1 kernel: [1017087.845881] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:22 AxenD1 kernel: [1017087.935415] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:41:26 AxenD1 kernel: [1017091.785868] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:26 AxenD1 kernel: [1017092.105875] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:37 AxenD1 kernel: [1017102.773865] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:37 AxenD1 kernel: [1017102.863320] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:41:40 AxenD1 kernel: [1017106.101863] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:41 AxenD1 kernel: [1017107.241867] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:51 AxenD1 kernel: [1017116.725860] igb :15:00.0 eth0: igb:
eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:51 AxenD1 kernel: [1017116.815206] igb :15:00.0 eth0: igb:
eth0 NIC Link is Down
Nov  1 15:41:55 AxenD1 kernel: [1017120.521882] igb :15:00.1 eth1: igb:
eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Nov  1 15:41:55 AxenD1 kernel: [1017120.725854] igb

Re: [ovs-discuss] VXLAN support in OVS 2.5.0

2017-01-11 Thread Shravan S K 
Like this?
vm01---|
|--vm03

br1(vxlanport1)br-int1=br-int2--(vxlanport2)br2
vm02---|
|---vm04

What is the need for the bridges br-int1 and br-int2? Why is it not
possible without them(as the topology shown earlier in this thread)?




Shravan

On 11 January 2017 at 11:59, Scott Lowe  wrote:

> Please see my response inline, prefixed with [SL].
>
>
> On 01/10/2017 09:50 PM, Shravan S K wrote:
> > I am asking if that can be done on a single physical host having OVS.
> > Say, as mininet creates bridges which act as switches. Can vxlan be
> > setup using Mininet?
>
>
> [SL] I don't know if it's possible for Mininet to set up VXLAN; that's a
> question best asked on a Mininet-related forum.
>
> As for whether it can be done on a single host, I suppose if you were to
> use 2 separate bridges for physical connectivity along with 2 separate
> bridges for the tunnels, it might work. I've never tried it, though, so
> this is just conjecture.
>
>
> > Shravan
> >
> > On 10 January 2017 at 23:33, Scott Lowe  > > wrote:
> >
> > Please see my response below.
> >
> >
> > On 01/10/2017 02:26 AM, Shravan S K wrote:
> > > Is it possible to create a VXLAN setup using just bridges created
> by
> > > OVS? (using ovs-vsctl to create these bridges,ports and vxlan
> config)
> > >
> > > vm01---| |--vm03
> > >   br1---br2
> > > vm02---| |---vm04
> >
> >
> > Yes, this is possible. On each hypervisor where OVS is running and
> where
> > you have VMs you'd like to connect over VXLAN tunnels, create a
> bridge
> > ("br-tun", for example). Create and configure a VXLAN port
> appropriately
> > on br-tun on each hypervisor, and then connect your VMs. You should
> be
> > good to go. My website has an example of doing this with GRE; VXLAN
> > should be nearly identical.
> >
> > Hope this helps,
>
>
> --
> Scott
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

2017-01-11 Thread Brandon Cheng 
Hi,

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?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss