DOC: Proofreading bonding.rst (#1721)

17 files changed, 737 insertions, 557 deletions

diff --git a/docs/_include/interface-address-with-dhcp.txt b/docs/_include/interface-address-with-dhcp.txt
index d454d051..c0afc203 100644
--- a/docs/_include/interface-address-with-dhcp.txt
+++ b/docs/_include/interface-address-with-dhcp.txt
@@ -2,18 +2,20 @@
   {{ var5 }} {{ var6 }} address <address | dhcp |
    dhcpv6>
 
-  Configure interface `<interface>` with one or more interface addresses.
-
-  * **address** can be specified multiple times as IPv4 and/or IPv6
-    address, e.g. 192.0.2.1/24 and/or 2001:db8::1/64
-  * **dhcp** interface address is received by DHCP from a DHCP server
-    on this segment.
-  * **dhcpv6** interface address is received by DHCPv6 from a DHCPv6
-    server on this segment.
-
-  .. note:: When using DHCP to retrieve IPv4 address and if local
-     customizations are needed, they should be possible using the enter and
-     exit hooks provided. The hook dirs are:
+  **Configure the interface with one or more IP addresses.**
+
+  The following options are available:
+
+  * **address:** Assign one or more IPv4 or IPv6 addresses to the interface. 
+    For example, use 192.0.2.1/24 for IPv4 or 2001:db8::1/64 for IPv6.
+  * **dhcp:** The interface obtains an IPv4 address from a DHCP server on the 
+    same network segment.
+  * **dhcpv6:** The interface obtains an IPv6 address from a DHCPv6 server on 
+    the same network segment.
+
+  .. note:: If the interface obtains an IPv4 address via DHCP, and specific 
+     adjustments are needed before/after the IP address is obtained, use the 
+     provided hook scripts:
 
      * ``/config/scripts/dhcp-client/pre-hooks.d/``
      * ``/config/scripts/dhcp-client/post-hooks.d/``
diff --git a/docs/_include/interface-description.txt b/docs/_include/interface-description.txt
index 064d9559..2de47fe3 100644
--- a/docs/_include/interface-description.txt
+++ b/docs/_include/interface-description.txt
@@ -1,11 +1,13 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} description <description>
 
-  Set a human readable, descriptive alias for this connection. Alias is used by
-  e.g. the :opcmd:`show interfaces` command or SNMP based monitoring tools.
+  **Configure a clear, descriptive alias for the interface.** 
+
+  This alias appears in the :opcmd:`show interfaces` command and SNMP-based 
+  monitoring tools.
 
   Example:
 
   .. code-block:: none
 
-    set interfaces {{ var0 }} {{ var1 }} {{ var2 }} {{ var4 }} {{ var5 }} {{ var7 }} description 'This is an awesome interface running on VyOS'
\ No newline at end of file
+    set interfaces {{ var0 }} {{ var1 }} {{ var2 }} {{ var4 }} {{ var5 }} {{ var7 }} description 'This is an interface running on VyOS.'
\ No newline at end of file
diff --git a/docs/_include/interface-dhcp-options.txt b/docs/_include/interface-dhcp-options.txt
index c5683ca3..6cc715e7 100644
--- a/docs/_include/interface-dhcp-options.txt
+++ b/docs/_include/interface-dhcp-options.txt
@@ -1,12 +1,14 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcp-options client-id <description>
 
-  :rfc:`2131` states: The client MAY choose to explicitly provide the identifier
-  through the 'client identifier' option. If the client supplies a 'client
-  identifier', the client MUST use the same 'client identifier' in all
-  subsequent messages, and the server MUST use that identifier to identify the
-  client.
-
+  **Configure a DHCP client identifier for the interface, as specified in** 
+  :rfc:`2131`.
+
+  The ``client-id`` is an identifier that the DHCP client sends to the DHCP 
+  server to uniquely identify itself for IP address assignment. By default, 
+  the client uses its MAC address. The ``<description>`` is a user-defined 
+  string that will be sent to the DHCP server as the DHCP client identifier.
+  
   Example:
 
   .. code-block:: none
@@ -16,8 +18,10 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcp-options host-name <hostname>
 
-  Instead of sending the real system hostname to the DHCP server, overwrite the
-  host-name with this given-value.
+  **Configure a specific hostname for the interface.**
+
+  Instead of the real hostname, the DHCP client will send the specific hostname 
+  to the DHCP server when requesting an IP address.
 
   Example:
 
@@ -28,13 +32,12 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcp-options vendor-class-id <vendor-id>
 
-  This option is used by some DHCP clients to identify the vendor type and
-  possibly the configuration of a DHCP client. The information is a string of
-  bytes whose contents are specific to the vendor and are not specified in a
-  standard.
+  **Configure the DHCP client to include a vendor-class identifier in its DHCP 
+  requests on this interface.**
 
-  The vendor-class-id option can be used to request a specific class of vendor
-  options from the server.
+  The vendor-class identifier is a vendor-specific byte string that enables 
+  the DHCP server to identify the device and, in some cases, provide 
+  configuration options. 
 
   Example:
 
@@ -45,8 +48,8 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcp-options no-default-route
 
-  Only request an address from the DHCP server but do not request a default
-  gateway.
+  **Configure the DHCP client to obtain an IP address, but ignore any default 
+  gateway provided by the DHCP server on this interface.**
 
   Example:
 
@@ -57,7 +60,8 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcp-options default-route-distance <distance>
 
-  Set the distance for the default gateway sent by the DHCP server.
+  **Configure the distance for the default route obtained from the DHCP server 
+  on this interface.** 
 
   Example:
 
@@ -68,11 +72,13 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcp-options reject <address>
 
-  Reject DHCP leases from a given address or range.
-  This is useful when a modem gives a local IP when first starting.
+  **Configure the DHCP client to reject the specific IP address or IP address 
+  range from the DHCP server on this interface.** 
 
-  * **address** can be specified multiple times,
-    e.g. 192.168.100.1 and/or 192.168.100.0/24
+  This is useful when a modem assigns a local IP address upon start. To reject 
+  multiple addresses, run this command multiple times with different values. 
+  You can reject individual addresses (192.168.100.1) or entire subnets 
+  (192.168.100.0/24).
 
   Example:
 
@@ -83,10 +89,13 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcp-options user-class <string>
 
-  This option is used by some DHCP clients as a way for users to specify
-  identifying information to the client. This can be used in a similar way to
-  the vendor-class-identifier option, but the value of the option is specified
-  by the user, not the vendor.
+  **Configure the DHCP client to send a specific user-class identifier in its 
+  DHCP requests on this interface.** 
+
+  The DHCP server can interpret this identifier and provide specific 
+  configuration options based on it (for example, default routes). 
+  The user-class value typically groups DHCP clients with similar configuration 
+  needs (for example, employees, guests, or printers).
 
   Example:
 
diff --git a/docs/_include/interface-dhcpv6-options.txt b/docs/_include/interface-dhcpv6-options.txt
index e584f36b..4f4a1869 100644
--- a/docs/_include/interface-dhcpv6-options.txt
+++ b/docs/_include/interface-dhcpv6-options.txt
@@ -1,11 +1,23 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcpv6-options duid <duid>
 
-  The DHCP unique identifier (DUID) is used by a client to get an IP address
-  from a DHCPv6 server. It has a 2-byte DUID type field, and a variable-length
-  identifier field up to 128 bytes. Its actual length depends on its type. The
-  server compares the DUID with its database and delivers configuration data
-  (address, lease times, DNS servers, etc.) to the client.
+  **Configure a specific** :abbr:`DUID (DHCP Unique Identifier)` **for the 
+  DHCPv6 client on this interface.**
+
+  The DUID is an identifier used by a DHCPv6 client to get an IPv6 address from 
+  a DHCPv6 server. It consists of a 2-byte type field, followed by a 
+  variable-length identifier field up to 128 bytes. The format of the identifier 
+  part depends on the DUID type:
+
+  * **DUID-LLT:** The most common type, which includes a hardware type, a timestamp, and a MAC address.
+  * **DUID-EN:** Is based on a vendor's enterprise number and a unique identifier assigned by the vendor.
+  * **DUID-LL:** Includes only a MAC address.
+
+  The DHCP server matches the DUID against its database and provides 
+  configuration data (such as address, lease times, DNS servers, etc.) 
+  to the DHCP client.
+
+  Example:
 
   .. code-block:: none
 
@@ -14,8 +26,12 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcpv6-options no-release
 
-  When no-release is specified, dhcp6c will avoid sending a release message on
-  client exit in order to prevent losing an assigned address or prefix.
+  **Configure the DHCP client not to send a release message when it stops 
+  running on this interface.**
+
+  This helps retain the assigned address or prefix. 
+
+  Example:
 
   .. code-block:: none
 
@@ -25,10 +41,13 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcpv6-options parameters-only
 
-  This statement specifies dhcp6c to only exchange informational configuration
-  parameters with servers. A list of DNS server addresses is an example of such
-  parameters. This statement is useful when the client does not need stateful
-  configuration parameters such as IPv6 addresses or prefixes.
+  **Enable a stateless DHCPv6 client mode on this interface.**
+
+  In stateless mode, the DHCPv6 client requests only stateless configuration 
+  parameters from the DHCP server (for example, DNS server addresses). It 
+  doesn’t request a stateful configuration, such as IPv6 addresses or prefixes.
+
+  Example:
 
   .. code-block:: none
 
@@ -37,8 +56,13 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcpv6-options rapid-commit
 
-  When rapid-commit is specified, dhcp6c will include a rapid-commit option in
-  solicit messages and wait for an immediate reply instead of advertisements.
+  **Enable DHCPv6 rapid commit on this interface.**
+
+  When enabled, the DHCP client and server skip the negotiation steps 
+  (Advertise and Request), completing the DHCPv6 configuration process 
+  in just two messages (Solicit and final Reply).
+
+  Example:
 
   .. code-block:: none
 
