FRR only needs lua library (package libluaX.Y-dev) to be compiled and
linked, but its `configure` script makes use of lua interpreter to
perform its checks. Therefore, `luaX.Y` package is a requisite
build-dependency for debian packaging.
This commit adds the debian package with the lua interpreter to the
build dependencies.
Signed-off-by: Eugene Crosser <crosser@average.org>
Whn using as-override, we should be able to deny outgoing updates from
being propogated when `neighbor soo` is configured.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In kernel_socket.c, the code is deleting and then adding
the route back in on a change operation. This just translates
too two re's, one for deletion and one for addition. The deletion
will just be ignored. Let's not do the extra deletion.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The new route code path was using a combination of
both rib_add() and rib_add_multipath() let's clean
it up some to use rib_add_multipath()
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently if an operator does this operation:
sharpd@eva ~/frr8> sudo ip nexthop add id 5000 via 192.168.119.44 dev enp39s0 ; sudo ip route add 10.0.0.1 nhid 5000
2022/06/30 08:52:40 ZEBRA: [ZHQK5-J9M1R] proto2zebra: Please add this protocol(0) to proper rt_netlink.c handling
2022/06/30 08:52:40 ZEBRA: [PS16P-365FK][EC 4043309076] Zebra failed to find the nexthop hash entry for id=5000 in a route entry
sharpd@eva ~/frr8> vtysh -c "show ip route 10.0.0.1"
Routing entry for 0.0.0.0/0
Known via "kernel", distance 0, metric 100, best
Last update 00:01:58 ago
* 192.168.119.1, via enp39s0
The route is dropped by zebra with no warnings. This is not good,
but unlikely to happen at this point in time. In order to fix
this issue route processing from inputs needs to happen after nexthop
group processing from inputs. This was not possible because
nexthop groups are placed on the metaQ. As such the above
nexthop group creation is placed on the metaQ for processing
in META_QUEUE_NHG. Then the route is read in and processed
immediately. The nexthop group is not found ( not processed yet!)
and the route is dropped in zebra.
Modify the code to have early route processing of validity
on the MetaQ. This preserves the order of operations.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Convert label processing that comes from zapi messages
into being handled by the meta-Q. This is because early
route processing is going to be moved to the meta-Q as
well and we will have a chicken and egg problem without
moving this code to be processed by the meta-Q.
Ordering of messages from ospf as an example:
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:62] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:43] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:61] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:66] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
The ZEBRA_MPLS_LABELS_REPLACE immediately turn around and attempt to replace nexthop labels on routes that
were added. If the route add is placed on the metaQ, it will not exist yet and as such the label replace
will fail.
Modify the zebra code to take the label operations and place them on the metaQ as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Before this, if the community-list has an entry with permit internet (0:0),
then it's treated as permit everything and returned as MATCH.
So if we have something like:
```
bgp community-list standard OUT_AS_PERMIT seq 5 permit internet
bgp community-list standard OUT_AS_PERMIT seq 10 deny 4:1
bgp community-list standard OUT_AS_PERMIT seq 20 permit 3:1
```
It's not gonna work because it will return MATCH and stops parsing.
Routes with 4:1 community will be advertised.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The socket created for pimv6 was created using AF_INET for PIMV6
too.
Since the api pim_reg_sock is common to both PIMv4 and PIMv6,
need to use PIM_AF instead of AF_INET.
Fixes: #11815
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Before:
```
donatas-laptop# show bgp ipv4 unicast community-list testas
% testas is not a valid community-list name
donatas-laptop# con
donatas-laptop(config)# bgp community-list standard testas permit internet
donatas-laptop(config)# do show bgp ipv4 unicast community-list testas
donatas-laptop(config)#
```
`is not a valid community-list name` is a misleading warning message.
Doing the same for filter-list, access-list, prefix-list, route-map.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Although VTY_GET_CONTEXT can return a failed value, it will
never happen in pbrd because of how context work. In
any event add some code to make coverity happy
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
ls_msg2edge calls ls_edge_del_all which will free the
edge variable. Ensure that FRR properly returns NULL.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The call into pim_cmd_lookup_vrf may be NULL
and dereferencing it before ensuring that the
vrf pointer is non-NULL is a good way to crash.
A crash can be initiated in pim:
eva# show ip msdp vrf NOEXIST mesh-group
vtysh: error reading from pimd: Permission denied (13)Warning: closing connection to pimd because of an I/O error!
eva# 2022/08/15 11:47:38 [PHJDC-499N2][EC 100663314] STARVATION: task vtysh_rl_read (560b77f76de6) ran for 16777ms (cpu time 0ms)
eva#
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
