[quagga-dev 12903] Re: Question about Not allowing outside programs to remove Quagga routes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1
On 2015-07-30 16:06, Vincent JARDIN wrote:
> +1
>
> When a FIB manager is the author/owner of a route, it must be
> trusted. Since the kernels (BSD, Linux) do not provide any means(*)
> from preventing 3rd parties from removing such routes, let's add
> them again like you are doing with this patch.
>
> However, since it changes some behaviours, I feel it requires a
> argv + CLI command in order to disable this behaviour. I agree that
> your proposal should be the default behavior.
>
> About the patch: - the git log is not good enough, your email is
> better - zlog_debug ("Zebra route %s/%d was deleted by others from
> kernel", -> it should be a warning, not a debug function to be
> displayed anytimes it happens. - INET6 is missing.
>
> On 30/07/2015 14:37, Donald Sharp wrote:
>> In a private discussion with David Lamparter, we discussed this
>> patch:
>>
>> https://github.com/CumulusNetworks/quagga/commit/8b27eb162a9048498f2f87e4ae60b9a6ae62941b
>>
>>
>>
This patch changes the behavior of Quagga to reinstall routes, that were
>> sourced from Quagga, back into the kernel if a route delete is
>> received. David felt that this behavior was enough of a change
>> that it should be brought to the list for discussion/decision.
>> The whole crux of the decision revolves around the question 'Who
>> is the source of truth for routes?'. We've written this patch
>> because we believe that the answer to this question is that
>> Quagga is the source of truth of routes if it is being run.
>>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJVumEkAAoJECwqsKluDEdYc4EIAIFu/iwIOcCre5/M6NcfhsGS
prxcgK2iWGMqfECY7jKB3twHt7y22IgK7+PaOTe9By1nrJ9HuPxuoIQVZ3/E3QlY
wScbzmhAPWt2/1O2h5SKS6QighiY2uoLlyWE1OqIeCcVhp3hO4WFzLv8oUVDrG23
mFTDEvNAGsXbvQiksDYpDBFNWiFsjikwLLo2W0l1GP4HQIY3ekzr3rczBK3bSmv/
vba7bnCow/YH8C7XwAETFFLo7/S3NZM0rhis5pKzDq5pFcqrD1NaHRzCBlvjO1ju
ddNtEMjU0dOyK6rn6K54NY9J+RaA1aCdNNCPWAGwJ1KPzf1dlC08r6Nq2p5jUyo=
=GmSe
-END PGP SIGNATURE-
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12902] Re: Fast OSPF convergence
On 7/27/2015 2:14 PM, Michael Rossberg wrote:
Hi,
This is a great idea, thanks for the implementation!
I am happy if someone finds it useful.
struct timeval
+msec2tv (int a)
+{
+ struct timeval ret;
+
+ ret.tv_sec = 0;
+ ret.tv_usec = a * 1000;
+
+ return tv_adjust (ret);
+}
I'm not a very big fan of returning local static information in msec2tv. I
would prefer that you pass in the struct timeval * that you want filled in.
Otherwise you are going to get some very weird behavior when someone down the
line missappropriates the msec2tv and calls it twice and expects the output to
stay consistent. Additionally if someone ever adds another thread it will
misbehave as well.
Please note that the value is returned by copy and not by reference to a static
or
global variable. Hence, it should work perfectly in multithreaded environments
or
over multiple calls. It may not be the fastest, but struct timeval is small.
Donald,
You were not alone, I had the same thought when I first looked at the
code. Returning a struct instead of a pointer has been always considered
a "sin" to the point where I even forgot it is possible and well
defined. As Michael pointed out, every time you call the function a copy
is created and passed up to the caller where it is (generally speaking)
stored in a stack variable. Memory management is avoided in this case at
the cost of speed. Since timeval is only a couple of integers probably,
it is not too bad and you keep the code simple. Like you suggested, I
always pass a pointer from the caller when dealing with a situation like
this.
Michael, Thanks for implementing this!
Cheers,
Jafar
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12901] Re: Question about Not allowing outside programs to remove Quagga routes
+1
When a FIB manager is the author/owner of a route, it must be trusted.
Since the kernels (BSD, Linux) do not provide any means(*) from
preventing 3rd parties from removing such routes, let's add them again
like you are doing with this patch.
However, since it changes some behaviours, I feel it requires a argv +
CLI command in order to disable this behaviour. I agree that your
proposal should be the default behavior.
About the patch:
- the git log is not good enough, your email is better
- zlog_debug ("Zebra route %s/%d was deleted by others from kernel",
-> it should be a warning, not a debug function to be displayed anytimes
it happens.
- INET6 is missing.
Best regards,
On 30/07/2015 14:37, Donald Sharp wrote:
In a private discussion with David Lamparter, we discussed this patch:
https://github.com/CumulusNetworks/quagga/commit/8b27eb162a9048498f2f87e4ae60b9a6ae62941b
This patch changes the behavior of Quagga to reinstall routes, that were
sourced from Quagga, back into the kernel if a route delete is
received. David felt that this behavior was enough of a change that it
should be brought to the list for discussion/decision. The whole crux
of the decision revolves around the question 'Who is the source of truth
for routes?'. We've written this patch because we believe that the
answer to this question is that Quagga is the source of truth of routes
if it is being run.
Finally David also had some questions about how this could be done on
BSD as well.
thoughts?
thanks!
donald
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12900] Re: Outstanding patches & accepted
Hello Paul, Le 30/07/2015 11:58, Paul Jakma a écrit : On Thu, 30 Jul 2015, olivier.dug...@orange.com wrote: [ ... snip ...] Sorry for the delay on this. Possibly a bit frustrating for you I'll concede, but if it's any re-assurance it's actually cause I think it's cause your patch is quite important. I also might not have much bandwidth myself on this for the next month, after that should do. No problem. My concern is that TE patches will be well included in the next Quagga release. I have already missed the last release while my original patches have been submitted several months before. I would not that same thing occurs one more time. Regards Olivier regards, _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12899] Question about Not allowing outside programs to remove Quagga routes
In a private discussion with David Lamparter, we discussed this patch: https://github.com/CumulusNetworks/quagga/commit/8b27eb162a9048498f2f87e4ae60b9a6ae62941b This patch changes the behavior of Quagga to reinstall routes, that were sourced from Quagga, back into the kernel if a route delete is received. David felt that this behavior was enough of a change that it should be brought to the list for discussion/decision. The whole crux of the decision revolves around the question 'Who is the source of truth for routes?'. We've written this patch because we believe that the answer to this question is that Quagga is the source of truth of routes if it is being run. Finally David also had some questions about how this could be done on BSD as well. thoughts? thanks! donald ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12898] Re: Outstanding patches & accepted
On Thu, 30 Jul 2015, olivier.dug...@orange.com wrote: Hello Paul, I'm concern by the next round of patch i.e. LLS-TE. The status is as follow: - I sent on the mailing list 2 patches on top of the LLS-TE git repo to add consistent checking of new value for link parameters and to add bitfield to determine if a link parameter value is set or not independantly of its value. Do you review and apply these 2 patches ? I've not looked yet, but will soon. - For me, only update of documentation according to the new CLI command is needed. I'll be off 3 weeks for holidays tomorrow evening. So, let me know quickly if you needdocumentation updateor others information/code. I don't think I need any thing as such. Sorry for the delay on this. Possibly a bit frustrating for you I'll concede, but if it's any re-assurance it's actually cause I think it's cause your patch is quite important. I also might not have much bandwidth myself on this for the next month, after that should do. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: If there is no wind, row. -- Polish proverb ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12897] Re: Outstanding patches & accepted
Hello Paul, I'm concern by the next round of patch i.e. LLS-TE. The status is as follow: - I sent on the mailing list 2 patches on top of the LLS-TE git repo to add consistent checking of new value for link parameters and to add bitfield to determine if a link parameter value is set or not independantly of its value. Do you review and apply these 2 patches ? - For me, only update of documentation according to the new CLI command is needed. I'll be off 3 weeks for holidays tomorrow evening. So, let me know quickly if you needdocumentation updateor others information/code. Regards, Olivier Le 29/07/2015 23:23, Paul Jakma a écrit : Hi, Catching up. Round 1 of proposed patches: http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile/patch-tracking/1/proposed/ff Those are from Vincent's dig into patchwork in: https://lists.quagga.net/pipermail/quagga-dev/2015-June/012751.html Plus a few I'd gotten on the list. - Pw 1249 does not apply cleanly. - 410 is nacked according to Vincent - 537 was nacked by Vincent, but I suggested it should probably be applied no pushback on that? - 1248, Donald was to get back on that? (Also, there was a branch with a few reworks of PIM/multicast changes?) - a Linux rt-realms patch, which seems to have been created ages ago and maintenance passed along a few different people (I think my commit message is still missing some of the patch archeology). I don't want to reject this, but I don't want to apply it as is either. I'm concerned how it fits in generally, and also about whether the patch is doing the right thing in having 2 commands (neighbour and rmap) to set the realm. (I see also some updates later). Assuming 537 can go in, 410 is nacked, and the realms patch isn't ready, then this is what will get ff-pulled into master: http://git.savannah.gnu.org/cgit/quagga.git/log/?h=volatile/patch-tracking/1/accepted Next round, once above is settled/closed, the list can consider and review: - carry forward realms from previous, with updates - There is a FreeBSD multiple-FIB patch in bugzilla - LLS-TE (blocked on me at the moment though) - More patchwork cleaning from Vincent: https://lists.quagga.net/pipermail/quagga-dev/2015-June/012788.html - I'll hoover anything since the last round on-list into a branch for review - 1248 from above, and other multicast/pim - NHRP - Anyone want to do more patchwork diving? regards, _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12896] Re: Outstanding patches & accepted
Hi, On Wed, 29 Jul 2015, Donald Sharp wrote: 1249 - I'll resend it in the next day or so. I'm surprised it doesn't apply? Probably trivial. I'll see if I can tweak it so. 1248 - I sent an update with the changes Vincent wanted. Here is the pointer to it: https://lists.quagga.net/pipermail/quagga-dev/2015-June/012756.html Ah, cool. The multicast pim branch changes I made is here: https://github.com/CumulusNetworks/quagga/tree/pimd_fixings - The https://github.com/CumulusNetworks/quagga/commit/058c3235e067713b999417a552cd4b532ab08c74 commit was NAK'ed by Everton and I think rightly so. I have not got around to fixing it yet. Ok, so that can carry to next round presumably. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: There is Jackson standing like a stone wall. Let us determine to die, and we will conquer. Follow me. -- General Barnard E. Bee (CSA) ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
