Let's try to remember that when using a malloc function
it can never fail and as such testing for NULL does
nothing.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Introduce ZEBRA_IF_DUMMY interface flag to identify Linux dummy interfaces [0].
These interfaces behave similarly to loopback interfaces and can be
specially handled by daemons.
[0]: https://github.com/torvalds/linux/blob/master/drivers/net/dummy.c
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Just like `link down`, check all kernel routes when interface become up.
And, they maybe will be selected as the best one by zebra.
Signed-off-by: anlan_cs <anlan_cs@126.com>
The functions:
if_get_flags
if_flags_update
if_flags_mangle
are never invoked from a linux netlink build. Put a #ifdef
around those functions so that they are not included on the
linux build as that they are not needed there.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
For interface config:
shutdown
mpls
multicast
These states were never being shown in output, let's show it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Current code intentionally ignores kernel routes. Modify
zebra to allow these routes to be read in on linux. Also
modify zebra to look to see if a route should be treated
as a connected and mark it as such.
Additionally this should properly handle some of the issues
being seen with NOPREFIXROUTE.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
During internal testing, when the following sequence is followed, two
non default vrfs end up pointing to the same table-id
- Initially vrf201 has table id 1002
- ip link add dev vrf202 type vrf table 1002
- ip link set dev vrf202 up
- ip link set dev <intrerface> master vrf202
This will ideally lead to zebra exit since this is a misconfiguration as
expected.
However if we perform a restart frr.service at this point, we end up
having two vrfs pointing to same table-id and bad things can happen.
This is because in the interface_vrf_change, we incorrectly check for
vrf_lookup_by_id() to evaluate if there is a misconfig. This works well
for a non restart case but not for the startup case.
root@mlx-3700-20:mgmt:/var/log/frr# sudo vtysh -c "sh vrf"
vrf mgmt id 37 table 1001
vrf vrf201 id 46 table 1002
vrf vrf202 id 59 table 1002 >>>>
Fix: in all cases of misconfiguration, exit zebra as expected.
Ticket :#3970414
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
In case of EVPN MH bond, a member port going in
protodown state due to external reason (one case being linkflap),
frr updates the state correctly but upon manually
clearing external reason trigger FRR to reinstate
protodown without any reason code.
Fix is to ensure if the protodown reason was external
and new state is to have protodown 'off' then do no reinstate
protodown.
Ticket: #3947432
Testing:
switch:#ip link show swp1
4: swp1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9216 qdisc
pfifo_fast master bond1 state DOWN mode DEFAULT group default qlen
1000
link/ether 1c:34:da:2c:aa:68 brd ff:ff:ff:ff:ff:ff protodown on
protodown_reason <linkflap>
switch:#ip link set swp1 protodown off protodown_reason linkflap off
switch:#ip link show swp1
4: swp1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 9216 qdisc
pfifo_fast master bond1 state DOWN mode DEFAULT group default qlen
1000
link/ether 1c:34:da:2c:aa:68 brd ff:ff:ff:ff:ff:ff
Signed-off-by: Chirag Shah <chirag@nvidia.com>
A specific sequence of actions involving the addition and removal of IP
routes and network interfaces can lead to a route installation failure.
The issue occurs under the following conditions:
- Initially, there is no route present via the ens3 interface.
- Adds a route: ip route 10.0.0.0/24 192.168.0.100 ens3
- Removes the same route: no ip route 10.0.0.0/24 192.168.0.100 ens3
- Removes the ens3 interface.
- Re-adds the ens3 interface.
- Again adds the same route: ip route 10.0.0.0/24 192.168.0.100 ens3
- And again removes it: no ip route 10.0.0.0/24 192.168.0.100 ens3
- Shuts down the ens3 interface
- Reactivates the interface
- Adds the route once more: ip route 10.0.0.0/24 192.168.0.100 ens3
The route appears to be rejected.
> # show ip route nexthop
> S>r 10.0.0.0/24 [1/0] (6) via 192.168.0.100, ens3, weight 1, 00:00:01
The commit 35729f38fa ("zebra: Add a timer to nexthop group deletion")
introduced a feature to keep a nexthop-group in Zebra for a certain
period even when it is no longer in use. But if a nexthop-group
interface is removed during this period, the association between the
nexthop-group and the interface is lost in zebra memory. If the
interface is later added back and a route is re-established, the
nexthop-group interface dependency is not correctly reestablished.
As a consequence, the nexthop-group flags remain unset when the
interface is down. Upon the interface's reactivation, zebra does not
reinstall the nexthop-group in the kernel because it is marked as valid
and installed, but in reality, it does not exist in the kernel (it was
removed when the interface was down). Thus, attempts to install a route
via this nexthop-group ID fail.
Stop maintaining a nexthop-group when its associated interface is no
longer present.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The function call in to zebra_interface_nhg_reinstall
is an action that takes place on interface up events
*not* when the connected addresses are added to
a system. this will prevent this function being
called when new connected interfaces come alive
that is an independent operation of the interface
coming up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
zebra_if_nhg_dependents_XXX were just simple wrapper
functions that inited/deleted data structures.
These were already function calls themselves. Let's
remove the abstraction and make the code simpler.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
These functions provided a level of abstraction that forced
us to call multiple functions when a simple data structure
change was all that is needed. Let's consolidate down
and make things a bit simpler.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
get_iflink_speed() returns UINT32_MAX when the speeds is unknown.
Routing daemons (at least ospfd) interprets it as the high value.
Return errors in get_iflink_speed() to avoid the confusion.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
- use `apply_finish` callback when possible to avoid multiple applies per commit
- move table range working to the CLI handler
- remove unnecessary conditional compilation
- remove unnecessary boolean conversion
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Make link-params a presence container and activate it when entering the
node. The "enable" command is not necessary anymore but kept hidden for
backwards compatibility.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Replace "shutdown" leaf with "enabled" leaf in frr-zebra YANG module
to make it in line with standard YANG models.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Introduce new "[no] multicast <enable|disable>" command to be able to
remove the configuration. Current "[no] multicast" command cannot be
removed. Current command is hidden but still works for backwards
compatibility.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Currently, when editing a leaf-list, `nb_candidate_edit` expects to
receive it's xpath without a predicate and the value in a separate
argument, and then creates the full xpath. This hack is complicated,
because it depends on the operation and on the caller being a backend or
not. Instead, let's require to always include the predicate in a
leaf-list xpath. Update all the usages in the code accordingly.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
- initialize the necessary bit when creating if_link_params
- fix CLI description to mark extended as the default mode
- correctly set mode to extended when using the "no" form of the command
- handle the "show_defaults" parameter correctly in cli_show callback
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
First, any data tree validation in CLI handler is not correct, because
this code won't be called when the change is done through any other
frontend. Second, these checks are not necessary at all, because NB
layer handles the change between admin-grp/affinity automatically.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
- it was not printed at all because of the incorrect `yang_dnode_exist`
check
- the intended output was "admin-group" instead of "admin-grp" used in
the actual CLI command
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Despite if it's managed by FRR or the kernel, show it. If the system has only
link-local addresses, we should show it unless it's a secondary one.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Let's say we this:
```
$ ip link set down dev r1-eth0
$ ip link set up dev r1-eth0
```
But at the same time we have this interface configured by the FRR too:
```
interface r1-eth0
ipv6 address fe80:1::1/64
exit
```
We never re-add fe80:1::1/64, when the interface comes up, and we have a
strange situation where NHT stops working and other stuff depending on NHT
stops too (BGP peering, etc.).
Closes: https://github.com/FRRouting/frr/issues/15050
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
