Check for value present in list before removing
as in certain python3 ValueError traceback is observed.
Traceback (most recent call last):
File "/usr/lib/frr/frr-reload.py",
line 2278, in <module>
(lines_to_add, lines_to_del, restart_frr)
= compare_context_objects(newconf, running)
File "/usr/lib/frr/frr-reload.py",
line 1933, in compare_context_objects
lines_to_add, lines_to_del
File "/usr/lib/frr/frr-reload.py",
line 1549, in ignore_delete_re_add_lines
lines_to_del.remove((ctx_keys, line))
ValueError: list.remove(x): x not in list
Ticket:#3389979
Issue:3389979
Testing Done:
With fix perform frr-relaod on frr.conf config where earlier
traceback was seen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Got `ERROR: Daemon babeld is not a valid option for 'show running-config'` when using `frr-reload.py --reload --daemon babeld`.
Adds `babeld` and `nhrpd` as valid daemons.
Signed-off-by: Yuxiang Zhu <vfreex@gmail.com>
agentx can't be disabled once enabled, so we should ignore it for frr-reload.py.
```
$ /usr/lib/frr/frr-reload.py --reload /etc/frr/bgpd.conf --bindir /usr/local/bin
"no agentx" we failed to remove this command
SNMP AgentX support cannot be disabled once enabled
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If we add/modify community/large/ext lists without sequence numbers, and
doing frr-reload.py, then rules with sequence numbers (show running-config
always adds sequence numbers) will be deleted and new ones will be re-added.
This could lead to blackholing for some time.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
At the moment we set /var/log/frr permissions to 0750 (frr:frr), but the log
file is 0640 (root:adm) (unless logrotated) and that doesn't allow adm group
to even open the directory.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There are singline-line commands inside `router bgp` that start with
`vnc ` or `bmp `. Those commands are currently treated as node-entering
commands. We need to specify such commands more precisely.
Fixes#10548.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
frr-reload triggers restart of service in case
it fails to parse new config file and conjunction with
running config contains 'router bgp' (default bgp instnace).
When frr-reload fails to parse new config file, it fails
to build newconfig context (empty object).
Instead of bailing out it compares against the running config
context. If the running config contains default bgp instance
it thinks new config is removing default bgp instance so it
triggers frr restart.
Fix is to to bail out reload script when it fails to parse
config file.
Ticket:#2861989
Reviewed By: MR-83
Testing Done:
router bgp 102 vrf RED
bgp router-id 2.2.2.2
neighbor underlay peer-group
neighbor underlay remote-as <---- Partial config
Before fix:
2021-12-02 02:43:16,987 ERROR: vtysh failed to process new
configuration: vtysh (mark file) exited with status 4:
b'line 79: % Command incomplete: neighbor underlay remote-as\n\n'
2021-12-02 02:43:17,145 INFO: Loading Config object from vtysh show
running
2021-12-02 02:43:17,362 INFO: "frr version 7.5+cl5.0.0u0" cannot be
removed
2021-12-02 02:43:17,362 INFO: "frr defaults datacenter" cannot be
removed
2021-12-02 02:43:17,362 INFO: "service integrated-vtysh-config" cannot
be removed
2021-12-02 02:43:17,363 INFO: "line vty" cannot be removed
2021-12-02 02:43:17,522 INFO: EVPN is enabled and default instance del
needed
2021-12-02 02:43:17,522 INFO: Restarting FRR <---- Restart frr
After fix:
Just throw Error and abort the script.
root@TORS1:mgmt:/home/cumulus# /usr/lib/frr/frr-reload.py --debug
--reload --stdout /etc/frr/frr.conf
2021-12-02 04:00:56,519 INFO: Called via "Namespace(bindir='/usr/bin',
confdir='/etc/frr', daemon='', debug=True, filename='/etc/frr/$
rr.conf', input=None, overwrite=False, pathspace=None, reload=True,
rundir='/var/run/frr', stdout=True, test=False, vty_socket=None)"
2021-12-02 04:00:56,520 INFO: Loading Config object from file
/etc/frr/frr.conf
2021-12-02 04:00:56,679 ERROR: vtysh failed to process new
configuration: vtysh (mark file) exited with status 4:
b'line 79: % Command incomplete: neighbor underlay remote-as\n\n'
root@TORS1:mgmt:/home/cumulus#
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Remove neighbor <> remote-as <> config line,
if the neighbor is part of the peer-group and
peer-group contains remote-as config.
Neighbors which are part of the peer-group
cannot override remote-as.
Fix:
Frr-reload needs to remote 'neighbor <> remote-as <>'
from lines_to_add if its already part of peer-group
and peer-group has remote-as config.
Testing Done:
Before:
Config snippet:
neighbor PEERS peer-group
neighbor PEERS remote-as external
neighbor PEERS timers 3 9
neighbor 10.2.1.1 remote-as external
neighbor 10.2.1.1 peer-group PEERS
neighbor 10.2.1.1 timers 3 9
neighbor 10.2.1.2 remote-as external
neighbor 10.2.1.2 peer-group PEERS
Frr-reload failure:
line 179: Failure to communicate[13] to bgpd, line: neighbor 10.2.1.1
remote-as external
% Peer-group member cannot override remote-as of peer-group
line 179: Failure to communicate[13] to bgpd, line: neighbor 10.2.1.2
remote-as external
% Peer-group member cannot override remote-as of peer-group
After:
frr-reload apply the config successfully.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Calling get_contexts() can't display as expected, it wrongly displays:
<__main__.Context object at 0x7fdee1d5ad50>
So make it display correct data by add __str__ in Context class.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Currently, in frr-reload we:
- store a list of single-line context keywords which needs to be
frequently updated,
- have a separate "if" clause for every node and subnode we have in FRR.
Instead, we can store the tree of all known FRR nodes. This tree needs
to be updated whenever we add a new node, which is not frequent. And,
most importantly, it allows us to write node-agnostic code and save more
than 250 LOC.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
- Remove incorrect requirement for `service integrated-vtysh-config`
when producing a delta.
- Add `--test-reset` option which suppresses non-parseable lines from the
produced delta
- Use new features in common_config.py
Signed-off-by: Christian Hopps <chopps@labn.net>
When using frr-reload.py to modify a bgp neighbors route-map
the code was doing this:
a) deleting the previous route-map: `no neighbor XX route-map YY (in|out)`
b) Adding the new route-map back in `neighbor XX route-may ZZ (in|out)`
Now imagine that we have an outgoing route-map that we are changing
and the reload is large because of a large number of lines in frr.conf
Item (a) will happen. BGP will immediately start sending all local
routes. At some point in time in the future (b) will be applied.
This of course causes a withdraw but for a short amount of time we
are leaking unintended routes. This is bad for several reasons
not 1) route churn upstream, 2) we might influence traffic to go the
wrong way. 3) if upstream has a maximum-prefix command the routes
being sent might trip its circuitry and shutdown the peer entirely
not even allowing you to get to (b).
Ticket: #2589685
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem reported that frr-reload.py didn't handle the mac access-list
command correctly, causing reloads to fail. This fix adds the
support for the command as a single line context.
Signed-off-by: Don Slice <dslice@nvidia.com>
All of peers and respective configs are wiped out when
pee-group is removed.
In an attempt to remove peer-group and its associated peers
configs via frr-reload fails if the peer-group is removed first.
To pass the peer-group config removal via frr-reload following
steps are taken:
Find the bgp context to which peer-group belongs.
Find the peer-group associated peer(s) and store them in a list.
Remove the peers config lines from the pending list.
Move the peer-group deletion line to end of the pending list so
any remaining peer-group associated config can be removed successfully.
The above steps take 3 iterations over the pending list and scales
linearly.
Ticket:2656351
Reviewed By:CCR-11575
Testing Done:
Broken:
config:
router bgp 5544
neighbor PG1 peer-group
neighbor PG1 remote-as external
neighbor swp10 interface peer-group PG1
neighbor swp10 timers 3 9
failed frr-reload log:
2021-05-17 22:02:42,608 INFO: Executed "router bgp 5544 no neighbor
PG1 peer-group"
2021-05-17 22:02:42,708 INFO: Failed to execute router bgp 5544 no
neighbor PG1 remote-as external
2021-05-17 22:02:42,808 INFO: Failed to execute router bgp 5544 no
neighbor PG1 remote-as
2021-05-17 22:02:42,906 INFO: Failed to execute router bgp 5544 no
neighbor PG1
2021-05-17 22:02:43,007 INFO: Failed to execute router bgp 5544 no
neighbor
2021-05-17 22:02:43,106 INFO: Failed to execute router bgp 5544 no
2021-05-17 22:02:43,106 ERROR: "router bgp 5544 -- no" we failed to
remove this command
2021-05-17 22:02:43,107 ERROR: % Create the peer-group or interface
first
With fix:
2021-05-17 22:05:27,687 INFO: Executed "router bgp 5544 no neighbor
PG1 remote-as external"
2021-05-17 22:05:27,791 INFO: Executed "router bgp 5544 no neighbor
PG1 peer-group"
Signed-off-by: Chirag Shah <chirag@nvidia.com>
frr-reload no longer consolidates ip prefix-list "le 32" or "le 128"
rules when a "ge" is present, more accurately representing existing user
config and reflecting also what is accepted in CLI.
Signed-off-by: Wesley Coakley <wcoakley@nvidia.com>
When I run frr-reload.py I am seeing this error:
Apr 21 06:23:51 eva frrinit.sh[3776992]: /usr/lib/frr/frr-reload.py:1094: SyntaxWarning: "is not" with a literal. Did you mean "!="?
Apr 21 06:23:51 eva frrinit.sh[3776992]: if line is not "exit-vrf":
fix
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
avoid issuing a [no] command if we are then issuing the affirmative
one. This avoids spurious requests for the default label ranges,
which might fail if something else is using those labels.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Problems reported that in certain cases, frr-reload.py would
delete vrf static routes inadvertantly due to two different
reasons. First, vrf statics with null0 or Null0 nexthops would
fail the match since rendered as blackholes. This was already
fixed for non-vrf statics so added for vrf-based. Second,
frr-reload would fail to match due to different formats for
adding the command. If entered in the old way
"ip route x.x.x.x/x y.y.y.y vrf NAME" and rendered
in the new sway "vrf NAME\nip route x.x.x.x/x y.y.y.y" it would
fail to match do an inadvertant delete.
Ticket: 2570270
Signed-off-by: Don Slice <dslice@nvidia.com>
Log vtysh message for a failed command.
Ticket:2556706
Reviewed By:
Testing Done:
frr reload fails to delete default bgp instance in presence of bgp vrf
instance(s), it captures vtysh message and logs in frr-reload.log
logs backend
2021-03-05 05:16:45,623 INFO: Failed to execute no router bgp 5544
2021-03-05 05:16:45,735 INFO: Failed to execute no router bgp
2021-03-05 05:16:45,846 INFO: Failed to execute no router
2021-03-05 05:16:45,846 ERROR: "no router" we failed to remove this
command
2021-03-05 05:16:45,847 ERROR: % Cannot delete default BGP instance.
Dependent VRF instances exist
Signed-off-by: Chirag Shah <chirag@nvidia.com>
if no form of the cli fails to execute, mark frr-reload
as failure so return code can be nonzero.
The similar approach is done for non no-form (add case) of the cli.
Ticket:CM-33345
Reviewed By:CCR-11287
Testing Done:
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Issue:
The rpki subcontext uses exit instead of end to exit.
This makes issues with frr-reload in the way that frr-reload never exits
rpki context until it reaches the next end statement. this also happens when
parsing the configuration from vtysh.
Fixes: #7887
Signed-off-by: Runar Borge <runar@borge.nu>
Fix the handling of multiple BFD profiles by adding the appropriated
code to push/pop contexts inside BFD configuration node.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
If frr.conf contains a prefix-list or access-list without a seq number,
frr-reload needs to be aware that it should not delete/add if the running
config contains a seq number.
Ticket: CM-32623
Signed-off-by: Don Slice <dslice@nvidia.com>
Since new workflow instructions state to run black against
python change and it found formatting changes required that
were not part of my change set, committing those changes
separately.
Signed-off-by: Don Slice <dslice@nvidia.com>
make sure that the order in which the pcep-related commands are
removed by frr-reload.py is the correct one, i.e., pce followed
by pce-config followed by pcc.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
on one hand, the default value for a peer preference was always being
displayed, and on the other there was some code in frr-reload.py which
was attempting to add a default value to match this behavior, and which
was incorrectly overriding a specified preference. Fix this by removing
this code and making pathd behave like other daemons in this respect,
i.e. not displaying the default value.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
