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

[Michael Ben-Ami via discuss]

Shravan, these mininet branches seem to address our problem:

https://github.com/mininet/mininet/pull/577
https://github.com/mininet/mininet/pull/524

I've had more luck with the first one.

On Fri, Jan 13, 2017 at 1:40 PM, Michael Ben-Ami 
wrote:

> Thanks Joe, I'm looking at feasibility submitting a PR to mininet so that
> it can natively accomplish exactly this.
>
> On Fri, Jan 13, 2017 at 1:31 PM, Joe Stringer  wrote:
>
>> On 13 January 2017 at 08:20, Michael Ben-Ami via discuss
>>  wrote:
>> > I'm in a very similar boat as Shravan. The utility for me is to be able
>> to
>> > test flow sets on arbitrary mininet topologies that simulate real world
>> > topologies that may or may not use VXLAN. The root cause as I see it is
>> that
>> > mininet must put all OVS bridges in the same namespace. This is
>> probably an
>> > OVS limitation not mininet. Has been discussed a little here:
>> > https://mail.openvswitch.org/pipermail/ovs-discuss/2015-Sept
>> ember/038543.html
>>
>> For what it's worth, I believe that this is a limitation for each OVS
>> instance - each instance can only run bridges in the namespace it is
>> running. If you ran multiple copies of OVS in different network
>> namespaces / containers, it should work. (So would running the copies
>> in different VMs)
>>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Matias Vara]

Thank you very much Felipe and Bef, I will ask again intel about this.

Matias

2017-01-13 20:55 GMT+00:00 Felipe Arturo Polanco :

> Some ixgbe NICs of Intel require recompilation of driver if packet
>  forwarding  is being used.
>
> There is a flag that needs to be put to false in the arguments to avoid
> issues like the one you describe.
>
> If this is your case Please go to the Readme file of your driver source
> code and scroll down to the part of LZO flag warning and packet forwarding
> for more information.
>
>
> On Jan 13, 2017 4:46 PM, "Ben Pfaff"  wrote:
>
> That does seem likely to me, but if you discover any evidence that
> points to OVS, please do come back and talk to us again.
>
> On Thu, Jan 12, 2017 at 10:40:07AM +, Matias Vara wrote:
> > Thank you Ben, so the problem could in the driver or in the kernel.
> >
> > 2017-01-11 17:37 GMT+00:00 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
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Ben Pfaff]

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;

Thanks,

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

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

[Felipe Arturo Polanco]

Some ixgbe NICs of Intel require recompilation of driver if packet
 forwarding  is being used.

There is a flag that needs to be put to false in the arguments to avoid
issues like the one you describe.

If this is your case Please go to the Readme file of your driver source
code and scroll down to the part of LZO flag warning and packet forwarding
for more information.


On Jan 13, 2017 4:46 PM, "Ben Pfaff"  wrote:

That does seem likely to me, but if you discover any evidence that
points to OVS, please do come back and talk to us again.

On Thu, Jan 12, 2017 at 10:40:07AM +, Matias Vara wrote:
> Thank you Ben, so the problem could in the driver or in the kernel.
>
> 2017-01-11 17:37 GMT+00:00 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
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Ben Pfaff]

That does seem likely to me, but if you discover any evidence that
points to OVS, please do come back and talk to us again.

On Thu, Jan 12, 2017 at 10:40:07AM +, Matias Vara wrote:
> Thank you Ben, so the problem could in the driver or in the kernel.
> 
> 2017-01-11 17:37 GMT+00:00 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

Re: [ovs-discuss] \\答复: It takes too long to create 512 bridges in ovs2.5.0

[Ben Pfaff]

This does seem like a worthwhile change.  Will you submit it as an
official patch?

Thanks,

Ben.

