In this commit, we are creating a dummy upstream & dummy channel_oil
for (*, G) when RP is not configured or not reachable.
Dummy upstream: <upstream_addr = INADDR_ANY, rpf = Unknown>
Dummy channel oil: <iif = MAXVIFS>
Signed-off-by: Sarita Patra <saritap@vmware.com>
When FRR receives IGMP/PIM (*, G) join and RP is not configured or not
reachable, then we are creating a dummy upstream with incoming interface
as NULL and upstream address as INADDR_ANY.
Added upstream address and incoming interface validation where it is necessary,
before doing any operation on the upstream.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When FRR receives IGMP/PIM (*, G) join and RP is not configured or
not reachable, then we are creating a dummy upstream with incoming
interface as NULL.
Added some null checks for the incoming interface, while displaying
the pim upstream information in the cli command "show ip pim upstream".
Signed-off-by: Sarita Patra <saritap@vmware.com>
Added comments which explains the new values for existing fields
and new fields in the upstream and channel_oil data structure.
Following are the summary of the behaviour change in PIM code.
Scenario 1 : RP doesn’t exist/RP not reachable
Event: Join received
Current behaviour:
No upstream gets created
Changed behaviour:
Upstream data structure created with below info
upstream_addr: INADDR_ANY
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE (flag introduced to indicate if this entry is valid to get installed in hardware)
RPF details: Not valid
Join state: NOT_JOINED
Kernal installed: FALSE
Scenario 2: Dummy upstream exists
Event: RP configured
Current Behaviour:
upstream address updated for the dummy upstream created.
Changed Behaviour:
upstream_addr: RP address
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE
RPF details: only RP address updated
Join state: NOT_JOINED
Kernel installed: FALSE
Scenario 3: Dummy upstream exists
Event: RP becomes reachable
Current Behaviour:
Update channel oil, rpf details in the upstream and install in hardware
Changed Behaviour:
upstream_addr: RP Adress
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE
RPF details: RPF details updated via NHT callback
Join state: JOINED
Kernel installed: TRUE
Scenario 4: MRoute exists
Event: RP gets deleted
Current behaviour:
Nothing got updated in him upstream and channel oil,
join timer still runs. Mroute still exists in kernel.
Changed behaviour:
upstream_addr: INADDR_ANY
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE
RPF details: Not valid
Join state: NOT_JOINED (also sent prune towards deleted RPF nbr)
Kernel installed: FALSE
Scenario 5: MRoute Exists
Event: RP unreachable
Current behaviour:
Nothing got updated in him upstream and channel oil,
join timer still runs. Mroute sdeleted from kernel.
Changed behaviour:
upstream_addr: RP address
channel_oil iif: MAXVIF
channel_oil is_valid: FALSE
RPF details: only RP address updated
Join state: NOT_JOINED (also sent prune towards deleted RPF nbr)
Kernel installed: FALSE
Scenario 6: Mroute exists
Event: Better RP configured with precise group range & reachable.
Current behaviour:
No effect on existing route.
Changed behaviour:
Upstream address: Better RP
RPF interface: towards the better RP
Join state: JOINED (Send a prune towards the old RP and send a join
towards the better RP)
Scenario 7: Mroute exists
Event: RP deleted and another RP with broad group range fits this group & reachable
Current behaviour:
No effect on current behaviour
Changed behaviour:
Upstream address: next available RP
RPF interface: towards the next available RP
Join state: JOINED (Send a prune towards the old RP and send a join
towards the better RP)
Signed-off-by: Sarita Patra <saritap@vmware.com>
Display only ipv4 neighbors when 'show bgp ipv4 neighbors' command is issued.
Display only ipv6 neighbors when 'show bgp ipv6 neighbors' command is issued.
Take the address family of the peer address into account, while displaying the neighbors.
Signed-off-by: Akhilesh Samineni <akhilesh.samineni@broadcom.com>
Running zebra after commit 888756b208
in valgrind produces this item:
==17102== Invalid read of size 8
==17102== at 0x44D84C: rib_dest_from_rnode (rib.h:375)
==17102== by 0x4546ED: rib_process_result (zebra_rib.c:1904)
==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102== by 0x4D0902B: thread_call (thread.c:1607)
==17102== by 0x4CC3983: frr_run (libfrr.c:1011)
==17102== by 0x4266F6: main (main.c:473)
==17102== Address 0x83bd468 is 88 bytes inside a block of size 96 free'd
==17102== at 0x4A35F54: free (vg_replace_malloc.c:530)
==17102== by 0x4CCAC00: qfree (memory.c:129)
==17102== by 0x4D03DC6: route_node_destroy (table.c:501)
==17102== by 0x4D039EE: route_node_free (table.c:90)
==17102== by 0x4D03971: route_node_delete (table.c:382)
==17102== by 0x44D82A: route_unlock_node (table.h:256)
==17102== by 0x454617: rib_process_result (zebra_rib.c:1882)
==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102== by 0x4D0902B: thread_call (thread.c:1607)
==17102== by 0x4CC3983: frr_run (libfrr.c:1011)
==17102== by 0x4266F6: main (main.c:473)
==17102== Block was alloc'd at
==17102== at 0x4A36FF6: calloc (vg_replace_malloc.c:752)
==17102== by 0x4CCAA2D: qcalloc (memory.c:110)
==17102== by 0x4D03D88: route_node_create (table.c:489)
==17102== by 0x4D0360F: route_node_new (table.c:65)
==17102== by 0x4D034F8: route_node_set (table.c:74)
==17102== by 0x4D03486: route_node_get (table.c:327)
==17102== by 0x4CFB700: srcdest_rnode_get (srcdest_table.c:243)
==17102== by 0x4545C1: rib_process_result (zebra_rib.c:1872)
==17102== by 0x45436D: rib_process_dplane_results (zebra_rib.c:3295)
==17102== by 0x4D0902B: thread_call (thread.c:1607)
==17102== by 0x4CC3983: frr_run (libfrr.c:1011)
==17102== by 0x4266F6: main (main.c:473)
==17102==
This is happening because of this order of events:
1) Route is deleted in the main thread and scheduled for rib processing.
2) Rib garbage collection is run and we remove the route node since it
is no longer needed.
3) Data plane returns from the deletion in the kernel and we call
the srcdest_rnode_get function to get the prefix that was deleted.
This recreates a new route node. This creates a route_node with
a lock count of 1, which we freed via the route_unlock_node call.
Then we continued to use the rn pointer. Which leaves us with use
after frees.
The solution is, of course, to just move the unlock the node at the
end of the function if we have a route_node.
Fixes: #3854
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The community_delete and lcommunity_delete functionality was
creating a special string that needed to be specially parsed.
Remove all this string creation and just pass the pertinent
data into the appropriate functions.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Commit: 6005fe55bc
Introduced a crash with zebra looking up either the
nbr structure or the mac structure. This is because
the zvni used is NULL and we eventually call a hash_lookup
call that would cause a NULL dereference. Partially
revert this commit to original behavior.
Problems found via clang Static Analyzer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The struct prefix *prefix is really a const struct prefix *
This was causing compile warns->errors on some compilers
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
L3VNI keeps reference to svi interface (ifp).
When a netlink change received there is no flag
that mac has changed. Currently simply overwrite
interface's (ifp) hw_addr (MAC) field.
For originating EVPN type-2 and type-5 routes due to VNI
MAC change, comparison is required to check existing MAC
vs. netlink change MAC field.
Ticket:CM-23850
Reviewed By:CCR-8283
Testing Done:
Validate EVPN type-5 routes originated upon changing MAC address
of L3VNI's SVI inteface via ip link set cmd.
checked show bgp l2vpn evpn route and Rmac field contains new
MAC address.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
In order to iterate over MPLS VPN routes, it's necessary to use
two nested loops (the outer loop iterates over the MPLS VPN RDs,
and the inner loop iterates over the VPN routes from that RD).
The add-path code wasn't doing this, which was leading to lots of
crashes when add-path was enabled for the MPLS VPN SAFI. This patch
fixes the problem.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
If path->net is NULL in the bgp_path_info_free() function, then
bgpd would crash in bgp_addpath_free_info_data() with the following
backtrace:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ff7b267a42a in __GI_abort () at abort.c:89
#2 0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249
#3 <signal handler called>
#4 idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368
#5 0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100
#6 0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252
#7 bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276
#8 0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320
#9 0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476
#10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503
#11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294
#12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606
#13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011
#14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481
Add a null-check protection to fix this problem.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
isisd CLI has some housekeeping code that removes the
"frr-isisd:isis" container from the interface configuration when
IS-IS is disabled for both IPv4 and IPv6 in the corresponding
interface.
The problem is that the code was checking the values of the
"ipv4-routing" and "ipv6-routing" leafs without checking if the
parent "frr-isisd:isis" container was present. So, entering "no
ip[v6] router isis" twice would cause isisd to crash since the
"frr-isisd:isis" container wouldn't be present the second time the
command is processed. Fix this.
isisd aborted: vtysh -c "configure terminal" -c "interface eth99" -c "no ip router isis WORD"
isisd aborted: vtysh -c "configure terminal" -c "interface eth99" -c "no ipv6 router isis"
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Fix bug in the code that compares IPv6 addresses. If memcmp()
returns 0 then the two addresses are equal.
Because of this problem, hash_release() could return NULL in a few
places, leading to the following crashes (found by the CLI fuzzer):
pbrd aborted: vtysh -c "configure terminal" -c "pbr-map WORD seq 100" -c "no set nexthop 2001:db8::1"
pbrd aborted: vtysh -c "configure terminal" -c "nexthop-group NHGROUP" -c "no nexthop 2001:db8::1"
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add a test command to pim that allows you to reset the keepalive timer
for an upstream to it's max value. This is to allow purposeful testing
of cleanup code in pim, by forcing the keeaplive timer to expire later.
robot# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
enp3s0 192.168.201.136 225.1.0.0 NotJ,RegP 00:00:10 00:00:52 00:00:25 00:02:54 1
robot# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
enp3s0 192.168.201.136 225.1.0.0 NotJ,RegP 00:00:11 00:00:51 00:00:24 00:02:53 1
robot# test pim keep 192.168.201.136 225.1.0.0
Setting (192.168.201.136,225.1.0.0) to current keep alive time: 210
robot# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
enp3s0 192.168.201.136 225.1.0.0 NotJ,RegP 00:00:27 00:00:35 00:00:08 00:03:27 1
robot#
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This has a python script that helps in collecting various CLI show command outputs in an automated way.
This commit has two files.
1.Text Configuration file: support_bundle_commands.conf - This file has list of CLI show commands to be executed. This file will be in tools/etc/frr/ directory. On executing command "sudo install -m 644 tools/etc/frr/ support_bundle_commands.conf /etc/frr/support_bundle_commands.conf", as part of FRR installation, this file will be copied into /etc/frr directory.
2.Python script file: generate_support_bundle.py - This file has the python code that has the below functionality.
* It reads the support_bundle_commands.conf file. For each process present in the conf file, it creates a support_bundle file. For example, it creates bgp_support_bundle.log file for BGP and zebra_support_bundle.log file for Zebra. These files will be created in /var/log/frr/ directory. This is where regular FRR log files are also stored currently.
* The script reads the CLI command specified between CLI_START and CLI_END key words for each process. It will execute the commands one by one.
* For each such command, the script also appends the current time stamp at which the CLI command is executed.
* In case of successful execution of the CLI command, it will copy the CLI output into the above support bundle file.
* In case of CLI command failure, it will capture the error thrown and the error is also written into the same file.
* A small snippet of the output file is as below.
>>[2019-01-02 13:55:23.318987]show bgp summary
IPv4 Unicast Summary:
BGP router identifier 203.0.113.1, local AS number 65000 vrf-id 0
BGP table version 4
RIB entries 7, using 1176 bytes of memory
Peers 1, using 21 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
203.0.113.2 4 65001 34 34 0 0 0 00:29:47 2
Total number of neighbors 1
>>[2019-01-02 13:55:23.619953]show ip bgp
BGP table version is 4, local router ID is 203.0.113.1, vrf id 0
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Signed-off-by: Sri Mohana Singamsetty <msingamsetty@vmware.com>
The support of embedded extensions doesn't allow to build the
RPM with and without (for older version). Require new version of
Lbyang with embedded extensions supported
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
After creating a libyang context, we need to hook up our callback to use
embedded built-in modules. I hadn't added this to the yang translator
code.
Also, ly_ctx_new fails if the search directory doesn't exist. Since
that's not a hard error for us, work around that and ignore inaccessible
YANG_MODELS_DIR. (This is needed for snap packages.)
Signed-off-by: David Lamparter <equinox@diac24.net>
TBH when I looked at watchfrr I didn't see any MI support and hence
assumed this just didn't work to begin with. However, it actually does
(transparently to watchfrr, by just using "ospfd-1" as daemon name.)
So, fix this up and make it work again.
(Also remove 2 extraneous \n in messages.)
Signed-off-by: David Lamparter <equinox@diac24.net>
watchfrr_enable is ignored, watchfrr_options is unneeded and the
valgrind options have been replaced with daemon_wrap/all_wrap.
Signed-off-by: David Lamparter <equinox@diac24.net>
There's no good reason to not have these options default to the
installation path of tools/watchfrr.sh. Doing so allows us to ditch
watchfrr_options from daemons/daemons.conf completely.
Fixes: #3652
Signed-off-by: David Lamparter <equinox@diac24.net>
We were missing several Conflicts: (or Breaks:) lines. Specifically,
- the .png diagrams in frr-doc conflict with quagga-doc
- the quagga package was split up and we conflict on each on the
daemon's man pages
- pimd also conflicts on the man page.
This is a "conservative" fix for the time being, putting everything into
Conflicts:. Some of these might have other options to fix them (e.g.
renaming the diagrams or man pages) but that needs more thought and
isn't appropriate for a simple fix.
There is also the "layer 9" consideration of whether to add "Replaces:
quagga" lines. For the time being I'd say it's a bit early to have that
discussion.
Reported-by: Andreas Beckmann <anbe@debian.org>
References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921376
Signed-off-by: David Lamparter <equinox@diac24.net>
Dependencies for the actual library packages are autogenerated by shlib
handling. Removing the bogus line should hopefully get this to build
on Debian buildd...
Signed-off-by: David Lamparter <equinox@diac24.net>
While originally created to support upgrading within non-official
previous FRR packages, the same logic makes upgrading from Quagga
configs more straightforward.
Signed-off-by: David Lamparter <equinox@diac24.net>
If we try to monitor a nonexisting daemon in watchfrr, it will
(currently) forever wait at startup since the vty connection will never
come up. Just drop the daemon from the daemon list in such a case.
Signed-off-by: David Lamparter <equinox@diac24.net>
If we wait forever for all daemons to come up, we can hang the entire
boot process, especially on init.d based systems.
Signed-off-by: David Lamparter <equinox@diac24.net>
Ditch the old non-working one and add 3 new ones to check:
- that zebra can talk to the kernel at least somewhat
- that SNMP and RPKI modules can be loaded
- that frr-reload.py works
This should catch most build environment SNAFUs.
Signed-off-by: David Lamparter <equinox@diac24.net>
