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>
When using pam for authentication, the code just silently
fails and gives no indication to the end user what has gone
wrong. Try to increase messaging about what has gone wrong
by outputting some more data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When installing a table route into the kernel choose
RTPROT_ZEBRA as the installing/controlling protocol.
This way we can know we installed it as well as stop
the warnings about this special case of `ip import-table XX`
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are importing/removing the table entry from table X into the
default routing table we are not properly setting the table_id
of the route entry. This is causing the route to be pushed
into the wrong internal table and to not be found for deletion.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The import table code assumes that they will only work
in the default vrf. This is ok, but we should push the
vrf_id and zvrf to be passed in instead of just using
VRF_DEFAULT.
This will allow us to fix a couple of things:
1) A bug in import where we are not creating the
route entry with the appropriate table so the imported
entry is showing up in the wrong spot.
2) In the future allow `ip import-table X` to become
vrf aware very easily.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The import-table code when looking up the table to use
for route-import was reversing the order of the table_id
and vrf_id causing us to never ever lookup a table
and we would cause the `ip|ipv6 import-table X` commands
to be just ignored.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Improve debugging when we cannot find a route to delete
that we have been told to delete.
New output:
2019/06/25 17:43:49 ZEBRA: default[0]:4.5.6.7/32 doesn't exist in rib
2019/06/25 17:43:49 ZEBRA: default[0]:4.5.6.8/32 doesn't exist in rib
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add a not under the log-filter command to indicate
that, while filtering reduces load on the system by
large margins, there may still be a small performance
hit from filtering those.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
This helps northbound to create the `bfd` node on the configuration
output sooner than adding a peer.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
When we receive an igmp query on a interface, ensure that the
source address of the packet is connected to the incoming
interface. This will prevent a meanie from crafting a igmp
packet with a source address less than ours and causing
us to suspend query activities.
Fixes: #1692
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The `no redistribute ...` commands were not allowing
the input to be in any order. Fix code to allow this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Build will fail with `Werror` enabled with:
```
CC bfdd/bfdd_cli.o
In file included from ./lib/frratomic.h:21:0,
from ./lib/memory.h:22,
from ./lib/vector.h:25,
from ./lib/command.h:25,
from bfdd/bfdd_cli.c:23:
./config.h:665:0: error: "_FILE_OFFSET_BITS" redefined [-Werror]
#define _FILE_OFFSET_BITS 64
^
In file included from /usr/include/iso/stdlib_iso.h:49:0,
from /usr/include/stdlib.h:37,
from ./lib/memory.h:20,
from ./lib/vector.h:25,
from ./lib/command.h:25,
from bfdd/bfdd_cli.c:23:
/opt/gcc-5.1.0/lib/gcc/i386-pc-solaris2.11/5.1.0/include-fixed/sys/feature_tests.h:231:0: note: this is the location of the previous definition
#define _FILE_OFFSET_BITS 32
^
In file included from ./lib/thread.h:24:0,
from ./lib/vty.h:27,
from ./lib/command.h:26,
from bfdd/bfdd_cli.c:23:
./lib/zebra.h:271:2: error: #warning "assuming 4-byte alignment for CMSG_SPACE" [-Werror=cpp]
#warning "assuming 4-byte alignment for CMSG_SPACE"
^
./lib/zebra.h:277:2: error: #warning "assuming 4-byte alignment for CMSG_LEN" [-Werror=cpp]
#warning "assuming 4-byte alignment for CMSG_LEN"
^
cc1: all warnings being treated as errors
Makefile:6876: recipe for target 'bfdd/bfdd_cli.o' failed
gmake[1]: *** [bfdd/bfdd_cli.o] Error 1
```
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
1) If we are moving the nexthop we are tracking to
a new rn in the rib, then we know that the route
to get to that nexthop has changed. As such
we should notify the upper level.
This manifested itself because the code had a trigraph `?`
in the wrong order. Put the comparison in the right order.
2) If we are re-matching to the same rn and we call compare_state
then we need to see if our stored nexthops are the same or different.
If they are the same we should not notify. If they are different
we should notify. compare_state was only comparing the flags
on a route and since those are not necessarily the right flags
to look at( and we are well after the fact that the route has
already changed and been processed ) let's just compare
the nexthops to see if they are the same or different.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix details :
Added a utility cli to generate a igmp query on an interface.
This won't impact the existing query generation based on the
general query interval.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
when receiving an EAGAIN while trying to read the header
of a ZAPI message, we were erroneously continuing as if
everything was fine, which could crash zebra. Fix this
by returning and letting the re-armed read task deal with
this
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
under some conditions, the callback to get a label for
a LU bgp path could be called after the path had already
been freed. In this case we would be reading garbage
and potentially crash. Lock the path info before
queueing the callback, and unlock as the first step
of the callback, exiting gracefully if the path info
is now NULL.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
In a pim-evpn setup (say TORC11<=>TORC12) an mroute can have a mix of
PIM and IGMP joins. The vxlan termination device ipmr-lo is IGMP
joined on termination mroutes and the peerlink-rif can be pim joined
on the same mroute if the MLAG peer (TORC11) loses all its uplinks to
underlay -
root@TORC12:~# net show pim state 239.1.1.101|grep pimreg
1 * 239.1.1.101 uplink-1
pimreg(I ), ipmr-lo( J ), peerlink-3.4094( J )
root@TORC12:~#
When the uplinks come back up on TORC11 it will prune the peerlink-rif
and join the RP (say spine) via the uplinks.
TORC12 is rxing the prune and removing the if_channel
(pim_ifchannel_delete). However it is not removing the OIF from
mfcc_ttl basically leaving behind a leaked OIF in the forwarding
entry. And this is because it is deriving the owner flag from the
parent upstream entry and incorrectly concluding that all OIFs are
IGMP joined.
Thix fix flushes out both PIM and IGMP ownership when the ifchannel is
deleted.
There is a second fix in the commit and that is to set the proto mask
correctly (to STAR) for inherited OIFs. (S,G) entries can inherit the
OIF from the (*, G) entry and this decision can change when the pim/igmp
ifchannel is removed. The earlier code was setting the proto-mask
incorrectly to PIM or IGMP.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit d4d1d968dbbe61347393f7dace8b675496ff1024)
When a link goes down the vifi was being deleted but the OIF stayed
in the OIL with a stale vifi -
oroot@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source Group IIF OIL
1 * 239.1.1.111 swp1s1 pimreg(I ), ipmr-lo( J )
1 6.0.0.28 239.1.1.111 lo pimreg( J ), ipmr-lo( *), swp1s1( J )
root@act-7726-03:~# ip link set swp1s1 down
root@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source Group IIF OIL
1 * 239.1.1.111 swp1s0 pimreg(I ), ipmr-lo( J )
1 6.0.0.28 239.1.1.111 lo ipmr-lo( *), swp1s0( J ), <oif?>( J ) >>>>>>>>
root@act-7726-03:~#
The problem was as a part ifchannel_delete the join state of the channel
was checked to avoid incorrect OIF deletion this was preventing the OIF
from being flushed. Fix is to flip the channel join-state to NOINFO before
deleting it.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
These two data types were written to handle redistribute
and external data types. On shutdown cleanup the memory
allocated to these if we are doing redistribution.
This was found using valgrind.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Lets allow specification to accept microseconds, but limit the timers
configuration in FRR to milliseconds (minimum is 10 ms and maximum is 60
seconds).
This matches the RFC 5880 and the IETF BFD YANG draft model.
Signed-off-by: Rafael Zalamena <rzalamena@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>
Add command 'no bfd' to remove all BFD sessions configuration and fix
other daemon integration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
```
warnings: BFD: [EC 100663317] YANG model "frr-bfdd@*" not embedded, trying external file
```
Embed the YANG model into the binary to avoid reading an external file.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When the remote discriminator hasn't been assigned yet, then we can't
return a value of 0. The value '0' is an invalid discriminator and the
yang handlers will complain about it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Lets start using the new BFD yang model and translate the BFD session
configuration commands to use the northbound.
One important change: all sessions will default to use
`VRF_DEFAULT_NAME` (usually "default") when no VRF is configured. All
places which search for BFD sessions must now take this into account.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