@@ -47,8 +71,14 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcpv6-options temporary
 
-  Request only a temporary address and not form an IA_NA (Identity Association
-  for Non-temporary Addresses) partnership.
+  **Configure the DHCPv6 client to request a temporary IPv6 address on this 
+  interface.**
+
+  When configured, the DHCP client doesn’t form an Identity Association for 
+  Non-temporary Addresses (IA_NA) partnership. Consequently, it only obtains 
+  a temporary IPv6 address and doesn’t obtain a permanent one.
+
+  Example:
 
   .. code-block:: none
 
diff --git a/docs/_include/interface-dhcpv6-prefix-delegation.txt b/docs/_include/interface-dhcpv6-prefix-delegation.txt
index c6564092..dacb63a5 100644
--- a/docs/_include/interface-dhcpv6-prefix-delegation.txt
+++ b/docs/_include/interface-dhcpv6-prefix-delegation.txt
@@ -1,20 +1,24 @@
 **DHCPv6 Prefix Delegation (PD)**
 
-VyOS 1.3 (equuleus) supports DHCPv6-PD (:rfc:`3633`). DHCPv6 Prefix Delegation
-is supported by most ISPs who provide native IPv6 for consumers on fixed
-networks.
+VyOS supports DHCPv6 Prefix Delegation (DHCPv6-PD) as described in :rfc:`3633`. 
+DHCPv6-PD is supported by most ISPs that provide native IPv6 for consumers on 
+fixed networks.
+
 
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcpv6-options pd <id> length <length>
 
-  Some ISPs by default only delegate a /64 prefix. To request for a specific
-  prefix size use this option to request for a bigger delegation for this pd
-  `<id>`. This value is in the range from 32 - 64 so you could request up to a
-  /32 prefix (if your ISP allows this) down to a /64 delegation.
+  **Configure a specific prefix length for DHCPv6-PD requests on this 
+  interface.** 
+
+  Some ISPs provide only a /64 prefix by default. Use this command to 
+  request a different prefix length for a specific DHCPv6-PD request, 
+  ranging from /32 (if allowed by your ISP) down to /64. <id> is a 
+  unique identifier for the DHCPv6-PD request.
 
-  The default value corresponds to 64.
+  The default value is 64.
 
-  To request a /56 prefix from your ISP use:
+  To request a /56 prefix from your ISP, use:
 
   .. code-block:: none
 
@@ -24,18 +28,23 @@ networks.
   {{ var5 }} {{ var6 }} dhcpv6-options pd <id> interface <delegatee>
   address <address>
 
-  Specify the interface address used locally on the interface where the prefix
-  has been delegated to. ID must be a decimal integer.
+  **Configure the IPv6 interface identifier (host portion) for the delegatee 
+  interface.**
+
+  The value must be a decimal integer. It is appended to the delegated prefix 
+  and the configured :abbr:`SLA ID (Site-Level Aggregation ID)` to form the 
+  final IPv6 address.
+
+  By default, the host portion is generated based on the parent interface's 
+  MAC address (EUI-64 format).
 
-  It will be combined with the delegated prefix and the sla-id to form a
-  complete interface address. The default is to use the EUI-64 address of the
-  interface.
+   .. stop_vyoslinter
 
-  .. stop_vyoslinter
+  **Example:**
 
-  Example: Delegate a /64 prefix to interface eth8 which will use a local
-  address on this router of ``<prefix>::ffff``, as the address 65534 will
-  correspond to ``ffff`` in hexadecimal notation.
+  If a /64 prefix is delegated to interface eth8 and you configure the host 
+  portion as 65535, the resulting IPv6 address will end with ::ffff, as 
+  65535 corresponds to ffff in hexadecimal notation.
 
   .. start_vyoslinter
 
@@ -47,16 +56,19 @@ networks.
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} dhcpv6-options pd <id> interface <delegatee> sla-id <id>
 
-  Specify the identifier value of the site-level aggregator (SLA) on the
-  interface. ID must be a decimal number greater then 0 which fits in the
-  length of SLA IDs (see below).
+  **Configure the** :abbr:`SLA ID (Site-Level Aggregation ID)` **for the 
+  delegatee interface.**
 
-  Example: If ID is 1 and the client is delegated an IPv6 prefix
-  2001:db8:ffff::/48, dhcp6c will combine the two values into a single IPv6
-  prefix, 2001:db8:ffff:1::/64, and will configure the prefix on the specified
-  interface.
+  The value must be a decimal integer greater than 0 and fit in the length of 
+  SLA IDs. It is converted to hexadecimal and appended to the delegated prefix 
+  to form the specific subnet prefix for the delegatee interface.
+
+  **Example:** 
+
+  If SLA ID is 1 and the delegated prefix is ``2001:db8:ffff::/48``, the 
+  resulting subnet prefix for the delegatee interface will be 
+  ``2001:db8:ffff:1::/64``.
 
   .. code-block:: none
 
     set interfaces {{ var0 }} {{ var1 }} {{ var2 }} {{ var4 }} {{ var5 }} {{ var7 }} dhcpv6-options pd 0 interface eth8 sla-id 1
-
diff --git a/docs/_include/interface-disable-flow-control.txt b/docs/_include/interface-disable-flow-control.txt
index 347f1145..67cd0a2b 100644
--- a/docs/_include/interface-disable-flow-control.txt
+++ b/docs/_include/interface-disable-flow-control.txt
@@ -1,20 +1,14 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
    disable-flow-control
 
-  Ethernet flow control is a mechanism for temporarily stopping the transmission
-  of data on Ethernet family computer networks. The goal of this mechanism is to
-  ensure zero packet loss in the presence of network congestion.
+  **Disable Ethernet flow control (IEEE 802.3x pause frames) on the interface.** 
 
-  The first flow control mechanism, the pause frame, was defined by the IEEE
-  802.3x standard.
+   Ethernet flow control, defined by the IEEE 802.3x standard, temporarily stops 
+   data transmission to prevent packet loss during network congestion. For 
+   example, when a sender transmits data faster than the receiver can process it.
 
-  A sending station (computer or network switch) may be transmitting data faster
-  than the other end of the link can accept it. Using flow control, the
-  receiving station can signal the sender requesting suspension of
-  transmissions until the receiver catches up.
-
-  Use this command to disable the generation of Ethernet flow control (pause
-  frames).
+   Disabling Ethernet flow control means the interface will not signal the 
+   connected device to pause transmission and will drop packets if overwhelmed. 
 
    Example:
 
diff --git a/docs/_include/interface-disable-link-detect.txt b/docs/_include/interface-disable-link-detect.txt
index 1a766715..194bbadd 100644
--- a/docs/_include/interface-disable-link-detect.txt
+++ b/docs/_include/interface-disable-link-detect.txt
@@ -1,10 +1,10 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} disable-link-detect
 
-  Use this command to direct an interface to not detect any physical state
-  changes on a link, for example, when the cable is unplugged.
+  **Disable physical link-state change detection on the interface, such as 
+  when a cable is unplugged.**
 
-  Default is to detects physical link state changes.
+  By default, the interface detects physical link-state changes.
 
   Example:
 
diff --git a/docs/_include/interface-disable.txt b/docs/_include/interface-disable.txt
index 774c1cdd..a1b53517 100644
--- a/docs/_include/interface-disable.txt
+++ b/docs/_include/interface-disable.txt
@@ -1,7 +1,9 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} disable
 
-  Disable given `<interface>`. It will be placed in administratively down
+  **Disable the interface.**
+
+  The interface will be set to the administratively down
   (``A/D``) state.
 
   Example:
diff --git a/docs/_include/interface-evpn-uplink.txt b/docs/_include/interface-evpn-uplink.txt
index 3495361d..84b09727 100644
--- a/docs/_include/interface-evpn-uplink.txt
+++ b/docs/_include/interface-evpn-uplink.txt
@@ -1,10 +1,12 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> evpn uplink
 
-  When all the underlay links go down the PE no longer has access
-  to the VxLAN +overlay. To prevent blackholing of traffic the
-  server/ES links are protodowned on the PE.
+  **Configure this interface as an EVPN-MH uplink interface.**
 
-  A link can be setup for uplink tracking via the following example:
+  If all uplink interfaces on a PE device go down, this PE device loses access 
+  to the VXLAN overlay. To prevent traffic blackholing, the PE device forces a 
+  protocol shutdown (protodown) of its downstream EVPN-MH interfaces.
+
+  The following example configures bond0 as an EVPN-MH uplink interface:
 
   .. code-block:: none
 
diff --git a/docs/_include/interface-ip.txt b/docs/_include/interface-ip.txt
index 5163edd8..7965115d 100644
--- a/docs/_include/interface-ip.txt
+++ b/docs/_include/interface-ip.txt
@@ -1,28 +1,34 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip adjust-mss <mss | clamp-mss-to-pmtu>
 
-  As Internet wide PMTU discovery rarely works, we sometimes need to clamp our
-  TCP MSS value to a specific value. This is a field in the TCP options part of
-  a SYN packet. By setting the MSS value, you are telling the remote side
-  unequivocally 'do not try to send me packets bigger than this value'.
+  **Configure the** :abbr:`MSS (Maximum Segment Size)` **advertised in outgoing 
+  TCP SYN packets on the specified interface.** 
 
-  .. note:: This command was introduced in VyOS 1.4 - it was previously called:
-    ``set firewall options interface <name> adjust-mss <value>``
+  By clamping the MSS value in TCP SYN packets, you explicitly inform the 
+  remote side not to send packets larger than that size. This prevents 
+  connection issues that occur when Path MTU Discovery (PMTUD) fails.
 