On Thu, Jan 12, 2017 at 08:33:44AM +, zhangsha (A) wrote:
> Hi, Ben
> Thanks for your reply, which means a lot to me. 
> It is much faster if I create 512 bridges in a single transaction, like 
> restarting service. But This is not feasible in all the tests. Sometimes I 
> need it to be more extensive(e.g., creating a new virtual machine at any 
> time).
> So, I am thinking maybe I can move the xlate_txn_start() and 
> xlate_txn_commit() out of the loop(See the following patch, please)?
> As a global variable, new_xcfg only needs to be allocated once time at the 
> beginning and to be commited at the end, other than in loop body(This causes 
> many unnecessary allocations, free, and synchronize, I think).
> 
> ofproto/ofproto-dpif.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> index b101d22..0019d0a 100644
> --- a/ofproto/ofproto-dpif.c
> +++ b/ofproto/ofproto-dpif.c
> @@ -667,6 +667,7 @@ type_run(const char *type)
>  }
>  backer->need_revalidate = 0;
>  
> +xlate_txn_start();
>  HMAP_FOR_EACH (ofproto, all_ofproto_dpifs_node, &all_ofproto_dpifs) {
>  struct ofport_dpif *ofport;
>  struct ofbundle *bundle;
> @@ -675,7 +676,6 @@ type_run(const char *type)
>  continue;
>  }
>  
> -xlate_txn_start();
>  xlate_ofproto_set(ofproto, ofproto->up.name,
>ofproto->backer->dpif, ofproto->ml,
>ofproto->stp, ofproto->rstp, ofproto->ms,
> @@ -709,9 +709,9 @@ type_run(const char *type)
>   ofport->up.pp.state, ofport->is_tunnel,
>   ofport->may_enable);
>  }
> -xlate_txn_commit();
>  }
>  
> +xlate_txn_commit();
>  udpif_revalidate(backer->udpif);
>  }
> 
> -邮件原件-
> 发件人: Ben Pfaff [mailto:b...@ovn.org] 
> 发送时间: 2016年12月27日 2:38
> 收件人: zhangsha (A)
> 抄送: ovs-discuss@openvswitch.org; caihe; wr...@nicira.com; et...@nicira.com
> 主题: Re: [ovs-discuss] It takes too long to create 512 bridges in ovs2.5.0
> 
> On Wed, Dec 14, 2016 at 02:33:39PM +, zhangsha (A) wrote:
> > Hi, all
> > 
> > In my test scenario, I found that it takes too long time, 488s, to create 
> > 512 bridges in ovs 2.5.0.
> > After analyzing the code and some tests, I found that more than 70% of the 
> > time was consumed in the implementation of function xlate_txn_commit.
> > Function type_run calls xlate_txn_start and xlate_txn_commit(calls 
> > ovsrcu_synchronize) to implement RCU locking in each cycle of the loop.
> > Function ovsrcu_synchronize() was called too much times if there are 
> > certain number bridges, which means a lot of time waste.
> > 
> > So, I was thinking if I can use ovsrcu_postpone replacing 
> > ovsrcu_synchronize to shorten the execution time of type_run when there are 
> > certain number bridges.
> > I have tested this, and the result indicates that the time of creating 512 
> > bridges will be short down to 269s. Result and my patch is as follows:
> > 
> > 
> > ovsrcu_postpone
> > 
> > ovsrcu_synchronize
> > 
> > ovs
> > 
> > 269
> > 
> > 488
> > 
> > 
> > 
> > This is my patch:
> > ofproto/ofproto-dpif-xlate.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/ofproto/ofproto-dpif-xlate.c 
> > b/ofproto/ofproto-dpif-xlate.c index d5f18b6..59f4b5c 100644
> > --- a/ofproto/ofproto-dpif-xlate.c
> > +++ b/ofproto/ofproto-dpif-xlate.c
> > @@ -865,8 +865,9 @@ xlate_txn_commit(void)
> >  struct xlate_cfg *xcfg = ovsrcu_get(struct xlate_cfg *, &xcfgp);
> >  ovsrcu_set(&xcfgp, new_xcfg);
> > -ovsrcu_synchronize();
> > -xlate_xcfg_free(xcfg);
> > +ovsrcu_postpone(xlate_xcfg_free, xcfg);
> >  new_xcfg = NULL;
> > }
> > 
> > Whether this modification will introduce any problems?
> 
> Yes.  See the following commit.
> 
> It sounds like you're creating each bridge in a separate database 
> transaction.  If you create them in a single transaction, it will be much 
> faster.
> 
> --8<--cut here-->8--
> 
> From 40a9c4c26be9b59c3494dd5900c21015ea7d27d4 Mon Sep 17 00:00:00 2001
> From: Alex Wang 
> Date: Fri, 7 Nov 2014 13:02:05 -0800
> Subject: [PATCH] ofproto-dpif-xlate: Allow direct destroy of previous config.
> 
> Before this commit, the ofproto-dpif-xlate module uses ovs-rcu to postpone 
> the destroy of previous configuration.  However, the delayed close of object 
> like 'struct netdev' could cause failure in immediate re-add or reconfigure 
> of the same device.
> 
> To fix the above issue, this commit makes the ofproto-dpif-xlate module call 
> ovsrcu_synchronize(), which waits for all threads to finish the use of 
> reference to previous config.  Then, the mod

Re: [ovs-discuss] packet copy action?

