[ovs-discuss] Remove a meter, but the flows including this meter in their instruction set can't be removed.
Hi, I use openvswitch-2.1.2. I found a bug which is shown as title. My test steps as follows: 1. add a meter_3 2. add a meter_4 3. add a flow and its instruction set has meter_3. 4. modify this flow, replace meter_3 with meter_4. 5. dump-flows to confirm instruction set of this flow has meter_4. priority=100,ip,nw_dst=1.2.3.4 actions=meter:4,output:6 6. Remove meter_4, but this flow can't be removed, even this flow used meter_3. 7. Remove meter_3, then this flow is removed. It seems the flow always used the meter which is binding at first time. BR. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] [ovs-dpdk] how to check link between guest vNIC and dpdkvhost socket
Hi, I do have the memAccess property as follows for both VM Best Regards Xu Rongjie (Max) -Original Message- From: ovs-discuss-boun...@openvswitch.org [ mailto:ovs-discuss-boun...@openvswitch.org ] On Behalf Of Flavio Leitner Sent: Thursday, October 26, 2017 09:50 To: Xu, Rongjie (NSB - CN/Hangzhou) Cc: ovs-discuss@openvswitch.org Subject: Re: [ovs-discuss] [ovs-dpdk] how to link between guest vNIC and dpdkvhost socket On Wed, 25 Oct 2017 07:36:13 + "Xu, Rongjie (NSB - CN/Hangzhou)" wrote: > Hi, > > I have one OpenStack environment with OVS-DPDK (manually installed). I success to launch two VMs on two separate compute node with vhostuser interface type. But I cannot ping from one to another. I found there are even no packets in the local 'br-int' bridge (where dpdkvhostuser interface is attached). My guess is the link between guest vNIC and dpdkvhost socket at host side is somehow broken, but I do not know how to proceed. Anyone any suggestions? Most probably you forgot to share the memory between host and guest. in the VM xml: E.g.: ... ... fbl > Compute0: > Bridge br-int > Controller "tcp:127.0.0.1:6633" > is_connected: true > fail_mode: secure > Port "vhu2aae3928-3c" > tag: 1 > Interface "vhu2aae3928-3c" > type: dpdkvhostuser > root@compute0:~# file /var/run/openvswitch/vhu2aae3928-3c > /var/run/openvswitch/vhu2aae3928-3c: socket > > Compute1: > Bridge br-int > Controller "tcp:127.0.0.1:6633" > is_connected: true > fail_mode: secure > Port "vhuca25b420-6d" > tag: 1 > Interface "vhuca25b420-6d" >type: dpdkvhostuser > root@compute1:~# file /var/run/openvswitch/vhuca25b420-6d > /var/run/openvswitch/vhuca25b420-6d: socket > > > When I ping, I even does not find ARP packets in the br-int flow tables. > root@compute0:~# ovs-ofctl dump-flows br-int | grep "in_port=3" > cookie=0xb177d87a58ae18fe, duration=1927.889s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=10,icmp6,in_port=3,icmp_type=136 actions=resubmit(,24) > cookie=0xb177d87a58ae18fe, duration=1927.886s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=10,arp,in_port=3 actions=resubmit(,24) > cookie=0xb177d87a58ae18fe, duration=1927.893s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=9,in_port=3 actions=resubmit(,25) > cookie=0xb177d87a58ae18fe, duration=1927.891s, table=24, n_packets=0, n_bytes=0, idle_age=1927, priority=2,icmp6,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fed3:2116 actions=NORMAL > cookie=0xb177d87a58ae18fe, duration=1927.888s, table=24, n_packets=0, n_bytes=0, idle_age=1927, priority=2,arp,in_port=3,arp_spa=192.168.100.13 actions=resubmit(,25) > cookie=0xb177d87a58ae18fe, duration=1927.896s, table=25, n_packets=0, n_bytes=0, idle_age=1927, priority=2,in_port=3,dl_src=fa:16:3e:d3:21:16 actions=NORMAL > > root@compute0:~# ovs-ofctl show br-int > OFPT_FEATURES_REPLY (xid=0x2): dpid:caf6709a034a > n_tables:254, n_buffers:256 > capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP > actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst > 1(int-br0): addr:7e:de:e2:7b:2a:83 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > 2(patch-tun): addr:5a:2a:d3:f0:14:72 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > 3(vhu2aae3928-3c): addr:00:00:00:00:00:00 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > > Best Regards > Xu Rongjie (Max) > -- Flavio ___ 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-dpdk] how to check link between guest vNIC and dpdkvhost socket
Hi, I do have the memAccess property as follows for both VM Best Regards Xu Rongjie (Max) -Original Message- From: ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Flavio Leitner Sent: Thursday, October 26, 2017 09:50 To: Xu, Rongjie (NSB - CN/Hangzhou) Cc: ovs-discuss@openvswitch.org Subject: Re: [ovs-discuss] [ovs-dpdk] how to link between guest vNIC and dpdkvhost socket On Wed, 25 Oct 2017 07:36:13 + "Xu, Rongjie (NSB - CN/Hangzhou)" wrote: > Hi, > > I have one OpenStack environment with OVS-DPDK (manually installed). I > success to launch two VMs on two separate compute node with vhostuser > interface type. But I cannot ping from one to another. I found there are even > no packets in the local 'br-int' bridge (where dpdkvhostuser interface is > attached). My guess is the link between guest vNIC and dpdkvhost socket at > host side is somehow broken, but I do not know how to proceed. Anyone any > suggestions? Most probably you forgot to share the memory between host and guest. in the VM xml: E.g.: ... ... fbl > Compute0: > Bridge br-int > Controller "tcp:127.0.0.1:6633" > is_connected: true > fail_mode: secure > Port "vhu2aae3928-3c" > tag: 1 > Interface "vhu2aae3928-3c" > type: dpdkvhostuser > root@compute0:~# file /var/run/openvswitch/vhu2aae3928-3c > /var/run/openvswitch/vhu2aae3928-3c: socket > > Compute1: > Bridge br-int > Controller "tcp:127.0.0.1:6633" > is_connected: true > fail_mode: secure > Port "vhuca25b420-6d" > tag: 1 > Interface "vhuca25b420-6d" >type: dpdkvhostuser > root@compute1:~# file /var/run/openvswitch/vhuca25b420-6d > /var/run/openvswitch/vhuca25b420-6d: socket > > > When I ping, I even does not find ARP packets in the br-int flow tables. > root@compute0:~# ovs-ofctl dump-flows br-int | grep "in_port=3" > cookie=0xb177d87a58ae18fe, duration=1927.889s, table=0, n_packets=0, > n_bytes=0, idle_age=1927, priority=10,icmp6,in_port=3,icmp_type=136 > actions=resubmit(,24) > cookie=0xb177d87a58ae18fe, duration=1927.886s, table=0, n_packets=0, > n_bytes=0, idle_age=1927, priority=10,arp,in_port=3 actions=resubmit(,24) > cookie=0xb177d87a58ae18fe, duration=1927.893s, table=0, n_packets=0, > n_bytes=0, idle_age=1927, priority=9,in_port=3 actions=resubmit(,25) > cookie=0xb177d87a58ae18fe, duration=1927.891s, table=24, n_packets=0, > n_bytes=0, idle_age=1927, > priority=2,icmp6,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fed3:2116 > actions=NORMAL > cookie=0xb177d87a58ae18fe, duration=1927.888s, table=24, n_packets=0, > n_bytes=0, idle_age=1927, priority=2,arp,in_port=3,arp_spa=192.168.100.13 > actions=resubmit(,25) > cookie=0xb177d87a58ae18fe, duration=1927.896s, table=25, n_packets=0, > n_bytes=0, idle_age=1927, priority=2,in_port=3,dl_src=fa:16:3e:d3:21:16 > actions=NORMAL > > root@compute0:~# ovs-ofctl show br-int > OFPT_FEATURES_REPLY (xid=0x2): dpid:caf6709a034a > n_tables:254, n_buffers:256 > capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP > actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src > mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst > 1(int-br0): addr:7e:de:e2:7b:2a:83 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > 2(patch-tun): addr:5a:2a:d3:f0:14:72 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > 3(vhu2aae3928-3c): addr:00:00:00:00:00:00 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > > Best Regards > Xu Rongjie (Max) > -- Flavio ___ 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-dpdk] how to link between guest vNIC and dpdkvhost socket
On Wed, 25 Oct 2017 07:36:13 + "Xu, Rongjie (NSB - CN/Hangzhou)" wrote: > Hi, > > I have one OpenStack environment with OVS-DPDK (manually installed). I > success to launch two VMs on two separate compute node with vhostuser > interface type. But I cannot ping from one to another. I found there are even > no packets in the local 'br-int' bridge (where dpdkvhostuser interface is > attached). My guess is the link between guest vNIC and dpdkvhost socket at > host side is somehow broken, but I do not know how to proceed. Anyone any > suggestions? Most probably you forgot to share the memory between host and guest. in the VM xml: E.g.: ... ... fbl > Compute0: > Bridge br-int > Controller "tcp:127.0.0.1:6633" > is_connected: true > fail_mode: secure > Port "vhu2aae3928-3c" > tag: 1 > Interface "vhu2aae3928-3c" > type: dpdkvhostuser > root@compute0:~# file /var/run/openvswitch/vhu2aae3928-3c > /var/run/openvswitch/vhu2aae3928-3c: socket > > Compute1: > Bridge br-int > Controller "tcp:127.0.0.1:6633" > is_connected: true > fail_mode: secure > Port "vhuca25b420-6d" > tag: 1 > Interface "vhuca25b420-6d" >type: dpdkvhostuser > root@compute1:~# file /var/run/openvswitch/vhuca25b420-6d > /var/run/openvswitch/vhuca25b420-6d: socket > > > When I ping, I even does not find ARP packets in the br-int flow tables. > root@compute0:~# ovs-ofctl dump-flows br-int | grep "in_port=3" > cookie=0xb177d87a58ae18fe, duration=1927.889s, table=0, n_packets=0, > n_bytes=0, idle_age=1927, priority=10,icmp6,in_port=3,icmp_type=136 > actions=resubmit(,24) > cookie=0xb177d87a58ae18fe, duration=1927.886s, table=0, n_packets=0, > n_bytes=0, idle_age=1927, priority=10,arp,in_port=3 actions=resubmit(,24) > cookie=0xb177d87a58ae18fe, duration=1927.893s, table=0, n_packets=0, > n_bytes=0, idle_age=1927, priority=9,in_port=3 actions=resubmit(,25) > cookie=0xb177d87a58ae18fe, duration=1927.891s, table=24, n_packets=0, > n_bytes=0, idle_age=1927, > priority=2,icmp6,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fed3:2116 > actions=NORMAL > cookie=0xb177d87a58ae18fe, duration=1927.888s, table=24, n_packets=0, > n_bytes=0, idle_age=1927, priority=2,arp,in_port=3,arp_spa=192.168.100.13 > actions=resubmit(,25) > cookie=0xb177d87a58ae18fe, duration=1927.896s, table=25, n_packets=0, > n_bytes=0, idle_age=1927, priority=2,in_port=3,dl_src=fa:16:3e:d3:21:16 > actions=NORMAL > > root@compute0:~# ovs-ofctl show br-int > OFPT_FEATURES_REPLY (xid=0x2): dpid:caf6709a034a > n_tables:254, n_buffers:256 > capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP > actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src > mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst > 1(int-br0): addr:7e:de:e2:7b:2a:83 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > 2(patch-tun): addr:5a:2a:d3:f0:14:72 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > 3(vhu2aae3928-3c): addr:00:00:00:00:00:00 > config: 0 > state: 0 > speed: 0 Mbps now, 0 Mbps max > > Best Regards > Xu Rongjie (Max) > -- Flavio ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] Default Openflow Ports
We’re trying to manually set the openflow port numbers for our OVS bridge ports. What port numbers should we avoid setting? I thought it was 1-16k and 65534-65535 that are allocated by OVS, but wanted to confirm. Thanks, Tommy Romano ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] [OVN] "Finish up ARP support" approach
Hi folks, Looking into the OVN project and ways to contribute back. I've looked into the `TODO.rst` file under `ovn/` (How up to date is it?) and, more specifically, to the "Finish up ARP/ND support" item, which seems to be a good one to tackle at first. Last week's "OVN: Add support for periodic router advertisements" patch seems to have added further support to ND under IPv6. So, after looking through the patch, I'm thinking on approaching ARP the following way (which is similar to the way RAs was done): - Add an `options` field to set the expiration value (probably defaulting to 60 seconds) to the `Logical_Router_Port` table in the NB DB; - (Maybe even an additional field to set if one wants to disable the bind re-checks before expiration); - In `northd`, translate those `options` in the `Logical_Router_Port` NB DB into `options` in the `Port_Binding` table in the SB DB; - For each run of `pinctrl_run`, check for each binding of each port if the expiration has passed: - If so, and the re-check options has been enabled, send an ARP packet, leading to the update of the MAC binding. - If not, and a check has been performed already, or if the re-check options is disabled, delete the binding. Now, it is still not clear to me what will be the best way to track each last-checked time for each binding, so one can then delete the entry after the expiration (maybe through options on the `MAC_Binding` table as well?). This is very theoretic for now, but do you see any drawbacks to this approach? And is this more or less what's intended for the "Finish up ARP support" TODO item? Thanks, Tiago. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] [OVN] OVN doesn't work using OVS 2.8.1 on Centos 7.3 using conntrack
On Wed, Oct 25, 2017 at 10:51 PM, Ben Pfaff wrote:
> On Wed, Oct 25, 2017 at 06:50:29PM +0530, Numan Siddique wrote:
> > On Wed, Oct 25, 2017 at 3:09 PM, Daniel Alvarez Sanchez <
> dalva...@redhat.com
> > > wrote:
> >
> > >
> > >
> > > On Tue, Oct 24, 2017 at 11:35 PM, Ben Pfaff wrote:
> > >
> > >> On Tue, Oct 24, 2017 at 02:27:59PM -0700, Ben Pfaff wrote:
> > >> > On Tue, Oct 24, 2017 at 11:07:58PM +0200, Daniel Alvarez Sanchez
> wrote:
> > >> > > Hi guys,
> > >> > >
> > >> > > Great job Numan!
> > >> > > As we discussed over IRC, the patch below may make more sense.
> > >> > > It essentially sets the dl_type so that when packet comes from the
> > >> > > controller, it matches
> > >> > > a valid type and OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 is not added.
> > >> > > Maybe what Numan proposed and this patch could be a good
> combination
> > >> but I
> > >> > > think
> > >> > > that we definitely need to set the dl_type as it's later checked
> in
> > >> > > pkt_metadata_from_flow()
> > >> > > and it'll be zero there otherwise.
> > >> > > What do you guys think? I have tried the patch below and the
> kernel
> > >> error
> > >> > > is not shown
> > >> > > anymore when issuing DHCP requests.
> > >> > >
> > >> > >
> > >> > > diff --git a/lib/flow.c b/lib/flow.c
> > >> > > index b2b10aa..62b948f 100644
> > >> > > --- a/lib/flow.c
> > >> > > +++ b/lib/flow.c
> > >> > > @@ -1073,6 +1073,7 @@ flow_get_metadata(const struct flow *flow,
> > >> struct
> > >> > > match *flow_metadata)
> > >> > >
> > >> > > if (flow->ct_state != 0) {
> > >> > > match_set_ct_state(flow_metadata, flow->ct_state);
> > >> > > +match_set_dl_type(flow_metadata, flow->dl_type);
> > >> > > if (is_ct_valid(flow, NULL, NULL) && flow->ct_nw_proto
> != 0)
> > >> {
> > >> > > if (flow->dl_type == htons(ETH_TYPE_IP)) {
> > >> > > match_set_ct_nw_src(flow_metadata,
> flow->ct_nw_src);
> > >> >
> > >> > This patch seems reasonable too.
> > >> >
> > >> > I recommend adding a comment above it to explain what's going on,
> > >> > because dl_type is not a metadata field and it's confusing to deal
> with
> > >> > it in a context that's supposed to be all about metadata. I guess
> the
> > >> > comment would essentially say that dl_type is essential to the
> > >> > interpretation of the conntrack metadata.
> > >>
> > >> Oh, and for this patch too I'd welcome a formal patch proposal.
> > >>
> > >
> > > Done. Thanks a lot Ben.
> > > If this get merged, it would be great if we can get it into 2.8 branch
> and
> > > add a new tag (2.8.2).
> > >
> > > Thanks!!
> > >
> >
> > Ben, we have submitted both the patches. The patch from Daniel - (
> > https://patchwork.ozlabs.org/patch/830160/) will fix the issue.
> > Not sure if this patch https://patchwork.ozlabs.org/patch/830132/ is
> > needed any more.
> >
> > Request to review these patches if possible as RDO is blocked on these
> > patches before we can update from OVS 2.7.2 to OVS 2.8(.2)
>
> I've reviewed both. I wasn't able to immediately apply either one, but
> they're obviously moving in the right direction, so I'd appreciate
> follow-up from both of you so that we can get them in.
>
Thanks for the review.
Numan
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] [OVN] OVN doesn't work using OVS 2.8.1 on Centos 7.3 using conntrack
On Wed, Oct 25, 2017 at 06:50:29PM +0530, Numan Siddique wrote:
> On Wed, Oct 25, 2017 at 3:09 PM, Daniel Alvarez Sanchez > wrote:
>
> >
> >
> > On Tue, Oct 24, 2017 at 11:35 PM, Ben Pfaff wrote:
> >
> >> On Tue, Oct 24, 2017 at 02:27:59PM -0700, Ben Pfaff wrote:
> >> > On Tue, Oct 24, 2017 at 11:07:58PM +0200, Daniel Alvarez Sanchez wrote:
> >> > > Hi guys,
> >> > >
> >> > > Great job Numan!
> >> > > As we discussed over IRC, the patch below may make more sense.
> >> > > It essentially sets the dl_type so that when packet comes from the
> >> > > controller, it matches
> >> > > a valid type and OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 is not added.
> >> > > Maybe what Numan proposed and this patch could be a good combination
> >> but I
> >> > > think
> >> > > that we definitely need to set the dl_type as it's later checked in
> >> > > pkt_metadata_from_flow()
> >> > > and it'll be zero there otherwise.
> >> > > What do you guys think? I have tried the patch below and the kernel
> >> error
> >> > > is not shown
> >> > > anymore when issuing DHCP requests.
> >> > >
> >> > >
> >> > > diff --git a/lib/flow.c b/lib/flow.c
> >> > > index b2b10aa..62b948f 100644
> >> > > --- a/lib/flow.c
> >> > > +++ b/lib/flow.c
> >> > > @@ -1073,6 +1073,7 @@ flow_get_metadata(const struct flow *flow,
> >> struct
> >> > > match *flow_metadata)
> >> > >
> >> > > if (flow->ct_state != 0) {
> >> > > match_set_ct_state(flow_metadata, flow->ct_state);
> >> > > +match_set_dl_type(flow_metadata, flow->dl_type);
> >> > > if (is_ct_valid(flow, NULL, NULL) && flow->ct_nw_proto != 0)
> >> {
> >> > > if (flow->dl_type == htons(ETH_TYPE_IP)) {
> >> > > match_set_ct_nw_src(flow_metadata, flow->ct_nw_src);
> >> >
> >> > This patch seems reasonable too.
> >> >
> >> > I recommend adding a comment above it to explain what's going on,
> >> > because dl_type is not a metadata field and it's confusing to deal with
> >> > it in a context that's supposed to be all about metadata. I guess the
> >> > comment would essentially say that dl_type is essential to the
> >> > interpretation of the conntrack metadata.
> >>
> >> Oh, and for this patch too I'd welcome a formal patch proposal.
> >>
> >
> > Done. Thanks a lot Ben.
> > If this get merged, it would be great if we can get it into 2.8 branch and
> > add a new tag (2.8.2).
> >
> > Thanks!!
> >
>
> Ben, we have submitted both the patches. The patch from Daniel - (
> https://patchwork.ozlabs.org/patch/830160/) will fix the issue.
> Not sure if this patch https://patchwork.ozlabs.org/patch/830132/ is
> needed any more.
>
> Request to review these patches if possible as RDO is blocked on these
> patches before we can update from OVS 2.7.2 to OVS 2.8(.2)
I've reviewed both. I wasn't able to immediately apply either one, but
they're obviously moving in the right direction, so I'd appreciate
follow-up from both of you so that we can get them in.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] About the 'clone' action
On Wed, Oct 25, 2017 at 06:07:41PM +0800, Hui Xiang wrote: > I think I am finally catching a bit with the concept of 'clone' action > after reviewing below patches in order, so the for OVN case, the new > 'clone' action aims to drop most of the OVS patch port, and after add new > ct_clear action, some fixes, I assume it works with NAT, and I am using > 2.8.1 for testing, please point out the patches if I am missing any. I think that should work fine. There are a few bug fixes on branch-2.8 that are not in any v2.8.x release, but I don't think that they will affect OVN. > One other question is Can I set bridge-mapping:physnet1:br-int? In > other words, the br-int has vm vif, has tunnel ports(the tunnel ports > would point to another nic), and has the external nic as local gateway > router port, is it feasible without configuring more extra flows. I don't think OVN contemplates br-int being using as a bridge mapping. My guess is that that would fail. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] [ovs-dpdk] how to link between guest vNIC and dpdkvhost socket
Hi, I have one OpenStack environment with OVS-DPDK (manually installed). I success to launch two VMs on two separate compute node with vhostuser interface type. But I cannot ping from one to another. I found there are even no packets in the local 'br-int' bridge (where dpdkvhostuser interface is attached). My guess is the link between guest vNIC and dpdkvhost socket at host side is somehow broken, but I do not know how to proceed. Anyone any suggestions? Compute0: Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port "vhu2aae3928-3c" tag: 1 Interface "vhu2aae3928-3c" type: dpdkvhostuser root@compute0:~# file /var/run/openvswitch/vhu2aae3928-3c /var/run/openvswitch/vhu2aae3928-3c: socket Compute1: Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port "vhuca25b420-6d" tag: 1 Interface "vhuca25b420-6d" type: dpdkvhostuser root@compute1:~# file /var/run/openvswitch/vhuca25b420-6d /var/run/openvswitch/vhuca25b420-6d: socket When I ping, I even does not find ARP packets in the br-int flow tables. root@compute0:~# ovs-ofctl dump-flows br-int | grep "in_port=3" cookie=0xb177d87a58ae18fe, duration=1927.889s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=10,icmp6,in_port=3,icmp_type=136 actions=resubmit(,24) cookie=0xb177d87a58ae18fe, duration=1927.886s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=10,arp,in_port=3 actions=resubmit(,24) cookie=0xb177d87a58ae18fe, duration=1927.893s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=9,in_port=3 actions=resubmit(,25) cookie=0xb177d87a58ae18fe, duration=1927.891s, table=24, n_packets=0, n_bytes=0, idle_age=1927, priority=2,icmp6,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fed3:2116 actions=NORMAL cookie=0xb177d87a58ae18fe, duration=1927.888s, table=24, n_packets=0, n_bytes=0, idle_age=1927, priority=2,arp,in_port=3,arp_spa=192.168.100.13 actions=resubmit(,25) cookie=0xb177d87a58ae18fe, duration=1927.896s, table=25, n_packets=0, n_bytes=0, idle_age=1927, priority=2,in_port=3,dl_src=fa:16:3e:d3:21:16 actions=NORMAL root@compute0:~# ovs-ofctl show br-int OFPT_FEATURES_REPLY (xid=0x2): dpid:caf6709a034a n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(int-br0): addr:7e:de:e2:7b:2a:83 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 2(patch-tun): addr:5a:2a:d3:f0:14:72 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 3(vhu2aae3928-3c): addr:00:00:00:00:00:00 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max Best Regards Xu Rongjie (Max) ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS Flow insert
On Wed, Oct 25, 2017 at 05:13:03PM +0300, Sara Gittlin wrote: > Can someone refer to the code where a new flow is inserted to > openflow tables in the OVS, as a consequence action of a received > message from a controller? handle_flow_mod() in ofproto.c ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] OVS Flow insert
Hello Can someone refer to the code where a new flow is inserted to openflow tables in the OVS, as a consequence action of a received message from a controller? Thanks in advance --Sara ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] [OVN] OVN doesn't work using OVS 2.8.1 on Centos 7.3 using conntrack
On Wed, Oct 25, 2017 at 3:09 PM, Daniel Alvarez Sanchez wrote:
>
>
> On Tue, Oct 24, 2017 at 11:35 PM, Ben Pfaff wrote:
>
>> On Tue, Oct 24, 2017 at 02:27:59PM -0700, Ben Pfaff wrote:
>> > On Tue, Oct 24, 2017 at 11:07:58PM +0200, Daniel Alvarez Sanchez wrote:
>> > > Hi guys,
>> > >
>> > > Great job Numan!
>> > > As we discussed over IRC, the patch below may make more sense.
>> > > It essentially sets the dl_type so that when packet comes from the
>> > > controller, it matches
>> > > a valid type and OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 is not added.
>> > > Maybe what Numan proposed and this patch could be a good combination
>> but I
>> > > think
>> > > that we definitely need to set the dl_type as it's later checked in
>> > > pkt_metadata_from_flow()
>> > > and it'll be zero there otherwise.
>> > > What do you guys think? I have tried the patch below and the kernel
>> error
>> > > is not shown
>> > > anymore when issuing DHCP requests.
>> > >
>> > >
>> > > diff --git a/lib/flow.c b/lib/flow.c
>> > > index b2b10aa..62b948f 100644
>> > > --- a/lib/flow.c
>> > > +++ b/lib/flow.c
>> > > @@ -1073,6 +1073,7 @@ flow_get_metadata(const struct flow *flow,
>> struct
>> > > match *flow_metadata)
>> > >
>> > > if (flow->ct_state != 0) {
>> > > match_set_ct_state(flow_metadata, flow->ct_state);
>> > > +match_set_dl_type(flow_metadata, flow->dl_type);
>> > > if (is_ct_valid(flow, NULL, NULL) && flow->ct_nw_proto != 0)
>> {
>> > > if (flow->dl_type == htons(ETH_TYPE_IP)) {
>> > > match_set_ct_nw_src(flow_metadata, flow->ct_nw_src);
>> >
>> > This patch seems reasonable too.
>> >
>> > I recommend adding a comment above it to explain what's going on,
>> > because dl_type is not a metadata field and it's confusing to deal with
>> > it in a context that's supposed to be all about metadata. I guess the
>> > comment would essentially say that dl_type is essential to the
>> > interpretation of the conntrack metadata.
>>
>> Oh, and for this patch too I'd welcome a formal patch proposal.
>>
>
> Done. Thanks a lot Ben.
> If this get merged, it would be great if we can get it into 2.8 branch and
> add a new tag (2.8.2).
>
> Thanks!!
>
Ben, we have submitted both the patches. The patch from Daniel - (
https://patchwork.ozlabs.org/patch/830160/) will fix the issue.
Not sure if this patch https://patchwork.ozlabs.org/patch/830132/ is
needed any more.
Request to review these patches if possible as RDO is blocked on these
patches before we can update from OVS 2.7.2 to OVS 2.8(.2)
Thanks
Numan
Daniel
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] About the 'clone' action
Thanks Ben for your info. I think I am finally catching a bit with the concept of 'clone' action after reviewing below patches in order, so the for OVN case, the new 'clone' action aims to drop most of the OVS patch port, and after add new ct_clear action, some fixes, I assume it works with NAT, and I am using 2.8.1 for testing, please point out the patches if I am missing any. One other question is Can I set bridge-mapping:physnet1:br-int? In other words, the br-int has vm vif, has tunnel ports(the tunnel ports would point to another nic), and has the external nic as local gateway router port, is it feasible without configuring more extra flows. [ovs-dev] [RFC PATCH] ofp-actions: Add clone action. https://mail.openvswitch.org/pipermail/ovs-dev/2016-November/325542.html ovn-controller: Drop most uses of OVS patch ports. https://github.com/openvswitch/ovs/commit/f1a8bd06d58f2c5312622fbaeacbc6ce7576e347https://github.com/openvswitch/ovs/commit/f1a8bd06d58f2c5312622fbaeacbc6ce7576e347 [ovs-dev] [PATCH 2/3] dpif-netdev: Add clone action https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327633.html [ovs-dev] Issues with the use of the clone action for resubmission to the pipeline https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/326981.html [ovs-dev] ovn ping from VM to external gateway IP failed. https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326936.html [ovs-dev] [PATCH v2 0/4] Fix some "clone"-related issues https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327251.html [ovs-dev] [PATCH v2 3/4] New action "ct_clear". https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327268.html [ovs-dev] [PATCH v2 4/4] ovn-controller: Clear conntrack state inside clone action. https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327255.html On Tue, Oct 24, 2017 at 12:21 AM, Ben Pfaff wrote: > On Mon, Oct 23, 2017 at 04:28:53PM +0800, Hui Xiang wrote: > > I am trying to understand clone action deeply and checking the patch > > related with 'clone'[1], where said "The clone action provides an action > > envelope to enclose an action list." and "The clone action is very > similar > > with the OpenFlow clone action recently added", but sorry I am not able > to > > find any "clone" action definition in the OpenFlow spec[2], or any > envelope > > 's kind of phrases, it just referred some clone(copy) of piple, am I > > looking in a wrong place? > > Open vSwitch has two kinds of actions. First, there are OpenFlow > actions, which include both standard actions and extension actions. > "clone" is an OpenFlow extension action implemented by Open vSwitch. > Second, there are datapath actions, which are an implementation detail > of Open vSwitch. Open vSwitch has a datapath action also called > "clone", which does something similar to the OpenFlow extension "clone" > action but at the datapath level. > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] [ovs-dev] [OVN] OVN doesn't work using OVS 2.8.1 on Centos 7.3 using conntrack
On Tue, Oct 24, 2017 at 11:35 PM, Ben Pfaff wrote:
> On Tue, Oct 24, 2017 at 02:27:59PM -0700, Ben Pfaff wrote:
> > On Tue, Oct 24, 2017 at 11:07:58PM +0200, Daniel Alvarez Sanchez wrote:
> > > Hi guys,
> > >
> > > Great job Numan!
> > > As we discussed over IRC, the patch below may make more sense.
> > > It essentially sets the dl_type so that when packet comes from the
> > > controller, it matches
> > > a valid type and OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4 is not added.
> > > Maybe what Numan proposed and this patch could be a good combination
> but I
> > > think
> > > that we definitely need to set the dl_type as it's later checked in
> > > pkt_metadata_from_flow()
> > > and it'll be zero there otherwise.
> > > What do you guys think? I have tried the patch below and the kernel
> error
> > > is not shown
> > > anymore when issuing DHCP requests.
> > >
> > >
> > > diff --git a/lib/flow.c b/lib/flow.c
> > > index b2b10aa..62b948f 100644
> > > --- a/lib/flow.c
> > > +++ b/lib/flow.c
> > > @@ -1073,6 +1073,7 @@ flow_get_metadata(const struct flow *flow, struct
> > > match *flow_metadata)
> > >
> > > if (flow->ct_state != 0) {
> > > match_set_ct_state(flow_metadata, flow->ct_state);
> > > +match_set_dl_type(flow_metadata, flow->dl_type);
> > > if (is_ct_valid(flow, NULL, NULL) && flow->ct_nw_proto != 0) {
> > > if (flow->dl_type == htons(ETH_TYPE_IP)) {
> > > match_set_ct_nw_src(flow_metadata, flow->ct_nw_src);
> >
> > This patch seems reasonable too.
> >
> > I recommend adding a comment above it to explain what's going on,
> > because dl_type is not a metadata field and it's confusing to deal with
> > it in a context that's supposed to be all about metadata. I guess the
> > comment would essentially say that dl_type is essential to the
> > interpretation of the conntrack metadata.
>
> Oh, and for this patch too I'd welcome a formal patch proposal.
>
Done. Thanks a lot Ben.
If this get merged, it would be great if we can get it into 2.8 branch and
add a new tag (2.8.2).
Thanks!!
Daniel
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] [ovs-dpdk] how to link between guest vNIC and dpdkvhost socket
Hi, I have one OpenStack environment with OVS-DPDK (manually installed). I success to launch two VMs on two separate compute node with vhostuser interface type. But I cannot ping from one to another. I found there are even no packets in the local 'br-int' bridge (where dpdkvhostuser interface is attached). My guess is the link between guest vNIC and dpdkvhost socket at host side is somehow broken, but I do not know how to proceed. Anyone any suggestions? Compute0: Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port "vhu2aae3928-3c" tag: 1 Interface "vhu2aae3928-3c" type: dpdkvhostuser root@compute0:~# file /var/run/openvswitch/vhu2aae3928-3c /var/run/openvswitch/vhu2aae3928-3c: socket Compute1: Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port "vhuca25b420-6d" tag: 1 Interface "vhuca25b420-6d" type: dpdkvhostuser root@compute1:~# file /var/run/openvswitch/vhuca25b420-6d /var/run/openvswitch/vhuca25b420-6d: socket When I ping, I even does not find ARP packets in the br-int flow tables. root@compute0:~# ovs-ofctl dump-flows br-int | grep "in_port=3" cookie=0xb177d87a58ae18fe, duration=1927.889s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=10,icmp6,in_port=3,icmp_type=136 actions=resubmit(,24) cookie=0xb177d87a58ae18fe, duration=1927.886s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=10,arp,in_port=3 actions=resubmit(,24) cookie=0xb177d87a58ae18fe, duration=1927.893s, table=0, n_packets=0, n_bytes=0, idle_age=1927, priority=9,in_port=3 actions=resubmit(,25) cookie=0xb177d87a58ae18fe, duration=1927.891s, table=24, n_packets=0, n_bytes=0, idle_age=1927, priority=2,icmp6,in_port=3,icmp_type=136,nd_target=fe80::f816:3eff:fed3:2116 actions=NORMAL cookie=0xb177d87a58ae18fe, duration=1927.888s, table=24, n_packets=0, n_bytes=0, idle_age=1927, priority=2,arp,in_port=3,arp_spa=192.168.100.13 actions=resubmit(,25) cookie=0xb177d87a58ae18fe, duration=1927.896s, table=25, n_packets=0, n_bytes=0, idle_age=1927, priority=2,in_port=3,dl_src=fa:16:3e:d3:21:16 actions=NORMAL root@compute0:~# ovs-ofctl show br-int OFPT_FEATURES_REPLY (xid=0x2): dpid:caf6709a034a n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst 1(int-br0): addr:7e:de:e2:7b:2a:83 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 2(patch-tun): addr:5a:2a:d3:f0:14:72 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max 3(vhu2aae3928-3c): addr:00:00:00:00:00:00 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max Best Regards Xu Rongjie (Max) ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
