When P and Q spaces are adjacent then it makes sense to use adjacency SIDs to
from the P node to the Q node. There are some other corner cases where this
makes also sense like when a P/Q node adjacent to root node.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
A reverse SPF is important in the context of TI-LFA, e.g. for
computing so called Q spaces. In case the weights of the links are
symmetric there is no difference to the 'normal' SPF and hence this
patch is really just needed for the case with asymmetric link
weights.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
The raw zapi apis to encode and decode NHGs don't need to be
public; also add a little more validity-checking.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
1. Added 7 testcases to verify PIM BSM functionality. Here we have used Scapy
to send raw packet, generated using Cisco and FRR. Raw packets are kept in
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
1. Scapy, is a python tool, which would be used in multicast-pim-bsm-topo1
suite automation. We have some BSM raw packets captured and saved in
JSON file, these packets would be sent using scapy on tests demands.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
1. Added 8 testcases to verify PIM BSM functionality. Here we have used Scapy
to send raw packet, generated using Cisco and FRR. Raw packets are kept in
JSON file and sent tests on-demand in script.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
The `struct ecommunity` structure is using an int for a size value.
Let's switch it over to a uint32_t for size values since a size
value for data can never be negative.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Calling fpm_nl_enqueue we should expect a it fit or not
return value on the outgoing stream. This is not necessary
to check here because the while loop where we are checking this
already has ensured that the data being written will fit.
CID -> 1499854
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
the pnhi data structure can receive either a interface or a
nhr data structure. Ensure that we don't crash.
CID -> 1500586
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In the function bgp_adj_out_set_subgroup, the attr pointer
is already derefed in all paths leading to a test for NULL.
You cannot pass a NULL attribute in since the whole function
would just immediately crash.
CID -> 1500604
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Tests were timing out in our test system due to lost packets and
flakiness of the lower end systems. Just set the timers to 3/10
and give them plenty of time to converge.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Setting `zebra route-map delay-timer 0` completely turns of any
route-map processing in zebra. Which is completely wrong. A timer
of 0 means `do it now`.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
New test does this:
a) Ensures that we run the correct number of times given two
`ip protocol X` commands( ie we do not run the route-map application
against all routes, only those affected )
b) Ensure that when we modify the route-map the state ends up sane
this includes making a static route depend on a sharp route that
gets removed from the change of the sharp route-map
c) Ensure that the kernel routes are correct.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If we are running with a delayed timer to handle route-map changes
in zebra, if another route-map change is made to the cli, push
out the timer instead of not modifying the timer. This will
allow a large set of route-maps to be possibly be read in by
the system and we don't have a state where new route-map
changes are being read in and having the timer pop in
the middle of it.
Additionally convert to use THREAD_OFF, preventing a possible
use after free as well as aligning the thread api usage
with what we consider correct.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Current code when a route map changes schedules a rerun of all routes in the
particular table. So if you modify the `ip protocol XX route-map FOO`
route-map `FOO` all routes will be rechecked. This is extremely expensive.
Modify zebra to only update the routes associated with the route-map. So
if we have 800k bgp routes and 50 ospf routes and we are route-map'ing
the ospf routes we'll only look at 50 routes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we need to cause a reprocessing of data the code currently
marks all routes as needing to be looked at. Modify the
rib_update_table code to allow us to specify a specific route
type we only want to reprocess. At this point none
of the code is behaving differently this is just setup
for a future code change.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When the routemap code was rewritten for performance the
code to track the number of times a particular section of
a route-map was applied was not correctly updated. In
this case I found another sequence of events where the
number of times a section was invoked was not being correctly
kept.
Effectively in this case when route_map_get_index is called
and returns an index the route map has been applied( see that
skip_match_clause is set to true and then in the for loop
below the skip_match_clause is tested and index->applied is
incremented.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Commit 220e848cc5 introduced an optimization that would prevent ldpd
from sending redundant label mappings when it receives notifications
from zebra about routes that didn't effectively change (such
notifications can happen under certain circumstances).
The problem is that that commit didn't take into account the metric
of the received routes, so it would dismiss a notification of a
route with a better metric taking the place of another route in the
RIB, preventing the newly selected route from receiving the label
mappings it needs.
Revert 220e848cc5 temporarily to fix sporadic failures in the CI
system until we have a better solution.
Debugged-by: Lynne Morrison lynne@voltanet.io
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Use nl_pid from the netlink socket used for programming the kernel
(netlink_dplane) in netlink route messages sent by the 'fpm' module.
This makes 'fpm' consistent with 'dplane_fpm_nl' which already
behaves this way, and allows FPM server implementations to determine
route origin via nlmsg_pid.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
