The normal flag was enabling detail messages, but what we want is the
detail flag enabling normal messages.
Remove the _ONLY macro while at it, it's only used for config print &
that seems like a place where making the difference explicitly visible
is helpful regardless.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
If duplicate value is entered, the whole plist/alist just dropped.
Before:
```
$ grep prefix-list /etc/frr/frr.conf
ip prefix-list test seq 5 permit 1.1.1.1/32
ip prefix-list test seq 10 permit 1.1.1.1/32
$ systemctl restart frr
$ vtysh -c 'show run | include prefix-list'
$
```
After:
```
$ grep prefix-list /etc/frr/frr.conf
ip prefix-list test seq 5 permit 1.1.1.1/32
ip prefix-list test seq 10 permit 1.1.1.1/32
$ systemctl restart frr
$ vtysh -c 'show run | include prefix-list'
ip prefix-list test seq 5 permit 1.1.1.1/32
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Some recent improvement in GCC triggers 2 new warnings, and they're
actual bugs (reading beyond end of prefix_ipv6 by accessing it as
prefix, which is larger.) Luckily it's only in sharpd.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Prior to this fix, the magic number (16) was used regardless of what value
the user specified for func-bits. With this fix, user-specified values are
handled appropriately.
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
RT value will be unique across different VNIs but the
same across routers (in the same AS) for a particula
VNI.
It is unique, so add `break` for search procedure.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Modifying the "mld_group_watermark_cmd" to "ipv6_mld_group_watermark_cmd"
and "igmp_group_watermark_cmd" to "ip_igmp_group_watermark_cmd" for consistency.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Fix: 06e4e90132
Modified BGP to pay more attention the prefix returned from
zebra to ensure that a LPM wasn't accidently causing BGP
import checks to think it had a match when it did not.
This unfortunately removed the check to handle the route
removal.
This sequence of config and events would leave BGP in a bad state:
ip route 100.100.100.0/24 Null0
router bgp 32932
bgp network import-check
address-family ipv4 uni
network 100.100.100.0/24
Then if you removed the static route the import check would
still think the route existed:
donatas-pc(config)# ip route 100.100.100.0/24 Null0
donatas-pc(config)# do sh ip bgp import-check-table
Current BGP import check cache:
100.100.100.0 valid [IGP metric 0], #paths 1
blackhole
Last update: Sat Apr 23 22:51:34 2022
donatas-pc(config)# do sh ip nht
100.100.100.0
resolved via static
is directly connected, Null0
Client list: bgp(fd 17)
donatas-pc(config)# do sh ip bgp neighbors 192.168.10.123 advertised-routes | include 100.100.100.0
*> 100.100.100.0/24 0.0.0.0 0 32768 i
donatas-pc(config)# no ip route 100.100.100.0/24 Null0
donatas-pc(config)# do sh ip nht
100.100.100.0
resolved via kernel
via 192.168.10.1, enp3s0
Client list: bgp(fd 17)
donatas-pc(config)# do sh ip bgp import-check-table
Current BGP import check cache:
100.100.100.0 valid [IGP metric 0], #paths 1
blackhole
Last update: Sat Apr 23 22:51:34 2022
donatas-pc(config)# do sh ip bgp neighbors 192.168.10.123 advertised-routes | include 100.100.100.0
*> 100.100.100.0/24 0.0.0.0 0 32768 i
donatas-pc(config)#
Fix this by moving the code to handle the prefix check to the
evaluation function and mark the bnc as not matching and actually
evaluate the bnc.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Other VRFs get VRF_ADD notifications from zebra which triggers
static_fixup_vrf_ids, but since the default VRF is implicit we need to
make that same call on connect.
This should fix problems with staticd being started before (or
concurrent with and thus racing) zebra.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
nh_update is only called in two places and both precede a matching
follow-up nht_register call. Fold the update into register, and make
register do the right thing™ for all cases (i.e. update refcounts as
needed, and retry zebra NHT registration if it failed before).
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Since this is a free()-type function, clear the caller's pointer to
NULL to aid static analysis and prevent UAF bugs.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Put static_nexthop -> prefix code into a small helper, remove extra
prefix variable, and grab AFI from prefix.
This commit should not result in any functional change.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
With the simple BFD configuration -
(active mode, single hop, without other parameters)
```
!
bfd
peer 11.11.11.11
exit
!
```
The interface with 11.11.11.0/24 is a *virtual* interface,
which can be deleted.
After BFD FSM is created and session is ok, do these things:
1) delete this interface
2) create this interface
3) set same ip address in this interface
Now, everything seems completely restored because all configuration
is same. But bad thing happens, BFD session hang on "down" status -
```
root# show bfd peer 11.11.11.11
BFD Peer:
peer 11.11.11.11 vrf default
ID: 638815827
Remote ID: 0
Active mode
Status: down
Downtime: 3 second(s)
Diagnostics: path down <- caused by destroyed interface
Remote diagnostics: ok
```
With the interface creating, `bfdd_sessions_enable_interface()`
wrongly compares added interface with the created, even key of
this `bfd_session` isn't binded with any interface. So this
`bfd_session` will hang on "down" status for ever.
So skip the compare in this case (no interface in key) to wake up
this `bfd_session`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
When a bgp neighbor removed from associated to peer-group,
the neighbor is fully deleted, subsequent deletion of any
configuration related to the neighbor leads to failure
in frr-reload.
Fix: In frr-reload lines to delete check if any neighbor with
peer-group removal line is present, if so then remove any
further config deletion associated the neighbor needs to removed
from the lines to delete.
Ticket:#3032234
Reviewed By:
Testing Done:
BEFORE FIX:
-----------
2022-04-08 20:03:32,734 INFO: Executed "router bgp 4200000005 no neighbor swp5 interface peer-group UNDERLAY"
2022-04-08 20:03:32,892 INFO: Failed to execute router bgp 4200000005 no neighbor swp5 password SSSS
2022-04-08 20:03:33,050 INFO: Failed to execute router bgp 4200000005 no neighbor swp5 password
2022-04-08 20:03:33,218 INFO: Failed to execute router bgp 4200000005 no neighbor swp5
2022-04-08 20:03:33,354 INFO: Failed to execute router bgp 4200000005 no neighbor
2022-04-08 20:03:33,520 INFO: Failed to execute router bgp 4200000005 no
2022-04-08 20:03:33,521 ERROR: "router bgp 4200000005 -- no" we failed to remove this command
2022-04-08 20:03:33,521 ERROR: % Specify remote-as or peer-group commands first
2022-04-08 20:03:33,691 INFO: Failed to execute router bgp 4200000005 no neighbor swp5 advertisement-interval 0
2022-04-08 20:03:33,853 INFO: Failed to execute router bgp 4200000005 no neighbor swp5 advertisement-interval
2022-04-08 20:03:34,015 INFO: Failed to execute router bgp 4200000005 no neighbor swp5
2022-04-08 20:03:34,145 INFO: Failed to execute router bgp 4200000005 no neighbor
2022-04-08 20:03:34,326 INFO: Failed to execute router bgp 4200000005 no
2022-04-08 20:03:34,327 ERROR: "router bgp 4200000005 -- no" we failed to remove this command
2022-04-08 20:03:34,327 ERROR: % Specify remote-as or peer-group commands first
AFTER FIX:
----------
delete of numbered neighbor:
2022-04-08 19:52:17,204 INFO: Executed "router bgp 4200000005 no
neighbor 1.2.3.4 peer-group UNDERLAY"
2022-04-08 19:52:17,205 INFO: /var/run/frr/reload-GRFX1M.txt content
delete of unnumbered neighbor:
2022-04-08 20:00:02,952 INFO: Executed "router bgp 4200000005 no
neighbor swp5 interface peer-group UNDERLAY"
2022-04-08 20:00:02,953 INFO: /var/run/frr/reload-722C3P.txt content
Signed-off-by: Chirag Shah <chirag@nvidia.com>
BGPd does not allow default instance deletion
in presence of bgp vrf instance;
frr-reload script fails if delete list contains
default instance followed by vrf instance.
Fix:
frr-reload scans lines_to_delete to look for
'router bgp' and 'router bgp vrf ...' line.
If both are present switch the order to delete
bgp vrf instance(s) than default instance at the end.
Testing Done:
Before:
INFO: Loading Config object from file /etc/frr/frr.conf
INFO: Loading Config object from vtysh show running
INFO: Failed to execute no router bgp 40201 <-- Failed to delete
INFO: Failed to execute no router bgp
INFO: Failed to execute no router
ERROR: "no router" we failed to remove this command
ERROR: % Cannot delete default BGP instance. Dependent VRF instances exist
INFO: Executed "no router bgp 40201 vrf bgp-test" <-- vrf instance deleted
INFO: Loading Config object from vtysh show running
After:
order of deletion switched
INFO: Loading Config object from file /etc/frr/frr.conf
INFO: Loading Config object from vtysh show running
INFO: Executed "no router bgp 40201 vrf bgp-test"
INFO: Executed "no router bgp 40201"
INFO: Loading Config object from vtysh show running
Signed-off-by: Chirag Shah <chirag@nvidia.com>
VRRP as per RFC 5798 'Master Advertisement interval' field refers to the
advertisement interval, we received the last time we got an Advertisement
from a peer who wasn't us, who was in the master state.
This could be clarified by making the field name 'Master Advertisement
interval (rx)',and when we're in the Master state, we put (stale) after the interval.
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
That commit aim is to fix an invalid isis access to sptree when
lpd is stopping. isisd is running.
lpd and isisd are running. isis is L1 type configured.
isis_ldp_rlfa_handle_client_close function try to clear
uninitialized spftree.
Expected behavior: isisd not crashing and running.
isis_ldp_rlfa_handle_client_close not trying to clear spftree
that are not initializes due tio the configuration.
Fix: test the configured area's type avoiding to deleted
an unconfigured sptree. function isis_rlfa_handle_client_close
will be aligned on spftree_area_del function
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
End operator is showing:
!
frr version 8.0.1
frr defaults traditional
hostname test.example.com
domainname
domainname should not be printed in this case at all. I do not
see any mechanism in current code that this could happen, but
what do I know? Put some extra stupid insurance in place
to prevent bad config from being generated.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
5421bf8 commit forgot to set the parameter "new" to true
when a new source is created, have fixed it.
igmp_get_source_by_addr api is currently setting the parameter
"new" to false always. This is not right. The caller apis are using
this field to decide and based on that take actions to create timers, etc.
Its need to be set to true when a new source is created.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
watchfrr and staticd do not require <1024 ports to be running, thus they can
start, but others fail.
We should allow only users with EUID=0 (sudo or root) running frrinit.sh.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In addition to turning on isis bfd debugging traces, the internal
bfd messaging debug is also enabled. Reversely, when isis bfd traces
are off, the internal messaging debug traces are off too.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
