[quagga-dev 16730] Re: [PATCH] bgpd: Dynamic Neighbors feature
On Jun 25, 2018, at 9:55 AM, Victor Sartori wrote: > I found this patch on list archive and don't find this patch on quagga > commits. > > I found a another message in list archives ''[quagga-dev 11920] BGP Dynamic > Neighbor support', but I don't find anything about it too on git commits. > > There's a bug on this patch or plans to merge it with master? > > I can help with tests or anything else (I think I cannot help with code, my > skills in C is very poor) Unfortunately, not much is getting committed to Quagga anymore. I believe that FRR (a Quagga fork, which is getting most of the dev energy these days) has this feature but I haven't used it. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16724] Re: cleanup patch
On Apr 5, 2018, at 4:21 PM, Илья Шипицин wrote: > Hello, > > please review attached patch This patch seems obviously correct. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16494] Re: RIPD refuses to accept default route with non-zero netmask
On Jan 10, 2017, at 5:41 PM, Paul Jakma wrote: > On Tue, 10 Jan 2017, Alexis Rosen wrote: >> On Jan 10, 2017, at 10:47 AM, Paul Jakma wrote: >>> On Tue, 10 Jan 2017, Alexis Rosen wrote: >>>> This makes sense to me, and the RFC doesn't. >>> >>> Where's the RFC wrong exactly? "subnet 0" - 0/1 can't be that, as 0/1 means >>> you can not look at the full addr? >> >> On Dec 22, 2016, at 4:38 PM, Michael H Lambert wrote: > >>> This use case makes sense to me. However, quoting RFC 2453, "The special >>> address 0.0.0.0 is used to describe a default route." It makes no >>> reference to an associated netmask. > >> So, to answer your question, I think 2453 should be amended to say that only >> 0.0.0.0/0 is the default. > >> The problem is, there may be a ton of gear and code out there like quagga >> that ignores the mask on 0.0.0.0. > > Well, it's clearing the netmask, when the s_addr is 0. That's not in the RFC > either. Re-announced route will have it 0 then I assume. Good point, that's not really right either! On that basis, I propose that that bit of code be deleted, since it's not really RFC-compliant either. If someone really cares about compliance, they can re-patch it with a proper configuration switch. > Is there anywhere that would break if we stopped clearing the netmask? Seems > unlikely that anyone would be distributing 0/x, 0 < x <= 8 routes yet > expecting it to be a default - anyone trying that is probably like Jim, > wishing that bug wasn't there? ;) > > Risks seem very slim, or ..? Sounds reasonable. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16413] Re: [quagga-users 14531] Re: Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)
On Nov 16, 2016, at 10:14 AM, Paul Jakma wrote:
> On Wed, 16 Nov 2016, Alexis Rosen wrote:
>> On Nov 15, 2016, at 6:00 PM, Martin Winter
>> wrote:
>>> On 14 Nov 2016, at 21:20, Alexis Rosen wrote:
>>>> On Oct 18, 2016, at 1:56 AM, Martin Winter
>>>> wrote:
>> Actually, this continues the confusion. The statement above is compatible
>> with this interpretation:
>
>> The issue can be triggered on any interface with a reachable
>> IPv6 address by any IPv6 ICMP message
>>
>> ...but that's not true. I think what you're trying to say is this:
>
>> The issue can be triggered on any interface that has a reachable
>> IPv6 address by a Router Advertisement packet ("RA", or ICMPv6
>> type 134).
>
> Correct. Though, note that if the former is true, then the former is true. If
> I can send an any ICMP message, I can send the required RA packet[...]
My point is that the earlier text can be read to say that any ICMP can trigger
the issue, whereas in fact only certain ICMPs can.
>> Also, there is ambiguity as to whether RA-issuing or RA-receiving code is
>> the problem (see below).
>
> In the receive path.
Right, but since the workaround is to turn off the RA-issuing feature, this
needs more clarity.
Is it the case that only RS messages actually trigger the bug? Nothing in the
advisory actually says that. In fact there seems to be a lot of confusion in
the text between RAs, RSes, and ND in general (which is the source of my
confusion here).
>> If I am correct, then let me suggest the following as a complete replacement
>> for the lead paragraph:
>>
>> A remotely exploitable buffer overflow exists in the IPv6 Router
>> Advertisement reception code in Zebra. The issue can be
>> triggered on any interface that has a reachable IPv6 address, by
>> a Router Advertisement packet ("RA", or ICMPv6 type 134). To be
>> vulnerable, the Zebra daemon must be running, and the
>> non-default "no ipv6 nd suppress-ra" must be enabled an at least
>> one interface.
>
>> That's ambiguous because of the double-negative.
>>
>> Maybe this?
>> Users of Quagga who do not use the Zebra daemon are NOT affected.
>> Users of Zebra who have IPv6 neighbor-discovery disabled (the
>> default) are NOT affected. Enabling IPv6 neighbor-discovery on
>> ANY interface exposes users to this attack on EVERY IPv6 interface.
>
> I don't object as such.
Martin, are you OK with those paragraphs? If I'm correct above (about RSes
being the only problem) would you like me to do a quick edit on the rest of the
text?
>> Since this bug only affects Linux, would it instead make more sense to do
>> net.ipv6.conf.all.accept_ra=0
>> and maybe
>> net.ipv6.conf.default.accept_ra=0
>
>> instead to work around the bug? That would prevent processing of all RA
>> messages on every interface.
>
> By the kernel, for its own client side auto-configuration. Different thing.
> The code concerned is the router-side advertisement, in zebra.
Got it, thanks.
/a
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16412] Re: [quagga-users 14526] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)
On Nov 16, 2016, at 10:05 AM, Paul Jakma wrote: > On Tue, 15 Nov 2016, Alexis Rosen wrote: > >> As far as I can tell, this is an editing error of some sort, and in fact you >> can NOT trigger the issue simply by having an IPv6 address reachable with an >> ICMP. > > Ah, what's the basis for that? I looked at the code, and that security claim > seemed possible. ISTM that the bug is in code which allocates memory to hold contents of a received RA, so if you can't get RAs on the box, you'll never try to allocate a too-small amount of memory. RSes as well? However, given the difficulty/CPU cost of blocking obscured ICMPv6 packets (see for example RFC7113), maybe drawing the distinction between different types of ICMPs isn't all that useful in a practical security context. >> Later in the advisory, it says: > >>> Usage of Quagga without running the 'zebra' daemon, or no >>> IPv6 neighbor-discovery are not affected. >> >> A quick look at the code also suggests this is so, but my familiarity with >> this code is basically nil, and it would be very easy for me to get this >> wrong. > > The code concerned is all the zebra daemon, so that's correct. The code that > reads the message is only enabled if the zebra RA/ND feature is. > > Note, you could have the kernel IPv6 ND/SLAC enabled, and be fine - it's > about the zebra feature. That's also not 100% clear. Yes. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16405] Re: [quagga-users 14521] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)
While I was at first concerned about wording, which I address first, I am also
concerned about the substance of the CVE, which I'll address at the end.
On Nov 15, 2016, at 6:00 PM, Martin Winter
wrote:
> On 14 Nov 2016, at 21:20, Alexis Rosen wrote:
>> On Oct 18, 2016, at 1:56 AM, Martin Winter
>> wrote:
>>> Security Advisory: Quagga Buffer Overflow in IPv6 RA handling
>>> =
>>>
>>> [...] The issue can be triggered on an IPv6 address where the Quagga
>>> daemon is reachable by a RA (Router Advertisement or IPv6 ICMP message.
>>
>> So... Nearly a month later, I'm deleting old mail and noticed this.
>>
>> As far as I can tell, this is an editing error of some sort, and in fact you
>> can NOT trigger the issue simply by having an IPv6 address reachable with an
>> ICMP.
>
> How about this wording:
>
> A buffer overflow exists in the IPv6 (Router Advertisement) code in
> Zebra. The issue can be triggered on any interface with a reachable
> IPv6 address
> by a RA (Router Advertisement) or IPv6 ICMP message.
> The issue leads to a crash of the zebra daemon.
Actually, this continues the confusion. The statement above is compatible with
this interpretation:
The issue can be triggered on any interface with a reachable IPv6
address
by any IPv6 ICMP message
...but that's not true. I think what you're trying to say is this:
The issue can be triggered on any interface that has a reachable IPv6
address
by a Router Advertisement packet ("RA", or ICMPv6 type 134).
Also, there is ambiguity as to whether RA-issuing or RA-receiving code is the
problem (see below).
If I am correct, then let me suggest the following as a complete replacement
for the lead paragraph:
A remotely exploitable buffer overflow exists in the IPv6 Router
Advertisement reception code in Zebra. The issue can be triggered
on any interface that has a reachable IPv6 address, by a Router
Advertisement packet ("RA", or ICMPv6 type 134). To be vulnerable,
the Zebra daemon must be running, and the non-default "no ipv6 nd
suppress-ra" must be enabled an at least one interface.
>> Later in the advisory, it says:
>>> Usage of Quagga without running the 'zebra' daemon, or no
>>> IPv6 neighbor-discovery are not affected.
>
> What this should say:
> The issue is in Zebra daemon. So you are safe without Zebra daemon (i.e. some
> users only using BGPd)
> You are also safe if you have the IPv6 neighbor-discovery disabled.
>
> So maybe just a missing comma?
>
> Usage of Quagga without running the 'zebra' daemon, or no
> IPv6 neighbor-discovery, are not affected.
That's ambiguous because of the double-negative.
Maybe this?
Users of Quagga who do not use the Zebra daemon are NOT affected.
Users of Zebra who have IPv6 neighbor-discovery disabled (the
default) are NOT affected. Enabling IPv6 neighbor-discovery on
ANY interface exposes users to this attack on EVERY IPv6 interface.
However I am still puzzled by something. "ipv6 nd suppress-ra" prevents
Quagga from *sending* RAs. But the bug described is in receiving RAs. Will
"ipv6 nd suppress-ra" really prevent the bug?
Since this bug only affects Linux, would it instead make more sense to do
net.ipv6.conf.all.accept_ra=0
and maybe
net.ipv6.conf.default.accept_ra=0
instead to work around the bug? That would prevent processing of all RA
messages on every interface. Another approach would be to turn off autoconfig
for all interfaces, but I am not 100% sure the vulnerable code path would be
avoided then.
Thanks, and sorry this is so late.
/a
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16400] Re: [quagga-users 14444] Quagga CVE Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release)
On Oct 18, 2016, at 1:56 AM, Martin Winter wrote: > Security Advisory: Quagga Buffer Overflow in IPv6 RA handling > = > > [...] The issue can be triggered on an IPv6 address where the Quagga > daemon is reachable by a RA (Router Advertisement or IPv6 ICMP message. So... Nearly a month later, I'm deleting old mail and noticed this. As far as I can tell, this is an editing error of some sort, and in fact you can NOT trigger the issue simply by having an IPv6 address reachable with an ICMP. Later in the advisory, it says: > Usage of Quagga without running the 'zebra' daemon, or no > IPv6 neighbor-discovery are not affected. A quick look at the code also suggests this is so, but my familiarity with this code is basically nil, and it would be very easy for me to get this wrong. Can someone who is certain please clarify? And maybe update the CVE so the sentence makes sense (and has balanced parentheses)? Thanks. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 16164] Re: Proposed 8 testing Update
On Oct 3, 2016, at 11:21 AM, Vincent JARDIN wrote: > Le 03/10/2016 à 15:08, Paul Jakma a écrit : >> >> My inclination is to release as is. Document regressions. Try fix them >> later. > +1 ISTM the large majority of quagga users will not see any such documentation. They'll build/install using their distro's package manager. Then when things break, they'll come here looking for support, or else decide that quagga sucks and try something else. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15277] Re: Regarding SSH support in Quagga
On May 16, 2016, at 10:03 AM, Devender wrote: > I have Quagga/Zebra installed on Ubuntu 14-04 , I am able to connect to > Quagga CLI using Telnet but SSH to CLI is not working. Do Quagga CLI supports > SSH ? No, it doesn't support either SSH or telnet. It's just sending text across a network socket. If you want ssh, you set it up on the router host, use ssh to connect, and then use vtysh. BTW, this sort of question probably belongs on quagga-users, not quagga-dev. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15246] Re: Route-Map Behavior
On Apr 22, 2016, at 11:45 AM, Donald Sharp wrote: > Paul and I have been discussing this commit: > > https://github.com/donaldsharp/quagga/commit/4a77fb6cc78cacfd0c6cd0c35ba766f994a87e11 > > Quagga behavior without this patch does not take into effect for already > processed events. So if you change a route-map > you need to reset the peer by hand to make it take into effect. > > With this code change a timer is started that gets executed after a small > time that causes all routes to be reprocessed. > > Paul suggestion is to add an event on 'conf t' exit to immediately expire the > timer if it is still running. Which I am planning on writing here > shortly. > > Having said that does anyone else have thoughts on this behavior and what it > may or may not do? Did anyone answer you? (If so I missed it.) I'd love to see this feature, since this has been a PITA for the last 20 years. However... this could lead to surprising behavior. It wouldn't be at all unusual for someone to change a route map, then change a prefix list it uses, then a community list, etc... all while in config mode, to be followed by a soft reconfigure of the BGP session when done. (And yes, you could argue that you should configure the dependencies first, but doing it this way has always been safe.) But now with your patch, what if your timer expires while the user is still doing the configure? Undefined and possibly catastrophic behavior. I'd suggest removing the timer and just recalculating on exit from configure. That doesn't guarantee the scenario above can't happen, but it's pretty close. Alternatively, you could have an option to add both behaviors if the option is set and neither if it isn't. Also, if you reprocess on exit from configure, it would be nice to say so on the console (or log it?). /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 14813] Re: [PATCH 10/10] build: goodbye, gawk
On Mar 2, 2016, at 8:38 PM, Donald Sharp wrote: > On a side note, extract.pl.in as far as I can tell only is used to auto > generate the perl binary location. Is there a modern distribution that > doesn't have perl in /usr/bin? Would people mind if I removed the > extract.pl.in -> extract.pl configure creation? NetBSD7 (and previous) don't ship with perl. Plenty of systems will have it in /usr/local/bin. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 14810] Re: XR-Like Commit Feature
On Mar 2, 2016, at 6:43 PM, Alexander Turner wrote: > So Vyatta is interesting though looking through the source code, it seems as > if they've modified bash (I think for autocomplete functionality?) and > written their own shell. Their commit function is hiding in here from what it > seems. I was not aware of any bash modifications. Did you see source for that? Bash has a ridiculously complex autocompletion feature, and they are indeed using that very extensively. BTW, if you haven't looked at VyOS, that's probably where you want to direct your attention - there's always work going on there, though sadly, I don't see any evidence of integration with later versions of Quagga. :-( > Paul, I like your reload idea and plan on using it (this in on your public > fork?), though I'm thinking more along the lines of preventing screwups in > the CLI which could result in lost connectivity. Along the lines of: > • Don't action commands until `commit` issued > • Review pending commands with `commit review` > • Commit revert timer `commit revert 5` to revert commands after 5 > minutes if `commit confirm` not issued. > Just thinking out loud here. All that is in Vyatta/VyOS already. I just don't know if it's too tightly intertwined with their rewritten config parser. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 14803] Re: XR-Like Commit Feature
On Mar 1, 2016, at 6:55 PM, Alexander Turner wrote: > Looking into starting a feature that prevents commands from being executed > until a 'commit' command is issued in vtysh. Looking through the source code > it would seem as if each daemon doesn't exactly facilitate this easily though > I'm curious if this can be done through vtysh. > > As in, when each command is entered into vtysh, vtysh checks that it's a > valid command (syntactically), stores it in an array and executes the list > (and clearing said array) when the commit command is issued. Writes would > still be the same. > > What's the consensus amongst the community? Has anyone tried this or spoken > about this previously? > > Interested to hear thoughts and get a discussion going... This has already been done, as part of a much much larger project, by Vyatta (now VyOS). I haven't looked at the code but it's possible you might be able to use some of it- at least the back-end half of it. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 14373] Re: Location of 'vrf ' option in a command
Anything that breaks the common case that millions (?) of fingers have on automatic - "sho ip route xxx" - is going to seriously irritate many many people. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13989] Re: cleaning up commands (was Re: BGP 'view' to 'vrf')
On Nov 25, 2015, at 8:29 AM, Paul Jakma wrote: > On Tue, 24 Nov 2015, Alexis Rosen wrote: >> I would be shocked if there was a consensus to move away from the current >> CLI. > > Me too. ;) > > The idea is to be able to support other interfaces, and allow them to be > written with out specific knowledge of Quagga internals (unless they are > required to transform how Quagga structures things to fit into some other > externally defined schema). Yes, I understood that. I was reacting to Vincent's comment. > E.g. it should be possible to write other styles of CLI. So, VyOS and EdgeOS have already done that (well, Vyatta did, but that's dead now). It might be worth a little extra effort to make sure they have a chance to weigh in on this. Anything that brings the codebases closer together can only make all projects stronger. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13986] Re: cleaning up commands (was Re: BGP 'view' to 'vrf')
On Nov 24, 2015, at 9:06 AM, Vincent JARDIN wrote: > On 24/11/2015 14:38, Paul Jakma wrote: >> So the things we need to consider: >> >> - Existing CLI >> - SNMP >> - YANG >> - OVSDB >> - > - bson/json > - XML/binary XML configuration > - ODL - Opendaylight > > We should not mix: > a- transport frameworks > vs > b- datastore > vs > c- Quagga's backend (currently CLI) to process them > > I would prefer c- to be improved (run away from the current CLI) so any upper > framework that have been listed would apply efficiently. I would be shocked if there was a consensus to move away from the current CLI. However, if things do go in that direction, it might be interesting to look at the former Vyatta, now VyOS, codebase. The disadvantage is, obviously, the complete divergence in configuration CLI, but there are some very significant advantages as well. Primarily, I think it would benefit both VyOS and Quagga greatly if the code differences were minimized - VyOS would get a much better routing component, while Quagga would pick up more users using a modern codebase. Everything I said about VyOS also applies to Ubiquity's EdgeOS. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13837] Re: [PATCH 06/58] quagga: nexthop-tracking.patch
This looks great. Long past time for it. But I'm curious - have you profiled the change in CPU and memory? I'm less concerned about CPU (obviously going to be a big win) than memory. I'm happy to pay it for the CPU gain, just curious about how expensive it will be. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13717] Re: [PATCH 18/22] BGP: Reprocess the trigger points when an attached route map changes
On Nov 10, 2015, at 9:13 AM, Daniel Walton wrote: > Cisco IOS behaves the same way as quagga with the proposed patch...route-maps > are applied automatically after a few seconds. Example: I didn't realize that that had changed... > While I appreciate the convenience it provides, I can also see this patch > being a significant PITA from time to time. So I would suggest the ability to > go either way, based on a CLI command. The simple version would simply switch > behavior between the two modes; a more complex version would queue up changes > while "holding" them, and then process them all as soon as the hold is > released. ISTM that the more complex version would be a really nice feature > to have, but since I'm not writing the code, I'm not going to complain either > way. > > The user could do this by setting the timer to 0, make their changes and then > set the timer to non-zero (or leave it at zero and soft clear all peers). > > superm-redxp-05(config-router)# bgp route-map delay-timer ? > <0-600> 0 disables the timer, no route updates happen when route-maps > change > superm-redxp-05(config-router)# Yes, that's exactly what I was talking about. Didn't know that was there - sorry for the noise. :-( /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13586] Re: [PATCH 18/22] BGP: Reprocess the trigger points when an attached route map changes
On Nov 9, 2015, at 8:21 PM, Donald Sharp wrote: > From: Dinesh G Dutt > > Currently, modifications to route maps do not affect already processed > routes; they only affect new route updates. This patch addresses this > limitation. This is highly desirable, from one point of view, both as a significant convenience and because it keeps tripping up newbies who wonder why their changes aren't having any effect. However... the current behavior is consistent with Cisco's since the beginning of time, and is well understood by most. More, it allows multiple changes to be made in batches, without having to worry about inconsistent states during those changes. While the existing behavior is easy enough to deal with (clear ip bgp...), there is no easy way to get the existing behavior once this patch is in. While I appreciate the convenience it provides, I can also see this patch being a significant PITA from time to time. So I would suggest the ability to go either way, based on a CLI command. The simple version would simply switch behavior between the two modes; a more complex version would queue up changes while "holding" them, and then process them all as soon as the hold is released. ISTM that the more complex version would be a really nice feature to have, but since I'm not writing the code, I'm not going to complain either way. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13350] Re: doc: Add 'OSPF Fundamentals' section to OSPF docs
On Oct 20, 2015, at 11:14 AM, Paul Jakma wrote:
> This is an old bit of documentation work gathering dust in my attic. I'd
> written it to try help OSPF admins better understand and debug their
> networks in the event of problems. I didn't finish it off, so never
> submitted it. Not sure if it's useful. Havn't fully re-checked it for
> accuracy, and there's wording that could be better, and it needs
> finishing...
>
> Is it useful?
No opinion, I didn't get through all of it, but you typoed Dijkstra's first
name ("Edgser").
/a
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13324] Re: Quagga support VRRP
On Oct 19, 2015, at 6:37 AM, Balaji G wrote: > Quagga is a routing protocols suite. It does not have support for VRRP. Maybe it would be better to say it doesn't include VRRP, than that it doesn't support it. If you install a VRRP package, it will work fine with Quagga- at least as much as any routing protocol suite will. So, for example, you will have to hack some stuff together if you want BGP to work right. But it can be done. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13078] Re: Patches adding commands should update docs?
On Sep 15, 2015, at 5:44 AM, Paul Jakma wrote: > Well, what about requiring that where a command is modified and that command > has documentation already, that the documentation is updated? > > Out-of-date and hence misleading documentation is perhaps more annoying than > none. Agreed. Potentially *way* more. However, who is going to check? I guess, since you're doing the committing, that would be you (& other maintainers). So if you're willing to eat that additional overhead, I'm all for this. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13064] Re: BGP: deactivating an address-family for neighbor removes some of the config
On Sep 11, 2015, at 3:37 PM, Lou Berger wrote: > On 09/11/2015 02:35 PM, Alexis Rosen wrote: >> On Sep 11, 2015, at 8:25 AM, Michael H Lambert wrote: >>> For deleting the per-AFI/SAFI config, how about just >>> >>> no neighbor address-family >>> >>> (eg, "no neighbor 1::1 address-family ipv6 multicast"). >> >> +1 >> >> That's exactly what I was thinking. > > This is inconsistent with the current afi/safi config: > > address-family vpnv4 > neighbor 127.0.0.115 activate > neighbor 127.0.0.115 route-reflector-client > neighbor 127.0.0.116 activate > neighbor 127.0.0.116 route-reflector-client > exit-address-family > ! > > of course right now a 'no neighbor 127.0.0.116 activate' will delete all > neighbor information. This too is inconsistent with the base neighbor > config. > > So for consistency I propose: > > address-family > no neighbor 127.0.0.116 activate #for deactivate > no neighbor 127.0.0.116 delete #for remove neighbor > exit-address-family Hm. That's somewhat counterintuitive. The obvious option, if somewhat inconsistent with standard usage, would be: address-family no neighbor 127.0.0.116 activate #for deactivate delete neighbor 127.0.0.116#for remove neighbor exit-address-family Alternatively, "no neighbor " could mean to delete either the afi/safi config or the entire config, depending on current scope. Assuming quagga can handle that, I think I'd favor it. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13061] Re: BGP: deactivating an address-family for neighbor removes some of the config
On Sep 11, 2015, at 8:25 AM, Michael H Lambert wrote: >> On 11 Sep 2015, at 06:34, Paul Jakma wrote: >> >> Yeah, be nice to have 1 way to delete the per-AFI/SAFI config, and another >> to disable the neighbour in that AFI/SAFI, but keep config. >> >> What would be the sanest way to add such commands, or options to existing >> commands? > > For deleting the per-AFI/SAFI config, how about just > > no neighbor address-family > > (eg, "no neighbor 1::1 address-family ipv6 multicast"). +1 That's exactly what I was thinking. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 13054] Re: BGP: deactivating an address-family for neighbor removes some of the config
On Sep 10, 2015, at 9:36 AM, Paul Jakma wrote: > On Thu, 10 Sep 2015, Donald Sharp wrote: >> Paul - >> >> I don't get this. 'no neighbor activate' does nothing more than >> temporarily turn the neighbor off, why would it remove some config? If I >> wanted to remove the neighbor, I would do a 'no neighbor X' instead, right? > > As things stand, 'no neigh X' removes the neighbour completely, regardless of > the AFI/SAFI context. 'no neigh X activate' removes the AFI/SAFI config and > deconfigs that AFi/SAFI. > > Various arguments could be made I guess, though. > > Note, you can also put the general configuration into a peer-group, and then > activate and deactivate neighbours to use that peer-group. And deactivating > should leave the peer-group. > > So peer-groups can give a label for sets of configs and make that config-set > have a lifetime beyond specific neighbour definition/activation. ISTM that the current behavior is a significant violation of the principle of least surprise. It also differs from similar commands, like "shutdown" on an interface. I think it would be preferable to have it simply deactivate the neighbor without changing the config in any way. That's a useful thing to be able to do. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12922] Re: Opinions requested: Package spec files for various distribution and doc - add to quagga git?
On Aug 12, 2015, at 8:45 PM, Martin Winter wrote: > This includes some (basic) documentation on how to build from source and how > to > build a package for each of these distributions. All the Doc is currently in > Markdown format (because the gut servers do a nice on-the-fly rendering) > > What does the community think? > - Should I submit these to the Quagga Git? Yes. > - If yes on doc, is Markdown acceptable or should it be in Tex? Tex is very useful in situations where nothing less works well. The rest of the time it's a millstone around our necks. Why carry that extra weight if you don't have to? /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12601] Re: [PATCH v3 00/22] VRF support in quagga
I don't use VRFs with Quagga. While I think it would be healthy for the platform to have support, I don't need it myself, so I have no vested interest in any particular outcome here. On Jun 1, 2015, at 11:38 AM, Paul Jakma wrote: > On Mon, 1 Jun 2015, David Lamparter wrote: >> At least, I don't see anyone else trying to further discuss this. > > That's fine. > > Then I NACK and it doesn't go in. If that happens, then you cause a retroactive fork. That is, there are users of this code, and many more who have expressed strong interest. It will be out there, and it will be used, because nobody has a plausible alternative. And Quagga is not Linux- those "out-of-tree patches" will likely wind up with more maintainers and coders than vanilla. That's not a healthy outcome in the short term (though in the long term might lead to a reasonably healthy Quagga++ or whatever). I have tried to follow your argument. ISTM that one of your acceptable options is getting lost in the noise - that people acknowledge that taking this patchset may be problematic later. If nobody's willing to even go that far, then maybe the right thing to do is make a new branch, take the patches, make an alpha (not beta) release, and see what other patches come along in a few months. By then, the merits of the argument might well be a lot clearer, and if not, well, I think the writing is on the wall in that case anyway. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 12251] Re: babeld sync-up
On May 7, 2015, at 6:45 AM, Juliusz Chroboczek wrote: >> Just to re-iterate again, everyone, including Juliusz, seems to be agreed >> that Quagga is fully honouring all the licence conditions. > > I have no plans to sue anyone, if that's what you mean. However unethical > their behaviour. > > -- Juliusz I'm a bystander with no dog in this fight (so what the heck am I doing here?). But based on the exchanges I've seen, I'm wondering if people are really as far apart as it seems right now. Unless there's more to this that hasn't been posted, I think Juliusz has two major issues: 1) Commit messages have incorrect attribution 2) The license is GPL, while the original code was BSDish IIRC, Paul already offered to redo the commits. That leaves #2 as the big issue. If each source file in Quagga were GPLed, but also contained a header referring to the matching BSD-licensed sources (thus allowing anyone who wanted is under a BSD license to access it easily), would that be anywhere close to satisfactory? The header would say something like "this code is also available under a BSD license at http://blahblah.blah";. True, the quagga-specific changes wouldn't be in that BSD version, but that should be fine - anyone who needs it under BSD license can't use quagga anyway. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11997] Re: [PATCH 15/15] doc: zebra multicast RIB commands
On Jan 29, 2015, at 7:54 PM, David Lamparter
wrote:
> +@deffn Command {ip multicast rpf-lookup-mode @var{mode}} {}
> +@deffnx Command {no ip multicast rpf-lookup-mode [@var{mode}]} {}
> +
> +@var{mode} sets the method used to perform RPF lookups. Supported modes:
> +
> +@table @samp
> +@item urib-only
> +Performs the lookup on the Unicast RIB. The Multicast RIB is never used.
> +@item mrib-only
> +Performs the lookup on the Multicast RIB. The Unicast RIB is never used.
> +@item mrib-then-urib
> +Tries to perform the lookup on the Multicast RIB. If any route is found,
> +that route is used. Otherwise, the Unicast RIB is tried.
> +@item lower-distance
> +Performs a lookup on the Multicast RIB and Unicast RIB each. The result
> +with the lower administrative distance is used; if they're equal, the
> +Multicast RIB takes precedence.
> +@item longer-prefix
> +Performs a lookup on the Multicast RIB and Unicast RIB each. The result
> +with the longer prefix length is used; if they're equal, the
> +Multicast RIB takes precedence.
> +@end table
Shouldn't the documentation indicate which mode is default?
/a
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11902] Re: ospfd-mi.patch: OSPF multi-instance support
On Dec 15, 2014, at 5:22 AM, Feng Lu wrote: > (1) u_short instance > > The instance ID is defined as an unsigned short value. It seems enough > for now, while I don't know whether it would be proper in the future > or for some special reason. > > Is it more better to use u_int32_t? > > Or at least, I suggest to add a type definition in zebra.h like: > >typedef u_int32_t inst_t; > > to avoid changing the code everywhere if we would need to change the > type. +1. Also simplifies issue #8. > (7) > /* Configuration filename and directory. */ >-char config_default[] = SYSCONFDIR OSPF_DEFAULT_CONFIG; >+char config_default[100]; > > >/* Process ID saved for use by init system */ >-const char *pid_file = PATH_OSPFD_PID; >+char pid_file[100]; > >+ char vty_path[100]; > > There should be a better way to define the string length than a hard- > coding value 100. For example: > >char pid_file[2 * sizeof (PATH_OSPFD_PID)] = PATH_OSPFD_PID; Use PATH_MAX? /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11874] Re: ospfd-mi.patch: OSPF multi-instance support
On Dec 5, 2014, at 4:20 AM, David Lamparter wrote: > Ah, that argument I can actually understand. Ohwell. > > We need to make sure they're maintained, then - if they aren't, I still > think they hurt more than they help :/. Ultimately, I guess Greg is > spot on in arguing that the common, generally useful parts make sense. > I somewhat overshot the point I was trying to make. I disagree that they hurt more than help. For someone with minimal experience with quagga (most distro package maintainers), a 90% right starting point is way better than a 0% starting point. Of course, the closer to perfect we can get them, the better. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11868] Re: ospfd-mi.patch: OSPF multi-instance support
[Oops, sorry, sending again with the correct From: address] David, I think you're missing an important point: Quagga has a much greater interest in being available on many platforms, than individual platforms/distros have in making quagga available. To the extent that a larger user base is desirable, the project should suck it up and make an effort to keep init scripts (systemd configs, etc.) current, because the alternative is to have older or broken versions in some/many repositories. Take for example netatalk - a significant project, with a large user base. Nevertheless, for years you couldn't build a working version in ubuntu from apt(itude) because it was out of date and broken. Now that that's no longer the case, the version available is still dramatically out of date. This is all because the maintainer simply didn't have the time to do a new version. Every little thing you do to make it harder for distros to keep quagga current (or get it running correctly in the first place) will have an outsized impact on how current quagga is in their repos. And the more out of date they get, the more "try again with the current version" noise there will be in the lists. Because of this I think it's in the project's interest to keep init scripts around, and getting rid of them is a false economy. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11846] Re: [PATCH] zebra/kernel_socket.c: Use platform alignment
On Dec 2, 2014, at 3:31 PM, Greg Troxel wrote: > + * platforms, and 8 bytes on others. bytes. NetBSD 6 changed the You might want to fix that. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11810] Re: ospfd-mi.patch: OSPF multi-instance support
On Nov 26, 2014, at 3:36 AM, Vipin Kumar wrote: > Please find a write-up for this feature, location of the code, and attached > are some real outputs from the running code. Hope this will be useful to the > members of the community interested in this feature. This is great! Have you had a chance to look at the VRF patches? I suspect that a number of people would be interested in knowing how easily they could be integrated with yours - it would provide a good start on the answer to the questions Paul has been asking. > - zebra route/redistribute mechanisms are modified to work with > [protocol type + instance-id] > > - bgpd now has ability to have multiple instance specific redistribution > for a protocol (OSPF only supported/tested for now). > > - ospfd now has ability to have multiple instance specific redistribution > from other OSPF instances. Does the lack of mention of mods to rip, isis, & babel mean that they can't do redistribution from multiple ospfs yet? In any case, I hope to see a rapid review and merge of this code. It has clearly been of significant interest to a number of people over the last several years. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11809] Re: zebra dest/src routing support
I have no dog in this fight (discussion), but I am curious... wasn't it decided (more than a year ago IIRC) that the Quagga project would move to a merge-early default behavior? I thought the criterion for merging was changed to, approximately, "don't break stuff". If so, that seems inconsistent with the arguments over this feature and over the VRF patches. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11775] Re: [PATCH v2] zebra: Set link-detect on by default
On Nov 21, 2014, at 1:31 PM, Lennart Sorensen wrote: > On Fri, Nov 21, 2014 at 06:43:04AM -0500, Alexis Rosen wrote: >> So, here's a really bad solution, but if it gets the patch merged, then it >> would be "good enough"... >> [...] > > Most people use packages, not make install. So a bad solution that is > in fact a non solution. True... but packagers could be told to run that same hack on installation. I don't know how good they tend to be at following such instructions though. BTW, I wouldn't even have suggested this, but the integrate-over-two-releases idea seems much the same and even more hackish, opening a hole wherein people who skip a single release don't get the benefit of whatever dubious protection we're trying to offer. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 11767] Re: [PATCH v2] zebra: Set link-detect on by default
On Nov 21, 2014, at 3:29 AM, Dinesh Dutt wrote: > I also agree that we should do this in a way that avoids affecting > existing users and that this should be the default for new > configurations. I don't know of a good way to address both issues > offhand. Let me think some more and respond if I can come up with a way. So, here's a really bad solution, but if it gets the patch merged, then it would be "good enough"... I haven't done a pure quagga install in years so I don't remember the details, but ISTM that at "make install" time, it should be possible to tell with fairly good confidence whether a box is new or not. Why not make that determination, and leave a flag file if so? zebra can look for that flag when it loads, if it finds no indication (a "link-detect default ...") one way or the other in its config. Depending on what it finds, it adds either "link-detect default enable" or "link-detect default disable" (or whatever syntax you like) to its config. And when it writes the config, it deletes the flag. Yes, it's a disgusting hack better suited to a half-wit admin's shell script, but... I'd hate to see this die because history held us back. /a ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
