[quagga-dev 13010] VRF implementation with netns breaks quagga for kernels w/o netns
Hello, trying to run the current master tree on OpenWRT I noticed that any Quagga daemon would just exit with code 1. It seems that this has been introduced by this commit: commit 55cfa2f190620f7c711944637659bc208970324d Author: Feng Lu Date: Thu Jul 3 18:24:34 2014 +0800 My understanding of it is this: This commit checks for the presence of the setns system call in the kernel and sets a flag HAVE_NETNS if it is found. If the flag is set at compile time, netns support in the kernel needs to be enabled at runtime. If it is absent, Quagga daemons will just exit with exit(1) from VRF initialization because it fails to open "/proc/self/ns/net". However OpenWRT does not have netns support enabled in its standard configuration, while its kernel headers do provide the API, causing Quagga to be built with the HAVE_NETNS flag set and then failing to run on the target platform. In my opinion and from past experience with code that uses network namespaces, this should not be a compile time decision but something that is decided at runtime. If namespaces can be correctly used at startup use them for VRFs, otherwise fall back. Another option would be to add something like --without-netns to the autoconf, however that would mean that distributions might make the wrong choice for their users. -Christian ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13009] Re: "set comm-list xxx delete", "deny" and "internet"
On Sat, 22 Aug 2015, Chris Hall wrote: While I'm beating this topic to death Not at all. It'd be really good to distil all this into doc/bgpd.texi updates! regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Chris Rumpf wrote: I would like to join this mailing list. you want all of us to give you a call saying you're welcome ?? - e...@home.nl on linux-kernel ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13008] Re: "set comm-list xxx delete", "deny" and "internet"
On Fri, 21 Aug 2015, Chris Hall wrote: On the subject of "set comm-list xxx delete", The Fine Manual (page 61) says: "For communities value deletion, only permit community-list is used. deny community-list is ignored." AFAICS this is true "up to a point". What actually happens is that when a "deny" entry in the community-list matches the communities, processing of the community-list ceases. If the "deny" entry does not match, it is (indeed) ignored. I am not qualified to suggest whether this is a documentation or a code SNAFU... but I guess it does what it does and everybody is used to that ? It'd be good to document this, both the current behaviour and then any improvements, wouldn't it? (I.e. in the documentation). I guess in terms of what we have supported, we have never defiend behaviour when a deny is included, so we ahve some latitude to do whatever is sensible here, including honouring the documentation. ip community-list 120 deny 100:50 ip community-list 120 permit 100:.* may be expected to delete all 100:.* except for 100:50, which looks useful and reasonably obvious ! But I guess it's too late to change Quagga to do that now ? I think we're in undefined land on the deny really. Perhaps it should be ignored, as the docs say. But, whatever works for people - I see Daniel has a patch to make this work in accordance with other implementations? BTW, running "100:.*" through the regular expression engine has the happy, or possibly unhappy, effect of matching (inter alia) 100:10 and 32100:10. I guess that's what everybody expects/wants ? Expected given how regexes work, though perhaps will be unexpected in this context. I think that should be documented, for sure. An option to automatically anchor it might be useful for some? Returning to the Fine Manual, it also says that with this configured: ip community-list standard DEL permit 100:1 100:2 route-map RMAP permit 10 set comm-list DEL delete "value 100:1 and 100:2 is removed"... which doesn't quite capture the subtlety that 100:1 and 100:2 are both removed, iff *both* are present. A patch to make the documentation finer would be good :). In this context, Cisco get twitchy about multiple community values in an "ip community-list" when used with "set comm-list xxx delete", which I have some sympathy with, simplicity-of-semantics-wise. Though it's not clear what happens if you do use an inappropriate "ip community-list", . PS: IMHO, I feel that using a regex for these things is rather like using a machine-pistol to enforce discipline in a kindergarten: it'll probably work, but you may not be completely happy with the result. It lets you implement policies where the community number space is split into different things. Kind of working around a lack of typing. BGP Wide Communities might help fix this and allow thigns to be a bit more structured, maybe. Another possible gotcha is that in the context of a delete, the regexp is applied community by community; while for a general match the regexp is applied to the string form of the entire list of communities. (Possible to think it does community by community in both cases). regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Check me if I'm wrong, Sandy, but if I kill all the golfers... they're gonna lock me up and throw away the key! ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13007] Re: FreeBSD FIBs (was Re: patch reviews, 2)
On 02/09/2015 14:35, Paul Jakma wrote: Further review comments: - HAVE_FIB is a bit too generic. HAVE_FREEBSD_FIB? Yes, +it should include a zebra argv (runtime) option too once we HAVE_FREEBSD_FIB, so it will leave the options to support both modes for FreeBSD: - 1 quagga per FIB - 1 quagga for all fib ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13006] FreeBSD FIBs (was Re: patch reviews, 2)
Hi, (Note: for emails to make it through to quagga-dev you need to subscribe to it via http://lists.quagga.net - if you don't want to receive list email, you can set your subscription to not deliver list mail to you). On Mon, 24 Aug 2015, Baptiste Daroussin wrote: Add support for FreeBSD distinct kernel FIBs https://bugzilla.quagga.net/show_bug.cgi?id=839 VRF integration? Should this be integrated with the VRF ID already being kept somehow? I think there is a need for 2 differents implementations: The one I proposed which is make quagga run in a FIB and respect that FIB. The second would be make quagga handle the fib and in that case yes it would need a VRF implementation. For my use case I did only need the first and it was quite easy to implement. The second would take more time, but I agree in most cases, it would be more interesting for users than the first. I can work later on implementing the second once the first is in. So, one thing I don't quite understand is, if this is appropriate without VRF support, does that mean FreeBSD is sending /all/ interfaces in response to the sysctl, regardless of whether they are appropriate for the FIB the process is running in? If so, isn't that a FreeBSD kernel bug? A kernel network interface virtualisation solution should /not/ require any patches or changes to software to run as it did before, surely? I'm confused why this patch is necessary. If it isn't tying into multi-RIB support, then it shouldn't need a patch - and if a patch is needed, perhaps it should be to fix the FreeBSD kernel? Otherwise, it needs to tie in with the 'front end' VRF state we keep that connects (or will do in some way) to the user UI. Can you explain what's going on a bit more? Is it that the setfib utility, having called 'setfib()' has changed the behaviour of the kernel? So the kernel is using new multi-FIB semantics with 'zebra'? Further review comments: - HAVE_FIB is a bit too generic. HAVE_FREEBSD_FIB? - You described usage to me before (e.g. that setfib utility), that'd be good in the commit message. - The rtread_sysctl.c::route_read change presumably is there to tell the kernel to restrict the read to the given FIB ID. Why doesn't a similar approach work for if_sysctl.c::interface_list? It'd be much nicer to have the sysctl restrict itself to a given FIB ID in constructing the returned interface list, than to then have to issue an ioctl() as every message is parsed, or not? Some comments in the code about how this kernel interface works would be good on this. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Q: What's the difference betweeen USL and the Graf Zeppelin? A: The Graf Zeppelin represented cutting edge technology for its time. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13005] Re: patch reviews, 2
On Wed, 2 Sep 2015, Donald Sharp wrote: Everton Acked the new patch: https://lists.quagga.net/pipermail/quagga-dev/2015-August/013052.html Great. So that's everyone agreed on that round of PIM patches. I'll push those soon. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: We seldom repent talking too little, but very often talking too much. -- Jean de la Bruyere ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13004] Re: patch reviews, 2
Everton Acked the new patch: https://lists.quagga.net/pipermail/quagga-dev/2015-August/013052.html donald On Wed, Sep 2, 2015 at 5:30 AM, Paul Jakma wrote: > On Fri, 21 Aug 2015, Everton Marques wrote: > > PIMD: Create ability to modify hello and hold timers per interface >>> http://patchwork.quagga.net/patch/1290/ >>> https://lists.quagga.net/pipermail/quagga-dev/2015-July/012921.html >>> Outstanding comment from Everton? >>> >> > >>> Yes... >> Everton >> > > Donald reposted a patch on that since. Does that address your comment? > Good to go or ...? > > regards, > -- > Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A > Fortune: > Surprise due today. Also the rent. > ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13003] Re: New OSPF crash Quagga Master (When changing OSPF router-id)
On Sat, 22 Aug 2015, Martin Winter wrote: On 20 Aug 2015, at 6:13, Paul Jakma wrote: So what you're asking is to push a commit at a time, and wait till the CI has run before pushing the next? Yes, when possible. Or at least just bundle related commits together. My goal is still to have some automatic feedback on test results back to list (or maintainer) for each run, but at this time the result still needs too much manual investigation to make sure it’s not a false alarm if things break. This could be tricky. We have to couple the pushing of commits to the running of the CI tool on those commits. Hmm. So the commiter would need to: 1. Push the next minimum set of commits that are needed to build (ideally that'd be 1 commit) 2. Check the CI tool and wait till it has run 3. Go to 1 ? This is the CI at https://ci1.netdef.org/browse/QUAGGA-QMASTER right? Better would be to remember the last head the CI ran on, then after more commits are pulled in, go through each commit and do the CI on each? E.g. if abc123 was the last commit ID, then get the list of more recent commits, checkout and run the CI in that with something like: for COMMIT in $(git rev-list abc123..); do git checkout $COMMIT && runci() || exit ... done Unfortunately not without rewriting the whole CI system (as fas as I know). Atlassian Bamboo (which I use) and Jenkins work in a way that they get triggered by git server telling them that new commits are available or by polling a git server for changes. And they don't support doing something akin to 'git bisect' to find the commit? Surely others must have run into this? Hmm, seems so: https://issues.jenkins-ci.org/browse/JENKINS-12972 https://jira.atlassian.com/browse/SRCTREE-1125 Also, your suggestion would break builds in the rare case where multiple commits need to be tested together to build a working system (not sure if and how often this might happen). Yeah, ideally every commit should be 'golden' and produce a buildable and workign tree. The ideal and reality have a tendency to disagree every now and then though, despite best efforts. ;) regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Experience is not what happens to you; it is what you do with what happens to you. -- Aldous Huxley___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13002] Re: patch reviews, 2
On Fri, 21 Aug 2015, Everton Marques wrote: PIMD: Create ability to modify hello and hold timers per interface http://patchwork.quagga.net/patch/1290/ https://lists.quagga.net/pipermail/quagga-dev/2015-July/012921.html Outstanding comment from Everton? Yes... Everton Donald reposted a patch on that since. Does that address your comment? Good to go or ...? regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Surprise due today. Also the rent. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
