After the cleanup, adding this doesn't require updating a zillion
locations in the code anymore, just one :)
Partially derived from 6a00e91d99
Originally-by: Emanuele Di Pascale <emanuele@voltanet.io>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
- throw vtysh into a wrapper class
- ignore "username" commands
- use mark output on stdout
- some other random cleanups
Signed-off-by: David Lamparter <equinox@diac24.net>
This reverts commit 3fa139a65b.
This is being reverted because this commit completely
breaks the invocation of frr-reload.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported that with certain configs, when the user
deleted a "neighbor x.x.x.x bfd 4 100 100" statement from
frr.conf and then reloaded, a traceback was seen and the
deletion did not succeed. Found that in some scenarios
it was possible to have something in lines_to_add that
was in a different context and when the re.search was
attempted, it found an empy line and was unhappy. This
fix avoids trying to search in the wrong context.
Ticket: CM-29145
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
when removing a whole address-family block from ldpd config
we were erroneously trying to also remove each of the interface
sub-sub-contexts that belonged to it; this would effectively
re-enable the AF we just removed. Work around this by ignoring
these sub-sub-contexts if we detect that we are already
removing the parent block.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Problem seen when deleting many static routes or access-lists due
to frr-reload.py issuing individual vtysh -c commands for every
line. On slow switches, this can take long enough for systemd to
time out the reload process and restart frr. This fix uses add
logic for static routes, prefix-lists, and access-lists to gang
the changes together.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-27856
These make no sense. stderr=subprocess.STDOUT means that vtysh's stdout
and stderr are combined and returned by check_output. We don't expect
errors in that, and we certainly don't log them.
Leaving vtysh's stderr as stderr is perfectly fine, it'll be captured
for logging just like stderr output from frr-reload.py.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Found that while the previous fix solved the traceback and created
the correct configuration, it was doing a delete/add process rather
than just an add. This was due to an incorrectly created search
string. This commit fixes that search string and testing verifies
that the correct thing is now being done.
Ticket: CM-27233
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem reported with tracebacks seen when making multiple bfd timer
changes in frr.conf and applying via frr-reload.py. Found that when
multiple bfd timer changes are made, the same line can be added for
deletion more than once, causing the traceback when the deletion is
performed. This fix verifies the correct line is being appended for
deletion.
Ticket: CM-27233
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
instead of suppressing the 'exit' markers at the end of each
'interface XXX' clause in the mpls ldp configuration, mark
those with a special marker 'exit-ldp-if' and teach the
reload script to correctly recognize the new sub-subcontext
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
frr-reload.py has many special case rules that did not consider ldpd
at all. Specifically:
1. The bulk of ldp configuration comes in a big 'mpls ldp' context, which was
previously considered a single-line context as it started with 'mpls'. This
rule should only apply to labels and lsps.
2. ldp has a 'router-id' config line that fell into the same rule as the above
one. It should not be considered a single-line context as more ldp
configuration can follow.
3. enabled interfaces should not end their context. A better fix
would actually require popping a new context for each interface
in case there is any interface-specific config, but at least this
fix will address the most common use case.
4. when declaring pseudowires, any line with 'member pseudowire XXX' should
be considered a sub-context of the 'l2vpn YYY type ZZZ' context. Without
this fix, changes in the first psuedowire declared would not correctly
be processed (e.g. removing a 'control-word exclude' line would not
be picked up).
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
allow frr-reload.py to be invoked with a --daemon option to specify
an individual daemon for which the configuration diff should be
computed. This is useful when integrated config is not used and we
want to apply a patch to a single daemon config file.
No attempt to integrate this with 'service frr reload' has been done.
Making watchfrr work with per-daemon config is outside the scope of
this simple patch.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
allow command line parameters to specify different folder for
the vtysh binary, config file location and temporary file.
Keep the old hardcoded paths as default values for those options
to preserve current functionality.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Add `allow-external-route-update` and `domainname` to the one line
context list, otherwise reload will fail when those commands show up in
the running configuration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Problem reported that if a bgp neighbor had a bfd timer change
made in frr.conf and systemctl reload frr performed, the neighbor
with the timer changed bounced. If the change is made in vtysh
by just adding the new timer values, no peer bounce occurs. This
fix skips the delete part of the delete/add process in frr-reload
so the peers stay up.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Discovered in testing that if a static route in the default table
was entered immediately after a vrf static block, the static route
intended for the default table was put in the vrf instead. This
fix retains the "exit-vrf" statement which causes the following
static routes to appear in the default table correctly.
Ticket: CM-23985
Signed-off-by: Don Slice <dslice@cumulusnetwork.com>
Problem caused when nclu is used to create "ip route 1.1.1.0/24
blackhole" because frr-reload.py changed the line to Null0 instead
of blackhole. If nclu tries to delete it using the same line as
entered, the commit fails since it doesn't match.
Ticket: CM-23986
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem seen when removing last config item under the vrf context,
where frr-reload.py tries instead to delete the vrf context itself.
Since that is not permitted on an active vrf, the command errors
out and nothing is deleted.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem reported that when a peer-group was added in certain
configurations, it would be rejected because of the order of the
commands put in by nclu. Issued turned out to be how frr-reload.py
was handling the sub-sub-context of the vni under the address-family
and subsequently how it handled the following exit-vni.
Ticket: CM-21996
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
There are several lines that we cannot do a "no" on
- frr version
- frr defaults
- password
- line vty
frr-reload should ignore these if asked to do a "no" on them
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
The "3.0", etc in the comments were referring to Cumulus Linux 3.0 which
was confusing now that FRR has a 3.0
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
We had multiple places checking for
if ctx_keys[0].startswith('router bgp') and line
Combine these into a single check
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Without this fix frr-reload would do a del/add even if the only
difference were bogus whitespaces.
root@cel-redxp-10[nclu]# /usr/lib/frr/frr-reload.py --test
/etc/frr/frr.conf
Lines To Delete
===============
router bgp 100
no bgp router-id 1.1.1.1
Lines To Add
============
router bgp 100
bgp router-id 1.1.1.1
root@cel-redxp-10[nclu]#
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Today if we hit an error while apply the contents of file FOO that error
does not bubble up to a non-zero exit.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
When an entire address-family section is removed from under BGP, we
cannot just issue 'no address-family foo bar' as address-family line
doesn't support 'no'. We have to delete the individual lines under the
address-family.