[Ben Pfaff]

Sure.  Or whatever makes sense for what you're doing.

On Fri, Jan 13, 2017 at 11:06:33AM -0800, Joo Yong-Seok wrote:
> You mean, one action is normal and the other action is output:?
> 
> Thank you!
> 
> Best regards,
> 
> On Fri, Jan 13, 2017 at 11:04 AM, Ben Pfaff  wrote:
> 
> > On Fri, Jan 13, 2017 at 10:44:10AM -0800, Joo Yong-Seok wrote:
> > > Very quick question. Is there any action like "copying packet" or "packet
> > > monitoring" n openvswitch flow rule?
> > >
> > > I want to send an original packet to the network but maintain packet copy
> > > for the monitoring purpose - (kind of "clone" or "copy" concept in skb.)
> >
> > Just execute two output actions.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] packet copy action?

[Joo Yong-Seok]

You mean, one action is normal and the other action is output:?

Thank you!

Best regards,

On Fri, Jan 13, 2017 at 11:04 AM, Ben Pfaff  wrote:

> On Fri, Jan 13, 2017 at 10:44:10AM -0800, Joo Yong-Seok wrote:
> > Very quick question. Is there any action like "copying packet" or "packet
> > monitoring" n openvswitch flow rule?
> >
> > I want to send an original packet to the network but maintain packet copy
> > for the monitoring purpose - (kind of "clone" or "copy" concept in skb.)
>
> Just execute two output actions.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] packet copy action?

[Ben Pfaff]

On Fri, Jan 13, 2017 at 10:44:10AM -0800, Joo Yong-Seok wrote:
> Very quick question. Is there any action like "copying packet" or "packet
> monitoring" n openvswitch flow rule?
> 
> I want to send an original packet to the network but maintain packet copy
> for the monitoring purpose - (kind of "clone" or "copy" concept in skb.)

Just execute two output actions.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] packet copy action?

[Joo Yong-Seok]

Hello,

Very quick question. Is there any action like "copying packet" or "packet
monitoring" n openvswitch flow rule?

I want to send an original packet to the network but maintain packet copy
for the monitoring purpose - (kind of "clone" or "copy" concept in skb.)

Best regards,

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

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

[Michael Ben-Ami via discuss]

Thanks Joe, I'm looking at feasibility submitting a PR to mininet so that
it can natively accomplish exactly this.

On Fri, Jan 13, 2017 at 1:31 PM, Joe Stringer  wrote:

> On 13 January 2017 at 08:20, Michael Ben-Ami via discuss
>  wrote:
> > I'm in a very similar boat as Shravan. The utility for me is to be able
> to
> > test flow sets on arbitrary mininet topologies that simulate real world
> > topologies that may or may not use VXLAN. The root cause as I see it is
> that
> > mininet must put all OVS bridges in the same namespace. This is probably
> an
> > OVS limitation not mininet. Has been discussed a little here:
> > https://mail.openvswitch.org/pipermail/ovs-discuss/2015-
> September/038543.html
>
> For what it's worth, I believe that this is a limitation for each OVS
> instance - each instance can only run bridges in the namespace it is
> running. If you ran multiple copies of OVS in different network
> namespaces / containers, it should work. (So would running the copies
> in different VMs)
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

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

[Joe Stringer]

On 13 January 2017 at 08:20, Michael Ben-Ami via discuss
 wrote:
> I'm in a very similar boat as Shravan. The utility for me is to be able to
> test flow sets on arbitrary mininet topologies that simulate real world
> topologies that may or may not use VXLAN. The root cause as I see it is that
> mininet must put all OVS bridges in the same namespace. This is probably an
> OVS limitation not mininet. Has been discussed a little here:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2015-September/038543.html

For what it's worth, I believe that this is a limitation for each OVS
instance - each instance can only run bridges in the namespace it is
running. If you ran multiple copies of OVS in different network
namespaces / containers, it should work. (So would running the copies
in different VMs)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] BFD and RSTP don't work together on Open vSwitch 2.5.1

[Vaisanen, Mika]

Hello,

I have done some trials with Open vSwitch RSTP and BFD features. While the 
features work well independently, I have discovered that the features don't 
work well when enabled on the same switch instance.

It seems to be that when BFD is enabled on interface, RSTP considers that link 
down instantly and blocks all outgoing traffic on that interface.  
Unfortunately this includes also the outgoing BFD messages. This leads to 
situation BFD will never get the link up and RSTP will never be able to use the 
link.

