isisd: don't validate dict integrity for regular builds
This method is intended to be only used for debugging as per the author
and profiling shows we are spending a lot of cycles on it. Remove it for
regular builds by guarding it with a define.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Donald Sharp [Wed, 2 Aug 2017 17:16:51 +0000 (13:16 -0400)]
pimd: Squash some more memory leaks
When a interface is flapped we were leaking some memory
associated with link lists. Especially in the jp_agg
code. If your network was/is stable and you are not
running at any scale you probably would not see this
as impactful at all.
Ticket: CM-16392 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 2 Aug 2017 16:10:50 +0000 (12:10 -0400)]
pimd: Clean back pointer upon deletion
The channel_oil has a back pointer(up) to the upstream data structure.
If we are planning on keeping the channel oil (due to ref count issues)
longer than keeping the upstream, when we delete the upstream we were
not clearing the back pointer to up. This would result in a situation
where if that memory has started to be used again it will cause a
crash and other fun things.
Ticket: CM-17092 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 31 Jul 2017 13:58:42 +0000 (09:58 -0400)]
pimd: Remove almost duplicate pim->ifchannel_list
The pim->ifchannel_list can be duplicated by iterating
over each vrf and then over each pim_ifp->pim_ifchannel_list
Since list handling is taking allot of time at scale
convert over to using this value.
Additionally clean up pim_cmd.c to have helper functions
to handle the actual encoding of data for output.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Renato Westphal [Wed, 2 Aug 2017 01:12:24 +0000 (22:12 -0300)]
lib: fix build from git repository on OpenBSD
The OpenBSD's cp(1) command doesn't support the -v option. This will
change in the next releases (starting from v6.2) but this patch fixes
the problem for v6.1 and older releases.
Donald Sharp [Wed, 2 Aug 2017 00:36:33 +0000 (20:36 -0400)]
lib: Remove sockopt_cork functionality
Linux -> TCP_CORK is enabled by default
*BSD -> The equivalent is TCP_NOPUSH
As such sockopt_cork is effectively useless
especially since the two places it is used
do it right before TCP writes then disable
it right after the writes are over.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Daniel Walton [Tue, 1 Aug 2017 18:31:56 +0000 (18:31 +0000)]
bgpd: multipath change for VRF route is not updated in zebra
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
If you are doing multipath in a VRF and bounce one of the multipaths for
a prefix, bgp is not updating the zebra entry for that prefix with the
new multipaths. We start with:
cel-redxp-10# show bgp vrf RED ipv4 unicast 6.0.0.16/32
BGP routing table entry for 6.0.0.16/32
Paths: (4 available, best #4, table RED)
Advertised to non peer-group peers:
spine-1(swp1) spine-2(swp2) spine-3(swp3) spine-4(swp4)
104 65104 65002
fe80::202:ff:fe00:2d from spine-4(swp4) (6.0.0.12)
(fe80::202:ff:fe00:2d) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 104
AddPath ID: RX 0, TX 21
Last update: Tue Aug 1 18:28:33 2017
101 65104 65002
fe80::202:ff:fe00:21 from spine-1(swp1) (6.0.0.9)
(fe80::202:ff:fe00:21) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 101, best
AddPath ID: RX 0, TX 8
Last update: Tue Aug 1 18:28:33 2017
cel-redxp-10#
cel-redxp-10# show ip route vrf RED 6.0.0.16/32
Routing entry for 6.0.0.16/32
Known via "bgp", distance 20, metric 0, vrf RED, best
Last update 00:00:25 ago
* fe80::202:ff:fe00:21, via swp1
* fe80::202:ff:fe00:25, via swp2
* fe80::202:ff:fe00:29, via swp3
* fe80::202:ff:fe00:2d, via swp4
cel-redxp-10#
And then on spine-1 we bounce all peers
spine-1# clear ip bgp *
spine-1#
On the leaf (cel-redxp-10) we remove the route from spine-1
cel-redxp-10# show ip route vrf RED 6.0.0.16/32
Routing entry for 6.0.0.16/32
Known via "bgp", distance 20, metric 0, vrf RED, best
Last update 00:00:01 ago
* fe80::202:ff:fe00:25, via swp2
* fe80::202:ff:fe00:29, via swp3
* fe80::202:ff:fe00:2d, via swp4
cel-redxp-10#
So far so good. The problem is when the session to spine-1 comes back up
bgp will mark the flag from spine-1 as `multipath` but does not update
zebra. We end up in a state where BGP has 4 paths flags as multipath but
only 3 paths are in the RIB.
Renato Westphal [Tue, 1 Aug 2017 00:37:46 +0000 (21:37 -0300)]
bgpd: don't make any assumptions about the size of an enum
The size of an enum is compiler dependent and thus we shouldn't use
enums inside structures that represent fields of a packet.
Problem detected by the 'test_capability' unit test.
The problem was not apparent before because the 'iana_safi_t' enum didn't
exist and 'safi_t' was a typedef to uint8_t. Now we have two different
enums, 'iana_afi_t' and 'iana_safi_t', and both need to be encoded in
different ways on the wire (2 bytes vs 1 byte).
Renato Westphal [Tue, 1 Aug 2017 00:09:01 +0000 (21:09 -0300)]
lib: remove SAFI_RESERVED_4 and SAFI_RESERVED_5
SAFI values have been a major source of confusion over the last few
years. That's because each SAFI needs to be represented in two different
ways:
* IANA's value used to send/receive packets over the network;
* Internal value used for array indexing.
In the second case, defining reserved values makes no sense because we
don't want to index SAFIs that simply don't exist. The sole purpose of
the internal SAFI values is to remove the gaps we have among the IANA
values, which would represent wasted memory in C arrays. With that said,
remove these reserved SAFIs to avoid further confusion in the future.
Chirag Shah [Mon, 31 Jul 2017 20:12:33 +0000 (13:12 -0700)]
ospf6d: adjust changes per PR 870 review
called list_delete instead of list_free
Moved MTYPE_STATIC in ospfd/zebra.c
Revert changes in ospf6_zebra.c where malloc is called for
multiple nexthops.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Daniel Walton [Mon, 31 Jul 2017 21:22:23 +0000 (21:22 +0000)]
bgpd: peer hash expands until we are out of memory
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
swpX peers all start out with the same sockunion so initially they all
go into the same hash bucket. Once IPv6 ND has worked its magic they
will have different sockunions and will go in different buckets...life
is good.
Until then though, we are in a phase where all swpX peers have the same
socknunion. Once we have HASH_THRESHOLD (10) swpX peers and call
hash_get for a new swpX peer the hash code calls hash_expand(). This
happens because there are more than HASH_THRESHOLD entries in a single
bucket so the logic is "expand the hash to spread things out"...in our
case expanding doesn't spread out the swpX peers because all of their
sockunions are the same.
I looked at having peer_hash_make and peer_hash_same consider the ifname
of the swpX peer but that is a large change that we don't want to make
at the moment. So the fix is to put a cap on how large we are
willing to let the hash table get. By default there is no limit but if
max_size is set we will not allow the hash to expand above that.
* Functions that build TLVs in ospf_te.c and ospf_te.c use 'tlvh + 1'
to move the pointer to the TLV payload ifor strem_put().
* Correct this by using TLV_DATA() macro which is saffer.
zebra: refactor zebra_static_ipv4() and static_ipv6_func()
This is a preliminary step to join both functions into one later.
The main idea here is to make these functions have separate arguments
for the nexthop address and the nexthop interface, and adjust the call
sites appropriately. Having an argument that could be a nexthop address
OR a nexthop interface was making the code very hard to follow. With
this simplification, a lot of code duplication was removed and now both
functions look very similar.
zebra: accept static v6 routes with non-existent nexthop interfaces
We don't need to enforce that the interface exists because the route can
be activated later once the interface becomes available. We already do
this for IPv4 routes and IPv6 routes with both a nexthop address and a
nexthop interface.