Pascal Mathis [Sat, 19 May 2018 20:10:48 +0000 (22:10 +0200)]
bgpd: Improve group overrides for AF flags
The current implementation for overriding peer-group configuration on a
peer member consists of several bandaids, which introduce more issues
than they fix. A generic approach for implementing peer-group overrides
for address-family flags is clearly missing.
This commit implements a generic and sane approach to overriding
peer-group configuration on a peer-member. A separate peer attribute
called 'af_flags_override' which was introduced in 04e1c5b is being used
to keep track of all address-family flags, storing whether the
configuration is being inherited from the parent-group or overridden.
All address-family flags are being supported by this implementation
(note: flags, not filters/maps) except 'send-community', which currently
breaks due to having the three flags enabled by default, which is not
being properly handled within this commit; all flags are supposed to
have an 'off'/'false' state by default.
In the interest of readability and comprehensibility, the flag
'send-community' is being fixed in a separate commit.
The following rules apply when looking at the new peer-group override
implementation this commit provides:
- Each peer-group can enable every flag (except the limitations noted
above), which gets automatically inherited to all members.
- Each peer can enable each flag independently and/or modify their
value, if available. (e.g.: weight <value>)
- Each command executed on a neighbor/peer gets explicitely set as an
override, so even when the peer-group has the same kind of
configuration, both will show up in 'show running-configuration'.
- Executing 'no <command>' on a peer will remove the peer-specific
configuration and make the peer inherit the configuration from the
peer-group again.
- Executing 'no <command>' on a peer-group will only remove the flag
from the peer-group, however not from peers explicitely setting that
flag.
This guarantees a clean implementation which does not break, even when
constantly messing with the flags of a peer-group. The same behavior is
present in Cisco devices, so people familiar with those should feel safe
when dealing with FRRs peer-groups.
The only restriction that now applies is that single peer cannot
disable a flag which was set by a peer-group, because 'no <command>' is
already being used for disabling a peer-specific override. This is not
supported by any known vendor though, would require many specific
edge-cases and magic comparisons and will most likely only end up
confusing the user. Additionally, peer-groups should only contain flags
which are being used by all peer members.
Donald Sharp [Fri, 25 May 2018 18:45:16 +0000 (14:45 -0400)]
zebra: Add a breadcrumb for when we ignore a route
When we receive a route that we think we own and we
are not in startup conditions, then add a small debug
to help debug the issue when this happens, instead
of silently just ignoring the route.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 25 May 2018 18:36:12 +0000 (14:36 -0400)]
tools, zebra: Use different protocol value for our statics
The re-use of RTPROT_STATIC has caused too many collisions
where other legitimate route sources are causing us to
believe we are the originator of the route. Modify
the code so that if another protocol inserts RTPROT_STATIC
we will assume it's a Kernel Route.
Fixes: #2293 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We added our own copy of if_link.h (among others). This
file unconditionally defines IFLA_WIRELESS, so we don't need
the conditional defines in the if_netlink.c code...
Issue: https://github.com/FRRouting/frr/issues/2299 Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
Quentin Young [Thu, 24 May 2018 18:43:57 +0000 (18:43 +0000)]
lib: add proper doc comments for hash & linklist
* Remove references to ospf source files from linklist.[ch]
* Remove documentation comments from hash.c and linklist.c
* Add comprehensive documentation comments to linklist.h and hash.h
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Don Slice [Thu, 24 May 2018 14:58:37 +0000 (10:58 -0400)]
bgpd: additional neighbor message improvement
Added improved error message text to other places that could also
encounter the same condition. In testing found that in certain
case, duplicate error messages were previously issued. This fix
also removes the duplicates.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Don Slice [Wed, 23 May 2018 12:09:59 +0000 (08:09 -0400)]
bgpd: improve error message for neighbor not found
Problem reported due to tab completion showing all possible peers
in every vrf, but when neighbor in wrong vrf entered "no such
neighbor" is the error message. Making it slightly more clear
with "no such neighbor in the view/vrf" to clue the user that they
may have specified the wrong vrf.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Donald Sharp [Thu, 24 May 2018 13:03:11 +0000 (09:03 -0400)]
zebra: Fix RULE notification netlink messages
Fix the code so that we would actually start receiving
RULE netlink notifications.
The Kernel expects the long long to be a bit field
value, while the newer netlink message types are
an enum. So we need to convert the message type
number to a bit position and set that value.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 23 May 2018 13:24:12 +0000 (09:24 -0400)]
zebra: Move where we check for non-kernel netlink messages
Move where we check for non-kernel netlink messages to
a slightly earlier spot. This will allow in subsuquent
commits the removal of an extra parameter that needs to
be passed around.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 23 May 2018 12:25:51 +0000 (08:25 -0400)]
zebra: Ignore most netlink notifications from ourselves
The BPF filter was an exclusion list of netlink messages
we did not want to receive from our self. The problem
with this is that the exclusion list was and will be
ever growing. So switch the test around to an inclusion
list since it is shorter and not growing. Right
now this is RTM_NEWADDR and RTM_DELADDR.
Change some of the debug messages to error messages
so that when something slips through and it is unexpected
during development we will see the problem.
Also try to improve the documentation about what
the filter is doing and leave some breadcrumbs for
future developers to know where to change code
when new functionality is added.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 22 May 2018 14:54:20 +0000 (10:54 -0400)]
bgpd: Ensure virt->vrfs is valid
Move the list_delete_and_null of the virt->vrfs code to
the actual deletion function to ensure proper lifecycle.
This assumption allows us to know that irt->vrfs is always
true so remove the NULL check on it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Tue, 22 May 2018 14:50:53 +0000 (10:50 -0400)]
bgpd: Free vni list on actual deletion
The irt->vnis list was being freed on going down,
but actually delete it from the deletion function. Then
we can know that the irt->vnis is a valid list anywhere
we have a irt pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Quentin Young [Wed, 16 May 2018 21:07:54 +0000 (21:07 +0000)]
*: remove -r from daemons except zebra
This option is only implemented by 4 daemons:
- BGPD
- RIPD
- RIPNGD
- Zebra
Manpages and documentation say that the option causes routes to not be
uninstalled from zebra when the daemon terminates. This is true for RIPD
and RIPNGD. This is not true for BGPD; in that daemon it only prevents
transmission of Cease / Peer Unconfig NOTIFICATION messages to peers.
Moreover, when any daemon disconnects from Zebra, all of its routes are
uninstalled from Zebra and the kernel regardless of this option,
rendering the option largely vestigial.
It is still useful in Zebra, where it prevents all routes from being
uninstalled when Zebra shuts down, so it is left there.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Fri, 18 May 2018 19:41:46 +0000 (15:41 -0400)]
zebra: Allow runtime determination of v6 RR semantics
The linux kernel is getting the same Route Replace semantics
for v6 that v4 uses. Allow the end-user to know if their
kernel has this ability and if so to specify it so zebra
can take advantage of this.
Why not do auto-detection? Because you would have to write
code in zebra to add a route then add the same route again
with different nexthops to see if which semantics it is using.
It sure is easier to just add a cli that allows the user to
do it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Quentin Young [Fri, 18 May 2018 19:10:31 +0000 (19:10 +0000)]
doc: fix distclean
Apparently Automake has some undocumented logic somewhere that makes it
so any Makefile generated from an Automake Makefile.am is removed from
its secret list of things to delete that it deletes when performing a
recursive distclean before actually performing the recursive distclean
and since the secret list is automatically generated from the list of
things that Autoconf should generate in configure.ac we can't remove the
Makefile from that list or it will break Automake's list of things to
automatically generate that it generates from Autoconf's list of things
to automatically generate.
Thus, to prevent Automake from deleting Makefiles and then immediately
trying to use the Makefiles it just deleted to delete said Makefiles, we
must remove ourselves from the secret list, which is accomplished by
changing the file extension to '.am' instead of '.in'.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Thu, 17 May 2018 22:46:14 +0000 (18:46 -0400)]
zebra: memset buf to prevent uninited writes into kernel
Setup the buf used for extra data passed into kernel such
that we are cleaning it out before writing data to it,
so we can avoid writing uninited data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Chirag Shah [Tue, 1 May 2018 23:34:31 +0000 (16:34 -0700)]
ospf6d: Fix ECMP for asbr external routes
Use brouter table to fetch nexthops for
asbr prefix (external) routes.
Change adv. router of the router's path once
the DB/FIB is updated with effective nexthops.
Cleanup of nexthop update when route's adv
router changes cost.
Ticket:CM-16139
Testing Done:
Tested ASBR external routes in CLOS topology with
multiple paths asbr originator at tor to spine.
Validated external route's nexthop within
area and inter area.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Donald Sharp [Wed, 16 May 2018 23:24:22 +0000 (19:24 -0400)]
zebra: Convert zrmac->host_list list to a RB Tree
The host_list when we attempt to use it at scale, ends
up spending a non-trivial amount of time finding and
sorting entries for the host list. Convert to a rb tree.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Quentin Young [Thu, 10 May 2018 17:51:08 +0000 (13:51 -0400)]
doc: add "Getting Started" section
While we have docs on various pieces of the build system we don't have
any docs on how to actually get FRR running once it's installed, nor do
we have comprehensive documentation on the basic procedure for building
from source. This patch remedies both of those.
Also updated the services list in the docs and removed the SERVICES file
from the project root.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Pascal Mathis [Wed, 16 May 2018 19:55:55 +0000 (21:55 +0200)]
bgpd: Fix memleak, adapt adv- to recv-routes code
This commit tries to adapt a similar codeflow within the `show bgp [afi]
[safi] neighbor <neighbor> advertised-routes` command compared to its
`received-routes` and `filtered-routes` opponents. Some branching code
has been restructured to achieve this.
Additionally, this commit fixes a memory leak within `received-routes`
(and `filtered-routes`, although the issue has been present before the
previous commit!) where the previous implementation forgot to
deduplicate the BGP attributes.
When a user called `<...> received-routes route-map <RM-TEST>` and that
routemap changed any AS path or community parameters, the duplicated
memory for these parameters was never freed. This has been fixed by
ensuring to call `bgp_attr_undup()` accordingly.
Pascal Mathis [Wed, 16 May 2018 17:17:42 +0000 (19:17 +0200)]
bgpd: Implement new adjacent route show commands
This commit changes the behavior of `show bgp [afi] [safi] neighbor
<neighbor> received-routes [json]` to return all received prefixes
instead of filtering rejected/denied prefixes.
Compared to Cisco and Juniper products, this is the usual way how this
command is supposed to work, as `show bgp [afi] [safi] neighbor
<neighbor> routes` will already return all accepted prefixes.
Additionally, the new command `show bgp [afi] [safi] neighbor <neighbor>
filtered-routes` has been added, which returns a list of all prefixes
that got filtered away, so it can be roughly described as a subset of
"received prefixes - accepted prefixes".
As the already available `filtered_count` variable inside
`show_adj_route` has not been used before, the last output line
summarizing the amount of prefixes found was extended to also mention
the amount of filtered prefixes if present.
projects / mirror / frr.git / log