This makes clang-format not wreck all our hand-formatted DEFUN/DEFPY
statements. We apparently missed this option when we originally looked
at setting up the .clang-format control file...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
join_desired looks at whether up->channel_oil is empty. up->channel_oil
is updated from pim_forward_stop(), calling pim_channel_del_oif(). But
that was being called *after* updating join_desired, so join_desired saw
a non-empty OIL. Pull up the pim_forward_stop() call to before updating
join_desired.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
It looks like the code was trying to do this with the null_register
parameter on pim_upstream_start_register_stop_timer(), but that didn't
quite work right. Restructure a bit to get it right.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
libyang3-dev is required.
TODO: add redhat, snapcraft
Suggested-by: Martin Winter <mwinter@opensourcerouting.org>
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Didn't catch this one when adding the warning/error (with -Werror) for
missing this. Neither the CI nor I build with ZeroMQ enabled :(.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
- Fix memleak on multiple errstr returns (multiple clients) Allow the
- multiple clients to all return results and merge them (as with other
operations like get tree).
Signed-off-by: Christian Hopps <chopps@labn.net>
The current json display lost a lot of LSPs, added them.
Fixed the json format for two commands:
"show isis database detail json"
"show isis database json"
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The previous idea of using config xpath registrations for actions b/c
the config is the subject of the action is sub-optimal. It splits
handling of YANG "actions" (Action and RPCs) between 2 different
registartion maps for the same category of functionality.
Signed-off-by: Christian Hopps <chopps@labn.net>
Using the same address with a different prefix length is not supported.
If we configure two identical addresses with different
netmasks 192.168.1.1/30 and then 192.168.1.1/29. Zebra sends
'192.168.1.1' with a prefix length of 29. However, the function
'zebra_interface_address_read()' reads '192.168.1.1/30' because the
prefix length is not checked.
Using 'same_prefix()' is more convenient.
Signed-off-by: Loïc Sang <loic.sang@6wind.com>
When ospf6d originates an AS-external route that has been read from a kernel
routing table, then the metric of that route was ignored until now.
If a routemap is configured, then this metric will be redistributed from
now on.
Using metric increment and decrement in routemaps is supported by ospf6d now.
Signed-off-by: Alexander Rose <alexander.rose@secunet.com>
When BGP receives an SRV6_LOCATOR_ADD message from zebra, it calls the
`bgp_zebra_process_srv6_locator_add()` function to process the message.
`bgp_zebra_process_srv6_locator_add()` decodes the message first, and
then if the pointer to the default BGP instance is NULL (i.e. the
default BGP instance is not configured yet), it returns early without
doing anything and without using the decoded message information.
This commit fixes the order of the operations executed by
`bgp_zebra_process_srv6_locator_add()`. We first ensure that the default
BGP instance is ready and we return early if it is not. Then, we decode
the message and do something with the information contained in it.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
When a bgp neighbor graceful-restart config mode change
is applied, after accepting the config if it does not
take effect instead of throwing vtysh error code,
return the success to vtysh and warn the user.
The debug log is already present at critical code point
where GR failure is seen during config apply.
Ticket: #3761481
Testing Done:
root@tor-1:# vtysh -c 'config t' -c 'router bgp 65564
vrf VRF2' -c 'neighbor 20.1.1.1 graceful-restart'
As part of configuring graceful-restart, capability send to zebra failed
root@tor-1:# echo $?
0
Signed-off-by: Chirag Shah <chirag@nvidia.com>
When BGP receives a `SRV6_LOCATOR_DEL` from zebra, it invokes
`bgp_zebra_process_srv6_locator_delete` to process the message.
`bgp_zebra_process_srv6_locator_delete` obtains a pointer to the default
BGP instance and then dereferences this pointer.
If the default BGP instance is not ready / not configured yet, this
pointer this pointer is `NULL` and dereferencing it causes BGP to crash.
This commit fix the issue by adding a a check to verify if the pointer
is `NULL` and returning early if it is.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
In the context of SVD (Single VxLAN Device) for L3VNI,
the remote VTEP's nexthop is programmed neighbor entry against
SVD along with neighbor entry against SVI.
However, when L3VNI is removed or the VRF is disabled, all SVI
based remote nexthop neighbors are uninstalled and deleted.
The SVD based neigh entries remains in Zebra and the Kernel.
Subsequently, when reconfiguring L3VNI and relearning the same nexthop,
the neighbor entry is not programmed is because it is not removed
from Zebra SVD neighbor hash table, leading to the failure to
reprogram the entry.
With this fix, the SVD nexthop neigh entry is uninstalled
and deleted from Zebra and Kernel.
Ticket: #3729045
Testing:
borderleaf:# ip neigh show 2.2.2.2
2.2.2.2 dev vlan2560_l3 lladdr 00:01:00:00:1d:09 extern_learn NOARP proto zebra
2.2.2.2 dev vxlan99 lladdr 00:01:00:00:1d:09 extern_learn NOARP proto zebra
With the fix:
Zebra log shows both enties SVD (vxlan99) and SVI (vlan2560_l3)
neighbor entries are deleted.
2024/05/03 18:41:33.527125 ZEBRA: [NH6N7-54CD1] Tx RTM_DELNEIGH family
ipv4 IF vxlan99(16) Neigh 2.2.2.2 MAC null flags 0x10 state 0x0
ext_flags 0x0
2024/05/03 18:41:33.527128 ZEBRA: [NH6N7-54CD1] Tx RTM_DELNEIGH family
ipv4 IF vlan2560_l3(18) Neigh 2.2.2.2 MAC null flags 0x10 state 0x0
ext_flags 0x0
borderleaf:# ip neigh show 2.2.2.2
borderleaf:#
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Upon bridge flap, the associated SVD case,
VLAN membership is not updated correctly.
When SVI comes up, the VNI could not associate
with it as bridge VLAN membership was not updated.
Ticket: #3821632
Testing:
Before fix:
-----------
tor-1:#ifdown br_l3vni ; sleep 1 ; ifup br_l3vni
tor-1:# vtysh -c 'show evpn vni 8888'
VNI: 8888
Type: L3
Tenant VRF: sym_1
Vlan: 490
Bridge: br_l3vni
Local Vtep Ip: 27.0.0.9
Vxlan-Intf: vxlan99
SVI-If: None <<<<<< SVI not found
State: Down <<<<<< status remained in down BGP is not informed
VNI Filter: none
System MAC: None
Router MAC: None
L2 VNIs: 1800 1801 1900 1901
After fix:
----------
tor-1:# ifdown br_l3vni; sleep 1; ifup br_l3vni
tor-1:# vtysh
Hello, this is FRRouting (version 8.4.3).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
tor-1# show evpn vni 8888
VNI: 8888
Type: L3
Tenant VRF: sym_1
Vlan: 490
Bridge: br_l3vni
Local Vtep Ip: 27.0.0.9
Vxlan-Intf: vxlan99
SVI-If: vlan490_l3 <<<<<<
State: Up <<<<<<
VNI Filter: none
System MAC: 44:38:39:ff:ff:29
Router MAC: 44:38:39:ff:ff:29
L2 VNIs: 1800 1801 1900 1901
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Before:
```
anlan# show isis neighbor
Area xx:
System Id Interface L State Holdtime SNPA
0023.0000.0000 enp1s0 2 Down Expiring2c53.4a30.0820
```
After:
```
anlan# show isis neighbor
Area xx:
System Id Interface L State Holdtime SNPA
0023.0000.0000 enp1s0 2 Down Expiring 2c53.4a30.0820
```
The `-` display format caused by no hello packet in `isis_adj_print_vty()`
is same as that of above "Expiring".
Signed-off-by: anlan_cs <anlan_cs@tom.com>