-  .. hint:: MSS value = MTU - 20 (IP header) - 20 (TCP header), resulting in
-    1452 bytes on a 1492 byte MTU.
+  The following options are available:
+
+  * **mss:** Sets the MSS to a specific value, in bytes. Use this option if 
+    you need to enforce a specific MSS, for example, to troubleshoot 
+    connectivity issues or accommodate specific network requirements.
+  * **clamp-mss-to-pmtu:** The router automatically calculates the MSS to be 
+    the interface's MTU minus 40 bytes for IPv4 traffic (20 bytes for the IPv4 
+    header and 20 bytes for the TCP header). This option is recommended to 
+    automatically set the proper value.
 
-  Instead of a numerical MSS value `clamp-mss-to-pmtu` can be used to
-  automatically set the proper value.
 
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip arp-cache-timeout
 
-  Once a neighbor has been found, the entry is considered to be valid for at
-  least for this specific time. An entry's validity will be extended if it
-  receives positive feedback from higher level protocols.
+  **Configure how long an ARP entry remains valid after learning an IP-to-MAC 
+  address mapping on this interface.** 
+
+  The default duration is 30 seconds.
 
-  This defaults to 30 seconds.
+  An ARP entry remains valid if it receives positive feedback from 
+  higher-level protocols.
 
   Example:
 
@@ -33,19 +39,17 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip disable-arp-filter
 
-  If set the kernel can respond to arp requests with addresses from other
-  interfaces. This may seem wrong but it usually makes sense, because it
-  increases the chance of successful communication. IP addresses are owned by
-  the complete host on Linux, not by particular interfaces. Only for more
-  complex setups like load-balancing, does this behaviour cause problems.
+  **Configure ARP filtering on this interface.**
 
-  If not set (default) allows you to have multiple network interfaces on the
-  same subnet, and have the ARPs for each interface be answered based on whether
-  or not the kernel would route a packet from the ARP'd IP out that interface
-  (therefore you must use source based routing for this to work).
+  **Default behavior:** The kernel responds to ARP requests on this interface 
+  only if the traffic would be routed back to the ARP sender through that 
+  specific interface. 
 
-  In other words it allows control of which cards (usually 1) will respond to an
-  arp request.
+  **If configured:** The kernel responds to ARP requests on this interface for any 
+  IP address configured on the local host, regardless of which specific interface 
+  that IP address is assigned to, and regardless of the routing table. This 
+  reflects the Linux concept that IP addresses belong to the host, not individual 
+  interfaces.  
 
   Example:
 
@@ -56,8 +60,12 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip disable-forwarding
 
-  Configure interface-specific Host/Router behaviour. If set, the interface will
-  switch to host mode and IPv6 forwarding will be disabled on this interface.
+  **Configure the interface for host or router behavior.**
+
+  If configured, the interface switches to host mode, and IPv4 forwarding is 
+  disabled on it.
+
+  Example:
 
   .. code-block:: none
 
@@ -66,14 +74,15 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip enable-directed-broadcast
 
-  Define different modes for IP directed broadcast forwarding as described in
-  :rfc:`1812` and :rfc:`2644`.
+  **Configure whether to forward IP-directed broadcast packets received on this 
+  interface.** 
+  
+  **Default behavior:** IP-directed broadcast packets are dropped. 
 
-  If configured, incoming IP directed broadcast packets on this interface will
-  be forwarded.
+  **If configured:** IP-directed broadcast packets are forwarded to all hosts 
+  on the destination subnet, as defined in :rfc:`1812` and :rfc:`2644`.  
 
-  If this option is unset (default), incoming IP directed broadcast packets
-  will not be forwarded.
+  Example:
 
   .. code-block:: none
 
@@ -82,14 +91,15 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip enable-arp-accept
 
-  Define behavior for gratuitous ARP frames whose IP is not already present in
-  the ARP table. If configured create new entries in the ARP table.
+  **Configure how to process gratuitous ARPs on this interface.**
+
+  If configured, an IP-to-MAC address mapping is added to the ARP table based 
+  on gratuitous ARP requests or replies.
 
-  Both replies and requests type gratuitous arp will trigger the ARP table to be
-  updated, if this setting is on.
+  .. note:: If the ARP table already contains the IP address from a gratuitous 
+     ARP, its entry is updated regardless of whether this setting is configured.
 
-  If the ARP table already contains the IP address of the gratuitous arp frame,
-  the arp table will be updated regardless if this setting is on or off.
+  Example:
 
   .. code-block:: none
 
@@ -98,18 +108,18 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip enable-arp-announce
 
-  Define different restriction levels for announcing the local source IP address
-  from IP packets in ARP requests sent on interface.
+  **Configure the source IP selection for ARP requests on this interface.**
 
-  Use any local address, configured on any interface if this is not set.
+  **Default behavior:** The kernel can use any IP address the host owns as 
+  the source IP address in ARP requests on this interface.
 
-  If configured, try to avoid local addresses that are not in the target's
-  subnet for this interface. This mode is useful when target hosts reachable via
-  this interface require the source IP address in ARP requests to be part of
-  their logical network configured on the receiving interface. When we generate
-  the request we will check all our subnets that include the target IP and will
-  preserve the source address if it is from such subnet. If there is no such
-  subnet we select source address according to the rules for level 2.
+  **If configured:** The kernel first attempts to select a source IP address 
+  configured on the interface that shares a common subnet with the target 
+  IP address. If there is no such subnet, the kernel selects the IP address 
+  it would normally use (based on the routing table to reach the target 
+  destination).
+
+  Example:
 
   .. code-block:: none
 
@@ -118,14 +128,15 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip enable-arp-ignore
 
-  Define different modes for sending replies in response to received ARP
-  requests that resolve local target IP addresses:
+  **Configure which ARP requests will be ignored on this interface.**
+
+  **Default behavior:** The kernel responds to ARP requests for any local 
+  IP addresses, regardless of which interface they are assigned to.
 
-  If configured, reply only if the target IP address is local address configured
-  on the incoming interface.
+  **If configured:** The kernel responds to ARP requests only if the target 
+  IP address is assigned to this specific interface.
 
-  If this option is unset (default), reply for any local target IP address,
-  configured on any interface.
+  Example:
 
   .. code-block:: none
 
@@ -134,12 +145,13 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip enable-proxy-arp
 
-  Use this command to enable proxy Address Resolution Protocol (ARP) on this
-  interface. Proxy ARP allows an Ethernet interface to respond with its own
-  :abbr:`MAC (Media Access Control)` address to ARP requests for destination IP
-  addresses on subnets attached to other interfaces on the system. Subsequent
-  packets sent to those destination IP addresses are forwarded appropriately by
-  the system.
+  **Configure proxy ARP on this interface.**
+
+  If configured, the router (kernel) intercepts ARP requests for non-local IP 
+  addresses and replies with the :abbr:`MAC (Media Access Control)` address 
+  of the interface that received the request. Subsequent packets destined 
+  to these IP addresses are forwarded to their actual destinations on remote 
+  subnets.
 
   Example:
 
@@ -150,41 +162,53 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip proxy-arp-pvlan
 
-  Private VLAN proxy arp. Basically allow proxy arp replies back to the same
-  interface (from which the ARP request/solicitation was received).
+  **Configure local proxy ARP on the interface.**
 
-  This is done to support (ethernet) switch features, like :rfc:`3069`, where
-  the individual ports are NOT allowed to communicate with each other, but they
-  are allowed to talk to the upstream router. As described in :rfc:`3069`, it is
-  possible to allow these hosts to communicate through the upstream router by
-  proxy_arp'ing.
+  If configured, the router (kernel) responds to ARP requests on this VLAN 
+  interface even if the target IP address resides on the same subnet and 
+  interface.
 
-  .. note:: Does not need to be used together with proxy_arp.
+  This is used to support network isolation requirements (RFC 3069) for private 
+  VLANs (PVLANs). In PVLAN configurations, hosts on isolated ports are NOT 
+  allowed to communicate directly with each other at Layer 2, but they can 
+  communicate with the upstream router. 
 
-  This technology is known by different names:
+  By replying to inter-host ARP requests with its own :abbr:`MAC (Media Access Control)` 
+  address, the router (kernel) directs inter-host traffic through itself instead of 
+  directly between hosts.
 
-  - In :rfc:`3069` it is called VLAN Aggregation
+  .. note:: This command works independently and does not require enabling 
+     the standard proxy ARP on the interface.
 
-  - Cisco and Allied Telesyn call it Private VLAN
+  Local proxy ARP is also known as:
 
-  - Hewlett-Packard call it Source-Port filtering or port-isolation
+  - VLAN aggregation (:rfc:`3069`).
 
-  - Ericsson call it MAC-Forced Forwarding (RFC Draft)
+  - Private VLAN  (Cisco, Allied Telesyn).
+
+  - Source-port filtering or port isolation (Hewlett-Packard).
+
+  - MAC-Forced Forwarding (Ericsson).
 
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ip source-validation <strict | loose | disable>
 
-  Enable policy for source validation by reversed path, as specified in
-  :rfc:`3704`. Current recommended practice in :rfc:`3704` is to enable strict
-  mode to prevent IP spoofing from DDos attacks. If using asymmetric routing
-  or other complicated routing, then loose mode is recommended.
+  **Configure source IP address validation using** :abbr:`RPF (Reverse Path 
+  Forwarding)` **on this interface, as specified in** :rfc:`3704`. 
+
+  The following options are available:
+
+  - **strict:** Each incoming packet’s source IP address is checked against the 
+    Forwarding Information Base (FIB). If the interface is not the best route 
+    back to that source, validation fails, and the packet is dropped.
 
-  - strict: Each incoming packet is tested against the FIB and if the interface
-    is not the best reverse path the packet check will fail. By default failed
-    packets are discarded.
+  - **loose:** Each incoming packet’s source IP address is checked against the 
+    FIB. If the source IP address is unreachable through any interface, validation 
+    fails.
 
