| Age | Commit message (Collapse) | Author |
|---|
|
The line `pbr table range ...` does not start a new context so treat it
like a single-line context
Signed-off-by: Wesley Coakley <w@wesleycoakley.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>
|
|
Signed-off-by: Donald Sharp <sharpd@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>
|
|
Since black is finding issues before applying my change, committing
those changes separately
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>
|
|
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
|
|
fpm: frr-reload, IPv6 and an improvement
|
|
This new dynamic module makes pathd behave as a PCC for dynamic candidate path
using the external library pcpelib https://github.com/volta-networks/pceplib .
The candidate paths defined as dynamic will trigger computation requests to the
configured PCE, and the PCE response will be used to update the policy.
It supports multiple PCE. The one with smaller precedence will be elected
as the master PCE, and only if the connection repeatedly fails, the PCC will
switch to another PCE.
Example of configuration:
segment-routing
traffic-eng
pcep
pce-config CONF
source-address ip 10.10.10.10
sr-draft07
!
pce PCE1
config CONF
address ip 1.1.1.1
!
pce PCE2
config CONF
address ip 2.2.2.2
!
pcc
peer PCE1 precedence 10
peer PCE2 precedence 20
!
!
!
!
Co-authored-by: Brady Johnson <brady@voltanet.io>
Co-authored-by: Emanuele Di Pascale <emanuele@voltanet.io>
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Co-authored-by: Javier Garcia <javier.garcia@voltanet.io>
Co-authored-by: Renato Westphal <renato@opensourcerouting.org>
Co-authored-by: Sebastien Merle <sebastien@netdef.org>
Signed-off-by: Sebastien Merle <sebastien@netdef.org>
|
|
This new daemon manages Segment-Routing Traffic-Engineering
(SR-TE) Policies and installs them into zebra. It provides
the usual yang support and vtysh commands to define or change
SR-TE Policies.
In a nutshell SR-TE Policies provide the possibility to steer
traffic through a (possibly dynamic) list of Segment Routing
segments to the endpoint of the policy. This list of segments
is part of a Candidate Path which again belongs to the SR-TE
Policy. SR-TE Policies are uniquely identified by their color
and endpoint. The color can be used to e.g. match BGP
communities on incoming traffic.
There can be multiple Candidate Paths for a single
policy, the active Candidate Path is chosen according to
certain conditions of which the most important is its
preference. Candidate Paths can be explicit (fixed list of
segments) or dynamic (list of segment comes from e.g. PCEP, see
below).
Configuration example:
segment-routing
traffic-eng
segment-list SL
index 10 mpls label 1111
index 20 mpls label 2222
!
policy color 4 endpoint 10.10.10.4
name POL4
binding-sid 104
candidate-path preference 100 name exp explicit segment-list SL
candidate-path preference 200 name dyn dynamic
!
!
!
There is an important connection between dynamic Candidate
Paths and the overall topic of Path Computation. Later on for
pathd a dynamic module will be introduced that is capable
of communicating via the PCEP protocol with a PCE (Path
Computation Element) which again is capable of calculating
paths according to its local TED (Traffic Engineering Database).
This dynamic module will be able to inject the mentioned
dynamic Candidate Paths into pathd based on calculated paths
from a PCE.
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-06
Co-authored-by: Sebastien Merle <sebastien@netdef.org>
Co-authored-by: Renato Westphal <renato@opensourcerouting.org>
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Co-authored-by: Emanuele Di Pascale <emanuele@voltanet.io>
Signed-off-by: Sebastien Merle <sebastien@netdef.org>
|
|
frr reload fixes for mac and ip normalization
|
|
Instruct `frr-reload.py` to not use `fpm` commands as configuration
node.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
|
MAC address can be configured as lower/upper hex characters but is
always rendered as lower case in "show run". Avoid incorrect "change
detection" by ignoring case.
Ticket: CM-32235
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
|
|
The condition to normalize ipv6 addresses was accidentally broken via -
[
e238920df07be0b61e483f0a58e0b99ab3d2e0ea tools: Fix reload with 'ipv6 address...' in interface
]
The condition was supposed to be skipped only if "ipv6 add" was present
in the line.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
|
|
when deleting a whole l2vpn context in ldpd which also had pseudowires
in it, we were first deleting the l2vpn with a 'no l2vpn XXX' command,
and then adding it again by running 'l2vpn XXX\n no member pseudowire YYY'
which obviously was not needed. As a result the l2vpn would be reinstated.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
|
|
We are now using black.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
|
|
Based on the current code, I think the intent was to gracefully handle
vtysh failures and print a useful error message. Barriers in the way of
that:
- Despite reading the results of subprocess.communicate(), there won't
be anything there, because we aren't passing subprocess.PIPE as stdin
and stderr when calling subprocess.Popen()
- Despite catching subprocess.TimeoutExpired, if we were to actually hit
this case frr-reload.py would just crash because it's calling
.communicate() on an unbound process variable, probably a copy-paste
error
- Aside from that, building a kwargs dict to pass to a function that
contains something if something else is not None and nothing if it is,
is pointless when we could just pass the thing itself
Net result is that if vtysh fails to read an frr.conf due to syntax
errors, instead of crashing with a traceback, we actually handle the
error condition, log the problem and vtysh's output, and exit. Actually
we were printing the failed line just by chance because stderr wasn't
captured from the subprocess and I guess showed up as part of systemd's
error capturing or something, but the traceback did a good job of
obscuring that with useless noise.
Old:
frrinit.sh[32183]: * Started watchfrr
frrinit.sh[32183]: line 20: % Unknown command: eee
frrinit.sh[32183]: Traceback (most recent call last):
frrinit.sh[32183]: File "/usr/lib/frr/frr-reload.py", line 1316, in <module>
frrinit.sh[32183]: newconf.load_from_file(args.filename)
frrinit.sh[32183]: File "/usr/lib/frr/frr-reload.py", line 231, in load_from_file
frrinit.sh[32183]: file_output = self.vtysh.mark_file(filename)
frrinit.sh[32183]: File "/usr/lib/frr/frr-reload.py", line 146, in mark_file
frrinit.sh[32183]: % (child.returncode, stderr))
frrinit.sh[32183]: __main__.VtyshException: vtysh (mark file) exited with status 2:
frrinit.sh[32183]: None
New:
frrinit.sh[30090]: * Started watchfrr
frrinit.sh[30090]: vtysh failed to process new configuration: vtysh (mark file) exited with status 2:
frrinit.sh[30090]: line 20: % Unknown command: eee
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
|
|
When you add a key chain in the RIP configuration file and reload the
configurations via the frr-reload.py script, the script will fail and
the key chain will not appear in the running configuration. The reason
is that frr-reload.py doesn't recognize key as a sub-context.
Before this change, keys were generated this way:
key chain test
key 2
key-string 123
key 3
key-string 456
With this change, keys will be generated this way:
key chain test
key 2
key-string 123
exit
key 3
key-string 456
exit
This will allow frr-reload.py to see the key sub-context and correctly
reload them.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
|
|
tools: frr-reload: more detailed log level control
|
|
watchfrr: add `-N` and `--netns` options
|
|
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
Reported that in certain config changes, a static intended for the
default table would be duplicated into a vrf context. Determined
that we still weren't keeping or adding the exit-vrf command when
necessary to keep the contexts straight. Added logic to look for
the failing circumstances and add or remove the delete of the
exit-vrf command as needed.
Signed-off-by: Don Slice <dslice@nvidia.com>
|
|
In several instances a call to log.error() is preceded by a print()
for the same message. To prevent duplicate messages these print()
calls are removed.
To maintain (very) similar behaviour we add a StreamHandler to the
logger, when doing logging to a file (ie. --reload without --stdout),
which additionally sends error and above logs to STDOUT without any
metadata (exactly as they did before, with print()).
There is one subtle change - the log from Vtysh.is_config_available()
is now preceded with the "vtysh 'configure' returned" text, whereas
previously only the output from vtysh was sent to STDOUT.
Furthermore any error logs which weren't previously explicitly logged
to STDOUT will now be.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
|
|
Add a "--log-level" option to frr-reload to set the maximum message
level to be logged. When the option is not used, the level is set to
info as before.
The existing --debug option is synonymous with --log-level=debug and
these options are therefore mutually exclusive.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
|
|
add lines starting with 'peer' to the list of sub-contexts that are handled by frr-reload.py.
https://github.com/FRRouting/frr/issues/6511#issuecomment-655163833
Signed-off-by: Paul Manley <paul.manley@wholefoods.com>
|
|
When you have this configuration:
int foo
ipv6 address fd01:0:0:1::1/64
And issue a reload statement, FRR-reload
is reducing the code to a
`no ipv6 address fd01:0:0:1::/64`
and then issuing a:
`ipv6 address fd01:0:0:1::/64`
The end result is of course that the foo
interface now has two v6 addresses on it.
The brilliance of this is of course if you
happen to have two systems that are connected
over an interface, and you issue a reload command.
They both get fd01:0:0:1::/64 as an ipv6 address
and DAD detection kicks in and stomps on your stuff.
Put a special hey don't munch the v6 address line
in a reload situation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
tools: 'evpn mh' is a new one-line context
|
|
frr-reload.py needs to know about config-level commands, otherwise it
assumes they are contexts
Ticket: CM-30128
Ticket: CM-30077
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
|
the refactored frr-reload.py is adding 'no-header' to the
'show running' command of vtysh, but if a daemon is specified
the no-header option should only be added after the daemon name.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
|
|
After the cleanup, adding this doesn't require updating a zillion
locations in the code anymore, just one :)
Partially derived from 6a00e91d99f7f98d857c2056d0dcfeba48966581
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 3fa139a65be70e5a81b5f078530094f09a247416.
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>
|
|
Fixes and extensions to frr_reload.py
|
|
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>
|