Expected behaviour would be that BFD messages are send and received regardless 
of the RSTP state of a link. Eventually BFD would see link state up and RSTP 
could start to use the link.

Software version details:
CentOS 7.2 Linux
Linux version 3.10.0-327.36.3.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc 
version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) ) #1 SMP Mon Oct 24 16:09:20 UTC 
O
ovs-vswitchd (Open vSwitch) 2.5.1


How to reproduce problem:
Two (CentOS) hosts connected together with eno51 interface.

# On host_1
service firewalld stop
ifconfig eno51 192.168.0.11/24 up
ovs-vsctl add-br br2 -- set Bridge br2 rstp_enable=true
ifconfig br2 172.16.20.1/24 up
ovs-vsctl add-port br2 gre0 -- set interface gre0 type=gre 
options:remote_ip=192.168.0.12 options:key=1 bfd:enable=true

# On host_2
service firewalld stop
ifconfig eno51 192.168.0.12/24 up
ovs-vsctl add-br br2 -- set Bridge br2 rstp_enable=true
ifconfig br2 172.16.20.2/24 up
ovs-vsctl add-port br2 gre0 -- set interface gre0 type=gre 
options:remote_ip=192.168.0.11 options:key=1 bfd:enable=true


# BFD sees path down.
[root@host_1 ~]# ovs-appctl bfd/show
 gre0 
Forwarding: false
Detect Multiplier: 3
Concatenated Path Down: false
TX Interval: Approx 1000ms
RX Interval: Approx 1000ms
Detect Time: now +5076509ms
Next TX Time: now -52ms
Last TX Time: now +728ms

Local Flags: none
Local Session State: down
Local Diagnostic: No Diagnostic
Local Discriminator: 0xfd19b281
Local Minimum TX Interval: 1000ms
Local Minimum RX Interval: 1000ms

Remote Flags: none
Remote Session State: down
Remote Diagnostic: No Diagnostic
Remote Discriminator: 0x0
Remote Minimum TX Interval: 0ms
Remote Minimum RX Interval: 1ms


[root@ host_1 ~]# ovs-dpctl show
system@ovs-system:
lookups: hit:1739 missed:81 lost:0
flows: 0
masks: hit:2570 total:1 hit/pkt:1.41
port 0: ovs-system (internal)
port 1: br2 (internal)
port 2: gre_sys (gre)

# RSTP has disabled the port
[root@ host_1 ~]# ovs-vsctl get Port gre0 rstp_status
{rstp_designated_bridge_id="0.000.", rstp_designated_path_cost="0", 
rstp_designated_port_id="", rstp_port_id="8001", rstp_port_role=Disabled, 
rstp_port_state=Discarding}


# Connectivity between bridges is broken.
[root@host_1 ~]# ping -c 1 172.16.20.2
PING 172.16.20.2 (172.16.20.2) 56(84) bytes of data.
>From 172.16.20.1 icmp_seq=1 Destination Host Unreachable

--- 172.16.20.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

# Nothing is being transmitted on the gre tunnel
[root@host_1 ~]# tcpdump -n -i eno51
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno51, link-type EN10MB (Ethernet), capture size 65535 bytes
^C0 packets captured
0 packets received by filter
0 packets dropped by kernel



Note: If I disable either RSTP or BFD on the above configuration, everything 
works. Only when they are both enabled things break down.



BR, Mika





The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.




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

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

[Raymond Burkholder]

Following along with Scott’s thoughts, I have a Vagrant project at 
https://github.com/rburkholder/vagrant which I use for testing various kernels, 
openvswitch versions, and configurations.

 

The OVN test setup provides the ability to configure and connect multiple 
guests, much like mininet does.  And with Vagrant’s snapshot ability, it is 
easy to rollback and redo tests.

 

So…. if you run out of luck on getting what you want in mininet, there is that 
alternate mechanism in VirtualBox and you don’t have to re-invent the wheel to 
get started.

 

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Michael Ben-Ami via 
discuss
Sent: Friday, January 13, 2017 12:21
To: O'Reilly, Darragh 
Cc: ovs-discuss@openvswitch.org
Subject: {Disarmed} Re: [ovs-discuss] VXLAN support in OVS 2.5.0

 

I'm in a very similar boat as Shravan. The utility for me is to be able to test 
flow sets on arbitrary mininet topologies that simulate real world topologies 
that may or may not use VXLAN. The root cause as I see it is that mininet must 
put all OVS bridges in the same namespace. This is probably an OVS limitation 
not mininet. Has been discussed a little here: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2015-September/038543.html

 

Of course you could start mininet itself in different namespaces, but that 
defeats a lot of the purpose of building topologies within a mininet.

 

