Joachim Wiberg 7fa141178f cli: layered show interface, IEEE 802.3.2-2025 ethernet model
Import ieee802-ethernet-interface@2025-09-10.yang, from IEEE 802.3.2-2025,
and companion ieee802-ethernet-phy-type.yang, replacing the 2019 revision.
Operational interface speed moves to ietf-interfaces:speed, RFC 8343,
eth:speed is now obsolete.  Bump infix-interfaces.yang revision to track
the upgrade.

The CLI 'show interface' command renders interfaces as bottom-up layered
protocol rows.  Ethernet interfaces a new IEEE link-mode row (1000baseT,
10GbaseLR, ...) is added with 'duplex: full|half' in the DATA column.
Without link the ethernet row is the first row.  Tunnels and wifi follow
the same layering: gre/vxlan rows carry remote:/vni: tokens with optional
ethernet sub-row for the L2-bearing variants; wifi rows carry 'station' or
'access-point' ssid:, signal:, stations: tokens.

admin@bpi-76-8f-c2:/> show interface
⚑ INTERFACE   PROTOCOL      STATE       DATA
⇅ lo          loopback      UP
              ipv4                      127.0.0.1/8 (static)
              ipv6                      ::1/128 (static)
⇅ br0         bridge        DOWN
  │           ethernet                  32:2e:3f:76:8f:c2
  │           ipv4                      192.168.0.1/24 (static)
⇅ ├ lan0      bridge        LOWER-DOWN
⇅ ├ lan1      bridge        LOWER-DOWN
⇅ ├ lan2      bridge        LOWER-DOWN
⇅ └ lan3      bridge        LOWER-DOWN
⇅ gre0        gre           UP          remote: 198.51.100.7
              ipv4                      10.255.0.1/30 (static)
⇅ sfp1        ethernet      DOWN        ca:59:f0:77:80:5b
⇅ wan         1000baseT     UP          duplex: full
              ethernet                  32:2e:3f:76:8f:c2
              ipv4                      192.168.0.235/24 (dhcp)
              ipv6                      fe80::302e:3fff:fe76:8fc2/64 (link-layer)
⇅ wan.10      vlan          UP          vid: 10
  │           ipv4                      10.0.10.1/24 (static)
  └ wan
⇅ wan.10.20   vlan          UP          vid: 20
  │           ipv4                      10.0.10.20/28 (static)
  └ wan.10
⇅ wifi0       wifi          UP          station ssid: corp-net signal: good
              ethernet                  dc:a6:32:00:11:22
              ipv4                      192.168.7.42/24 (dhcp)

yanger populates phy-type and pmd-type from a static ETHTOOL link-mode
identity table keyed on (port, speed, duplex).  Both leaves are populated
for unambiguous media (copper, DAC, copper-T); for generic fiber where
the (port, speed, duplex) tuple can map to multiple PMDs (SR vs LR vs
ER, etc.) only the phy-type family identity is emitted — guessing the
PMD would be misleading.  cli_pretty prefers pmd-type (specific) and
falls back to phy-type (family) for display.

yanger also emits ietf-interfaces:speed and fixes a long-standing
'auto-negotation' typo (yanger had never matched ethtool's correctly-
spelled JSON field, so operational auto-negotiation always read
'unknown').

Filling the WG's gap on fixed-speed config
------------------------------------------

IEEE Std 802.3.2-2025 obsoleted the eth:speed leaf without providing a
config-true replacement; the standards-correct way to express what
older Infix configurations called 'fixed speed' is to restrict the set
of PMDs auto-negotiation may advertise.  Augment auto-negotiation with
two leaf-lists:

  auto-negotiation/advertised-pmd-types  config-true,  leaf-list of pmd-type
  ethernet/supported-pmd-types           config-false, leaf-list of pmd-type

