Re: [ovs-discuss] RFC: incremental computation for OVN with DDlog
piece is OVS client library code to pass the JSON to and > from the actual database server. > > > >* We need to translate the C flow generation code in ovn-northd into > > > DDlog's domain specific language. There are some tricky parts to > > > this but we expect the bulk of it to be straightforward and probably > > > easier to read in DDlog than in C. We've started with the tricky > > > parts, which you can find at > > > > > > https://github.com/ryzhyk/differential-datalog/blob/northd/test/ovn/ovn_northd.dl > > > Please don't take the code there as illustrative of what one would > > > typically see for flow generation, because as I said, these are the > > > hard parts. > > > > Thanks for the code examples. Seeing sample DDlog is very nice, even if it's > > not necessarily illustrative of what the final product will be. > > > > For those of us doing work right now to add new features to OVN, how should > > we approach the conversion to DDlog? As an example, I have some multicast > > work in progress that will add some new northbound data. It also introduces > > ovn-northd changes to generate logical flows and southbound data. > > > > My assumption is that I should focus 100% on the C implementation for now. > > When should I consider adding the analogous DDlog changes? > > The DDlog implementation has a lot of catching up to do. I think that > other OVN efforts should focus on the C implementation. Applying recent > changes to DDlog should not add much to the DDlog work. > > > Is there some sort of plan for how to keep DDlog up to date in the face of > > new C development? For instance, would we implement a policy that states > > that C changes will not be accepted without equivalent DDlog changes? For > > this initial conversion, would we declare a C feature freeze date that > > states that no new ovn-northd C changes may be added after that date in > > order to give a stable feature set for DDlog conversion? > > We need to have some kind of policy once the DDlog implementation is > merged into mainline OVS. I don't think it's necessary to freeze the C > implementation yet; maybe not at all, since it doesn't really move that > quickly either. > > > >* The OVN build system will need some changes: > > > > > > - The DDlog compiler, which translates .dl files into Rust, is > > > written in Haskell, so Haskell becomes an OVN build requirement > > > but not a runtime requirement. (If that's a problem, then we can > > > arrange to distribute the Rust output as well as the .dl input, > > > for situations where Haskell is not available.) > > > > > > - OVN will require a Rust compiler at build time. Whatever > > > libraries Rust needs becomes runtime requirements. > > > > > > - ovn-northd (and eventually ovn-controller) will link against the > > > Rust object files and call into DDlog through its external API. > > > > > >* Initially, we plan to make DDlog optional. If Haskell and Rust are > > > available at configure and build time, ovn-northd will build in > > > support for DDlog. At ovn-northd runtime, command-line options will > > > control which implementation is used; we hope to make it possible to > > > run both in parallel to check for differences in behavior. After > > > the DDlog implementation is proven in practice, we hope to delete > > > the C implementation entirely. > > > > It's a bit of a loaded question, but by what measure do we consider the > > DDlog implementation to be proven in practice? > > > > Until the C implementation is erased, should we expect to develop features > > for both C and DDlog? Or should we expect to target new features only for > > DDlog? > > I expect that "proven in practice" is subjective. One baseline would be > that the DDlog implementation passes all the existing OVN unit tests. > Beyond that, I think that we would have to convince real users to try > the DDlog implementation and report problems. (If we get the "run both > implementations in parallel" working well, then we could alternatively > ask them to try that and pass along any 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
Re: [ovs-discuss] OVN - VLAN packet duplicate processing on egress pipeline
On Mon, Jul 23, 2018 at 8:06 AM Anil Venkata wrote: > > Packets destined for VLAN remote logical ports are sent out through physical > table 65 rather than physical table 32 (Geneve remote logical ports are sent > through table 32). I found below description in ovn architecture > documentation. > > http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html > > A special case is that when a localnet port exists on the > datapath, remote port is connected by switching to the local‐ > net port. In this case, instead of adding a flow in table 32 > to reach the remote port, a flow is added in table 33 to > switch the logical outport to the localnet port, and resubmit > to table 33 as if it were unicasted to a logical port on the > local hypervisor. > > > Any reason for this decision. Because of this, 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
Re: [ovs-discuss] OVN vm on vlan network using geneve tunnel for external traffic
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 geneve tunnel(between compute >>> and gateway nodes) to reach external network. Because of this, we need to >>> consider tunnelling overhead while assigning MTU for vlan network. Can we >>> improve OVN to avoid tunnelling in this case. >> >> When OVN tunnels packets, the tunnel metadata includes information on >> the logical network, logical input port, and logical output port. The >> logical input port is only used for egress ACLs, so it could be omitted >> if egress ACLs are constrained not to match on the logical input port. >> The logical network and logical output port are still needed, though, so >> to encode that in a VLAN they would have to add up to 12 bits or less. >> That's pretty constraining. Do you have some idea for how to do it? > > I don't think ACLs are a factor here because it's actually the logical > router pipeline forwarded the packet over a tunnel. The only logical > switches involved are VLAN networks (a switch with a localnet port). > > The unexpected behavior here is that despite using all VLAN networks, > a Geneve tunnel is used when the packet is sent to the L3 gateway node > that's doing SNAT. Note that the type of router configured here is > the hybrid-type, where routing is fully distributed in all cases > except when NAT is required, then it gets redirected to a central > point. That redirect is what we're seeing here. > > I've thought of two ways out of this: > > 1) In this scenario, if you really don't want any tunneling in use, > configure a fully centralized router instead. The downside is that > East-West routing will be centralized, as well. > > 2) Use two routers. ls1 (VLAN) with all ports for VMs <-> distributed > east-west router <-> ls2 (VLAN) used just to interconnect the routers > <-> centralized router for SNAT. The downside here is that you still > lose the ability to bind floating IPs directly to 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 After an internal conversation on this topic, I wrote the following doc to summarize what was observed and to capture ideas for next steps: https://docs.google.com/document/d/1JecGIXPH0RAqfGvD0nmtBdEU1zflHACp8WSRnKCFSgg/edit?usp=sharing -- Russell Bryant ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN vm on vlan network using geneve tunnel for external traffic
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 geneve tunnel(between compute >> and gateway nodes) to reach external network. Because of this, we need to >> consider tunnelling overhead while assigning MTU for vlan network. Can we >> improve OVN to avoid tunnelling in this case. > > When OVN tunnels packets, the tunnel metadata includes information on > the logical network, logical input port, and logical output port. The > logical input port is only used for egress ACLs, so it could be omitted > if egress ACLs are constrained not to match on the logical input port. > The logical network and logical output port are still needed, though, so > to encode that in a VLAN they would have to add up to 12 bits or less. > That's pretty constraining. Do you have some idea for how to do it? I don't think ACLs are a factor here because it's actually the logical router pipeline forwarded the packet over a tunnel. The only logical switches involved are VLAN networks (a switch with a localnet port). The unexpected behavior here is that despite using all VLAN networks, a Geneve tunnel is used when the packet is sent to the L3 gateway node that's doing SNAT. Note that the type of router configured here is the hybrid-type, where routing is fully distributed in all cases except when NAT is required, then it gets redirected to a central point. That redirect is what we're seeing here. I've thought of two ways out of this: 1) In this scenario, if you really don't want any tunneling in use, configure a fully centralized router instead. The downside is that East-West routing will be centralized, as well. 2) Use two routers. ls1 (VLAN) with all ports for VMs <-> distributed east-west router <-> ls2 (VLAN) used just to interconnect the routers <-> centralized router for SNAT. The downside here is that you still lose the ability to bind floating IPs directly to 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 ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] clustered OVSDB in 2.9 or 2.10?
On Mon, Jan 15, 2018 at 2:30 AM, Numan Siddique <nusid...@redhat.com> wrote: > > > On Fri, Jan 12, 2018 at 1:28 AM, Ben Pfaff <b...@ovn.org> wrote: >> >> I posted the patches to add clustering support to OVSDB at the end of >> last year so that it was technically qualified to make it into OVS 2.9. >> At least in OVS 2.9, it will be marked "experimental", since it's a >> major change that might need work to be suitable for production (we >> simply don't know yet). Since it's a huge change, review is naturally >> taking a while. >> >> It occurred to me that it might make more sense to get this into master >> just after we branch for 2.9. Then it would be basically the first >> feature in 2.10. That would give us the whole 2.10 release cycle to get >> it from experimental to something production quality, and we could in >> theory release 2.10 with a solid clustered OVSDB. Instead of >> experimental in 2.9 and then production in 2.10, we'd just have >> production in 2.10. That might also give us some opportunity to make >> breaking changes within the 2.10 cycle that users who were experimenting >> with 2.9 might be reluctant to accept as part of an upgrade. >> >> Does anyone have thoughts on which is the preferred path? > > > Hi Ben, > > I see one advantage for OpenStack Tripleo + OVN integration in having this > feature > supported as expiremental in OVS 2.9. Once we have OVS 2.9 availalbe in RDO > packages > we could work on integrating this feature (as optional) during OVN > deployments. The scope of > this work would be to start OVN db services with clustering enabled and > configuring it. > The next OpenStack release is Queens and is under development, but we are > already late for new > features so it is fine. The release after Queens is Rocky and it will be > easier to integrate > clustered ovsdb feature with Rocky release if we have it in OVS 2.9. This 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 the feature is in a release. It's also a bit more difficult to test it in integrated CI until it's in a release. It's also understandable if 2.9 turns out to be too aggressive. -- Russell Bryant ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] ovn-controller consuming lots of CPU
t; 56 seconds (most recently, 3 seconds ago) due to excessive rate > 2017-12-12T20:14:52Z|11896|netdev_linux|DBG|unknown qdisc "mq" > 2017-12-12T20:14:54Z|11897|hmap|DBG|Dropped 15511 log messages in last 6 > seconds (most recently, 0 seconds ago) due to excessive rate > 2017-12-12T20:14:54Z|11898|hmap|DBG|ovn/lib/expr.c:2644: 6 nodes in bucket > (128 nodes, 64 buckets) > 2017-12-12T20:14:54Z|11899|timeval|WARN|Unreasonably long 1831ms poll > interval (1828ms user, 4ms system) > 2017-12-12T20:14:54Z|11900|timeval|WARN|context switches: 0 voluntary, 12 > involuntary > The log messages show up continuously. The logs appear even when the network > isn’t being used. > I poked around with Ethan Jackson and he noted that the hmap counters seem > unusually high: > root@ip-172-31-11-193:/# ovs-appctl -t ovn-controller coverage/show > Event coverage, avg rate over last: 5 seconds, last minute, last hour, > hash=d6ee5804: > hmap_pathological2323.6/sec 2662.467/sec 2514.0069/sec total: > 9407536 > hmap_expand 3596.8/sec 4121.283/sec 3890.8833/sec total: > 14604479 > txn_unchanged 0.8/sec 0.917/sec0.8658/sec total: > 5659 > txn_incomplete 0.0/sec 0.000/sec0.0008/sec total: > 33 > txn_success0.0/sec 0.000/sec0.0006/sec total: > 24 > poll_create_node 2.4/sec 2.750/sec2.5986/sec total: > 18218 > poll_zero_timeout 0.0/sec 0.000/sec0.0100/sec total: > 71 > rconn_queued 0.0/sec 0.050/sec0.0531/sec total: > 252570 > rconn_sent 0.0/sec 0.050/sec0.0531/sec total: > 252570 > seq_change 1.2/sec 1.383/sec1.2992/sec total: > 8500 > pstream_open 0.0/sec 0.000/sec0./sec total: > 1 > stream_open0.0/sec 0.000/sec0./sec total: > 6 > unixctl_received 0.0/sec 0.000/sec0.0019/sec total: > 7 > unixctl_replied0.0/sec 0.000/sec0.0019/sec total: > 7 > util_xalloc 2731550.2/sec 3129900.483/sec 569276.5414/sec > total: 11057381035 > vconn_open 0.0/sec 0.000/sec0./sec total: > 4 > vconn_received 0.0/sec 0.050/sec0.0444/sec total: > 201 > vconn_sent 0.0/sec 0.000/sec0.0144/sec total: > 253535 > netdev_get_ifindex 0.4/sec 0.467/sec0.4328/sec total: > 2822 > netlink_received 0.4/sec 0.467/sec0.4328/sec total: > 2822 > netlink_sent 0.4/sec 0.467/sec0.4328/sec total: > 2822 > cmap_expand0.0/sec 0.000/sec0./sec total: > 2 > 47 events never hit > I’ve also attached the output of ovs-bugtool run from the machine running > ovn-northd, 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 ACLs result in ~25 openflow flows being generated. > ovn-controller re-creates this flow table from scratch each time it runs its > main loop. > > These are unsolved problems as yet in ovn-controller. The two high-level > thoughts on the matter are: > 1) See if we can reduce the number of generated flows when ACLs are used. > 2) See if we can perform incremental changes on the flow table rather than > re-creating it from scratch every time. > > There are two commits that may be of interest to you. > > * As Miguel mentioned in his response, Russell Bryant submitted a change [1] > within the past couple of months to help towards (1) a bit. The idea was > that if we can detect that a flow will never be needed on a specific > machine, then don't generate it. It's not going to cover everything, but it > could potentially help you. That change is present in 2.7.3 and 2.8.1 > > * A change [2] by Han Zhou fixed an issue where we were generating the flow > table and then just throwing it away since vswitchd was not ready for us to > submit a new flow table to it. This change is present in 2.7.3 and 2.8.0. > > These two commits aren't silver bullets but if you're running a version of > OVS that does not have these commits in them already, you may see some > improvement with an upgrade. > > Mark > > [1] > https://mail.openvswitch.org/pipermail/ovs-dev/2017-September/338847.html > [2] https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/331286.html > > > > ___ > 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
Re: [ovs-discuss] Idea of an ovn native "rally"
On Fri, Dec 1, 2017 at 4:35 AM, Miguel Angel Ajo Pelayo <majop...@redhat.com > wrote: > Oh, thank you Ben, > > That's fantastic, I didn't know that was based on rally. > > I have to give it a try, and sync with mr Mestery. > Russell, were you involved in this? > Not involved, but aware of it. It helps simulate larger scale by running many instances of OVN on a single host using ovs-sandbox (or at least a similar technique). I've added Han Zhou and Lei Huang, where the project originally came from. > > Best regards, > Miguel Ángel. > > > > On Tue, Nov 28, 2017 at 7:39 PM, Ben Pfaff <b...@ovn.org> wrote: > >> On Thu, Nov 23, 2017 at 12:01:33PM +0100, Miguel Angel Ajo Pelayo wrote: >> > Today during coffee I was discussing with Jakub the idea of having >> > some sort of "rally" [1] [2] like project to measure the native reponse >> > of OVN at scale, measuring things like: >> > >> > * NB object creation to SB update >> > * Tap creation to SB port binding, and to connectivity. >> > * dnat NAT association to dnat connectivity >> > >> > * any other ideas? >> > >> > >> > This project has been specially helpful (in OpenStack) to detect race >> > conditions and bottlenecks. But I'm afraid that the OpenStack overhead >> > hide the real OVN numbers. >> >> 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
Re: [ovs-discuss] [ovn] Chassis Table or MAC_Binding Table in ovn-sb have aging?
On Mon, Sep 25, 2017 at 10:10 AM, Guoshuai Li <l...@dtdream.com> wrote: > Hi All > > > When the chassis node power off, the south of the database to the Chassis > table also exists. > > For example, the gateway node power off, but the chassis information still > exists, the traffic continues to forward the package to the chassis. If you turn on gateway HA, the traffic should move to another host. > When an external IP address is destroyed, MAC_Binding also has this IP. > > For example, the MAC address of the device of the external gateway changes > (changed one). If there is no external ARP packet, MAC_Binding will not be > updated. There is no expiration of MAC_Binding entries. This needs to be improved. > > > Is there a good way to solve this problem? > > please help > > Thanks > > ___ > 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
Re: [ovs-discuss] Troubleshooting network issues with ovn without network namespaces
On Fri, Sep 15, 2017 at 12:45 AM, Vikrant Aggarwal <ervikran...@gmail.com> wrote: > Hi Folks, > > With ovs as mechanism driver in neutron, I used network namespaces often to > troubleshoot the network related issue especially with instances which are > not having floating ip attached to them. It's easy to take ssh session to > instances without floating ip from network namespace and then take the > tcpdump at various hops to troubleshoot the issue. > > With ovn, hops are reduced as all decisions are made using openflows but > it's difficult to troubleshoot the issue. > > Do we have any mechanism to take the ssh session to instance with only > private ip in case of ovn and take tcpdump on logical switches and ports? If you're using the latest Neutron integration (networking-ovn), we now create namespaces for OpenStack metadata API integration. 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 ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Tenant multicast traffic on OpenStack with OVN
On Fri, Sep 8, 2017 at 10:09 AM, Tom Verdaat <t...@server.biz> wrote: > Hi Numan, > > Good to know. So OVN would not fix this automatically. At least, given the > info in Darragh's gist not when used in combination with GRE/VxLAN/Geneve. > > Is this on the roadmap? 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
Re: [ovs-discuss] [ovs-ovn 2.7] How to find the compute node hosting l3 gateway router
On Thu, Sep 14, 2017 at 11:26 PM, Vikrant Aggarwal
<ervikran...@gmail.com> wrote:
> Thanks Russell.
>
> Command has given me the compute2 chassis UUID, while checking "ovn-sbctl
> show" I found that lrp port is associated with compute2. May be we can
> directly issue "ovn-sbctl show" to see with which chassis lrp port is
> associated, would this be a right approach?
Yes, that should work too. :-)
>
> [root@controller ~(keystone_admin)]# ovn-nbctl list Logical_Router_Port
> lrp-b95e9ae7-5c91-4037-8d2c-660d4af00974
> _uuid : 947dc0fb-cfe6-4737-aa27-9fb38b7c7ac9
> enabled : []
> external_ids: {}
> mac : "fa:16:3e:52:20:7c"
> name: "lrp-b95e9ae7-5c91-4037-8d2c-660d4af00974"
> networks: ["192.168.122.50/24"]
> options :
> {redirect-chassis="4180095d-1528-4063-b135-5dc0abc4ecee"}
> peer: []
>
> [root@controller ~(keystone_admin)]# ovn-sbctl show
> Chassis "07e20ac2-4f66-41d4-b8c6-a5b6ae80921b"
> hostname: controller
> Encap geneve
> ip: "192.168.122.39"
> options: {csum="true"}
> Chassis "080677db-48d9-49ad-9ee4-e02eeb3da5c2"
> hostname: "compute1"
> Encap geneve
> ip: "192.168.122.15"
> options: {csum="true"}
> 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"}
> Port_Binding "4c72cee2-35b7-4bcd-8c77-135a22d16df1"
> Port_Binding "cr-lrp-b95e9ae7-5c91-4037-8d2c-660d4af00974"
>
>
> Thanks & Regards,
> Vikrant Aggarwal
>
>
>
> On Fri, Sep 15, 2017 at 3:20 AM, Russell Bryant <russ...@ovn.org> wrote:
>>
>> On Fri, Sep 8, 2017 at 8:40 AM, Vikrant Aggarwal <ervikran...@gmail.com>
>> wrote:
>> > Hi Team,
>> >
>> > I have done the installation of packstack pike using ovn as mechanism
>> > driver
>> > on centos. I have one controller and two compute nodes.
>> >
>> > - Created one tenant geneve based network (added as port to router) and
>> > a
>> > flat external network (set as gateway for router).
>> >
>> > ~~~
>> > [root@controller ~(keystone_admin)]# rpm -qa | awk '/openvswitch-ovn/
>> > {print
>> > $1}'
>> > openvswitch-ovn-common-2.7.2-3.1fc27.el7.x86_64
>> > openvswitch-ovn-host-2.7.2-3.1fc27.el7.x86_64
>> > openvswitch-ovn-central-2.7.2-3.1fc27.el7.x86_64
>> > ~~~
>> >
>> > I am trying to find a compute node on which my gateway router is hosted
>> > and
>> > also the command to check the health of distributed logical routers.
>> >
>> > It seems like that "lrp-get-gateway-chassis" command is not present in
>> > the
>> > version which I am using.
>> >
>> > ~~~
>> > [root@controller ~]# ovn-nbctl lrp-get-gateway-chassis
>> > ovn-nbctl: unknown command 'lrp-get-gateway-chassis'; use --help for
>> > help
>> >
>> > [root@controller ~]# ovn-nbctl --help | grep -i gateway
>> >
>> > ~~~
>> >
>> > Output of ovn-nbctl show.
>> >
>> > ~~~
>> >
>> > [root@controller ~(keystone_admin)]# ovn-nbctl show
>> > switch 0d413d9c-7f23-4ace-9a8a-29817b3b33b5
>> > (neutron-89113f8b-bc01-46b1-84fb-edd5d606879c)
>> > port 6fe3cab5-5f84-44c8-90f2-64c21b489c62
>> > addresses: ["fa:16:3e:fa:d6:d3 10.10.10.9"]
>> > port 397c019e-9bc3-49d3-ac4c-4aeeb1b3ba3e
>> > addresses: ["router"]
>> > port 4c72cee2-35b7-4bcd-8c77-135a22d16df1
>> > addresses: ["fa:16:3e:55:3f:be 10.10.10.4"]
>> > switch 1ec08997-0899-40d1-9b74-0a25ef476c00
>> > (neutron-e411bbe8-e169-4268-b2bf-d5959d9d7260)
>> > port provnet-e411bbe8-e169-4268-b2bf-d5959d9d7260
>> > addresses: ["unknown"]
>> > port b95e9ae7-5c91-4037-8d2c-660d4af00974
>> > addresses: ["router"]
>> > router 7418a4e7-abff-4af7-85f5-6eea2ede9bea
>> > (neutron-67dc2e78-e109-4dac-acce-b71b2c944dc1)
>> > port lrp-b95e9ae7-5c91-4037-8d2c-660d4af00974
>> > mac: "fa:16:3e:52:20:7c"
>> > networks: ["192.168.122.50/24"]
>> > port lrp-397c019e-9bc3-49d3-ac4c-4aeeb1b3ba3e
>> > mac: "fa:16:3e:87:28:40"
>> > networks: ["10.10.10.1/24"]
>>
>> Try running:
>>
>> # ovn-nbctl list Logical_Router_Port
>> lrp-397c019e-9bc3-49d3-ac4c-4aeeb1b3ba3e
>>
>> (or the other logical router port, I'm not sure which is the right one)
>>
>> 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
>
>
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-ovn 2.7] How to find the compute node hosting l3 gateway router
On Fri, Sep 8, 2017 at 8:40 AM, Vikrant Aggarwal <ervikran...@gmail.com> wrote:
> Hi Team,
>
> I have done the installation of packstack pike using ovn as mechanism driver
> on centos. I have one controller and two compute nodes.
>
> - Created one tenant geneve based network (added as port to router) and a
> flat external network (set as gateway for router).
>
> ~~~
> [root@controller ~(keystone_admin)]# rpm -qa | awk '/openvswitch-ovn/ {print
> $1}'
> openvswitch-ovn-common-2.7.2-3.1fc27.el7.x86_64
> openvswitch-ovn-host-2.7.2-3.1fc27.el7.x86_64
> openvswitch-ovn-central-2.7.2-3.1fc27.el7.x86_64
> ~~~
>
> I am trying to find a compute node on which my gateway router is hosted and
> also the command to check the health of distributed logical routers.
>
> It seems like that "lrp-get-gateway-chassis" command is not present in the
> version which I am using.
>
> ~~~
> [root@controller ~]# ovn-nbctl lrp-get-gateway-chassis
> ovn-nbctl: unknown command 'lrp-get-gateway-chassis'; use --help for help
>
> [root@controller ~]# ovn-nbctl --help | grep -i gateway
>
> ~~~
>
> Output of ovn-nbctl show.
>
> ~~~
>
> [root@controller ~(keystone_admin)]# ovn-nbctl show
> switch 0d413d9c-7f23-4ace-9a8a-29817b3b33b5
> (neutron-89113f8b-bc01-46b1-84fb-edd5d606879c)
> port 6fe3cab5-5f84-44c8-90f2-64c21b489c62
> addresses: ["fa:16:3e:fa:d6:d3 10.10.10.9"]
> port 397c019e-9bc3-49d3-ac4c-4aeeb1b3ba3e
> addresses: ["router"]
> port 4c72cee2-35b7-4bcd-8c77-135a22d16df1
> addresses: ["fa:16:3e:55:3f:be 10.10.10.4"]
> switch 1ec08997-0899-40d1-9b74-0a25ef476c00
> (neutron-e411bbe8-e169-4268-b2bf-d5959d9d7260)
> port provnet-e411bbe8-e169-4268-b2bf-d5959d9d7260
> addresses: ["unknown"]
> port b95e9ae7-5c91-4037-8d2c-660d4af00974
> addresses: ["router"]
> router 7418a4e7-abff-4af7-85f5-6eea2ede9bea
> (neutron-67dc2e78-e109-4dac-acce-b71b2c944dc1)
> port lrp-b95e9ae7-5c91-4037-8d2c-660d4af00974
> mac: "fa:16:3e:52:20:7c"
> networks: ["192.168.122.50/24"]
> port lrp-397c019e-9bc3-49d3-ac4c-4aeeb1b3ba3e
> mac: "fa:16:3e:87:28:40"
> networks: ["10.10.10.1/24"]
Try running:
# ovn-nbctl list Logical_Router_Port lrp-397c019e-9bc3-49d3-ac4c-4aeeb1b3ba3e
(or the other logical router port, I'm not sure which is the right one)
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
Re: [ovs-discuss] ovn-bridge-mappings configuration issue.
Great! Thanks for following up to confirm that it works for you. On Tue, Aug 22, 2017 at 6:14 AM, Rana, JaiSingh <jaisingh.r...@cavium.com> wrote: > Hi Russel, > > > Thanks for quick reply. Yes i created external network on controller node > with > > > 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 > > > > From: Russell Bryant <russ...@ovn.org> > Sent: 21 August 2017 21:17 > To: Rana, JaiSingh > Cc: ovs-discuss@openvswitch.org > Subject: Re: [ovs-discuss] ovn-bridge-mappings configuration issue. > > On Mon, Aug 21, 2017 at 7:43 AM, Rana, JaiSingh > <jaisingh.r...@cavium.com> wrote: >> Hi, >> >> For configuring external gateway, ovn-controller man page says: >> >> " >> >> external_ids:ovn-bridge-mappings >> A list of key-value pairs that map a physical network >> name to a local ovs bridge that provides connectivity >> to that network. An example value mapping two >> physical network names to two ovs bridges would be: phys‐ >> net1:br-eth0,physnet2:br-eth1. >> " >> >> >> Created bridge br-ex and attached an interface p1p2 having external >> connectivity. >> >> >> # ovs-vsctl --may-exist add-br br-ex -- set bridge br-ex >> protocols=OpenFlow13 >> >> # ovs-vsctl set open . external-ids:ovn-bridge-mappings=provider:br-ex >> # ovs-vsctl --may-exist add-port br-ex p1p2 >> >> >> After configuring Openstack with external networks, ovn-controller on >> compute actually looks for bridge named "provider" in >> ovn/controller/patch.c : add_bridge_mappings, which of-course is not >> created >> but throws error that "br-ex" not found as can be seen in >> ovn-controller.log >> >> "2017-08-18T11:20:30.477Z|04536|patch|ERR| bridge not found for localnet >> port 'provnet-03bf-ad69-4225-b69c-0cd23d7969af' with network name >> 'br-ex'" >> >> When this external-id is defined as ovn-bridge-mappings=br-ex:br-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_name" should be set to > "provider" in this example. > > -- > Russell Bryant -- Russell Bryant ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] ovn-bridge-mappings configuration issue.
On Mon, Aug 21, 2017 at 7:43 AM, Rana, JaiSingh <jaisingh.r...@cavium.com> wrote: > Hi, > > For configuring external gateway, ovn-controller man page says: > > " > > external_ids:ovn-bridge-mappings > A list of key-value pairs that map a physical network > name to a local ovs bridge that provides connectivity > to that network. An example value mapping two > physical network names to two ovs bridges would be: phys‐ > net1:br-eth0,physnet2:br-eth1. > " > > > Created bridge br-ex and attached an interface p1p2 having external > connectivity. > > > # ovs-vsctl --may-exist add-br br-ex -- set bridge br-ex > protocols=OpenFlow13 > > # ovs-vsctl set open . external-ids:ovn-bridge-mappings=provider:br-ex > # ovs-vsctl --may-exist add-port br-ex p1p2 > > > After configuring Openstack with external networks, ovn-controller on > compute actually looks for bridge named "provider" in > ovn/controller/patch.c : add_bridge_mappings, which of-course is not created > but throws error that "br-ex" not found as can be seen in ovn-controller.log > > "2017-08-18T11:20:30.477Z|04536|patch|ERR| bridge not found for localnet > port 'provnet-03bf-ad69-4225-b69c-0cd23d7969af' with network name > 'br-ex'" > > When this external-id is defined as ovn-bridge-mappings=br-ex:br-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_name" should be set to "provider" in this example. -- Russell Bryant ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN external network access in Openstack
On Thu, Nov 17, 2016 at 9:44 AM, Michael Kashin <mmkas...@gmail.com> wrote: > I'm using stable/newton, not master. Is master networking-ovn backwards > compatible with newton version of Neutron or do I need to get ocata Neutron > as well? > It may work, but that combination 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
Re: [ovs-discuss] OVN external network access in Openstack
On Wed, Nov 16, 2016 at 12:38 PM, Michael Kashin <mmkas...@gmail.com> wrote: > Greetings, > > I'm integration RDO (Packstack) Openstack with OVN and facing a problem > connecting DVR to external networks. My setup consists of a couple of > virtual networks and a router interconnecting them. On each compute node > I've create a "br-ex" and created a mapping > "ovn-bridge-mappings=extnet:br-ex". > I've also created a neutron network with "--provider:physical_network > extnet" and assigned this network as a gateway to my router. I can see that > OVN northDB creates a new LS with two ports as expected: > > switch 151ac068-ee99-4324-b785-40709b2e2061 (neutron-b4786af5-cf70-4fc2- > 8f36-e9d540165d37) > > port provnet-b4786af5-cf70-4fc2-8f36-e9d540165d37 > > addresses: ["unknown"] > > port fb73ca73-488f-40aa-89e1-e8e312de7a77 > > addresses: ["fa:16:3e:1d:75:66 169.254.0.50"] > > However, I can't see any link between my DVR and this LS. Am I expected to > create a DVR-to-extLS patch manually? > What version of networking-ovn are you using? To do this, you need networking-ovn from master (ocata). > Can you also clarify one more thing. I've seen the setting for L3 gateway > scheduling which, I assume, should place that external router IP > (169.254.0.50 in my case) on a particular compute node. Is there any > document that describes what happens during GW scheduling? > Right now scheduling is primitive. It uses a "least loaded" scheduling policy to distribute gateways among the available chassis. There are some obvious enhancements that need to be made. 1) We need to be 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