Shravan, if you find a workable solution please let me know.

 

Thanks,

Michael

 

On Fri, Jan 13, 2017 at 7:07 AM, O'Reilly, Darragh mailto:darragh.orei...@hpe.com> > wrote:

 

Not sure what you are trying to do. But if you just want to connect two bridges 
on the same host, then you can use patches or veths.

But if you really want to use vxlan, then maybe the loopback (lo  
 MailScanner warning: numerical links are often malicious: 
127.0.0.1/8) can be used, something like this:

 

ovs-vsctl add-br br0

ovs-vsctl add-port br0 vxlan0 -- set interface vxlan0 type=vxlan 
options:local_ip=127.1.1.1 options:remote_ip=127.2.2.2

 

ovs-vsctl add-br br1

ovs-vsctl add-port br1 vxlan1 -- set interface vxlan1 type=vxlan 
options:local_ip=127.2.2.2 options:remote_ip=127.1.1.1

 

 

From: ovs-discuss-boun...@openvswitch.org 
  
[mailto:ovs-discuss-boun...@openvswitch.org 
 ] On Behalf Of Shravan S K
Sent: 13 January 2017 10:21


To: Scott Lowe mailto:scott.l...@scottlowe.org> >
Cc: ovs-discuss@openvswitch.org  
Subject: Re: [ovs-discuss] VXLAN support in OVS 2.5.0

 

My motive is to simulate VXLAN functionality on a bigger topology using mininet.
My plan - As Mininet uses OVS bridges to simulate vswitch functionality, we can 
use ovs-vsctl to configure VXLAN functionality on the bridges. I thought let me 
try for a simple topology without using Mininet and just using OVS on a single 
host and 2 VMs. If it works, then I can make a similar configuration for a 
bigger topology using mininet. 

 

OVS on a single host and 2 VMs : vm1-br1---br2-vm2 

I am confused on how to perform the vxlan config for the above setup. 

 

If the above one works, I could try on the mininet topologies. 

For the mininet topology ( --topo=linear,2 )

h1 - s1 -- s2  h2 (h1,h2 are hosts, s1,s2 are switches - 
actually ovs bridges)

$ ovs-vsctl show 
ad172f01-511d-46fe-9022-d23de31e06e2
Bridge "s2"
Controller "ptcp:6635"
fail_mode: standalone
Port "s2-eth2"
Interface "s2-eth2"
Port "s2"
Interface "s2"
type: internal
Port "s2-eth1"
Interface "s2-eth1"
Bridge "s1"
Controller "ptcp:6634"
fail_mode: standalone
Port "s1-eth2"
Interface "s1-eth2"
Port "s1"
Interface "s1"
type: internal
Port "s1-eth1"
Interface "s1-eth1"
ovs_version: "2.5.0"

In the mininet console,

mininet>net
h1 h1-eth0:s1-eth1
h2 h2-eth0:s2-eth1
s1 lo:  s1-eth1:h1-eth0 s1-eth2:s2-eth2
s2 lo:  s2-eth1:h2-eth0 s2-eth2:s1-eth2

As the vxlan configuration part is related to OVS, I am asking in this forum, 
rather than the mininet forum. 

Thanks. 

 

 




Shravan

 

On 13 January 2017 at 11:08, Scott Lowe mailto:scott.l...@scottlowe.org> > wrote:

I would still echo Raymond's suggestion: use VirtualBox to create two "hosts" 
running OVS and connect them via a VXLAN tunnel over standard VBox networking. 
You can use network namespaces (as Justin suggested) on the VMs running OVS to 
simulate connecting to OVS since VBox doesn't support nested virtualization.

 

You can take a look at  to see if 
there is a Vagrant environment I've already created that might help you in this 
situation.


-- 

Scott

 

Sent from my mobile device


On Jan 12, 

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

[Michael Ben-Ami via discuss]

I'm in a very similar boat as Shravan. The utility for me is to be able to
test flow sets on arbitrary mininet topologies that simulate real world
topologies that may or may not use VXLAN. The root cause as I see it is
that mininet must put all OVS bridges in the same namespace. This is
probably an OVS limitation not mininet. Has been discussed a little here:
https://mail.openvswitch.org/pipermail/ovs-discuss/2015-September/038543.html

Of course you could start mininet itself in different namespaces, but that
defeats a lot of the purpose of building topologies within a mininet.

Shravan, if you find a workable solution please let me know.

Thanks,
Michael

On Fri, Jan 13, 2017 at 7:07 AM, O'Reilly, Darragh 
wrote:

>
>
> Not sure what you are trying to do. But if you just want to connect two
> bridges on the same host, then you can use patches or veths.
>
> But if you really want to use vxlan, then maybe the loopback (lo
> 127.0.0.1/8) can be used, something like this:
>
>
>
> ovs-vsctl add-br br0
>
> ovs-vsctl add-port br0 vxlan0 -- set interface vxlan0 type=vxlan
> options:local_ip=127.1.1.1 options:remote_ip=127.2.2.2
>
>
>
> ovs-vsctl add-br br1
>
> ovs-vsctl add-port br1 vxlan1 -- set interface vxlan1 type=vxlan
> options:local_ip=127.2.2.2 options:remote_ip=127.1.1.1
>
>
>
>
>
> *From:* ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-bounces@
> openvswitch.org] *On Behalf Of *Shravan S K
> *Sent:* 13 January 2017 10:21
>
> *To:* Scott Lowe 
> *Cc:* ovs-discuss@openvswitch.org
> *Subject:* Re: [ovs-discuss] VXLAN support in OVS 2.5.0
>
>
>
> My motive is to simulate VXLAN functionality on a bigger topology using
> mininet.
> My plan - As Mininet uses OVS bridges to simulate vswitch functionality,
> we can use ovs-vsctl to configure VXLAN functionality on the bridges. I
> thought let me try for a simple topology without using Mininet and just
> using OVS on a single host and 2 VMs. If it works, then I can make a
> similar configuration for a bigger topology using mininet.
>
>
>
> OVS on a single host and 2 VMs : vm1-br1---br2-vm2
>
> I am confused on how to perform the vxlan config for the above setup.
>
>
>
> If the above one works, I could try on the mininet topologies.
>
> For the mininet topology ( --topo=linear,2 )
>
> h1 - s1 -- s2  h2 (h1,h2 are hosts, s1,s2 are switches -
> actually ovs bridges)
>
> *$ ovs-vsctl show *
> ad172f01-511d-46fe-9022-d23de31e06e2
> Bridge "s2"
> Controller "ptcp:6635"
> fail_mode: standalone
> Port "s2-eth2"
> Interface "s2-eth2"
> Port "s2"
> Interface "s2"
> type: internal
> Port "s2-eth1"
> Interface "s2-eth1"
> Bridge "s1"
> Controller "ptcp:6634"
> fail_mode: standalone
> Port "s1-eth2"
> Interface "s1-eth2"
> Port "s1"
> Interface "s1"
> type: internal
> Port "s1-eth1"
> Interface "s1-eth1"
> ovs_version: "2.5.0"
>
> In the mininet console,
>
> *mininet>net*
> h1 h1-eth0:s1-eth1
> h2 h2-eth0:s2-eth1
> s1 lo:  s1-eth1:h1-eth0 s1-eth2:s2-eth2
> s2 lo:  s2-eth1:h2-eth0 s2-eth2:s1-eth2
>
> As the vxlan configuration part is related to OVS, I am asking in this
> forum, rather than the mininet forum.
>
> Thanks.
>
>
>
>
>
>
> Shravan
>
>
>
> On 13 January 2017 at 11:08, Scott Lowe  wrote:
>
> I would still echo Raymond's suggestion: use VirtualBox to create two
> "hosts" running OVS and connect them via a VXLAN tunnel over standard VBox
> networking. You can use network namespaces (as Justin suggested) on the VMs
> running OVS to simulate connecting to OVS since VBox doesn't support nested
> virtualization.
>
>
>
> You can take a look at  to
> see if there is a Vagrant environment I've already created that might help
> you in this situation.
>
>
> --
>
> Scott
>
>
>
> Sent from my mobile device
>
>
> On Jan 12, 2017, at 9:46 PM, Shravan S K  wrote:
>
> I know that. But I wanted to experiment with OVS bridges first, and then
> if it worked I wanted to re-create the config for a larger topology using
> Mininet(which uses OVS bridges(for switches) using OVS).
>
> Thanks.
>
>
> Shravan
>
>
>
> On 13 January 2017 at 08:06, Raymond Burkholder 
> wrote:
>
> Try running VirtualBox, and build two guests with shared networking.
> That will get you an appropriate simulation of computer to computer vxlan
> mechanisms.
>
>
>
> *From:* ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-bounces@
> openvswitch.org] *On Behalf Of *Shravan S K
> *Sent:* Thursday, January 12, 2017 22:34
> *To:* Scott Lowe 
> *Cc:* ovs-discuss@openvswitch.org
> *Subject:* Re: [ovs-discuss] VXLAN support in OVS 2.5.0
>
>
>
> Because of lack of hardware, I'm trying a vxlan setup on a single
> computer.
>
> On 13-Jan-2017 04:47, "Scott Lowe"  wrote:
>
> Please don't drop the list.
>
> Before we go down that path, can you help me

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