Pinning a port to a single mode is now expressed as a single-entry
advertised-pmd-types list.  The kernel-supported set is exposed as
operational state for diagnosis — SFP/SFP+ cages report the inserted
module's capabilities, narrowing the list to a single PMD when the
optic only supports one mode (as suggested by @wkz in PR review).
When the supported list collapses to a single entry, yanger uses it
to refine the operational pmd-type leaf — more accurate than the
(port, speed, duplex) lookup for fiber.

confd C apply path (src/confd/src/ieee802-ethernet-interface.c)
translates each advertised pmd-type identity to the corresponding
ETHTOOL_LINK_MODE_*_BIT_*, ORs them into a mask, and emits
'ethtool --change <if> autoneg on advertise 0x<mask>'.  An empty
list keeps the historical default of advertising every supported
mode.  The (legacy) 'auto-negotiation/enable = false' + speed/duplex
branch is removed — it has no model representation any more.

cli_pretty's detail view gains 'advertised' and 'supported' rows
listing the PMDs in each set.  A new _pr_label_list() helper unifies
multi-row rendering across these new rows and the pre-existing
ipv4/ipv6 address rows.

The detailed interface view also gains a 'link mode' row carrying the
pmd-type / phy-type-derived label.

Migration of existing startup configurations
--------------------------------------------

Bump confd version 1.8 → 1.9 to trigger the migration on upgrade.
share/migrate/1.9/10-ethernet-advertise.sh translates old configs of
the form

  ethernet { auto-negotiation { enable false; } speed S; duplex D; }

into

  ethernet { auto-negotiation { advertised-pmd-types [PMD]; } duplex D; }

mapping (S, D) → PMD via a static lookup covering the copper-T speeds
the deprecated speed leaf historically supported (10/100/1000/2.5G/
5G/10G).  Interfaces that don't disable auto-negotiation, or that
lack a speed leaf, are passed through untouched.

Closes #530
Closes #805

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
2026-05-27 20:53:29 +02:00
2026-05-19 13:45:25 +02:00
2026-05-16 20:56:56 +02:00
2026-05-23 16:23:53 +00:00
2026-05-23 16:23:53 +00:00
2022-12-05 21:09:05 +01:00

License Badge Release Badge GitHub Status Coverity Status Discord

Infix — Immutable.Friendly.Secure

Turn any ARM or x86 device into a powerful, manageable network appliance in minutes. From $35 Raspberry Pi boards to enterprise switches — deploy routers, IoT gateways, edge devices, or custom network solutions that just work.

Our Values

🔒 Immutable
Your system never breaks. Read-only filesystem with atomic upgrades means no configuration drift, no corrupted updates, and instant rollback if something goes wrong. Deploy once, trust forever.

🤝 Friendly
Actually easy to use. Auto-generated CLI from standard YANG models comes with built-in help for every command — just hit ? or TAB for context-aware assistance.

Familiar NETCONF & RESTCONF APIs and comprehensive documentation mean you're never stuck. Whether you're learning networking or managing enterprise infrastructure.

🛡️ Secure
Built with security as a foundation, not an afterthought. Minimal attack surface, separation between system and data, and container isolation. Sleep better knowing your infrastructure is protected.

Why Choose Infix

Hardware Flexibility: Start with a $35 Raspberry Pi, scale to enterprise switching hardware. Same OS, same tools, same reliability.

Standards-Based: Built around YANG models and IETF standards. Learn once, use everywhere - no vendor lock-in.

Container Ready: Run your applications alongside networking functions. GPIO access, dedicated Ethernet ports, custom protocols — your device, your rules.

Use Cases

  1. Home Labs & Hobbyists:
    Transform a Raspberry Pi into a full-featured router with WiFi
  2. IoT & Edge Computing:
    Bridge devices to the cloud with reliable, updatable gateways
  3. Small Business Networks:
    Enterprise-grade features without the complexity or cost
  4. Developers & Makers:
    Test networking concepts, prototype IoT solutions, or build custom appliances
  5. Network Professionals:
    Consistent tooling from development to production deployment.
    How about a digital twin using raw Qemu or GNS3!

