| Age | Commit message (Collapse) | Author |
|---|
|
Changed negating set metric route-map command to be usable in
conjunction with the affirming command.
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
|
|
The "set metric" command wasn't processing metric additions and
subtractions (using + and -) correctly. Fix those problems.
Also, remove the "+metric" and "-metric" options since they don't
work and don't make any sense (they could be interpreted as unitary
increments/decrements but that was never supported).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
Add the missing route map doc string for call command.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
|
Time to rerun
|
|
The `no call` cli was not accepting the original CLI as
a quick cut-n-paste. This fixes that.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
When using the default CLI mode, the northbound layer needs to create
a separate transaction to process each YANG-modeled command since
they are supposed to be applied immediately (there's no candidate
configuration nor the "commit" command like in the transactional
CLI). The problem is that configuration transactions have an overhead
associated to them, in big part because of the use of some heavy
libyang functions like `lyd_validate()` and `lyd_diff()`. As of
now this overhead is substantial and doesn't scale well when large
numbers of transactions need to be performed in sequence.
As an example, loading 50k prefix-lists using a single transaction
takes about 2 seconds on a modern CPU. Loading the same 50k
prefix-lists using 50k transactions can take more than an hour
to complete (which is unacceptable by any standard). To fix this
problem, some heavy optimization work needs to be done on libyang and
on the FRR northbound itself too (e.g. perform partial configuration
diffs whenever possible). This, however, should be a long term
effort since these optimizations shouldn't be trivial to implement
and we're far from having the performance numbers we need.
In the meanwhile, this commit introduces a simple but efficient
workaround to alleviate the issue. In short, a new back-off timer
was introduced in the CLI to monitor and detect when too many
YANG-modeled commands are being received at the same time. When
a certain threshold is reached (100 YANG-modeled commands within
one second), the northbound starts to group all subsequent commands
into a single large transaction, which allows them to be processed
much faster (e.g. seconds and not hours). It's essentially a
protection mechanism that creates dynamically-sized transactions
when necessary to prevent performance issues from happening. This
mechanism is enabled both when parsing configuration files and when
reading commands from a terminal.
The downside of this optimization is that, if several YANG-modeled
commands are grouped into the same transaction and at least one of
them fails, the whole transaction is rejected. This is undesirable
since users don't expect transactional behavior when that's not
enabled explicitly. To minimize this issue, the CLI will log all
commands that were rejected whenever that happens, to make the
user aware of what happened and have enough information to fix
the problem. Commands that fail due to parsing errors or CLI-level
validations in general are rejected separately.
Again, this proposed workaround is intended to be temporary. The
goal is to provided a quick fix to issues like #6658 while we work
on better long-term solutions.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
DEFPY_YANG will allow the CLI to identify which commands are
YANG-modeled or not before executing them. This is going to be
useful for the upcoming configuration back-off timer work that
needs to commit pending configuration changes before executing a
command that isn't YANG-modeled.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
|
|
Merge the cisco style access list with zebra's logic so we can mix both
types of rules while keeping the commands.
With this the cisco style limitation of having 'destination-*' only for
specific number ranges no longer exist for users of YANG/northbound (the
CLI still has this limitation).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
|
And again for the name. Why on earth would we centralize this, just so
people can forget to update it?
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
Same as before, instead of shoving this into a big central list we can
just put the parent node in cmd_node.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
There is really no reason to not put this in the cmd_node.
And while we're add it, rename from pointless ".func" to ".config_write".
[v2: fix forgotten ldpd config_write]
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
The only nodes that have this as 0 don't have a "->func" anyway, so the
entire thing is really just pointless.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
... and use named assignments everywhere (so I can change the struct.)
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
Adapt the zebra route map code to use the transaction CLI output (e.g.
the CLI show callbacks) instead of the fallback compatibility.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
|
vtysh should handle going back up one level to try the command, there is
no need to be able to recurse inside route-map.
This also fixes a problem with northbound hitting the XPath queue limit
of 8 nodes.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
|
Allow old CLI users to still print their configuration without migrating
to northbound.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
|
Use the northbound back-end instead of the old route map CLI.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
|