-  - loose: Each incoming packet's source address is also tested against the FIB
-    and if the source address is not reachable via any interface the packet
-    check will fail.
+  - **disable:** No source IP address validation is performed. All incoming 
+    packets are accepted.
 
-  - disable: No source validation
+  RFC 3704 recommends enabling strict mode to prevent IP spoofing, such as 
+  DDoS attacks. For asymmetric or other complex routing scenarios, use loose 
+  mode.
diff --git a/docs/_include/interface-ipv6.txt b/docs/_include/interface-ipv6.txt
index 0c222d80..a122ae1a 100644
--- a/docs/_include/interface-ipv6.txt
+++ b/docs/_include/interface-ipv6.txt
@@ -1,16 +1,20 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ipv6 address autoconf
 
-  :abbr:`SLAAC (Stateless Address Autoconfiguration)` :rfc:`4862`. IPv6 hosts
-  can configure themselves automatically when connected to an IPv6 network using
-  the Neighbor Discovery Protocol via :abbr:`ICMPv6 (Internet Control Message
-  Protocol version 6)` router discovery messages. When first connected to a
-  network, a host sends a link-local router solicitation multicast request for
-  its configuration parameters; routers respond to such a request with a router
-  advertisement packet that contains Internet Layer configuration parameters.
+  **Configure the interface to automatically obtain an IPv6 address using**
+  :abbr:`SLAAC (Stateless Address Autoconfiguration)`, **as specified in** 
+  :rfc:`4862`. 
 
-  .. note:: This method automatically disables IPv6 traffic forwarding on the
-    interface in question.
+
+  IPv6 hosts can configure themselves automatically when connected to an 
+  IPv6 network using the Neighbor Discovery Protocol via ICMPv6 router 
+  discovery messages. When first connected to a network, a host sends a 
+  link-local router solicitation multicast request for its configuration 
+  parameters. The router responds with a router advertisement packet 
+  containing Internet Layer configuration parameters.
+
+  .. note:: This method automatically disables IPv6 traffic forwarding 
+     on the interface.
 
   Example:
 
@@ -22,8 +26,9 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ipv6 address eui64 <prefix>
 
-  :abbr:`EUI-64 (64-Bit Extended Unique Identifier)` as specified in
-  :rfc:`4291` allows a host to assign iteslf a unique 64-Bit IPv6 address.
+  **Configure the interface to assign itself an IPv6 address using the** 
+  :abbr:`EUI-64 (64-Bit Extended Unique Identifier)` **method, as 
+  specified** in :rfc:`4291`.
 
   Example:
 
@@ -34,7 +39,8 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ipv6 address no-default-link-local
 
-  Do not assign a link-local IPv6 address to this interface.
+  **Disable the automatic assignment of a link-local IPv6 address to 
+  this interface.**
 
   Example:
 
@@ -45,8 +51,10 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ipv6 disable-forwarding
 
-  Configure interface-specific Host/Router behaviour. If set, the interface will
-  switch to host mode and IPv6 forwarding will be disabled on this interface.
+  **Configure the interface for host or router behavior.**
+
+  If configured, the interface switches to host mode, and IPv6 forwarding is 
+  disabled on it.
 
   Example:
 
@@ -57,28 +65,36 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ipv6 adjust-mss <mss | clamp-mss-to-pmtu>
 
-  As Internet wide PMTU discovery rarely works, we sometimes need to clamp our
-  TCP MSS value to a specific value. This is a field in the TCP options part of
-  a SYN packet. By setting the MSS value, you are telling the remote side
-  unequivocally 'do not try to send me packets bigger than this value'.
+  **Configure the** :abbr:`MSS (Maximum Segment Size)` **advertised in outgoing 
+  TCP SYN packets on the specified interface.** 
 
-  .. note:: This command was introduced in VyOS 1.4 - it was previously called:
-    ``set firewall options interface <name> adjust-mss6 <value>``
+  By clamping the MSS value in TCP SYN packets, you explicitly inform 
+  the remote side not to send packets larger than that size. This prevents 
+  connection issues when Path MTU Discovery (PMTUD) fails.
 
-  .. hint:: MSS value = MTU - 40 (IPv6 header) - 20 (TCP header), resulting in
-    1432 bytes on a 1492 byte MTU.
+  The following options are available:
 
-  Instead of a numerical MSS value `clamp-mss-to-pmtu` can be used to
-  automatically set the proper value.
+  * **mss:** Set the MSS to a specific value, in bytes. Use this option to 
+    enforce a specific MSS, for example, to troubleshoot connectivity issues 
+    or accommodate specific network requirements.
+  * **clamp-mss-to-pmtu:** The router calculates the MSS to be the interface's 
+    MTU minus 60 bytes for IPv6 traffic (40 bytes for the IPv6 header and 20 
+    bytes for the TCP header). This option is recommended to automatically 
+    set the proper value.
 
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
-  {{ var5 }} {{ var6 }} ipv6 accept-dad <1-3>
+  {{ var5 }} {{ var6 }} ipv6 accept-dad <0 | 1 | 2>
+
+  **Configure IPv6** :abbr:`DAD (Duplicate Address Detection)` **on the 
+  interface.**
 
-  Whether to accept DAD (Duplicate Address Detection).
+  The following options are available:
 
-  - 0: Disable DAD
-  - 1: Enable DAD (default)
-  - 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found.
+  - **0:** Disables DAD. No duplicate address detection is performed.
+  - **1:** Enables DAD (default). Duplicate addresses are detected. The 
+    interface's IPv6 operation continues for valid IPv6 addresses.
+  - **2:** Enables DAD and, if a MAC-based duplicate link-local address 
+    is found, disables IPv6 operation on this interface.
 
   Example:
 
@@ -89,9 +105,11 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} ipv6 dup-addr-detect-transmits <n>
 
-  The amount of Duplicate Address Detection probes to send.
+  **Configure the number of** :abbr:`DAD (Duplicate Address Detection)`
+  **messages that the router (kernel) sends during IPv6 address assignment 
+  on this interface.**
 
-  Default: 1
+  The default value is 1. 
 
   Example:
 
diff --git a/docs/_include/interface-mac.txt b/docs/_include/interface-mac.txt
index 9c8c7de5..b8c84653 100644
--- a/docs/_include/interface-mac.txt
+++ b/docs/_include/interface-mac.txt
@@ -1,8 +1,7 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} mac <xx:xx:xx:xx:xx:xx>
 
-  Configure user defined :abbr:`MAC (Media Access Control)` address on given
-  `<interface>`.
+  **Configure a custom MAC address on the interface.**
 
   Example:
 
diff --git a/docs/_include/interface-mirror.txt b/docs/_include/interface-mirror.txt
index 26594984..06a42ca5 100644
--- a/docs/_include/interface-mirror.txt
+++ b/docs/_include/interface-mirror.txt
@@ -1,22 +1,26 @@
-SPAN port mirroring can copy the inbound/outbound traffic of the interface to
-the specified interface, usually the interface can be connected to some special
-equipment, such as a behavior control system, intrusion detection system or
-traffic collector, and can copy all related traffic from this port.
-The benefit of mirroring the traffic is that the application is isolated from 
-the source traffic and so application processing does not affect the traffic 
-or the system performance.
-
-VyOS uses the `mirror` option to configure port mirroring. The configuration
-is divided into 2 different directions. Destination ports should be configured
-for different traffic directions.
+:abbr:`SPAN (Switched Port Analyser)` port mirroring copies inbound and 
+outbound traffic from one interface to another specified interface.  
+
+The destination interface is usually connected to specialized equipment, 
+such as a behavior control system, an intrusion detection system, or 
+a traffic collector, and copies all related traffic from this port. The 
+benefit of mirroring traffic is that the application is isolated from the 
+source traffic, so application processing does not affect the traffic or 
+system performance.
+
+To configure :abbr:`SPAN (Switched Port Analyser)` port mirroring, VyOS uses 
+the ``mirror`` parameter. You can mirror ingress traffic (traffic entering the 
+router) and egress traffic (traffic leaving the router) separately. Both 
+directions can be mirrored to the same destination interface or split to 
+different ones.
 
 .. cfgcmd:: set interfaces {{ var0 }} <interface> mirror
    ingress <monitor-interface>
 
-   Configure port mirroring for `interface` inbound traffic and copy the
-   traffic to `monitor-interface`
-   
-   Example: Mirror the inbound traffic of `{{ var1 }}` port to `{{ var2 }}`
+   **Mirror ingress traffic from a bonding interface to the specified monitoring 
+   interface.**
+  
+   Example: Mirror the ingress traffic from `{{ var1 }}` to `{{ var2 }}`.
    
    .. code-block:: none
    
@@ -25,10 +29,11 @@ for different traffic directions.
 .. cfgcmd:: set interfaces {{ var0 }} <interface> mirror egress
    <monitor-interface>
 
-   Configure port mirroring for `interface` outbound traffic and copy the
-   traffic to `monitor-interface`
+   **Mirror egress traffic from a bonding interface to the specified monitoring 
+   interface.**
+
    
-   Example: Mirror the outbound traffic of `{{ var1 }}` port to `{{ var2 }}`
+   Example: Mirror the egress traffic from `{{ var1 }}` to `{{ var2 }}`.
    
    .. code-block:: none
    
diff --git a/docs/_include/interface-mtu.txt b/docs/_include/interface-mtu.txt
index f3666179..a67a2d8c 100644
--- a/docs/_include/interface-mtu.txt
+++ b/docs/_include/interface-mtu.txt
@@ -1,8 +1,10 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} mtu <mtu>
 
-  Configure :abbr:`MTU (Maximum Transmission Unit)` on given `<interface>`. It
-  is the size (in bytes) of the largest ethernet frame sent on this link.
+  **Configure the MTU on the interface.** 
+
+  This value defines the largest packet size, in bytes, that the interface 
+  transmits without fragmentation.
 
   Example:
 
