[ovs-discuss] 答复: [ovs-dev] can OVS conntrack support IP list like this: actions=ct(commit, table=0, zone=1, nat(dst=220.0.0.3, 220.0.0.7, 220.0.0.123))?
smime.p7m Description: S/MIME encrypted message ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS/OVN docker image for each stable release
Hi If it is useful, we can start this with: GitHub.com/ServiceFractal/ovs /Shivaram ::Sent from my mobile device:: > On Nov 7, 2019, at 4:15 PM, aginwala wrote: > > > Hi All: > > As discussed in the meeting today, we all agreed that it will be a good idea > to push docker images for each new ovs/ovn stable release. Hence, need help > from maintainers Ben/Mark/Justin/Han to address some open action items as it > is more of org/ownership/rights related: > Get new repo created under docker.io with name either ovs/ovn and declare it > public repo > How about copy-rights for running images for open source projects > Storage: unlimited or some limited GBs > Naming conventions for docker images ;e.g openswitch/ovn:2.13.1_debian or > openswitch/ovn:2.13.1_rhel. Similar for ovs. > > Once this is done, we can bundle docker image changes in the same release > process > > Please feel free to add any missing piece. > > ___ > 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] OVN RBAC role for ovn-northd?
Thanks Frode for covering that. Added minor comments too your PR and you can send formal patch. On Thu, Nov 7, 2019 at 2:00 PM Frode Nordahl wrote: > fwiw; I proposed this small note earlier this evening: > https://github.com/ovn-org/ovn/pull/25 > > tor. 7. nov. 2019, 21:47 skrev Ben Pfaff : > >> Sure, anything helps. >> >> On Thu, Nov 07, 2019 at 12:27:44PM -0800, aginwala wrote: >> > Hi Ben: >> > >> > It seems RBAC doc >> > >> http://docs.openvswitch.org/en/stable/tutorials/ovn-rbac/#configuring-rbac >> > only talks >> > about chassis and not mentioning about northd. I can submit a patch to >> > update that as a todo for northd and mention the workaround until we add >> > formal support. Is that ok? >> > >> > >> > >> > >> > On Thu, Nov 7, 2019 at 12:14 PM Ben Pfaff wrote: >> > >> > > Have we documented this? Should we? >> > > >> > > On Thu, Nov 07, 2019 at 10:20:22AM -0800, aginwala wrote: >> > > > Hi: >> > > > >> > > > It is a known fact and have-been discussed before. We use the same >> > > > workaround as you mentioned. Alternatively, you can also set >> role="" and >> > > it >> > > > will work for both northd and ovn-controller instead of separate >> > > listeners >> > > > which is also a security loop-hole. In short, some work is needed >> here >> > > > to handle rbac for northd. >> > > > >> > > > On Thu, Nov 7, 2019 at 9:47 AM Frode Nordahl < >> > > frode.nord...@canonical.com> >> > > > wrote: >> > > > >> > > > > Hello all, >> > > > > >> > > > > TL;DR; When enabling the `ovn-controller` role on the SB DB >> > > `ovsdb-server` >> > > > > listener, `ovn-northd` no longer has the necessary access to do >> its job >> > > > > when you are unable to use the local unix socket for its >> connection to >> > > the >> > > > > database. >> > > > > >> > > > > AFAICT there is no northd-specifc or admin type role available, >> have I >> > > > > missed something? >> > > > > >> > > > > I have worked around the issue by enabling a separate listener on >> a >> > > > > different port on the Southbound ovsdb-servers so that >> `ovn-northd` can >> > > > > connect to that. >> > > > > >> > > > > >> > > > > I have a OVN deployment with central components spread across >> three >> > > > > machines, there is an instance of the Northbound and Southbound >> > > > > `ovsdb-server` on each of them which are clustered, and there is >> also >> > > an >> > > > > instance of `ovn-northd` on each of them. >> > > > > >> > > > > The deployment is TLS-enabled and I have enabled RBAC. >> > > > > >> > > > > Since the DBs are clustered I have no control of which machine >> will be >> > > the >> > > > > leader, and it may be that one machine has the leader for the >> > > Northbound DB >> > > > > and a different machine has the leader of the Southbound DB. >> > > > > >> > > > > Because of this ovn-northd is unable to talk to the databases >> through a >> > > > > local unix socket and must use a TLS-enabled connection to the >> DBs, and >> > > > > herein lies the problem. >> > > > > >> > > > > >> > > > > I peeked at the RBAC implementation, and it appears to me that the >> > > > > permission system is tied to having specific columns in each >> table that >> > > > > maps to the name of the client that wants permission. On the >> surface >> > > this >> > > > > appears to not fit with `ovn-northd`'s needs as I would think it >> would >> > > need >> > > > > full access to all tables perhaps based on a centrally managed >> set of >> > > > > hostnames. >> > > > > >> > > > > -- >> > > > > Frode Nordahl >> > > > > >> > > > > ___ >> > > > > 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 >> > > >> > > >> > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN RBAC role for ovn-northd?
fwiw; I proposed this small note earlier this evening: https://github.com/ovn-org/ovn/pull/25 tor. 7. nov. 2019, 21:47 skrev Ben Pfaff : > Sure, anything helps. > > On Thu, Nov 07, 2019 at 12:27:44PM -0800, aginwala wrote: > > Hi Ben: > > > > It seems RBAC doc > > > http://docs.openvswitch.org/en/stable/tutorials/ovn-rbac/#configuring-rbac > > only talks > > about chassis and not mentioning about northd. I can submit a patch to > > update that as a todo for northd and mention the workaround until we add > > formal support. Is that ok? > > > > > > > > > > On Thu, Nov 7, 2019 at 12:14 PM Ben Pfaff wrote: > > > > > Have we documented this? Should we? > > > > > > On Thu, Nov 07, 2019 at 10:20:22AM -0800, aginwala wrote: > > > > Hi: > > > > > > > > It is a known fact and have-been discussed before. We use the same > > > > workaround as you mentioned. Alternatively, you can also set role="" > and > > > it > > > > will work for both northd and ovn-controller instead of separate > > > listeners > > > > which is also a security loop-hole. In short, some work is needed > here > > > > to handle rbac for northd. > > > > > > > > On Thu, Nov 7, 2019 at 9:47 AM Frode Nordahl < > > > frode.nord...@canonical.com> > > > > wrote: > > > > > > > > > Hello all, > > > > > > > > > > TL;DR; When enabling the `ovn-controller` role on the SB DB > > > `ovsdb-server` > > > > > listener, `ovn-northd` no longer has the necessary access to do > its job > > > > > when you are unable to use the local unix socket for its > connection to > > > the > > > > > database. > > > > > > > > > > AFAICT there is no northd-specifc or admin type role available, > have I > > > > > missed something? > > > > > > > > > > I have worked around the issue by enabling a separate listener on a > > > > > different port on the Southbound ovsdb-servers so that > `ovn-northd` can > > > > > connect to that. > > > > > > > > > > > > > > > I have a OVN deployment with central components spread across three > > > > > machines, there is an instance of the Northbound and Southbound > > > > > `ovsdb-server` on each of them which are clustered, and there is > also > > > an > > > > > instance of `ovn-northd` on each of them. > > > > > > > > > > The deployment is TLS-enabled and I have enabled RBAC. > > > > > > > > > > Since the DBs are clustered I have no control of which machine > will be > > > the > > > > > leader, and it may be that one machine has the leader for the > > > Northbound DB > > > > > and a different machine has the leader of the Southbound DB. > > > > > > > > > > Because of this ovn-northd is unable to talk to the databases > through a > > > > > local unix socket and must use a TLS-enabled connection to the > DBs, and > > > > > herein lies the problem. > > > > > > > > > > > > > > > I peeked at the RBAC implementation, and it appears to me that the > > > > > permission system is tied to having specific columns in each table > that > > > > > maps to the name of the client that wants permission. On the > surface > > > this > > > > > appears to not fit with `ovn-northd`'s needs as I would think it > would > > > need > > > > > full access to all tables perhaps based on a centrally managed set > of > > > > > hostnames. > > > > > > > > > > -- > > > > > Frode Nordahl > > > > > > > > > > ___ > > > > > 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 > > > > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] OVS/OVN docker image for each stable release
Hi All: As discussed in the meeting today, we all agreed that it will be a good idea to push docker images for each new ovs/ovn stable release. Hence, need help from maintainers Ben/Mark/Justin/Han to address some open action items as it is more of org/ownership/rights related: 1. Get new repo created under docker.io with name either ovs/ovn and declare it public repo 2. How about copy-rights for running images for open source projects 3. Storage: unlimited or some limited GBs 4. Naming conventions for docker images ;e.g openswitch/ovn:2.13.1_debian or openswitch/ovn:2.13.1_rhel. Similar for ovs. Once this is done, we can bundle docker image changes in the same release process Please feel free to add any missing piece. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN RBAC role for ovn-northd?
Sure, anything helps. On Thu, Nov 07, 2019 at 12:27:44PM -0800, aginwala wrote: > Hi Ben: > > It seems RBAC doc > http://docs.openvswitch.org/en/stable/tutorials/ovn-rbac/#configuring-rbac > only talks > about chassis and not mentioning about northd. I can submit a patch to > update that as a todo for northd and mention the workaround until we add > formal support. Is that ok? > > > > > On Thu, Nov 7, 2019 at 12:14 PM Ben Pfaff wrote: > > > Have we documented this? Should we? > > > > On Thu, Nov 07, 2019 at 10:20:22AM -0800, aginwala wrote: > > > Hi: > > > > > > It is a known fact and have-been discussed before. We use the same > > > workaround as you mentioned. Alternatively, you can also set role="" and > > it > > > will work for both northd and ovn-controller instead of separate > > listeners > > > which is also a security loop-hole. In short, some work is needed here > > > to handle rbac for northd. > > > > > > On Thu, Nov 7, 2019 at 9:47 AM Frode Nordahl < > > frode.nord...@canonical.com> > > > wrote: > > > > > > > Hello all, > > > > > > > > TL;DR; When enabling the `ovn-controller` role on the SB DB > > `ovsdb-server` > > > > listener, `ovn-northd` no longer has the necessary access to do its job > > > > when you are unable to use the local unix socket for its connection to > > the > > > > database. > > > > > > > > AFAICT there is no northd-specifc or admin type role available, have I > > > > missed something? > > > > > > > > I have worked around the issue by enabling a separate listener on a > > > > different port on the Southbound ovsdb-servers so that `ovn-northd` can > > > > connect to that. > > > > > > > > > > > > I have a OVN deployment with central components spread across three > > > > machines, there is an instance of the Northbound and Southbound > > > > `ovsdb-server` on each of them which are clustered, and there is also > > an > > > > instance of `ovn-northd` on each of them. > > > > > > > > The deployment is TLS-enabled and I have enabled RBAC. > > > > > > > > Since the DBs are clustered I have no control of which machine will be > > the > > > > leader, and it may be that one machine has the leader for the > > Northbound DB > > > > and a different machine has the leader of the Southbound DB. > > > > > > > > Because of this ovn-northd is unable to talk to the databases through a > > > > local unix socket and must use a TLS-enabled connection to the DBs, and > > > > herein lies the problem. > > > > > > > > > > > > I peeked at the RBAC implementation, and it appears to me that the > > > > permission system is tied to having specific columns in each table that > > > > maps to the name of the client that wants permission. On the surface > > this > > > > appears to not fit with `ovn-northd`'s needs as I would think it would > > need > > > > full access to all tables perhaps based on a centrally managed set of > > > > hostnames. > > > > > > > > -- > > > > Frode Nordahl > > > > > > > > ___ > > > > 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 > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN RBAC role for ovn-northd?
Hi Ben: It seems RBAC doc http://docs.openvswitch.org/en/stable/tutorials/ovn-rbac/#configuring-rbac only talks about chassis and not mentioning about northd. I can submit a patch to update that as a todo for northd and mention the workaround until we add formal support. Is that ok? On Thu, Nov 7, 2019 at 12:14 PM Ben Pfaff wrote: > Have we documented this? Should we? > > On Thu, Nov 07, 2019 at 10:20:22AM -0800, aginwala wrote: > > Hi: > > > > It is a known fact and have-been discussed before. We use the same > > workaround as you mentioned. Alternatively, you can also set role="" and > it > > will work for both northd and ovn-controller instead of separate > listeners > > which is also a security loop-hole. In short, some work is needed here > > to handle rbac for northd. > > > > On Thu, Nov 7, 2019 at 9:47 AM Frode Nordahl < > frode.nord...@canonical.com> > > wrote: > > > > > Hello all, > > > > > > TL;DR; When enabling the `ovn-controller` role on the SB DB > `ovsdb-server` > > > listener, `ovn-northd` no longer has the necessary access to do its job > > > when you are unable to use the local unix socket for its connection to > the > > > database. > > > > > > AFAICT there is no northd-specifc or admin type role available, have I > > > missed something? > > > > > > I have worked around the issue by enabling a separate listener on a > > > different port on the Southbound ovsdb-servers so that `ovn-northd` can > > > connect to that. > > > > > > > > > I have a OVN deployment with central components spread across three > > > machines, there is an instance of the Northbound and Southbound > > > `ovsdb-server` on each of them which are clustered, and there is also > an > > > instance of `ovn-northd` on each of them. > > > > > > The deployment is TLS-enabled and I have enabled RBAC. > > > > > > Since the DBs are clustered I have no control of which machine will be > the > > > leader, and it may be that one machine has the leader for the > Northbound DB > > > and a different machine has the leader of the Southbound DB. > > > > > > Because of this ovn-northd is unable to talk to the databases through a > > > local unix socket and must use a TLS-enabled connection to the DBs, and > > > herein lies the problem. > > > > > > > > > I peeked at the RBAC implementation, and it appears to me that the > > > permission system is tied to having specific columns in each table that > > > maps to the name of the client that wants permission. On the surface > this > > > appears to not fit with `ovn-northd`'s needs as I would think it would > need > > > full access to all tables perhaps based on a centrally managed set of > > > hostnames. > > > > > > -- > > > Frode Nordahl > > > > > > ___ > > > 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 > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN RBAC role for ovn-northd?
Have we documented this? Should we? On Thu, Nov 07, 2019 at 10:20:22AM -0800, aginwala wrote: > Hi: > > It is a known fact and have-been discussed before. We use the same > workaround as you mentioned. Alternatively, you can also set role="" and it > will work for both northd and ovn-controller instead of separate listeners > which is also a security loop-hole. In short, some work is needed here > to handle rbac for northd. > > On Thu, Nov 7, 2019 at 9:47 AM Frode Nordahl > wrote: > > > Hello all, > > > > TL;DR; When enabling the `ovn-controller` role on the SB DB `ovsdb-server` > > listener, `ovn-northd` no longer has the necessary access to do its job > > when you are unable to use the local unix socket for its connection to the > > database. > > > > AFAICT there is no northd-specifc or admin type role available, have I > > missed something? > > > > I have worked around the issue by enabling a separate listener on a > > different port on the Southbound ovsdb-servers so that `ovn-northd` can > > connect to that. > > > > > > I have a OVN deployment with central components spread across three > > machines, there is an instance of the Northbound and Southbound > > `ovsdb-server` on each of them which are clustered, and there is also an > > instance of `ovn-northd` on each of them. > > > > The deployment is TLS-enabled and I have enabled RBAC. > > > > Since the DBs are clustered I have no control of which machine will be the > > leader, and it may be that one machine has the leader for the Northbound DB > > and a different machine has the leader of the Southbound DB. > > > > Because of this ovn-northd is unable to talk to the databases through a > > local unix socket and must use a TLS-enabled connection to the DBs, and > > herein lies the problem. > > > > > > I peeked at the RBAC implementation, and it appears to me that the > > permission system is tied to having specific columns in each table that > > maps to the name of the client that wants permission. On the surface this > > appears to not fit with `ovn-northd`'s needs as I would think it would need > > full access to all tables perhaps based on a centrally managed set of > > hostnames. > > > > -- > > Frode Nordahl > > > > ___ > > 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 ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVN RBAC role for ovn-northd?
On Thu, Nov 7, 2019 at 7:20 PM aginwala wrote: > Hi: > > It is a known fact and have-been discussed before. We use the same > workaround as you mentioned. Alternatively, you can also set role="" and it > will work for both northd and ovn-controller instead of separate listeners > which is also a security loop-hole. In short, some work is needed here > to handle rbac for northd. > Thank you for your prompt response, and for confirming it being a known gap and that the approach is a reasonable one. Albeit not a solution, securing the separate port with external means such as firewall rules that only allow connections from the machines hosting ovn-northd will at least make it a bit more secure. Apologies for any duplicate questions or discussions. I made an honest attempt to find the information by searching the mailing list archive and existing documentation. -- Frode Nordahl > > On Thu, Nov 7, 2019 at 9:47 AM Frode Nordahl > wrote: > >> Hello all, >> >> TL;DR; When enabling the `ovn-controller` role on the SB DB >> `ovsdb-server` listener, `ovn-northd` no longer has the necessary access to >> do its job when you are unable to use the local unix socket for its >> connection to the database. >> >> AFAICT there is no northd-specifc or admin type role available, have I >> missed something? >> >> I have worked around the issue by enabling a separate listener on a >> different port on the Southbound ovsdb-servers so that `ovn-northd` can >> connect to that. >> >> >> I have a OVN deployment with central components spread across three >> machines, there is an instance of the Northbound and Southbound >> `ovsdb-server` on each of them which are clustered, and there is also an >> instance of `ovn-northd` on each of them. >> >> The deployment is TLS-enabled and I have enabled RBAC. >> >> Since the DBs are clustered I have no control of which machine will be >> the leader, and it may be that one machine has the leader for the >> Northbound DB and a different machine has the leader of the Southbound DB. >> >> Because of this ovn-northd is unable to talk to the databases through a >> local unix socket and must use a TLS-enabled connection to the DBs, and >> herein lies the problem. >> >> >> I peeked at the RBAC implementation, and it appears to me that the >> permission system is tied to having specific columns in each table that >> maps to the name of the client that wants permission. On the surface this >> appears to not fit with `ovn-northd`'s needs as I would think it would need >> full access to all tables perhaps based on a centrally managed set of >> hostnames. >> >> -- >> Frode Nordahl >> >> ___ >> 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] OVN RBAC role for ovn-northd?
Hi: It is a known fact and have-been discussed before. We use the same workaround as you mentioned. Alternatively, you can also set role="" and it will work for both northd and ovn-controller instead of separate listeners which is also a security loop-hole. In short, some work is needed here to handle rbac for northd. On Thu, Nov 7, 2019 at 9:47 AM Frode Nordahl wrote: > Hello all, > > TL;DR; When enabling the `ovn-controller` role on the SB DB `ovsdb-server` > listener, `ovn-northd` no longer has the necessary access to do its job > when you are unable to use the local unix socket for its connection to the > database. > > AFAICT there is no northd-specifc or admin type role available, have I > missed something? > > I have worked around the issue by enabling a separate listener on a > different port on the Southbound ovsdb-servers so that `ovn-northd` can > connect to that. > > > I have a OVN deployment with central components spread across three > machines, there is an instance of the Northbound and Southbound > `ovsdb-server` on each of them which are clustered, and there is also an > instance of `ovn-northd` on each of them. > > The deployment is TLS-enabled and I have enabled RBAC. > > Since the DBs are clustered I have no control of which machine will be the > leader, and it may be that one machine has the leader for the Northbound DB > and a different machine has the leader of the Southbound DB. > > Because of this ovn-northd is unable to talk to the databases through a > local unix socket and must use a TLS-enabled connection to the DBs, and > herein lies the problem. > > > I peeked at the RBAC implementation, and it appears to me that the > permission system is tied to having specific columns in each table that > maps to the name of the client that wants permission. On the surface this > appears to not fit with `ovn-northd`'s needs as I would think it would need > full access to all tables perhaps based on a centrally managed set of > hostnames. > > -- > Frode Nordahl > > ___ > 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
[ovs-discuss] OVN RBAC role for ovn-northd?
Hello all, TL;DR; When enabling the `ovn-controller` role on the SB DB `ovsdb-server` listener, `ovn-northd` no longer has the necessary access to do its job when you are unable to use the local unix socket for its connection to the database. AFAICT there is no northd-specifc or admin type role available, have I missed something? I have worked around the issue by enabling a separate listener on a different port on the Southbound ovsdb-servers so that `ovn-northd` can connect to that. I have a OVN deployment with central components spread across three machines, there is an instance of the Northbound and Southbound `ovsdb-server` on each of them which are clustered, and there is also an instance of `ovn-northd` on each of them. The deployment is TLS-enabled and I have enabled RBAC. Since the DBs are clustered I have no control of which machine will be the leader, and it may be that one machine has the leader for the Northbound DB and a different machine has the leader of the Southbound DB. Because of this ovn-northd is unable to talk to the databases through a local unix socket and must use a TLS-enabled connection to the DBs, and herein lies the problem. I peeked at the RBAC implementation, and it appears to me that the permission system is tied to having specific columns in each table that maps to the name of the client that wants permission. On the surface this appears to not fit with `ovn-northd`'s needs as I would think it would need full access to all tables perhaps based on a centrally managed set of hostnames. -- Frode Nordahl ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack
Hi Timo On Wed, Nov 6, 2019 at 9:37 PM txfh2007 wrote: > Hi Darrell: > Sorry, I forgot to tell you the attached flow is based on VM tx > direction rate limit. So the datapath action order is conntrack -> meter -> > forward decision -> output, For the VM rx direction rate limit, the > datapath flow is as below, please help to check, thank you! > For both directions, I think you want to apply the flow meter at the end of the pipeline. Can you do that and then check the numbers again. >Also, for the same flow table and meter configuration, the kernel > datapath rate limit is more accurate than userspace datapath. > For VM rx direction rate limit: > > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x29),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(dst= > 192.168.1.10/255.255.255.248,proto=6,frag=no),tcp_flags(ack), > packets:1031455, bytes:1481163900, used:0.149s, flags:., > actions:ct(zone=4),recirc(0x2a) > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x2a),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(src=192.168.1.8,dst=192.168.1.10,proto=6,frag=no), > packets:1685180, bytes:2415638857, used:0.118s, flags:P., actions:meter(1),6 > > > > > -- > ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by > userspace conntrack > > > Hi Timo > > On Wed, Nov 6, 2019 at 2:06 AM txfh2007 wrote: > > Hi Darrell: > > the flow dump result is as below: Please help to check > BEFORE: > > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1b),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst= > 192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(psh|ack), > packets:18934, bytes:2660, used:0.000s, flags:P., > actions:ct(zone=1),recirc(0x1c) > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1c),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no), > packets:5345996, bytes:7676256441, used:0.000s, flags:P., actions:5 > > AFTER: > > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x19),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst= > 192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(ack), > packets:2473174, bytes:3551472384, used:0.136s, flags:., > actions:meter(0),ct(zone=1),recirc(0x1a) > > > meter is being applied by above rule and then the pipeline continues below > to do another pass thru the datapath; > this would likely explain the numbers > Can you double check the Openflow rules and do the metering at output rule. > > > > ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1a),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no), > packets:5292889, bytes:7599875381, used:0.046s, flags:P., actions:5 > > > > meter rate is 1Gbps, iperf result is around 800Mbps > > [ 5] 95.00-96.00 sec 104 MBytes 869 Mbits/sec > [ 5] 96.00-97.00 sec 79.4 MBytes 666 Mbits/sec > [ 5] 97.00-98.00 sec 107 MBytes 896 Mbits/sec > [ 5] 98.00-99.00 sec 75.4 MBytes 632 Mbits/sec > [ 5] 99.00-100.00 sec 98.3 MBytes 824 Mbits/sec > [ 5] 100.00-100.04 sec 0.00 Bytes 0.00 bits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 5] 0.00-100.04 sec 0.00 Bytes 0.00 bits/sec sender > [ 5] 0.00-100.04 sec 9.29 GBytes 798 Mbits/sec > receiver > > > > -- > ：Darrell Ball > ：2019年11月6日(星期三) 02:46 > ：txfh2007 > ：Ben Pfaff ; ovs-discuss > ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by > userspace conntrack > > > Hi Timo > > On Mon, Nov 4, 2019 at 11:29 PM txfh2007 wrote: > > Hi Darrell: > The meter rate limit is set as 1Gbps, but the actual rate is around > 500Mbps.. I have read the meter patch, but this patch is to prevent delta_t > changed to 0. But in my case, the delta_t is around 35500ms. > > > It might be good to just include all known related fixes anyways, > including this other one > > > > https://github.com/openvswitch/ovs/commit/acc5df0e3cb036524d49891fdb9ba89b609dd26a > > > > > For my case, the meter action is on openflow table 46, and the ct action > is on table 44, the output action is on table 65, so I guess the order is > right? > > > Could you dump the 'relevant' datapath flows before adding the meter rule > and after adding the meter rule ? > ovs-appctl dpif/dump-flows > > > > Thanks > > Timo > > > > -- > ：Darrell Ball >
Re: [ovs-discuss] gso packet is failing with af_packet socket with packet_vnet_hdr
On Wed, 6 Nov 2019 01:59:41 +0530 Ramana Reddy wrote: > Hi Flavio, > As per your inputs, I modified the gso_size, and now > skb_gso_validate_mtu(skb, mtu) is returning true, and > ip_finish_output2(sk, skb) and dst_neigh_output(dst, neigh, skb); are > getting called. But still, I am seeing the large packets getting > dropped somewhere in the kernel > down the line and retransmission happening. The gso_size is the size of the data payload, so it doesn't account the headers. Usually this depends on the iface MTU like I pointed before and that MTU should account for the encapsulation later on. For example: veth0(1450)veth1(1450) -- VXLAN(64k) --- eth0(1500) Perhaps you can use ``dropwatch´´ to find out where the packet is dropped. fbl ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] ovs-vswitchd.service crashes
Hi Koukal I note that you're using the 4.18 kernel from Ubuntu; For Mellanox hardware offload I'd suggest you switch to using the hwe-edge kernel (5.3) as this is generally more mature for this (and other mlx5_core) feature - package name is 'linux-generic-hwe-18.04-edge'. On Thu, Nov 7, 2019 at 9:23 AM Koukal Petr wrote: > In case I turn off hw-offload with > ovs-vsctl set Open_vSwitch. other-config: hw-offload = false > then "ovs-vswitchd" is without collision. > > > Is it possible to reach someone who knows what to do with the offload > problem? > > Thank you for your help. > > Petr > On 11/6/19 6:48 PM, Ben Pfaff wrote: > > On Wed, Nov 06, 2019 at 01:59:36PM +0100, Koukal Petr wrote: > > The problem is the same even if hw-offload is off. > > I'm sending a log from ovs-vswitchd.log just after restarting the whole > openvswitch-switch. > Here you can see what happens before the assertion pops up. > > ethtool -K phys1-1 hw-tc-offload off > ethtool -K phys1-2 hw-tc-offload off > > This demonstrates turning off hardware offload at the ethtool level. > However, even with that, I believe that OVS will still try to use it if > OVS is configured for hardware offload. It looks like your OVS does > have hardware offload enabled. To turn it off, run: > > ovs-vsctl set Open_vSwitch . other-config:hw-offload=false > > Then restart OVS and see if it makes a difference. > > > Informace obsažené v této e-mailové zprávě a všech přiložených souborech > jsou důvěrné a jsou určeny pouze pro potřebu adresáta. Prosíme, abyste v > případě, že tento e-mail obdržíte omylem, neprodleně upozornili odesílatele > a tento e-mail odstranili z Vašeho systému. Pokud nejste zamýšleným > příjemcem, berte prosím na vědomí, že zveřejnění, kopírování, šíření či > přijetí jakéhokoliv opatření v souvislosti s obsahem této zprávy je > zakázáno a může být protiprávní. > > _ > > The information contained in this e-mail message and all attached files is > confidential and is intended solely for the use of the individual or entity > to whom they are addressed. Please notify the sender immediately if you > have received this e-mail by mistake and delete this e-mail from your > system. If you are not the intended recipient you are notified that > disclosing, copying, distributing or taking any action in reliance on the > contents of this information is prohibited and may be unlawful. > ___ > 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-vswitchd.service crashes
In case I turn off hw-offload with ovs-vsctl set Open_vSwitch. other-config: hw-offload = false then "ovs-vswitchd" is without collision. Is it possible to reach someone who knows what to do with the offload problem? Thank you for your help. Petr On 11/6/19 6:48 PM, Ben Pfaff wrote: On Wed, Nov 06, 2019 at 01:59:36PM +0100, Koukal Petr wrote: The problem is the same even if hw-offload is off. I'm sending a log from ovs-vswitchd.log just after restarting the whole openvswitch-switch. Here you can see what happens before the assertion pops up. ethtool -K phys1-1 hw-tc-offload off ethtool -K phys1-2 hw-tc-offload off This demonstrates turning off hardware offload at the ethtool level. However, even with that, I believe that OVS will still try to use it if OVS is configured for hardware offload. It looks like your OVS does have hardware offload enabled. To turn it off, run: ovs-vsctl set Open_vSwitch . other-config:hw-offload=false Then restart OVS and see if it makes a difference. Informace obsažené v této e-mailové zprávě a všech přiložených souborech jsou důvěrné a jsou určeny pouze pro potřebu adresáta. Prosíme, abyste v případě, že tento e-mail obdržíte omylem, neprodleně upozornili odesílatele a tento e-mail odstranili z Vašeho systému. Pokud nejste zamýšleným příjemcem, berte prosím na vědomí, že zveřejnění, kopírování, šíření či přijetí jakéhokoliv opatření v souvislosti s obsahem této zprávy je zakázáno a může být protiprávní. _ The information contained in this e-mail message and all attached files is confidential and is intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is prohibited and may be unlawful. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] ovs does not forward igmp to the interface which set mcast-snooping-flood-reports=true
Hi All I’m using ovs 2.11.3 on CentOS, I enabled multicast snooping on the bridge, I have a vm, and a nic with mcast-snooping-flood-reports=true on this bridge, vm sends igmp packet, but ovs doesn’t forward igmp to the nic. So ovs of other nodes cannot learn multicast table entries. Please feel free to correct me if I understand something wrong, looking forward to your reply. Thanks. ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
