When a device is in developer mode, drop the user directly into the
shell instead of having to go via the bootmenu, since this is usually
what you want in that case. Emit a note about how to access the menu,
for the rare cases when that is needed.
The test ensures that all interface types can be successfully created
and retrieved from the operational datastore. It also functions as a
regression test for issue #618 and will apply to all future interface
variants.
Fixes#622
Refactor 0f9d429 to first check if the .cfg file has any routing
protocol active before converting the type's value.
This fixes a regression in the release cycle that otherwise would
cause a fresh startup-config, created from a plain factory-config
from v24.08, to be converted to an empty file.
Inspired by this fix, the same mitigation, albeit highyl unlikely,
has been applied to the v1.0 user shell type migration.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Verify a VETH pair can be removed after a couple of dummy operations to
step the dagger generation past the initial where the pair is created.
NOTE: Infamy currenly lacks support for removing chunks of configuraion
e.g., a dut.del_config_dict(), or similar, and delete_xpath() is
not valid for configurations with dependencies like VETH pairs.
Issue #658
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When adding interfaces over NETCONF/RESTCONF, confd has a check to
ensure the peer end is skipped, since creating one end also create
the other.
This patch adds the corresponding skip when deleting a VETH pair.
Fixes#658
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch mainly updates the static routing chapter, and adds a new
section on route preferences, but it also makes slight touch-ups at
a few other places as well.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Now that all routes acquired from DHCP (and ZeroConf) are installed in
the kernel FIB via Frr (staticd -> zebra -> kernel), instead of directly
to the kernel FIB, let's extend this test slightly.
Add a canary static route that is installed before the DHCP client is
even started. This canary route should be installed along with the
DHCP (classless) route(s) when the interface comes up and acquires a
DHCP lease.
We take this opportunity to also verify that the route-preference is
properly carried over from test to operational RIB status.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Enable OSPF route metrics in RIB, only defined for OSPF
- Enable 'active' route flag for RIB, same as 'selected >' in FRR
- Enable 'last-updated' route field for RIB, used for uptime
- Augment route in RIB with 'installed' flag, same as 'FIB *' in FRR
The CLI "show ip route" command has been updated accordingly. The
classic Cisco style output has been kept instead of separating the
routes into Active and Backup, as discussed previously. Because
when inspecting large route sets you want to compare same prefix
vs distance/metric to understand why a certain route is selected.
admin@example:/> show ip route
PREFIX PREF NEXT-HOP PROTOCOL UPTIME
> 0.0.0.0/0 1/0 192.168.0.42 static 0h2m6s
* 192.168.122.1
0.0.0.0/0 5/0 192.168.122.1 static 0h2m6s
0.0.0.0/0 254/0 e1 static 0h2m6s
>* 169.254.0.0/16 0/0 e1 direct 0h2m6s
>* 192.168.0.0/24 1/0 192.168.122.1 static 0h2m6s
>* 192.168.122.0/24 0/0 e1 direct 0h2m12s
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
For consistency with the other IETF routing models, e.g., OSPF, let's
use the same model prefix for internal references.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Not the most obvious patch, but let me explain -- there will always be a
conflict betweem usability and "maintainability". The ietf-interfaces
yang model already declares /interfaces-state as deprecated, so we don't
really need to add a deviation 'not-supported', for usability, however,
it may be useful since the deviation helps cut out that tree completely.
While working with ietf-routing and our companion models, I found that
since it relies on ietf-interfaces, it also breaks the reload/reimport
of infix-routing while developing extensions/changes:
$ lint.sh -f tree ieee802-* iana-if-type@2023-01-26.yang \
ietf-interfaces@2018-02-20.yang \
infix-interfaces@2024-01-15.yang \
ietf-routing@2018-03-13.yang \
ietf-ipv4-unicast-routing@2018-03-13.yang \
ietf-ospf@2022-10-19.yang \
infix-routing@2024-09-22.yang
libyang err : Not found node "interfaces-state" in path. (Schema location "/ietf-routing:routing-state/interfaces/interface".)
libyang err : Target of leafref "interface" cannot be referenced because it is disabled. (Schema location "/ietf-routing:routing-state/interfaces/interface".)
YANGLINT[E]: Parsing schema module "ietf-routing@2018-03-13.yang" failed.
The only way to change/update models for a given build is to either, a)
surgically remove offending models from output/target/, then reinstall
all dependencies and hope it works better, or b) rebuild from distclean.
In most cases you end up with alternative b).
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Latest YANG model change reverts back to using the IETF routing-protocol
type. Update tests to check for infix-routing:ospf -> ietf-ospf:ospfv2.
Also, refactor and extend infamy/route.py:_exist_route() slightly for
readability and PEP-8, as well as to use an optional model prefix also
for next-hop-list addresses.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Straighten out formatting issues in ospfd.conf (debug)
- Simplify and reduce code duplication
- Avoid 'restart zebra' errors in runlevel S
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch changes the way Infix DHCP and ZerocConf clients set their
routes in the system. Instead of setting them directly in the kernel
we ask FRR staticd to set them for us.
The reason for this change is to be able to override routes from these
protocols with locally set static routes. The routes are now set with
a distance of 5 and 254, respectively, while static routes by default
have a distance of 1. In contrast, kernel routes are always treated
by Frr as distance 0, i.e., they are preferred over static routes.
Finally, this patch drops the use of Linux legacy interface aliases, or
colon interfaces, in an effort to reduce confusion for end users. This
may give some odd results if using older tools like ifconfig, so we
recommend using 'show interfaces' or 'ipb a' instead.
Fixes#640
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
With the redesign of the operational rib routes, using vtysh 'show ip route'
instead of the kernel 'ip route' as source, we no longer need the infix source
protocol.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The intention is to provide a similar set of commands as klish
admin-exec. However, instead of trying to make the Linux tools
more accessible, we now make the Infix tooling more accessible.
E.g., instead of "show ip route" mapping to "ip route show", we
map it to:
sysrepocfg -f json -X -d operational -x "/ietf-routing:routing/ribs" | \
/usr/libexec/statd/cli-pretty "show-routing-table"
As a spin-off we alos get a much more readable infix.xml for klish:
- Relocate logic to shell script wrapper 'show'
- Introduce Cisco style "show ip route" and "show ipv6 route"
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Apply a distance adjustment to routes retrieved from IPv4LL/ZeroConf and
DHCP to ensure that Frr (Zebra) can compare other protocol routes, e.g.,
static. Without this Frr will consider all routes read from the kernel
to have a protocol distance of 0, meaning better than static routes that
have a distance of 1.
Initial proposal to fix issue #640
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Since /etc is not retained across reboots, the sysrepo startup datastore
is not used to bootstrap the Infix. Instead, /cfg/startup-config.cfg is
used and loaded directly to the running datastore.
For some use-cases when operating directly on sysrepo this causes a lot
of confusion because startup == factory ds until any user calls the CLI
command `copy running-config startup-confg`.
This patch fixes this initial "glitch" by loading the starup datastore
at boot on successful loading of startup-config to unning.
To prevent any unintentional "auto-save" of, e.g., failure-config to
startup-config, we make confd aware of this "sync" operation during
bootstap.
Fixes#625
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Tobias Waldekranz