diff --git a/docs/_include/interface-vlan-8021q.txt b/docs/_include/interface-vlan-8021q.txt
index 1a527590..1a7a665f 100644
--- a/docs/_include/interface-vlan-8021q.txt
+++ b/docs/_include/interface-vlan-8021q.txt
@@ -1,33 +1,29 @@
-IEEE 802.1q_, often referred to as Dot1q, is the networking standard that
-supports virtual LANs (VLANs) on an IEEE 802.3 Ethernet network. The standard
-defines a system of VLAN tagging for Ethernet frames and the accompanying
-procedures to be used by bridges and switches in handling such frames.
-The standard also contains provisions for a quality-of-service prioritization
-scheme commonly known as IEEE 802.1p and defines the
-Generic Attribute Registration Protocol.
-
-Portions of the network which are VLAN-aware (i.e., IEEE 802.1q_ conformant) can
-include VLAN tags. When a frame enters the VLAN-aware portion of the network, a
-tag is added to represent the VLAN membership. Each frame must be
-distinguishable as being within exactly one VLAN. A frame in the VLAN-aware
-portion of the network that does not contain a VLAN tag is assumed to be
-flowing on the native VLAN.
-
-The standard was developed by IEEE 802.1, a working group of the IEEE 802
-standards committee, and continues to be actively revised. One of the notable
-revisions is 802.1Q-2014 which incorporated IEEE 802.1aq
-(Shortest Path Bridging) and much of the IEEE 802.1d standard.
-
-802.1q VLAN interfaces are represented as virtual sub-interfaces in VyOS. The
-term used for this is ``vif``.
+IEEE 802.1q_, often referred to as Dot1q, is the industry standard for 
+implementing VLANs on Ethernet networks. It defines VLAN tagging for 
+Ethernet frames and outlines procedures for bridges and switches. The 
+standard also includes quality-of-service prioritization (IEEE 802.1p) 
+and defines the Generic Attribute Registration Protocol.
+
+VLAN-aware network segments  (i.e., IEEE 802.1q_ conformant) use VLAN tags. 
+When a frame enters such a segment, a tag is added to indicate VLAN membership. 
+Each frame can belong to only one VLAN. If a frame arrives without a tag, it 
+is assumed to be part of the native VLAN.
+
+IEEE 802.1, a working group of the IEEE 802 standards committee, has developed 
+the standard and continues to revise it. One notable revision is 802.1Q-2014, 
+which incorporated IEEE 802.1aq (Shortest Path Bridging) and much of the IEEE 
+802.1d standard. 
+
+In VyOS, 802.1q VLAN interfaces are represented as virtual subinterfaces, 
+referred to as  ``vif``.
 
 .. cfgcmd:: set interfaces {{ var0 }} <interface> vif <vlan-id>
 
-  Create a new VLAN interface on interface `<interface>` using the VLAN number
-  provided via `<vlan-id>`.
+  **Configure a VLAN interface with a unique VLAN ID.** 
+
+  VLAN ID identifies a specific VLAN and ranges from 0 to 4094. 
 
-  You can create multiple VLAN interfaces on a physical interface. The VLAN ID
-  range is from 0 to 4094.
+  You can configure multiple VLAN interfaces on a single physical interface.
 
   .. note:: Only 802.1Q-tagged packets are accepted on Ethernet vifs.
 
diff --git a/docs/_include/interface-vrf.txt b/docs/_include/interface-vrf.txt
index 1fa94f9f..f6dfe47c 100644
--- a/docs/_include/interface-vrf.txt
+++ b/docs/_include/interface-vrf.txt
@@ -1,10 +1,11 @@
 .. cfgcmd:: set interfaces {{ var0 }} <interface> {{ var2 }} {{ var3 }}
   {{ var5 }} {{ var6 }} vrf <vrf>
 
-  Place interface in given VRF instance.
+  **Assign the interface to a specific** :abbr:`VRF (Virtual Routing and 
+  Forwarding)` **instance.**
 
-  .. seealso:: There is an entire chapter about how to configure a :ref:`vrf`,
-    please check this for additional information.
+  .. seealso:: For information on configuring a VRF, refer to the :ref:`vrf` 
+     section.
 
   Example:
 
diff --git a/docs/configuration/interfaces/bonding.rst b/docs/configuration/interfaces/bonding.rst
index 27f1bbed..e0a374c3 100644
--- a/docs/configuration/interfaces/bonding.rst
+++ b/docs/configuration/interfaces/bonding.rst
@@ -1,16 +1,20 @@
-:lastproofread: 2021-06-30
+:lastproofread: 2025-12-09
 
 .. _bond-interface:
 
 #######################
-Bond / Link Aggregation
+Bond / link aggregation
 #######################
 
-The bonding interface provides a method for aggregating multiple network
-interfaces into a single logical "bonded" interface, or LAG, or ether-channel,
-or port-channel. The behavior of the bonded interfaces depends upon the mode;
-generally speaking, modes provide either hot standby or load balancing services.
-Additionally, link integrity monitoring may be performed.
+A **bonding interface** aggregates multiple network interfaces into a single 
+logical interface (referred to as a bond, :abbr:`LAG (Link Aggregation Group)`, 
+EtherChannel, or port-channel).
+
+The behavior of a bonding interface depends on the selected mode. Modes provide 
+either fault tolerance or a combination of load balancing and fault tolerance. 
+Additionally, the bonding interface can be configured for link integrity 
+monitoring.
+
 
 *************
 Configuration
@@ -23,318 +27,394 @@ Common interface configuration
    :var0: bonding
    :var1: bond0
 
-Member Interfaces
+Member interfaces
 =================
 
 .. cfgcmd:: set interfaces bonding <interface> member interface <member>
 
-   Enslave `<member>` interface to bond `<interface>`.
+  **Add an interface to the bonding group.**
+
+  **Example:**
+
+  To configure eth0 and eth1 as members of the bonding interface bond0, execute 
+  the following commands:
+
+.. code-block:: none
+
+   set interfaces bonding bond0 member interface eth0
+   set interfaces bonding bond0 member interface eth1
 
-Bond options
+Bond modes
 ============
 
 .. cfgcmd:: set interfaces bonding <interface> mode <802.3ad | active-backup |
   broadcast | round-robin | transmit-load-balance | adaptive-load-balance |
   xor-hash>
 