Quick Example

Configure an interface in seconds - the CLI guides you with built-in help:

admin@infix-12-34-56:/> configure
admin@infix-12-34-56:/config/> edit interface eth0
admin@infix-12-34-56:/config/interface/eth0/> set ipv4 TAB
      address     autoconf      bind-ni-name     dhcp 
      enabled     forwarding    mtu              neighbor
admin@infix-12-34-56:/config/interface/eth0/> set ipv4 address 192.168.2.200 prefix-length 24
admin@infix-12-34-56:/config/interface/eth0/> show
type ethernet;
ipv4 {
  address 192.168.2.200 {
    prefix-length 24;
  }
}
admin@infix-12-34-56:/config/interface/eth0/> diff
interfaces {
  interface eth0 {
+    ipv4 {
+      address 192.168.2.200 {
+        prefix-length 24;
+      }
+    }
  }
}
admin@infix-12-34-56:/config/interface/eth0/> leave
admin@infix-12-34-56:/> show interfaces
INTERFACE       PROTOCOL   STATE       DATA                                  
lo              ethernet   UP          00:00:00:00:00:00
                ipv4                   127.0.0.1/8 (static)
                ipv6                   ::1/128 (static)
eth0            ethernet   UP          52:54:00:12:34:56
                ipv4                   192.168.2.200/24 (static)
                ipv6                   fe80::5054:ff:fe12:3456/64 (link-layer)
admin@infix-12-34-56:/> copy running startup

Notice how TAB completion shows available options, show displays current config, and diff shows exactly what changed before you commit your changes with the leave command.

For more information, see CLI documentation.

Get Started

Get pre-built images for your hardware. Use the CLI, web interface, or standard NETCONF/RESTCONF tools, e.g., curl. Add containers for any custom functionality you need.

Supported Platforms

  • Raspberry Pi 2B/3B/4B/CM4 - Perfect for home labs, learning, and prototyping
  • Banana Pi-R3 - Your next home router and gateway
  • NanoPi R2S - Compact dual-port router in a tiny package
  • x86_64 - Run in VMs or on mini PCs for development and testing
  • Marvell CN9130 CRB, EspressoBIN - High-performance ARM64 platforms
  • Microchip SparX-5i - Enterprise switching capabilities
  • Microchip SAMA7G54-EK - ARM Cortex-A7
  • NXP i.MX8MP EVK - Highly capable ARM64 SoC
  • StarFive VisionFive2 - RISC-V architecture support

Why start with Raspberry Pi? It's affordable, widely available, has built-in WiFi + Ethernet, and runs the exact same Infix OS you'd deploy in production. Perfect for learning, prototyping, or even small-scale deployments.

📖 Complete documentation💬 Join our Discord

Technical Details

bitSign - Code Signing

Built on proven open-source foundations: Linux, Buildroot, and sysrepo — for reliability you can trust:

  • Immutable OS: Read-only filesystem, atomic updates, instant rollback
  • YANG Configuration: Industry-standard models with auto-generated tooling
  • Hardware Acceleration: Linux switchdev support for wire-speed packet processing
  • Container Integration: Docker support with flexible network and hardware access
  • Memory Efficient: Runs comfortably on devices with as little as 256 MB RAM
  • Code Signing: Releases are cryptographically signed for integrity verification

Perfect for everything from resource-constrained edge devices to high-throughput network appliances.

With the entire system modeled in YANG, scalability is no longer an issue, be it in development, testing, or end users deploying and monitoring their devices. All knobs and dials are accessible from the CLI (console/SSH), or remotely using the native NETCONF or RESTCONF APIs.

Check the Latest Build for bleeding-edge features.



Infix development is sponsored by Wires

Alt

Languages
Python 36.9%
C 16.3%
Go 16.1%
HTML 13.5%
Shell 8.2%
Other 8.9%