The BGP MED (Multi_Exit_Discriminator) attribute has properties which can cause subtle convergence problems in BGP. These properties and problems have proven to be hard to understand, at least historically, and may still not be widely understood. The following attempts to collect together and present what is known about MED, to help operators and Quagga users in designing and configuring their networks.
Archive for Quagga
Update: Seems I can’t read – the outage possibly could be prolonged, but should not be permanent. The provider is working on the issues (power problems affecting the rack). We don’t have an immediate need for hosting, however a dual-disk caddy for a T1000 would still be ultra-useful. Thanks!
There’s been a major outage of Quagga.net services. The hosting provider has literally had to pull the plug for emergency reasons. It doesn’t look like service at that provider will be restored on any permanent basis. We’re currently looking for someone willing to sponsor costs for some or all of the following:
- Server hosted on a commercial basis with:
- Remote serial console
- Remote power-switch
- KVM support
- 80GB or more of redundant storage
- Hosting of a Sun T1000, ideally with:
- Shipping costs paid for from Belgium
- Existing single-disk upgraded to Sun dual-disk (this would obviate need for former server)
This would of course have to happen just as I’m away on holiday for 3 weeks, with only limited internet access.
If you think you can help, please leave a comment with your email.
Euro-IX is looking to sponsor Quagga development. This was announced by Nick Hilliard in a post to the quagga-dev list. This is really great to see and I commend Euro-IX for providing these resources for Quagga.
- If you don’t know git, take a day or two to learn (it’s not that hard, and the gitk and git-gui GUI tools can help a lot)
- Read through the existing commit messages to get a feel for the common style – and try use this style in your own commit messages:
- A one-line summary as the 1st line of the commit message. You may wish to start it with ‘applicability:’, e.g. ‘bgpd:’, ‘netlink:’, ‘freebsd:’, etc. This is used for release announcements.
- The body of the commit message, containing a high-level description of the goal of the changes, including the problem being addressed and the reasoning for the commit, on a change by change basis (e.g. per file, even per-function, if that’s appropriate). For a large commit, an introductory overview may be needed.The goal is two-fold: To force the submitter to perform a self-review of the commit (and so catch problems); and to give the reader the required context to review the commit.
- An honest indication of the confidence you have in the patch, including what, if any testing has been done.
- If the patch contains work done by others, e.g. because it is a rework of some other patch, indicate this. Though, ideally, the original patch should be a separate commit, attributed correctly with the –author argument to git-commit.
- Read the HACKING document (parts are out of date though)
- Prepare a branch, based on the Quagga.net master, that contains your changes and nothing else (merges from master are ok; if you need to merge it together with other things for your own purposes, then use another branch – they’re cheap).
- If you like to rebase published branches, please name-space such branches with a ‘volatile/’ prefix.
- Order the commits so the that the safest, least-contraversial commits are earlier in the branch than patches that are less likely to be mergeable. This allows maintainers to, perhaps, still be able to pull part of your branch if some patches are deemed problematic.
- If you have a large and/or less-obviously-safe patch, try to split the patch up into smaller ones. E.g. there may be infrastructural improvements that can be factored out and go in first.
It’s extremely rare that contributors do all of the above. Commit messages in particular are often free-form. Sometimes they describe the problem, but not why the change fixes it. Sometimes the change is described, but without reference to the problem. Sometimes the message is akin to a C-to-english transliteration.
It might seem like a pain to force submitters to spend 5 to 10 minutes to go through their patch and construct a structured, detailed, but high-level description of their patch and their intent. However not doing so forces the reviewer to spend even more time to mentally construct the same. If you have many contributors feeding patches to a small number of maintainers, then it just doesn’t scale unless contributors make an effort to make their patches as reviewable and easy-to-integrate as possible.
In short, try to make life easy for your maintainer. There are several small, maybe even apparently trivial, things you can do quite easily which help reduce their load, and help smooth your patches’ path.
Updates: Git strips out ’s, so change section recommending patch subjects encode information in them.
I will be working on Quagga full-time, hopefully for the whole summer, thanks to sponsorhip from Vyatta.
The plan is, amongst other things, to get through the outstanding queue of patches and get at least 2 releases out, with a good, well-tested and stable release toward the latter part of the summer.