DOC: Proofreading virtual, loopback, and dummy interfaces (#1745)

3 files changed, 47 insertions, 37 deletions

diff --git a/docs/configuration/interfaces/dummy.rst b/docs/configuration/interfaces/dummy.rst
index 945361c2..55c134e3 100644
--- a/docs/configuration/interfaces/dummy.rst
+++ b/docs/configuration/interfaces/dummy.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2023-01-20
+:lastproofread: 2026-01-23
 
 .. _dummy-interface:
 
@@ -6,22 +6,25 @@
 Dummy
 #####
 
-The dummy interface is really a little exotic, but rather useful nevertheless.
-Dummy interfaces are much like the :ref:`loopback-interface` interface, except
-you can have as many as you want.
+A dummy interface is a virtual network interface that operates like the 
+loopback interface, accepting traffic and routing it back to the local host. 
+Unlike the loopback interface, which is limited to one per system and reserved 
+for internal system use, multiple dummy interfaces can be created, removed, and 
+managed without impacting core operations.
 
-.. note:: Dummy interfaces can be used as interfaces that always stay up (in
-   the same fashion to loopbacks in Cisco IOS), or for testing purposes.
+As a software-based interface, the dummy interface does not depend on physical 
+link state and remains active as long as the operating system is running.
 
-.. hint:: On systems with multiple redundant uplinks and routes,
-   it's a good idea to use a dedicated address for management and dynamic routing protocols.
-   However, assigning that address to a physical link is risky:
-   if that link goes down, that address will become inaccessible.
-   A common solution is to assign the management address to a loopback or a dummy interface
-   and advertise that address via all physical links, so that it's reachable
-   through any of them. Since in Linux-based systems, there can be only one loopback interface,
-   it's better to use a dummy interface for that purpose, since they can be added, removed,
-   and taken up and down independently.
+Dummy interfaces are commonly used in environments with multiple redundant 
+uplinks (e.g., a server connected to two different switches), where assigning a 
+management IP address to a specific physical interface is risky. If that 
+interface fails, the management IP address becomes unreachable.
+
+Assigning the management IP address to a dummy interface and advertising it 
+over all available physical links ensures the address remains reachable as long 
+as at least one physical path is active.
+
+Dummy interfaces are also used for testing and simulation purposes.
 
 *************
 Configuration
@@ -64,7 +67,7 @@ Operation
 
 .. opcmd:: show interfaces dummy <interface>
 
-   Show detailed information on given `<interface>`
+   Show detailed interface information.
 
    .. code-block:: none
 
diff --git a/docs/configuration/interfaces/loopback.rst b/docs/configuration/interfaces/loopback.rst
index b5fbdf83..77b6e475 100644
--- a/docs/configuration/interfaces/loopback.rst
+++ b/docs/configuration/interfaces/loopback.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2023-01-20
+:lastproofread: 2026-01-23
 
 .. _loopback-interface:
 
@@ -6,20 +6,20 @@
 Loopback
 ########
 
-The loopback networking interface is a virtual network device implemented
-entirely in software. All traffic sent to it "loops back" and just targets
-services on your local machine.
+The loopback interface is a virtual, software-based network interface. All 
+traffic sent to it loops back and only targets services on the local host.
 
-.. note:: There can only be one loopback ``lo`` interface on the system. If
-   you need multiple interfaces, please use the :ref:`dummy-interface`
+.. note:: Only one loopback ``lo`` interface is allowed per operating system. 
+   If you require multiple virtual interfaces, use the :ref:`dummy-interface`
    interface type.
 
-.. hint:: A loopback interface is always up, thus it could be used for
-   management traffic or as source/destination for and :abbr:`IGP (Interior
-   Gateway Protocol)` like :ref:`routing-bgp` so your internal BGP link is not
-   dependent on physical link states and multiple routes can be chosen to the
-   destination. A :ref:`dummy-interface` Interface should always be preferred
-   over a :ref:`loopback-interface` interface.
+.. hint:: The loopback interface is always operational, making it suitable for 
+   management traffic or as a stable source/destination for routing protocols such 
+   as BGP. This ensures internal routing sessions remain independent of physical 
+   link states. 
+
+   However, in most cases, the dummy interface is preferred over the loopback 
+   interface.
 
 *************
 Configuration
@@ -55,7 +55,7 @@ Operation
 
 .. opcmd:: show interfaces loopback lo
 
-   Show detailed information on the given loopback interface `lo`.
+   Show detailed interface information.
 
    .. code-block:: none
 
diff --git a/docs/configuration/interfaces/virtual-ethernet.rst b/docs/configuration/interfaces/virtual-ethernet.rst
index 3324feb6..5df7e962 100644
--- a/docs/configuration/interfaces/virtual-ethernet.rst
+++ b/docs/configuration/interfaces/virtual-ethernet.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2022-11-25
+:lastproofread: 2026-01-26
 
 .. _virtual-ethernet:
 
@@ -6,11 +6,16 @@
 Virtual Ethernet
 ################
 
-The veth devices are virtual Ethernet devices. They can act as tunnels between
-network namespaces to create a bridge to a physical network device in another
-namespace or VRF, but can also be used as standalone network devices.
+Virtual Ethernet (veth) interfaces are software-based interfaces that operate 
+in pairs, creating a tunnel between each other. Traffic transmitted into one 
+interface of the pair (e.g., ``veth0``) is delivered directly to its peer 
+interface (e.g., ``veth1``). 
 
-.. note:: veth interfaces need to be created in pairs - it's called the peer name
+Veth interfaces are commonly used to connect network namespaces or VRFs, but 
+they can also function as standalone virtual network interfaces.
+
+.. note:: Veth interfaces must be created in pairs, where each interface acts 
+   as the peer of the other. 
 
 *************
 Configuration
@@ -26,6 +31,7 @@ Common interface configuration
 .. cmdinclude:: /_include/interface-description.txt
    :var0: virtual-ethernet
    :var1: veth0
+
 VLAN
 ====
 
@@ -35,7 +41,7 @@ Regular VLANs (802.1q)
    :var0: virtual-ethernet
    :var1: veth0
 
-QinQ (802.1ad)
+802.1ad (QinQ)
 --------------
 
 .. cmdinclude:: /_include/interface-vlan-8021ad.txt
@@ -69,7 +75,7 @@ Operation
 
 .. opcmd:: show interfaces virtual-ethernet <interface>
 
-   Show detailed information on given `<interface>`
+   Show detailed interface information.
 
    .. code-block:: none
 
@@ -91,7 +97,8 @@ Operation
 Example
 *******
 
-Interconnect the global VRF with vrf "red" using the veth10 <-> veth 11 pair
+The following example shows how to connect the global VRF to VRF ‘red ‘ using 
+the ``veth10`` and ``veth11`` veth pair.
 
 .. code-block:: none