-   Specifies one of the bonding policies. The default is 802.3ad. Possible
-   values are:
-
-   * ``802.3ad`` - IEEE 802.3ad Dynamic link aggregation. Creates aggregation
-     groups that share the same speed and duplex settings. Utilizes all slaves
-     in the active aggregator according to the 802.3ad specification.
-
-     Slave selection for outgoing traffic is done according to the transmit
-     hash policy, which may be changed from the default simple XOR policy via
-     the :cfgcmd:`hash-policy` option, documented below.
-
-     .. note:: Not all transmit policies may be 802.3ad compliant, particularly
-        in regards to the packet misordering requirements of section 43.2.4
-        of the 802.3ad standard.
-
-   * ``active-backup`` - Active-backup policy: Only one slave in the bond is
-     active. A different slave becomes active if, and only if, the active slave
-     fails. The bond's MAC address is externally visible on only one port
-     (network adapter) to avoid confusing the switch.
-
-     When a failover occurs in active-backup mode, bonding will issue one or
-     more gratuitous ARPs on the newly active slave. One gratuitous ARP is
-     issued for the bonding master interface and each VLAN interfaces
-     configured above it, provided that the interface has at least one IP
-     address configured. Gratuitous ARPs issued for VLAN interfaces are tagged
-     with the appropriate VLAN id.
-
-     This mode provides fault tolerance. The :cfgcmd:`primary` option,
-     documented below, affects the behavior of this mode.
-
-   * ``broadcast`` - Broadcast policy: transmits everything on all slave
-     interfaces.
-
-     This mode provides fault tolerance.
-
-   * ``round-robin`` - Round-robin policy: Transmit packets in sequential
-     order from the first available slave through the last.
-
-     This mode provides load balancing and fault tolerance.
-
-   * ``transmit-load-balance`` - Adaptive transmit load balancing: channel
-     bonding that does not require any special switch support.
-
-     Incoming traffic is received by the current slave. If the receiving slave
-     fails, another slave takes over the MAC address of the failed receiving
-     slave.
-
-   * ``adaptive-load-balance`` - Adaptive load balancing: includes
-     transmit-load-balance plus receive load balancing for IPV4 traffic, and
-     does not require any special switch support. The receive load balancing
-     is achieved by ARP negotiation. The bonding driver intercepts the ARP
-     Replies sent by the local system on their way out and overwrites the
-     source hardware address with the unique hardware address of one of the
-     slaves in the bond such that different peers use different hardware
-     addresses for the server.
-
-     Receive traffic from connections created by the server is also balanced.
-     When the local system sends an ARP Request the bonding driver copies and
-     saves the peer's IP information from the ARP packet. When the ARP Reply
-     arrives from the peer, its hardware address is retrieved and the bonding
-     driver initiates an ARP reply to this peer assigning it to one of the
-     slaves in the bond. A problematic outcome of using ARP negotiation for
-     balancing is that each time that an ARP request is broadcast it uses the
-     hardware address of the bond. Hence, peers learn the hardware address
-     of the bond and the balancing of receive traffic collapses to the current
-     slave. This is handled by sending updates (ARP Replies) to all the peers
-     with their individually assigned hardware address such that the traffic
-     is redistributed. Receive traffic is also redistributed when a new slave
-     is added to the bond and when an inactive slave is re-activated. The
-     receive load is distributed sequentially (round robin) among the group
-     of highest speed slaves in the bond.
-
-     When a link is reconnected or a new slave joins the bond the receive
-     traffic is redistributed among all active slaves in the bond by initiating
-     ARP Replies with the selected MAC address to each of the clients. The
-     updelay parameter (detailed below) must be set to a value equal or greater
-     than the switch's forwarding delay so that the ARP Replies sent to the
-     peers will not be blocked by the switch.
-
-   * ``xor-hash`` - XOR policy: Transmit based on the selected transmit
-     hash policy.  The default policy is a simple [(source MAC address XOR'd
-     with destination MAC address XOR packet type ID) modulo slave count].
-     Alternate transmit policies may be selected via the :cfgcmd:`hash-policy`
-     option, described below.
-
-     This mode provides load balancing and fault tolerance.
+   **Configure the bonding mode on the interface. The default mode is** 
+   ``802.3ad``.
+
+   The available modes are:
+
+   * ``802.3ad`` 
+  
+   .. list-table::
+      :widths: 20 80
+
+      * - **Description:**
+        - IEEE 802.3ad Dynamic Link Aggregation. Groups only member interfaces with 
+          the same speed (e.g., 1 Gbps) and duplex settings. Member interfaces with 
+          different speed and duplex settings are not included in the active bond.
+
+          Provides load balancing and fault tolerance. Uses the :abbr:`LACP (Link 
+          Aggregation Control Protocol)` to negotiate the bond with the switch.  
+      * - **Traffic distribution:**
+        - Traffic is distributed according to the **transmit hash policy** 
+          (default: XOR). 
+
+          The bonding driver applies an XOR operation to specific packet header fields, 
+          generating a hash value that maps to a particular member interface. This 
+          ensures the same network flow is consistently transmitted over the same member 
+          interface. 
+        
+          The transmit hash policy is configured via the ``hash-policy`` option.
+      * - **Failover:**
+        - If a member interface fails, the hash is recalculated to distribute 
+          traffic among the remaining active member interfaces.
+
+   .. note:: Not all transmit hash policies comply with 802.3ad, particularly
+      section 43.2.4. Using a non-compliant policy may result in out-of-order
+      packet delivery.
+
+   * ``active-backup`` 
+
+   .. list-table::
+      :widths: 20 80
+ 
+      * - **Description:**
+        - Provides fault tolerance. Only one member interface is active at a time. 
+          Other member interfaces remain in a standby mode.  
+      * - **Traffic distribution:**         
+        - All traffic (incoming and outgoing) is routed via one active member interface.
+      * - **Failover:**         
+        - If the designated member interface fails, all traffic is routed to
+          another member interface. The bonding driver sends a Gratuitous ARP 
+          to update the peer's MAC address table, linking the bond's MAC address 
+          to another physical port.
+
+   * ``broadcast``
+
+   .. list-table::
+      :widths: 20 80
+ 
+      * - **Description:**
+        - Provides maximum fault tolerance by duplicating traffic.
+      * - **Traffic distribution:**         
+        - Every packet is duplicated and transmitted on **all** member interfaces.
+      * - **Failover:**         
+        - Traffic flow is not interrupted as long as at least one member interface 
+          remains active.
+
+   * ``round-robin``   
+
+   .. list-table::
+      :widths: 20 80
+ 
+      * - **Description:**
+        - Provides load balancing and fault tolerance.
+      * - **Traffic distribution:**         
+        - Packets are transmitted in sequential order across the member interfaces 
+          (e.g., packet 1 > interface A, packet 2 > interface B, etc.).
+      * - **Failover:**         
+        - If a member interface fails, the sequence skips the failed interface and 
+          continues with the remaining active members.
+
+   * ``transmit-load-balance``   
+
+   .. list-table::
+      :widths: 20 80
+ 
+      * - **Description:**
+        - Provides adaptive transmit load balancing and fault tolerance.
+      * - **Traffic distribution:**         
+        - **Outgoing:** Distributed across all active member interfaces based on 
+          the current load.
+
+          **Incoming:** Received by a designated member interface (active receiver).
+      * - **Failover:**         
+        - If the active receiver fails, another member interface takes over as the new 
+          active receiver.
+
+   * ``adaptive-load-balance``
+
+   .. list-table::
+      :widths: 20 80
+
+      * - **Description:**
+        - Provides adaptive transmit load balancing identical to 
+          ``transmit-load-balance``, receive load balancing for IPv4 traffic, and fault 
+          tolerance for both incoming and outgoing traffic.
+      * - **Traffic distribution:**
+        - **Outgoing:** Identical to ``transmit-load-balance``.
+
+          **Incoming:** Distributed based on ARP manipulation. For both local and remote
+          connections, the bonding driver intercepts ARP traffic and changes the source
+          MAC address to the MAC address of the least loaded member interface. 
+
+          All traffic from that peer is then routed to the chosen member interface.
+      * - **Failover:**
+        - If a member interface's state changes (fails, recovers, is added, or excluded),
+          the traffic is redistributed among all active member interfaces.
+
+   * ``xor-hash``: Provides load balancing and fault tolerance based on a hash formula. 
+     Distributes traffic and handles failover identically to ``802.3ad``, but operates 
+     without the :abbr:`LACP (Link Aggregation Control Protocol)`.
 
 .. cfgcmd:: set interfaces bonding <interface> min-links <0-16>
 
-   Specifies the minimum number of links that must be active before asserting
-   carrier. It is similar to the Cisco EtherChannel min-links feature. This
-   allows setting the minimum number of member ports that must be up (link-up
-   state) before marking the bond device as up (carrier on). This is useful for
-   situations where higher level services such as clustering want to ensure a
-   minimum number of low bandwidth links are active before switchover.
+   **Configure how many member interfaces must be active (in the link-up state) to 
+   mark the bonding interface UP (carrier asserted).**
 
-   This option only affects 802.3ad mode.
+   This command applies only when the bonding interface is configured in 802.3ad 
+   mode and functions like the Cisco EtherChannel min-links feature. It ensures 
+   that a bonding interface is marked UP (carrier asserted) only when a specified 
+   number of member interfaces are active (in the link-up state). This helps 
+   guarantee a minimum level of bandwidth for higher-level services (such as 
+   clustering) relying on the bonding interface. 
 
-   The default value is 0. This will cause the carrier to be asserted
-   (for 802.3ad mode) whenever there is an active aggregator,
-   regardless of the number of available links in that aggregator.
+   The default value is 0. This marks the bonding interface UP (carrier asserted) 
+   whenever an active LACP aggregator exists, regardless of the number of member 
+   interfaces in that aggregator. 
 
-   .. note:: Because an aggregator cannot be active without at least one
-      available link, setting this option to 0 or to 1 has the exact same
-      effect.
+   .. note:: In 802.3ad mode, a bond cannot be active without at least one active 
+      member interface. Therefore, setting min-links to 0 or 1 has the same result: 
+      the bonding interface is marked UP (carrier asserted).
 
 .. cfgcmd:: set interfaces bonding <interface> lacp-rate <slow|fast>
 
-   Option specifying the rate in which we'll ask our link partner to transmit
-   LACPDU packets in 802.3ad mode.
-
-   This option only affects 802.3ad mode.
-
-   * slow: Request partner to transmit LACPDUs every 30 seconds
-
-   * fast: Request partner to transmit LACPDUs every 1 second
-
-   The default value is slow.
-
-.. cfgcmd:: set interfaces bonding <interface> system-mac <mac address>
-
-   This option allow to specifies the 802.3ad system MAC address.You can set a
-   random mac-address that can be used for these LACPDU exchanges.
-   
-.. cfgcmd:: set interfaces bonding <interface> hash-policy <policy>
-
-   * **layer2** - Uses XOR of hardware MAC addresses and packet type ID field
-     to generate the hash. The formula is
-
-     .. code-block:: none
-
-       hash = source MAC XOR destination MAC XOR packet type ID
-       slave number = hash modulo slave count
-
-     This algorithm will place all traffic to a particular network peer on
-     the same slave.
-
-     This algorithm is 802.3ad compliant.
+   **Configure the rate at which the bonding interface requests its link 
+   partner to send** :abbr:`LACPDUs (Link Aggregation Control Protocol Data 
+   Units)` **in 802.3ad mode.**
 
-   * **layer2+3** - This policy uses a combination of layer2 and layer3
-     protocol information to generate the hash. Uses XOR of hardware MAC
-     addresses and IP addresses to generate the hash. The formula is:
+   This command applies only when the bonding interface is configured in 
+   802.3ad mode.
 
-     .. code-block:: none
+   The following options are available:
 
-       hash = source MAC XOR destination MAC XOR packet type ID
-       hash = hash XOR source IP XOR destination IP
-       hash = hash XOR (hash RSHIFT 16)
-       hash = hash XOR (hash RSHIFT 8)
+   * **slow (default):** Requests the link partner to transmit LACPDUs every 30 seconds.
 
-     And then hash is reduced modulo slave count.
+   * **fast:** Requests the link partner to transmit LACPDUs every 1 second. 
 
-     If the protocol is IPv6 then the source and destination addresses are
-     first hashed using ipv6_addr_hash.
 
-     This algorithm will place all traffic to a particular network peer on the
-     same slave. For non-IP traffic, the formula is the same as for the layer2
-     transmit hash policy.
-
-     This policy is intended to provide a more balanced distribution of traffic
-     than layer2 alone, especially in environments where a layer3 gateway
-     device is required to reach most destinations.
-
-     This algorithm is 802.3ad compliant.
-
-   * **layer3+4** - This policy uses upper layer protocol information, when
-     available, to generate the hash. This allows for traffic to a particular
-     network peer to span multiple slaves, although a single connection will
-     not span multiple slaves.
-
-     The formula for unfragmented TCP and UDP packets is
+.. cfgcmd:: set interfaces bonding <interface> system-mac <mac address>
 
-     .. code-block:: none
+   **Configure a specific MAC address for the bonding interface.**
 
