The previous workaround only works for -O0, at higher optimization
levels gcc reorders the statements in the file global scope which breaks
the asm statement :(.
Fixes: #4563Fixes: #5074
Signed-off-by: David Lamparter <equinox@diac24.net>
gcc 4.x does not properly support structs with variable length array
members. Specifically, for global variables, it completely ignores the
array, coming up with a size much smaller than what is correct. This is
broken for both sizeof() as well as ELF object size.
This breaks for frr_interface_info since this variable is in some cases
copy relocated by the linker. (The linker does this to make the address
of the variable a "constant" for the main program.) This copying uses
the ELF object size, thereby copying only the non-array part of the
struct.
Breakage ensues...
(This fix is a bit ugly, but it's limited to very old gcc, and it's
better than changing the array to "nodes[1000]" and wasting memory...)
Fixes: #4563Fixes: #5074
Signed-off-by: David Lamparter <equinox@diac24.net>
Add some apis that allocate and init nexthop objects
from various kinds of arguments: ip addrs, interfaces,
blackhole types.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
By default announct Self Type-2 routes with
system IP as nexthop and system MAC as
nexthop.
An API to check type-2 is self route via
checking ipv4/ipv6 address from connected interfaces list.
An API to extract RMAC and nexthop for type-2
routes based on advertise-svi-ip knob is enabled.
When advertise-pip is enabled/disabled, trigger type-2
route update. For self type-2 routes to use
anycast or individual (rmac, nexthop) addresses.
Ticket:CM-26190
Reviewed By:
Testing Done:
Enable 'advertise-svi-ip' knob in bgp default instance.
the vrf instance svi ip is advertised with nexthop
as default instance router-id and RMAC as system MAC.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
some vty no operations were not removing the entry of the access-list,
since the access-list name was not retrieved correctly. the index was
not correct for 'no ipv6 access-list WORD' operations, but also for one 'no
access-list WORD [..] any' operation.
PR=66244
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Acked-by: Alain Ritoux <alain.ritoux@6wind.com>
This includes:
1. Processing client Registrations for MLAG
2. storing client Interests for MLAG updates
3. Opening communication channel to MLAG with First client reg
4. Closing Communication channel with last client De-reg
5. Spawning a new thread for handling MLAG updates peocessing
6. adding Test code
7. advertising MLAG Updates to clients based on their interests
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
This includes:
1. Defining message formats
2. Stream Decoding after receiving the message at PIM
3. Handling MLAG UP & Down Notifications
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
when ever a FRR Client wants to send any data to another node
using MLAG Channel, uses below mechanisam.
1. sends a MLAG Registration to zebra with interested messages that
it is intended to receive from peer.
2. In response to this request, Zebra opens communication channel with
MLAG. and also in Rx. diretion zebra forwards only those messages which
client shown interest during registration
3. when client is no-longer interested in communicating with MLAG, client
posts De-register to Zebra
4. if this is the last client which is interested for MLAG Communication,
zebra closes the channel.
why PIM Needs MLAG Communication
================================
1. In general on LAN Networks elecetd DR will send the Join towards
Multicast RP in case of a LHR and Register in case of FHR.
2. But in case DR Goes down, traffic will be re-converged only after
the New DR is elected, but this can take time based on Hold Timer to
detect the DR down.
3. this can be optimised by using MLAG Mecganisam.
4. and also Traffic can be forwarded more efficiently by knowing the cost
towards RP using MLAG
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
This allows to set motd from an input instead of creating a file.
Example:
root@exit2-debian-9:~/frr# telnet 127.0.0.1 2605
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Hello, this is bgpd
User Access Verification
Password:
exit2-debian-9> enable
exit2-debian-9# sh run
Current configuration:
!
frr version 7.3-dev-MyOwnFRRVersion
frr defaults traditional
!
hostname exit2-debian-9
password belekas
log file /var/log/frr/labas.log
log syslog informational
banner motd line Hello, this is bgpd
!
!
!
line vty
!
end
exit2-debian-9#
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Scenarios where this code change is required:
1. BFD is un-configured from BGP at remote end.
Neighbour BFD sends ADMIN_DOWN state, but BFD on local side will send
DOWN to BGP, resulting in BGP session DOWN.
Removing BFD session administratively shouldn't bring DOWN BGP session
at local or remote.
2. BFD is un-configured from BGP or shutdown locally.
BFD will send state DOWN to BGP resulting in BGP session DOWN.
(This is akin to saying do not use BFD for BGP)
Removing BFD session administratively shouldn't bring DOWN BGP session at
local or remote.
Signed-off-by: Sayed Mohd Saquib sayed.saquib@broadcom.com
Make nexthop_next() and nexthop_next_active_resolved() use
const for the nexthop argument. They should not be modifying so
it makes sense here.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Reduce the api for deleting nexthops and the containing
group to just one call rather than having a special case
and handling it separately.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a common handler function for the different nexthop_group_equal*()
comparison functions.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add NULL checks in `nexthop_group_equal*()` iteration
before calling `nexthop_same()` to make Clang SA happy.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Logic error on the second null check for nexthop groups
passed to the `nexthop_group_equal*() functions. This fixes it.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a nexthop hashing api for only hashing on word-sized
attributes. Calling the jhash/jhash2 function is quite slow
in scaled envrionments but sometimes you do need a more granular hash.
The tradeoff here is that hashtable buckets using this hash
might be more full.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
In the nexthop hashing function, lets reduce the hash calls as
much as possible. So, reduce the onlink and infindex to one
call to jhash_2words().
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Optimize the fib and notified nexthop group comparison algorithm
to assume ordering. There were some pretty serious performance hits with
this on high ecmp routes.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Separate nexthop_group_equal() into two versions. One
that compares verses recurisvely resolved nexthops and
one that doesn't.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We were waiting until install time to mark nexthops as duplicate.
Since they are immutable now and re-used, move this marking into
when they are actually created to save a bunch of cycles.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
When hashing a nexthop, shove all the nexthop g_addr data together
and pass it as one call to jhash2() to optimize a bit better.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Speed up nexthop_group_equal() by making it assume the
groups it has been passed are ordered. This should always
be the case.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We should hash nexthops on the onlink flag since that is a
descriptor of the nexthop and not a status of it.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Include resolved nexthops when hashing a nexthop
group but provide an API that allows you to non-recursively
hash as well.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add the ability to recursively resolve nexthop group hash entries
and resolve them when sending to the kernel.
When copying over nexthops into an NHE, copy resolved info as well.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We will use a nhe context for dataplane interaction with
nextho group hash entries.
New nhe's from the kernel will be put into a group array
if they are a group and queued on the rib metaq to be processed
later.
New nhe's sent to the kernel will be set on the dataplane context
with approprate ID's in the group array if needed.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a function to check whether nexthop groups
are equivalent. It does not care about ordering.
Also, set any functions that it relies on to take
const vars as well.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Guard the libyang debug messages under this command so that only
people interested on those messages will see them.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
getrusage, in a heavily stressed system, can account for
signficant running time due to process switching to the kernel.
Allow the end-operator to specify `--disable-cpu-time` to
avoid this call. Additionally we cause `show thread cpu` to
not show up if this is selected.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add a new function getsockopt_so_recvbuf which tells you the
operating systems receive buffer size.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Currently libyang logs errors only (LY_LLERR by default), independent of
FRR's log level. This commit lets libyang log everything including all
sorts of debug logs (when libyang is built in 'Debug' mode). FRR's
logging infrastructure filters logs out according to the configured log
level.
There is a very small performance overhead involved, even when libyang
is build in 'Release' mode. This overhead is mainly affecting config
processing and barely measurable being around 0-3% of the processing
time without this change.
Signed-off-by: Sascha Kattelmann <sascha@netdef.org>
With commit: a9ff90c41b
the vrf_id_t was changed from a uint16_t to a uint32_t
Zebra tracked the last command sent to it's peer via peeking
into the data it was sending to each client ( since we had
lost the idea of what the command was when it was time to track
the data ).
Add a define to track this and add a bit of verbiage
to the code to allow us to notice when we screw with
the header again so that this is just fixed correctly
when it happens again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When POLLNVAL is received for a FD then that FD is removed from the
pfd array and also array is rearranged using memmove. When memmove
is used then unused index are not cleanedup. When a new FD takes
up that index then it ends up using stale events without any handler
set for the same.
Signed-off-by: Santosh P K <sapk@vmware.com>
The dnode member of the nb_config structure can be null on
daemons that don't implement any YANG module. As such, update
the nb_cli_show_config_prepare() function to always check if the
libyang data node that is going to be displayed is null or not
before operating on it.
This fixes the following warning (introduced by commit 5e6a9350c1):
libyang: Invalid arguments (lyd_schema_sort())
Reported-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This change fixes a static analyzer warning and should also make us
safer when using this function. At the moment the code that triggered
the warning is the only one that uses this function.
Passing anything other than `struct prefix` to `str2prefix` function is
dangerous, because the structure might be smaller than expected and we
might have an buffer overflow.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Remove the xpath field from the nb_config_cb structure in order
to reduce its size. This allows the northbound to spend less time
allocating memory during the processing of large configuration
transactions.
To make this work, use yang_dnode_get_path() to obtain the xpath
from the dnode field whenever necessary.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Commit 6b5d6e2dbc changed how we order configuration callbacks
and introduced a regression in the processing of the 'apply_finish'
callbacks. Fix this.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Load the startup configuration directly into the CLI shared candidate
configuration instead of loading it into a private candidate
configuration. This way we don't need to initialize the shared
candidate separately later as a copy of the running configuration,
which is a potentially expensive operation.
Also, make the northbound process SIGHUP correctly even when --tcli
is not used.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
nb_candidate_edit() was calling both the lyd_schema_sort() and
lyd_validate() functions whenever a new node was added to the
candidate configuration. This was done to ensure the candidate
is always ready to be displayed correctly (libyang only creates
default child nodes during the validation process, and data nodes
aren't guaranteed to be ordered by default).
The problem is that the two aforementioned functions are too
expensive to be called in the northbound hot path. Instead, it makes
more sense to call them only before displaying the configuration
(in which case a recursive sort needs to be done). Introduce the
nb_cli_show_config_prepare() to achieve that purpose.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The nb_cli_apply_changes() function was creating a full copy of
the candidate configuration before editing it. This excerpt from
the northbond documentation explains why this was being done:
"NOTE: the nb_cli_cfg_change() function clones the candidate
configuration before actually editing it. This way, if any error
happens during the editing, the original candidate is restored to
avoid inconsistencies. Either all changes from the configuration
command are performed successfully or none are. It's like a
mini-transaction but happening on the candidate configuration
(thus the northbound callbacks are not involved)".
The problem is that this kind of error handling is just too
expensive. A command should never fail to edit the candidate
configuration unless there's a bug in the code (e.g. when the
CLI wrapper command passes an integer value that YANG rejects due
to a "range" statement). In such cases, a command might fail to
be applied or applied only partially if it edits multiple YANG
nodes. When that happens, just log an error to make the operator
aware of the problem, but otherwise ignore it instead of rejecting
the command and restoring the candidate to its previous state. We
shouldn't add an extreme overhead to the northbound CLI client only
to handle errors that should never happen in practice.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There's no need to check for removed configuration objects in the
following two cases:
* A private candidate configuration is being edited;
* The startup configuration is being read.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We have unsigned 4 byte integrals in the codebase that end up in json
output, so we need to force a json library that can handle these.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Description: The changes have been done to make the snmp socket
non-blocking before calling snmp_read()
Problem Description/Summary :
vtysh hangs on first try to enter after a reboot with BGP dynamic peers
Expected Behavior :
VTYSH should not hang.
When we debug more into bgpd docker by doing gdb on its threads, we find the below thread of bgpd, which is causing the issue.
Thread 1 (Thread 0x7f1e1ec46d40 (LWP 47)):
0x00007f1e1d762593 in recvfrom () from /lib/x86_64-linux-gnu/libpthread.so.0
0x00007f1e1aadd09b in netsnmp_tcpbase_recv () from /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30
0x00007f1e1aad9617 in netsnmp_transport_recv () from /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30
0x00007f1e1aab2c07 in _sess_read () from /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30
0x00007f1e1aab3a29 in snmp_sess_read2 () from /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30
0x00007f1e1aab3a7b in snmp_read2 () from /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30
0x00007f1e1aab3acf in snmp_read () from /usr/lib/x86_64-linux-gnu/libnetsnmp.so.30
0x00007f1e1b44d7ec in agentx_read (t=0x7fffa75f0080) at lib/agentx.c:63
0x00007f1e1e7d6451 in thread_call (thread=0x7fffa75f0080) at lib/thread.c:1620
0x00007f1e1e770699 in frr_run (master=0x559396ea60f0) at lib/libfrr.c:1011
0x0000559395b4d953 in main (argc=5, argv=0x7fffa75f02b8) at bgpd/bgp_main.c:492
(gdb) bt
0x00007f830c89d210 in __read_nocancel () from /lib/x86_64-linux-gnu/libpthread.so.0
0x000056450e1e8238 in vtysh_client_run (vclient=0x56450e4a8b40 <vtysh_client+24768>, line=0x56450e21add0 enable, callback=0x0, cbarg=0x0) at vtysh/vtysh.c:216
0x000056450e1e8c6b in vtysh_client_run_all (head_client=0x56450e4a8b40 <vtysh_client+24768>, line=0x56450e21add0 enable, continue_on_err=0, callback=0x0, cbarg=0x0) at vtysh/vtysh.c:356
0x000056450e1e8ddb in vtysh_client_execute (head_client=0x56450e4a8b40 <vtysh_client+24768>, line=0x56450e21add0 enable) at vtysh/vtysh.c:393
0x000056450e1e9c82 in vtysh_execute_func (line=0x56450e21add0 enable, pager=0) at vtysh/vtysh.c:598
0x000056450e1e9dee in vtysh_execute_no_pager (line=0x56450e21add0 enable) at vtysh/vtysh.c:619
0x000056450e1f7d48 in vtysh_read_file (confp=0x56451000a9d0, top_cfg=1) at vtysh/vtysh_config.c:494
0x000056450e1f7ef2 in vtysh_read_config (config_default_dir=0x56450e4edc20 <frr_config> /etc/frr/frr.conf, top_cfg=1) at vtysh/vtysh_config.c:522
0x000056450e1e5de4 in vtysh_apply_top_level_config () at vtysh/vtysh_main.c:301
0x000056450e1e7842 in main (argc=2, argv=0x7ffc81e6f598, env=0x7ffc81e6f5b0) at vtysh/vtysh_main.c:692
The fix has been taken from the following link.
https://sourceforge.net/p/net-snmp/patches/1348/
Signed-off-by: Preetham Singh <preetham.singh@broadcom.com>
Our Address Sanitizer CI is finding this issue:
error 09-Oct-2019 19:28:33 r4: bgpd triggered an exception by AddressSanitizer
error 09-Oct-2019 19:28:33 ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdd425b060 at pc 0x00000068575f bp 0x7ffdd4258550 sp 0x7ffdd4258540
error 09-Oct-2019 19:28:33 READ of size 1 at 0x7ffdd425b060 thread T0
error 09-Oct-2019 19:28:33 #0 0x68575e in prefix_cmp lib/prefix.c:776
error 09-Oct-2019 19:28:33 #1 0x5889f5 in rfapiItBiIndexSearch bgpd/rfapi/rfapi_import.c:2230
error 09-Oct-2019 19:28:33 #2 0x5889f5 in rfapiBgpInfoFilteredImportVPN bgpd/rfapi/rfapi_import.c:3520
error 09-Oct-2019 19:28:33 #3 0x58b909 in rfapiProcessWithdraw bgpd/rfapi/rfapi_import.c:4071
error 09-Oct-2019 19:28:33 #4 0x4c459b in bgp_withdraw bgpd/bgp_route.c:3736
error 09-Oct-2019 19:28:33 #5 0x484122 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:237
error 09-Oct-2019 19:28:33 #6 0x497f52 in bgp_nlri_parse bgpd/bgp_packet.c:315
error 09-Oct-2019 19:28:33 #7 0x49d06d in bgp_update_receive bgpd/bgp_packet.c:1598
error 09-Oct-2019 19:28:33 #8 0x49d06d in bgp_process_packet bgpd/bgp_packet.c:2274
error 09-Oct-2019 19:28:33 #9 0x6b9f54 in thread_call lib/thread.c:1531
error 09-Oct-2019 19:28:33 #10 0x657037 in frr_run lib/libfrr.c:1052
error 09-Oct-2019 19:28:33 #11 0x42d268 in main bgpd/bgp_main.c:486
error 09-Oct-2019 19:28:33 #12 0x7f806032482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
error 09-Oct-2019 19:28:33 #13 0x42bcc8 in _start (/usr/lib/frr/bgpd+0x42bcc8)
error 09-Oct-2019 19:28:33
error 09-Oct-2019 19:28:33 Address 0x7ffdd425b060 is located in stack of thread T0 at offset 240 in frame
error 09-Oct-2019 19:28:33 #0 0x483945 in bgp_nlri_parse_vpn bgpd/bgp_mplsvpn.c:103
error 09-Oct-2019 19:28:33
error 09-Oct-2019 19:28:33 This frame has 5 object(s):
error 09-Oct-2019 19:28:33 [32, 36) 'label'
error 09-Oct-2019 19:28:33 [96, 108) 'rd_as'
error 09-Oct-2019 19:28:33 [160, 172) 'rd_ip'
error 09-Oct-2019 19:28:33 [224, 240) 'prd' <== Memory access at offset 240 overflows this variable
error 09-Oct-2019 19:28:33 [288, 336) 'p'
error 09-Oct-2019 19:28:33 HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
error 09-Oct-2019 19:28:33 (longjmp and C++ exceptions *are* supported)
error 09-Oct-2019 19:28:33 SUMMARY: AddressSanitizer: stack-buffer-overflow lib/prefix.c:776 prefix_cmp
error 09-Oct-2019 19:28:33 Shadow bytes around the buggy address:
error 09-Oct-2019 19:28:33 0x10003a8435b0: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00
error 09-Oct-2019 19:28:33 0x10003a8435c0: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3
error 09-Oct-2019 19:28:33 0x10003a8435d0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
error 09-Oct-2019 19:28:33 0x10003a8435e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
error 09-Oct-2019 19:28:33 0x10003a8435f0: f1 f1 04 f4 f4 f4 f2 f2 f2 f2 00 04 f4 f4 f2 f2
error 09-Oct-2019 19:28:33 =>0x10003a843600: f2 f2 00 04 f4 f4 f2 f2 f2 f2 00 00[f4]f4 f2 f2
error 09-Oct-2019 19:28:33 0x10003a843610: f2 f2 00 00 00 00 00 00 f4 f4 f3 f3 f3 f3 00 00
error 09-Oct-2019 19:28:33 0x10003a843620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
error 09-Oct-2019 19:28:33 0x10003a843630: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 02 f4
error 09-Oct-2019 19:28:33 0x10003a843640: f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 00 00
error 09-Oct-2019 19:28:33 0x10003a843650: f4 f4 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00
error 09-Oct-2019 19:28:33 Shadow byte legend (one shadow byte represents 8 application bytes):
error 09-Oct-2019 19:28:33 Addressable: 00
error 09-Oct-2019 19:28:33 Partially addressable: 01 02 03 04 05 06 07
error 09-Oct-2019 19:28:33 Heap left redzone: fa
error 09-Oct-2019 19:28:33 Heap right redzone: fb
error 09-Oct-2019 19:28:33 Freed heap region: fd
error 09-Oct-2019 19:28:33 Stack left redzone: f1
error 09-Oct-2019 19:28:33 Stack mid redzone: f2
error 09-Oct-2019 19:28:33 Stack right redzone: f3
error 09-Oct-2019 19:28:33 Stack partial redzone: f4
error 09-Oct-2019 19:28:33 Stack after return: f5
error 09-Oct-2019 19:28:33 Stack use after scope: f8
error 09-Oct-2019 19:28:33 Global redzone: f9
error 09-Oct-2019 19:28:33 Global init order: f6
error 09-Oct-2019 19:28:33 Poisoned by user: f7
error 09-Oct-2019 19:28:33 Container overflow: fc
error 09-Oct-2019 19:28:33 Array cookie: ac
error 09-Oct-2019 19:28:33 Intra object redzone: bb
error 09-Oct-2019 19:28:33 ASan internal: fe
error 09-Oct-2019 19:28:36 r3: Daemon bgpd not running
This is the result of this code pattern in rfapi/rfapi_import.c:
prefix_cmp((struct prefix *)&bpi_result->extra->vnc.import.rd,
(struct prefix *)prd))
Effectively prd or vnc.import.rd are `struct prefix_rd` which
are being typecast to a `struct prefix`. Not a big deal except commit
1315d74de9 modified the prefix_cmp
function to allow for a sorted prefix_cmp. In prefix_cmp
we were looking at the offset and shift. In the case
of vnc we were passing a prefix length of 64 which is the exact length of
the remaining data structure for struct prefix_rd. So we calculated
a offset of 8 and a shift of 0. The data structures for the prefix
portion happened to be equal to 64 bits of data. So we checked that
with the memcmp got a 0 and promptly read off the end of the data
structure for the numcmp. The fix is if shift is 0 that means thei
the memcmp has checked everything and there is nothing to do.
Please note: We will still crash if we set the prefixlen > then
~312 bits currently( ie if the prefixlen specifies a bit length
longer than the prefix length ). I do not think there is
anything to do here( nor am I sure how to correct this either )
as that we are going to have some severe problems when we muck
up the prefixlen.
Fixes: #5025
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cleanup the interface creation apis to make it more
clear what they are doing.
Make it explicit that the creation via name/ifindex will
only add it to the appropriate list.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
If the name has not been set yet (we were only passed the
ifindex in some cases like with master/slave timings) then
do not add/del it from the ifname rb tree on the vrf struct.
Doing so causes duplicate entries on the tree and infinte loops
can happen when iterating over it.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We were using the incorrect comparison function for the
ifindex-based rb tree. Luckily, we were using the correct one
in RB_GENERATE so I guess that overwrote what was declared in the
prototype?
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Adding ietf routing types yang module to makefile
lib: Adding this yang module to common place
so it can be accessed from all frr modules.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Some issues with our internal vector type being typedef'd as `vector`,
which conflicts with the C++ standard vector class...
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
inet_pton() is used to parse ipv4 addresses internally, therefore FRR
does not support octal notation for quads. The ipv4 cli token validator
should make sure that str2prefix() can parse tokens it allows, and
str2prefix uses inet_pton, so we have to disallow leading zeros in ipv4
quads.
In short, 1.1.1.01 is no longer valid and must be expressed as 1.1.1.1.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Allow systemd to be informed about operational state so operators can
infer a bit about what is going on with FRR from the systemd status
cli.
sharpd@robot ~/frr4> systemctl status frr
● frr.service - FRRouting
Loaded: loaded (/usr/lib/systemd/system/frr.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2019-10-03 21:09:04 EDT; 7s ago
Docs: https://frrouting.readthedocs.io/en/latest/setup.html
Process: 32455 ExecStart=/usr/lib/frr/frrinit.sh start (code=exited, status=0/SUCCESS)
Status: "FRR Operational"
Tasks: 12 (limit: 4915)
Memory: 76.5M
CGroup: /system.slice/frr.service
├─32468 /usr/lib/frr/watchfrr -d zebra bgpd staticd
├─32487 /usr/lib/frr/zebra -d -A 127.0.0.1 -s 90000000
├─32492 /usr/lib/frr/bgpd -d -A 127.0.0.1
└─32500 /usr/lib/frr/staticd -d -A 127.0.0.1
Please note the `Status: ...` line above.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The vrf_id in `zsend_interface_vrf_update()` is encoded as
a long via `stream_putl()`, we should decode it as such
as well.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
This reverts commit 11375c5274.
That commit was introduced to fix a CI failure, which should now not
accure due to the preceding commit/revert.
Signed-off-by: Juergen Werner <juergen@opensourcerouting.org>
The asm-code was interpreted inconsistently for different platforms.
In particular for AArch64 this caused UB, if multiple static MTYPEs
where defined in one file. All static MTYPE_* could point to the same
memory location (namely the first defined MTYPE) OR to their respective
(correct) locations depending on the context of their usage.
Signed-off-by: Juergen Werner <juergen@opensourcerouting.org>
Current autocompletion works only for simple "vrf NAME" case.
This commit expands it also for the following cases:
- "nexthop-vrf NAME" in staticd
- usage of $varname in many daemons
All daemons are updated to use single varname "$vrf_name".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This includes:
1. Processing client Registrations for MLAG
2. storing client Interests for MLAG updates
3. Opening communication channel to MLAG with First client reg
4. Closing Communication channel with last client De-reg
5. Spawning a new thread for handling MLAG updates peocessing
6. adding Test code
7. advertising MLAG Updates to clients based on their interests
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
This includes:
1. Defining message formats
2. Stream Decoding after receiving the message at PIM
3. Handling MLAG UP & Down Notifications
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
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>
When zebra gets a callback from the kernel that an interface has
actually been deleted *and* the end users has not configured
the interface, then allow for deletion of the interface from zebra.
This is especially important in a docker environment where containers
and their veth interfaces are treated as ephermeal. FRR can quickly
have an inordinate amount of interfaces sitting around that are
not in the kernel and we have no way to clean them up either.
My expectation is that this will cause a second order crashes
in upper level protocols, but I am not sure how to catch these
and fix them now ( suggestions welcome ). There are too many
use patterns and order based events that I cannot know for certain
that we are going to see any at all, until someone sees this problem
as a crash :( I do not recommend that this be put in the current
stabilization branch and allow this to soak in master for some time
first.
Testing:
sharpd@donna ~/frr4> sudo ip link add vethdj type veth peer name vethjd
sharpd@donna ~/frr4> sudo ip link add vethaa type veth peer name vethab
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
vethaa down default
vethab down default
vethdj down default
vethjd down default
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo ip link set vethaa up
sharpd@donna ~/frr4> sudo ip link set vethab up
sharpd@donna ~/frr4> sudo ip link del vethdj
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
vethaa up default
vethab up default
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo ip link del vethaa
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo ip link add vethaa type veth peer name vethab
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
vethaa down default
vethab down default
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo vtysh -c "show run"
Building configuration...
Current configuration:
!
frr version 7.2-dev
frr defaults datacenter
hostname donna.cumulusnetworks.com
log stdout
no ipv6 forwarding
!
ip route 192.168.3.0/24 192.168.209.1
ip route 192.168.4.0/24 blackhole
ip route 192.168.5.0/24 192.168.209.1
ip route 192.168.6.0/24 192.168.209.1
ip route 192.168.7.0/24 99.99.99.99 nexthop-vrf EVA
ip route 192.168.8.0/24 192.168.209.1
ip route 4.5.6.7/32 12.13.14.15
!
interface dummy1
ip address 12.13.14.15/32
!
interface vethaa
description FROO
!
line vty
!
end
sharpd@donna ~/frr4> sudo ip link del vethaa
sharpd@donna ~/frr4> sudo vtysh -c "show int brief"
Interface Status VRF Addresses
--------- ------ --- ---------
dummy1 down default
enp0s3 up default 10.0.2.15/24
enp0s8 up default 192.168.209.2/24
enp0s9 up default 192.168.210.2/24
enp0s10 up default 192.168.212.4/24
lo up default 10.22.89.38/32
vethaa down default
virbr0 up default 192.168.122.1/24
virbr0-nic down default
sharpd@donna ~/frr4> sudo vtysh -c "show run"
Building configuration...
Current configuration:
!
frr version 7.2-dev
frr defaults datacenter
hostname donna.cumulusnetworks.com
log stdout
no ipv6 forwarding
!
ip route 192.168.3.0/24 192.168.209.1
ip route 192.168.4.0/24 blackhole
ip route 192.168.5.0/24 192.168.209.1
ip route 192.168.6.0/24 192.168.209.1
ip route 192.168.7.0/24 99.99.99.99 nexthop-vrf EVA
ip route 192.168.8.0/24 192.168.209.1
ip route 4.5.6.7/32 12.13.14.15
!
interface dummy1
ip address 12.13.14.15/32
!
interface vethaa
description FROO
!
line vty
!
end
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
During initialization, the northbound detects if any required
callback is missing (fatal error) or if any unneeded callback is
present (warning).
There are three callbacks, however, that should require special
handling: get_next(), get_keys() and lookup_entry().
These callbacks are normally unneeded for configuration lists. But,
if a configuration list is augmented with new state nodes by another
module, then the three callbacks mentioned above become required. In
this case, never log a warning when these callbacks are implemented
when they are not needed, since this depends on context (e.g. some
daemons might augment "frr-interface" while others don't).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When a configuration transaction is being performed, the northbound
uses a red-black tree to store the configuration changes that need to
be processed. The problem is that we were sorting the configuration
changes based on their XPaths (and callback priorities). This means
the original order of the changes wasn't being respected, which is
a problem for lists that use the "ordered-by user" statement. To
fix this, add a new "seq" member to the "nb_config_cb" structure
so that we can preserve the order of the configuration changes as
told by libyang.
Since none of the FRR modules use "ordered-by user" lists so far,
no daemon was affected by this problem.
Reported-by: Martin Winter <mwinter@opensourcerouting.org>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When updating the XPath during the iteration of operational data,
include the namespace of the augmenting module when necessary.
Reported-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Adding a lock to protect the global running configuration doesn't
help much since the FRR daemons are not prepared to process
configuration changes in a pthread that is not the main one (a
whole lot of new protections would be necessary to prevent race
conditions).
This means the lock added by commit 83981138 only adds more
complexity for no benefit. Remove it now to simplify the code.
All northbound clients, including the gRPC one, should either run
in the main pthread or use synchronization primitives to process
configuration transactions in the main pthread.
This reverts commit 83981138fe.
This callback can be used to validate subsections of the
configuration being committed before validating the configuration
changes themselves. It's useful to perform more complex validations
that depend on the relationship between multiple nodes.
Only YANG-level validation (performed by libyang) and the
NB_EV_VALIDATE validation (that can be used to validate individual
configuration changes) proved to be insufficient in some cases.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We had wrappers for IPv4 and IPv6 prefixes, but not for IP (version
agnostic) prefixes. This commit addresses this issue.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In preparation to Segment Routing:
- Update the management of Traffic Engineering subTLVs to the new tlvs parser
- Add Router Capability TLV 242 as per RFC 4971 & 7981
- Add Segment Routing subTLVs as per draft-isis-segment-routing-extension-25
Modified files:
- isis_tlvs.h: add new structure to manage TE subTLVs, TLV 242 & SR subTLVs
- isis_tlvs.c: add new functions (pack, copy, free, unpack & print) to process
TE subTLVs, Router Capability TLV and SR subTLVs
- isis_circuit.[c,h] & isis_lsp.[c,h]: update to new subTLVs & TLV processing
- isis_te.[c,h]: remove all old TE structures and managment functions,
and add hook call to set local and remote IP addresses as wellas update TE
parameters
- isis_zebra.[c,h]: add hook call when new interface is up
- isis_mt.[c,h], isis_pdu.c & isis_northbound.c: adjust to new TE subTLVs
- tests/isisd/test_fuzz_isis_tlv_tests.h.gz: adapte fuuz tests to new parser
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
when ever a FRR Client wants to send any data to another node
using MLAG Channel, uses below mechanisam.
1. sends a MLAG Registration to zebra with interested messages that
it is intended to receive from peer.
2. In response to this request, Zebra opens communication channel with
MLAG. and also in Rx. diretion zebra forwards only those messages which
client shown interest during registration
3. when client is no-longer interested in communicating with MLAG, client
posts De-register to Zebra
4. if this is the last client which is interested for MLAG Communication,
zebra closes the channel.
why PIM Needs MLAG Communication
================================
1. In general on LAN Networks elecetd DR will send the Join towards
Multicast RP in case of a LHR and Register in case of FHR.
2. But in case DR Goes down, traffic will be re-converged only after
the New DR is elected, but this can take time based on Hold Timer to
detect the DR down.
3. this can be optimised by using MLAG Mecganisam.
4. and also Traffic can be forwarded more efficiently by knowing the cost
towards RP using MLAG
Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
Pthreads were not being deleted from the list after destruction. This
isn't causing any bugs currently but that's just by dumb luck.
Signed-off-by: Quentin Young <qlyoung@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>
This new message makes it possible to install/reinstall LSPs with
multiple nexthops using a single ZAPI message.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Add ability to specify the nexthop type;
* Add ability to install or not a FTN (in addition to an LSP).
These two additions will be useful to install local SR Prefix-SIDs
configured with the no-PHP option.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
SR support for IS-IS is coming so we need to be able to distinguish
OSPF and IS-IS LSPs.
While here, add missing case statement for LDP on
lsp_type_from_re_type().
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Use the route type and instance instead of the route distance
to identify MPLS FTNs. This is a more robust approach since the
routing daemons can modify the distance of their announced routes
via configuration, which can cause inconsistencies.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Do this for the following reasons:
* Improve modularity of the code by separating the decoding of the
ZAPI messages from their processing;
* Create an API that is easier to use by the client daemons.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Commit eaf6705d7a fixed a problem caused by configuration changes
coming from the kernel. The fix consisted of regenerating the
candidate configuration before every configuration command (when
using the non-transactional CLI mode). There's no need, however,
to regenerate the candidate when it's identical to the running
configuration. Since the northbound keeps track of the version
of each configuration, we can use that information to prevent
regenerating the candidate configuration when that is not necessary.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
frr_with_mutex(...) { ... } locks and automatically unlocks the listed
mutex(es) when the block is exited. This adds a bit of safety against
forgetting the unlock in error paths & co. and makes the code a slight
bit more readable.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
A couple functions in routemap.c were returning
0/1 that were being mapped into the appropriate
enum values on the calling functions to check return
values. This matches the return values to the actual
enum for future readability.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This implements BMP. There's no fine-grained history here, the non-BMP
preparations are already split out from here so all that remains is BMP
proper.
Signed-off-by: David Lamparter <equinox@diac24.net>
This - mostly intended for BMP - implements a pull-driven write buffer
filled on demand by a callback with some reasonable buffering logic.
I don't expect it to be that useful in other places, but it's not BMP
specific so it's properly split off in its own place.
Signed-off-by: David Lamparter <equinox@diac24.net>
Arm platforms are crashing in our topotests with this callstack;
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0xffffabb591d0 (LWP 18947))]
(gdb) bt
file=file@entry=0xaaaadfed1e48 "lib/memory.c", line=line@entry=80,
function=function@entry=0xaaaadfed1db8 <__func__.10514> "mt_count_free") at lib/log.c:837
(gdb)
So we are crashing because we are attempting to free a mtype that has no allocations
associated with it.
I added this debug code:
@@ -227,7 +230,9 @@ static void rcu_bump(void)
struct rcu_next *rn;
rn = XMALLOC(MTYPE_RCU_NEXT, sizeof(*rn));
-
+ zlog_debug("RCU_BUMP");
+ mtype_dump(MTYPE_RCU_THREAD);
+ mtype_dump(MTYPE_RCU_NEXT);
/* note: each RCUA_NEXT item corresponds to exactly one seqno bump.
* This means we don't need to communicate which seqno is which
* RCUA_NEXT, since we really don't care.
and added a mtype_dump function:
+void mtype_dump(struct memtype *mt)
+{
+ zlog_debug("%s: %d", mt->name, (int)mt->n_alloc);
+}
Which resulted in this output:
2019/08/28 15:41:11 BGP: RCU_BUMP
2019/08/28 15:41:11 BGP: RCU thread: 3
2019/08/28 15:41:11 BGP: RCU thread: 3
If we look at the defintion of the two static memory types:
DEFINE_MTYPE_STATIC(LIB, RCU_THREAD, "RCU thread")
DEFINE_MTYPE_STATIC(LIB, RCU_NEXT, "RCU sequence barrier")
I would have expected the output to be:
RCU_BUMP
RCU thread: 3
RCU sequence barrier: X
instead.
As a thought experiment I reduced the number of static memory types
to 1 in the file and the crash stopped happening.
I suspect we have a systematic error on arm in lib/memory.h
due to the asm code. I am going to leave that alone for the
moment ( and leave the crash issue open ), but see if we
can get this code change into the system so that our CI
system becomes happy again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The FRR community has run into an issue where keeping up our
CI system to work with solaris has become a fairly large burden.
We have also sent emails and asked around and have not found
anyone standing up saying that they are using Solaris.
Given the fact that we do not have any comprehensive testing
being done w/ solaris and the fact that we are getting a steady
stream of new features that will never work on solaris and
we cannot find anyone to say that they are using it. Let's
start the drawn out process of deprecating the code.
If in the mean-time someone comes forward with the fact that
they are using it we can then not deprecate it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
FRR has two implementations of VRF, one backed by netns and the other by
the proper VRF implementation in the Linux kernel. In certain places, the
code assumes that a VRF is netns and so lookups fail. One example of this
is in IPv6 RA code. This causes functionality such as Unnumbered BGP to
fail. To fix this, this patch makes if_lookup_by_index handle the
behavior based on the backend, similar to if_get_by_index. For the two
places in if.c that were calling if_lookup_by_index to be specific to
the VRF, I renamed the existing code, if_lookup_by_ifindex and made it a
static function that is never exposed or called by any routine outside of
if.c.
Signed-off-by: Dinesh G Dutt <5016467+ddutt@users.noreply.github.com>
This is the second part of commit 8d92004979, which converted
only one of the two calls to inet_aton().
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Some other ZAPI decode functions still use void return values and
can't propagate stream errors to their callers. They need to be fixed
as well in the future.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Problem reported that "clear bgp *" only cleared ipv6 peers.
Changed the logic to clear all afi/safis of all peers in
that case. Also improved the operation of clearing
individual afi/safi using soft/in/out to do the right thing.
Ticket: CM-25887
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Sort nexthops before we push them to zebra. This offloads
the nexthop sorting zebra is doing onto the upper level protocols
so that when it gets to zebra and we construct a group, it just has
to append them to the tail for every nexthop.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a tail check to see if we can just put the nexthop
at the end of the already sorted list before iteration.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Debian packaging when run finds a bunch of spelling errors:
I: frr: spelling-error-in-binary usr/bin/vtysh occurences occurrences
I: frr: spelling-error-in-binary usr/lib/frr/bfdd Amount of times Number of times
I: frr: spelling-error-in-binary usr/lib/frr/bgpd occurences occurrences
I: frr: spelling-error-in-binary usr/lib/frr/bgpd recieved received
I: frr: spelling-error-in-binary usr/lib/frr/isisd betweeen between
I: frr: spelling-error-in-binary usr/lib/frr/ospf6d Infomation Information
I: frr: spelling-error-in-binary usr/lib/frr/ospfd missmatch mismatch
I: frr: spelling-error-in-binary usr/lib/frr/pimd bootsrap bootstrap
I: frr: spelling-error-in-binary usr/lib/frr/pimd Unknwon Unknown
I: frr: spelling-error-in-binary usr/lib/frr/zebra Requsted Requested
I: frr: spelling-error-in-binary usr/lib/frr/zebra uknown unknown
I: frr: spelling-error-in-binary usr/lib/x86_64-linux-gnu/frr/libfrr.so.0.0.0 overriden overridden
This commit fixes all of them except the bgp `recieved` issue due to
it being part of json output. That one will need to go through
a deprecation cycle.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The `destination` field of the connection structure was used to store
the broadcast address, if the connection was not p2p. This multipurpose
is not very evident and the benefits over calculating the bcast address
on the fly minimal.
Signed-off-by: Juergen Werner <juergen@opensourcerouting.org>
In if_netlink.c, when an interface structure, ifp, is first created,
its possible for the master to come up after the slave interface does.
This means, the slave interface has no way to display the master's ifname
in show outputs. To fix this, we need to allow creation by ifindex instead
of by ifname so that this issue is handled.
Signed-off-by: Dinesh G Dutt<5016467+ddutt@users.noreply.github.com>
The correct cast for these is (unsigned char), because "char" could be
signed and thus have some negative value. isalpha & co. expect an int
arg that is positive, i.e. 0-255. So we need to cast to (unsigned char)
when calling any of these.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The function ipv4_broadcast_addr() does not calculate correct broadcast
addresses for point-to-point connections with prefix 31. RFC3021
section 3.3 [1] specifies:
"The 255.255.255.255 IP broadcast address MUST be used for broadcast
Address Mask Replies in point-to-point links with 31-bit subnet masks"
The issue causes Zebra to print the following warning when IPv4 address
with 31 prefix (e.g. 192.168.222.240/31) is configured on a network
interface:
ZEBRA: [EC 4043309141] warning: interface VNS broadcast addr 255.255.255.255/31 != calculated 192.168.222.241, routing protocols may malfunction
The issue has been originally found in Quagga [2], but it is present also
in FRR.
[1] https://tools.ietf.org/html/rfc3021#section-3.3
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1713449
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Coverity report caught this log mutex being unlocked twice.
Removing the extra one before the goto statement.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
All users of the pqueue_* implementations have been migrated to use
some new data structure (TYPEDSKIP for ospf, HEAP for thread.c).
Remove.
Signed-off-by: David Lamparter <equinox@diac24.net>
Replaces the use of pqueue_* for the thread_master's timer list with an
instance of DECLARE_HEAP_*.
Signed-off-by: David Lamparter <equinox@diac24.net>
The new list api did not implement the `*_del` endpoint as
it was described in the docs here:
http://docs.frrouting.org/projects/dev-guide/en/latest/lists.html#c.Z_del
This patch implements the endpoints to return the object deleted if
found, otherwise NULL for all but the atomic lists.
The atomic list `*_del` code is marked as TODO and will remain undefined
for now.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
seqlock_timedwait() puts an (absolute, CLOCK_MONOTONIC) deadline on how
long we wait. The RCU code uses this for its watchdog implementation.
Signed-off-by: David Lamparter <equinox@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>
when requesting a specific label chunk (e.g. for the SRGB),
it might happen that we cannot get what we want. In this
event, we must be prepared to receive a response with no
label chunk. Without this fix, if the remote label manager
was not able to alloate the chunk we requested, we would
hang indefinitely trying to read data from the stream which
was not there.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
For SRGB, we need to support chunk requests starting at a
specific point in the label space, rather than just asking
for any sufficiently large chunk. To this purpose, we extend
the label manager api to request a chunk with a base value;
if the base is set to 0, the label manager will behave as it
currently does, i.e. fetching the first free chunk big enough
to satisfy the request.
update all the existing calls to get chunks from the label
manager so that they use MPLS_LABEL_BASE_ANY as the base
for the requested chunk
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
in addition to support for tcpflags, it is possible to filter on any
protocol. the filtering can then be based with iptables.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zvni setup in zebra is controlled via bgpd i.e. advertise_all_vni
from bgpd triggers this setup. As a part of zvni creation we may need
to setup BUM mcast SG entries which are propagated to pimd for MDT setup.
Now pimd may not be present at the time of zvni creation or may restart
post zvni creation so we need a mechanism to replay (on pimd startup) and
to cleanup (on pimd stop). This is addressed via zebra_vxlan_sg_replay and
zebra_evpn_pim_cfg_clean_up.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The callback itself might want to reschedule the resolver, so it is
useful to clear out the callback field before making the call instead of
after.
Signed-off-by: David Lamparter <equinox@diac24.net>
Add the process pids to the output produced by 'show modules'.
At least in a development setting, where there may be multiple
instances of frr running, it can be handy to be able to id
the exact pids, for debugging e.g.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
When using the LYD_PATH_OPT_NOPARENTRET flag, lyd_new_path() returns
the path-referenced node instead of the first created node. This
flag wasn't available in libyang 0.16-r1 so we couldn't use it
before. Use it now to simplify the code where possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
libyang-0.16-r3 contains a commit[1] that changed the autodelete
behavior of subtrees when validating data. A few FRR commands were
affected by this change since they relied on the old autodelete
behavior.
To fix these commands, use the LYD_OPT_WHENAUTODEL flag when
validating data to restore the old autodelete behavior (which adds
a lot of convenience for us).
[1] https://github.com/CESNET/libyang/commit/bbc43b1b4
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add a file that exposes functions which modify nexthop groups.
Nexthop groups are techincally immutable but there are a
few special cases where we need direct access to add/remove
nexthops after the group has been made. This file provides a
way to expose those functions in a way that makes it clear
this is a private/hidden api.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a nexthop_dup() api that both allocates and copies
a new nexthop from an old one. Still retain the old exposed
function nexthop_copy() so we can copy without allocation.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add nexthop_group_copy and nexthop_group_add_sorted functions.
nexthop_group_copy -> Copy src nexthop_group into dst nexthop_group
nexthop_group_add_sorted -> Adds a new nexthop to the nexthop group
in a sorted manner.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Our command matcher doesn't handle {[...]} correctly; let's warn about
it so the DEFUN can be changed to [{...}] (which does work as expected.)
Fixes: #4594
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Make the function parameter `const` so the analyzer doesn't suspect we
are trying to change its value.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Some more complex CLI usages will require northbound to support
signalizing a custom configuration node end.
For an example:
```
router bgp 100
bgp router-id 10.254.254.1
neighbor 10.0.0.100 remote-as 200
!
address-family ipv4 unicast
network 10.0.1.0/24
network 10.0.2.0/24
network 10.0.3.0/24
exit-address-family
!
address-family ipv6 unicast
neighbor 10.0.0.100 activate
exit-address-family
!
```
This commit implements a new callback called `cli_show_end` which
complements `cli_show` and is only called at the end of processing the
yang configuration node. It will be used to write the configuration
node termination like: "!" or "exit-address-family".
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The "static struct mtype * const MTYPE_FOO" doesn't quite make a
"constant" that is usable for initializers. An 1-element array works
better.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When running `show run` of route-maps the order is basically
the order read in some fashion. Convert the display to
always be the alphabetically sorted order.
Suggested-by: Manuel Schweizer <manuel@cloudscale.ch>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This will allow the end-user to clear the counters associated
with the route-map. Subsuquent `show route-map ..` commands
will display counters since the last clear.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a prefix-list is applied to a BGP neighbor to deny the learning
of specific routes, the hit count is showing 0 for BGP even though
the routes are being filtered correctly due
to the configured prefix-list.
Before fix:
c1# show ip prefix-list nag seq 10
ZEBRA: seq 10 permit any (hit count: 0, refcount: 0)
BGP: seq 10 permit any (hit count: 0, refcount: 0)
c1# show ip prefix-list nag seq 5
ZEBRA: seq 5 deny 1.0.1.0/24 (hit count: 0, refcount: 0)
BGP: seq 5 deny 1.0.1.0/24 (hit count: 0, refcount: 0)
Fix: Increment the prefix-list's hit count whenever a rule match occurs.
After Fix:
c1# show ip prefix-list nag seq 10
ZEBRA: seq 10 permit any (hit count: 0, refcount: 0)
BGP: seq 10 permit any (hit count: 6, refcount: 0)
c1# show ip prefix-list nag seq 5
ZEBRA: seq 5 deny 1.0.1.0/24 (hit count: 0, refcount: 0)
BGP: seq 5 deny 1.0.1.0/24 (hit count: 1, refcount: 0)
Signed-off-by: Visakha Erina visakha.erina@broadcom.com
Adding a read with the address of the thread pointer we want to
use will allow lib/thread.c to properly handle your thread pointers.
Instead we were setting the pointer to NULL before we passed
into the _read and _write thread functions. Remove the NULL
pointer set and just let thread.c handle everything.
vty_stdio_resume and vty_read would blindly add read and write
which would cause vty_event() to drop the thread pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Use %% style for errors in log commands and switch
tabs to a single space in output. Also, remove un-needed
output for success.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add vrrpd and sharpd to the DAEMONS_* list so they
can be dispatched daemons independent commands
such as `show work-queues` and `log-filter`.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
As logging functions are called, if filters are stored,
look for the filter substring in the logs. If it is not
found, do not output the log to a file or stdout.
If the filter is matched, handle the log call per usual.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add vtysh commands to add/del/clear/show filters across
all daemons and independently on each one. Add automake and
clippy boilerplate for those commands as well.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Simplify the code in deleting a filter by using memmove rather
than iterating. Memmove handles overlapping strings safely so
this is fine here.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add code for manipulation/creation of log filters
and their table. Specifically, add lookup,clear,add,del,dump
functionality.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
When displaying `show thread poll` data add the
function we are supposed to call when the poll
event happens.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When adding a read/write poll event and we are using a developmental
build add a bit of code to ensure that we do not already have an read
or write event scheduled.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If we have a case where have created a fd for i/o and we have
removed the handling thread but still have the fd in the poll
data structure, there existed a case where we would get
the handle this fd return from poll but we would immediately
do nothing with it because we didn't have a thread to hand
the event to.
This leads to an infinite loop. Prevent the infinite loop
from happening and log the problem.
We still need to find the cause of this happening. But
let's prevent the system from melting down in the mean time.
Fixes: #2796
Signed-off-by: David Lamparter <equinox@diac24.net>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is mostly relevant for Solaris, where config.h sets up some #define
that affect overall header behaviour, so it needs to be before anything
else.
Signed-off-by: David Lamparter <equinox@diac24.net>
For some reason, the compiler on OpenBSD on our CI boxes doesn't like
struct initializers with ".a.b = x, .a.c = y", generating a warning
about overwritten initializers...
Signed-off-by: David Lamparter <equinox@diac24.net>
We need to be calling snprintfrr() instead of snprintf() in places that
wrap snprintf in some user-exposed way; otherwise the extensions won't
be available for those functions.
Signed-off-by: David Lamparter <equinox@diac24.net>
clippy can't process #ifdef or similar bits inside of an argument list
(e.g. within the braces of a DEFUN or DEFPY statement.) Improve error
reporting to catch these cases instead of generating broken C code.
Fixes: #3840
Signed-off-by: David Lamparter <equinox@diac24.net>
* adds a `--with-clippy=...` option to use a prebuilt clippy binary
* limits the autoconf tests done for `--enable-clippy-only`
(e.g. no libyang)
Fixes: #3921Fixes: #4006
Signed-off-by: David Lamparter <equinox@diac24.net>
Even when using the classic CLI mode (i.e. when --tcli is not
used), the northbound code still uses vty->candidate_config
to perform configuration changes. From the perspective of the
user, the running configuration is being edited directly, but
under the hood the northbound layer does a full configuration
transaction for each command. When the running configuration is
edited by a northbound client other than the CLI (e.g. kernel,
gRPC), vty->candidate_config might become outdated, and this can
lead to lots of weird problems. To fix this, always regenerate
vty->candidate_config before each configuration command when
using the classic CLI mode. When using the transactional CLI,
the user needs to update the candidate manually using the "update"
command, otherwise the "commit" command will fail with this error:
"% Candidate configuration needs to be updated before commit".
Fixes some problems reported by Don after moving an interface from
one VRF to another one while zebra is running.
Reported-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Field vrf_id is replaced by the pointer of the struct vrf *.
For that all other code referencing to (interface)->vrf_id is replaced.
This work should not change the behaviour.
It is just a continuation work toward having an interface API handling
vrf pointer only.
some new generic functions are created in vrf:
vrf_to_id, vrf_to_name,
a zebra function is also created:
zvrf_info_lookup
an ospf function is also created:
ospf_lookup_by_vrf
it is to be noted that now that interface has a vrf pointer, some more
optimisations could be thought through all the rest of the code. as
example, many structure store the vrf_id. those structures could get
the exact vrf structure if inherited from an interface vrf context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
vrf_id parameter is replaced with struct vrf * parameter. It is
needed to create vrf structure before entering in the fuction.
an error is generated in case the vrf parameter is missing.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
there may be cases where the vrf is yet allocated from the vty, and the
discovery process did not make the relationship between the vrf_id and
the name of the vrf. For instance, by parsing an interface belonging to
vrf-id X, it is not sure that vrf-id X and vrfname XX are talking about
the same vrf. For that, lets allocate the vrf, and lets try to detect
there is a duplicate case in vrf, so that the merge can be done without
any impact for the user.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
the interface search is based on vrfs. As at startup, some interfaces
may be configured, there is need to have vrfs contexts present. A macro
is being appended with an extra parameter that permits create a vrf and
return the context. This macro is also used by some show routines, but
will not create vrfs, because that extra parameter will be set to false,
on that case.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Upon accessing interface NB API, the interface is created, if the vrf
is available. the commit does not change the behaviour, since at this
commit, this is not yet possible to have vrf contexts, while zebra did
not connect to daemons. However, that commit adds some work, so that it
will be possible to work on a vrf context, without having the vrf_id
completely resolved. for instance, if we suppose a vrf is created by
command 'vrf TOTO' in the starting configuration of a daemon, then 'interface
TITI vrf TOTO' will permit to create interface TITI within vrf TOTO.
the macro VRF_GET_INSTANCE will return the vrf context, if available or
not.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
Added a CLI "debug route-map" to enble route-map debugs
Added debugs for following triggers
1. Add/delete a route-map
2. Add/delete a sequence in route-map
3. Add/delete a match statement(dependency)
4. Update a dependency
5. Apply a route-map
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This version of container_of() should work on C++, by ditching the
unavailable builtins (at the cost of no longer checking for "const"
violations.)
Signed-off-by: David Lamparter <equinox@diac24.net>
vrf pointer is used as reference when calling if_get_by_name() function.
this will permit to create interfaces with an unknown vrf_id, since it
is only necessary to get the vrf structure to store the interfaces.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
On some compiler platforms the md5 setup function was
not returning anything. Place failure case on the bottom
to properly handle this situation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Various compilers in our CI system were complaining about various
auto-conversions. Let's get these cleaned up a bit more.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the user specifies -N namespace allow it to influence the
frr_vtydir(DAEMON_VTY_DIR) to have namespace in it's path
like so: $frrstate_dir/<namespace>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When using -z, allow that to override the zapi domain socket
path. If using -N add the namespace name to the path to
$frr_statedir/<namespace>/zserv.api. If you don't specify
the -N or -z option then it is $frr_statedir/zserv.api
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
reallocarray() is walled behind stupid feature macros on various
platforms and doesn't quite gain us much in that particular use case.
Signed-off-by: David Lamparter <equinox@diac24.net>
This makes printfrr extensions available in most of our format strings.
snprintf() is the obvious exception.
Signed-off-by: David Lamparter <equinox@diac24.net>
[u]int64_t is the only type in the intX_t family that needs
special-casing for printf since the calling convention may differ
between 32-bit and 64-bit systems.
Adding the L specifier allows us to eschew the gnarly-looking PRIu64.
Signed-off-by: David Lamparter <equinox@diac24.net>
The get_route_map_delete_event function should return a value
even if we never get to that part of the function. Make sure
we know why we are here so it can be fixed appropriately in
the future.
Signed-off-by: Donald Sharp <sharpd@cumulusnetwork.com>
The zebra_size_t type needs to be owned by zclient.h since
it is part of the zapi protocol. Move it to where the
structure belongs.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
zebra.h had some defined flags that were being used
as part of the route encode/decode functionality. These
belong in the zclient.h code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We have some functions that are owned by log.c, so
move their declarations from zebra.h to log.h
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The iana_afi_t and iana_safi_t were being created in zebra.h
and zebra.h is a bit of a dumping ground. When the iana_afi2str and
iana_safi2str functions were created, it was correctly pointed out
that we should just use the internal afi_t and safi_t 2str functions
but to do that we would need to include prefix.h in zebra.h. Which
really is not the right thing to do. This tells us that we need
to break out this code into it's own header.
Move to iana_afi.h the enums and specific functions and remove
from zebra. Convert to using the afi2str and safi2str functions.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the code such that we can auto turn the iana values of afi
and safi to pleasant to read strings.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Although the RFC states hostname length should be < 255 chars,
FRR allows infinite length technically. However, when you try
to set a hostname > 80 chars, you would immediately notice a crash.
RCA: Crash due to buffer overflow. Large buffer sprintf'd into smaller
buffer. Usage of sprintf function instead of snprintf which is safer.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.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>
When you have compiled FRR with a large multipath number
then encoding large ecmp routes between zebra and the
routing daemons. There exists a theoritical size
of multipath that will cause the encoding to be larger
than the ZEBRA_MAX_PACKET_SIZ. In the cases where
we have allocated streams that will encode routes
then let's ensure that whatever size we have will
auto-fit what we say we can send.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add 'no log commands' cli and at the same time add a
--command-log-always to the daemon startup cli.
If --command-log-always is specified then all commands are
auto-logged and the 'no log commands' form of the command
is now ignored.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
gcc is complaing about this with --enable-dev and --enable-werror:
In function 'nb_log_callback',
inlined from 'nb_transaction_apply_finish' at lib/northbound.c:1106:4:
lib/northbound.c:777:2: error: '%s' directive argument is null [-Werror=format-overflow=]
777 | zlog_debug(
| ^~~~~~~~~~~
778 | "northbound callback: event [%s] op [%s] xpath [%s] value [%s]",
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
779 | nb_event_name(event), nb_operation_name(operation), xpath,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
780 | value);
| ~~~~~~
CC lib/ringbuf.lo
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The vtypath_default variable had a possibility of being overwritten
due to size constraints. This fixes this issue.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.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>
Separate out the debug_init api to have 2 functions:
1) Function to register a callback
2) Function to initiate the cli.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
