In the route_entry we are keeping a non pointer based
nexthop group, switch the code to use a pointer for all
operations here and ensure we create and delete the memory.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add some base functionality so we can verify we are getting messages
about nexthops from the kernel.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
The linux kernel is adding support for nexthop groups. Update our
includes to reflect new types and structs we should be listening
for from the kernel.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add some code to allow us to do lookups and releases of
nexthop groups from zebra. At this point we do not do anything
with it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We need to track if a nexthop group is valid and installed,
so create some basic flags to track this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit does nothing more than just create a hash structure
that we will use to track nexthop groups.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The result variable was already tested against PIM_GROUP_BAD_ADDR_MASK_COMBO
earlier in the function. No need to do the same thing twice.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
All paths leading to this point in the code have already deref'ed
the pim->global_scope.bsrp_table. No point in testing for
validness now. This was caught by Coverity.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We passed peer as NULL and nothing happened.
exit2-debian-9# conf
exit2-debian-9(config)# int gre1
exit2-debian-9(config-if)# ip nhrp map 1.1.1.1 local
exit2-debian-9(config-if)# ip nhrp map 2.2.2.2 3.3.3.3
exit2-debian-9(config-if)# do sh run
...
!
interface gre1
ip nhrp map 1.1.1.1 local
ip nhrp map 2.2.2.2 3.3.3.3
!
...
exit2-debian-9(config-if)# no ip nhrp map 1.1.1.1
exit2-debian-9(config-if)# do sh run
...
!
interface gre1
ip nhrp map 2.2.2.2 3.3.3.3
!
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
The pim_msg_send() return code was not being checked. Make
consistent with it's usage everywhere else.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported with error messages appearing in the log
complaining about invalid afi/safi combinations. Determined
that the error messages were recently added in the function
that turns afi and safi values to strings. Unfortunately,
the function is called from places using FOREACH_AFI_SAFI,
which spins thru every afi and safi number including some
that are not legal together (ipv4 evpn and l2vpn multicast
for example.) This fix removes these error messages since
it is not necessarily an error to call it with invalid
combinations.
Ticket: CM-26883
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
with network namespace vrf backend, there is possibilities that the same
interface name can be used across two different vrfs. Then, enforce the
check when static daemon receives interface events. Adding to the
interface name, check for the vrf id, too.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Due to some extremely shoddy programming on my part, the error messages
for certain errors was pretty much always wrong. We would start with the
correct error message, then on the next check, regardless of whether it
passed or failed, we would null out the error message, then on the next
one set it again (to the wrong message), then null it, and just keep
alternating. So errors were sometimes not being reported, sometimes
being reported correctly (if the condition parity happened to match the
appropriate condition), and sometimes being reported correctly.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Traffic Engineering parameters are correctly advertised in LSP when
'mpls-te on' CLI command is present in the startup config file.
However, if IS-IS is started without TE enable at startup and
'mpls-te on' command is issued after, TE link parameters are never
announced. The patch correct this issue.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
Since we don't have a daemon who's job is to handle kernel
routes and we don't get an explicit route delete anymore if
nexthops become unreachable from the kernel, zebra must
re-process kernel routes itself to make sure they are still valid.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We can assume that system/kernel routes are valid indeed
if this is our first time procesing them. But since we don't
get explicit deletion events for kernel routes anymore, we
have to be prepared to process them if the nexthop becomes
unreachable for instance. Therefore, if the route is not NEW,
then don't assume its valid.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
If we need to batch process the rib (all tables or specific
vrf), do so as a scheduled thread event rather than immediately
handling it. Further, add context to the events so that you
narrow down to certain route types you want to reprocess.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
