Donald Sharp [Fri, 27 Jan 2017 20:33:00 +0000 (15:33 -0500)]
*: Fix redistribute issue
Somewhere in the past we switched from
using the auto-generated redistribute statements
to a non-generated version. This caused us to
loose new protocols to redistribute as they are
added. Put it back.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
David Lamparter [Thu, 26 Jan 2017 04:59:50 +0000 (05:59 +0100)]
lib: graph: fix vector_remove()
vector_remove would corrupt the data in the following sequence:
1. assume vector v = [a, b], active = 2
2. vector_unset(v, 0) => v = [NULL, b], active = 2
3. vector_remove(v, 1)
vector_remove calls vector_unset(v, 1), vector_unset notices index #0 is
also NULL and thus sets active to 0.
The equality test in vector_remove() now fails, leading it to decrement
v->active *again*, leading to an underflow that will likely crash the
daemon (and might even be exploitable).
This call sequence does not happen in existing code since vector_unset()
is not used on graph from/to lists. Nonetheless this is a buried land
mine in the code at best.
Rewrite the function - while we're at it, there's no reason to move the
entire array around, just fill the hole with the last element.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org> Cc: Quentin Young <qlyoung@cumulusnetworks.com>
David Lamparter [Wed, 25 Jan 2017 03:13:14 +0000 (04:13 +0100)]
lib: graph: fix deletions
Iterating over an array while deleting items needs to consider
interactions between the iteration position and deletion. The previous
code completely ignored that problem, leading to memleaks (graph_delete
skipping half of the nodes) and dangling pointers (if parallel edges
exist in graph_remove_edge).
Iterating backwards is safe and reduces "move to fill hole" overhead in
deletion.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org> Cc: Quentin Young <qlyoung@cumulusnetworks.com>
David Lamparter [Wed, 25 Jan 2017 21:33:29 +0000 (22:33 +0100)]
bgpd: lcommunity: fix minor issues
- route_set_lcommunity would do nothing (and leak memory) if attr->extra
wasn't up yet
- an if() arch in bgp_show_table() was duplicated (with no effect)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Wed, 25 Jan 2017 13:26:21 +0000 (08:26 -0500)]
bgpd: Add ability to clean lcommunity hash
Ensure that we don't leak any memory on shutdown.
Since the bgp_lcommunity.c file mirrors bgp_ecommunity.c
Add the same code for shutdown that ecommunity has.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
... which means that there are 2 distinct MTYPE_CMD_TOKENS.
(The description text being different does not matter, even with the
same text it'd be 2 distinct types.)
command_match.c allocates token->arg in command_match_r() while
command.c frees it in del_cmd_token(). Therefore with each command
being executed, the allocation count goes up on one, down on the other.
=> clean up parser allocation counting. Also, use separate MTYPEs for
the different fields in struct cmd_token.
Fixes: #108 / ee9216cf ("lib, ripngd: clean up merge leftovers") Signed-off-by: David Lamparter <equinox@opensourcerouting.org> Cc: Quentin Young <qlyoung@cumulusnetworks.com>
Philippe Guibert [Fri, 20 Jan 2017 10:44:18 +0000 (11:44 +0100)]
bgpd: move bgp_show_type enumerate to bgp_route.h
This bgp_show_type enumerate was duplicated and modified in several
places. The commit takes the enumerate with the biggest enumerate, so
that it can be used by all the functions using this enumerate.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 24 Jan 2017 14:49:47 +0000 (15:49 +0100)]
bgpd: fix ambiguity between show ip bgp ipv4|ipv6 encap|vpn commands
The commit is removed duplicated command show ip bgp ipv4|ipv6 enca|vpn
command that is conflicting between bgp_route.c and
bgp_mplsvpn.c/bgp_encap.c files. The fix is integrating the call to
specific mpls or encap settings from inside bgp_show_route() function.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 24 Jan 2017 09:13:37 +0000 (10:13 +0100)]
bgpd: remove duplicated vty command to enter in vpn address family node
Because the vpn configuration command was duplicate, there was an
ambiguity to raise. This is a fix that permits configuring vpnv4 or
vpnv6 address-families on bgp.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Tue, 24 Jan 2017 00:48:24 +0000 (19:48 -0500)]
bgpd: Start cleanup of 'show [ip] bgp ...' commands
Create bgp_vty_find_and_parse_afi_safi_vrf that
will parse the
`show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]]'
part of a command and to return the correct spot we are in the command.
Cleanup 'dampening parameters' part of this command.
Consolidate the creation of the bgp data structure to be a bit cleaner.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Sun, 22 Jan 2017 16:01:09 +0000 (11:01 -0500)]
bgpd: Fix function used only within KEEP_OLD_VPN_COMMANDS
The show_adj_route_vpn function is only currently used
in conjunction with the KEEP_OLD_VPN_COMMANDS #define.
Add this function to that define for the moment.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
David Lamparter [Sat, 17 Dec 2016 06:32:58 +0000 (07:32 +0100)]
lib: parser: add error location reporting
flex+bison have nice capabilities to track the location that is
currently being processed; let's enable these and get better warnings
for broken CLI specs.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Sat, 17 Dec 2016 04:25:36 +0000 (05:25 +0100)]
lib: parser: unify subgraphs & simplify even more
This cuts a large piece of complexity from the parser by making the
sequences between | the same, no matter whether it's <> () or [].
This causes some changes in behaviour:
- [foo|bar] is now accepted
- <foo|[bar]> is now accepted (yes it's stupid)
- {a|b} is now means "at least one of these, in any order"; to allow
zero use [{a|b}] instead.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Sat, 17 Dec 2016 04:14:49 +0000 (05:14 +0100)]
lib: parser: keep subgraph pointers on stack
There's no need to malloc() these, we can just keep them on the stack.
The entire struct will get copied around, but replacing a 2-pointer copy
with a 1-pointer copy + malloc + free overhead is not quite efficient.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
projects / mirror_frr.git / log