The gRPC code paths uses different functions than the BGP code path.
Thus is did not receive the fix for the mac mobility handling.
Fixes: c393f43 ("evpn: fix quadratic evpn mac-mobility handling")
- Changes table.(*packerV4).pack.func1 (split) to adjust the max
parameter before using it to allocate slice size. Previously the full
max size was allocated then max was (possibly) truncated before
further use.
Moves a number of heavily called debug lines behind if checks to avoid
needless allocations of Fields objects and stringification of fields.
For cases where the server is not set to "debug" log level, these fields
were allocated on the heap and then immediately discarded - as well a
number of these were stringifying state / NLRIs regardless of log level.
In servers with significant amounts of routes and BGP peers, this lead
to a large amount of wasted allocations - in our case looking at Go's
memory profiler, 25% of all allocations were from these lines alone.
This patch adds a special case in the destination hashmap for EVPN
Type-2 routes, to index them by MAC address. This allows for direct
access to the destination struct, instead of iterating over all
destination and all paths.
In effect, this replaces an iteration over all known paths by a quick
lookup to the MAC, leaving only an iteration to multiple paths to the
same MAC (e.g. multihoming or through multiple VNIs).
The practical effect is a reasonable convergence time for large EVPN
instances.
- before: 6m 7s
- after: 11s
The comparison was performed on a Xeon Silver 4209T, and an EVPN
instance comprising of 13k EVPN type-2 routes. The time is measured
by comparing the timestamp of the first and the last routes logged by
the cli's monitor mode.
Given the extreme difference, no further work was done for a more
accurate measurment.
When ListPathRequest is done by a gRPC client including a malformed prefix,
the server would crash an invalid memory address reference.
This commit fixes the crash by checking whether the parseCIDR method returned
an error.
Fix TEID processing in Type 2 ST Route:
- TEID can be 0-32 bits value as described in I-D.
Accept hex and IPv4 format for TEID in CLI and show TEID as IPv4 format in CLI.
- TEID is generally represented in hexadecimal format.
- IPv4 format is useful because Type 2 ST Route can be used in the longest match algorithm as described in I-D.
It saves a lot of resources when there is a lot of communities to match against,
say hundreds of RTs. The same approach is used in some other conditions,
ex. AsPathCondition.
ToLocal() is used to copy Path in rib for advertising/exporting via
API (like ListPath). Needs to copy PathId.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
gobgp is tightly coupled with logrus and uses the global logrus logger
instance. The uses of gobgp library can't use other logging libraries.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
seems that sticking to Go API v1 for protobuf is headache for projects
using GoBGP.
This breaks the compatibility so bumps up the major version to 3.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
whereby MP-capable peer uses MP_REACH_NLRI to send updates to gobgp
gobgp accepts it but without setting NEXT_HOP pathattr
then gobgp propagates the paths to the non-MP-capable peer with update.NLRI set but without NEXT_HOP
the non-MP-capable peer will treat the update as withdraw message cause routes cannot propagate properly
