If the timer is not explicitly configured for a peer, the default timer
is not taken into account and SendHoldTimer mechanism does not work at all.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Daemons like isisd continue to use the previous link-params after they
are removed from zebra.
For example,
>r0# sh run zebra
> (...)
> interface eth-rt1
> link-params
> enable
> metric 100
> exit-link-params
> r0# conf
> r0(config)# interface eth-rt1
> r0(config-if)# link-params
> r0(config-link-params)# no enable
After "no enable", "sh run zebra" displays no more link-params context.
The "no enable" causes the release of the "link_params" pointer within
the "interface" structure. The zebra function to update daemons with
a ZEBRA_INTERFACE_LINK_PARAMS zapi message is called but the function
returns without doing anything because the "link_params" pointer is
NULL. Therefore, the "link_params" pointers are kept in daemons.
When the zebra "link_params" pointer is NULL:
- Send a zapi link param message that contains no link parameters
instead of sending no message.
- At reception in daemons, the absence of link parameters causes the
release of the "link_params" pointer.
Fixes: 16f1b9e ("Update Traffic Engineering Support for OSPFD")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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>
touch + chown can have a gap between the commands (or the second failed).
This could lead to unexpected permissions (root, instead of frr) for some
.conf files or directories.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When forming a neighbor relationship on an interface, ospf is
currently evaluating unnumbered as highest priority, without
any consideration for if you have /32's and non /32's on the
interface. Effectively if I have something like this:
int foo0
ip address 192.168.119.1/24
!
router ospf
network 0.0.0.0/0 area 0
!
ospf will form a neighbor on foo0 if it exists. Now
suppose someone does this:
int foo0
ip address 192.168.120.1/32
This will create the unnumbered interface on foo0 and
the peering will come down immediately.
The problem here is that the original designers of the unnumbered
code for ospf didn't envision end operators mixing and matching
addresses on an interface like this ( for perfectly legitimate
reasons I might add ).
So if ospf has both numbered and unnumbered let's match against
the numbered first and then unnumbered. This solves the problem
Fixes: #6823
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When bgp is using `bgp suppress-fib-pending` and the end
operator is using network statements, bgp was not sending
the network'ed prefix'es to it's peers. Fix this.
Also update the test cases for bgp_suppress_fib to test
this new corner case( I am sure that there are going to
be others that will need to be added ).
Fixes: #12112
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix vni table output broken by 8304dabfab
The "Imported from" output was not getting delimitted by a newline
after the mentioned commit. This fixes that and retains the output
wanted by the original change.
Before:
'''
Route [2]:[0]:[48]:[b6:3a:cc:d5:a1:cd]:[128]:[fe80::b43a:ccff:fed5:a1cd] VNI 30/10 Imported from 2.2.2.2:4:[2]:[0]:[48]:[b6:3a:cc:d5:a1:cd]:[128]:[fe80::b43a:ccff:fed5:a1cd], VNI 30/10
2
2.2.2.2(alfred) from alfred(veth1) (2.2.2.2)
Origin IGP, valid, external, bestpath-from-AS 2, best (First path received)
Extended Community: RT:2:30 ET:8
Last update: Fri Oct 7 16:04:59 2022
'''
After:
'''
Route [2]:[0]:[48]:[b2:cf:96:70:4f:b6]:[128]:[fe80::b0cf:96ff:fe70:4fb6] VNI 30/10
Imported from 2.2.2.2:4:[2]:[0]:[48]:[b2:cf:96:70:4f:b6]:[128]:[fe80::b0cf:96ff:fe70:4fb6], VNI 30/10
2
2.2.2.2(alfred) from alfred(veth1) (2.2.2.2)
Origin IGP, valid, external, bestpath-from-AS 2, best (First path received)
Extended Community: RT:2:30 ET:8
Last update: Fri Oct 7 17:02:28 2022
'''
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Add new `show bgp vni ...` command to docs. This command
is used to show the per-VNI EVPN tables in BGP.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Both install_evpn_route_entry_in_vni_mac() and
install_evpn_route_entry_in_vni_ip() will unlock the bgp_dest when
install_evpn_route_entry_in_vni_common() returns, so there's no need to
unlock the bgp_dest inside the _common function. Let's let the new
wrappers handle the cleanup of the dest.
Ticket: #3119673
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