[O'Reilly, Darragh]

Not sure what you are trying to do. But if you just want to connect two bridges 
on the same host, then you can use patches or veths.
But if you really want to use vxlan, then maybe the loopback (lo 127.0.0.1/8) 
can be used, something like this:

ovs-vsctl add-br br0
ovs-vsctl add-port br0 vxlan0 -- set interface vxlan0 type=vxlan 
options:local_ip=127.1.1.1 options:remote_ip=127.2.2.2

ovs-vsctl add-br br1
ovs-vsctl add-port br1 vxlan1 -- set interface vxlan1 type=vxlan 
options:local_ip=127.2.2.2 options:remote_ip=127.1.1.1


From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Shravan S K
Sent: 13 January 2017 10:21
To: Scott Lowe 
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] VXLAN support in OVS 2.5.0

My motive is to simulate VXLAN functionality on a bigger topology using mininet.
My plan - As Mininet uses OVS bridges to simulate vswitch functionality, we can 
use ovs-vsctl to configure VXLAN functionality on the bridges. I thought let me 
try for a simple topology without using Mininet and just using OVS on a single 
host and 2 VMs. If it works, then I can make a similar configuration for a 
bigger topology using mininet.

OVS on a single host and 2 VMs : vm1-br1---br2-vm2
I am confused on how to perform the vxlan config for the above setup.

If the above one works, I could try on the mininet topologies.
For the mininet topology ( --topo=linear,2 )
h1 - s1 -- s2  h2 (h1,h2 are hosts, s1,s2 are switches - 
actually ovs bridges)
$ ovs-vsctl show
ad172f01-511d-46fe-9022-d23de31e06e2
Bridge "s2"
Controller "ptcp:6635"
fail_mode: standalone
Port "s2-eth2"
Interface "s2-eth2"
Port "s2"
Interface "s2"
type: internal
Port "s2-eth1"
Interface "s2-eth1"
Bridge "s1"
Controller "ptcp:6634"
fail_mode: standalone
Port "s1-eth2"
Interface "s1-eth2"
Port "s1"
Interface "s1"
type: internal
Port "s1-eth1"
Interface "s1-eth1"
ovs_version: "2.5.0"
In the mininet console,
mininet>net
h1 h1-eth0:s1-eth1
h2 h2-eth0:s2-eth1
s1 lo:  s1-eth1:h1-eth0 s1-eth2:s2-eth2
s2 lo:  s2-eth1:h2-eth0 s2-eth2:s1-eth2
As the vxlan configuration part is related to OVS, I am asking in this forum, 
rather than the mininet forum.
Thanks.



Shravan

On 13 January 2017 at 11:08, Scott Lowe 
mailto:scott.l...@scottlowe.org>> wrote:
I would still echo Raymond's suggestion: use VirtualBox to create two "hosts" 
running OVS and connect them via a VXLAN tunnel over standard VBox networking. 
You can use network namespaces (as Justin suggested) on the VMs running OVS to 
simulate connecting to OVS since VBox doesn't support nested virtualization.

You can take a look at  to see if 
there is a Vagrant environment I've already created that might help you in this 
situation.

--
Scott

Sent from my mobile device

On Jan 12, 2017, at 9:46 PM, Shravan S K 
mailto:sra9...@gmail.com>> wrote:
I know that. But I wanted to experiment with OVS bridges first, and then if it 
worked I wanted to re-create the config for a larger topology using 
Mininet(which uses OVS bridges(for switches) using OVS).
Thanks.

Shravan

On 13 January 2017 at 08:06, Raymond Burkholder 
mailto:r...@oneunified.net>> wrote:
Try running VirtualBox, and build two guests with shared networking.   That 
will get you an appropriate simulation of computer to computer vxlan mechanisms.

From: 
ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org]
 On Behalf Of Shravan S K
Sent: Thursday, January 12, 2017 22:34
To: Scott Lowe mailto:scott.l...@scottlowe.org>>
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] VXLAN support in OVS 2.5.0


Because of lack of hardware, I'm trying a vxlan setup on a single computer.
On 13-Jan-2017 04:47, "Scott Lowe" 
mailto:scott.l...@scottlowe.org>> wrote:
Please don't drop the list.

