Repository navigation
network: Use loopback0 for the routed dummy interface - #1114
Merged
Merged
Conversation
✅
|
| Descriptor | Linter | Files | Fixed | Errors | Max errors | Warnings | Elapsed time |
|---|---|---|---|---|---|---|---|
| ✅ ACTION | actionlint | 5 | 0 | 0 | 0.05s | ||
| ✅ JSON | jsonlint | 4 | 0 | 0 | 0.1s | ||
| ✅ JSON | prettier | 4 | 0 | 0 | 0.36s | ||
| ✅ JSON | v8r | 4 | 0 | 0 | 7.12s | ||
| ✅ MARKDOWN | markdownlint | 180 | 0 | 0 | 2.78s | ||
| ✅ MARKDOWN | markdown-table-formatter | 180 | 0 | 0 | 0.37s | ||
| ✅ REPOSITORY | betterleaks | yes | no | no | 0.59s | ||
| ✅ REPOSITORY | checkov | yes | no | no | 15.7s | ||
| ✅ REPOSITORY | git_diff | yes | no | no | 0.06s | ||
| ✅ REPOSITORY | secretlint | yes | no | no | 1.05s | ||
| ✅ REPOSITORY | trufflehog | yes | no | no | 2.97s | ||
| ✅ SPELL | codespell | 190 | 0 | 0 | 0.55s | ||
| lychee | 190 | 4 | 0 | 51.42s | |||
| ✅ YAML | prettier | 6 | 0 | 0 | 0.4s | ||
| ✅ YAML | v8r | 6 | 0 | 0 | 5.91s | ||
| ✅ YAML | yamllint | 6 | 0 | 0 | 0.55s |
Detailed Issues
⚠️ SPELL / lychee - 4 errors
📝 Summary
---------------------
🔍 Total.........1215
🔗 Unique.........908
✅ Successful....1107
⏳ Timeouts.........0
🔀 Redirected.......9
👻 Excluded.......104
❓ Unknown..........0
🚫 Errors...........4
⛔ Unsupported......4
Errors in .claude/skills/security-advisory/SKILL.md
[400] https://cveawg.mitre.org/api/cve/ (at 16:18) | Rejected status code: 400 Bad Request
[404] https://raw.githubusercontent.com/osism/ (at 17:18) | Rejected status code: 404 Not Found
[400] https://registry.osism.tech/service/token (at 18:19) | Rejected status code: 400 Bad Request
Errors in docs/release-notes/osism-7.md
[ERROR] https://www.openstack.org/software/openstack-bobcat (at 978:38) | Connection failed. Check network connectivity and firewall settings
Hint: Followed 9 redirects. You might want to consider replacing redirecting URLs with the resolved URLs. Use verbose mode (`-v`/`-vv`) to see redirection details.
See detailed reports in MegaLinter artifacts
Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)
- Documentation: Custom Flavors
- Command:
npx mega-linter-runner@10.1.0 --custom-flavor-setup --custom-flavor-linters ACTION_ACTIONLINT,JSON_JSONLINT,JSON_V8R,JSON_PRETTIER,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_BETTERLEAKS,REPOSITORY_SECRETLINT,REPOSITORY_TRUFFLEHOG,SPELL_LYCHEE,SPELL_CODESPELL,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R

Show us your support by starring ⭐ the repository
The configuration guide's IPv6 fabric underlay example creates a dummy0 device, puts the host's addresses on it and points internal_interface at it, relying on the frr role's dummy0 default for the BGP announcements. OSISM is moving away from the dummy0 name: the rest of OSISM uses loopback0 for this interface (osism/defaults, the netplan generated from NetBox, the cluster network concept page), and new deployments should not be set up with the legacy name. Name the device loopback0 throughout the example, and set frr_loopback_interface: loopback0 in its frr part. The frr role defaults to dummy0, so without that line the renamed example would announce none of the host's addresses. Setting it explicitly keeps the example correct whatever the role's default is. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
The dummy interface section said only how dummy devices are created, with dummy0 as the example name. It did not say what such a device is for in a routed network, or why its name matters. Explain that in a BGP-to-the-host network each node's own addresses sit on a dummy interface named loopback0, which FRR announces and OSISM's defaults use as network_interface and, without internal_interface, for the console, hosts and management interfaces. Say to use loopback0 rather than the legacy dummy0, and to set frr_loopback_interface: loopback0 as well, because FRR announces the addresses of the interface that variable names and the frr role has defaulted to dummy0. Rename the section's example device to loopback0 accordingly. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
The dummy interface section documented only network_dummy_interfaces, which creates dummy devices with systemd.netdev and leaves their addresses to network_ethernets. It did not mention network_dummy_devices, although that is what the network role renders into Netplan's dummy-devices section on Ubuntu 24.04 and later (templates/netplan/01-osism.yaml.j2) and what the inventory reconciler generates for loopback0 when the network comes from NetBox. network_dummy_devices is the newer of the two: the network role added it in 2024 (ansible-collection-commons #692), the inventory reconciler moved from network_dummy_interfaces to it in 2025 (container-image-inventory-reconciler #361) and builds its VRF dummy interfaces on it, and the deploy guide requires Ubuntu 24.04 on the nodes. Document network_dummy_devices, with the device's addresses, as the way to define dummy devices. Describe network_dummy_interfaces as the older form that existing configurations use, which still works and is needed on hosts older than Ubuntu 24.04, where dummy-devices is not rendered. Say that network_dummy_interface_mtu applies to those devices only. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
The IPv6 fabric underlay example creates loopback0 with network_dummy_interfaces and puts its addresses in network_ethernets, while the dummy interface section now recommends network_dummy_devices on Ubuntu 24.04 and later, the form the inventory reconciler generates from NetBox. Define loopback0 and its addresses in network_dummy_devices instead, so the page shows one consistent form. The device no longer gets network_dummy_interface_mtu (9000) and keeps the kernel default. That does not limit traffic to or from its addresses, which is routed through the uplinks and uses their MTU. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
ideaship
force-pushed
the
frr-loopback0
branch
from
October 20, 2026 10:36
24a8454 to
95e0673
Compare
ideaship
marked this pull request as ready for review
October 20, 2026 10:52
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The network configuration guide used
dummy0for the dummy interface that carries a node's own addresses in a routed network, and relied on the frr role'sdummy0default for the BGP announcements. OSISM is moving away from thedummy0name: the rest of OSISM usesloopback0, and new deployments should not be set up with the legacy name.Four commits, each standing on its own:
internal_interfacebecomeloopback0. The example also setsfrr_loopback_interface: loopback0; without it, the renamed example would announce none of the host's addresses while the frr role defaults todummy0.loopback0rather thandummy0, and thatfrr_loopback_interfaceshould name it.dummy-deviceson Ubuntu 24.04 and later, and what the inventory reconciler generates from NetBox.network_dummy_interfaces(systemd.netdev) is described as the older form that existing configurations use; it still works and is needed before Ubuntu 24.04.network_dummy_interface_mtu. That doesn't limit traffic to or from its addresses, which is routed through the uplinks and uses their MTU (checked with a loopback0 MTU of 1280 and 1328-byte packets in both directions).Because the example sets
frr_loopback_interfaceexplicitly, it is correct whatever the frr role's default is. Changing that default toloopback0is proposed separately; this change does not depend on it:🤖 Generated with Claude Code