-       hash = source port, destination port (as in the header)
-       hash = hash XOR source IP XOR destination IP
-       hash = hash XOR (hash RSHIFT 16)
-       hash = hash XOR (hash RSHIFT 8)
+   This sets the 802.3ad system MAC address, which is used for :abbr:`LACPDU (Link 
+   Aggregation Control Protocol Data Unit)` exchanges with the link partner. 
+   You can assign a fixed MAC address or generate a random one for these 
+   :abbr:`LACPDU (Link Aggregation Control Protocol Data Unit)` exchanges. 
 
-     And then hash is reduced modulo slave count.
 
-     If the protocol is IPv6 then the source and destination addresses are
-     first hashed using ipv6_addr_hash.
+.. cfgcmd:: set interfaces bonding <interface> hash-policy <policy>
 
-     For fragmented TCP or UDP packets and all other IPv4 and IPv6 protocol
-     traffic, the source and destination port information is omitted. For
-     non-IP traffic, the formula is the same as for the layer2 transmit hash
-     policy.
+   **Configure which transmit hash policy to use for distributing traffic across 
+   member interfaces.**
+
+   The following policies are available:
+
+   * ``layer2``
+
+     .. list-table::
+        :widths: 20 80
+
+        * - **Description:**
+          - Routes all traffic destined for a specific network peer through the same 
+            member interface. The policy is 802.3ad-compliant.
+        * - **Hash inputs:**
+          - Source MAC address, destination MAC address, and Ethernet packet type ID. 
+        * - **Formula:**
+          - .. code-block:: none
+
+               hash = source MAC address XOR destination MAC address XOR packet type ID
+               member interface number = hash modulo member interface count
+
+   * ``layer2+3``
+
+     .. list-table::
+        :widths: 20 80
+
+        * - **Description:**
+          - Similar to ``layer2``, routes all traffic destined for a specific network 
+            peer through the same member interface and is IEEE 802.3ad-compliant. Uses 
+            both Layer 2 and Layer 3 information to provide a more balanced traffic distribution.
+        * - **Hash inputs:**
+          - * Source MAC address, destination MAC address, and Ethernet packet type ID.
+            * Source IP address, destination IP address. IPv6 addresses are first hashed 
+              using ``IPv6_addr_hash``. 
+        * - **Formula:**
+          - .. code-block:: none
+
+               hash = source MAC address XOR destination MAC address XOR packet type ID
+               hash = hash XOR source IP address XOR destination IP address
+               hash = hash XOR (hash RSHIFT 16)
+               hash = hash XOR (hash RSHIFT 8)
+               member interface number = hash modulo member interface count
+         
+            For non-IP traffic, the formula is the same as for ``layer2``.
+
+   * ``layer3+4``
+
+     .. list-table::
+        :widths: 20 80
+
+        * - **Description:**
+          - Routes different connections (flows) destined for a specific network peer 
+            through multiple member interfaces, but ensures each individual flow is 
+            routed through only one member interface.
+
+            .. note:: This policy is not fully 802.3ad-compliant. When a single TCP 
+               or UDP flow contains both fragmented and unfragmented packets, the 
+               algorithm may distribute them across different member interfaces. This 
+               may result in out-of-order packet delivery, violating the 802.3ad standard.
+        * - **Hash inputs:**
+          - * Source port, destination port (if available).
+            * Source IP address, destination IP address. IPv6 addresses are first hashed 
+              using ``IPv6_addr_hash``. 
+        * - **Formula:**
+          - .. code-block:: none
+
+               hash = source port, destination port (as in the header)
+               hash = hash XOR source IP address XOR destination IP address
+               hash = hash XOR (hash RSHIFT 16)
+               hash = hash XOR (hash RSHIFT 8)
+               member interface number = hash modulo member interface count
+
+            For fragmented TCP or UDP packets and all other IPv4 and IPv6 traffic, the 
+            source and destination port information is omitted.
+
+            For non-IP traffic, the formula is the same as for ``layer2``.
+ 
+.. cfgcmd:: set interfaces bonding <interface> primary <interface>
 
-     This algorithm is not fully 802.3ad compliant. A single TCP or UDP
-     conversation containing both fragmented and unfragmented packets will see
-     packets striped across two interfaces. This may result in out of order
-     delivery. Most traffic types will not meet these criteria, as TCP rarely
-     fragments traffic, and most UDP traffic is not involved in extended
-     conversations. Other implementations of 802.3ad may or may not tolerate
-     this noncompliance.
+   **Configure the primary member interface in the bond.**
 
-.. cfgcmd:: set interfaces bonding <interface> primary <interface>
+   The primary member interface remains active as long as it is operational; 
+   alternative member interfaces are used only if it fails. 
 
-    An `<interface>` specifying which slave is the primary device. The specified
-    device will always be the active slave while it is available. Only when the
-    primary is off-line will alternate devices be used. This is useful when one
-    slave is preferred over another, e.g., when one slave has higher throughput
-    than another.
+   Use this configuration when a specific member interface is preferred, 
+   such as one with higher throughput.
 
-    The primary option is only valid for active-backup, transmit-load-balance,
-    and adaptive-load-balance mode.
+   This command applies only to ``active-backup``, ``transmit-load-balance``, and 
+   ``adaptive-load-balance`` modes.
 
 .. cfgcmd:: set interfaces bonding <interface> arp-monitor interval <time>
 
-   Specifies the ARP link monitoring `<time>` in seconds.
+   **Configure the ARP monitoring interval, in seconds, for the bonding interface.**
 
-   The ARP monitor works by periodically checking the slave devices to determine
-   whether they have sent or received traffic recently (the precise criteria
-   depends upon the bonding mode, and the state of the slave). Regular traffic
-   is generated via ARP probes issued for the addresses specified by the
-   :cfgcmd:`arp-monitor target` option.
+   ARP monitoring periodically assesses the health of each member interface by 
+   checking whether it has recently sent or received traffic (this criterion 
+   varies depending on the bonding mode and the member interface’s state). ARP 
+   probes are sent to the IP addresses specified with the arp-monitor target option.
 
-   If ARP monitoring is used in an etherchannel compatible mode (modes
-   round-robin and xor-hash), the switch should be configured in a mode that
-   evenly distributes packets across all links. If the switch is configured to
-   distribute the packets in an XOR fashion, all replies from the ARP targets
-   will be received on the same link which could cause the other team members
-   to fail.
+   When ARP monitoring is used with EtherChannel-compatible modes (such as 
+   ``round-robin`` or ``xor-hash``), the switch should be configured to distribute 
+   traffic across all member interfaces. If the switch distributes traffic using 
+   an XOR-based policy, all ARP replies will be received on one member interface, 
+   causing other member interfaces to be incorrectly marked as failed. 
 
-   A value of 0 disables ARP monitoring. The default value is 0.
+   Setting this value to 0 disables ARP monitoring.
+
+   The default value is 0.
 
 .. cfgcmd:: set interfaces bonding <interface> arp-monitor target <address>
 
-   Specifies the IP addresses to use as ARP monitoring peers when
-   :cfgcmd:`arp-monitor interval` option is > 0. These are the targets of the
-   ARP request sent to determine the health of the link to the targets.
+   **Configure the IP addresses for ARP monitoring requests.**
+
+   The bonding driver sends ARP requests to these IP addresses to check the 
+   state of member interfaces.
 
-   Multiple target IP addresses can be specified. At least one IP address must
-   be given for ARP monitoring to function.
+   To enable ARP monitoring, configure at least one IP address (up to 16 per 
+   bonding interface). 
 
-   The maximum number of targets that can be specified is 16. The default value
-   is no IP address.
+   By default, no IP addresses are configured. 
 
-VLAN
-====
+:abbr:`VLAN (Virtual Local Area Network)`
+=========================================
 
 .. cmdinclude:: /_include/interface-vlan-8021q.txt
    :var0: bonding
    :var1: bond0
 
-Port Mirror (SPAN)
-==================
+SPAN port mirroring
+===================
 
 .. cmdinclude:: ../../_include/interface-mirror.txt
-   :var0: bondinging
+   :var0: bonding
    :var1: bond1
    :var2: eth3
 
-EVPN Multihoming
+EVPN multihoming
 ----------------
 
-All-Active Multihoming is used for redundancy and load sharing. Servers are
-attached to two or more PEs and the links are bonded (link-aggregation).
-This group of server links is referred to as an :abbr:`ES (Ethernet Segment)`.
+EVPN multihoming (EVPN-MH) is a standards-based solution (RFC 7432, RFC 8365) 
+that enables Customer Edge (CE) devices, such as servers, to connect to two 
+or more Provider Edge (PE) devices for redundancy and load balancing. 
 
-An Ethernet Segment can be configured by specifying a system-MAC and a local
-discriminator or a complete ESINAME against the bond interface on the PE.
+EVPN-MH is often used as a modern, standards-based alternative to 
+:abbr:`MLAG (Multi-Chassis Link Aggregation)` and :abbr:`VTEPs (Virtual 
+Tunnel Endpoints)`. 
 
-.. cfgcmd:: set interfaces bonding <interface> evpn es-id <<1-16777215|10-byte ID>
-.. cfgcmd:: set interfaces bonding <interface> evpn es-sys-mac <xx:xx:xx:xx:xx:xx>
+**Ethernet Segment (ES) and Ethernet Segment Identifier (ESI)**
 
-  The sys-mac and local discriminator are used for generating a 10-byte, Type-3
-  Ethernet Segment ID. ESINAME is a 10-byte, Type-0 Ethernet Segment ID -
-  "00:AA:BB:CC:DD:EE:FF:GG:HH:II".
+Physical links that connect a CE device to PE devices are bundled using link 
+aggregation. This logical bundle is called an Ethernet Segment (ES) and is 
+uniquely identified by an Ethernet Segment Identifier (ESI) within the 
+EVPN domain.
 
