Continous Integration Result: SUCCESSFUL
Congratulations, this patch passed basic tests
Tested-by: NetDEF CI System
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter .
Patches applied :
Patchwork 2007: http://patchwork.quagga.net/patch/
Between git getting confused a bit between the different versions of the
functions and me adding extra comments, this patch looks a lot more
complicated than it needs to be. Basically it boils down to reducing the
zsend_ipv4_nexthop_lookup_mrib() and zread_ipv4_nexthop_lookup_mrib()
functions
z[send/read]_ipv4_nexthop_lookup functions have been duplicated for multicast
mrib lookup. The mrib versions are identical to the unicast versions except for
a couple of places. The differences do not justify duplicating two functions
and 80 lines of codes. Code refactoring and an if statement w
Philippe,
okay fixes pushed to v2 (including removing v6 ifdefs) to show changes
and v3* posted to show final results. We have a couple of more issues
to deal with (skiplist license and a bug fix we're testing). Once these
are resolved we'll submit a formal patch update.
BTW V3 has the referen
On 6/17/2016 9:15 AM, Philippe Guibert wrote:
> On Thu, Jun 16, 2016 at 8:52 PM, Lou Berger wrote:
>
> Hello Lou,
>
>> Philippe,
>>
>> I've posted a fix to this (patch on patch) in
>>
>> https://github.com/LabNConsulting/quagga-vnc/commit/cd54370cb94d598aa95bd7561cc012200920d97a
>>
> I posted 2
On Fri, Jun 17, 2016 at 9:28 AM, Paul Jakma wrote:
> On Fri, 17 Jun 2016, Daniel Walton wrote:
>
> /* If this is an EBGP peer with remove-private-AS */
>>> static void
>>> bgp_peer_remove_private_as (struct bgp *bgp, afi_t afi, safi_t safi,
>>> struct peer *peer, struc
Continous Integration Result: SUCCESSFUL
Congratulations, this patch passed basic tests
Tested-by: NetDEF CI System
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter .
Patches applied :
Patchwork 2006: http://patchwork.quagga.net/patch/
On Fri, 17 Jun 2016, Daniel Walton wrote:
/* If this is an EBGP peer with remove-private-AS */
static void
bgp_peer_remove_private_as (struct bgp *bgp, afi_t afi, safi_t safi,
struct peer *peer, struct attr *attr)
{
if (peer->sort != BGP_PEER_EBGP)
return;
if
On Fri, Jun 17, 2016 at 5:33 AM, Paul Jakma wrote:
> Oh,
>
> Just another thing, the bgp_route.c::bgp_peer_remove_private_as function
> wasn't completely clear ot me. I think the logic simplifies out to at least:
>
> /* If this is an EBGP peer with remove-private-AS */
> static void
> bgp_peer_re
On Thu, Jun 16, 2016 at 8:52 PM, Lou Berger wrote:
Hello Lou,
> Philippe,
>
> I've posted a fix to this (patch on patch) in
>
> https://github.com/LabNConsulting/quagga-vnc/commit/cd54370cb94d598aa95bd7561cc012200920d97a
>
I posted 2 minor comments:
1) The code has been compacted; however i fe
On Fri, Jun 17, 2016 at 4:58 AM, Paul Jakma wrote:
> Hi,
>
> Is it just me, or does this patch leak attr->aspath? I've highlighted the
> bits that made me ask that. Though, to be fair, if so then it looks like
> the old remove-private-as also leaked.
>
> I'd suggest separating lifetime management
> On 17 Jun 2016, at 05:33, Paul Jakma wrote:
>
> If the user has not specified 'all', but has specified 'replace' wouldn't the
> action of least-surprise be to replace private-ASes regardless of whether the
> AS_PATH has public ones?
I couldn't see that this case was covered, but wouldn't rep
just sent to list - rev should hopefully address the CI failure too.
On June 17, 2016 5:26:23 AM Philippe Guibert
wrote:
> On Thu, Jun 16, 2016 at 8:45 PM, Lou Berger wrote:
>
> Hello Lou,
>
>>
>> ---
>> bgpd/bgp_encap.c | 45 -
>> bgpd/bgp_mplsvpn
---
bgpd/bgp_encap.c | 45 -
bgpd/bgp_mplsvpn.c | 8
bgpd/bgp_mplsvpn.h | 5 +
3 files changed, 9 insertions(+), 49 deletions(-)
diff --git a/bgpd/bgp_encap.c b/bgpd/bgp_encap.c
index 1a09ba6..e69da04 100644
--- a/bgpd/bgp_encap.c
+++ b
Continous Integration Result: SUCCESSFUL
Congratulations, this patch passed basic tests
Tested-by: NetDEF CI System
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter .
Patches applied :
Patchwork 2005: http://patchwork.quagga.net/patch/
You should look at lib/zclient.c and zebra/zserv.c. As that the
answer is 'it depends'.
donald
On Fri, Jun 17, 2016 at 6:10 AM, dexter i wrote:
> what is the ipc mechanism used in Quagga..?
>
> ___
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.n
* bgp_aspath.c: (aspath_prepend) aspath_delete_confed_seq may result
in as2 being updated, and seg2 becoming invalid. E.g. if the first
segment of of as2 is confeds. However, code there after unconditionally
reads from seg2.
Reset seg2, and re-do the empty check on it.
Caught by valgrin
what is the ipc mechanism used in Quagga..?
___
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
Oh,
Just another thing, the bgp_route.c::bgp_peer_remove_private_as function
wasn't completely clear ot me. I think the logic simplifies out to at
least:
/* If this is an EBGP peer with remove-private-AS */
static void
bgp_peer_remove_private_as (struct bgp *bgp, afi_t afi, safi_t safi,
On Thu, Jun 16, 2016 at 8:45 PM, Lou Berger wrote:
Hello Lou,
>
> ---
> bgpd/bgp_encap.c | 45 -
> bgpd/bgp_mplsvpn.c | 8
> bgpd/bgp_mplsvpn.h | 4
[..]
> -static u_int16_t
> +u_int16_t
> decode_rd_type (u_char *pnt)
Please, can yo
Hi,
Is it just me, or does this patch leak attr->aspath? I've highlighted
the bits that made me ask that. Though, to be fair, if so then it looks
like the old remove-private-as also leaked.
I'd suggest separating lifetime management from the manipulation. Have
aspath_replace_private_asns and
21 matches
Mail list logo
