Donald Sharp [Thu, 7 Jun 2018 21:10:38 +0000 (17:10 -0400)]
bgpd: Actually display labeled unicast routes received
The labeled unicast and unicast tables have been combined
into the unicast table. Additionally we have a restriction
where if you configure labeled unicast you cannot configure
unicast. This created a bug with 'show bgp ipv4 labeled-unicast summ'
command where we were displaying NoNeg, because v4 has been intentionally
turned off.
Modify the code so that when we are looking up if we have negotiated
a capapbility we use the correct one, while still using the appropriate
table for prefix count.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Renato Westphal [Thu, 7 Jun 2018 18:45:33 +0000 (15:45 -0300)]
zebra: remove unnecessary preprocessor check
The IFLA_INFO_SLAVE_KIND constant is always defined now that we imported
our own copies of the Linux kernel headers. Remove the preprocessor
checks since they aren't necessary anymore.
Donald Sharp [Fri, 1 Jun 2018 00:51:43 +0000 (20:51 -0400)]
ospfd: Note that we do not care about self origination in this case
When we first get a packet, we need to know if we are self
originated later to make correct decisions. Go ahead and
note that we do not plan to make any decision points
about our self origination here.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 31 May 2018 16:56:21 +0000 (12:56 -0400)]
bgpd: Actually release peer from bgp_peer hash
When we are determining the state of a peer, we sometimes
detect that we should update the peer->su. The bgp->peer_hash
keeps a hash of peers based upon the peer->su. This requires
us to release the stored value before we re-insert it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Renato Westphal [Sun, 3 Jun 2018 01:00:32 +0000 (22:00 -0300)]
build: append -std=gnu99 after SNMP_CFLAGS
Programs that link to libnetsnmp must be compiled using a special set
of flags as specified by the "net-snmp-config --base-cflags" command
(whose output is stored in the SNMP_CFLAGS variable). The problem is
that "net-snmp-config --base-cflags" can output -std=c99 in addition to
other compiler flags in some platforms, and this breaks the build since
FRR souce code makes use of some GNU compiler extensions (e.g. allow
trailing commas in function parameter lists). In order to solve this
problem, append -std=gnu99 after SNMP_CFLAGS in all makefiles where this
variable is used. This way the -std=c99 flag will be overwritten when it's
present. Source files that don't link to libnetsnmp will be compiled using
either -std=gnu99 or -std=gnu11 depending on the compiler availability.
Quentin Young [Fri, 1 Jun 2018 19:25:03 +0000 (19:25 +0000)]
vtysh: fix potential stack buffer overflow
If vtysh was instructed to perform line-by-line processing on the output
of a command executed against a daemon and this output, as received by
vtysh, was not terminated with a newline, vtysh could print contents of
memory to its output device.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Fri, 1 Jun 2018 19:03:57 +0000 (15:03 -0400)]
bgpd: Deprecate and hide the `no bgp multiple-instance` command
This command needs to be deprecated. It partially implements
a refusal to create multiple instances. If you do not need
multiple instances, just don't create them in the cli instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Philippe Guibert [Thu, 17 May 2018 13:34:51 +0000 (15:34 +0200)]
zebra: keep one command to handle vty with/without table param
That fix is a workaround from a vtysh limitation.
Because table identifier should be accessible in configuration only for
vrf netns backends, there was a need to differentiate the vty commands.
Unfortunately, vtysh parses the two commands without knowing which
command has really been installed.
Using one single vty command will avoid having this issue in vtysh.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Wed, 28 Mar 2018 08:46:14 +0000 (10:46 +0200)]
zebra: table_id election with the vrf backend
As table_id for VRF with netns backend is main table ( RT_TABLE_MAIN or
zebrad.rtm_table_default), this makes possible to return the table id
that wants to be configured for those cases. ( in addition to default
VRF). In other cases ( VRF Lite presumably), then vrf table_id is
returned.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Wed, 30 May 2018 09:46:13 +0000 (11:46 +0200)]
doc: replace 'intact' keyword with something more clear
Keeping the config intact might be misunderstood. I say that even if VRF
netns is automatically discovered, it is possible for administrator to
save the netns information in the config file, to bring more clarity (
hence the config commands available).
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Wed, 30 May 2018 09:38:24 +0000 (11:38 +0200)]
doc: inform the diff between config from zebra and outside
To avoid some confusions, it is precised in the documentation that
the configuration not done from zebra will not be injected in the
configuration context. As consequence, the config file will not be
impacted by underlying network context. But also, this will not be
possible for *Zebra* to attempt to modify outside networking objects.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Wed, 30 May 2018 22:17:17 +0000 (18:17 -0400)]
bgpd: Lock originating bgp pointer for vrf route leaking
There exists cases where we will attempt to hard delete
the bgp instance( say a `no router bgp` is issued )
when we have vrf route leaking. If we do have this
lock the bgp instance of the originator and do not
let it be deleted out from under us until we are
finished processing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 31 May 2018 13:37:34 +0000 (09:37 -0400)]
bgpd: Fix SA issue with uninited ifindex value
The rearrangement of where the decision point of
filling in the aggregate information, must have allowed
SA to find a path of code where we may use ifindex uninitialized.
While I don't think this is possible to happen, make this issue
go away.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 30 May 2018 13:37:03 +0000 (09:37 -0400)]
bgpd: Notice when peer_clear fails
Issue Found by Coverity Scan. When we call peer_clear we
are checking the return code in every other call. Add
a bit of extra code to notice the failure and note it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 17 May 2018 11:58:02 +0000 (07:58 -0400)]
redhat: Make watchfrr the default
With systemd being the default on more systems now, lets
configure watchfrr to start else systemd systems on
redhat will not stay up for more than 1 minute.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 30 May 2018 00:04:17 +0000 (20:04 -0400)]
bgpd: Add null0 route back for aggregate-address route created.
The aggregate-address command is not creating the null0
route. This got lost somewhere in the last year or so.
Add this ability back for BGP route installs into
zebra.
We need this aggregate route installed into the rib
because we are drawing this traffic to us irrelevant
of the number of routes we do have for that prefix.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Pascal Mathis [Mon, 28 May 2018 16:50:52 +0000 (18:50 +0200)]
tests: Improve test suite for peer attributes
This commit improves the previous implementation of the peer attribute
test suite by getting rid of some really ugly macros and replacing them
with sane functions.
Additionally, the macro TEST_ASSERT was changed to TEST_ASSERT_EQ (==
comparison) which now also prints the line where the assertion has been
infringend. This should make it way more clear where a specific issue
has been spotted.
Last but not least, the multicast families for both IPv4 and IPv6 had
been added as they are working without any further changes or special
cases for all currently existing peer attributes. Other AFI/SAFI
references have been removed to keep the code clean.
Pascal Mathis [Sun, 27 May 2018 17:36:48 +0000 (19:36 +0200)]
bgpd: Fix style issues for peer-group overrides
This commit fixes all outstanding style/formatting issues as detected by
'git clang-format' or 'checkpath' for the new peer-group override
implementation, which spanned across several commits.
Pascal Mathis [Sun, 27 May 2018 17:23:57 +0000 (19:23 +0200)]
bgpd: Fix group overrides for AF flags/filters
The previous commit introduced very strict unit tests which check all
three involved components (config input, config output, internal data
structures) which revealed two more bugs in the peer-group override
implementation.
This commit fixes overrides for 'allowas-in <number>' and
'unsuppress-map', which both had a small mistake/typo causing those
issues.
Pascal Mathis [Sun, 27 May 2018 15:52:19 +0000 (17:52 +0200)]
tests: Add tests for overriding BGP peer attrs
This commit introduces unit tests for BGP peer attributes and checks all
three involved components, which are:
- CLI Configuration Input: The appropriate commands to configure the
attribute on either a peer or peer-group are being executed the same way
an end user would do it.
- CLI Configuration Output: The output of 'show running-config' is being
checked for presence/absence of expected configuration strings.
- Internal Data Structures: The internal data structures for maintaining
flag/filter states (value + override + invert) are being checked after
each operation to ensure the override has been implemented properly.
All attributes to be tested must be defined within the 'peer_attrs'
structure, which contains all peer attributes as of today and checks
them with both IPv4 Unicast and IPv6 Unicast. More address families are
supposed to be introduced at a later point in time.
Each attribute is being checked in its own 'clean' BGP environment, so
everything gets reset after each attribute to avoid any weird edge
cases. The 'correct' BGP startup and shutdown routine was taken from
'bgp_main.c' to ensure that we are not leaking any memory or acting
different than the real 'bgpd' would do.
Pascal Mathis [Sun, 27 May 2018 15:39:45 +0000 (17:39 +0200)]
bgpd: Fix group overrides for inverted AF flags
This commit fixes peer-group overrides for inverted AF flags. This
implementation is currently only being used by the three 'send-community'
flags. Commit 70ee29b4d introduced generic support for overriding AF
flags, but did not support inverted flags.
By introducing an additional array on the BGP peer structure called
'af_flags_invert' all current and future flags which should work in an
inverted way can now also be properly overridden.
The CLI commands will work exactly the same way as before, just that 'no
<command>' now sets the flag and override whereas '<command>' will unset
the flag and remove the override.
Pascal Mathis [Mon, 21 May 2018 10:09:25 +0000 (12:09 +0200)]
bgpd: Improve group overrides for AF filters
This commit adds the same peer-group override capabilites as d122d7cf7
for all filter/map options that can be enabled/disabled on each
address-family of a BGP peer.
All currently existing filter/map options are being supported:
filter-list, distribute-list, prefix-list, route-map and unsuppress-map
To implement this behavior, a new peer attribute 'filter_override' has
been added together with various PEER_FT_ (filter type) constants for
tracking the state of each filter in the same way as it is being done
with 'af_flags_override'.
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>