-  Type-1 (EAD-per-ES and EAD-per-EVI) routes are used to advertise the locally
-  attached ESs and to learn off remote ESs in the network. Local Type-2/MAC-IP
-  routes are also advertised with a destination ESI allowing for MAC-IP syncing
-  between Ethernet Segment peers. Reference: RFC 7432, RFC 8365
+To enable EVPN-MH, configure the same ESI on the bonding interfaces of all 
+PE devices connected to a single CE device.
 
-  EVPN-MH is intended as a replacement for MLAG or Anycast VTEPs. In multihoming
-  each PE has an unique VTEP address which requires the introduction of a new
-  dataplane construct, MAC-ECMP. Here a MAC/FDB entry can point to a list of
-  remote PEs/VTEPs.
+An ESI is configured by specifying either a system MAC address and a local 
+discriminator, or an Ethernet Segment Identifier Name (ESINAME).
 
-.. cfgcmd:: set interfaces bonding <interface> evpn es-df-pref <1-65535>
+The following two commands generate a 10-byte Type-3 ESI by combining the 
+system MAC and local discriminator: 
+
+.. cfgcmd:: set interfaces bonding <interface> evpn es-id <1-16777215|10-byte ID>
+.. cfgcmd:: set interfaces bonding <interface> evpn es-sys-mac <xx:xx:xx:xx:xx:xx>
 
-  Type-4 (ESR) routes are used for Designated Forwarder (DF) election.
-  DFs forward BUM traffic received via the overlay network. This
-  implementation uses a preference based DF election specified by
-  draft-ietf-bess-evpn-pref-df.
+  Alternatively, assign an ESINAME directly as a 10-byte Type-0 ESI using the 
+  following format: 00:AA:BB:CC:DD:EE:FF:GG:HH:II.
 
-  The DF preference is configurable per-ES.
+  **BGP-EVPN route usage**
 
-  BUM traffic is rxed via the overlay by all PEs attached to a server but
-  only the DF can forward the de-capsulated traffic to the access port.
-  To accommodate that non-DF filters are installed in the dataplane to drop
-  the traffic.
+  EVPN-MH uses BGP-EVPN route types 1 and 2 for ES discovery and MAC-IP 
+  synchronization:
 
-  Similarly traffic received from ES peers via the overlay cannot be forwarded
-  to the server. This is split-horizon-filtering with local bias.
+  * **Type 1 (EAD-per-ES and EAD-per-EVI)** routes advertise the locally 
+    attached ESs and discover remote ESs in the network. 
+  * **Type 2 (MAC-IP advertisement)** routes are advertised with a 
+    destination ESI, enabling MAC-IP synchronization between ES peers.
 
+.. cfgcmd:: set interfaces bonding <interface> evpn es-df-pref <1-65535>
+
+  **Configure the** :abbr:`DF (Designated Forwarder)` **preference (1-65535) for 
+  the interface. A higher value indicates a higher preference to become the** 
+  :abbr:`DF (Designated Forwarder)`. **The** :abbr:`DF (Designated Forwarder)` 
+  **preference is configured per-ES.**
+
+  The DF election process determines which interface in a specific ES forwards 
+  :abbr:`BUM (Broadcast, Unknown Unicast, and Multicast)` traffic from the EVPN 
+  overlay to the connected CE device. EVPN Type-4 (Ethernet Segment) routes are 
+  used to elect the DF, implementing the preference-based election method defined 
+  in RFC 9785.
+
+  Interfaces not elected as the DF drop any BUM traffic from the EVPN overlay 
+  using non-DF filters. Similarly, traffic received from ES peers via the EVPN 
+  overlay is blocked from forwarding to the CE device to maintain split-horizon 
+  filtering with local bias.
+  
 .. cmdinclude:: /_include/interface-evpn-uplink.txt
    :var0: bonding
    :var1: bond0
@@ -343,17 +423,18 @@ discriminator or a complete ESINAME against the bond interface on the PE.
 Example
 *******
 
-The following configuration on VyOS applies to all following 3rd party vendors.
-It creates a bond with two links and VLAN 10, 100 on the bonded interfaces with
-a per VIF IPv4 address.
+The following configuration example applies to all listed third-party vendors. 
+It creates a bonding interface with two member interfaces, defines VLANs 10 
+and 100 on the bonding interface, and assigns an IPv4 address to each VLAN 
+subinterface.
 
 .. code-block:: none
 
-  # Create bonding interface bond0 with 802.3ad LACP
+  # Create the bonding interface bond0 with 802.3ad LACP
   set interfaces bonding bond0 hash-policy 'layer2'
   set interfaces bonding bond0 mode '802.3ad'
 
-  # Add the required vlans and IPv4 addresses on them
+  # Add the required VLANs and IPv4 addresses on them
   set interfaces bonding bond0 vif 10 address 192.168.0.1/24
   set interfaces bonding bond0 vif 100 address 10.10.10.1/24
 
@@ -361,20 +442,21 @@ a per VIF IPv4 address.
   set interfaces bonding bond0 member interface eth1
   set interfaces bonding bond0 member interface eth2
 
+.. note:: If you are running this configuration in a virtual environment like 
+   EVE-NG, ensure the e1000 driver is chosen for your VyOS NIC. The default 
+   drivers, such as ``virtio-net-pci`` or ``vmxnet3``, are incompatible with 
+   this configuration. Specifically, ICMP messages will not be processed correctly.
 
-.. note:: If you happen to run this in a virtual environment like by EVE-NG
-   you need to ensure your VyOS NIC is set to use the e1000 driver. Using the
-   default ``virtio-net-pci`` or the ``vmxnet3`` driver will not work. ICMP
-   messages will not be properly processed. They are visible on the virtual wire
-   but will not make it fully up the networking stack.
-
-   You can check your NIC driver by issuing :opcmd:`show interfaces ethernet
+   To check your NIC driver, use the following command: :opcmd:`show interfaces ethernet
    eth0 physical | grep -i driver`
 
-Cisco Catalyst
-==============
+Cisco Catalyst configuration
+============================
 
-Assign member interfaces to PortChannel
+Configure a Cisco Catalyst switch to integrate with a two-member VyOS bonding 
+interface.
+
+Assign member interfaces to PortChannel:
 
 .. code-block:: none
 
@@ -387,8 +469,8 @@ Assign member interfaces to PortChannel
    channel-group 1 mode active
   !
 
-A new interface becomes present ``Port-channel1``, all configuration like
-allowed VLAN interfaces, STP will happen here.
+A new interface, ``Port-channel1``, becomes available; all configuration, 
+such as allowed VLAN interfaces and STP, is applied here.
 
 .. code-block:: none
 
@@ -401,11 +483,11 @@ allowed VLAN interfaces, STP will happen here.
   !
 
 
-Juniper EX Switch
-=================
+Juniper EX Switch configuration
+===============================
 
-For a headstart you can use the below example on how to build a bond with two
-interfaces from VyOS to a Juniper EX Switch system.
+Configure a Juniper EX Series switch to integrate with a two-member VyOS bonding 
+interface.
 
 .. code-block:: none
 
@@ -413,7 +495,7 @@ interfaces from VyOS to a Juniper EX Switch system.
   set interfaces ae0 aggregated-ether-options link-speed 10g
   set interfaces ae0 aggregated-ether-options lacp active
 
-  # Create layer 2 on the aggregated ethernet device with trunking for our vlans
+  # Create layer 2 on the aggregated ethernet device with trunking for our VLANs
   set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
 
   # Add the required vlans to the device
@@ -430,29 +512,29 @@ interfaces from VyOS to a Juniper EX Switch system.
   set interfaces xe-0/1/0 ether-options 802.3ad ae0
   set interfaces xe-1/1/0 ether-options 802.3ad ae0
 
-Aruba/HP
-========
+Aruba/HP configuration
+======================
 
-For a headstart you can use the below example on how to build a
-bond,port-channel with two interfaces from VyOS to a Aruba/HP 2510G switch.
+Configure an Aruba/HP 2510G switch to integrate with a two-member VyOS bonding 
+interface.
 
 .. code-block:: none
 
   # Create trunk with 2 member interfaces (interface 1 and 2) and LACP
   trunk 1-2 Trk1 LACP
 
-  # Add the required vlans to the trunk
+  # Add the required VLANs to the trunk
   vlan 10 tagged Trk1
   vlan 100 tagged Trk1
 
-Arista EOS
-==========
+Arista EOS configuration
+========================
 
-When utilizing VyOS in an environment with Arista gear you can use this blue
-print as an initial setup to get an LACP bond / port-channel operational between
-those two devices.
+When deploying VyOS in environments with Arista switches, use the following 
+blueprint as an initial setup to configure an operational LACP port-channel 
+between the two devices.
 
-Lets assume the following topology:
+Let's assume the following topology:
 
 .. figure:: /_static/images/vyos_arista_bond_lacp.png
    :alt: VyOS Arista EOS setup
@@ -555,10 +637,10 @@ Lets assume the following topology:
         channel-group 20 mode active
      !
 
-.. note:: When using EVE-NG to lab this environment ensure you are using e1000
-   as the desired driver for your VyOS network interfaces. When using the
-   regular virtio network driver no LACP PDUs will be sent by VyOS thus the
-   port-channel will never become active!
+.. note:: When testing this environment in EVE-NG, ensure the e1000 driver 
+   is chosen for your VyOS network interfaces. If the default virtio driver 
+   is used, VyOS will not transmit LACP PDUs, preventing the port-channel 
+   from ever becoming active.
 
 *********
 Operation
@@ -581,7 +663,7 @@ Operation
 
 .. opcmd:: show interfaces bonding <interface>
 
-   Show detailed information on given `<interface>`
+   Show detailed interface information.
 
    .. code-block:: none
 
@@ -598,8 +680,8 @@ Operation
 
 .. opcmd:: show interfaces bonding <interface> detail
 
-   Show detailed information about the underlaying physical links on given
-   bond `<interface>`.
+   Show detailed information about the underlying physical links on the given 
+   bonding interface.
 
    .. code-block:: none