Add these file and introduce some new fundamental types
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Donnie Savage <diivious@hotmail.com>
Rename struct eigrp_nexthop_entry to struct eigrp_route_descriptor
Rename struct eigrp_prefix_entry to struct eigrp_prefix_descriptor
Fix all the associated function names as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Donnie SAvage <diivious@hotmail.com>
Move the prototypes for eigrp_yang that are in eigrpd.h
into eigrp_yang.h.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Donnie Savage <diivious@hotmail.com>
Move the forward declarations for eigrp_cli.c from eigrpd.h
into eigrp_cli.h.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Donnie Savage <diivious@hotmail.com>
The `struct eigrp_master` data structure belongs in the
eigrpd.h file. Move it over, in addition start forward
thinking about the different TLV versions so we can
track them better in the future.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Donnie Savage <diivious@hotmail.com>
Issue:
The bgp routes learnt from peers which are not installed in kernel are
advertised to peers. This can cause routers to send traffic to these
destinations only to get dropped. The fix is to provide a configurable
option "bgp suppress-fib-pending". When the option is enabled, bgp will
advertise routes only if it these are successfully installed in kernel.
Fix (Part1) :
* Added message ZEBRA_ROUTE_NOTIFY_REQUEST used by client to request
FIB install status for routes
* Added AFI/SAFI to ZAPI messages
* Modified the functions zapi_route_notify_decode(), zsend_route_notify_owner()
and route_notify_internal() to include AFI, SAFI as parameters
Signed-off-by: kssoman <somanks@gmail.com>
Replace all lib/thread cancel macros, use thread_cancel()
everywhere. Only the THREAD_OFF macro and thread_cancel() api are
supported. Also adjust thread_cancel_async() to NULL caller's pointer (if
present).
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Change thread_cancel to take a ** to an event, NULL-check
before dereferencing, and NULL the caller's pointer. Update
many callers to use the new signature.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Currently eigrp has a bunch of commands that are not fully
implemented yet. Tone down the yang code change of making
these in your face errors to zlog_warns, so the end-user
can not be freaked out by the message.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We have this pattern in the code base:
if (thread)
THREAD_OFF(thread);
If we look at THREAD_OFF we check to see if thread
is non-null too. So we have a double check.
This is unnecessary. Convert to just using THREAD_OFF
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
DEFPY_YANG will allow the CLI to identify which commands are
YANG-modeled or not before executing them. This is going to be
useful for the upcoming configuration back-off timer work that
needs to commit pending configuration changes before executing a
command that isn't YANG-modeled.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Remove mid-string line breaks, cf. workflow doc:
.. [#tool_style_conflicts] For example, lines over 80 characters are allowed
for text strings to make it possible to search the code for them: please
see `Linux kernel style (breaking long lines and strings)
<https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_
and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_.
Scripted commit, idempotent to running:
```
python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'`
```
Signed-off-by: David Lamparter <equinox@diac24.net>
These are easy to get subtly wrong, and doing so can cause
nondeterministic failures when racing in parallel builds.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Having a fixed set of parameters for each northbound callback isn't a
good idea since it makes it difficult to add new parameters whenever
that becomes necessary, as several hundreds or thousands of existing
callbacks need to be updated accordingly.
To remediate this issue, this commit changes the signature of all
northbound callbacks to have a single parameter: a pointer to a
'nb_cb_x_args' structure (where x is different for each type
of callback). These structures encapsulate all real parameters
(both input and output) the callbacks need to have access to. And
adding a new parameter to a given callback is as simple as adding
a new field to the corresponding 'nb_cb_x_args' structure, without
needing to update any instance of that callback in any daemon.
This commit includes a .cocci semantic patch that can be used to
update old code to the new format automatically.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
And again for the name. Why on earth would we centralize this, just so
people can forget to update it?
Signed-off-by: David Lamparter <equinox@diac24.net>
Same as before, instead of shoving this into a big central list we can
just put the parent node in cmd_node.
Signed-off-by: David Lamparter <equinox@diac24.net>
There is really no reason to not put this in the cmd_node.
And while we're add it, rename from pointless ".func" to ".config_write".
[v2: fix forgotten ldpd config_write]
Signed-off-by: David Lamparter <equinox@diac24.net>
The only nodes that have this as 0 don't have a "->func" anyway, so the
entire thing is really just pointless.
Signed-off-by: David Lamparter <equinox@diac24.net>
The vrrpd one conflicts with the standalone vrrpd package; also we're
installing daemons to /usr/lib/frr on some systems so they're not on
PATH.
Signed-off-by: David Lamparter <equinox@diac24.net>
Commit: ddbf3e6060
This commit modified the interface up handling code in
ZAPI such that the zclient handled the decoding for you.
Prior to this commit ospf assumed that it could use the
old ifp pointer to know state before reading the stream.
This lead to a situation where ospf would `smartly` track
and do the right thing in this situation. This commit
changed this assumption and in certain scenarios, say
a interface was changed after it was already up would
lead to situations where ospf would not properly handle
the new interface up.
Modify ospf to track data that is important to it in
it's interface->info pointer.
This code pattern was followed in both eigrp and pim.
In eigrp's case it was just behaving weirdly in any event
so fixing this pattern is not a big deal. In pim's
case it was not properly using this so it's a no-op
to fix.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This function was excessively complicated. Simplify and
make everyone use the same access macro.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Use a local variable to avoid trying to take the address
of a packed struct member - an address from the ip header
in these cases.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
For all the places we have a zclient->interface_up convert
them to use the interface ifp_up callback instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Switch the zclient->interface_add functionality to have everyone
use the interface create callback in lib/if.c
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Start the conversion to allow zapi interface callbacks to be
controlled like vrf creation/destruction/change callbacks.
This will allow us to consolidate control into the interface.c
instead of having each daemon read the stream and react accordingly.
This will hopefully reduce a bunch of cut-n-paste stuff
Create 4 new callback functions that will be controlled by
lib/if.c
create -> A upper level protocol receives an interface creation event
The ifp is brand spanking newly created in the system.
up -> A upper level protocol receives a interface up event
This means the interface is up and ready to go.
down -> A upper level protocol receives a interface down
destroy -> A upper level protocol receives a destroy event
This means to delete the pointers associated with it.
At this point this is just boilerplate setup for future commits.
There is no new functionality.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
User pass the string match large-community 1 exact-match from CLI.
Now route map lib has got the string as "1 exact-match". It passes the string
to call back for compilation. BGP will parse this string and came to know
that for "1" it has to do exact match. Routemap lib has to save "1" in it’s
dependency table. Here routemap is saving this as a “1 exact-match”
which is wrong. The solution is used the compiled data.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
We assign a value to the eigrp data structure and then
immediately overwrite it in the for loop. No need to
do a eigrp_lookup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Conver these functions:
route_map_add_match
route_map_delete_match
route_map_add_set
route_map_delete_set
To return the `enum rmap_compile_rets` and ensure all functions
that use this code handle all the enumerated possible returns.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the cli to allow us to specify the [vrf NAME]
and also get rid of the usages of VRF_DEFAULT that we can.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Push out the pass in of struct eigrp to all functions
in eigrp_topology.c so we do not lookup the eigrp pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to parse `router eigrp AS [vrf NAME]` and
modify eigrp_lookup to actually handle a vrf_id for us.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For those places where we can immediately transform the usage
of VRF_DEFAULT to eigrp->vrf_id do so.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Move all configuration commands to the new CLI code (`eigrp_cli.c`),
implement the northbound and do all the necessary wiring to get it
working.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away
State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH
We require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Net prefixes in eigrp update packets is created and read
without check host endianness.
This patch use ntohl and htonl to read and write ip prefix
from and to packet.
Tested: x86, powerpc
Signed-off-by: Pawel Dembicki <p.dembicki@wb.com.pl>
the vrf_id parameter is replaced by struct vrf * parameter.
this impacts most of the daemons that look for an interface based on the
name and the vrf identifier.
Also, it fixes 2 lookup calls in zebra and sharpd, where the vrf_id was
ignored until now.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Say, more than one sequence of a route-map uses the same named entity
in its match clause. After that entity is removed from any one of the
route-map sequences, any further changes made to that entity doesn't
dynamically take effect.
A reference counter, that allows the named entity to keep a count of
the route-maps dependent on it, has been introduced to address this issue.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH)
State1: Receveived RMAP_MATCH
THEN: If Routemap type is PERMIT, execute other rules if applicable,
otherwise we PERMIT!
Else: If Routemap type is DENY, we DENYMATCH right away
State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise,
return DENYMATCH by default if nothing matched.
With reference to PR 4078 (https://github.com/FRRouting/frr/pull/4078),
we require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP (or another enum) to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR
as the 3rd state (or create a new enum like RMAP_NOOP)?
RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd.
We chose to go with RMAP_NOOP (but open to ideas),
as a way to bypass the rmap filter
As a result we have a 3rd state:
State3: Received RMAP_NOOP
Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default.
Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
This macro:
- Marks ZAPI callbacks for readability
- Standardizes argument names
- Makes it simple to add ZAPI arguments in the future
- Ensures proper types
- Looks better
- Shortens function declarations
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
an interface rmap context can be created from a custom name string,
instead of a vrf. This ability permits to handle several instances of
interface route map in the same vrf. The naming convention will be
transparent on what the name is for in the daemon code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
so as to handle ri/ripng/eigrp multiple instances, the need is to
encapsulate if_rmap hash table into a container context self to each
instance. This work then reviews the if_rmap api, mainly by adding a
if_rmap_ctx context, that is passed for each exchange between library
and the daemon.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
On interface down do not delete the eigrp interface data
structure. Ensure that the address that we have setup the
eigrp data structure ontop of is what we are deleting.
Additionally add a test to show that this is no-longer
crashing eigrp. Future commits will further modify
this test to actually ensure that the eigrp topo is
updated correctly and the rib has the correct data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The ref count for the eigrp topology table was incorrect in a couple
of spots. Let's clean it up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The prefix data structure was being freed yet still needed in the
future and it's a fundamental part of the eigrp_interface data
structure let's keep it there instead of having it be deleted
and then not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This command was crashing. This fixes the crash
we are still not behaving quite correctly on
handling routes we have learned from those peers
covered by the network statement.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify EIGRP code to pass its used metric down to zebra.
Additionally update topotests to pass with these changes.
Fixes: #3703
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- some target_CFLAGS that needed to include AM_CFLAGS didn't do so
- libyang/sysrepo/sqlite3/confd CFLAGS + LIBS weren't used at all
- consistently use $(FOO_CFLAGS) instead of @FOO_CFLAGS@
- 2 dependencies were missing for clippy
Signed-off-by: David Lamparter <equinox@diac24.net>
Some daemons like ospfd and isisd have the ability to advertise a
default route to their peers only if one exists in the RIB. This
is what the "default-information originate" commands do when used
without the "always" parameter.
For that to work, these daemons use the ZEBRA_REDISTRIBUTE_DEFAULT_ADD
message to request default route information to zebra. The problem
is that this message didn't have an AFI parameter, so a default route
from any address-family would satisfy the requests from both daemons
(e.g. ::/0 would trigger ospfd to advertise a default route to its
peers, and 0.0.0.0/0 would trigger isisd to advertise a default route
to its IPv6 peers).
Fix this by adding an AFI parameter to the
ZEBRA_REDISTRIBUTE_DEFAULT_{ADD,DELETE} messages and making the
corresponding code changes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This code addition allows eigrp to set/unset the router-id
value. At this point I am not 100% sure that we do all the necessary
rework when a router-id changes. But on startup if read in before
a network statement we should be ok.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In eigrp we were using a uint32_t to hold the `struct in_addr` data
for the router id values. This caused us to do unnecessary conversions
pre and post for in/out. Let's just use the standard `struct in_addr`
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Let's write the eigrp config even if we have no network statements
as that the other functions return safely if nothing to do here.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
a distribute_ctx context pointer is returned after initialisation to the
calling daemon. this context pointer will be further used to do
discussion with distribute service. Today, there is no specific problem
with old api, since the pointer is the same in all the memory process.
but the pointer will be different if we have multiple instances. Right
now, this is not the case, but if that happens, that work will be used
for that.
distribute-list initialisation is split in two. the vty initialisation
is done at global level, while the context initialisation is done for
each routing daemon instance.
babel daemon is being equipped with a routing returning the main babel
instance.
also, a delete routine is available when the daemon routing instance is
suppressed.
a list of contexts is used inside distribute_list. This will permit
distribute_list utility to handle in the same daemon to handle more than
one context. This will be very useful in the vrf context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
cf. https://wiki.debian.org/NonFreeIETFDocuments
These MIBs were in our git purely for documentation purposes, they are
not installed and not needed for building SNMP support.
Signed-off-by: David Lamparter <equinox@diac24.net>
It's been a year since we added the new optional parameters
to instantiation. Let's switch over to the new name.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Introduce frr-interface.yang, which defines a model for managing FRR
interfaces.
Update the 'frr_yang_module_info' array of all daemons that will
implement this module.
Add automatically generated stub callbacks in if.c. These callbacks will
be implemented in the following commit.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
FRR_DAEMON_INFO should now contain an array of 'frr_yang_module_info'
structures describing the YANG modules implemented by the daemon.
This array will be used by frr_init() function to load all YANG modules
and initialize the northbound callbacks during the daemon initialization.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The bandwidth command was not properly reading cli input
and would do weird stuff with the input.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The keychain authentication code under eigrp was
using the wrong argv numbers for keychain lookup. Convert
to DEFPY.
I do not actually know if this allows eigrp authentication to
work. But this connects up a bit more of the pieces if it does.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
During shutdown we were not properly cleaning up some memory
as reported by valgrind. Additionally during cleanup operations
I noticed that there were some dead/unused functions remove/reduce.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The eigrp interface structure was storing a pointer to the
connected interface structure and on shutdown of an interface
this would cause zebra to call eigrp back with a shutdown of
that interface, as part of that operation the connected interface
structure is being deleted, but eigrp was keeping a pointer to
the connected structure. At the same time we were keeping the address
of the connected structure and this is all we need, so keep a copy
of that data and use that instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
config.h (or, transitively, zebra.h) must be the first include file
listed for autoconf things like _GNU_SOURCE and _POSIX_C_SOURCE to work
correctly.
Signed-off-by: David Lamparter <equinox@diac24.net>
Since we're now building through one large Makefile, we can easily put
things with their daemons and crossreference nicely.
Signed-off-by: David Lamparter <equinox@diac24.net>
The Vrf aliases can be known with a specific hook. That hook will then,
from zebra propagate the information to the relevant zapi clients.
The registration hook function is the same for all daemons.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
