Re: [openstack-dev] [neutron][linux bridge]
Hello, What about tc_lib.py and function to set bandwidth limits which linuxbridge agent is currently using? -- Best regards / Pozdrawiam Sławek Kapłoński sla...@kaplonski.pl On Thu, 07 Jul 2016, Bhatia, Manjeet S wrote: > Hi, > > There is work in progress for pure python driven linux network configuration. > I think most > of work will be done with this patch https://review.openstack.org/#/c/155631/ > . The only > thing left after this will be linux bridge configuration, Which I would like > to discuss with > community. There are two ways at the moment I can think to do that > implementation, > First, use pybrctl which may need some changes in library itself in order for > full support. > It will clean up the code from neutron. But looking pybrctl code which is > just executing > Shell commands, another solution which Brandon Logan discussed is move the > existing > Code for executing those commands to neutron-lib, which I think is better > solution. I would > like to have views of community, especially people working neutron-lib about > moving > python code for executing brctl commands to neutron-lib. > > > Thanks and Regards ! > Manjeet Singh Bhatia > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][linux bridge]
Hi, I'm not close to Neutron's discussions but do you think to have a look at pyroute2 [1]? "Pyroute2 is a pure Python netlink and Linux network configuration library. It requires only Python stdlib, no 3rd party libraries." Which permits to create bridge and adding interfaces easily [2] (but not only...). [1] https://github.com/svinota/pyroute2 [2] https://github.com/svinota/pyroute2/blob/a76d2efd8966ec5b6cc713dc5d909b5cd070a9a8/benchmark/ipdb.py#L16 On Fri, Jul 8, 2016 at 8:05 AM, Brandon Logan wrote: > pybrctl repo is at: https://github.com/udragon/pybrctl > It is in pypi. > > Looks like a wrapper around the shell brctl commands. I don't think it > would buy us anything more than what moving neutron's current > implementation of doing brctl commands to neutron-lib would do. In > fact, it might end up costing more. That's just my very uninformed > opinion though. > > Thanks, > Brandon > > On Thu, 2016-07-07 at 23:59 +, Bhatia, Manjeet S wrote: > > Hi, > > > > There is work in progress for pure python driven linux network > > configuration. I think most > > of work will be done with this patch https://review.openstack.org/#/c > > /155631/ . The only > > thing left after this will be linux bridge configuration, Which I > > would like to discuss with > > community. There are two ways at the moment I can think to do that > > implementation, > > First, use pybrctl which may need some changes in library itself in > > order for full support. > > It will clean up the code from neutron. But looking pybrctl code > > which is just executing > > Shell commands, another solution which Brandon Logan discussed is > > move the existing > > Code for executing those commands to neutron-lib, which I think is > > better solution. I would > > like to have views of community, especially people working neutron- > > lib about moving > > python code for executing brctl commands to neutron-lib. > > > > > > Thanks and Regards ! > > Manjeet Singh Bhatia > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][linux bridge]
pybrctl repo is at: https://github.com/udragon/pybrctl It is in pypi. Looks like a wrapper around the shell brctl commands. I don't think it would buy us anything more than what moving neutron's current implementation of doing brctl commands to neutron-lib would do. In fact, it might end up costing more. That's just my very uninformed opinion though. Thanks, Brandon On Thu, 2016-07-07 at 23:59 +, Bhatia, Manjeet S wrote: > Hi, > > There is work in progress for pure python driven linux network > configuration. I think most > of work will be done with this patch https://review.openstack.org/#/c > /155631/ . The only > thing left after this will be linux bridge configuration, Which I > would like to discuss with > community. There are two ways at the moment I can think to do that > implementation, > First, use pybrctl which may need some changes in library itself in > order for full support. > It will clean up the code from neutron. But looking pybrctl code > which is just executing > Shell commands, another solution which Brandon Logan discussed is > move the existing > Code for executing those commands to neutron-lib, which I think is > better solution. I would > like to have views of community, especially people working neutron- > lib about moving > python code for executing brctl commands to neutron-lib. > > > Thanks and Regards ! > Manjeet Singh Bhatia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][linux bridge]
Hi, There is work in progress for pure python driven linux network configuration. I think most of work will be done with this patch https://review.openstack.org/#/c/155631/ . The only thing left after this will be linux bridge configuration, Which I would like to discuss with community. There are two ways at the moment I can think to do that implementation, First, use pybrctl which may need some changes in library itself in order for full support. It will clean up the code from neutron. But looking pybrctl code which is just executing Shell commands, another solution which Brandon Logan discussed is move the existing Code for executing those commands to neutron-lib, which I think is better solution. I would like to have views of community, especially people working neutron-lib about moving python code for executing brctl commands to neutron-lib. Thanks and Regards ! Manjeet Singh Bhatia __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Linux Bridge CI is now a voting gate job
On 9 December 2015 at 03:53, Sean Dague wrote: > On 12/07/2015 04:05 PM, Sean M. Collins wrote: > > It's been a couple months - the last time I posted on this subject we > > were still working on getting Linux Bridge to become an experimental[1] > > job. During the Liberty cycle, the Linux Bridge CI was promoted from > > experimental status, to being run on all Neutron changes, but > > non-voting. > > > > Well, we're finally at the point where the Linux Bridge job is > > gating[2]. I am sure there are still bugs that will need to be addressed > > - I will be watching the gate very carefully the next couple of hours > > and throughout this week. > > > > Feel free to leave bags of flaming :poo: at my doorstep > > > > On a serious note, thank you to everyone who over this year has > > committed patches and fixes to make this happen, it's been an amazing > > example of open source and community involvement. I'll be happy to buy > > drinks if you helped with LB in San Antonio if there is a neutron social > > event (in addition to paying back amotoki for the Tokyo social). > > > > [1]: > http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html > > [2]: https://review.openstack.org/205674 > > > > Nicely done! Thanks much! > Don't want to be a party pooper but I added the job failure rate to the dashboard [1], and the result so far is not pleasing. Hopefully this is due to a failure tail fixed in [2]. Cheers, Armando [1] https://review.openstack.org/#/c/255588/ [2] https://review.openstack.org/#/c/252493/ > -Sean > > -- > Sean Dague > http://dague.net > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Linux Bridge CI is now a voting gate job
On 12/07/2015 04:05 PM, Sean M. Collins wrote: > It's been a couple months - the last time I posted on this subject we > were still working on getting Linux Bridge to become an experimental[1] > job. During the Liberty cycle, the Linux Bridge CI was promoted from > experimental status, to being run on all Neutron changes, but > non-voting. > > Well, we're finally at the point where the Linux Bridge job is > gating[2]. I am sure there are still bugs that will need to be addressed > - I will be watching the gate very carefully the next couple of hours > and throughout this week. > > Feel free to leave bags of flaming :poo: at my doorstep > > On a serious note, thank you to everyone who over this year has > committed patches and fixes to make this happen, it's been an amazing > example of open source and community involvement. I'll be happy to buy > drinks if you helped with LB in San Antonio if there is a neutron social > event (in addition to paying back amotoki for the Tokyo social). > > [1]: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html > [2]: https://review.openstack.org/205674 > Nicely done! Thanks much! -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Linux Bridge CI is now a voting gate job
On 12/08/2015 07:54 PM, Andreas Scheuring wrote: Great work! Indeed, Sean, fantastic effort getting this done. :) -jay On Mo, 2015-12-07 at 21:05 +, Sean M. Collins wrote: >It's been a couple months - the last time I posted on this subject we >were still working on getting Linux Bridge to become an experimental[1] >job. During the Liberty cycle, the Linux Bridge CI was promoted from >experimental status, to being run on all Neutron changes, but >non-voting. > >Well, we're finally at the point where the Linux Bridge job is >gating[2]. I am sure there are still bugs that will need to be addressed >- I will be watching the gate very carefully the next couple of hours >and throughout this week. > >Feel free to leave bags of flaming :poo: at my doorstep > >On a serious note, thank you to everyone who over this year has >committed patches and fixes to make this happen, it's been an amazing >example of open source and community involvement. I'll be happy to buy >drinks if you helped with LB in San Antonio if there is a neutron social >event (in addition to paying back amotoki for the Tokyo social). > >[1]:http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html >[2]:https://review.openstack.org/205674 > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Linux Bridge CI is now a voting gate job
Great work! -- Andreas (IRC: scheuran) On Mo, 2015-12-07 at 21:05 +, Sean M. Collins wrote: > It's been a couple months - the last time I posted on this subject we > were still working on getting Linux Bridge to become an experimental[1] > job. During the Liberty cycle, the Linux Bridge CI was promoted from > experimental status, to being run on all Neutron changes, but > non-voting. > > Well, we're finally at the point where the Linux Bridge job is > gating[2]. I am sure there are still bugs that will need to be addressed > - I will be watching the gate very carefully the next couple of hours > and throughout this week. > > Feel free to leave bags of flaming :poo: at my doorstep > > On a serious note, thank you to everyone who over this year has > committed patches and fixes to make this happen, it's been an amazing > example of open source and community involvement. I'll be happy to buy > drinks if you helped with LB in San Antonio if there is a neutron social > event (in addition to paying back amotoki for the Tokyo social). > > [1]: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html > [2]: https://review.openstack.org/205674 > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Linux Bridge CI is now a voting gate job
It's been a couple months - the last time I posted on this subject we were still working on getting Linux Bridge to become an experimental[1] job. During the Liberty cycle, the Linux Bridge CI was promoted from experimental status, to being run on all Neutron changes, but non-voting. Well, we're finally at the point where the Linux Bridge job is gating[2]. I am sure there are still bugs that will need to be addressed - I will be watching the gate very carefully the next couple of hours and throughout this week. Feel free to leave bags of flaming :poo: at my doorstep On a serious note, thank you to everyone who over this year has committed patches and fixes to make this happen, it's been an amazing example of open source and community involvement. I'll be happy to buy drinks if you helped with LB in San Antonio if there is a neutron social event (in addition to paying back amotoki for the Tokyo social). [1]: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html [2]: https://review.openstack.org/205674 -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Linux Bridge CI status report
As of Jul 27 2015 - we are currently passing 85% of the time on the LB CI job. There are some legitimate failures on patches where LB was the dissenting job, meaning there was most likely a bug in the LB code or job. I've listed the runs where the Linux Bridge CI job under L32 of this etherpad - I plan to drill down into the logs and see if we can classify the failures. https://etherpad.openstack.org/p/devstack-linuxbridge Basically the 85% stat is for just today since the 48 hour query in Kibana includes the weekend, where not a lot of traffic occurs - however using a small sample allows me to filter the failures by hand, and classify patches that failed multiple CI jobs, meaning the patch was probably flawed, versus patches that *should* have passed the LB CI. Also, I have backported some DevStack patches to the stable/kilo branch to enable the Linux Bridge CI job to successfully run on patches against that branch, which has improved the overall success rate since there were recently patches against stable/kilo due to an upcoming release. Ideally, I'd like to see the following backport approved, however I don't think it warrants a freeze exception. https://review.openstack.org/202845 Also, if we could get some core reviewers to look at the following, it would be much appreciated. https://review.openstack.org/193485 Overall, I'm very happy with the stats so far, and have a WIP patch to make the LB job voting. I think after we get 202845 merged and maybe get up into the 90% success rate I'll take off the WIP and solicit feedback https://review.openstack.org/205674 -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Linux Bridge CI status report
This is great work! I see most of the devstack patches have now merged, and the Neutron ones are merging to. On Wed, Jul 8, 2015 at 5:37 AM, Sean Dague wrote: > Nice job all! Really awesome. I just approved 195653, so it will show up > in the check queue non voting shortly. > > -Sean > > On 07/07/2015 10:01 PM, Sean M. Collins wrote: > > Hi, > > > > At the risk of jinxing it, I'd like to report that with the merge of a > > couple patches to fix race conditions[1][2] and DevStack[3] - we're > looking > > at promising results for experimental runs for the Linux Bridge > > CI on changes that are supposed to pass[4], as well as being useful for > > patches under development[5][6]. > > > > It's still early, but I think we've made great progress so far, and my > > plan is in the next week or so to see if we can move it from > > experimental status, to the check queue (but keep it non-voting)[7]. > This will > > help uncover any other bugs that exist, as well as helping provide a CI > system > > that can help give certainty for reviewers on patches > > to Neutron in the Linux Bridge parts of the tree. > > > > I'd also like to thank the bug reporters and authors of > > of the linked patches - since most of what I did was just nudge > > things along. > > > > [1]: https://review.openstack.org/#/c/198833/ > > > > [2]: https://review.openstack.org/#/c/197162/ > > > > [3]: https://review.openstack.org/#/c/192906/ > > > > [4]: https://review.openstack.org/#/c/187235/ > > > > [5]: https://review.openstack.org/196986 > > > > [6]: https://review.openstack.org/#/c/138512/ > > > > [7]: https://review.openstack.org/#/c/195653/ > > > > > -- > Sean Dague > http://dague.net > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Linux Bridge CI status report
Nice job all! Really awesome. I just approved 195653, so it will show up in the check queue non voting shortly. -Sean On 07/07/2015 10:01 PM, Sean M. Collins wrote: > Hi, > > At the risk of jinxing it, I'd like to report that with the merge of a > couple patches to fix race conditions[1][2] and DevStack[3] - we're looking > at promising results for experimental runs for the Linux Bridge > CI on changes that are supposed to pass[4], as well as being useful for > patches under development[5][6]. > > It's still early, but I think we've made great progress so far, and my > plan is in the next week or so to see if we can move it from > experimental status, to the check queue (but keep it non-voting)[7]. This will > help uncover any other bugs that exist, as well as helping provide a CI system > that can help give certainty for reviewers on patches > to Neutron in the Linux Bridge parts of the tree. > > I'd also like to thank the bug reporters and authors of > of the linked patches - since most of what I did was just nudge > things along. > > [1]: https://review.openstack.org/#/c/198833/ > > [2]: https://review.openstack.org/#/c/197162/ > > [3]: https://review.openstack.org/#/c/192906/ > > [4]: https://review.openstack.org/#/c/187235/ > > [5]: https://review.openstack.org/196986 > > [6]: https://review.openstack.org/#/c/138512/ > > [7]: https://review.openstack.org/#/c/195653/ > -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Linux Bridge CI status report
On 07/07/2015 10:13 PM, Doug Wiegley wrote: > Great work. > > Doug Piling in on Doug's post, great work here Sean. Anita. > > >> On Jul 7, 2015, at 8:01 PM, Sean M. Collins wrote: >> >> Hi, >> >> At the risk of jinxing it, I'd like to report that with the merge of a >> couple patches to fix race conditions[1][2] and DevStack[3] - we're looking >> at promising results for experimental runs for the Linux Bridge >> CI on changes that are supposed to pass[4], as well as being useful for >> patches under development[5][6]. >> >> It's still early, but I think we've made great progress so far, and my >> plan is in the next week or so to see if we can move it from >> experimental status, to the check queue (but keep it non-voting)[7]. This >> will >> help uncover any other bugs that exist, as well as helping provide a CI >> system >> that can help give certainty for reviewers on patches >> to Neutron in the Linux Bridge parts of the tree. >> >> I'd also like to thank the bug reporters and authors of >> of the linked patches - since most of what I did was just nudge >> things along. >> >> [1]: https://review.openstack.org/#/c/198833/ >> >> [2]: https://review.openstack.org/#/c/197162/ >> >> [3]: https://review.openstack.org/#/c/192906/ >> >> [4]: https://review.openstack.org/#/c/187235/ >> >> [5]: https://review.openstack.org/196986 >> >> [6]: https://review.openstack.org/#/c/138512/ >> >> [7]: https://review.openstack.org/#/c/195653/ >> -- >> Sean M. Collins >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Linux Bridge CI status report
Great work. Doug > On Jul 7, 2015, at 8:01 PM, Sean M. Collins wrote: > > Hi, > > At the risk of jinxing it, I'd like to report that with the merge of a > couple patches to fix race conditions[1][2] and DevStack[3] - we're looking > at promising results for experimental runs for the Linux Bridge > CI on changes that are supposed to pass[4], as well as being useful for > patches under development[5][6]. > > It's still early, but I think we've made great progress so far, and my > plan is in the next week or so to see if we can move it from > experimental status, to the check queue (but keep it non-voting)[7]. This will > help uncover any other bugs that exist, as well as helping provide a CI system > that can help give certainty for reviewers on patches > to Neutron in the Linux Bridge parts of the tree. > > I'd also like to thank the bug reporters and authors of > of the linked patches - since most of what I did was just nudge > things along. > > [1]: https://review.openstack.org/#/c/198833/ > > [2]: https://review.openstack.org/#/c/197162/ > > [3]: https://review.openstack.org/#/c/192906/ > > [4]: https://review.openstack.org/#/c/187235/ > > [5]: https://review.openstack.org/196986 > > [6]: https://review.openstack.org/#/c/138512/ > > [7]: https://review.openstack.org/#/c/195653/ > -- > Sean M. Collins > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Linux Bridge CI status report
Hi, At the risk of jinxing it, I'd like to report that with the merge of a couple patches to fix race conditions[1][2] and DevStack[3] - we're looking at promising results for experimental runs for the Linux Bridge CI on changes that are supposed to pass[4], as well as being useful for patches under development[5][6]. It's still early, but I think we've made great progress so far, and my plan is in the next week or so to see if we can move it from experimental status, to the check queue (but keep it non-voting)[7]. This will help uncover any other bugs that exist, as well as helping provide a CI system that can help give certainty for reviewers on patches to Neutron in the Linux Bridge parts of the tree. I'd also like to thank the bug reporters and authors of of the linked patches - since most of what I did was just nudge things along. [1]: https://review.openstack.org/#/c/198833/ [2]: https://review.openstack.org/#/c/197162/ [3]: https://review.openstack.org/#/c/192906/ [4]: https://review.openstack.org/#/c/187235/ [5]: https://review.openstack.org/196986 [6]: https://review.openstack.org/#/c/138512/ [7]: https://review.openstack.org/#/c/195653/ -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Linux Bridge MTU bug when the VXLAN tunneling is used
I had a look for fix that and I don't found a simple way. The minimal MTU can be deducted by the LB agent with the value found on the bridge and the LB agent can set it on veth interface connect to that bridge. But there no easy way to set it on the other side of the veth in the namespace. LB agent doesn't know the name of the other side of the veth and it doesn't know the name of the namespace. Furthermore, I'm not sure it's a good way to modify network in a namespace doesn't manage by the LB agent. Another simple solution, is to set a global config flag to define the minimal MTU and all agents which create veth use it to set interfaces MTU. I opened a bug to discuss: https://bugs.launchpad.net/neutron/+bug/1242534 Regards, Édouard. On Sun, Oct 20, 2013 at 5:29 PM, Salvatore Orlando wrote: > It might be worth both documenting this limitation on the admin guide and > provide a fix which we should backport to havana too. > It sounds like the fix should not be too extensive, so the backport should > be easily feasible. > > Regards, > Salvatore > > > On 18 October 2013 21:50, Édouard Thuleau wrote: > >> Hi all, >> >> I made some tests with the ML2 plugin and the Linux Bridge agent with >> VXLAN tunneling. >> >> By default, physical interface (used for VXLAN tunneling) has an MTU of >> 1500 octets. And when LB agent creates a VXLAN interface, the MTU is >> automatically 50 octets less than the physical interface (so 1450 octets) >> [1]. Therefore, the bridge use to plug tap of VM, veth from network >> namespaces (l3 or dhcp) and VXLAN interface has an MTU of 1450 octets >> (Linux bridges take minimum of all the underlying ports [2]). >> >> So the bridge could only forward packets of length smaller than 1450 >> octets to VXLAN interface [3]. >> >> But the veth interfaces used to link network namespaces and bridges are >> spawn by l3 and dhcp agents (and perhaps other agents) with an MTU of 1500 >> octets. So, packets which arriving from them are dropped if they need to be >> forwarded to the VXLAN interface. >> >> A simple workaround is to increase by 50 at least the MTU of the physical >> interface to harmonize MTU between interfaces. But by default (without MTU >> customizing), the LB/VXLAN mode have strange behavior (cannot make curl >> from server behind a router or execute command with verbose output in SSH >> through a floating IP (SSH connection works)...) >> >> So my question is, do you think we need to open a bug and find a fix for >> that ? Or do we need to put warning in docs (and logs perhaps)? >> >> [1] >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/vxlan.c#n2437 >> [2] >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_if.c#n402 >> [3] >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_forward.c#n74 >> >> Édouard. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Linux Bridge MTU bug when the VXLAN tunneling is used
It might be worth both documenting this limitation on the admin guide and provide a fix which we should backport to havana too. It sounds like the fix should not be too extensive, so the backport should be easily feasible. Regards, Salvatore On 18 October 2013 21:50, Édouard Thuleau wrote: > Hi all, > > I made some tests with the ML2 plugin and the Linux Bridge agent with > VXLAN tunneling. > > By default, physical interface (used for VXLAN tunneling) has an MTU of > 1500 octets. And when LB agent creates a VXLAN interface, the MTU is > automatically 50 octets less than the physical interface (so 1450 octets) > [1]. Therefore, the bridge use to plug tap of VM, veth from network > namespaces (l3 or dhcp) and VXLAN interface has an MTU of 1450 octets > (Linux bridges take minimum of all the underlying ports [2]). > > So the bridge could only forward packets of length smaller than 1450 > octets to VXLAN interface [3]. > > But the veth interfaces used to link network namespaces and bridges are > spawn by l3 and dhcp agents (and perhaps other agents) with an MTU of 1500 > octets. So, packets which arriving from them are dropped if they need to be > forwarded to the VXLAN interface. > > A simple workaround is to increase by 50 at least the MTU of the physical > interface to harmonize MTU between interfaces. But by default (without MTU > customizing), the LB/VXLAN mode have strange behavior (cannot make curl > from server behind a router or execute command with verbose output in SSH > through a floating IP (SSH connection works)...) > > So my question is, do you think we need to open a bug and find a fix for > that ? Or do we need to put warning in docs (and logs perhaps)? > > [1] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/vxlan.c#n2437 > [2] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_if.c#n402 > [3] > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_forward.c#n74 > > Édouard. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Linux Bridge MTU bug when the VXLAN tunneling is used
Hi all, I made some tests with the ML2 plugin and the Linux Bridge agent with VXLAN tunneling. By default, physical interface (used for VXLAN tunneling) has an MTU of 1500 octets. And when LB agent creates a VXLAN interface, the MTU is automatically 50 octets less than the physical interface (so 1450 octets) [1]. Therefore, the bridge use to plug tap of VM, veth from network namespaces (l3 or dhcp) and VXLAN interface has an MTU of 1450 octets (Linux bridges take minimum of all the underlying ports [2]). So the bridge could only forward packets of length smaller than 1450 octets to VXLAN interface [3]. But the veth interfaces used to link network namespaces and bridges are spawn by l3 and dhcp agents (and perhaps other agents) with an MTU of 1500 octets. So, packets which arriving from them are dropped if they need to be forwarded to the VXLAN interface. A simple workaround is to increase by 50 at least the MTU of the physical interface to harmonize MTU between interfaces. But by default (without MTU customizing), the LB/VXLAN mode have strange behavior (cannot make curl from server behind a router or execute command with verbose output in SSH through a floating IP (SSH connection works)...) So my question is, do you think we need to open a bug and find a fix for that ? Or do we need to put warning in docs (and logs perhaps)? [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/vxlan.c#n2437 [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_if.c#n402 [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_forward.c#n74 Édouard. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev