From efd6ea180ad96a82ee8b0cc38582a9d505e794fb Mon Sep 17 00:00:00 2001 From: Yuriy Andamasov Date: Wed, 15 Apr 2026 12:08:34 +0300 Subject: perf: convert all images to WebP with PDF fallback MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add WebP versions of all 187 PNG/JPG images (38MB → 17MB, 55% reduction). Update RST/MD references to use Sphinx wildcard syntax (.*) so HTML builds use WebP while PDF/LaTeX builds fall back to original PNG/JPG. Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/configuration/firewall/bridge.rst | 6 +++--- docs/configuration/firewall/flowtables.rst | 2 +- docs/configuration/firewall/index.rst | 4 ++-- docs/configuration/firewall/ipv4.rst | 4 ++-- docs/configuration/firewall/ipv6.rst | 4 ++-- docs/configuration/interfaces/bonding.rst | 2 +- docs/configuration/interfaces/openvpn-examples.rst | 2 +- docs/configuration/interfaces/wireguard.rst | 4 ++-- docs/configuration/loadbalancing/wan.rst | 2 +- docs/configuration/nat/nat44.rst | 2 +- docs/configuration/nat/nat66.rst | 4 ++-- docs/configuration/policy/examples.rst | 2 +- docs/configuration/protocols/pim.rst | 2 +- docs/configuration/service/conntrack-sync.rst | 2 +- docs/configuration/service/dhcp-relay.rst | 4 ++-- docs/configuration/service/snmp.rst | 2 +- docs/configuration/vpn/dmvpn.rst | 4 ++-- docs/configuration/vpn/ipsec/ipsec_general.rst | 2 +- docs/configuration/vpn/ipsec/site2site_ipsec.rst | 2 +- docs/configuration/vrf/index.rst | 2 +- 20 files changed, 29 insertions(+), 29 deletions(-) (limited to 'docs/configuration') diff --git a/docs/configuration/firewall/bridge.rst b/docs/configuration/firewall/bridge.rst index 9c360d35..fdf1179f 100644 --- a/docs/configuration/firewall/bridge.rst +++ b/docs/configuration/firewall/bridge.rst @@ -47,13 +47,13 @@ For traffic that needs to be switched internally by the bridge, base chain is **forward**, and it's base command for filtering is ``set firewall bridge forward filter ...``, which happens in stage 4, highlighted with red color. -.. figure:: /_static/images/firewall-bridge-forward.png +.. figure:: /_static/images/firewall-bridge-forward.* For traffic destined to the router itself, or that needs to be routed (assuming a layer3 bridge is configured), the base chain is **input**, the base command is ``set firewall bridge input filter ...`` and the path is: -.. figure:: /_static/images/firewall-bridge-input.png +.. figure:: /_static/images/firewall-bridge-input.* If it's not dropped, then the packet is sent to **IP Layer**, and will be processed by the **IP Layer** firewall: IPv4 or IPv6 ruleset. Check once again @@ -64,7 +64,7 @@ And for traffic that originates from the bridge itself, the base chain is **output**, base command is ``set firewall bridge output filter ...``, and the path is: -.. figure:: /_static/images/firewall-bridge-output.png +.. figure:: /_static/images/firewall-bridge-output.* Custom bridge firewall chains can be created with the command ``set firewall bridge name ...``. In order to use such custom chain, a rule with action jump, diff --git a/docs/configuration/firewall/flowtables.rst b/docs/configuration/firewall/flowtables.rst index 915bf39d..35fb0add 100644 --- a/docs/configuration/firewall/flowtables.rst +++ b/docs/configuration/firewall/flowtables.rst @@ -34,7 +34,7 @@ Flowtables allow you to define a fastpath through the flowtable datapath. The flowtable supports for the layer 3 IPv4 and IPv6 and the layer 4 TCP and UDP protocols. -.. figure:: /_static/images/firewall-flowtable-packet-flow.png +.. figure:: /_static/images/firewall-flowtable-packet-flow.* Once the first packet of the flow successfully goes through the IP forwarding path (black circles path), from the second packet on, you might decide to diff --git a/docs/configuration/firewall/index.rst b/docs/configuration/firewall/index.rst index a5b88839..4fd9b208 100644 --- a/docs/configuration/firewall/index.rst +++ b/docs/configuration/firewall/index.rst @@ -20,7 +20,7 @@ A simplified traffic flow diagram, based on Netfilter packet flow, is shown next, in order to have a full view and understanding of how packets are processed, and what possible paths traffic can take. -.. figure:: /_static/images/firewall-gral-packet-flow.png +.. figure:: /_static/images/firewall-gral-packet-flow.* The main points regarding this packet flow and terminology used in VyOS firewall are covered below: @@ -224,4 +224,4 @@ As the example image below shows, the device now needs rules to allow/block traffic to or from the services running on the device that have open connections on that interface. -.. figure:: /_static/images/firewall-zonebased.png +.. figure:: /_static/images/firewall-zonebased.* diff --git a/docs/configuration/firewall/ipv4.rst b/docs/configuration/firewall/ipv4.rst index a9435fa8..4d54a68f 100644 --- a/docs/configuration/firewall/ipv4.rst +++ b/docs/configuration/firewall/ipv4.rst @@ -55,7 +55,7 @@ For transit traffic, which is received by the router and forwarded, the base chain is **forward**. A simplified packet flow diagram for transit traffic is shown next: -.. figure:: /_static/images/firewall-fwd-packet-flow.png +.. figure:: /_static/images/firewall-fwd-packet-flow.* The base firewall chain to configure filtering rules for transit traffic is ``set firewall ipv4 forward filter ...``, which happens in stage 5, @@ -67,7 +67,7 @@ A new simplified packet flow diagram is shown next, which shows the path for traffic destined to the router itself, and traffic generated by the router (starting from circle number 6): -.. figure:: /_static/images/firewall-input-packet-flow.png +.. figure:: /_static/images/firewall-input-packet-flow.* The base chain for traffic towards the router is ``set firewall ipv4 input filter ...`` diff --git a/docs/configuration/firewall/ipv6.rst b/docs/configuration/firewall/ipv6.rst index 95502f4a..905d0d20 100644 --- a/docs/configuration/firewall/ipv6.rst +++ b/docs/configuration/firewall/ipv6.rst @@ -55,7 +55,7 @@ For transit traffic, which is received by the router and forwarded, the base chain is **forward**. A simplified packet flow diagram for transit traffic is shown next: -.. figure:: /_static/images/firewall-fwd-packet-flow.png +.. figure:: /_static/images/firewall-fwd-packet-flow.* The base firewall chain to configure filtering rules for transit traffic is ``set firewall ipv6 forward filter ...``, which happens in stage 5, @@ -67,7 +67,7 @@ A new simplified packet flow diagram is shown next, which shows the path for traffic destined to the router itself, and traffic generated by the router (starting from circle number 6): -.. figure:: /_static/images/firewall-input-packet-flow.png +.. figure:: /_static/images/firewall-input-packet-flow.* The base chain for traffic towards the router is ``set firewall ipv6 input filter ...`` diff --git a/docs/configuration/interfaces/bonding.rst b/docs/configuration/interfaces/bonding.rst index e0a374c3..187720a9 100644 --- a/docs/configuration/interfaces/bonding.rst +++ b/docs/configuration/interfaces/bonding.rst @@ -536,7 +536,7 @@ between the two devices. Let's assume the following topology: -.. figure:: /_static/images/vyos_arista_bond_lacp.png +.. figure:: /_static/images/vyos_arista_bond_lacp.* :alt: VyOS Arista EOS setup **R1** diff --git a/docs/configuration/interfaces/openvpn-examples.rst b/docs/configuration/interfaces/openvpn-examples.rst index 46409975..bba04d9c 100644 --- a/docs/configuration/interfaces/openvpn-examples.rst +++ b/docs/configuration/interfaces/openvpn-examples.rst @@ -34,7 +34,7 @@ In both cases, we will use the following settings: router has a dynamic IP address. -.. figure:: /_static/images/openvpn_site2site_diagram.jpg +.. figure:: /_static/images/openvpn_site2site_diagram.* Set up site-to-site certificates -------------------------------- diff --git a/docs/configuration/interfaces/wireguard.rst b/docs/configuration/interfaces/wireguard.rst index 1f7c875f..e66b0fb8 100644 --- a/docs/configuration/interfaces/wireguard.rst +++ b/docs/configuration/interfaces/wireguard.rst @@ -16,7 +16,7 @@ Site-to-site VPN The following diagram illustrates a site-to-site VPN setup. -.. figure:: /_static/images/wireguard_site2site_diagram.jpg +.. figure:: /_static/images/wireguard_site2site_diagram.* ******** Keypairs @@ -425,7 +425,7 @@ simplify deployment, generate a per-mobile configuration from the VyOS CLI. to. The address parameter can be used twice to assign both an IPv4 (/32) and an IPv6 (/128) address to the client. - .. figure:: /_static/images/wireguard_qrcode.jpg + .. figure:: /_static/images/wireguard_qrcode.* :alt: WireGuard Client QR code .. stop_vyoslinter diff --git a/docs/configuration/loadbalancing/wan.rst b/docs/configuration/loadbalancing/wan.rst index 745cd8c2..b376f4fb 100644 --- a/docs/configuration/loadbalancing/wan.rst +++ b/docs/configuration/loadbalancing/wan.rst @@ -201,7 +201,7 @@ Sticky Connections Inbound connections to a WAN interface can be improperly handled when the reply is sent back to the client. -.. image:: /_static/images/sticky-connections.jpg +.. image:: /_static/images/sticky-connections.* :width: 80% :align: center diff --git a/docs/configuration/nat/nat44.rst b/docs/configuration/nat/nat44.rst index fb0d5af9..63b787ba 100644 --- a/docs/configuration/nat/nat44.rst +++ b/docs/configuration/nat/nat44.rst @@ -692,7 +692,7 @@ The ASP requests that all connections from this company should come from 172.29.41.89 - an address that is assigned by the ASP and not in use at the customer site. -.. figure:: /_static/images/nat_before_vpn_topology.png +.. figure:: /_static/images/nat_before_vpn_topology.* :scale: 100 % :alt: NAT before VPN Topology diff --git a/docs/configuration/nat/nat66.rst b/docs/configuration/nat/nat66.rst index 42f63fc9..31f6c002 100644 --- a/docs/configuration/nat/nat66.rst +++ b/docs/configuration/nat/nat66.rst @@ -124,7 +124,7 @@ Use the following topology to build a nat66 based isolated network between internal and external networks (dynamic prefix is not supported): -.. figure:: /_static/images/vyos_1_4_nat66_simple.png +.. figure:: /_static/images/vyos_1_4_nat66_simple.* :alt: VyOS NAT66 Simple Configure R1: @@ -154,7 +154,7 @@ R2: Use the following topology to translate internal user local addresses (``fc::/7``) to DHCPv6-PD provided prefixes from an ISP connected to a VyOS HA pair. -.. figure:: /_static/images/vyos_1_5_nat66_dhcpv6_wdummy.png +.. figure:: /_static/images/vyos_1_5_nat66_dhcpv6_wdummy.* :alt: VyOS NAT66 DHCPv6 using a dummy interface Configure both routers (a and b) for DHCPv6-PD via dummy interface: diff --git a/docs/configuration/policy/examples.rst b/docs/configuration/policy/examples.rst index d822d839..6c5c592a 100644 --- a/docs/configuration/policy/examples.rst +++ b/docs/configuration/policy/examples.rst @@ -99,7 +99,7 @@ Routing tables that will be used in this example are: * ``main`` Routing table used by VyOS and other interfaces not participating in PBR -.. figure:: /_static/images/pbr_example_1.png +.. figure:: /_static/images/pbr_example_1.* :scale: 80 % :alt: PBR multiple uplinks diff --git a/docs/configuration/protocols/pim.rst b/docs/configuration/protocols/pim.rst index 2e881943..019f1e64 100644 --- a/docs/configuration/protocols/pim.rst +++ b/docs/configuration/protocols/pim.rst @@ -218,7 +218,7 @@ Example In the following example we can see a basic multicast setup: -.. image:: /_static/images/multicast-basic.png +.. image:: /_static/images/multicast-basic.* :width: 90% :align: center :alt: Network Topology Diagram diff --git a/docs/configuration/service/conntrack-sync.rst b/docs/configuration/service/conntrack-sync.rst index 232db1a8..08b71eed 100644 --- a/docs/configuration/service/conntrack-sync.rst +++ b/docs/configuration/service/conntrack-sync.rst @@ -196,7 +196,7 @@ Example The next example is a simple configuration of conntrack-sync. -.. figure:: /_static/images/service_conntrack_sync-schema.png +.. figure:: /_static/images/service_conntrack_sync-schema.* :scale: 60 % :alt: Conntrack Sync Example diff --git a/docs/configuration/service/dhcp-relay.rst b/docs/configuration/service/dhcp-relay.rst index 632b2800..6a1b02f2 100644 --- a/docs/configuration/service/dhcp-relay.rst +++ b/docs/configuration/service/dhcp-relay.rst @@ -89,7 +89,7 @@ Example * Router receives DHCP client requests on ``eth1`` and relays them to the server at 10.0.1.4 on ``eth2``. -.. figure:: /_static/images/service_dhcp-relay01.png +.. figure:: /_static/images/service_dhcp-relay01.* :scale: 80 % :alt: DHCP relay example @@ -177,7 +177,7 @@ Example * Requests are forwarded through ``eth2`` as the `upstream interface` * External DHCPv6 server is at 2001:db8::4 -.. figure:: /_static/images/service_dhcpv6-relay01.png +.. figure:: /_static/images/service_dhcpv6-relay01.* :scale: 80 % :alt: DHCPv6 relay example diff --git a/docs/configuration/service/snmp.rst b/docs/configuration/service/snmp.rst index b444ab85..6dc13240 100644 --- a/docs/configuration/service/snmp.rst +++ b/docs/configuration/service/snmp.rst @@ -56,7 +56,7 @@ managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs may exist on any managed network. -.. figure:: /_static/images/service_snmp_communication_principles_diagram.png +.. figure:: /_static/images/service_snmp_communication_principles_diagram.* :scale: 20 % :alt: Principle of SNMP Communication diff --git a/docs/configuration/vpn/dmvpn.rst b/docs/configuration/vpn/dmvpn.rst index 59f5af1e..dc796fe8 100644 --- a/docs/configuration/vpn/dmvpn.rst +++ b/docs/configuration/vpn/dmvpn.rst @@ -27,7 +27,7 @@ peers. complete solution also incorporates the use of a routing protocol. BGP is particularly well suited for use with DMVPN. -.. figure:: /_static/images/vpn_dmvpn_topology01.png +.. figure:: /_static/images/vpn_dmvpn_topology01.* :scale: 40 % :alt: Baseline DMVPN topology @@ -195,7 +195,7 @@ Example This blueprint uses VyOS as the DMVPN Hub and Cisco IOSv 15.5(3)M and VyOS as multiple spoke sites. -.. figure:: /_static/images/blueprint-dmvpn.png +.. figure:: /_static/images/blueprint-dmvpn.* :width: 70% :align: center :alt: DMVPN Network Topology Diagram diff --git a/docs/configuration/vpn/ipsec/ipsec_general.rst b/docs/configuration/vpn/ipsec/ipsec_general.rst index 873f4f51..a9a1eb0f 100644 --- a/docs/configuration/vpn/ipsec/ipsec_general.rst +++ b/docs/configuration/vpn/ipsec/ipsec_general.rst @@ -32,7 +32,7 @@ There are two IPsec modes: another IP datagram, and an IPsec header (AH or ESP) is inserted between the outer and inner headers. -.. figure:: /_static/images/ESP_AH.png +.. figure:: /_static/images/ESP_AH.* :scale: 80 % :alt: AH and ESP in Transport Mode and Tunnel Mode diff --git a/docs/configuration/vpn/ipsec/site2site_ipsec.rst b/docs/configuration/vpn/ipsec/site2site_ipsec.rst index 227621ac..628b8e9d 100644 --- a/docs/configuration/vpn/ipsec/site2site_ipsec.rst +++ b/docs/configuration/vpn/ipsec/site2site_ipsec.rst @@ -184,7 +184,7 @@ The result of wrong value selection can be unstable work of the VPN. Below flow-chart could be a quick reference for the close-action combination depending on how the peer is configured. -.. figure:: /_static/images/IPSec_close_action_settings.png +.. figure:: /_static/images/IPSec_close_action_settings.* Similar combinations are applicable for the dead-peer-detection. diff --git a/docs/configuration/vrf/index.rst b/docs/configuration/vrf/index.rst index f41e98a2..d8b81bac 100644 --- a/docs/configuration/vrf/index.rst +++ b/docs/configuration/vrf/index.rst @@ -272,7 +272,7 @@ VRF route leaking The following example topology was built using EVE-NG. -.. figure:: /_static/images/vrf-example-topology-01.png +.. figure:: /_static/images/vrf-example-topology-01.* :alt: VRF topology example VRF route leaking -- cgit v1.2.3 From 5d4cdc95200e8ef8fa9ef0f52c5607b76e980692 Mon Sep 17 00:00:00 2001 From: Yuriy Andamasov Date: Tue, 21 Apr 2026 15:18:07 +0300 Subject: fix: suppress linter for real/protocol IPs in config examples MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The following files were touched by the WebP image PR and exposed pre-existing lint violations — real IPs needed for authenticity or actual protocol addresses (OSPF router-IDs, MAC-embedded IPv6): - inter-vrf-routing-vrf-lite.rst: 195.51.100.1, 198.51.0.0/16 - ipsec-cisco-route-based.rst: 1.1.1.1, 2.2.2.2, 1.0.0.0 (Cisco loopback/OSPF RID) - ipsec-pa-route-based.rst: 1.1.1.1, 2.2.2.2 (PA/VyOS OSPF RIDs) - lac-lns.rst: 8.8.8.8 (DNS example) - pppoe-ipv6-basic.rst: ::64 (prefix format illustration) - bridge.rst: 33:33::16:50:0 (MAC address in firewall log) 🤖 Generated by [robots](https://vyos.io) --- docs/configexamples/inter-vrf-routing-vrf-lite.rst | 7 ++++++- docs/configexamples/ipsec-cisco-route-based.rst | 15 +++++++++++++++ docs/configexamples/ipsec-pa-route-based.rst | 16 ++++++++++++++++ docs/configexamples/lac-lns.rst | 4 ++++ docs/configexamples/pppoe-ipv6-basic.rst | 5 +++++ docs/configuration/firewall/bridge.rst | 4 ++++ 6 files changed, 50 insertions(+), 1 deletion(-) (limited to 'docs/configuration') diff --git a/docs/configexamples/inter-vrf-routing-vrf-lite.rst b/docs/configexamples/inter-vrf-routing-vrf-lite.rst index fd4f6489..36dabd73 100644 --- a/docs/configexamples/inter-vrf-routing-vrf-lite.rst +++ b/docs/configexamples/inter-vrf-routing-vrf-lite.rst @@ -467,7 +467,7 @@ Now we perform some end-to-end testing - From Management to Outside (fails as intended) - +.. stop_vyoslinter .. code-block:: none @@ -515,6 +515,7 @@ Now we perform some end-to-end testing --- 2001:db8:2::1 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms +.. start_vyoslinter - LAN1 to Outside @@ -772,6 +773,8 @@ route-map with an prefix-list. We create a prefix-list first and add all the routes we need to. +.. stop_vyoslinter + .. code-block:: none # set both ipv4 and ipv6 policies @@ -795,6 +798,8 @@ We create a prefix-list first and add all the routes we need to. set policy prefix-list6 LAN2-Internet-v6 rule 4 action 'permit' set policy prefix-list6 LAN2-Internet-v6 rule 4 prefix '2001:db8:0:1::/64' +.. start_vyoslinter + Then add a route-map and reference to above prefix. Consider that the actions taken inside the prefix will MATCH the routes that will be affected by the actions inside the rules of the route-map. diff --git a/docs/configexamples/ipsec-cisco-route-based.rst b/docs/configexamples/ipsec-cisco-route-based.rst index 955c21d4..553c5e2a 100644 --- a/docs/configexamples/ipsec-cisco-route-based.rst +++ b/docs/configexamples/ipsec-cisco-route-based.rst @@ -89,6 +89,8 @@ Configuration VyOS ---- +.. stop_vyoslinter + .. code-block:: none set interfaces ethernet eth0 address '10.0.1.2/30' @@ -132,9 +134,13 @@ VyOS set vpn ipsec site-to-site peer CISCO remote-address '10.0.2.2' set vpn ipsec site-to-site peer CISCO vti bind 'vti1' +.. start_vyoslinter + Cisco ----- +.. stop_vyoslinter + .. code-block:: none crypto isakmp policy 10 @@ -196,6 +202,7 @@ Cisco ! ip route 0.0.0.0 0.0.0.0 10.0.2.1 +.. start_vyoslinter Monitoring @@ -230,6 +237,8 @@ IPsec SAs: OSPF Neighbor Status: +.. stop_vyoslinter + .. code-block:: none vyos@vyos:~$ show ip ospf neighbor @@ -237,6 +246,8 @@ OSPF Neighbor Status: Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL 1.1.1.1 1 Full/- 1h29m37s 39.317s 10.100.100.2 vti1:10.100.100.1 0 0 0 +.. start_vyoslinter + Routing Table: .. code-block:: none @@ -268,6 +279,8 @@ Routing Table: Monitoring on Cisco side ------------------------ +.. stop_vyoslinter + IKE SAs: .. code-block:: none @@ -378,6 +391,8 @@ Routing Table: C 192.168.11.0/24 is directly connected, GigabitEthernet0/2 L 192.168.11.1/32 is directly connected, GigabitEthernet0/2 +.. start_vyoslinter + Checking Connectivity --------------------- diff --git a/docs/configexamples/ipsec-pa-route-based.rst b/docs/configexamples/ipsec-pa-route-based.rst index 0b629041..96349d98 100644 --- a/docs/configexamples/ipsec-pa-route-based.rst +++ b/docs/configexamples/ipsec-pa-route-based.rst @@ -88,6 +88,8 @@ Configuration VyOS ---- +.. stop_vyoslinter + .. code-block:: none set interfaces ethernet eth0 address '10.0.1.2/30' @@ -131,9 +133,13 @@ VyOS set vpn ipsec site-to-site peer CISCO remote-address '10.0.2.2' set vpn ipsec site-to-site peer CISCO vti bind 'vti1' +.. start_vyoslinter + Palo Alto --------- +.. stop_vyoslinter + GUI Configuration: Network -> Network Profiles -> IKE Crypto @@ -225,6 +231,8 @@ CLI configuration with OSPF: set network virtual-router default protocol ospf router-id 1.1.1.1 set network virtual-router default interface [ ethernet1/1 ethernet1/2 ethernet1/3 tunnel.1 ] +.. start_vyoslinter + Monitoring ========== @@ -260,6 +268,8 @@ IPsec SAs: OSPF Neighbor Status: +.. stop_vyoslinter + .. code-block:: none vyos@vyos:~$ show ip ospf neighbor @@ -267,6 +277,8 @@ OSPF Neighbor Status: Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL 1.1.1.1 1 Full/- 23m56s 37.948s 10.100.100.2 vti1:10.100.100.1 0 0 0 +.. start_vyoslinter + Routing Table: @@ -337,6 +349,8 @@ IPsec SAs: OSPF Neighbor Status: +.. stop_vyoslinter + .. code-block:: none admin@PA-VM> show routing protocol ospf neighbor @@ -361,6 +375,8 @@ OSPF Neighbor Status: restart helper time remaining: 0 restart helper exit reason: none +.. start_vyoslinter + Routing Table: diff --git a/docs/configexamples/lac-lns.rst b/docs/configexamples/lac-lns.rst index 98bad773..f622b48f 100644 --- a/docs/configexamples/lac-lns.rst +++ b/docs/configexamples/lac-lns.rst @@ -79,6 +79,8 @@ LAC LNS --- +.. stop_vyoslinter + .. code-block:: none set interfaces ethernet eth0 address '192.168.139.100/24' @@ -96,6 +98,8 @@ LNS set vpn l2tp remote-access name-server '8.8.8.8' set vpn l2tp remote-access ppp-options disable-ccp +.. start_vyoslinter + .. note:: This setup requires the Compression Control Protocol (CCP) being disabled, the command ``set vpn l2tp remote-access ppp-options disable-ccp`` accomplishes that. diff --git a/docs/configexamples/pppoe-ipv6-basic.rst b/docs/configexamples/pppoe-ipv6-basic.rst index 520ca00b..cc14451c 100644 --- a/docs/configexamples/pppoe-ipv6-basic.rst +++ b/docs/configexamples/pppoe-ipv6-basic.rst @@ -51,8 +51,13 @@ delegation (PD). set interfaces pppoe pppoe0 ipv6 address autoconf set interfaces pppoe pppoe0 dhcpv6-options pd 0 interface eth1 address '100' +.. stop_vyoslinter + * Here we use the prefix to configure the address of eth1 (LAN) to form ``::64``, where ``64`` is hexadecimal of address 100. + +.. start_vyoslinter + * For home network users, most of time ISP only provides /64 prefix, hence there is no need to set SLA ID and prefix length. See :ref:`pppoe-interface` for more information. diff --git a/docs/configuration/firewall/bridge.rst b/docs/configuration/firewall/bridge.rst index 832bdf67..53775514 100644 --- a/docs/configuration/firewall/bridge.rst +++ b/docs/configuration/firewall/bridge.rst @@ -557,6 +557,8 @@ And op-mode commands: Inspect logs: +.. stop_vyoslinter + .. code-block:: none vyos@BRI:~$ show log firewall bridge @@ -567,3 +569,5 @@ Inspect logs: vyos@BRI:~$ show log firewall bridge forward filter Dec 05 14:42:22 kernel: [bri-FWD-filter-default-D]IN=eth2 OUT=eth1 MAC=33:33:00:00:00:16:50:00:00:06:00:00:86:dd SRC=0000:0000:0000:0000:0000:0000:0000:0000 DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=96 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=ICMPv6 TYPE=143 CODE=0 Dec 05 14:42:22 kernel: [bri-FWD-filter-default-D]IN=eth2 OUT=eth1 MAC=33:33:00:00:00:16:50:00:00:06:00:00:86:dd SRC=0000:0000:0000:0000:0000:0000:0000:0000 DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=96 TC=0 HOPLIMIT=1 FLOWLBL=0 PROTO=ICMPv6 TYPE=143 CODE=0 + +.. start_vyoslinter -- cgit v1.2.3 From d0a0fd4998b35af5b4e59374a5706ffeb27c7ee5 Mon Sep 17 00:00:00 2001 From: Yuriy Andamasov Date: Tue, 21 Apr 2026 20:35:22 +0300 Subject: fix: resolve all line-length lint warnings across 14 RST files MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Wrap prose lines exceeding 80 chars and apply stop/start_vyoslinter markers around cfgcmd/opcmd directive lines that cannot be shortened (e.g. long option names with placeholder arguments). Affected files: bonding, wireguard, pim, conntrack-sync, dmvpn, ipsec_general, site2site_ipsec, vrf/index, bare-metal, inter-vrf-routing-vrf-lite, lac-lns, tunnelbroker, OpenVPN_with_LDAP, dmvpn-dualhub-dualcloud. 🤖 Generated by [robots](https://vyos.io) --- .../OpenVPN_with_LDAP/OpenVPN_with_LDAP.rst | 17 +- .../autotest/tunnelbroker/tunnelbroker.rst | 14 +- docs/configexamples/dmvpn-dualhub-dualcloud.rst | 39 ++- docs/configexamples/inter-vrf-routing-vrf-lite.rst | 3 +- docs/configexamples/lac-lns.rst | 3 +- docs/configuration/interfaces/bonding.rst | 334 ++++++++++++--------- docs/configuration/interfaces/wireguard.rst | 39 ++- docs/configuration/protocols/pim.rst | 39 ++- docs/configuration/service/conntrack-sync.rst | 12 +- docs/configuration/vpn/dmvpn.rst | 60 ++-- docs/configuration/vpn/ipsec/ipsec_general.rst | 20 +- docs/configuration/vpn/ipsec/site2site_ipsec.rst | 24 +- docs/configuration/vrf/index.rst | 21 +- docs/installation/bare-metal.rst | 3 +- 14 files changed, 383 insertions(+), 245 deletions(-) (limited to 'docs/configuration') diff --git a/docs/configexamples/autotest/OpenVPN_with_LDAP/OpenVPN_with_LDAP.rst b/docs/configexamples/autotest/OpenVPN_with_LDAP/OpenVPN_with_LDAP.rst index 0ddd7e3e..ae997905 100644 --- a/docs/configexamples/autotest/OpenVPN_with_LDAP/OpenVPN_with_LDAP.rst +++ b/docs/configexamples/autotest/OpenVPN_with_LDAP/OpenVPN_with_LDAP.rst @@ -39,14 +39,22 @@ Here are some PowerShell commands to quickly add a Test Active Directory. Configure VyOS as OpenVPN Server ==================================== -In this example OpenVPN will be setup with a client certificate and username / password authentication. +In this example OpenVPN will be setup with a client certificate and +username / password authentication. -First a CA, a signed server and client ceftificate and a Diffie-Hellman parameter musst be generated and installed. -Please look :ref:`here ` for more information. +First a CA, a signed server and client ceftificate and a +Diffie-Hellman parameter musst be generated and installed. +Please look :ref:`here ` for more +information. | Add the LDAP plugin configuration file `/config/auth/ldap-auth.config` + +.. stop_vyoslinter + | Check all possible settings `here `_ +.. start_vyoslinter + .. literalinclude:: _include/ldap-auth.config :language: none @@ -93,7 +101,8 @@ OpenVPN Server configuration can be carried out. Client configuration ==================== -One advantage of having the client certificate stored is the ability to create the client configuration. +One advantage of having the client certificate stored is the ability to +create the client configuration. .. code-block:: none diff --git a/docs/configexamples/autotest/tunnelbroker/tunnelbroker.rst b/docs/configexamples/autotest/tunnelbroker/tunnelbroker.rst index a14a3199..e34cb779 100644 --- a/docs/configexamples/autotest/tunnelbroker/tunnelbroker.rst +++ b/docs/configexamples/autotest/tunnelbroker/tunnelbroker.rst @@ -220,9 +220,11 @@ Please note, 'autonomous-flag' and 'on-link-flag' are enabled by default, Firewall ======== -Finally, don't forget the :ref:`Firewall`. The usage is identical, except for -instead of `set firewall ipv4 name NAME`, you would use `set firewall ipv6 name -NAME`. - -Similarly, to attach the firewall, you would use `set firewall ipv6 name NAME rule N inbound-interface name eth0` or `set firewall zone LOCAL from WAN firewall -ipv6-name`. +Finally, don't forget the +:ref:`Firewall`. The usage is +identical, except instead of `set firewall ipv4 name NAME`, you would +use `set firewall ipv6 name NAME`. + +Similarly, to attach the firewall, you would use +`set firewall ipv6 name NAME rule N inbound-interface name eth0` or +`set firewall zone LOCAL from WAN firewall ipv6-name`. diff --git a/docs/configexamples/dmvpn-dualhub-dualcloud.rst b/docs/configexamples/dmvpn-dualhub-dualcloud.rst index 7bcfcf84..a3a4e619 100644 --- a/docs/configexamples/dmvpn-dualhub-dualcloud.rst +++ b/docs/configexamples/dmvpn-dualhub-dualcloud.rst @@ -6,11 +6,12 @@ DMVPN Dual HUB Dual Cloud ######################### -This document is to describe a basic setup to build DVMPN network with two Hubs and two clouds using DMVPN Phase3. +This document is to describe a basic setup to build DVMPN network with +two Hubs and two clouds using DMVPN Phase3. OSPF is used as routing protocol inside DMVPN. -In this example we use VyOS 1.5 as HUBs and Spokes (HUB-1, HUB-2, SPOKE-2, SPOKE-3) and Cisco IOSv 15.5(3)M (SPOKE-1) -as a Spoke. +In this example we use VyOS 1.5 as HUBs and Spokes (HUB-1, HUB-2, +SPOKE-2, SPOKE-3) and Cisco IOSv 15.5(3)M (SPOKE-1) as a Spoke. Network Topology ================ @@ -80,9 +81,12 @@ Spoke-3 NHRP configuration __________________ -The next step is to configure the NHRP protocol. In a Dual cloud network, every HUB has to be configured with one GRE -multipoint tunnel interface and every spoke has to be configured with two tunnel interfaces, one tunnel to each hub. -In this example tunnel networks are 10.100.100.0/24 for the first cloud and 10.100.101.0/24 for the second cloud. +The next step is to configure the NHRP protocol. In a Dual cloud +network, every HUB has to be configured with one GRE multipoint tunnel +interface and every spoke has to be configured with two tunnel +interfaces, one tunnel to each hub. +In this example tunnel networks are 10.100.100.0/24 for the first cloud +and 10.100.101.0/24 for the second cloud. But VyOS uses FRR for NHRP, that is why the tunnel address mask must be /32. HUB-1 @@ -211,8 +215,10 @@ Spoke-3 Overlay configuration _____________________ -The last step is to configure the routing protocol. In this scenario, OSPF was chosen as the dynamic routing protocol. -But you can use iBGP or eBGP. To form fast convergence it is possible to use BFD protocol. +The last step is to configure the routing protocol. In this scenario, +OSPF was chosen as the dynamic routing protocol. +But you can use iBGP or eBGP. To form fast convergence it is possible +to use BFD protocol. HUB-1 @@ -378,7 +384,8 @@ SPOKE-1 Monitoring ========== -All spokes created IPSec tunnels to Hubs, are registered on Hubs using NHRP protocol and formed adjacency in OSPF. +All spokes created IPSec tunnels to Hubs, are registered on Hubs using +NHRP protocol and formed adjacency in OSPF. .. code-block:: none @@ -468,7 +475,8 @@ For instance, traceroute was generated from PC-SPOKE-2 to PC-SPOKE-1 3 *192.168.11.2 3.241 ms (ICMP type:3, code:3, Destination port unreachable) First trace goes via HUB but the second goes directly from SPOKE-1 to SPOKE-2. -Now routing tables are changed. LAN networks 192.168.12.0/24 and 192.168.11.0/24 available directly via SPOKES. +Now routing tables are changed. LAN networks 192.168.12.0/24 and +192.168.11.0/24 available directly via SPOKES. .. code-block:: none @@ -541,8 +549,11 @@ A new Spoke to Spoke IPSec tunnel is created Summary ======= -If one of the Hubs loses connectivity to the Internet, the other Hub will be available and take the main role. -This is a simple example where only one internet connection is used. But in the real world, there can be two -connections to the Internet. In this case, there is a recommendation to build each tunnel via each Internet connection, -choose the main cloud, and manipulate traffic via a routing protocol. It allows the creation failover on link-level +If one of the Hubs loses connectivity to the Internet, the other Hub +will be available and take the main role. +This is a simple example where only one internet connection is used. +But in the real world, there can be two connections to the Internet. +In this case, there is a recommendation to build each tunnel via each +Internet connection, choose the main cloud, and manipulate traffic via +a routing protocol. It allows the creation failover on link-level connections too. \ No newline at end of file diff --git a/docs/configexamples/inter-vrf-routing-vrf-lite.rst b/docs/configexamples/inter-vrf-routing-vrf-lite.rst index 36dabd73..1f02da8e 100644 --- a/docs/configexamples/inter-vrf-routing-vrf-lite.rst +++ b/docs/configexamples/inter-vrf-routing-vrf-lite.rst @@ -16,7 +16,8 @@ where you might need that some network can access other in a different VRF. The scope of this document is to cover such cases in a dynamic way without the use of MPLS-LDP. -General information about L3VPNs can be found in the :ref:`configuration/vrf/index:L3VPN VRFs` chapter. +General information about L3VPNs can be found in the +:ref:`configuration/vrf/index:L3VPN VRFs` chapter. ******** Overview diff --git a/docs/configexamples/lac-lns.rst b/docs/configexamples/lac-lns.rst index f622b48f..5f344d54 100644 --- a/docs/configexamples/lac-lns.rst +++ b/docs/configexamples/lac-lns.rst @@ -101,7 +101,8 @@ LNS .. start_vyoslinter .. note:: This setup requires the Compression Control Protocol (CCP) - being disabled, the command ``set vpn l2tp remote-access ppp-options disable-ccp`` + being disabled, the command + ``set vpn l2tp remote-access ppp-options disable-ccp`` accomplishes that. Client diff --git a/docs/configuration/interfaces/bonding.rst b/docs/configuration/interfaces/bonding.rst index 187720a9..7637790c 100644 --- a/docs/configuration/interfaces/bonding.rst +++ b/docs/configuration/interfaces/bonding.rst @@ -62,20 +62,23 @@ Bond modes :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. + - 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. + - 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:** @@ -92,15 +95,16 @@ Bond modes :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. + - 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`` @@ -109,11 +113,12 @@ Bond modes * - **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. + * - **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`` @@ -122,12 +127,13 @@ Bond modes * - **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. + * - **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`` @@ -136,14 +142,15 @@ Bond modes * - **Description:** - Provides adaptive transmit load balancing and fault tolerance. - * - **Traffic distribution:** - - **Outgoing:** Distributed across all active member interfaces based on - the current load. + * - **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. + **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`` @@ -151,75 +158,88 @@ Bond modes :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. + - 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. + **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. + 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. + - 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)`. + * ``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 min-links <0-16> - **Configure how many member interfaces must be active (in the link-up state) to - mark the bonding interface UP (carrier asserted).** + **Configure how many member interfaces must be active (in the + link-up state) to mark the bonding interface UP (carrier + asserted).** - 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. + 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 marks the bonding interface UP (carrier asserted) - whenever an active LACP aggregator exists, regardless of the number of member - interfaces 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:: 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). + .. 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 lacp-rate - **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.** + **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.** - This command applies only when the bonding interface is configured in - 802.3ad mode. + This command applies only when the bonding interface is configured + in 802.3ad mode. The following options are available: - * **slow (default):** Requests the link partner to transmit LACPDUs every 30 seconds. + * **slow (default):** Requests the link partner to transmit + LACPDUs every 30 seconds. - * **fast:** Requests the link partner to transmit LACPDUs every 1 second. + * **fast:** Requests the link partner to transmit LACPDUs every + 1 second. .. cfgcmd:: set interfaces bonding system-mac **Configure a specific MAC address for the bonding interface.** - 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. + 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. .. cfgcmd:: set interfaces bonding hash-policy - **Configure which transmit hash policy to use for distributing traffic across - member interfaces.** + **Configure which transmit hash policy to use for distributing + traffic across member interfaces.** The following policies are available: @@ -229,10 +249,12 @@ Bond modes :widths: 20 80 * - **Description:** - - Routes all traffic destined for a specific network peer through the same - member interface. The policy is 802.3ad-compliant. + - 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. + - Source MAC address, destination MAC address, and Ethernet + packet type ID. * - **Formula:** - .. code-block:: none @@ -245,13 +267,16 @@ Bond modes :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. + - 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``. + - * 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 @@ -269,18 +294,21 @@ Bond modes :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. + - 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``. + * Source IP address, destination IP address. IPv6 + addresses are first hashed using ``IPv6_addr_hash``. * - **Formula:** - .. code-block:: none @@ -290,8 +318,9 @@ Bond modes 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 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``. @@ -299,29 +328,33 @@ Bond modes **Configure the primary member interface in the bond.** - The primary member interface remains active as long as it is operational; - alternative member interfaces are used only if it fails. + The primary member interface remains active as long as it is + operational; alternative member interfaces are used only if it + fails. - Use this configuration when a specific member interface is preferred, - such as one with higher throughput. + Use this configuration when a specific member interface is + preferred, such as one with higher throughput. - This command applies only to ``active-backup``, ``transmit-load-balance``, and - ``adaptive-load-balance`` modes. + This command applies only to ``active-backup``, + ``transmit-load-balance``, and ``adaptive-load-balance`` modes. .. cfgcmd:: set interfaces bonding arp-monitor interval