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>
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>
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 -
[
e238920df0 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>
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>
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>
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>
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 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.
Ticket: CM-14600
Reviewed By: CCR-5615
Testing Done: Verifying the issue with/without the fix
I had intended the regexp to catch both ip and ipv6 routes, but somewhere
along the way, I left out the grouping in the regexp to catch if it was
ip or ipv6 at the start. This caused all the rest of the matches and replaces
to be off causing the issue reported by the bug.
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-14351
Reviewed By: dwalton
Testing Done:attempts to run NCLU test failed, Daniel verified.
Uninit variable bug, plus missed adding ValueError to the except
clauses in a couple of places.
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-14280, CM-14281, CM-14286
Reviewed By: CCR-5546
Testing Done: quagga_service_test, bgp_enhe, bgp_vrf etc.
If the user specifies a network statement such as "network 1.1.1.1/24",
the running config shows this as "network 1.1.1.0/24" which causes
unnecessary withdrawl of the prefix and re-advertisement causing
perturbations. The same thing applies to prefix-lists and of course, IPv6
addresses.
IPv6 addresses were being normalized already, and so we use that same
function to handle the IPv6 portion of the issue. Interestingly community
strings were also getting ensnared in the normalized IPv6 function due to
the presence of ':', but thats OK.
quagga's running config changes 'null0' and 'blackhole' keywords into 'Null0'.
For example: ip route 10.1.1.0/24 blackhole' is displayed as
'ip route 10.1.1.0/24 Null0'. Reload mistakes this and issues a delete of the
Null0 route followed by an add of the "blackhole" route. Unnecessary, and
results in unexpected routing perturabations.
Also fix prefix-list's le/ge behavior: It always prints ge first even if the
user has specified le followed by ge, and it doesn't print l3 32/128 if ge
is also specified, else it prints them.
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-14260
Reviewed By: CCR-14260
Testing Done: quagga reload tests (quagga_service, bgp_enhe etc.)
Quagga reload handles deletes of entire context by issuing a "no.." on the
entire context itself instead of deleting each individual line of the context.
However, this doesn't work when the context is "interface" since its not
allowed to do "no interface <ifname>" inside quagga. So special case this by
deleting each individual line of the context.
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-14259
Reviewed By: CCR-5527
Testing Done:
If users specify "ip prefix-list FOO permit 1.2.3.4/24", running config
displays that line as "ip prefix-list FOO seq 5 permit 1.2.3.4/24", which
causes reload to delete the running config line and add back the one in
the config.
This patch fixes that.
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-14059
Reviewed By: CCR-5524
Testing Done: the usual
At some point in the 3.x release cycle, it was decided to overwrite the
user's Quagga.conf configuration file with the output of running config
when the user did a quagga reload. This is problematic for several reasons
such as: losing user-specified comments, upsetting network automation
scripts which think some thing has changed all the time from the specified
config etc.
This patch fixes this issue by not overwriting the Quagga.conf file unless
the user specifies it via an additional option, or the file being used as
input to quagga reload isn't the default configuration file (incl. path).
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
Ticket: CM-14060
Reviewed By:
Testing Done:
There are two harmful problems (cause routing changes in the network) with the
2.5.x style config:
one with the old style specification of "multipath as-relax", and
the other with ip import-table, used by redistribute neighbor
In 2.5, we had the user specify 'no-as-set' as the suffix to
'bgp bestpath as-path multipath relax' to avoid quagga's default behavior
which'd cause weird routing problems. However, in 3.x, we made 'no-as-set' as
the default, and so its neither required to specify it nor is it shown in the
running config. This means when we do quagga reload, we remove the multipath
as-relax line and add it back with the no-as-set line. This causes all BGP
sessions to be reset.
The problem with the "ip import-table" is that it causes us to unimport the
routes and then add it back again, causing routing prefix changes throughout
the network, potentially causing blackholing of traffic.
This fix addresses both these issues and avoids the unnecessary routing blips.
Signed-off-by: Dinesh Dutt <ddutt@cumulusnetworks.com>