Before we go down that path, can you help me understand what you're
trying to achieve by building a VXLAN tunnel between two VMs on the same
host?



On 01/12/2017 10:15 AM, Shravan S K wrote:
> I am not sure how to do the config for what you said.
> Can you please explain how to configure the setup that you're suggesting ?
>
> Shravan
>
> On 12 January 2017 at 02:17, Scott Lowe 
> mailto:scott.l...@scottlowe.org>
> >> wrote:
>
> 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
> >
>  

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

[Shravan S K]

My motive is to simulate VXLAN functionality on a bigger topology using
mininet.
My plan - As Mininet uses OVS bridges to simulate vswitch functionality, we
can use ovs-vsctl to configure VXLAN functionality on the bridges. I
thought let me try for a simple topology without using Mininet and just
using OVS on a single host and 2 VMs. If it works, then I can make a
similar configuration for a bigger topology using mininet.

OVS on a single host and 2 VMs : vm1-br1---br2-vm2
I am confused on how to perform the vxlan config for the above setup.

If the above one works, I could try on the mininet topologies.
For the mininet topology ( --topo=linear,2 )
h1 - s1 -- s2  h2 (h1,h2 are hosts, s1,s2 are switches -
actually ovs bridges)

*$ ovs-vsctl show *
ad172f01-511d-46fe-9022-d23de31e06e2
Bridge "s2"
Controller "ptcp:6635"
fail_mode: standalone
Port "s2-eth2"
Interface "s2-eth2"
Port "s2"
Interface "s2"
type: internal
Port "s2-eth1"
Interface "s2-eth1"
Bridge "s1"
Controller "ptcp:6634"
fail_mode: standalone
Port "s1-eth2"
Interface "s1-eth2"
Port "s1"
Interface "s1"
type: internal
Port "s1-eth1"
Interface "s1-eth1"
ovs_version: "2.5.0"

In the mininet console,
*mininet>net*
h1 h1-eth0:s1-eth1
h2 h2-eth0:s2-eth1
s1 lo:  s1-eth1:h1-eth0 s1-eth2:s2-eth2
s2 lo:  s2-eth1:h2-eth0 s2-eth2:s1-eth2

As the vxlan configuration part is related to OVS, I am asking in this
forum, rather than the mininet forum.

Thanks.



Shravan

On 13 January 2017 at 11:08, Scott Lowe  wrote:

> I would still echo Raymond's suggestion: use VirtualBox to create two
> "hosts" running OVS and connect them via a VXLAN tunnel over standard VBox
> networking. You can use network namespaces (as Justin suggested) on the VMs
> running OVS to simulate connecting to OVS since VBox doesn't support nested
> virtualization.
>
> You can take a look at  to
> see if there is a Vagrant environment I've already created that might help
> you in this situation.
>
> --
> Scott
>
> Sent from my mobile device
>
> On Jan 12, 2017, at 9:46 PM, Shravan S K  wrote:
>
> I know that. But I wanted to experiment with OVS bridges first, and then
> if it worked I wanted to re-create the config for a larger topology using
> Mininet(which uses OVS bridges(for switches) using OVS).
>
> Thanks.
>
> Shravan
>
> On 13 January 2017 at 08:06, Raymond Burkholder 
> wrote:
>
>> Try running VirtualBox, and build two guests with shared networking.
>> That will get you an appropriate simulation of computer to computer vxlan
>> mechanisms.
>>
>>
>>
>> *From:* ovs-discuss-boun...@openvswitch.org [mailto:
>> ovs-discuss-boun...@openvswitch.org] *On Behalf Of *Shravan S K
>> *Sent:* Thursday, January 12, 2017 22:34
>> *To:* Scott Lowe 
>> *Cc:* ovs-discuss@openvswitch.org
>> *Subject:* Re: [ovs-discuss] VXLAN support in OVS 2.5.0
>>
>>
>>
>> Because of lack of hardware, I'm trying a vxlan setup on a single
>> computer.
>>
>> On 13-Jan-2017 04:47, "Scott Lowe"  wrote:
>>
>> Please don't drop the list.
>>
>> Before we go down that path, can you help me understand what you're
>> trying to achieve by building a VXLAN tunnel between two VMs on the same
>> host?
>>
>>
>>
>> On 01/12/2017 10:15 AM, Shravan S K wrote:
>> > I am not sure how to do the config for what you said.
>> > Can you please explain how to configure the setup that you're
>> suggesting ?
>> >
>> > Shravan
>> >
>> > On 12 January 2017 at 02:17, Scott Lowe > > > wrote:
>> >
>> > 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 >