diff --git a/doc/bridging.md b/doc/bridging.md
new file mode 100644
index 00000000..c751b90c
--- /dev/null
+++ b/doc/bridging.md
@@ -0,0 +1,284 @@
+# Bridging
+
+This is the most central part of the system. A bridge is a switch, and
+a switch is a bridge. In Linux, setting up a bridge with ports
+connected to physical switch fabric, means you manage the actual switch
+fabric!
+
+## MAC Bridge
+
+In Infix ports are by default not switch ports, unless the customer
+specific factory config sets it up this way. To enable switching, with
+offloading if you have a switch chipset, between ports you create a
+bridge and then add ports to that bridge. Like this:
+
+admin@example:/> configure
+admin@example:/config/> edit interface br0
+admin@example:/config/interface/br0/> up
+admin@example:/config/> set interface eth0 bridge-port bridge br0
+admin@example:/config/> set interface eth1 bridge-port bridge br0
+admin@example:/config/> leave
+
+
+Here we add two ports to bridge `br0`: `eth0` and `eth1`.
+
+> [!TIP]
+> The CLI has several built-in helpers governed by convention. E.g.,
+> naming bridges `brN`, where `N` is a number, the type is *inferred*
+> automatically and unlocks all bridge features. Other conventions are
+> `vethNA`, where `N` is a number and `A` is a letter ('a' for access
+> port and 'b' for bridge side is common), and `ethN.M` for VLAN M on
+> top of `ethN`, or `dockerN` for a IP masquerading container bridge.
+>
+> Note, this inference only works with the CLI, configuring networking
+> over NETCONF or RESTCONF requires setting the type explicitly.
+
+
+
+It is possible to create multiple MAC bridges, however, it is
+currently[^1] _not recommended_ to use more than one MAC bridge on
+products with Marvell LinkStreet switching ASICs. A VLAN filtering
+bridge should be used instead.
+
+## VLAN Filtering Bridge
+
+By default bridges in Linux do not filter based on VLAN tags. This can
+be enabled when creating a bridge by adding a port to a VLAN as a tagged
+or untagged member. Use the port default VID (PVID) setting to control
+VLAN association for traffic ingressing a port untagged (default PVID:
+1).
+
+admin@example:/config/> edit interface br0
+admin@example:/config/interface/br0/> up
+admin@example:/config/> set interface eth0 bridge-port bridge br0
+admin@example:/config/> set interface eth0 bridge-port pvid 10
+admin@example:/config/> set interface eth1 bridge-port bridge br0
+admin@example:/config/> set interface eth1 bridge-port pvid 20
+admin@example:/config/> edit interface br0
+admin@example:/config/interface/br0/> set bridge vlans vlan 10 untagged eth0
+admin@example:/config/interface/br0/> set bridge vlans vlan 20 untagged eth1
+
+
+This sets `eth0` as an untagged member of VLAN 10 and `eth1` as an
+untagged member of VLAN 20. Switching between these ports is thus
+prohibited.
+
+
+
+To terminate a VLAN in the switch itself, either for switch management
+or for routing, the bridge must become a (tagged) member of the VLAN.
+
+admin@example:/config/interface/br0/> set bridge vlans vlan 10 tagged br0
+admin@example:/config/interface/br0/> set bridge vlans vlan 20 tagged br0
+
+
+To route or to manage via a VLAN, a VLAN interface needs to be created
+on top of the bridge, see section [VLAN Interfaces](ethernet.md#vlan-interfaces)
+for more on this topic.
+
+> [!NOTE]
+> In some use-cases only a single management VLAN on the bridge is used.
+> For the example above, if the bridge itself is an untagged member only
+> in VLAN 10, IP addresses can be set directly on the bridge without the
+> need for dedicated VLAN interfaces on top of the bridge.
+
+
+## Multicast Filtering and Snooping
+
+Multicast filtering in the bridge is handled by the bridge itself. It
+can filter both IP multicast and MAC multicast. For IP multicast it
+also supports "snooping", i.e., IGMP and MLD, to automatically reduce
+the broadcast effects of multicast. See the next section for a summary
+of the [terminology used](#terminology-abbreviations).
+
+> [!IMPORTANT]
+> Currently there is no way to just enable multicast filtering without
+> also enabling snooping. This may change in the future, in which case
+> a `filtering` enabled setting will be made available along with the
+> existing `snooping` setting.
+
+When creating your bridge you must decide if you need a VLAN filtering
+bridge or a plain bridge (see previous section). Multicast filtering is
+supported for either, but take note that it must be enabled and set up
+per VLAN when VLAN filtering is enabled -- there are no global multicast
+settings in this operating mode.
+
+In the following example we have a regular 8-port bridge without VLAN
+filtering. We focus on the multicast specific settings:
+
+admin@example:/> configure
+admin@example:/config/> edit interface br0
+admin@example:/config/interface/br0/> set bridge multicast snooping
+admin@example:/config/interface/br0/> set ipv4 address 192.168.2.1 prefix-length 24
+admin@example:/config/interface/br0/> leave
+admin@example:/> copy running-config startup-config
+
+
+Here we enable snooping and set a static IPv4 address so that the switch
+can take part in IGMP querier elections. (MLD querier election
+currently not supported.) We can inspect the current state:
+
+admin@example:/> show ip multicast
+Multicast Overview
+Query Interval (default): 125 sec
+Router Timeout : 255
+Fast Leave Ports :
+Router Ports :
+Flood Ports : e0, e1, e2, e3, e4, e5, e6, e7
+
+
+br0 192.168.2.1 Up 125 None 3
+
+
+br0 224.1.1.1 e3, e2
+br0 ff02::6a br0
+
+
+This is a rather small LAN, so our bridge has already become the elected
+IGMP querier. We see it is ours because the timeout is `None`, and we
+recognize the IP address the system has detected, as ours. We can also
+see two ports that have joined the same IPv4 multicast group, 224.1.1.1,
+and one join from the system itself for the IPv6 group ff02::6a.
+
+Now, let us see what happens when we add another bridge, this time with
+VLAN filtering enabled. We skip the boring parts about how to move
+ports e4-e7 to `br1` and assign them to VLANs, and again, focus on the
+multicast bits only:
+
+admin@example:/> configure
+admin@example:/config/> edit interface br1
+admin@example:/config/interface/br1/> set bridge vlans vlan 1 multicast snooping
+admin@example:/config/interface/br1/> set bridge vlans vlan 2 multicast snooping
+admin@example:/config/interface/br1/> leave
+admin@example:/> copy running-config startup-config
+
+
+Let us see what we get:
+
+admin@example:/> show ip multicast
+Multicast Overview
+Query Interval (default): 125 sec
+Router Timeout : 255
+Fast Leave Ports : e5
+Router Ports : e1, e2, e5, e6, e7
+Flood Ports : e1, e2, e3, e4, e5, e6, e7, e8
+
+
+br0 192.168.2.1 Up 125 None 3
+br1 1 0.0.0.0 Up 125 None 3
+br1 2 0.0.0.0 Up 125 None 3
+
+
+br0 224.1.1.1 e2
+br0 ff02::fb br0
+br0 ff02::6a br0
+br0 ff02::1:ff00:0 br0
+br1 1 224.1.1.1 e5
+br1 2 224.1.1.1 e7
+br1 1 ff02::fb br1
+br1 1 ff02::1:ff00:0 br1
+
+
+In this setup we have a lot more going on. Multiple multicast router
+ports have been detected, and behind the scenes someone has also added
+an IGMP/MLD fast-leave port.
+
+### Terminology & Abbreviations
+
+ - **IGMP**: Internet Group Membership Protocol, multicast subscription
+ for IPv4, for details see [RFC3376][]
+ - **MLD**: Multicast Listener Discovery (Protocol), multicast
+ subscription for IPv6, for details see [RFC3810][]
+ - **Unknown/Unregistered multicast**: multicast groups that are *not*
+ in the multicast forwarding database (MDB)
+ - **Known/Registered multicast**: multicast groups that *are* in the
+ multicast forwarding database (MDB)
+ - **MDB**: the multicast forwarding database, consists of filters for
+ multicast groups, directing where multicast is allowed to egress. A
+ filter entry consists of a group and a port list. The bridge filters
+ with a unique database per VLAN, in the same was as the unicast FDB
+ - **Join/Leave**: the terminology used in earlier versions of the two
+ protocols to subscribe and unsubscribe to a multicast group. For
+ more information, see *Membership Report*
+ - **Membership Report** A membership report is sent by end-devices and
+ forwarded by switches to the elected querier on the LAN. They
+ consist of multiple "join" and "leave" operations on groups. They
+ can also, per group, list which senders to allow or block. Switches
+ usually only support the group subscription, and even more common
+ also only support filtering on the MAC level[^2]
+ - **Querier election**: the process of determining who is the elected
+ IGMP/MLD querier on a LAN. Lowest numerical IP address wins, the
+ special address 0.0.0.0 (proxy querier) never wins
+ - **Proxy querier**: when no better querier exists on a LAN, one or
+ more devices can send proxy queries with source address 0.0.0.0 (or
+ :: for IPv6). See **Query Interval**, below, why this is a good
+ thing
+ - **Query interval**: the time in seconds between two queries from an
+ IGMP/MLD querier. It is not uncommon that end-devices do not send
+ their membership reports unless they first hear a query
+ - **Fast Leave**: set on a bridge port to ensure multicast is pruned as
+ quickly as possible when a "leave" membership report is received. In
+ effect, this option marks the port as directly connected to an
+ end-device. When not set (default), a query with timeout is first
+ sent to ensure no unintentional loss of multicast is incurred
+ - **Router port**: can be both configured statically and detected at
+ runtime based on connected devices, usually multicast routers. On
+ a router port *all* multicast is forwarded, both known and unknown
+ - **Flood port**: set on a bridge port (default: enabled) to ensure
+ all *unknown* multicast is forwarded
+ - **Router timeout**: the time in seconds until a querier is deemed to
+ have been lost and another device (switch/router) takes over. In the
+ tables shown above, a *None* timeout is declared when the current
+ device is the active querier
+
+> [!TIP]
+> The reason why multicast flooding is enabled by default is to ensure
+> safe co-existence with MAC multicast, which is common in industrial
+> networks. It also allows end devices that do not know of IGMP/MLD to
+> communicate over multicast as long as the group they have chosen is
+> not used by other IGMP/MLD aware devices on the LAN.
+>
+> As soon as an IGMP/MLD membership report to "join" a group is received
+> the group is added to the kernel MDB and forwarding to other ports
+> stop. The only exception to this rule is multicast router ports.
+>
+> If your MAC multicast forwarding is not working properly, it may be
+> because an IP multicast group maps to the same MAC address. Please
+> see [RFC 1112][RFC1112] for details. Use static multicast router
+> ports, or static multicast MAC filters, to mitigate.
+
+[RFC1112]: https://www.rfc-editor.org/rfc/rfc1112.html
+[RFC3376]: https://www.rfc-editor.org/rfc/rfc3376.html
+[RFC3810]: https://www.rfc-editor.org/rfc/rfc3810.html
+
+## Forwarding of IEEE Reserved Group Addresses
+
+Addresses in the range `01:80:C2:00:00:0X` are used by various bridge
+signaling protocols, and are not forwarded by default. Still, it is
+sometimes useful to let the bridge forward such packets, this can be
+done by specifying protocol names or the last address *nibble* as
+decimal value `0..15`:
+
+admin@example:/config/> edit interface br0 bridge
+admin@example:/config/interface/br0/bridge/> set ieee-group-forward # Tap the ? key for alternatives
+ [0..15] List of IEEE link-local protocols to forward, e.g., STP, LLDP
+ dot1x 802.1X Port-Based Network Access Control.
+ lacp 802.3 Slow Protocols, e.g., LACP.
+ lldp 802.1AB Link Layer Discovery Protocol (LLDP).
+ stp Spanning Tree (STP/RSPT/MSTP).
+admin@example:/config/interface/br0/bridge/> set ieee-group-forward
+
+
+The following example configures bridge *br0* to forward LLDP packets.
+
+admin@example:/config/interface/br0/bridge/> set ieee-group-forward lldp
+admin@example:/config/interface/br0/bridge/>
+
+
+[^1]: MAC bridges on Marvell Linkstreet devices are currently limited to
+ a single MAC database, this may be a problem if the same MAC address
+ appears in different MAC bridges.
+[^2]: For example, IPv4 groups are mapped to MAC multicast addresses by
+ mapping the low-order 23-bits of the IP address in the low-order 23
+ bits of the Ethernet address 01:00:5E:00:00:00. Meaning, more than
+ one IP multicast group maps to the same MAC multicast group.
diff --git a/doc/ethernet.md b/doc/ethernet.md
new file mode 100644
index 00000000..84e8cb75
--- /dev/null
+++ b/doc/ethernet.md
@@ -0,0 +1,208 @@
+# Ethernet Interfaces
+
+This document covers VLAN interfaces, physical Ethernet interfaces,
+and virtual Ethernet (VETH) pairs.
+
+
+## VLAN Interfaces
+
+Creating a VLAN can be done in many ways. This section assumes VLAN
+interfaces created atop another Linux interface. E.g., the VLAN
+interfaces created on top of the Ethernet interface or bridge in the
+picture below.
+
+
+
+A VLAN interface is basically a filtering abstraction. When you run
+`tcpdump` on a VLAN interface you will only see the frames matching the
+VLAN ID of the interface, compared to *all* the VLAN IDs if you run
+`tcpdump` on the lower-layer interface.
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0.20
+admin@example:/config/interface/eth0.20/> show
+type vlan;
+vlan {
+ tag-type c-vlan;
+ id 20;
+ lower-layer-if eth0;
+}
+admin@example:/config/interface/eth0.20/> leave
+
+
+The example below assumes bridge br0 is already created, see [VLAN
+Filtering Bridge](bridging.md#vlan-filtering-bridge).
+
+admin@example:/> configure
+admin@example:/config/> edit interface vlan10
+admin@example:/config/interface/vlan10/> set vlan id 10
+admin@example:/config/interface/vlan10/> set vlan lower-layer-if br0
+admin@example:/config/interface/vlan10/> leave
+
+
+As conventions, a VLAN interface for VID 20 on top of an Ethernet
+interface *eth0* is named *eth0.20*, and a VLAN interface for VID 10 on
+top of a bridge interface *br0* is named *vlan10*.
+
+> [!NOTE]
+> If you name your VLAN interface `foo0.N` or `vlanN`, where `N` is a
+> number, the CLI infers the interface type automatically.
+
+
+## Physical Ethernet Interfaces
+
+### Ethernet Settings and Status
+
+Physical Ethernet interfaces provide low-level settings for speed/duplex as
+well as packet status and [statistics](#ethernet-statistics).
+
+By default, Ethernet interfaces defaults to auto-negotiating
+speed/duplex modes, advertising all speed and duplex modes available.
+In the example below, the switch would by default auto-negotiate speed
+1 Gbit/s on port eth1 and 100 Mbit/s on port eth4, as those are the
+highest speeds supported by H1 and H2 respectively.
+
+
+
+The speed and duplex status for the links can be listed as shown
+below, assuming the link operational status is 'up'.
+
+admin@example:/> show interface eth1
+name : eth1
+index : 2
+mtu : 1500
+operational status : up
+auto-negotiation : on
+duplex : full
+speed : 1000
+physical address : 00:53:00:06:11:01
+ipv4 addresses :
+ipv6 addresses :
+in-octets : 75581
+out-octets : 43130
+...
+admin@example:/> show interface eth4
+name : eth4
+index : 5
+mtu : 1500
+operational status : up
+auto-negotiation : on
+duplex : full
+speed : 100
+physical address : 00:53:00:06:11:04
+ipv4 addresses :
+ipv6 addresses :
+in-octets : 75439
+out-octets : 550704
+...
+admin@example:/>
+
+
+### Configuring fixed speed and duplex
+
+Auto-negotiation of speed/duplex mode is desired in almost all
+use-cases, but it is possible to disable auto-negotiation and specify
+a fixed speed and duplex mode.
+
+> [!IMPORTANT]
+> When setting a fixed speed and duplex mode, ensure both sides of the
+> link have matching configuration. If speed does not match, the link
+> will not come up. If duplex mode does not match, the result is
+> reported collisions and/or bad throughput.
+
+The example below configures port eth3 to fixed speed 100 Mbit/s
+half-duplex mode.
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth3 ethernet
+admin@example:/config/interface/eth3/ethernet/> set speed 0.1
+admin@example:/config/interface/eth3/ethernet/> set duplex half
+admin@example:/config/interface/eth3/ethernet/> set auto-negotiation enable false
+admin@example:/config/interface/eth3/ethernet/> show
+auto-negotiation {
+ enable false;
+}
+duplex half;
+speed 0.1;
+admin@example:/config/interface/eth3/ethernet/> leave
+admin@example:/>
+
+
+Speed metric is in Gbit/s. Auto-negotiation needs to be disabled in
+order for fixed speed/duplex to apply. Only speeds `0.1`(100 Mbit/s)
+and `0.01` (10 Mbit/s) can be specified. 1 Gbit/s and higher speeds
+require auto-negotiation to be enabled.
+
+### Ethernet statistics
+
+Ethernet packet statistics[^1] can be listed as shown below.
+
+admin@example:/> show interface eth1
+name : eth1
+index : 2
+mtu : 1500
+operational status : up
+auto-negotiation : on
+duplex : full
+speed : 1000
+physical address : 00:53:00:06:11:0a
+ipv4 addresses :
+ipv6 addresses :
+in-octets : 75581
+out-octets : 43130
+
+eth-in-frames : 434
+eth-in-multicast-frames : 296
+eth-in-broadcast-frames : 138
+eth-in-error-fcs-frames : 0
+eth-in-error-oversize-frames : 0
+eth-out-frames : 310
+eth-out-multicast-frames : 310
+eth-out-broadcast-frames : 0
+eth-out-good-octets : 76821
+eth-in-good-octets : 60598
+admin@example:/>
+
+
+
+## VETH Pairs
+
+A Virtual Ethernet (VETH) pair is basically a virtual Ethernet cable. A
+cable can be "plugged in" to a bridge and the other end can be given to
+a [container](container.md), or plugged into another bridge.
+
+The latter example is useful if you have multiple bridges in the system
+with different properties (VLAN filtering, IEEE group forwarding, etc.),
+but still want some way of communicating between these domains.
+
+admin@example:/> configure
+admin@example:/config/> edit interface veth0a
+admin@example:/config/interface/veth0a/> set veth peer veth0b
+admin@example:/config/interface/veth0a/> end
+admin@example:/config/> diff
+interfaces {
++ interface veth0a {
++ type veth;
++ veth {
++ peer veth0b;
++ }
++ }
++ interface veth0b {
++ type veth;
++ veth {
++ peer veth0a;
++ }
++ }
+}
+admin@example:/config/>
+
+
+> [!TIP]
+> This is another example of the automatic inference of the interface
+> type from the name. Any name can be used, but then you have to set
+> the interface type to `veth` manually.
+
+[^1]: Ethernet counters are described in *ieee802-ethernet-interface.yang*
+ and *infix-ethernet-interface.yang*. There is a dedicated document on
+ [Ethernet Counters](eth-counters.md) that provide additional details
+ on the statistics support.
diff --git a/doc/firewall.md b/doc/firewall.md
index b685b02b..1f33052a 100644
--- a/doc/firewall.md
+++ b/doc/firewall.md
@@ -93,7 +93,7 @@ about this in the [example below](#end-device-protection).
> [!IMPORTANT] Remember IP forwarding on interfaces!
> Firewall policies only control whether traffic is allowed on input, to be
> forwarded, or blocked (default). For the actual routing between interfaces
-> to work, you must also enable [IP forwarding](networking.md#ipv4-forwarding)
+> to work, you must also enable [IP forwarding](ip.md#ipv4-forwarding)
> on the relevant interfaces.
### Intra-Zone Traffic
@@ -461,4 +461,4 @@ You can check the current lockdown state:
}
```
-[1]: networking.md#bridging
+[1]: bridging.md
diff --git a/doc/iface.md b/doc/iface.md
new file mode 100644
index 00000000..3ec25285
--- /dev/null
+++ b/doc/iface.md
@@ -0,0 +1,143 @@
+# Common Interface Settings
+
+Common interface settings include `name`, `type`, `enabled`, `description`,
+and custom MAC address. Type-specific settings are covered in the dedicated
+sections for [Bridging](bridging.md), [Link Aggregation](lag.md),
+[Ethernet](ethernet.md), [IP Addressing](ip.md), and [Routing](routing.md).
+
+
+## Interface Name
+
+The interface name is limited to 1-15 characters due to Linux kernel
+constraints. Physical interfaces use their system-assigned names (e.g.,
+`eth0`, `eth1`), while user-created interfaces can be named freely within
+this limit.
+
+> [!TIP]
+> Naming conventions like `br0`, `lag0`, `vlan10`, or `eth0.20` allow
+> the CLI to automatically infer the interface type.
+
+
+## Interface Type
+
+The `type` setting defines what kind of interface this is: `bridge`, `lag`,
+`vlan`, `veth`, etc. When configuring via the CLI, the type is often
+inferred from the interface name. However, when configuring remotely via
+NETCONF or RESTCONF, the type *must* be set explicitly.
+
+admin@example:/config/> edit interface br0
+admin@example:/config/interface/br0/> set type bridge
+
+
+Available types can be listed from the CLI:
+
+admin@example:/config/interface/br0/> set type ?
+ bridge IEEE bridge interface.
+ dummy Linux dummy interface. Useful mostly for testing.
+ ethernet Any Ethernet interfaces, regardless of speed, RFC 3635.
+ gre GRE tunnel interface.
+ gretap GRETAP (Ethernet over GRE) tunnel interface.
+ lag IEEE link aggregate interface.
+ loopback Linux loopback interface.
+ other Other interface, i.e., unknown.
+ veth Linux virtual Ethernet pair.
+ vlan Layer 2 Virtual LAN using 802.1Q.
+ vxlan Virtual eXtensible LAN tunnel interface.
+ wifi WiFi (802.11) interface
+ wireguard WireGuard VPN tunnel interface.
+
+
+
+## Enable/Disable
+
+An interface can be administratively disabled using the `enabled` setting.
+By default, interfaces are enabled (`true`).
+
+admin@example:/config/> edit interface eth0
+admin@example:/config/interface/eth0/> set enabled false
+admin@example:/config/interface/eth0/> leave
+
+
+The operational status can be inspected to see both administrative and
+actual link state:
+
+admin@example:/> show interfaces
+INTERFACE PROTOCOL STATE DATA
+eth0 ethernet DISABLED 02:00:00:00:00:00
+eth1 ethernet UP 02:00:00:00:00:01
+...
+
+
+
+## Description
+
+The `description` is a free-form text string (max 64 characters) saved
+as the Linux interface alias (`ifalias`). Use it to document an interface's
+purpose or add notes for remote debugging.
+
+admin@example:/config/> edit interface eth0
+admin@example:/config/interface/eth0/> set description "Uplink to core switch"
+admin@example:/config/interface/eth0/> leave
+
+
+The description is visible in the operational datastore and in `show`
+commands:
+
+admin@example:/> show interface eth0
+name : eth0
+description : Uplink to core switch
+index : 2
+...
+
+
+
+## Custom MAC Address
+
+The `custom-phys-address` can be used to set an interface's MAC address.
+This is an extension to the ietf-interfaces YANG model, which defines
+`phys-address` as read-only[^1].
+
+> [!CAUTION]
+> There is no validation or safety checks performed by the system when
+> using `custom-phys-address`. In particular the `offset` variant can
+> be dangerous to use -- pay attention to the meaning of bits in the
+> upper-most octet: local bit, multicast/group, etc.
+
+### Fixed custom MAC
+
+Use a fixed custom MAC address when the interface must present a
+specific, deterministic identity on the network. This option bypasses
+any chassis-derived logic and applies the configured address verbatim.
+
+admin@example:/config/> edit interface veth0a
+admin@example:/config/interface/veth0a/> set custom-phys-address static 00:ab:00:11:22:33
+
+=> 00:ab:00:11:22:33
+
+
+### Chassis MAC
+
+Chassis MAC, sometimes also referred to as base MAC. In these two
+examples it is `00:53:00:c0:ff:ee`.
+
+admin@example:/config/> edit interface veth0a
+admin@example:/config/interface/veth0a/> set custom-phys-address chassis
+
+=> 00:53:00:c0:ff:ee
+
+
+### Chassis MAC, with offset
+
+When constructing a derived address it is recommended to set the locally
+administered bit. Same chassis MAC as before.
+
+admin@example:/config/> edit interface veth0a
+admin@example:/config/interface/veth0a/> set custom-phys-address chassis offset 02:00:00:00:00:02
+
+=> 02:53:00:c0:ff:f0
+
+
+
+[^1]: A YANG deviation was previously used to make it possible to set
+ `phys-address`, but this has been replaced with the more flexible
+ `custom-phys-address`.
diff --git a/doc/ip.md b/doc/ip.md
new file mode 100644
index 00000000..1f79b121
--- /dev/null
+++ b/doc/ip.md
@@ -0,0 +1,445 @@
+# IP Address Configuration
+
+This section details IP Addresses And Other Per-Interface IP settings.
+
+Infix support several network interface types, each can be assigned one
+or more IP addresses, both IPv4 and IPv6 are supported. (There is no
+concept of a "primary" address.)
+
+
+
+## IPv4 Address Assignment
+
+Multiple address assignment methods are available:
+
+| **Type** | **Yang Model** | **Description** |
+|:---------- |:----------------- |:-------------------------------------------------------------- |
+| static | ietf-ip | Static assignment of IPv4 address, e.g., *10.0.1.1/24* |
+| link-local | infix-ip | Auto-assignment of IPv4 address in 169.254.x.x/16 range |
+| dhcp | infix-dhcp-client | Assignment of IPv4 address by DHCP server, e.g., *10.0.1.1/24* |
+
+> [!NOTE]
+> The DHCP address method is only available for *LAN* interfaces
+> (Ethernet, virtual Ethernet (veth), bridge, link aggregates, etc.)
+
+Supported DHCP (request) options, configurability (Cfg) and defaults,
+are listed below. Configurable options can be disabled on a per client
+interface basis, some options, like `clientid` and option 81, are
+possible to set the value of as well.
+
+| **Opt** | **Name** | **Cfg** | **Description** |
+|---------|-----------------------------|---------|-----------------------------------------------------|
+| 1 | `netmask` | No | Request IP address and netmask |
+| 3 | `router` | Yes | Default route(s), see also option 121 and 249 |
+| 6 | `dns-server` | Yes | DNS server(s), static ones take precedence |
+| 12 | `hostname` | Yes | DHCP cannot set hostname, only for informing server |
+| 15 | `domain` | Yes | Default domain name, for name resolution |
+| 28 | `broadcast` | Yes | Broadcast address, calculated if disabled |
+| 42 | `ntp-server` | Yes | NTP server(s), static ones take precedence |
+| 50 | `address` | Yes | Request (previously cached) address |
+| 61 | `client-id` | Yes | Default MAC address (and option 12) |
+| 81 | `fqdn` | Yes | Similar to option 12, request FQDN update in DNS |
+| 119 | `search` | Yes | Request domain search list |
+| 121 | `classless-static-route` | Yes | Classless static routes |
+| 249 | `ms-classless-static-route` | Yes | Microsoft static route, same as option 121 |
+| | | | |
+
+**Default:** `router`, `dns-server`, `domain`, `broadcast`, `ntp-server`, `search`,
+ `address`, `classless-static-route`, `ms-classless-static-route`
+
+When configuring a DHCP client, ensure that the NTP client is enabled
+for the `ntp-server` DHCP option to be processed correctly. If the NTP
+client is not enabled, any NTP servers provided by the DHCP server will
+be ignored. For details on how to enable the NTP client, see the [NTP
+Client Configuration](system.md#ntp-client-configuration) section.
+
+> [!IMPORTANT]
+> Per [RFC3442][1], if the DHCP server returns both a Classless Static
+> Routes option (121) and Router option (3), the DHCP client *must*
+> ignore the latter.
+
+
+## IPv6 Address Assignment
+
+Multiple address assignment methods are available:
+
+| **Type** | **Yang Model** | **Description** |
+|:---------------- |:-------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------- |
+| static | ietf-ip | Static assignment of IPv6 address, e.g., *2001:db8:0:1::1/64* |
+| link-local | ietf-ip[^1] | (RFC4862) Auto-configured link-local IPv6 address (*fe80::0* prefix + interface identifier, e.g., *fe80::ccd2:82ff:fe52:728b/64*) |
+| global auto-conf | ietf-ip | (RFC4862) Auto-configured (stateless) global IPv6 address (prefix from router + interface identifier, e.g., *2001:db8:0:1:ccd2:82ff:fe52:728b/64* |
+| dhcp | infix-dhcpv6-client | Assignment of IPv6 address by DHCPv6 server, e.g., *2001:db8::42/128* |
+
+Both for *link-local* and *global auto-configuration*, it is possible
+to auto-configure using a random suffix instead of the interface
+identifier.
+
+> [!NOTE]
+> The DHCPv6 address method is only available for *LAN* interfaces
+> (Ethernet, virtual Ethernet (veth), bridge, link aggregates, etc.)
+
+Supported DHCPv6 (request) options, configurability (Cfg) and defaults,
+are listed below. Configurable options can be disabled on a per client
+interface basis, some options, like `client-id` and `client-fqdn`, are
+possible to set the value of as well.
+
+| **Opt** | **Name** | **Cfg** | **Description** |
+|---------|----------------------------|---------|--------------------------------------------------------|
+| 1 | `client-id` | Yes | Client identifier (DUID), auto-generated by default |
+| 2 | `server-id` | Yes | Server identifier (DUID) |
+| 23 | `dns-server` | Yes | DNS recursive name servers, static ones take precedence|
+| 24 | `domain-search` | Yes | Domain search list |
+| 25 | `ia-pd` | Yes | Prefix delegation for downstream networks |
+| 31 | `sntp-server` | Yes | Simple Network Time Protocol servers |
+| 32 | `information-refresh-time` | Yes | Refresh time for stateless DHCPv6 |
+| 39 | `client-fqdn` | Yes | Client FQDN, request DNS update from server |
+| 56 | `ntp-server` | Yes | NTP time servers, static ones take precedence |
+| | | | |
+
+**Default:** `dns-server`, `domain-search`, `ntp-server`
+
+DHCPv6 supports both **stateful** (address assignment) and **stateless**
+(information-only) modes:
+
+- **Stateful DHCPv6**: The server assigns IPv6 addresses to clients. This is
+ the default mode when enabling the DHCPv6 client.
+- **Stateless DHCPv6**: Used with SLAAC (Stateless Address Autoconfiguration)
+ when only configuration information (DNS, NTP, etc.) is needed. Enable with
+ the `information-only` setting.
+
+When configuring a DHCPv6 client, ensure that the NTP client is enabled
+for the `ntp-server` DHCPv6 option to be processed correctly. If the
+NTP client is not enabled, any NTP servers provided by the DHCPv6 server
+will be ignored. For details on how to enable the NTP client, see the
+[NTP Client Configuration](system.md#ntp-client-configuration) section.
+
+## Examples
+
+
+
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv6 fe80::ff:fe00:0/64 (link-layer)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+To illustrate IP address configuration, the examples below uses a
+switch with a single Ethernet interface (eth0) and a loopback
+interface (lo). As shown above, these examples assume *eth0* has an
+IPv6 link-local address and *lo* has static IPv4 and IPv6 addresses by
+default.
+
+### Static and link-local IPv4 addresses
+
+
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv4
+admin@example:/config/interface/eth0/ipv4/> set address 10.0.1.1 prefix-length 24
+admin@example:/config/interface/eth0/ipv4/> set autoconf
+admin@example:/config/interface/eth0/ipv4/> diff
++interfaces {
++ interface eth0 {
++ ipv4 {
++ address 10.0.1.1 {
++ prefix-length 24;
++ }
++ autoconf;
++ }
++ }
++}
+admin@example:/config/interface/eth0/ipv4/> leave
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv4 169.254.1.3/16 (random)
+ ipv4 10.0.1.1/24 (static)
+ ipv6 fe80::ff:fe00:0/64 (link-layer)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+As shown, the link-local IPv4 address is configured with `set autoconf`.
+The presence of the `autoconf` container enables IPv4 link-local address
+assignment. The resulting address (169.254.1.3/16) is of type *random*
+([ietf-ip.yang][2]).
+
+The IPv4LL client also supports a `request-address` setting which can be
+used to "seed" the client's starting address. If the address is free it
+will be used, otherwise it falls back to the default algorithm.
+
+admin@example:/config/interface/eth0/ipv4/> edit autoconf
+admin@example:/config/interface/eth0/ipv4/autoconf/> set request-address 169.254.1.2
+admin@example:/config/interface/eth0/ipv4/autoconf/> leave
+
+
+
+### Use of DHCP for IPv4 address assignment
+
+
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv4
+admin@example:/config/interface/eth0/ipv4/> set dhcp
+admin@example:/config/interface/eth0/ipv4/> leave
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv4 10.1.2.100/24 (dhcp)
+ ipv6 fe80::ff:fe00:0/64 (link-layer)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+The resulting address (10.1.2.100/24) is of type *dhcp*.
+
+To configure DHCP client options, such as sending a specific hostname to the
+server, you can specify options with values:
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv4 dhcp
+admin@example:/config/interface/eth0/ipv4/dhcp/> set option hostname value myhost
+admin@example:/config/interface/eth0/ipv4/dhcp/> show
+option hostname {
+ value myhost;
+}
+admin@example:/config/interface/eth0/ipv4/dhcp/> leave
+admin@example:/>
+
+
+> [!TIP]
+> The special value `auto` can be used with the hostname option to
+> automatically use the configured system hostname.
+
+Other useful DHCP options include:
+
+- `client-id` - Send a specific client identifier to the server
+- `route-preference` - Set the administrative distance for DHCP-learned routes (default: 5)
+
+For advanced usage with vendor-specific options, see the YANG model.
+
+### Use of DHCPv6 for IPv6 address assignment
+
+
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv6
+admin@example:/config/interface/eth0/ipv6/> set dhcp
+admin@example:/config/interface/eth0/ipv6/> leave
+admin@example:/> show interface
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv6 2001:db8::42/128 (dhcp)
+ ipv6 fe80::ff:fe00:0/64 (link-layer)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+The resulting address (2001:db8::42/128) is of type *dhcp*.
+
+To configure DHCPv6 client options, such as requesting prefix delegation
+for downstream networks, you can specify options:
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv6 dhcp
+admin@example:/config/interface/eth0/ipv6/dhcp/> set option ia-pd
+admin@example:/config/interface/eth0/ipv6/dhcp/> set option dns-server
+admin@example:/config/interface/eth0/ipv6/dhcp/> show
+option dns-server;
+option ia-pd;
+admin@example:/config/interface/eth0/ipv6/dhcp/> leave
+admin@example:/>
+
+
+For stateless DHCPv6 (used with SLAAC to get only configuration information):
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv6 dhcp
+admin@example:/config/interface/eth0/ipv6/dhcp/> set information-only true
+admin@example:/config/interface/eth0/ipv6/dhcp/> show
+information-only true;
+option dns-server;
+option domain-search;
+admin@example:/config/interface/eth0/ipv6/dhcp/> leave
+admin@example:/>
+
+
+Other useful DHCPv6 options include:
+
+- `duid` - Set a specific DHCPv6 Unique Identifier (auto-generated by default)
+- `client-fqdn` - Request the server to update DNS records with client's FQDN
+- `route-preference` - Set the administrative distance for DHCPv6-learned routes (default: 5)
+
+For advanced usage with vendor-specific options, see the YANG model.
+
+### Disabling IPv6 link-local address(es)
+
+The (only) way to disable IPv6 link-local addresses is by disabling IPv6
+on the interface.
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv6
+admin@example:/config/interface/eth0/ipv6/> set enabled false
+admin@example:/config/interface/eth0/ipv6/> leave
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+### Static IPv6 address
+
+
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv6
+admin@example:/config/interface/eth0/ipv6/> set address 2001:db8::1 prefix-length 64
+admin@example:/config/interface/eth0/ipv6/> leave
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv6 2001:db8::1/64 (static)
+ ipv6 fe80::ff:fe00:0/64 (link-layer)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+
+### Stateless Auto-configuration of Global IPv6 Address
+
+
+
+Stateless address auto-configuration of global addresses is enabled by
+default. The address is formed by concatenating the network prefix
+advertised by the router (here 2001:db8:0:1::0/64) and the interface
+identifier. The resulting address is of type *link-layer*, as it is
+formed based on the interface identifier ([ietf-ip.yang][2]).
+
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv6 2001:db8:0:1:0:ff:fe00:0/64 (link-layer)
+ ipv6 fe80::ff:fe00:0/64 (link-layer)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+Disabling auto-configuration of global IPv6 addresses can be done as shown
+below.
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv6
+admin@example:/config/interface/eth0/ipv6/> set autoconf create-global-addresses false
+admin@example:/config/interface/eth0/ipv6/> leave
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv6 fe80::ff:fe00:0/64 (link-layer)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+
+### Random Link Identifiers for IPv6 Stateless Autoconfiguration
+
+
+
+By default, the auto-configured link-local and global IPv6 addresses
+are formed from a link-identifier based on the MAC address.
+
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv6 2001:db8:0:1:0:ff:fe00:0/64 (link-layer)
+ ipv6 fe80::ff:fe00:0/64 (link-layer)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+To avoid revealing identity information in the IPv6 address, it is
+possible to specify use of a random identifier ([ietf-ip.yang][2] and
+[RFC8981][3]).
+
+admin@example:/> configure
+admin@example:/config/> edit interface eth0 ipv6
+admin@example:/config/interface/eth0/ipv6/> set autoconf create-temporary-addresses true
+admin@example:/config/interface/eth0/ipv6/> leave
+admin@example:/> show interfaces
+
+eth0 ethernet UP 02:00:00:00:00:00
+ ipv6 2001:db8:0:1:b705:8374:638e:74a8/64 (random)
+ ipv6 fe80::ad3d:b274:885a:9ffb/64 (random)
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+admin@example:/>
+
+
+Both the link-local address (fe80::) and the global address (2001:)
+have changed type to *random*.
+
+
+## IPv4 forwarding
+
+To be able to route (static or dynamic) on the interface it is
+required to enable forwarding. This setting controls if packets
+received on this interface can be forwarded.
+
+admin@example:/config/> edit interface eth0
+admin@example:/config/interface/eth0/> set ipv4 forwarding
+admin@example:/config/interface/eth0/> leave
+admin@example:/>
+
+
+
+## IPv6 forwarding
+
+Due to how the Linux kernel manages IPv6 forwarding, we can not fully
+control it per interface via this setting like how IPv4 works. Instead,
+IPv6 forwarding is globally enabled when at least one interface enable
+forwarding, otherwise it is disabled.
+
+The following table shows the system IPv6 features that the `forwarding`
+setting control when it is *Enabled* or *Disabled:
+
+| **IPv6 Feature** | **Enabled** | **Disabled** |
+|:-----------------------------------------|:------------|:-------------|
+| IsRouter set in Neighbour Advertisements | Yes | No |
+| Transmit Router Solicitations | No | Yes |
+| Router Advertisements are ignored | Yes | Yes |
+| Accept Redirects | No | Yes |
+
+admin@example:/config/> edit interface eth0
+admin@example:/config/interface/eth0/> set ipv6 forwarding
+admin@example:/config/interface/eth0/> leave
+admin@example:/>
+
+
+[1]: https://www.rfc-editor.org/rfc/rfc3442
+[2]: https://www.rfc-editor.org/rfc/rfc8344
+[3]: https://www.rfc-editor.org/rfc/rfc8981
+
+[^1]: Link-local IPv6 addresses are implicitly enabled when enabling
+ IPv6. IPv6 can be enabled/disabled per interface in the
+ [ietf-ip][2] YANG model.
diff --git a/doc/lag.md b/doc/lag.md
new file mode 100644
index 00000000..b4c6b4f8
--- /dev/null
+++ b/doc/lag.md
@@ -0,0 +1,245 @@
+# Link Aggregation
+
+A link aggregate, or *lag*, allows multiple physical interfaces to be
+combined into a single logical interface, providing increased bandwidth
+(in some cases) and redundancy (primarily). Two modes of qualifying lag
+member ports are available:
+
+ 1. **static**: Active members selected based on link status (carrier)
+ 2. **lacp:** IEEE 802.3ad Link Aggregation Control Protocol
+
+In LACP mode, LACPDUs are exchanged by the link partners to qualify each
+lag member, while in static mode only carrier is used. This additional
+exchange in LACP ensures traffic can be forwarded in both directions.
+
+Traffic distribution, for both modes, across the active lag member ports
+is determined by the hash policy[^1]. It uses an XOR of the source,
+destination MAC addresses and the EtherType field. This, IEEE
+802.3ad-compliant, algorithm will place all traffic to a particular
+network peer on the same link. Meaning there is no increased bandwidth
+for communication between two specific devices.
+
+> [!TIP]
+> Similar to other interface types, naming your interface `lagN`, where
+> `N` is a number, allows the CLI to automatically infer the interface
+> type as LAG.
+
+
+## Basic Configuration
+
+Creating a link aggregate interface and adding member ports:
+
+admin@example:/> configure
+admin@example:/config/> edit interface lag0
+admin@example:/config/interface/lag0/> set lag mode static
+admin@example:/config/interface/lag0/> end
+admin@example:/config/> set interface eth7 lag-port lag lag0
+admin@example:/config/> set interface eth8 lag-port lag lag0
+admin@example:/config/> leave
+
+
+A static lag responds only to link (carrier) changes of member ports.
+E.g., in this example egressing traffic is continuously distributed over
+the two links until link down on one link is detected, triggering all
+traffic to be steered to the sole remaining link.
+
+
+## LACP Configuration
+
+LACP mode provides dynamic negotiation of the link aggregate. Key
+settings include:
+
+admin@example:/> configure
+admin@example:/config/> edit interface lag0
+admin@example:/config/interface/lag0/> set lag mode lacp
+admin@example:/config/interface/lag0/> set lag lacp mode passive
+admin@example:/config/interface/lag0/> set lag lacp rate fast
+admin@example:/config/interface/lag0/> set lag lacp system-priority 100
+
+
+LACP mode supports two operational modes:
+
+ - **active:** Initiates negotiation by sending LACPDUs (default)
+ - **passive:** Waits for peer to initiate negotiation
+
+> [!NOTE]
+> At least one end of the link must be in active mode for negotiation to occur.
+
+The LACP rate setting controls protocol timing:
+
+ - **slow:** LACPDUs sent every 30 seconds, with 90 second timeout (default)
+ - **fast:** LACPDUs sent every second, with 3 second timeout
+
+
+## Link Flapping
+
+To protect against link flapping, debounce timers can be configured to
+delay link qualification. Usually only the `up` delay is needed:
+
+admin@example:/config/interface/lag0/lag/link-monitor/> edit debounce
+admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set up 500
+admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set down 200
+
+
+## Operational Status, Overview
+
+Like other interfaces, link aggregates are also available in the general
+interfaces overview in the CLI admin-exec context. Here is the above
+static mode aggregate:
+
+admin@example:/> show interfaces
+
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+.
+.
+.
+lag0 lag UP static: balance-xor, hash: layer2
+│ ethernet UP 00:a0:85:00:02:00
+├ eth7 lag ACTIVE
+└ eth8 lag ACTIVE
+
+
+Same aggregate, but in LACP mode:
+
+admin@example:/> show interfaces
+
+lo ethernet UP 00:00:00:00:00:00
+ ipv4 127.0.0.1/8 (static)
+ ipv6 ::1/128 (static)
+.
+.
+.
+lag0 lag UP lacp: active, rate: fast (1s), hash: layer2
+│ ethernet UP 00:a0:85:00:02:00
+├ eth7 lag ACTIVE active, short_timeout, aggregating, in_sync, collecting, distributing
+└ eth8 lag ACTIVE active, short_timeout, aggregating, in_sync, collecting, distributing
+
+
+
+## Operational Status, Detail
+
+In addition to basic status shown in the interface overview, detailed
+LAG status can be inspected:
+
+admin@example:/> show interface lag0
+name : lag0
+index : 25
+mtu : 1500
+operational status : up
+physical address : 00:a0:85:00:02:00
+lag mode : static
+lag type : balance-xor
+lag hash : layer2
+link debounce up : 0 msec
+link debounce down : 0 msec
+ipv4 addresses :
+ipv6 addresses :
+in-octets : 0
+out-octets : 2142
+
+
+Same aggregate, but in LACP mode:
+
+admin@example:/> show interface lag0
+name : lag0
+index : 24
+mtu : 1500
+operational status : up
+physical address : 00:a0:85:00:02:00
+lag mode : lacp
+lag hash : layer2
+lacp mode : active
+lacp rate : fast (1s)
+lacp aggregate id : 1
+lacp system priority: 65535
+lacp actor key : 9
+lacp partner key : 9
+lacp partner mac : 00:a0:85:00:03:00
+link debounce up : 0 msec
+link debounce down : 0 msec
+ipv4 addresses :
+ipv6 addresses :
+in-octets : 100892
+out-octets : 111776
+
+
+Member ports provide additional status information:
+
+ - Link failure counter: number of detected link failures
+ - LACP state flags: various states of LACP negotiation:
+ - `active`: port is actively sending LACPDUs
+ - `short_timeout`: using fast rate (1s) vs. slow rate (30s)
+ - `aggregating`: port is allowed to aggregate in this LAG
+ - `in_sync`: port is synchronized with partner
+ - `collecting`: port is allowed to receive traffic
+ - `distributing`: port is allowed to send traffic
+ - `defaulted`: using default partner info (partner not responding)
+ - `expired`: partner info has expired (no LACPDUs received)
+ - Aggregator ID: unique identifier for this LAG group
+ - Actor state: LACP state flags for this port (local)
+ - Partner state: LACP state flags from the remote port
+
+Example member port status:
+
+admin@example:/> show interface eth7
+name : eth7
+index : 8
+mtu : 1500
+operational status : up
+physical address : 00:a0:85:00:02:00
+lag member : lag0
+lag member state : active
+lacp aggregate id : 1
+lacp actor state : active, short_timeout, aggregating, in_sync, collecting, distributing
+lacp partner state : active, short_timeout, aggregating, in_sync, collecting, distributing
+link failure count : 0
+ipv4 addresses :
+ipv6 addresses :
+in-octets : 473244
+out-octets : 499037
+
+
+
+## Example: Switch Uplink with LACP
+
+LACP mode provides the most robust operation, automatically negotiating
+the link aggregate and detecting configuration mismatches.
+
+A common use case is connecting a switch to an upstream device:
+
+admin@example:/> configure
+admin@example:/config/> edit interface lag0
+admin@example:/config/interface/lag0/> set lag mode lacp
+
+
+Enable fast LACP for quicker fail-over:
+
+admin@example:/config/interface/lag0/> set lag lacp rate fast
+
+
+Add uplink ports
+
+admin@example:/config/interface/lag0/> end
+admin@example:/config/> set interface eth7 lag-port lag lag0
+admin@example:/config/> set interface eth8 lag-port lag lag0
+
+
+Enable protection against "link flapping".
+
+admin@example:/config/interface/lag0/> edit lag link-monitor
+admin@example:/config/interface/lag0/lag/link-monitor/> edit debounce
+admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set up 500
+admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set down 200
+admin@example:/config/interface/lag0/lag/link-monitor/debounce/> top
+
+
+Add to bridge for switching
+
+admin@example:/config/interface/lag0/lag/link-monitor/debounce/> end
+admin@example:/config/> set interface lag0 bridge-port bridge br0
+admin@example:/config/> leave
+
+
+[^1]: `(source MAC XOR destination MAC XOR EtherType) MODULO num_links`
diff --git a/doc/networking.md b/doc/networking.md
index 6867d6d0..bbe10226 100644
--- a/doc/networking.md
+++ b/doc/networking.md
@@ -45,16 +45,16 @@ other traffic would be bridged as usual.
| **Type** | **Yang Model** | **Description** |
|----------|----------------------------|--------------------------------------------------------------|
-| bridge | infix-if-bridge | SW implementation of an IEEE 802.1Q bridge |
-| ip | ietf-ip, infix-ip | IP address to the subordinate interface |
-| vlan | infix-if-vlan | Capture all traffic belonging to a specific 802.1Q VID |
-| lag | infix-if-lag | Link aggregation, static and IEEE 802.3ad (LACP) |
-| lo | ietf-interfaces | Software loopback interface |
-| eth | ieee802-ethernet-interface | Physical Ethernet device/port. |
-| | infix-ethernet-interface | |
-| veth | infix-if-veth | Virtual Ethernet pair, typically one end is in a container |
-| *common* | ietf-interfaces, | Properties common to all interface types |
-| | infix-interfaces | |
+| [bridge](bridging.md) | infix-if-bridge | SW implementation of an IEEE 802.1Q bridge |
+| [ip](ip.md) | ietf-ip, infix-ip | IP address to the subordinate interface |
+| [vlan](ethernet.md#vlan-interfaces) | infix-if-vlan | Capture all traffic belonging to a specific 802.1Q VID |
+| [lag](lag.md) | infix-if-lag | Link aggregation, static and IEEE 802.3ad (LACP) |
+| lo | ietf-interfaces | Software loopback interface |
+| [eth](ethernet.md#physical-ethernet-interfaces) | ieee802-ethernet-interface | Physical Ethernet device/port |
+| | infix-ethernet-interface | |
+| [veth](ethernet.md#veth-pairs) | infix-if-veth | Virtual Ethernet pair, typically one end is in a container |
+| [*common*](iface.md) | ietf-interfaces, | Properties common to all interface types |
+| | infix-interfaces | |
## Data Plane
@@ -81,1704 +81,5 @@ used on the left hand side can also be used freely on the right hand
side as well.
-### General
-
-General interface settings include `type`, `enable`, custom MAC address,
-and text `description`. Other settings have their own sections, below.
-
-The `type` is important to set when configuring devices remotely because
-unlike the CLI, a NETCONF or RESTCONF session cannot guess the interface
-type for you. The operating system provides an override of the
-available interface types.
-
-An `enabled` interface can be inspected using the operational datastore,
-nodes `admin-state` and `oper-state` show the status, . Possible values
-are listed in the YANG model.
-
-The `custom-phys-address` can be used to set an interface's MAC address.
-This is an extension to the ietf-interfaces YANG model, which defines
-`phys-address` as read-only[^4]. The following shows the different
-configuration options.
-
-The `description` is saved as Linux `ifalias` on an interface. It is a
-free-form string, useful for describing purpose or just adding comments
-for remote debugging, e.g., using the operational datastore.
-
-> [!CAUTION]
-> There is no validation or safety checks performed by the system when
-> using `custom-phys-address`. In particular the `offset` variant can
-> be dangerous to use -- pay attention to the meaning of bits in the
-> upper-most octet: local bit, multicast/group, etc.
-
-#### Fixed custom MAC
-
-Use a fixed custom MAC address when the interface must present a
-specific, deterministic identity on the network. This option bypasses
-any chassis-derived logic and applies the configured address verbatim.
-
-admin@example:/config/> edit interface veth0a
-admin@example:/config/interface/veth0a/> set custom-phys-address static 00:ab:00:11:22:33
-
-=> 00:ab:00:11:22:33
-
-
-#### Chassis MAC
-
-Chassis MAC, sometimes also referred to as base MAC. In these two
-examples it is `00:53:00:c0:ff:ee`.
-
-admin@example:/config/> edit interface veth0a
-admin@example:/config/interface/veth0a/> set custom-phys-address chassis
-
-=> 00:53:00:c0:ff:ee
-
-
-#### Chassis MAC, with offset
-
-When constructing a derived address it is recommended to set the locally
-administered bit. Same chassis MAC as before.
-
-admin@example:/config/> edit interface veth0a
-admin@example:/config/interface/veth0a/> set custom-phys-address chassis offset 02:00:00:00:00:02
-
-=> 02:53:00:c0:ff:f0
-
-
-### Bridging
-
-This is the most central part of the system. A bridge is a switch, and
-a switch is a bridge. In Linux, setting up a bridge with ports
-connected to physical switch fabric, means you manage the actual switch
-fabric!
-
-#### MAC Bridge
-
-In Infix ports are by default not switch ports, unless the customer
-specific factory config sets it up this way. To enable switching, with
-offloading if you have a switch chipset, between ports you create a
-bridge and then add ports to that bridge. Like this:
-
-admin@example:/> configure
-admin@example:/config/> edit interface br0
-admin@example:/config/interface/br0/> up
-admin@example:/config/> set interface eth0 bridge-port bridge br0
-admin@example:/config/> set interface eth1 bridge-port bridge br0
-admin@example:/config/> leave
-
-
-Here we add two ports to bridge `br0`: `eth0` and `eth1`.
-
-> [!TIP]
-> The CLI has several built-in helpers governed by convention. E.g.,
-> naming bridges `brN`, where `N` is a number, the type is *inferred*
-> automatically and unlocks all bridge features. Other conventions are
-> `vethNA`, where `N` is a number and `A` is a letter ('a' for access
-> port and 'b' for bridge side is common), and `ethN.M` for VLAN M on
-> top of `ethN`, or `dockerN` for a IP masquerading container bridge.
->
-> Note, this inference only works with the CLI, configuring networking
-> over NETCONF or RESTCONF requires setting the type explicitly.
-
-
-
-It is possible to create multiple MAC bridges, however, it is
-currently[^5] _not recommended_ to use more than one MAC bridge on
-products with Marvell LinkStreet switching ASICs. A VLAN filtering
-bridge should be used instead.
-
-#### VLAN Filtering Bridge
-
-By default bridges in Linux do not filter based on VLAN tags. This can
-be enabled when creating a bridge by adding a port to a VLAN as a tagged
-or untagged member. Use the port default VID (PVID) setting to control
-VLAN association for traffic ingressing a port untagged (default PVID:
-1).
-
-admin@example:/config/> edit interface br0
-admin@example:/config/interface/br0/> up
-admin@example:/config/> set interface eth0 bridge-port bridge br0
-admin@example:/config/> set interface eth0 bridge-port pvid 10
-admin@example:/config/> set interface eth1 bridge-port bridge br0
-admin@example:/config/> set interface eth1 bridge-port pvid 20
-admin@example:/config/> edit interface br0
-admin@example:/config/interface/br0/> set bridge vlans vlan 10 untagged eth0
-admin@example:/config/interface/br0/> set bridge vlans vlan 20 untagged eth1
-
-
-This sets `eth0` as an untagged member of VLAN 10 and `eth1` as an
-untagged member of VLAN 20. Switching between these ports is thus
-prohibited.
-
-
-
-To terminate a VLAN in the switch itself, either for switch management
-or for routing, the bridge must become a (tagged) member of the VLAN.
-
-admin@example:/config/interface/br0/> set bridge vlans vlan 10 tagged br0
-admin@example:/config/interface/br0/> set bridge vlans vlan 20 tagged br0
-
-
-To route or to manage via a VLAN, a VLAN interface needs to be created
-on top of the bridge, see section [VLAN Interfaces](#vlan-interfaces)
-below for more on this topic.
-
-> [!NOTE]
-> In some use-cases only a single management VLAN on the bridge is used.
-> For the example above, if the bridge itself is an untagged member only
-> in VLAN 10, IP addresses can be set directly on the bridge without the
-> need for dedicated VLAN interfaces on top of the bridge.
-
-
-#### Multicast Filtering and Snooping
-
-Multicast filtering in the bridge is handled by the bridge itself. It
-can filter both IP multicast and MAC multicast. For IP multicast it
-also supports "snooping", i.e., IGMP and MLD, to automatically reduce
-the broadcast effects of multicast. See the next section for a summary
-of the [terminology used](#terminology-abbreviations).
-
-> [!IMPORTANT]
-> Currently there is no way to just enable multicast filtering without
-> also enabling snooping. This may change in the future, in which case
-> a `filtering` enabled setting will be made available along with the
-> existing `snooping` setting.
-
-When creating your bridge you must decide if you need a VLAN filtering
-bridge or a plain bridge (see previous section). Multicast filtering is
-supported for either, but take note that it must be enabled and set up
-per VLAN when VLAN filtering is enabled -- there are no global multicast
-settings in this operating mode.
-
-In the following example we have a regular 8-port bridge without VLAN
-filtering. We focus on the multicast specific settings:
-
-admin@example:/> configure
-admin@example:/config/> edit interface br0
-admin@example:/config/interface/br0/> set bridge multicast snooping
-admin@example:/config/interface/br0/> set ipv4 address 192.168.2.1 prefix-length 24
-admin@example:/config/interface/br0/> leave
-admin@example:/> copy running-config startup-config
-
-
-Here we enable snooping and set a static IPv4 address so that the switch
-can take part in IGMP querier elections. (MLD querier election
-currently not supported.) We can inspect the current state:
-
-admin@example:/> show ip multicast
-Multicast Overview
-Query Interval (default): 125 sec
-Router Timeout : 255
-Fast Leave Ports :
-Router Ports :
-Flood Ports : e0, e1, e2, e3, e4, e5, e6, e7
-
-
-br0 192.168.2.1 Up 125 None 3
-
-
-br0 224.1.1.1 e3, e2
-br0 ff02::6a br0
-
-
-This is a rather small LAN, so our bridge has already become the elected
-IGMP querier. We see it is ours because the timeout is `None`, and we
-recognize the IP address the system has detected, as ours. We can also
-see two ports that have joined the same IPv4 multicast group, 224.1.1.1,
-and one join from the system itself for the IPv6 group ff02::6a.
-
-Now, let us see what happens when we add another bridge, this time with
-VLAN filtering enabled. We skip the boring parts about how to move
-ports e4-e7 to `br1` and assign them to VLANs, and again, focus on the
-multicast bits only:
-
-admin@example:/> configure
-admin@example:/config/> edit interface br1
-admin@example:/config/interface/br1/> set bridge vlans vlan 1 multicast snooping
-admin@example:/config/interface/br1/> set bridge vlans vlan 2 multicast snooping
-admin@example:/config/interface/br1/> leave
-admin@example:/> copy running-config startup-config
-
-
-Let us see what we get:
-
-admin@example:/> show ip multicast
-Multicast Overview
-Query Interval (default): 125 sec
-Router Timeout : 255
-Fast Leave Ports : e5
-Router Ports : e1, e2, e5, e6, e7
-Flood Ports : e1, e2, e3, e4, e5, e6, e7, e8
-
-
-br0 192.168.2.1 Up 125 None 3
-br1 1 0.0.0.0 Up 125 None 3
-br1 2 0.0.0.0 Up 125 None 3
-
-
-br0 224.1.1.1 e2
-br0 ff02::fb br0
-br0 ff02::6a br0
-br0 ff02::1:ff00:0 br0
-br1 1 224.1.1.1 e5
-br1 2 224.1.1.1 e7
-br1 1 ff02::fb br1
-br1 1 ff02::1:ff00:0 br1
-
-
-In this setup we have a lot more going on. Multiple multicast router
-ports have been detected, and behind the scenes someone has also added
-an IGMP/MLD fast-leave port.
-
-##### Terminology & Abbreviations
-
- - **IGMP**: Internet Group Membership Protocol, multicast subscription
- for IPv4, for details see [RFC3376][]
- - **MLD**: Multicast Listener Discovery (Protocol), multicast
- subscription for IPv6, for details see [RFC3810][]
- - **Unknown/Unregistered multicast**: multicast groups that are *not*
- in the multicast forwarding database (MDB)
- - **Known/Registered multicast**: multicast groups that *are* in the
- multicast forwarding database (MDB)
- - **MDB**: the multicast forwarding database, consists of filters for
- multicast groups, directing where multicast is allowed to egress. A
- filter entry consists of a group and a port list. The bridge filters
- with a unique database per VLAN, in the same was as the unicast FDB
- - **Join/Leave**: the terminology used in earlier versions of the two
- protocols to subscribe and unsubscribe to a multicast group. For
- more information, see *Membership Report*
- - **Membership Report** A membership report is sent by end-devices and
- forwarded by switches to the elected querier on the LAN. They
- consist of multiple "join" and "leave" operations on groups. They
- can also, per group, list which senders to allow or block. Switches
- usually only support the group subscription, and even more common
- also only support filtering on the MAC level[^3]
- - **Querier election**: the process of determining who is the elected
- IGMP/MLD querier on a LAN. Lowest numerical IP address wins, the
- special address 0.0.0.0 (proxy querier) never wins
- - **Proxy querier**: when no better querier exists on a LAN, one or
- more devices can send proxy queries with source address 0.0.0.0 (or
- :: for IPv6). See **Query Interval**, below, why this is a good
- thing
- - **Query interval**: the time in seconds between two queries from an
- IGMP/MLD querier. It is not uncommon that end-devices do not send
- their membership reports unless they first hear a query
- - **Fast Leave**: set on a bridge port to ensure multicast is pruned as
- quickly as possible when a "leave" membership report is received. In
- effect, this option marks the port as directly connected to an
- end-device. When not set (default), a query with timeout is first
- sent to ensure no unintentional loss of multicast is incurred
- - **Router port**: can be both configured statically and detected at
- runtime based on connected devices, usually multicast routers. On
- a router port *all* multicast is forwarded, both known and unknown
- - **Flood port**: set on a bridge port (default: enabled) to ensure
- all *unknown* multicast is forwarded
- - **Router timeout**: the time in seconds until a querier is deemed to
- have been lost and another device (switch/router) takes over. In the
- tables shown above, a *None* timeout is declared when the current
- device is the active querier
-
-> [!TIP]
-> The reason why multicast flooding is enabled by default is to ensure
-> safe co-existence with MAC multicast, which is common in industrial
-> networks. It also allows end devices that do not know of IGMP/MLD to
-> communicate over multicast as long as the group they have chosen is
-> not used by other IGMP/MLD aware devices on the LAN.
->
-> As soon as an IGMP/MLD membership report to "join" a group is received
-> the group is added to the kernel MDB and forwarding to other ports
-> stop. The only exception to this rule is multicast router ports.
->
-> If your MAC multicast forwarding is not working properly, it may be
-> because an IP multicast group maps to the same MAC address. Please
-> see [RFC 1112][RFC1112] for details. Use static multicast router
-> ports, or static multicast MAC filters, to mitigate.
-
-[RFC1112]: https://www.rfc-editor.org/rfc/rfc1112.html
-[RFC3376]: https://www.rfc-editor.org/rfc/rfc3376.html
-[RFC3810]: https://www.rfc-editor.org/rfc/rfc3810.html
-
-#### Forwarding of IEEE Reserved Group Addresses
-
-Addresses in the range `01:80:C2:00:00:0X` are used by various bridge
-signaling protocols, and are not forwarded by default. Still, it is
-sometimes useful to let the bridge forward such packets, this can be
-done by specifying protocol names or the last address *nibble* as
-decimal value `0..15`:
-
-admin@example:/config/> edit interface br0 bridge
-admin@example:/config/interface/br0/bridge/> set ieee-group-forward # Tap the ? key for alternatives
- [0..15] List of IEEE link-local protocols to forward, e.g., STP, LLDP
- dot1x 802.1X Port-Based Network Access Control.
- lacp 802.3 Slow Protocols, e.g., LACP.
- lldp 802.1AB Link Layer Discovery Protocol (LLDP).
- stp Spanning Tree (STP/RSPT/MSTP).
-admin@example:/config/interface/br0/bridge/> set ieee-group-forward
-
-
-The following example configures bridge *br0* to forward LLDP packets.
-
-admin@example:/config/interface/br0/bridge/> set ieee-group-forward lldp
-admin@example:/config/interface/br0/bridge/>
-
-
-
-### Link Aggregation
-
-A link aggregate, or *lag*, allows multiple physical interfaces to be
-combined into a single logical interface, providing increased bandwidth
-(in some cases) and redundancy (primarily). Two modes of qualifying lag
-member ports are available:
-
- 1. **static**: Active members selected based on link status (carrier)
- 2. **lacp:** IEEE 802.3ad Link Aggregation Control Protocol
-
-In LACP mode, LACPDUs are exchanged by the link partners to qualify each
-lag member, while in static mode only carrier is used. This additional
-exchange in LACP ensures traffic can be forwarded in both directions.
-
-Traffic distribution, for both modes, across the active lag member ports
-is determined by the hash policy[^1]. It uses an XOR of the source,
-destination MAC addresses and the EtherType field. This, IEEE
-802.3ad-compliant, algorithm will place all traffic to a particular
-network peer on the same link. Meaning there is no increased bandwidth
-for communication between two specific devices.
-
-> [!TIP]
-> Similar to other interface types, naming your interface `lagN`, where
-> `N` is a number, allows the CLI to automatically infer the interface
-> type as LAG.
-
-
-#### Basic Configuration
-
-Creating a link aggregate interface and adding member ports:
-
-admin@example:/> configure
-admin@example:/config/> edit interface lag0
-admin@example:/config/interface/lag0/> set lag mode static
-admin@example:/config/interface/lag0/> end
-admin@example:/config/> set interface eth7 lag-port lag lag0
-admin@example:/config/> set interface eth8 lag-port lag lag0
-admin@example:/config/> leave
-
-
-A static lag responds only to link (carrier) changes of member ports.
-E.g., in this example egressing traffic is continuously distributed over
-the two links until link down on one link is detected, triggering all
-traffic to be steered to the sole remaining link.
-
-
-#### LACP Configuration
-
-LACP mode provides dynamic negotiation of the link aggregate. Key
-settings include:
-
-admin@example:/> configure
-admin@example:/config/> edit interface lag0
-admin@example:/config/interface/lag0/> set lag mode lacp
-admin@example:/config/interface/lag0/> set lag lacp mode passive
-admin@example:/config/interface/lag0/> set lag lacp rate fast
-admin@example:/config/interface/lag0/> set lag lacp system-priority 100
-
-
-LACP mode supports two operational modes:
-
- - **active:** Initiates negotiation by sending LACPDUs (default)
- - **passive:** Waits for peer to initiate negotiation
-
-> [!NOTE]
-> At least one end of the link must be in active mode for negotiation to occur.
-
-The LACP rate setting controls protocol timing:
-
- - **slow:** LACPDUs sent every 30 seconds, with 90 second timeout (default)
- - **fast:** LACPDUs sent every second, with 3 second timeout
-
-
-#### Link Flapping
-
-To protect against link flapping, debounce timers can be configured to
-delay link qualification. Usually only the `up` delay is needed:
-
-admin@example:/config/interface/lag0/lag/link-monitor/> edit debounce
-admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set up 500
-admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set down 200
-
-
-#### Operational Status, Overview
-
-Like other interfaces, link aggregates are also available in the general
-interfaces overview in the CLI admin-exec context. Here is the above
-static mode aggregate:
-
-admin@example:/> show interfaces
-
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-.
-.
-.
-lag0 lag UP static: balance-xor, hash: layer2
-│ ethernet UP 00:a0:85:00:02:00
-├ eth7 lag ACTIVE
-└ eth8 lag ACTIVE
-
-
-Same aggregate, but in LACP mode:
-
-admin@example:/> show interfaces
-
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-.
-.
-.
-lag0 lag UP lacp: active, rate: fast (1s), hash: layer2
-│ ethernet UP 00:a0:85:00:02:00
-├ eth7 lag ACTIVE active, short_timeout, aggregating, in_sync, collecting, distributing
-└ eth8 lag ACTIVE active, short_timeout, aggregating, in_sync, collecting, distributing
-
-
-
-#### Operational Status, Detail
-
-In addition to basic status shown in the interface overview, detailed
-LAG status can be inspected:
-
-admin@example:/> show interface lag0
-name : lag0
-index : 25
-mtu : 1500
-operational status : up
-physical address : 00:a0:85:00:02:00
-lag mode : static
-lag type : balance-xor
-lag hash : layer2
-link debounce up : 0 msec
-link debounce down : 0 msec
-ipv4 addresses :
-ipv6 addresses :
-in-octets : 0
-out-octets : 2142
-
-
-Same aggregate, but in LACP mode:
-
-admin@example:/> show interface lag0
-name : lag0
-index : 24
-mtu : 1500
-operational status : up
-physical address : 00:a0:85:00:02:00
-lag mode : lacp
-lag hash : layer2
-lacp mode : active
-lacp rate : fast (1s)
-lacp aggregate id : 1
-lacp system priority: 65535
-lacp actor key : 9
-lacp partner key : 9
-lacp partner mac : 00:a0:85:00:03:00
-link debounce up : 0 msec
-link debounce down : 0 msec
-ipv4 addresses :
-ipv6 addresses :
-in-octets : 100892
-out-octets : 111776
-
-
-Member ports provide additional status information:
-
- - Link failure counter: number of detected link failures
- - LACP state flags: various states of LACP negotiation:
- - `active`: port is actively sending LACPDUs
- - `short_timeout`: using fast rate (1s) vs. slow rate (30s)
- - `aggregating`: port is allowed to aggregate in this LAG
- - `in_sync`: port is synchronized with partner
- - `collecting`: port is allowed to receive traffic
- - `distributing`: port is allowed to send traffic
- - `defaulted`: using default partner info (partner not responding)
- - `expired`: partner info has expired (no LACPDUs received)
- - Aggregator ID: unique identifier for this LAG group
- - Actor state: LACP state flags for this port (local)
- - Partner state: LACP state flags from the remote port
-
-Example member port status:
-
-admin@example:/> show interface eth7
-name : eth7
-index : 8
-mtu : 1500
-operational status : up
-physical address : 00:a0:85:00:02:00
-lag member : lag0
-lag member state : active
-lacp aggregate id : 1
-lacp actor state : active, short_timeout, aggregating, in_sync, collecting, distributing
-lacp partner state : active, short_timeout, aggregating, in_sync, collecting, distributing
-link failure count : 0
-ipv4 addresses :
-ipv6 addresses :
-in-octets : 473244
-out-octets : 499037
-
-
-
-#### Example: Switch Uplink with LACP
-
-LACP mode provides the most robust operation, automatically negotiating
-the link aggregate and detecting configuration mismatches.
-
-A common use case is connecting a switch to an upstream device:
-
-admin@example:/> configure
-admin@example:/config/> edit interface lag0
-admin@example:/config/interface/lag0/> set lag mode lacp
-
-
-Enable fast LACP for quicker fail-over:
-
-admin@example:/config/interface/lag0/> set lag lacp rate fast
-
-
-Add uplink ports
-
-admin@example:/config/interface/lag0/> end
-admin@example:/config/> set interface eth7 lag-port lag lag0
-admin@example:/config/> set interface eth8 lag-port lag lag0
-
-
-Enable protection against "link flapping".
-
-admin@example:/config/interface/lag0/> edit lag link-monitor
-admin@example:/config/interface/lag0/lag/link-monitor/> edit debounce
-admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set up 500
-admin@example:/config/interface/lag0/lag/link-monitor/debounce/> set down 200
-admin@example:/config/interface/lag0/lag/link-monitor/debounce/> top
-
-
-Add to bridge for switching
-
-admin@example:/config/interface/lag0/lag/link-monitor/debounce/> end
-admin@example:/config/> set interface lag0 bridge-port bridge br0
-admin@example:/config/> leave
-
-
-
-### VLAN Interfaces
-
-Creating a VLAN can be done in many ways. This section assumes VLAN
-interfaces created atop another Linux interface. E.g., the VLAN
-interfaces created on top of the Ethernet interface or bridge in the
-picture below.
-
-
-
-A VLAN interface is basically a filtering abstraction. When you run
-`tcpdump` on a VLAN interface you will only see the frames matching the
-VLAN ID of the interface, compared to *all* the VLAN IDs if you run
-`tcpdump` on the lower-layer interface.
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0.20
-admin@example:/config/interface/eth0.20/> show
-type vlan;
-vlan {
- tag-type c-vlan;
- id 20;
- lower-layer-if eth0;
-}
-admin@example:/config/interface/eth0.20/> leave
-
-
-The example below assumes bridge br0 is already created, see [VLAN
-Filtering Bridge](#vlan-filtering-bridge).
-
-admin@example:/> configure
-admin@example:/config/> edit interface vlan10
-admin@example:/config/interface/vlan10/> set vlan id 10
-admin@example:/config/interface/vlan10/> set vlan lower-layer-if br0
-admin@example:/config/interface/vlan10/> leave
-
-
-As conventions, a VLAN interface for VID 20 on top of an Ethernet
-interface *eth0* is named *eth0.20*, and a VLAN interface for VID 10 on
-top of a bridge interface *br0* is named *vlan10*.
-
-> [!NOTE]
-> If you name your VLAN interface `foo0.N` or `vlanN`, where `N` is a
-> number, the CLI infers the interface type automatically.
-
-
-### Physical Ethernet Interfaces
-
-#### Ethernet Settings and Status
-
-Physical Ethernet interfaces provide low-level settings for speed/duplex as
-well as packet status and [statistics](#ethernet-statistics).
-
-By default, Ethernet interfaces defaults to auto-negotiating
-speed/duplex modes, advertising all speed and duplex modes available.
-In the example below, the switch would by default auto-negotiate speed
-1 Gbit/s on port eth1 and 100 Mbit/s on port eth4, as those are the
-highest speeds supported by H1 and H2 respectively.
-
-
-
-The speed and duplex status for the links can be listed as shown
-below, assuming the link operational status is 'up'.
-
-admin@example:/> show interface eth1
-name : eth1
-index : 2
-mtu : 1500
-operational status : up
-auto-negotiation : on
-duplex : full
-speed : 1000
-physical address : 00:53:00:06:11:01
-ipv4 addresses :
-ipv6 addresses :
-in-octets : 75581
-out-octets : 43130
-...
-admin@example:/> show interface eth4
-name : eth4
-index : 5
-mtu : 1500
-operational status : up
-auto-negotiation : on
-duplex : full
-speed : 100
-physical address : 00:53:00:06:11:04
-ipv4 addresses :
-ipv6 addresses :
-in-octets : 75439
-out-octets : 550704
-...
-admin@example:/>
-
-
-#### Configuring fixed speed and duplex
-
-Auto-negotiation of speed/duplex mode is desired in almost all
-use-cases, but it is possible to disable auto-negotiation and specify
-a fixed speed and duplex mode.
-
-> [!IMPORTANT]
-> When setting a fixed speed and duplex mode, ensure both sides of the
-> link have matching configuration. If speed does not match, the link
-> will not come up. If duplex mode does not match, the result is
-> reported collisions and/or bad throughput.
-
-The example below configures port eth3 to fixed speed 100 Mbit/s
-half-duplex mode.
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth3 ethernet
-admin@example:/config/interface/eth3/ethernet/> set speed 0.1
-admin@example:/config/interface/eth3/ethernet/> set duplex half
-admin@example:/config/interface/eth3/ethernet/> set auto-negotiation enable false
-admin@example:/config/interface/eth3/ethernet/> show
-auto-negotiation {
- enable false;
-}
-duplex half;
-speed 0.1;
-admin@example:/config/interface/eth3/ethernet/> leave
-admin@example:/>
-
-
-Speed metric is in Gbit/s. Auto-negotiation needs to be disabled in
-order for fixed speed/duplex to apply. Only speeds `0.1`(100 Mbit/s)
-and `0.01` (10 Mbit/s) can be specified. 1 Gbit/s and higher speeds
-require auto-negotiation to be enabled.
-
-#### Ethernet statistics
-
-Ethernet packet statistics[^6] can be listed as shown below.
-
-admin@example:/> show interface eth1
-name : eth1
-index : 2
-mtu : 1500
-operational status : up
-auto-negotiation : on
-duplex : full
-speed : 1000
-physical address : 00:53:00:06:11:0a
-ipv4 addresses :
-ipv6 addresses :
-in-octets : 75581
-out-octets : 43130
-
-eth-in-frames : 434
-eth-in-multicast-frames : 296
-eth-in-broadcast-frames : 138
-eth-in-error-fcs-frames : 0
-eth-in-error-oversize-frames : 0
-eth-out-frames : 310
-eth-out-multicast-frames : 310
-eth-out-broadcast-frames : 0
-eth-out-good-octets : 76821
-eth-in-good-octets : 60598
-admin@example:/>
-
-
-
-### VETH Pairs
-
-A Virtual Ethernet (VETH) pair is basically a virtual Ethernet cable. A
-cable can be "plugged in" to a bridge and the other end can be given to
-a [container](container.md), or plugged into another bridge.
-
-The latter example is useful if you have multiple bridges in the system
-with different properties (VLAN filtering, IEEE group forwarding, etc.),
-but still want some way of communicating between these domains.
-
-admin@example:/> configure
-admin@example:/config/> edit interface veth0a
-admin@example:/config/interface/veth0a/> set veth peer veth0b
-admin@example:/config/interface/veth0a/> end
-admin@example:/config/> diff
-interfaces {
-+ interface veth0a {
-+ type veth;
-+ veth {
-+ peer veth0b;
-+ }
-+ }
-+ interface veth0b {
-+ type veth;
-+ veth {
-+ peer veth0a;
-+ }
-+ }
-}
-admin@example:/config/>
-
-
-> [!TIP]
-> This is another example of the automatic inference of the interface
-> type from the name. Any name can be used, but then you have to set
-> the interface type to `veth` manually.
-
-
-## Management Plane
-
-This section details IP Addresses And Other Per-Interface IP settings.
-
-Infix support several network interface types, each can be assigned one
-or more IP addresses, both IPv4 and IPv6 are supported. (There is no
-concept of a "primary" address.)
-
-
-
-### IPv4 Address Assignment
-
-Multiple address assignment methods are available:
-
-| **Type** | **Yang Model** | **Description** |
-|:---------- |:----------------- |:-------------------------------------------------------------- |
-| static | ietf-ip | Static assignment of IPv4 address, e.g., *10.0.1.1/24* |
-| link-local | infix-ip | Auto-assignment of IPv4 address in 169.254.x.x/16 range |
-| dhcp | infix-dhcp-client | Assignment of IPv4 address by DHCP server, e.g., *10.0.1.1/24* |
-
-> [!NOTE]
-> The DHCP address method is only available for *LAN* interfaces
-> (Ethernet, virtual Ethernet (veth), bridge, link aggregates, etc.)
-
-Supported DHCP (request) options, configurability (Cfg) and defaults,
-are listed below. Configurable options can be disabled on a per client
-interface basis, some options, like `clientid` and option 81, are
-possible to set the value of as well.
-
-| **Opt** | **Name** | **Cfg** | **Description** |
-|---------|-----------------------------|---------|-----------------------------------------------------|
-| 1 | `netmask` | No | Request IP address and netmask |
-| 3 | `router` | Yes | Default route(s), see also option 121 and 249 |
-| 6 | `dns-server` | Yes | DNS server(s), static ones take precedence |
-| 12 | `hostname` | Yes | DHCP cannot set hostname, only for informing server |
-| 15 | `domain` | Yes | Default domain name, for name resolution |
-| 28 | `broadcast` | Yes | Broadcast address, calculated if disabled |
-| 42 | `ntp-server` | Yes | NTP server(s), static ones take precedence |
-| 50 | `address` | Yes | Request (previously cached) address |
-| 61 | `client-id` | Yes | Default MAC address (and option 12) |
-| 81 | `fqdn` | Yes | Similar to option 12, request FQDN update in DNS |
-| 119 | `search` | Yes | Request domain search list |
-| 121 | `classless-static-route` | Yes | Classless static routes |
-| 249 | `ms-classless-static-route` | Yes | Microsoft static route, same as option 121 |
-| | | | |
-
-**Default:** `router`, `dns-server`, `domain`, `broadcast`, `ntp-server`, `search`,
- `address`, `classless-static-route`, `ms-classless-static-route`
-
-When configuring a DHCP client, ensure that the NTP client is enabled
-for the `ntp-server` DHCP option to be processed correctly. If the NTP
-client is not enabled, any NTP servers provided by the DHCP server will
-be ignored. For details on how to enable the NTP client, see the [NTP
-Client Configuration](system.md#ntp-client-configuration) section.
-
-> [!IMPORTANT]
-> Per [RFC3442][4], if the DHCP server returns both a Classless Static
-> Routes option (121) and Router option (3), the DHCP client *must*
-> ignore the latter.
-
-
-### IPv6 Address Assignment
-
-Multiple address assignment methods are available:
-
-| **Type** | **Yang Model** | **Description** |
-|:---------------- |:-------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------- |
-| static | ietf-ip | Static assignment of IPv6 address, e.g., *2001:db8:0:1::1/64* |
-| link-local | ietf-ip[^2] | (RFC4862) Auto-configured link-local IPv6 address (*fe80::0* prefix + interface identifier, e.g., *fe80::ccd2:82ff:fe52:728b/64*) |
-| global auto-conf | ietf-ip | (RFC4862) Auto-configured (stateless) global IPv6 address (prefix from router + interface identifier, e.g., *2001:db8:0:1:ccd2:82ff:fe52:728b/64* |
-| dhcp | infix-dhcpv6-client | Assignment of IPv6 address by DHCPv6 server, e.g., *2001:db8::42/128* |
-
-Both for *link-local* and *global auto-configuration*, it is possible
-to auto-configure using a random suffix instead of the interface
-identifier.
-
-> [!NOTE]
-> The DHCPv6 address method is only available for *LAN* interfaces
-> (Ethernet, virtual Ethernet (veth), bridge, link aggregates, etc.)
-
-Supported DHCPv6 (request) options, configurability (Cfg) and defaults,
-are listed below. Configurable options can be disabled on a per client
-interface basis, some options, like `client-id` and `client-fqdn`, are
-possible to set the value of as well.
-
-| **Opt** | **Name** | **Cfg** | **Description** |
-|---------|----------------------------|---------|--------------------------------------------------------|
-| 1 | `client-id` | Yes | Client identifier (DUID), auto-generated by default |
-| 2 | `server-id` | Yes | Server identifier (DUID) |
-| 23 | `dns-server` | Yes | DNS recursive name servers, static ones take precedence|
-| 24 | `domain-search` | Yes | Domain search list |
-| 25 | `ia-pd` | Yes | Prefix delegation for downstream networks |
-| 31 | `sntp-server` | Yes | Simple Network Time Protocol servers |
-| 32 | `information-refresh-time` | Yes | Refresh time for stateless DHCPv6 |
-| 39 | `client-fqdn` | Yes | Client FQDN, request DNS update from server |
-| 56 | `ntp-server` | Yes | NTP time servers, static ones take precedence |
-| | | | |
-
-**Default:** `dns-server`, `domain-search`, `ntp-server`
-
-DHCPv6 supports both **stateful** (address assignment) and **stateless**
-(information-only) modes:
-
-- **Stateful DHCPv6**: The server assigns IPv6 addresses to clients. This is
- the default mode when enabling the DHCPv6 client.
-- **Stateless DHCPv6**: Used with SLAAC (Stateless Address Autoconfiguration)
- when only configuration information (DNS, NTP, etc.) is needed. Enable with
- the `information-only` setting.
-
-When configuring a DHCPv6 client, ensure that the NTP client is enabled
-for the `ntp-server` DHCPv6 option to be processed correctly. If the
-NTP client is not enabled, any NTP servers provided by the DHCPv6 server
-will be ignored. For details on how to enable the NTP client, see the
-[NTP Client Configuration](system.md#ntp-client-configuration) section.
-
-### Examples
-
-
-
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv6 fe80::ff:fe00:0/64 (link-layer)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-To illustrate IP address configuration, the examples below uses a
-switch with a single Ethernet interface (eth0) and a loopback
-interface (lo). As shown above, these examples assume *eth0* has an
-IPv6 link-local address and *lo* has static IPv4 and IPv6 addresses by
-default.
-
-#### Static and link-local IPv4 addresses
-
-
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv4
-admin@example:/config/interface/eth0/ipv4/> set address 10.0.1.1 prefix-length 24
-admin@example:/config/interface/eth0/ipv4/> set autoconf
-admin@example:/config/interface/eth0/ipv4/> diff
-+interfaces {
-+ interface eth0 {
-+ ipv4 {
-+ address 10.0.1.1 {
-+ prefix-length 24;
-+ }
-+ autoconf;
-+ }
-+ }
-+}
-admin@example:/config/interface/eth0/ipv4/> leave
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv4 169.254.1.3/16 (random)
- ipv4 10.0.1.1/24 (static)
- ipv6 fe80::ff:fe00:0/64 (link-layer)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-As shown, the link-local IPv4 address is configured with `set autoconf`.
-The presence of the `autoconf` container enables IPv4 link-local address
-assignment. The resulting address (169.254.1.3/16) is of type *random*
-([ietf-ip.yang][2]).
-
-The IPv4LL client also supports a `request-address` setting which can be
-used to "seed" the client's starting address. If the address is free it
-will be used, otherwise it falls back to the default algorithm.
-
-admin@example:/config/interface/eth0/ipv4/> edit autoconf
-admin@example:/config/interface/eth0/ipv4/autoconf/> set request-address 169.254.1.2
-admin@example:/config/interface/eth0/ipv4/autoconf/> leave
-
-
-
-#### Use of DHCP for IPv4 address assignment
-
-
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv4
-admin@example:/config/interface/eth0/ipv4/> set dhcp
-admin@example:/config/interface/eth0/ipv4/> leave
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv4 10.1.2.100/24 (dhcp)
- ipv6 fe80::ff:fe00:0/64 (link-layer)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-The resulting address (10.1.2.100/24) is of type *dhcp*.
-
-To configure DHCP client options, such as sending a specific hostname to the
-server, you can specify options with values:
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv4 dhcp
-admin@example:/config/interface/eth0/ipv4/dhcp/> set option hostname value myhost
-admin@example:/config/interface/eth0/ipv4/dhcp/> show
-option hostname {
- value myhost;
-}
-admin@example:/config/interface/eth0/ipv4/dhcp/> leave
-admin@example:/>
-
-
-> [!TIP]
-> The special value `auto` can be used with the hostname option to
-> automatically use the configured system hostname.
-
-Other useful DHCP options include:
-
-- `client-id` - Send a specific client identifier to the server
-- `route-preference` - Set the administrative distance for DHCP-learned routes (default: 5)
-
-For advanced usage with vendor-specific options, see the YANG model.
-
-#### Use of DHCPv6 for IPv6 address assignment
-
-
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv6
-admin@example:/config/interface/eth0/ipv6/> set dhcp
-admin@example:/config/interface/eth0/ipv6/> leave
-admin@example:/> show interface
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv6 2001:db8::42/128 (dhcp)
- ipv6 fe80::ff:fe00:0/64 (link-layer)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-The resulting address (2001:db8::42/128) is of type *dhcp*.
-
-To configure DHCPv6 client options, such as requesting prefix delegation
-for downstream networks, you can specify options:
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv6 dhcp
-admin@example:/config/interface/eth0/ipv6/dhcp/> set option ia-pd
-admin@example:/config/interface/eth0/ipv6/dhcp/> set option dns-server
-admin@example:/config/interface/eth0/ipv6/dhcp/> show
-option dns-server;
-option ia-pd;
-admin@example:/config/interface/eth0/ipv6/dhcp/> leave
-admin@example:/>
-
-
-For stateless DHCPv6 (used with SLAAC to get only configuration information):
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv6 dhcp
-admin@example:/config/interface/eth0/ipv6/dhcp/> set information-only true
-admin@example:/config/interface/eth0/ipv6/dhcp/> show
-information-only true;
-option dns-server;
-option domain-search;
-admin@example:/config/interface/eth0/ipv6/dhcp/> leave
-admin@example:/>
-
-
-Other useful DHCPv6 options include:
-
-- `duid` - Set a specific DHCPv6 Unique Identifier (auto-generated by default)
-- `client-fqdn` - Request the server to update DNS records with client's FQDN
-- `route-preference` - Set the administrative distance for DHCPv6-learned routes (default: 5)
-
-For advanced usage with vendor-specific options, see the YANG model.
-
-#### Disabling IPv6 link-local address(es)
-
-The (only) way to disable IPv6 link-local addresses is by disabling IPv6
-on the interface.
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv6
-admin@example:/config/interface/eth0/ipv6/> set enabled false
-admin@example:/config/interface/eth0/ipv6/> leave
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-#### Static IPv6 address
-
-
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv6
-admin@example:/config/interface/eth0/ipv6/> set address 2001:db8::1 prefix-length 64
-admin@example:/config/interface/eth0/ipv6/> leave
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv6 2001:db8::1/64 (static)
- ipv6 fe80::ff:fe00:0/64 (link-layer)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-
-#### Stateless Auto-configuration of Global IPv6 Address
-
-
-
-Stateless address auto-configuration of global addresses is enabled by
-default. The address is formed by concatenating the network prefix
-advertised by the router (here 2001:db8:0:1::0/64) and the interface
-identifier. The resulting address is of type *link-layer*, as it is
-formed based on the interface identifier ([ietf-ip.yang][2]).
-
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv6 2001:db8:0:1:0:ff:fe00:0/64 (link-layer)
- ipv6 fe80::ff:fe00:0/64 (link-layer)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-Disabling auto-configuration of global IPv6 addresses can be done as shown
-below.
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv6
-admin@example:/config/interface/eth0/ipv6/> set autoconf create-global-addresses false
-admin@example:/config/interface/eth0/ipv6/> leave
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv6 fe80::ff:fe00:0/64 (link-layer)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-
-#### Random Link Identifiers for IPv6 Stateless Autoconfiguration
-
-
-
-By default, the auto-configured link-local and global IPv6 addresses
-are formed from a link-identifier based on the MAC address.
-
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv6 2001:db8:0:1:0:ff:fe00:0/64 (link-layer)
- ipv6 fe80::ff:fe00:0/64 (link-layer)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-To avoid revealing identity information in the IPv6 address, it is
-possible to specify use of a random identifier ([ietf-ip.yang][2] and
-[RFC8981][3]).
-
-admin@example:/> configure
-admin@example:/config/> edit interface eth0 ipv6
-admin@example:/config/interface/eth0/ipv6/> set autoconf create-temporary-addresses true
-admin@example:/config/interface/eth0/ipv6/> leave
-admin@example:/> show interfaces
-
-eth0 ethernet UP 02:00:00:00:00:00
- ipv6 2001:db8:0:1:b705:8374:638e:74a8/64 (random)
- ipv6 fe80::ad3d:b274:885a:9ffb/64 (random)
-lo ethernet UP 00:00:00:00:00:00
- ipv4 127.0.0.1/8 (static)
- ipv6 ::1/128 (static)
-admin@example:/>
-
-
-Both the link-local address (fe80::) and the global address (2001:)
-have changed type to *random*.
-
-
-### IPv4 forwarding
-
-To be able to route (static or dynamic) on the interface it is
-required to enable forwarding. This setting controls if packets
-received on this interface can be forwarded.
-
-admin@example:/config/> edit interface eth0
-admin@example:/config/interface/eth0/> set ipv4 forwarding
-admin@example:/config/interface/eth0/> leave
-admin@example:/>
-
-
-
-### IPv6 forwarding
-
-Due to how the Linux kernel manages IPv6 forwarding, we can not fully
-control it per interface via this setting like how IPv4 works. Instead,
-IPv6 forwarding is globally enabled when at least one interface enable
-forwarding, otherwise it is disabled.
-
-The following table shows the system IPv6 features that the `forwarding`
-setting control when it is *Enabled* or *Disabled:
-
-| **IPv6 Feature** | **Enabled** | **Disabled** |
-|:-----------------------------------------|:------------|:-------------|
-| IsRouter set in Neighbour Advertisements | Yes | No |
-| Transmit Router Solicitations | No | Yes |
-| Router Advertisements are ignored | Yes | Yes |
-| Accept Redirects | No | Yes |
-
-admin@example:/config/> edit interface eth0
-admin@example:/config/interface/eth0/> set ipv6 forwarding
-admin@example:/config/interface/eth0/> leave
-admin@example:/>
-
-
-
-## Routing support
-
-Currently supported YANG models:
-
-| **YANG Model** | **Description** |
-|:--------------------------|:--------------------------------|
-| ietf-routing | Base model for all other models |
-| ietf-ipv4-unicast-routing | Static IPv4 unicast routing |
-| ietf-ipv6-unicast-routing | Static IPv6 unicast routing |
-| ietf-ospf | OSPF routing |
-| ietf-rip | RIP routing |
-| infix-routing | Infix deviations and extensions |
-
-The base model, ietf-routing, is where all the other models hook in. It
-is used to set configuration and read operational status (RIB tables) in
-the other models.
-
-> [!NOTE]
-> The standard IETF routing models allows multiple instances, but Infix
-> currently *only support one instance* per routing protocol! In the
-> examples presented here, the instance name `default` is used.
-
-
-### IPv4 Static routes
-
-The standard IETF model for static routes reside under the `static`
-control plane protocol. For our examples we use the instance name
-`default`, you can use any name.
-
-For a route with destination 192.168.200.0/24 via 192.168.1.1:
-
-admin@example:/> configure
-admin@example:/config/> edit routing control-plane-protocol static name default ipv4
-admin@example:/config/routing/…/ipv4/> set route 192.168.200.0/24 next-hop next-hop-address 192.168.1.1
-admin@example:/config/routing/…/ipv4/> leave
-admin@example:/>
-
-
-For a "floating" static route with destination 10.0.0.0/16 via a backup
-router 192.168.1.1, using the highest possible distance:
-
-admin@example:/> configure
-admin@example:/config/> edit routing control-plane-protocol static name default ipv4
-admin@example:/config/routing/…/ipv4/> set route 10.0.0.0/16 next-hop next-hop-address 192.168.1.1 route-preference 254
-admin@example:/config/routing/…/ipv4/> leave
-admin@example:/>
-
-
-> [!TIP]
-> Remember to enable [IPv4 forwarding](#ipv4-forwarding) for the
-> interfaces you want to route between.
-
-
-### IPv6 Static routes
-
-admin@example:/> configure
-admin@example:/config/> edit routing control-plane-protocol static name default ipv6
-admin@example:/config/routing/…/ipv6/> set route 2001:db8:3c4d:200::/64 next-hop next-hop-address 2001:db8:3c4d:1::1
-admin@example:/config/routing/…/ipv6/> leave
-admin@example:/>
-
-
-
-### OSPFv2 Routing
-
-The system supports OSPF dynamic routing for IPv4, i.e., OSPFv2. To
-enable OSPF and set one active interface in area 0:
-
-admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
-admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 enabled
-admin@example:/config/routing/…/ospf/> leave
-admin@example:/>
-
-
-> [!TIP]
-> Remember to enable [IPv4 forwarding](#ipv4-forwarding) for all the
-> interfaces you want to route between.
-
-
-#### OSPF area types
-
-In addition to *regular* OSPF areas, area types *NSSA* and *Stub* are
-also supported. To configure an NSSA area with summary routes:
-
-admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
-admin@example:/config/routing/…/ospf/> set area 0.0.0.1 area-type nssa-area
-admin@example:/config/routing/…/ospf/> set area 0.0.0.1 summary true
-admin@example:/config/routing/…/ospf/> leave
-admin@example:/>
-
-
-
-#### Bidirectional Forwarding Detection (BFD)
-
-It is possible to enable BFD per OSPF interface to speed up detection of
-link loss.
-
-admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
-admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 bfd enabled true
-admin@example:/config/routing/…/ospf/> leave
-admin@example:/>
-
-
-
-#### OSPF interface settings
-
-We have already seen how to enable OSPF per interface (*enabled true*)
-and BFD for OSPF per interface (*bfd enabled true*). These and other
-OSPF interface settings are done in context of an OSFP area, e.g., *area
-0.0.0.0*. Available commands can be listed using the `?` mark.
-
-admin@example:/config/routing/…/> edit ospf area 0.0.0.0
-admin@example:/config/routing/…/ospf/area/0.0.0.0/> edit interface e0
-admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set ?
- bfd BFD interface configuration.
- cost Interface's cost.
- dead-interval Interval after which a neighbor is declared down
- enabled Enables/disables the OSPF protocol on the interface.
- hello-interval Interval between Hello packets (seconds). It must
- interface-type Interface type.
- passive Enables/disables a passive interface. A passive
- retransmit-interval Interval between retransmitting unacknowledged Link
- transmit-delay Estimated time needed to transmit Link State Update
-admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set
-
-
-For example, setting the OSPF *interface type* to *point-to-point* for
-an Ethernet interface can be done as follows.
-
-admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set interface-type point-to-point
-admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/>
-
-
-#### OSPF global settings
-
-In addition to *area* and *interface* specific settings, OSPF provides
-global settings for route redistribution and OSPF router identifier.
-
-admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
-admin@example:/config/routing/…/ospf/> set ?
- area List of OSPF areas.
- default-route-advertise Distribute default route to network
- explicit-router-id Defined in RFC 2328. A 32-bit number
- redistribute Redistribute protocols into OSPF
-admin@example:/config/routing/…/ospf/> set
-
-
-- Explicit router ID: By default the router will pick an IP address
- from one of its OSPF interfaces as OSPF router ID. An explicit ID is
- used to get a deterministic behavior, e.g., `set explicit-router-id
- 1.1.1.1`.
-- Redistribution: `set redistribute static` and `set redistribute connected`
- can be used to include static or connected routes into the OSPF routing
- domain. These routes are redistributed as *external type-2* (E2)
- routes.
-- Advertising default route: An OSPF router can be made to distribute
- a default route into the OSPF domain by command `set
- default-route-advertise enabled`. This route is distributed as long
- as the router itself has an *active* default route in its routing
- table. By adding command `set default-route-advertise always` the
- router will distribute a default route even when it lacks a default
- route. The default route will be distributed as an *external type-2*
- (E2) route.
-
-
-#### Debug OSPFv2
-
-Using NETCONF and the YANG model *ietf-routing* it is possible to read
-the OSPF routing table, neighbors and more, that may be useful for
-debugging the OSPFv2 setup. The CLI has various OSPF status commands
-such as `show ospf neighbor`, `show ospf interface` and `show ospf
-routes`.
-
-admin@example:/> show ospf neighbor
-
-10.1.1.2 1 Full/- 3h46m59s 30.177s 10.1.1.2 e0:10.1.1.1 0 0 0
-10.1.1.3 1 Full/- 3h46m55s 34.665s 10.1.1.3 e1:10.1.1.1 0 0 0
-admin@example:/>
-
-
-For more detailed troubleshooting, OSPF debug logging can be enabled to
-capture specific protocol events. Debug messages are written to the
-routing log file (`/var/log/routing`).
-
-> [!CAUTION]
-> Debug logging significantly increases log output and may impact
-> performance. Only enable debug categories needed for troubleshooting,
-> and disable them when done.
-
-To enable specific OSPF debug categories:
-
-admin@example:/> configure
-admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf debug
-admin@example:/config/routing/…/ospf/debug/> set bfd true
-admin@example:/config/routing/…/ospf/debug/> set nsm true
-admin@example:/config/routing/…/ospf/debug/> leave
-admin@example:/>
-
-
-Available debug categories include:
-
-- `bfd`: BFD (Bidirectional Forwarding Detection) events
-- `packet`: Detailed packet debugging (all OSPF packets)
-- `ism`: Interface State Machine events
-- `nsm`: Neighbor State Machine events
-- `default-information`: Default route origination
-- `nssa`: Not-So-Stubby Area events
-
-All debug options are disabled by default. Refer to the `infix-routing`
-YANG model for the complete list of available debug options.
-
-To view current debug settings:
-
-admin@example:/> show running-config routing control-plane-protocol
-
-
-To disable all debug logging, simply delete the debug settings or set
-all options back to `false`:
-
-admin@example:/> configure
-admin@example:/config/> delete routing control-plane-protocol ospfv2 name default ospf debug
-admin@example:/config/> leave
-admin@example:/>
-
-
-
-### RIP Routing
-
-The system supports RIP dynamic routing for IPv4, i.e., RIPv2. To enable
-RIP and set active interfaces:
-
-admin@example:/config/> edit routing control-plane-protocol ripv2 name default rip
-admin@example:/config/routing/…/rip/> set interfaces interface e0
-admin@example:/config/routing/…/rip/> set interfaces interface e1
-admin@example:/config/routing/…/rip/> leave
-admin@example:/>
-
-
-> [!TIP]
-> Remember to enable [IPv4 forwarding](#ipv4-forwarding) for all the
-> interfaces you want to route between.
-
-
-#### RIP interface settings
-
-By default, interfaces send and receive RIPv2 packets. To control the
-RIP version per interface:
-
-admin@example:/config/routing/…/rip/> edit interfaces interface e0
-admin@example:/config/routing/…/rip/interfaces/interface/e0/> set send-version 1
-admin@example:/config/routing/…/rip/interfaces/interface/e0/> set receive-version 1-2
-admin@example:/config/routing/…/rip/interfaces/interface/e0/> leave
-admin@example:/>
-
-
-Valid version values are `1`, `2`, or `1-2` (both versions).
-
-To configure a passive interface (advertise network but don't send/receive
-RIP updates):
-
-admin@example:/config/routing/…/rip/> edit interfaces interface e0
-admin@example:/config/routing/…/rip/interfaces/interface/e0/> set passive
-admin@example:/config/routing/…/rip/interfaces/interface/e0/> leave
-admin@example:/>
-
-
-
-#### RIP global settings
-
-RIP supports redistribution of connected and static routes:
-
-admin@example:/config/routing/…/rip/> set redistribute connected
-admin@example:/config/routing/…/rip/> set redistribute static
-admin@example:/config/routing/…/rip/> leave
-admin@example:/>
-
-
-
-#### Debug RIPv2
-
-The CLI provides various RIP status commands:
-
-admin@example:/> show ip rip
-Default version control: send version 2, receive version 2
-
- e0 2 2
- e1 2 2
-
-Routing for Networks:
- e0
- e1
-
-Routing Information Sources:
-
- 10.0.1.2 0 0 120 00:00:16
-Distance: (default is 120)
-
-admin@example:/> show ip rip neighbor
-
-10.0.1.2 0 0
-admin@example:/>
-
-
-For more detailed troubleshooting, RIP debug logging can be enabled to
-capture specific protocol events. Debug messages are written to the
-routing log file (`/var/log/routing`).
-
-> [!CAUTION]
-> Debug logging significantly increases log output and may impact
-> performance. Only enable debug categories needed for troubleshooting,
-> and disable them when done.
-
-To enable specific RIP debug categories:
-
-admin@example:/> configure
-admin@example:/config/> edit routing control-plane-protocol ripv2 name default rip debug
-admin@example:/config/routing/…/rip/debug/> set events true
-admin@example:/config/routing/…/rip/debug/> set packet true
-admin@example:/config/routing/…/rip/debug/> leave
-admin@example:/>
-
-
-Available debug categories include:
-
-- `events`: RIP events (sending/receiving packets, timers, interface changes)
-- `packet`: Detailed packet debugging (packet dumps with origin and port)
-- `kernel`: Kernel routing table updates (route add/delete, interface updates)
-
-All debug options are disabled by default. Refer to the `infix-routing`
-YANG model for the complete list of available debug options.
-
-To view current debug settings:
-
-admin@example:/> show running-config routing control-plane-protocol
-
-
-To disable all debug logging, simply delete the debug settings or set
-all options back to `false`:
-
-admin@example:/> configure
-admin@example:/config/> delete routing control-plane-protocol ripv2 name default rip debug
-admin@example:/config/> leave
-admin@example:/>
-
-
-
-### View routing table
-
-The routing table can be inspected from the operational datastore, XPath
-`/routing/ribs`, using sysrepocfg, NETCONF/RESTCONF, or using the CLI.
-
-
-#### IPv4 routing table
-
-This CLI example shows the IPv4 routing table with a few connected
-routes and some routes learned from OSPF. See the next section for
-an explanation of route preferences (PREF).
-
-The `>` at the start of a line marks a selected route (in the IETF YANG
-model referred to as *active*), if there are more than one route with
-the same destination the `*` marks the next-hop used and installed in
-the kernel FIB (the YANG model refers to this as *installed*).
-
-admin@example:/> show ip route
-
->* 0.0.0.0/0 110/2 10.0.23.1 ospfv2 4h2m43s
->* 10.0.0.1/32 110/4000 10.0.13.1 ospfv2 4h2m43s
- 10.0.0.3/32 110/0 lo ospfv2 4h2m57s
->* 10.0.0.3/32 0/0 lo direct 4h2m58s
- 10.0.13.0/30 110/2000 e5 ospfv2 4h2m57s
->* 10.0.13.0/30 0/0 e5 direct 4h2m58s
- 10.0.23.0/30 110/1 e6 ospfv2 4h2m57s
->* 10.0.23.0/30 0/0 e6 direct 4h2m58s
- 192.168.3.0/24 110/1 e2 ospfv2 4h2m57s
->* 192.168.3.0/24 0/0 e2 direct 4h2m58s
-admin@example:/>
-
-
-
-#### IPv6 routing table
-
-This CLI example show the IPv6 routing table.
-
-admin@example:/> show ipv6 route
-
->* ::/0 1/0 2001:db8:3c4d:50::1 static 0h1m20s
->* 2001:db8:3c4d:50::/64 0/0 e6 direct 0h1m20s
->* 2001:db8:3c4d:200::1/128 0/0 lo direct 0h1m20s
- * fe80::/64 0/0 e7 direct 0h1m20s
- * fe80::/64 0/0 e6 direct 0h1m20s
- * fe80::/64 0/0 e5 direct 0h1m20s
- * fe80::/64 0/0 e4 direct 0h1m20s
- * fe80::/64 0/0 e3 direct 0h1m20s
- * fe80::/64 0/0 e2 direct 0h1m20s
->* fe80::/64 0/0 e1 direct 0h1m20s
-admin@example:/>
-
-
-
-#### Route Preference
-
-The operating system leverages FRRouting ([Frr][0]) as routing engine
-for both static and dynamic routing. Even routes injected from a DHCP
-client, and IPv4 link-local (IPv4) routes, are injected into Frr to let
-it weigh all routes before installing them into the kernel routing table
-(sometimes referred to as FIB).
-
-Routes have different weights made up from a *distance* and a *metric*.
-The kernel routing table only talks about *metric*, which unfortunately
-is **not the same** -- this is one of the reasons why the term *route
-preference* is used instead. It is recommended to use the CLI, or any
-of the other previously mentioned YANG based front-ends, to inspect the
-routing table.
-
-Default distances used (lower numeric value wins):
-
-| **Distance** | **Protocol** |
-|--------------|-----------------------------------------|
-| 0 | Kernel routes, i.e., connected routes |
-| 1 | Static routes |
-| 5 | DHCP routes |
-| 110 | OSPF |
-| 254 | IPv4LL (ZeroConf) device routes |
-| 255 | Route will not be used or redistributed |
-
-Hence, a route learned from OSPF may be overridden by a static route set
-locally. By default, even a route to the same destination, but with a
-different next-hop, learned from a DHCP server wins over an OSPF route.
-
-The distance used for static routes and DHCP routes can be changed by
-setting a different *routing preference* value.
-
-> [!NOTE]
-> The kernel metric is an unsigned 32-bit value, which is read by Frr as
-> (upper) 8 bits distance and 24 bits metric. But it does not write it
-> back to the kernel FIB this way, only selected routes are candidates
-> to be installed in the FIB by Frr.
-
-
-#### Source protocol
-
-The source protocol describes the origin of the route.
-
-| **Protocol** | **Description** |
-|:-------------|:----------------------------------------------------|
-| kernel | Added when setting a subnet address on an interface |
-| static | User created, learned from DHCP, or IPv4LL |
-| ospfv2 | Routes learned from OSPFv2 |
-
-The YANG model *ietf-routing* support multiple ribs but only two are
-currently supported, namely `ipv4` and `ipv6`.
-
-
[1]: https://www.rfc-editor.org/rfc/rfc8343
[2]: https://www.rfc-editor.org/rfc/rfc8344
-[3]: https://www.rfc-editor.org/rfc/rfc8981
-[4]: https://www.rfc-editor.org/rfc/rfc3442
-[0]: https://frrouting.org/
-
-[^1]: `(source MAC XOR destination MAC XOR EtherType) MODULO num_links`
-[^2]: Link-local IPv6 addresses are implicitly enabled when enabling
- IPv6. IPv6 can be enabled/disabled per interface in the
- [ietf-ip][2] YANG model.
-[^3]: For example, IPv4 groups are mapped to MAC multicast addresses by
- mapping the low-order 23-bits of the IP address in the low-order 23
- bits of the Ethernet address 01:00:5E:00:00:00. Meaning, more than
- one IP multicast group maps to the same MAC multicast group.
-[^4]: A YANG deviation was previously used to make it possible to set
- `phys-address`, but this has been replaced with the more flexible
- `custom-phys-address`.
-[^5]: MAC bridges on Marvell Linkstreet devices are currently limited to
- a single MAC database, this may be a problem if the same MAC address
- appears in different MAC bridges.
-[^6]: Ethernet counters are described in *ieee802-ethernet-interface.yang*
- and *infix-ethernet-interface.yang*. There is a dedicated document on
- [Ethernet Counters](eth-counters.md) that provide additional details
- on the statistics support.
diff --git a/doc/routing.md b/doc/routing.md
new file mode 100644
index 00000000..13573b45
--- /dev/null
+++ b/doc/routing.md
@@ -0,0 +1,453 @@
+# Routing
+
+Currently supported YANG models:
+
+| **YANG Model** | **Description** |
+|:--------------------------|:--------------------------------|
+| ietf-routing | Base model for all other models |
+| ietf-ipv4-unicast-routing | Static IPv4 unicast routing |
+| ietf-ipv6-unicast-routing | Static IPv6 unicast routing |
+| ietf-ospf | OSPF routing |
+| ietf-rip | RIP routing |
+| infix-routing | Infix deviations and extensions |
+
+The base model, ietf-routing, is where all the other models hook in. It
+is used to set configuration and read operational status (RIB tables) in
+the other models.
+
+> [!NOTE]
+> The standard IETF routing models allows multiple instances, but Infix
+> currently *only support one instance* per routing protocol! In the
+> examples presented here, the instance name `default` is used.
+
+
+## IPv4 Static routes
+
+The standard IETF model for static routes reside under the `static`
+control plane protocol. For our examples we use the instance name
+`default`, you can use any name.
+
+For a route with destination 192.168.200.0/24 via 192.168.1.1:
+
+admin@example:/> configure
+admin@example:/config/> edit routing control-plane-protocol static name default ipv4
+admin@example:/config/routing/…/ipv4/> set route 192.168.200.0/24 next-hop next-hop-address 192.168.1.1
+admin@example:/config/routing/…/ipv4/> leave
+admin@example:/>
+
+
+For a "floating" static route with destination 10.0.0.0/16 via a backup
+router 192.168.1.1, using the highest possible distance:
+
+admin@example:/> configure
+admin@example:/config/> edit routing control-plane-protocol static name default ipv4
+admin@example:/config/routing/…/ipv4/> set route 10.0.0.0/16 next-hop next-hop-address 192.168.1.1 route-preference 254
+admin@example:/config/routing/…/ipv4/> leave
+admin@example:/>
+
+
+> [!TIP]
+> Remember to enable [IPv4 forwarding](ip.md#ipv4-forwarding) for the
+> interfaces you want to route between.
+
+
+## IPv6 Static routes
+
+admin@example:/> configure
+admin@example:/config/> edit routing control-plane-protocol static name default ipv6
+admin@example:/config/routing/…/ipv6/> set route 2001:db8:3c4d:200::/64 next-hop next-hop-address 2001:db8:3c4d:1::1
+admin@example:/config/routing/…/ipv6/> leave
+admin@example:/>
+
+
+
+## OSPFv2 Routing
+
+The system supports OSPF dynamic routing for IPv4, i.e., OSPFv2. To
+enable OSPF and set one active interface in area 0:
+
+admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
+admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 enabled
+admin@example:/config/routing/…/ospf/> leave
+admin@example:/>
+
+
+> [!TIP]
+> Remember to enable [IPv4 forwarding](ip.md#ipv4-forwarding) for all the
+> interfaces you want to route between.
+
+
+### OSPF area types
+
+In addition to *regular* OSPF areas, area types *NSSA* and *Stub* are
+also supported. To configure an NSSA area with summary routes:
+
+admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
+admin@example:/config/routing/…/ospf/> set area 0.0.0.1 area-type nssa-area
+admin@example:/config/routing/…/ospf/> set area 0.0.0.1 summary true
+admin@example:/config/routing/…/ospf/> leave
+admin@example:/>
+
+
+
+### Bidirectional Forwarding Detection (BFD)
+
+It is possible to enable BFD per OSPF interface to speed up detection of
+link loss.
+
+admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
+admin@example:/config/routing/…/ospf/> set area 0.0.0.0 interface e0 bfd enabled true
+admin@example:/config/routing/…/ospf/> leave
+admin@example:/>
+
+
+
+### OSPF interface settings
+
+We have already seen how to enable OSPF per interface (*enabled true*)
+and BFD for OSPF per interface (*bfd enabled true*). These and other
+OSPF interface settings are done in context of an OSFP area, e.g., *area
+0.0.0.0*. Available commands can be listed using the `?` mark.
+
+admin@example:/config/routing/…/> edit ospf area 0.0.0.0
+admin@example:/config/routing/…/ospf/area/0.0.0.0/> edit interface e0
+admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set ?
+ bfd BFD interface configuration.
+ cost Interface's cost.
+ dead-interval Interval after which a neighbor is declared down
+ enabled Enables/disables the OSPF protocol on the interface.
+ hello-interval Interval between Hello packets (seconds). It must
+ interface-type Interface type.
+ passive Enables/disables a passive interface. A passive
+ retransmit-interval Interval between retransmitting unacknowledged Link
+ transmit-delay Estimated time needed to transmit Link State Update
+admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set
+
+
+For example, setting the OSPF *interface type* to *point-to-point* for
+an Ethernet interface can be done as follows.
+
+admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/> set interface-type point-to-point
+admin@example:/config/routing/…/ospf/area/0.0.0.0/interface/e0/>
+
+
+### OSPF global settings
+
+In addition to *area* and *interface* specific settings, OSPF provides
+global settings for route redistribution and OSPF router identifier.
+
+admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf
+admin@example:/config/routing/…/ospf/> set ?
+ area List of OSPF areas.
+ default-route-advertise Distribute default route to network
+ explicit-router-id Defined in RFC 2328. A 32-bit number
+ redistribute Redistribute protocols into OSPF
+admin@example:/config/routing/…/ospf/> set
+
+
+- Explicit router ID: By default the router will pick an IP address
+ from one of its OSPF interfaces as OSPF router ID. An explicit ID is
+ used to get a deterministic behavior, e.g., `set explicit-router-id
+ 1.1.1.1`.
+- Redistribution: `set redistribute static` and `set redistribute connected`
+ can be used to include static or connected routes into the OSPF routing
+ domain. These routes are redistributed as *external type-2* (E2)
+ routes.
+- Advertising default route: An OSPF router can be made to distribute
+ a default route into the OSPF domain by command `set
+ default-route-advertise enabled`. This route is distributed as long
+ as the router itself has an *active* default route in its routing
+ table. By adding command `set default-route-advertise always` the
+ router will distribute a default route even when it lacks a default
+ route. The default route will be distributed as an *external type-2*
+ (E2) route.
+
+
+### Debug OSPFv2
+
+Using NETCONF and the YANG model *ietf-routing* it is possible to read
+the OSPF routing table, neighbors and more, that may be useful for
+debugging the OSPFv2 setup. The CLI has various OSPF status commands
+such as `show ospf neighbor`, `show ospf interface` and `show ospf
+routes`.
+
+admin@example:/> show ospf neighbor
+
+10.1.1.2 1 Full/- 3h46m59s 30.177s 10.1.1.2 e0:10.1.1.1 0 0 0
+10.1.1.3 1 Full/- 3h46m55s 34.665s 10.1.1.3 e1:10.1.1.1 0 0 0
+admin@example:/>
+
+
+For more detailed troubleshooting, OSPF debug logging can be enabled to
+capture specific protocol events. Debug messages are written to the
+routing log file (`/var/log/routing`).
+
+> [!CAUTION]
+> Debug logging significantly increases log output and may impact
+> performance. Only enable debug categories needed for troubleshooting,
+> and disable them when done.
+
+To enable specific OSPF debug categories:
+
+admin@example:/> configure
+admin@example:/config/> edit routing control-plane-protocol ospfv2 name default ospf debug
+admin@example:/config/routing/…/ospf/debug/> set bfd true
+admin@example:/config/routing/…/ospf/debug/> set nsm true
+admin@example:/config/routing/…/ospf/debug/> leave
+admin@example:/>
+
+
+Available debug categories include:
+
+- `bfd`: BFD (Bidirectional Forwarding Detection) events
+- `packet`: Detailed packet debugging (all OSPF packets)
+- `ism`: Interface State Machine events
+- `nsm`: Neighbor State Machine events
+- `default-information`: Default route origination
+- `nssa`: Not-So-Stubby Area events
+
+All debug options are disabled by default. Refer to the `infix-routing`
+YANG model for the complete list of available debug options.
+
+To view current debug settings:
+
+admin@example:/> show running-config routing control-plane-protocol
+
+
+To disable all debug logging, simply delete the debug settings or set
+all options back to `false`:
+
+admin@example:/> configure
+admin@example:/config/> delete routing control-plane-protocol ospfv2 name default ospf debug
+admin@example:/config/> leave
+admin@example:/>
+
+
+
+## RIP Routing
+
+The system supports RIP dynamic routing for IPv4, i.e., RIPv2. To enable
+RIP and set active interfaces:
+
+admin@example:/config/> edit routing control-plane-protocol ripv2 name default rip
+admin@example:/config/routing/…/rip/> set interfaces interface e0
+admin@example:/config/routing/…/rip/> set interfaces interface e1
+admin@example:/config/routing/…/rip/> leave
+admin@example:/>
+
+
+> [!TIP]
+> Remember to enable [IPv4 forwarding](ip.md#ipv4-forwarding) for all the
+> interfaces you want to route between.
+
+
+### RIP interface settings
+
+By default, interfaces send and receive RIPv2 packets. To control the
+RIP version per interface:
+
+admin@example:/config/routing/…/rip/> edit interfaces interface e0
+admin@example:/config/routing/…/rip/interfaces/interface/e0/> set send-version 1
+admin@example:/config/routing/…/rip/interfaces/interface/e0/> set receive-version 1-2
+admin@example:/config/routing/…/rip/interfaces/interface/e0/> leave
+admin@example:/>
+
+
+Valid version values are `1`, `2`, or `1-2` (both versions).
+
+To configure a passive interface (advertise network but don't send/receive
+RIP updates):
+
+admin@example:/config/routing/…/rip/> edit interfaces interface e0
+admin@example:/config/routing/…/rip/interfaces/interface/e0/> set passive
+admin@example:/config/routing/…/rip/interfaces/interface/e0/> leave
+admin@example:/>
+
+
+
+### RIP global settings
+
+RIP supports redistribution of connected and static routes:
+
+admin@example:/config/routing/…/rip/> set redistribute connected
+admin@example:/config/routing/…/rip/> set redistribute static
+admin@example:/config/routing/…/rip/> leave
+admin@example:/>
+
+
+
+### Debug RIPv2
+
+The CLI provides various RIP status commands:
+
+admin@example:/> show ip rip
+Default version control: send version 2, receive version 2
+
+ e0 2 2
+ e1 2 2
+
+Routing for Networks:
+ e0
+ e1
+
+Routing Information Sources:
+
+ 10.0.1.2 0 0 120 00:00:16
+Distance: (default is 120)
+
+admin@example:/> show ip rip neighbor
+
+10.0.1.2 0 0
+admin@example:/>
+
+
+For more detailed troubleshooting, RIP debug logging can be enabled to
+capture specific protocol events. Debug messages are written to the
+routing log file (`/var/log/routing`).
+
+> [!CAUTION]
+> Debug logging significantly increases log output and may impact
+> performance. Only enable debug categories needed for troubleshooting,
+> and disable them when done.
+
+To enable specific RIP debug categories:
+
+admin@example:/> configure
+admin@example:/config/> edit routing control-plane-protocol ripv2 name default rip debug
+admin@example:/config/routing/…/rip/debug/> set events true
+admin@example:/config/routing/…/rip/debug/> set packet true
+admin@example:/config/routing/…/rip/debug/> leave
+admin@example:/>
+
+
+Available debug categories include:
+
+- `events`: RIP events (sending/receiving packets, timers, interface changes)
+- `packet`: Detailed packet debugging (packet dumps with origin and port)
+- `kernel`: Kernel routing table updates (route add/delete, interface updates)
+
+All debug options are disabled by default. Refer to the `infix-routing`
+YANG model for the complete list of available debug options.
+
+To view current debug settings:
+
+admin@example:/> show running-config routing control-plane-protocol
+
+
+To disable all debug logging, simply delete the debug settings or set
+all options back to `false`:
+
+admin@example:/> configure
+admin@example:/config/> delete routing control-plane-protocol ripv2 name default rip debug
+admin@example:/config/> leave
+admin@example:/>
+
+
+
+## View routing table
+
+The routing table can be inspected from the operational datastore, XPath
+`/routing/ribs`, using sysrepocfg, NETCONF/RESTCONF, or using the CLI.
+
+
+### IPv4 routing table
+
+This CLI example shows the IPv4 routing table with a few connected
+routes and some routes learned from OSPF. See the next section for
+an explanation of route preferences (PREF).
+
+The `>` at the start of a line marks a selected route (in the IETF YANG
+model referred to as *active*), if there are more than one route with
+the same destination the `*` marks the next-hop used and installed in
+the kernel FIB (the YANG model refers to this as *installed*).
+
+admin@example:/> show ip route
+
+>* 0.0.0.0/0 110/2 10.0.23.1 ospfv2 4h2m43s
+>* 10.0.0.1/32 110/4000 10.0.13.1 ospfv2 4h2m43s
+ 10.0.0.3/32 110/0 lo ospfv2 4h2m57s
+>* 10.0.0.3/32 0/0 lo direct 4h2m58s
+ 10.0.13.0/30 110/2000 e5 ospfv2 4h2m57s
+>* 10.0.13.0/30 0/0 e5 direct 4h2m58s
+ 10.0.23.0/30 110/1 e6 ospfv2 4h2m57s
+>* 10.0.23.0/30 0/0 e6 direct 4h2m58s
+ 192.168.3.0/24 110/1 e2 ospfv2 4h2m57s
+>* 192.168.3.0/24 0/0 e2 direct 4h2m58s
+admin@example:/>
+
+
+
+### IPv6 routing table
+
+This CLI example show the IPv6 routing table.
+
+admin@example:/> show ipv6 route
+
+>* ::/0 1/0 2001:db8:3c4d:50::1 static 0h1m20s
+>* 2001:db8:3c4d:50::/64 0/0 e6 direct 0h1m20s
+>* 2001:db8:3c4d:200::1/128 0/0 lo direct 0h1m20s
+ * fe80::/64 0/0 e7 direct 0h1m20s
+ * fe80::/64 0/0 e6 direct 0h1m20s
+ * fe80::/64 0/0 e5 direct 0h1m20s
+ * fe80::/64 0/0 e4 direct 0h1m20s
+ * fe80::/64 0/0 e3 direct 0h1m20s
+ * fe80::/64 0/0 e2 direct 0h1m20s
+>* fe80::/64 0/0 e1 direct 0h1m20s
+admin@example:/>
+
+
+
+### Route Preference
+
+The operating system leverages FRRouting ([Frr][0]) as routing engine
+for both static and dynamic routing. Even routes injected from a DHCP
+client, and IPv4 link-local (IPv4) routes, are injected into Frr to let
+it weigh all routes before installing them into the kernel routing table
+(sometimes referred to as FIB).
+
+Routes have different weights made up from a *distance* and a *metric*.
+The kernel routing table only talks about *metric*, which unfortunately
+is **not the same** -- this is one of the reasons why the term *route
+preference* is used instead. It is recommended to use the CLI, or any
+of the other previously mentioned YANG based front-ends, to inspect the
+routing table.
+
+Default distances used (lower numeric value wins):
+
+| **Distance** | **Protocol** |
+|--------------|-----------------------------------------|
+| 0 | Kernel routes, i.e., connected routes |
+| 1 | Static routes |
+| 5 | DHCP routes |
+| 110 | OSPF |
+| 254 | IPv4LL (ZeroConf) device routes |
+| 255 | Route will not be used or redistributed |
+
+Hence, a route learned from OSPF may be overridden by a static route set
+locally. By default, even a route to the same destination, but with a
+different next-hop, learned from a DHCP server wins over an OSPF route.
+
+The distance used for static routes and DHCP routes can be changed by
+setting a different *routing preference* value.
+
+> [!NOTE]
+> The kernel metric is an unsigned 32-bit value, which is read by Frr as
+> (upper) 8 bits distance and 24 bits metric. But it does not write it
+> back to the kernel FIB this way, only selected routes are candidates
+> to be installed in the FIB by Frr.
+
+
+### Source protocol
+
+The source protocol describes the origin of the route.
+
+| **Protocol** | **Description** |
+|:-------------|:----------------------------------------------------|
+| kernel | Added when setting a subnet address on an interface |
+| static | User created, learned from DHCP, or IPv4LL |
+| ospfv2 | Routes learned from OSPFv2 |
+
+The YANG model *ietf-routing* support multiple ribs but only two are
+currently supported, namely `ipv4` and `ipv6`.
+
+[0]: https://frrouting.org/
diff --git a/doc/scripting-prod.md b/doc/scripting-prod.md
index 4f115b26..3836e51e 100644
--- a/doc/scripting-prod.md
+++ b/doc/scripting-prod.md
@@ -350,5 +350,5 @@ the created configuration.
[1]: scripting-sysrepocfg.md#backup-configuration
[2]: scripting-sysrepocfg.md#restore-configuration
-[8]: networking.md#bridging
-[9]: networking.md#vlan-filtering-bridge
+[8]: bridging.md
+[9]: bridging.md#vlan-filtering-bridge
diff --git a/doc/tunnels.md b/doc/tunnels.md
index 4240c479..8d9d211f 100644
--- a/doc/tunnels.md
+++ b/doc/tunnels.md
@@ -55,7 +55,7 @@ admin@example:/>
```
GRETAP interfaces can be added to a bridge, bridging local and remote Ethernet
-segments. See the [Bridge Configuration](networking.md#bridging)
+segments. See the [Bridge Configuration](bridging.md)
for more on bridges.
### OSPF over GRE
@@ -99,7 +99,7 @@ admin@siteB:/>
Once configured, OSPF will establish a neighbor relationship through the
tunnel and exchange routes between the sites. For more info on OSPF
-configuration, see [OSPFv2 Routing](networking.md#ospfv2-routing).
+configuration, see [OSPFv2 Routing](routing.md#ospfv2-routing).
> [!NOTE]
> Consider adjusting MTU on the tunnel interface to account for GRE
diff --git a/doc/vpn-wireguard.md b/doc/vpn-wireguard.md
index 38ab1e76..1daa1360 100644
--- a/doc/vpn-wireguard.md
+++ b/doc/vpn-wireguard.md
@@ -141,7 +141,7 @@ for 192.168.2.0/24 through this peer.
> [!NOTE]
> When routing traffic to networks behind WireGuard peers, you also need
> to configure static routes pointing to the WireGuard interface. See
-> [Static Routes](networking.md#routing-support) for more information.
+> [Static Routes](routing.md) for more information.
## Peer Configuration and Key Bags
diff --git a/mkdocs.yml b/mkdocs.yml
index 36a3d858..cc03ed1e 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -28,7 +28,13 @@ nav:
- Upgrading: cli/upgrade.md
- Docker Containers: container.md
- Networking:
- - Network Configuration: networking.md
+ - Overview: networking.md
+ - Common Settings: iface.md
+ - Bridging: bridging.md
+ - Link Aggregation: lag.md
+ - Ethernet Interfaces: ethernet.md
+ - IP Addressing: ip.md
+ - Routing: routing.md
- Firewall Configuration: firewall.md
- Quality of Service: qos.md
- RMON Counters: eth-counters.md