Add ability for the connected routes to know
if they are a prefix route or not.
sharpd@eva:/work/home/sharpd/frr1$ ip addr show dev dummy1
13: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether aa:93:ce:ce:3f:62 brd ff:ff:ff:ff:ff:ff
inet 192.168.55.1/24 scope global noprefixroute dummy1
valid_lft forever preferred_lft forever
inet 192.168.56.1/24 scope global dummy1
valid_lft forever preferred_lft forever
inet6 fe80::a893:ceff:fece:3f62/64 scope link
valid_lft forever preferred_lft forever
sharpd@eva:/work/home/sharpd/frr1$ sudo vtysh -c "show int dummy1"
Interface dummy1 is up, line protocol is up
Link ups: 0 last: (never)
Link downs: 0 last: (never)
vrf: default
index 13 metric 0 mtu 1500 speed 0 txqlen 1000
flags: <UP,BROADCAST,RUNNING,NOARP>
Type: Ethernet
HWaddr: aa:93:ce:ce:3f:62
inet 192.168.55.1/24 noprefixroute
inet 192.168.56.1/24
inet6 fe80::a893:ceff:fece:3f62/64
Interface Type Other
Interface Slave Type None
protodown: off
sharpd@eva:/work/home/sharpd/frr1$ sudo vtysh -c "show ip route"
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp13s0, 00:00:08
K>* 169.254.0.0/16 [0/1000] is directly connected, virbr2 linkdown, 00:00:08
L>* 192.168.44.1/32 is directly connected, dummy2, 00:00:08
L>* 192.168.55.1/32 is directly connected, dummy1, 00:00:08
C>* 192.168.56.0/24 is directly connected, dummy1, 00:00:08
L>* 192.168.56.1/32 is directly connected, dummy1, 00:00:08
L>* 192.168.119.205/32 is directly connected, enp13s0, 00:00:08
sharpd@eva:/work/home/sharpd/frr1$ ip route show
default via 192.168.119.1 dev enp13s0 proto dhcp metric 100
169.254.0.0/16 dev virbr2 scope link metric 1000 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.45.0/24 dev virbr2 proto kernel scope link src 192.168.45.1 linkdown
192.168.56.0/24 dev dummy1 proto kernel scope link src 192.168.56.1
192.168.119.0/24 dev enp13s0 proto kernel scope link src 192.168.119.205 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
sharpd@eva:/work/home/sharpd/frr1$ ip route show table 255
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 172.17.0.1 dev docker0 proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
local 192.168.44.1 dev dummy2 proto kernel scope host src 192.168.44.1
broadcast 192.168.44.255 dev dummy2 proto kernel scope link src 192.168.44.1
local 192.168.45.1 dev virbr2 proto kernel scope host src 192.168.45.1
broadcast 192.168.45.255 dev virbr2 proto kernel scope link src 192.168.45.1 linkdown
local 192.168.55.1 dev dummy1 proto kernel scope host src 192.168.55.1
broadcast 192.168.55.255 dev dummy1 proto kernel scope link src 192.168.55.1
local 192.168.56.1 dev dummy1 proto kernel scope host src 192.168.56.1
broadcast 192.168.56.255 dev dummy1 proto kernel scope link src 192.168.56.1
local 192.168.119.205 dev enp13s0 proto kernel scope host src 192.168.119.205
broadcast 192.168.119.255 dev enp13s0 proto kernel scope link src 192.168.119.205
local 192.168.122.1 dev virbr0 proto kernel scope host src 192.168.122.1
broadcast 192.168.122.255 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Fixes: #14952
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Replace `struct list *` with `DLIST(if_connected, ...)`.
NB: while converting this, I found multiple places using connected
prefixes assuming they were IPv4 without checking:
- vrrpd/vrrp.c: vrrp_socket()
- zebra/irdp_interface.c: irdp_get_prefix(), irdp_if_start(),
irdp_advert_off()
(these fixes are really hard to split off into separate commits as that
would require going back and reapplying the change but with the old list
handling)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replace several switch blocks that contain every dplane opcode
with simpler sets of if()s. In these cases the code only
uses a couple of opcodes.
Signed-off-by: Mark Stapp <mjs@labn.net>
...so that multiple functions can be subscribed.
The create/destroy hooks are renamed to real/unreal because that's what
they *actually* signal.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently when one interface changes its VRF, zebra will send these messages to
all daemons in *order*:
1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF )
2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF )
3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF )
When daemons deal with `VRF_UPDATE`, they use
`zebra_interface_vrf_update_read()->if_lookup_by_name()`
to check the interface exist or not in old VRF. This check will always return
*NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't
find this interface in old VRF.
Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough,
they will deal with RB tree, so don't send this `VRF_UPDATE` message when
vrf changes.
Since all daemons have good mechanism to deal with changing vrf, and don't
use this `VRF_UPDATE` mechanism. So, it is safe to completely remove
all the code with `VRF_UPDATE`.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Add the txqlen attribute to the common interface struct. Capture
the value in zebra, and distribute it through the interface lib
module's zapi messaging.
Signed-off-by: Mark Stapp <mjs@labn.net>
The code that handles the protodown_rc setting for
VRRP interfaces in zebra is sending a interface
to be set into a protodown state *before* the
interface has been learned by the kernel. Resulting
in crashes when the data plane sends the ctx back
to us saying hey man you are uncool.
Additionally change the protodown code to refuse
to send any protodown_rc codes *until* the interface
has actually been learned about from the kernel.
Ticket: 3582375
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Upon some internal testing some crashes were found. This fixes
the several crashes and normalizes the code to be closer in
it's execution pre and post changes to use the data plane.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The yang NB API does not handle the mpls configuration
on its leaf.
Add an mpls leaf to stick to the mpls configuration.
- true or false to mean if config
- not defined, means no config.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The 'no mpls' command wrongly assumes the user wants to disable
the mpls handling on the interface whereas this is just a config
knob that should mean 'I don't care with mpls'.
Fix this by adding a 'disable' option to the mpls command.
Fixes: 39ffa8e8e8 ("zebra: Add a `mpls enable` interface node command")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Currently the vrf change procedure for the deleted interface is after
its deletion, it causes problem for upper daemons.
Here is the problem of `bgp`:
After deletion of one **irrelevant** interface in the same vrf, its
`ifindex` is set to 0. And then, the vrf change procedure will send
"ZEBRA_INTERFACE_DOWN" to `bgpd`.
Normally, `bgp_nht_ifp_table_handle()` should igore this message for
no correlation. However, it wrongly matched `ifindex` of 0, and removed
the related routes for the down `bnc`.
Adjust the location of the vrf change procedure to fix this issue.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
The mpls configuration does not work when an interface is
created after having applied the frr configuration. The
below scenario illustrates:
> root@dut:~# modprobe mpls
> root@dut:~# zebra &
> [..]
> dut(config)# interface ifacenotcreated
> dut(config-if)# mpls enable
> dut(config-if)# Ctrl-D
> root@dut:~# ip li show ifacenotcreated
> Device "ifacenotcreated" does not exist.
> root@dut:~# ip li add ifacenotcreated type dummy
> 0
Fix this by forcing the mpls flag when the interface is detected.
> root@dut:~# cat /proc/sys/net/mpls/conf/ifacenotcreat/input
> 1
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
a) Move the reads of link and address information
into the dplane
b) Move the startup read of data into the dplane
as well.
c) Break up startup reading of the linux kernel data
into multiple phases. As that we have implied ordering
of data that must be read first and if the dplane has
taken over some data reading then we must delay initial
read-in of other data.
Fixes: #13288
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1) Add a bunch of get/set functions and associated data
structure in zebra_dplane to allow the setting and retrieval
of interface netlink data up into the master pthread.
2) Add a bit of code to breakup startup into stages. This is
because FRR currently has a mix of dplane and non dplane interactions
and the code needs to be paused before continuing on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
On removal, ensure that the ifp->node is set to a null
pointer so that FRR does not use data after freed.
In addition ensure that the ifp->node exists before
attempting to free it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. No any configuration in FRR, and `ip link add vrf1 type vrf ...`.
Currently, everything is ok.
2. `ip link del vrf1`.
`zebra` will wrongly/redundantly notify clients to add "vrf1" as a normal
interface after correct deletion of "vrf1".
```
ZEBRA: [KMXEB-K771Y] netlink_parse_info: netlink-listen (NS 0) type RTM_DELLINK(17), len=588, seq=0, pid=0
ZEBRA: [TDJW2-B9KJW] RTM_DELLINK for vrf1(93) <- Wrongly as normal interface, not vrf
ZEBRA: [WEEJX-M4HA0] interface vrf1 vrf vrf1(93) index 93 is now inactive.
ZEBRA: [NXAHW-290AC] MESSAGE: ZEBRA_INTERFACE_DELETE vrf1 vrf vrf1(93)
ZEBRA: [H97XA-ABB3A] MESSAGE: ZEBRA_INTERFACE_VRF_UPDATE/DEL vrf1 VRF Id 93 -> 0
ZEBRA: [HP8PZ-7D6D2] MESSAGE: ZEBRA_INTERFACE_VRF_UPDATE/ADD vrf1 VRF Id 93 -> 0 <-
ZEBRA: [Y6R2N-EF2N4] interface vrf1 is being deleted from the system
ZEBRA: [KNFMR-AFZ53] RTM_DELLINK for VRF vrf1(93)
ZEBRA: [P0CZ5-RF5FH] VRF vrf1 id 93 is now inactive
ZEBRA: [XC3P3-1DG4D] MESSAGE: ZEBRA_VRF_DELETE vrf1
ZEBRA: [ZMS2F-6K837] VRF vrf1 id 4294967295 deleted
OSPF: [JKWE3-97M3J] Zebra: interface add vrf1 vrf default[0] index 0 flags 480 metric 0 mtu 65575 speed 0 <- Wrongly add interface
```
`if_handle_vrf_change()` moved the interface from specific vrf to default
vrf. But it doesn't skip interface of vrf type. So, the wrong/redundant
add operation is done.
Note, the wrong add operation is regarded as an normal interface because
the `ifp->status` is cleared too early, so it is without VRF flag
( `ZEBRA_INTERFACE_VRF_LOOPBACK` ). Now, ospfd will initialize `ifp->type`
to `OSPF_IFTYPE_BROADCAST`.
3. `ip link add vrf1 type vrf ...`, add "vrf1" again. FRR will be with
wrong display:
```
interface vrf1
ip ospf network broadcast
exit
```
Here, zebra will send `ZEBRA_INTERFACE_ADD` again for "vrf1" with
correct `ifp->status`, so it will be updated into vrf type. But
it can't update `ifp->type` from `OSPF_IFTYPE_BROADCAST` to
`OSPF_IFTYPE_LOOPBACK` because it had been already configured in above
step 2.
Two changes to fix it:
1. Skip the procedure of switching VRF for interfaces of vrf type.
It means, don't send `ZEBRA_INTERFACE_ADD` to clients when deleting vrf.
2. Put the deletion of this flag at the last.
It means, clients should get correct `ifp->status`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Create VRF and interfaces:
ip netns add vrf1
ip link add veth1 index 100 type veth
ip link add link veth1 veth1.200 type vlan id 200
ip link set veth1.200 netns vrf1
ip -n vrf1 link add veth2 index 100 type veth
After reloading zebra, "show interface veth1.200" shows wrong parent
interface:
test# show interface veth1.200
Interface veth1.200 is down
...
Parent interface: veth2
This is because veth1.200 and veth1 are in different netns, and veth2
happens to have the same ifindex as veth1, in the same netns of
veth1.200.
When looking for parent, link-ifindex 100 should be looked up within
link-netns, rather than that of the child interface.
Add link_nsid to zebra interface, so that the <link_nsid, link_ifindex>
pair can uniquely identify the link interface.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
This patch addresses following issues,
- When the VLAN-VNI mapping is configured via a map and not using
individual VXLAN interfaces, upon removal of a VNI ensure that the
remote FDB entries are uninstalled correctly.
- When VNI configuration is performed using VLAN-VNI mapping (i.e., without
individual VXLAN interfaces) and flooded traffic is handled via multicast,
the multicast group corresponding to the VNI needs to be explicitly read
from the bridge FDB. This is relevant in the case of netlink interface to
the kernel and for the scenario where a new VNI is provisioned or comes up.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
This patch addresses following bug fixes
- Fix vtysh doc string in "show evpn access-vlan..." command
- Multicast group handling was little complex. This change avoids calling
multiple functions and directly calls the zebra_vxlan_if_update_vni for
mcast group updates.
- When a vlan-vni map is removed, the removed vni deletion was happening
in FRR with SVD config. This was resulting in stale vni and not
resulting propagation of the vni deletion.
During vni cleanup (zebra_vxlan_if_vni_clean) zebra_vxlan_if_vni_del
was called for vni delete which is not correct. We should be calling
zebra_vxlan_if_vni_entry_del for the given vni entry.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
Today to find the vni for a given (vlan, bridge) we walk over all interfaces
and filter the vxlan device associated with the bridge. With multiple vlan aware
bridge changes, we can derive the vni directly by looking up the hash table i.e.
the vlan_table of the associated (vlan, bridge) which would give the vni.
During vrf_terminate() call zebra_l2_bridge_if_cleanup if the interface
that we are removing is of type bridge. In this case, we walk over all
the vlan<->access_bd association and clean them up.
zebra_evpn_t is modified to record (vlan, bridge) details and the
corresponding vty is modified to print the same.
zevpn_bridge_if_set and zl3vni_bridge_if_set is used to set/unset the
association.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
This change set introduces data structure changes required for multiple vlan aware bridge
functionality. A new structure zebra_l2_bridge_if encapsulates the vlan to access_bd
association of the bridge. A vlan_table hash_table is used to record each instance
of the vlan to access_bd of the bridge via zebra_l2_bridge_vlan structure.
vxlan iftype derivation: netlink attribute IFLA_VXLAN_COLLECT_METADATA is used
to derive the iftype of the vxlan device. If the attribute is present, then the
vxlan interface is treated as single vxlan device, otherwise it would default to
traditional vxlan device.
zebra_vxlan_check_readd_vtep, zebra_vxlan_dp_network_mac_add/del is modified to
be vni aware.
mac_fdb_read_for_bridge - is modified to be (vlan, bridge) aware
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
This changeset introduces the data structure changes needed for
single vxlan device functionality. A new struct zebra_vxlan_vni_info
encodes the iftype and vni information for vxlan device.
The change addresses related access changes of the new data structure
fields from different files
zebra_vty is modified to take care of the vni dump information according
to the new vni data structure for vxlan devices.
Signed-off-by: Sharath Ramamurthy <sramamurthy@nvidia.com>
Add the support of Extended Admin-Group (RFC7308) to the zebra interface
link-params Traffic-Engineering context.
Extended admin-groups can be configured with the affinity-map:
> affinity-map blue bit-position 221
> int eth-rt1
> link-params
> affinity blue
> exit-link-params
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Don't attempt to dereference `ifp` directly if it might be null: there
is a check right before this usage: `ifp ? ifp->info : NULL`.
In this context it should be safe to assume `ifp` is not NULL because
the only caller of this function checks that for this `ifindex`. For
consistency we'll check for null anyway in case this ever changes (and
with this the coverity scan warning gets silenced).
Found by Coverity Scan (CID 1519776)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
If we enable MPLS for an interface via sysctl, we should write `mpls enable`,
not `mpls`.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This allows Zebra to manage QDISC, TCLASS, TFILTER in kernel and do cleaning
jobs when it starts up.
Signed-off-by: Siger Yang <siger.yang@outlook.com>
Rather than running selected source files through the preprocessor and a
bunch of perl regex'ing to get the list of all DEFUNs, use the data
collected in frr.xref.
This not only eliminates issues we've been having with preprocessor
failures due to nonexistent header files, but is also much faster.
Where extract.pl would take 5s, this now finishes in 0.2s. And since
this is a non-parallelizable build step towards the end of the build
(dependent on a lot of other things being done already), the speedup is
actually noticeable.
Also files containing CLI no longer need to be listed in `vtysh_scan`
since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL`
checks are equally obsolete.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
A given interface has no enabled link-params context. If a link-params
configuration command fails, the link-params is wrongly enabled:
> r4(config-link-params)# no enable
> r4(config-link-params)# delay
> (0-16777215) Average delay in micro-second as decimal (0...16777215)
> r4(config-link-params)# delay 50 min 300 max 500
> Average delay should be comprise between Min (300) and Max (500) delay
> r4(config-link-params)# do sh run zebra
> (...)
> interface eth-rt1
> link-params
> enable
> exit-link-params
link-params are enabled if and only if the interface structure has a
valid link_params pointer. Before checking the command validity,
if_link_params_get() is called to retrieve the link-params pointer.
However, this function initializes the pointer if it is NULL.
Only use if_link_params_get() to retrieve the pointer to avoid
confusion. In command setting functions, initialize the link_params
pointer if needed only after the validation of the command.
Fixes: 16f1b9e ("Update Traffic Engineering Support for OSPFD")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This commit implements necessary netlink encoders for traffic control
including QDISC, TCLASS and TFILTER, and adds basic dplane operations.
Co-authored-by: Stephen Worley <sworley@nvidia.com>
Signed-off-by: Siger Yang <siger.yang@outlook.com>
When moving an interface between vrf's we do not need
to install the connected routes multiple times.
eva# show ip route vrf all
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF BLUE:
C>* 4.5.6.7/32 is directly connected, dummy7, 00:00:10
VRF default:
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:00:10
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:00:10
eva# exit
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link add GREEN type vrf table 11000
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set GREEN up
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set dummy7 master GREEN
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> vtysh
Hello, this is FRRouting (version 8.4-dev).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
eva# show ip route vrf all
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF GREEN:
C>* 4.5.6.7/32 is directly connected, dummy7, 00:00:05
VRF default:
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:01:03
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:01:03
eva# exit
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo ip link set dummy7 nomaster
sharpd@eva ~/f/t/topotests (multiple_connected_installs)> sudo vtysh -c "show ip route vrf all"
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
VRF default:
K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:03:22
C>* 4.5.6.7/32 is directly connected, dummy7, 00:00:08
C>* 192.168.119.0/24 is directly connected, enp39s0, 00:03:22
sharpd@eva ~/f/t/topotests (multiple_connected_installs)>
@ 11 0:-* 5h50m 0.06 24x1.9GHz 31.4G26% 426G70% 2022-08-08 13:49:24
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently when FRR starts up it queries the kernel to see if mpls is turned on.
If not FRR does not enable zebra's mpls subsection. If at a later time mpls
is turned on, let's notice that an interface now is enabled for mpls( thus
implying that all the bits and bobs in the kernel are now setup properly ).
a) convert mpls_enabled to a bool
b) abstract a new function zebra_mpls_turned_on and call it
when FRR notices that an interface now has mpls enabled.
c) mpls_processq_init cannot fail, so actually notice that
and don't have special code to detect a failure.
New results:
sharpd@eva ~> vtysh -c "show zebra"
OS Linux(5.10.0-12-amd64)
ECMP Maximum 128
v4 Forwarding On
v6 Forwarding On
MPLS Off
EVPN Off
Kernel socket buffer size 90000000
VRF l3mdev Available
ASIC offload Unavailable
RA Compiled in
RFC 5549 BGP is not using
Kernel NHG Available
v4 All LinkDown Routes Off
v4 Default LinkDown Routes Off
v6 All LinkDown Routes Off
v6 Default LinkDown Routes Off
v4 All MC Forwarding On
v4 Default MC Forwarding Off
v6 All MC Forwarding On
v6 Default MC Forwarding Off
Route Route Neighbor LSP LSP
VRF Installs Removals Updates Installs Removals
default 26 7 0 0 0
<turn on mpls_iptunnel and mpls_router modules in the kernel and then do this>:
sharpd@eva ~> sudo sysctl -w net.mpls.conf.enp39s0.input=1
[sudo] password for sharpd:
net.mpls.conf.enp39s0.input = 1
sharpd@eva ~> vtysh -c "show zebra"
OS Linux(5.10.0-12-amd64)
ECMP Maximum 128
v4 Forwarding On
v6 Forwarding On
MPLS On
EVPN Off
Kernel socket buffer size 90000000
VRF l3mdev Available
ASIC offload Unavailable
RA Compiled in
RFC 5549 BGP is not using
Kernel NHG Available
v4 All LinkDown Routes Off
v4 Default LinkDown Routes Off
v6 All LinkDown Routes Off
v6 Default LinkDown Routes Off
v4 All MC Forwarding On
v4 Default MC Forwarding Off
v6 All MC Forwarding On
v6 Default MC Forwarding Off
Route Route Neighbor LSP LSP
VRF Installs Removals Updates Installs Removals
default 26 7 0 0 0
sharpd@eva ~>
I am doing this work because FRR keeps having operators not know about how
to properly use mpls. Let's make FRR behave a bit better in this weird edge
case.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There are 2 defines IF_ZEBRA_MULTICAST_X and
IF_ZEBRA_SHUTDOWN_X macros that do the same
thing. Combine into one.
Future commits will use the IF_ZEBRA_DATA_X macro
as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The rib_process_dplane_results function was having each
sub function handler process the results and then
free the ctx. Lot's of functionality that needs to remember
to free the context. Let's just free it in the main loop.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add the ability for the netconf dplane code to handle
the global NETCONFA_IFINDEX_DEFAULT and NETCONF_IFINDEX_ALL
values. Then store our interested values when we get
them from the kernel as well as being able to display
them to the end operator.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When Zebra receives the netconf update an afi is passed
let's seperate that out and track the v4/v6 specific data
to save and store appropriately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The mc_forwarding status for an interface was being sent but not
properly retrieved on the zebra master side of the dplane.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently the code is marking the nhg as uninstalled but not
causing that to flood up to the dependent nhgs:
nhg 3 is a group of 1/2
1 -> interface A
2 -> interface B
Suppose A goes down, old code would mark nhg 1 as !VALID and !INSTALLED.
Suppose B then goes down, old code would mark nhg 2 as !VALID and !INSTALLED
But would not mark nhg 3 as !VALID and !INSTALLED (sort of assuming that
it would just be cleaned up by NHG refcounts ). I would prefer that
the code is pedantic about nhg 3 actually being removed from the system.
This code moves the setting of !INSTALLED into zebra_nhg.c where it
really belongs.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Consolidate on linux to using the netlink api for gathering all data
about a interface. Leave this interface alone in the meantime for
other OS's.
This also has the side effect of reducing the amount of work
being done on linux in that FRR was handling shut/no shut
events 2 times. Once for the ioctl question asked and
once for the netlink message received.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Move a few things into places they actually belong, and reduce the
number of places we have `#ifdev HAVE_RTADV`. Just overall code
prettification.
... I had actually done this quite a while ago while doing some other
random hacking and thought it more useful to not be sitting on it on my
disk...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
RFC 7471 Section 4.2.7:
It is possible for min delay and max delay to be the same value.
Prior to this change, the code required min < avg < max. This
change allows min == avg and avg == max.
test case:
interface eth-rt1
link-params
delay 8000 min 8000 max 8000
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
In the FreeBSD code if you delete the interface
and it has no configuration, the ifp pointer will
be deleted from the system *but* zebra continues
to dereference the just freed pointer.
==58624== Invalid read of size 1
==58624== at 0x48539F3: strlcpy (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==58624== by 0x2B0565: ifreq_set_name (ioctl.c:48)
==58624== by 0x2B0565: if_get_flags (ioctl.c:416)
==58624== by 0x2B2D9E: ifan_read (kernel_socket.c:455)
==58624== by 0x2B2D9E: kernel_read (kernel_socket.c:1403)
==58624== by 0x499F46E: thread_call (thread.c:2002)
==58624== by 0x495D2B7: frr_run (libfrr.c:1196)
==58624== by 0x2B40B8: main (main.c:471)
==58624== Address 0x6baa7f0 is 64 bytes inside a block of size 432 free'd
==58624== at 0x484ECDC: free (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==58624== by 0x4953A64: if_delete (if.c:283)
==58624== by 0x2A93C1: if_delete_update (interface.c:874)
==58624== by 0x2B2DF3: ifan_read (kernel_socket.c:453)
==58624== by 0x2B2DF3: kernel_read (kernel_socket.c:1403)
==58624== by 0x499F46E: thread_call (thread.c:2002)
==58624== by 0x495D2B7: frr_run (libfrr.c:1196)
==58624== by 0x2B40B8: main (main.c:471)
==58624== Block was alloc'd at
==58624== at 0x4851381: calloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==58624== by 0x496A022: qcalloc (memory.c:116)
==58624== by 0x49546BC: if_new (if.c:164)
==58624== by 0x49546BC: if_create_name (if.c:218)
==58624== by 0x49546BC: if_get_by_name (if.c:603)
==58624== by 0x2B1295: ifm_read (kernel_socket.c:628)
==58624== by 0x2A7FB6: interface_list (if_sysctl.c:129)
==58624== by 0x2E99C8: zebra_ns_enable (zebra_ns.c:127)
==58624== by 0x2E99C8: zebra_ns_init (zebra_ns.c:214)
==58624== by 0x2B3FF2: main (main.c:401)
==58624==
Zebra needs to pass back whether or not the ifp pointer
was freed when if_delete_update is called and it should
then check in ifan_read as well as ifm_read that the
ifp pointer is still valid for use.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Use the SET/UNSET/CHECK/COND macros for flag bifields
where appropriate throught the protodown code base.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Simplify the code for printing the reason codes via
show command. Just remove the trailing comma last
before printing.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Cleanup the logs in the api for setting protodown on/off
that zapi and others use. Make them more useful to a user parsing
them after an issue.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Extern the api for setting the protodown reason code
bitfield directly. Some places may want to completely update the
bitfield with more than one reason at a time.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Only clear protodown reason on shutdown/sweep, retain protodown
state.
This is to retain traditional and expected behavior with daemons
like vrrpd setting protodown. They expet it to be set on shutdown
and retained on bring up to prevent traffic from being dropped.
We must cleanup our reason code though to prevent us from blocking
others.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add functionality to clear any reason code set on shutdown
of zebra when we are freeing the interface, in case a bad
client didn't tell us to clear it when the shutdown.
Also, in case of a crash or failure to do the above, clear reason
on startup if it is set.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add enums for set/unset of prodown state to handle the mainthread
knowing an update is already queued without actually marking it
as complete.
This is to make the logic confirm a bit more with other parts of the code
where we queue dplane updates and not update our internal structs until
success callback is received.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add support for setting the protodown reason code.
829eb208e8
These patches handle all our netlink code for setting the reason.
For protodown reason we only set `frr` as the reason externally
but internally we have more descriptive reasoning available via
`show interface IFNAME`. The kernel only provides a bitwidth of 32
that all userspace programs have to share so this makes the most sense.
Since this is new functionality, it needs to be added to the dplane
pthread instead. So these patches, also move the protodown setting we
were doing before into the dplane pthread. For this, we abstract it a
bit more to make it a general interface LINK update dplane API. This
API can be expanded to support gernal link creation/updating when/if
someone ever adds that code.
We also move a more common entrypoint for evpn-mh and from zapi clients
like vrrpd. They both call common code now to set our internal flags
for protodown and protodown reason.
Also add debugging code for dumping netlink packets with
protodown/protodown_reason.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
When an interface goes down, it signals any related NHGs to
re-validate themselves. During zebra shutdown, ensure we remove
any NHGs we've installed.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
With recent changes to interface up mechanics in if_netlink.c
FRR was receiving as many as 4 up events for an interface
on ifdown/ifup events. This was causing timing issues
in FRR based upon some fun timings. Remove this from
happening.
Ticket: CM-31623
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There exists some interface types that are slow on startup
to fully register their link speed. Especially those that
are working with an asic backend. The speed_update timer
associated with each interface would keep trying if the
system returned a MAX_UINT32 as the speed. This speed
means both unknown or there is none under linux.
Since some interface types are slow on startup let's modify
FRR to try for at most 4 minutes and give up trying on those
interfaces where we never get any useful data.
Why 4 minutes? I wanted to balance the time associated with
slow interfaces coming up with those that will never give us
a value. So I choose 4 minutes as a good ballpark of time
to keep trying
Why not track all those interfaces and just not attempt to
do the speed lookup? I would prefer to not keep track of these
as that I do not know all the interface types, nor do I wish
to keep programming as new ones come in.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Use the dataplane to query and read interface NETCONF data;
add netconf-oriented data to the dplane context object, and
add accessors for it. Add handler for incoming update
processing.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
RA packets are pretty chatty and when there is a warning from
a missconfiguration on the network, the log file gets filed
up with warnings. Modify the code in rtadv.c to only spit
out the warning in these cases at most every 6 hours.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
VRF name should not be printed in the config since 574445ec. The update
was done for NB config output but I missed it for regular vty output.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Add a thread_ignore_late_timer(struct thread *thread) function
that allows thread.c to ignore when timers are late to the party.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
