y errors that it reports.)
>
> My guess is that developing features for both implementations won't be
> much of a burden, beyond the burden of remembering to do it, because it
> should be easy to write DDlog for common features, not really harder
> (maybe easier) than writing the C.
I think this is implied based on the description of how ovn-northd
would work, but do you expect to make a completely seamless drop-in
replacement (aside from build-time and run-time dependencies? All
parameters would be identical, no new configuration, and requiring
zero change to integrations project like ovn-kubernetes or the
OpenStack OVN integration?
In terms of "proven in practice", OVN is at a stage where it's being
used in production, so ideally we set a very high bar for a switchover
like this. It sounds like you're planning for that by enabling
implementations to work in parallel instead of forcing a hard cutover
early. I would hope for something like multiple releases of a new
implementation in experimental state, allowing plenty of time for
testing in realistic, larger scale environments, and relying on
reports of significant successes before a cutover.
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
packet is redundantly
> processed in logical switch's egress pipeline on both local and remote
> hypervisors.
Have you identified a problem caused by this behavior?
Thanks,
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On Fri, Apr 13, 2018 at 9:01 PM, Russell Bryant <russ...@ovn.org> wrote:
> On Fri, Apr 13, 2018 at 5:27 PM, Ben Pfaff <b...@ovn.org> wrote:
>> On Wed, Apr 11, 2018 at 07:44:25PM +0530, Anil Venkata wrote:
>>> vm created on a vlan tenant network is using
compute nodes like
today.
3) Figure out a way for OVN to do this redirect to the gateway host
over a VLAN network. I suspect this isn't trivial and honestly
haven't spent the time to figure out what it would take, but this does
seem like the ideal behavior.
--
Russell Bryant
___
is the main benefit of putting it in 2.9 to me -- it makes it
easier to work on integration.
If it's in 2.9, OpenStack (as one example) can do integration work and
merge it as an optional feature. If it's deferred to 2.10, that work
can begin, but the patches can't be merged until th
rthd, and one of the machines running ovn-controller and ovs-vswitchd.
> Thanks,
> —Kevin
>
>
> Hi Kevin,
>
> In short, I agree with Ethan's assessment that the hmap numbers appear
> large. The ACLs, combined with ovn-controller's algorithms, are causing
> that. The
I support adding some OVN testing, especially scale testing. There is a
>> dormant ovn scale testing project that might be a place to start (I've
>> never looked at it personally):
>> https://github.com/openvswitch/ovn-scale-test
>>
>
>
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
n. You can
use those namespaces like you did before.
The other option would be to manually create a Neutron port, and then
manually create an interface in a namespace for that Neutron port. I
can send instructions if needed ...
--
Russell Bryant
___
oadmap? Somebody working on it? Is there a ticket that we
> can track?
Nobody is currently working on it.
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
rue"}
> Port_Binding "6fe3cab5-5f84-44c8-90f2-64c21b489c62"
> Chassis "4180095d-1528-4063-b135-5dc0abc4ecee"
> hostname: "compute2"
> Encap geneve
> ip: "192.168.122.207"
> options: {csum="true"}
>
You should see "redirect-chassis=" in the options column.
That identifies the chassis hosting the gateway router.
> ~~~
>
>
>
> Thanks & Regards,
> Vikrant Aggarwal
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
gt; neutron net-create NET-EXT --provider:network_type flat
> --provider:physical_network br-ex --router:external=true --shared
>
> Once i corrected option '--provider' option with
> '--provider:physical_network provider', its working fine on compute node.
>
> -Jai
>
>
> ___
r-ex, it
> works fine and no error is thrown.
>
>
> Is this a bug or the field before ":" in this external-id represents bridge
> name.
The error message indicates that a "localnet" was created with a
"network_name" of "br-ex". The "network
tion is not tested and will probably break
eventually. I recommend using Ocata Neutron as well.
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
able to specify only a subset of hosts that should be used
as gateways.
2) We need some HA capabilities to handle when a host handling a gateway
goes down.
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
the corresponding CI jobs. My suggestion would be to
try to do what you need using OVN's L3 support.
[1] https://review.openstack.org/#/c/346646/
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
chain needs in order to create the end to end rules. That includes
> 'chain_uuid',
> 'last_hop_port' at a minimum. Other than using 'external_ids', I cannot
> see where else
> to provide them. Any better ideas?
>
Well defined options that OVN will interpret usually go into a column
called "options", so I would add that instead of using external_ids.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
531c268bddf6b4#diff-
> 2c35162acf6ad144624954fdc4c3d9f4R2505
>
> [4]: http://sched.co/8aZE
>
>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
ing it to south DB external-ids?
OVN doesn't do gateway scheduling. It relies on something external to do
that. Are you talking about this in the context of OpenStack? If so, I do
remember talking about this but it's not done. It seems reasonable
though. Our scheduling right now is just a basic s
s much more of the feature set.
[1] https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
ity which is how I do currently with
> devstack. I would like to know if either ovn or neutron will have
> contentions if port-security disabled at neutron server.
>
You can disable it. There's no problem with that. It will just disable
related features: L2 and L3 port security and securi
ught through details yet.
The other option is if we can change ovn-controller to where it is only a
read-only client of the southbound database. In that case, perhaps
ovsdb-server wouldn't need to know identity, and instead could have a port
open that only accepts connections with read-only access to the database.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
ke it
> > work without warnings.
> >
>
> Thanks for the pointers. I will give it a try.
>
Hi, Numan. I'm using Fedora 24 and I don't see these warnings. I'm not
sure what's different.
$ gcc --version
gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
--
Russell Bryant
___
in the ovn-architecture
man page may be of interest to you.
There is also the capability to have software L2 or L3 gateways on a server
running ovn-controller.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
l have to solve this in ovsdb.
>>
>> This is a very good point. May be it is another +1 for #2? Or you have
> some other approach in mind?
>
Yes, +1 for #2.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
in ovn/TODO using etcd capabilities.
If we put ovsdb in front of it, we still have to solve this in ovsdb.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
aekho Nam.
>>
>>
>>
>> ___________
>> discuss mailing list
>> discuss@openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
>>
>>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
e guidance about the OVN usage with VMs please?
>
I don't know of any docs that show this in detail. The closest I'm aware
of is documentation on the OpenStack integration, which sets up VMs with
OVN.
http://docs.openstack.org/developer/networking-ovn/testing.html
http://docs.openstack.org/developer/networking-ovn/refarch.html
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
it outside of sandbox.
>
> Please let me know.
>
There are a couple of options that are document. One is to use the OVN
integration for OpenStack:
http://docs.openstack.org/developer/networking-ovn/testing.html
There is also Docker integration:
https://github.com/openvswitch
ports. Each results in a transaction from both ovn-northd
and ovn-controller right now. ovn-northd updates logical flows and creates
a Port_Binding row (at least). ovn-controller updates the Port_Binding row
to bind the port to a chassis.
--
Russell Bryant
Any etcd client
> transaction
> will always bring this version number from even to an odd number.
>
> No further transaction can be issued until "db/version"'s value become
> even.
>
> * A dedicated client enforces referential integrity
>
> There is a dedicated etc
n/env3/setup.sh#L43
>
>
Yes, ovn-controller normally does this automatically. The case where
ovn-sbctl does it is because we are simulating a fake other hypervisor and
manually do a step that ovn-controller on that hypervisor would have done.
Russell
--
Russell Bryant
_
ace won't change (will remain OVSDB), or that we can
provide a reasonable automated migration path from OVSDB to etcd. On the
surface, providing a migration seems reasonable enough.
Thanks,
--
Russell Bryant
--
Russell Bryant
___
discuss mailing lis
existing schemas and some example transactions
would be mapped to etcd? My gut reaction is that this is probably the
right direction unless we can identify blockers.
If we get to the point of a migration, I'd be willing to join an effort of
locking a small group in a room to do the migration as quick as p
a reasonable way? Can you elaborate on the
> architectural limitations? At the moment, the OpenStack implementation of
> OVN doesn't use DPDK.
>
One minor point here: The OpenStack driver for OVN can optionally make use
of OVS-DPDK.
--
Russell Bryant
__
ant to centralize all VNF’s for management/admin or specific hardware
>allocation reasons, though “network tromboning" would be an issue. I think
>it could be addressed with some additional parameters but I have not dug
>into it deeply yet.
e quickly on a first
iteration based on the work I had done before.
--
Russell Bryant
On Wed, Mar 30, 2016 at 1:13 PM, John McDowall <
jmcdow...@paloaltonetworks.com> wrote:
> Russell,
>
> Let me try and answer your questions:
>
>1. I looked at the networking-sfc API (
ome reasonable
limitations we can put in place to get a first version out?
Do you have interest in this functionality in OVN outside of OpenStack?
> Also what other use cases should we consider?
>
There seems to be some industry interest in NSH based SFC. It's not
supported by OVS yet, but it should be on our radar. I suppose it just
comes back to eventually wanting to support SFC-aware VNFs that expect some
metadata.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
o
avoid that as best we can. The networking-sfc project is the closest thing
to what we need. I'd like to see if we can use that, or help evolve it to
something that would work for OVN.
Hopefully that's helpful. I do still think this is something we should
work out for OVN, so I'd be happy to
o
avoid that as best we can. The networking-sfc project is the closest thing
to what we need. I'd like to see if we can use that, or help evolve it to
something that would work for OVN.
Hopefully that's helpful. I do still think this is something we should
work out for OVN, so I'd be happy to
or OVN that has this as a
requirement, so I think we'll need to create one. I have no idea what I'm
doing, but I'll see if I can get something going. :-)
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
Is anyone aware of an Ubuntu PPA based on the master branch of OVS?
Someone is interested in using one for OVN testing,
Thanks,
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
I tested it successfully with 3.13.0-83-generic on Ubuntu trusty. I also
acked the patch.
Thanks!
--
Russell Bryant
On Mon, Mar 21, 2016 at 12:46 PM, Jesse Gross <je...@kernel.org> wrote:
> I sent out a patch that I believe should fix this:
> http://openvswitch.org/pipermail/de
I believe this is caused by backports done for this bug:
https://bugs.launchpad.net/nova/+bug/1463911
--
Russell Bryant
On Mon, Mar 21, 2016 at 5:16 AM, Russell Bryant <russ...@ovn.org> wrote:
> FWIW, this issue has broken OpenStack CI with OVN. It was also reported
> he
> #ifndef HAVE_NF_IPV6_OPS_FRAGMENT
> > #ifdef OVS_FRAGMENT_BACKPORT
> > int rpl_ip6_fragment(struct sock *sk, struct sk_buff *skb,
> >int (*output)(OVS_VPORT_OUTPUT_PARAMS));
> > #else
> > static inline int rpl_ip6_fragment(struct sock *sk, struct sk_buff *skb,
> >
o do switching (or you
> can tell it "unknown").
I've seen this before when helping debug setups. It would be nice to help
catch this somehow and flag that configuration is incomplete, but I haven't
come up with any specific ideas.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
On Friday, March 4, 2016, Vivek Gupta <vive...@hcl.com> wrote:
> Do we have DPDK integrated OVS branch in Git?
>
There's no special branch for it. It's in the main branches (master and
release branches).
--
Russell
--
Russell Bryant
___
ething
> I'd like to see if we can improve...
>
> Thanks for sharing the data. The master branch supports "monitor2" and
> "update2" JSONRPC messages. Do you know if they are being used?
That's the default unless you explicitly turn it off, right?
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
p with the request load? or
ovsdb-server? or?
Also, are you running multiple Neutron API workers?
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
t's best if we focus on the bottlenecks.
My understanding based on the IBM scale testing so far was that it
appeared ovn-controller was the first bottleneck hit. We also dug into
it and determined it was logical flow processing taking the bulk of the
time. I was under the impression th
twork with 100 VMs on it can max out
> a 10 Gbps interface adapter with a 100 mbps broadcast/multicast stream.
>
> 1. http://openvswitch.org/pipermail/discuss/2015-December/019632.html
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
ow_aggregate field, stats_dict)
> File "/usr/bin/ovs-dpctl-top", line 250, in element_ipv4_get
> element_show = fmt % (field_type, element["src"], element["dst"])
> KeyError: 'src'|||
>
> |ovs-dpctl-top --version 2.4.0|
Can you share the output of 'ovs-d
t would be good to post
this to the dev list, as well.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
e=unix:"$sandbox"/db.sock
ovs-vsctl set open . external-ids:ovn-encap-type=geneve
ovs-vsctl set open . external-ids:ovn-encap-ip=127.0.0.1
You need to set those values as appropriate.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
p was modeled largely on
ovn-controller and some common code was split out. In particular, see the
ovsdb_idl_loop_* functions. It seems like we should refactor the main loop
ovn-northd to use that.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
capture the details. It may still be a few weeks before I can get back
to it, though.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
in/out of a VNF.
If NSH gets into OVS, we can use it for SFC as well. It probably makes
sense to add NSH as a generic encap for OVN. We could also use it only
to pass metadata in/out of a VNF if we wanted.
In the meantime, we can be working on how to model this properly in
OVN_Northbound, as we
On 11/03/2015 04:01 PM, Ben Pfaff wrote:
> On Tue, Nov 03, 2015 at 03:45:45PM -0500, Russell Bryant wrote:
>> In the meantime, we can be working on how to model this properly in
>> OVN_Northbound, as well as trying to work out a reasonable
>> implementation based on Geneve
, but if possible it would
be awesome if it got shifted by 1 or 2 days so that it didn't require
traveling over the weekend.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
/datapath.c:2268:10: error: macro __DATE__
might prevent reproducible builds [-Werror=date-time]
VERSION);
^
Add the following to your 'make' command:
$ make EXTRA_CFLAGS=-Wno-error=date-time
--
Russell Bryant
___
discuss mailing list
discuss
61 matches
Mail list logo
