docs: fix stale .png/.jpg image refs to match .webp assets in Sagitta (#2098)

Signed-off-by: MilaNad <l.nadolina@vyos.io>

19 files changed, 26 insertions, 26 deletions

diff --git a/docs/configuration/firewall/flowtables.md b/docs/configuration/firewall/flowtables.md
index bc9fc457..9fab80b4 100644
--- a/docs/configuration/firewall/flowtables.md
+++ b/docs/configuration/firewall/flowtables.md
@@ -35,7 +35,7 @@ Flowtables allows 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.webp
 :::
 
 Once the first packet of the flow successfully goes through the IP forwarding
diff --git a/docs/configuration/firewall/index.md b/docs/configuration/firewall/index.md
index 53c5a7fc..58903314 100644
--- a/docs/configuration/firewall/index.md
+++ b/docs/configuration/firewall/index.md
@@ -15,7 +15,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.webp
 :::
 
 The main points regarding this packet flow and terminology used in VyOS
@@ -177,5 +177,5 @@ 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.webp
 :::
diff --git a/docs/configuration/firewall/ipv4.md b/docs/configuration/firewall/ipv4.md
index 23ff6c39..c020afb8 100644
--- a/docs/configuration/firewall/ipv4.md
+++ b/docs/configuration/firewall/ipv4.md
@@ -38,7 +38,7 @@ For transit traffic, which is received by the router and forwarded, 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.webp
 :::
 
 Where firewall base chain to configure firewall filtering rules for transit
@@ -51,7 +51,7 @@ A new simplified packet flow diagram is shown next, which shows the path
 for traffic destinated 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.webp
 :::
 
 Base chain is for traffic toward the router is `set firewall ipv4 input
diff --git a/docs/configuration/firewall/ipv6.md b/docs/configuration/firewall/ipv6.md
index e2db7928..9fd8988c 100644
--- a/docs/configuration/firewall/ipv6.md
+++ b/docs/configuration/firewall/ipv6.md
@@ -38,7 +38,7 @@ For transit traffic, which is received by the router and forwarded, 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.webp
 :::
 
 Where firewall base chain to configure firewall filtering rules for transit
@@ -51,7 +51,7 @@ A new simplified packet flow diagram is shown next, which shows the path
 for traffic destinated 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.webp
 :::
 
 Base chain is for traffic toward the router is `set firewall ipv6 input
diff --git a/docs/configuration/interfaces/bonding.md b/docs/configuration/interfaces/bonding.md
index ef6988e5..2c9ef2ba 100644
--- a/docs/configuration/interfaces/bonding.md
+++ b/docs/configuration/interfaces/bonding.md
@@ -473,7 +473,7 @@ those two devices.
 
 Lets assume the following topology:
 
-:::{figure} /_static/images/vyos_arista_bond_lacp.png
+:::{figure} /_static/images/vyos_arista_bond_lacp.webp
 :alt: VyOS Arista EOS setup
 :::
 
diff --git a/docs/configuration/interfaces/openvpn.md b/docs/configuration/interfaces/openvpn.md
index 5bd78695..1903d0db 100644
--- a/docs/configuration/interfaces/openvpn.md
+++ b/docs/configuration/interfaces/openvpn.md
@@ -33,7 +33,7 @@ interface using `set interfaces openvpn`.
 
 ## Site-to-Site
 
-:::{figure} /_static/images/openvpn_site2site_diagram.jpg
+:::{figure} /_static/images/openvpn_site2site_diagram.webp
 :::
 
 OpenVPN is popular for client-server setups, but its site-to-site mode
diff --git a/docs/configuration/interfaces/wireguard.md b/docs/configuration/interfaces/wireguard.md
index 3f69a7fe..ea97a0aa 100644
--- a/docs/configuration/interfaces/wireguard.md
+++ b/docs/configuration/interfaces/wireguard.md
@@ -14,7 +14,7 @@ information.
 
 This diagram corresponds with the example site to site configuration below.
 
-:::{figure} /_static/images/wireguard_site2site_diagram.jpg
+:::{figure} /_static/images/wireguard_site2site_diagram.webp
 :::
 
 ## Keypairs
@@ -425,7 +425,7 @@ public key. Please keep this in mind when using this convenience feature.
   will connect to. The address parameter can be used up to two times and is used
   to assign the clients specific IPv4 (/32) or IPv6 (/128) address.
 
-  .. figure:: /_static/images/wireguard_qrcode.jpg
+  .. figure:: /_static/images/wireguard_qrcode.webp
      :alt: WireGuard Client QR code
 ```
 
diff --git a/docs/configuration/loadbalancing/wan.md b/docs/configuration/loadbalancing/wan.md
index 272ba9e9..f59bf5ae 100644
--- a/docs/configuration/loadbalancing/wan.md
+++ b/docs/configuration/loadbalancing/wan.md
@@ -193,7 +193,7 @@ set load-balancing wan disable-source-nat
 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.webp
 :align: center
 :width: 80%
 ```
diff --git a/docs/configuration/nat/nat44.md b/docs/configuration/nat/nat44.md
index f7357f19..37a65149 100644
--- a/docs/configuration/nat/nat44.md
+++ b/docs/configuration/nat/nat44.md
@@ -676,7 +676,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.webp
 :alt: NAT before VPN Topology
 :scale: 100 %
 
diff --git a/docs/configuration/nat/nat66.md b/docs/configuration/nat/nat66.md
index 371da24f..34400485 100644
--- a/docs/configuration/nat/nat66.md
+++ b/docs/configuration/nat/nat66.md
@@ -102,7 +102,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.webp
 :alt: VyOS NAT66 Simple Configure
 :::
 
@@ -132,7 +132,7 @@ set service router-advert interface br1 prefix ::/0
 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.webp
 :alt: VyOS NAT66 DHCPv6 using a dummy interface
 :::
 
diff --git a/docs/configuration/policy/examples.md b/docs/configuration/policy/examples.md
index 992aa82c..926949c0 100644
--- a/docs/configuration/policy/examples.md
+++ b/docs/configuration/policy/examples.md
@@ -93,7 +93,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.webp
 :alt: PBR multiple uplinks
 :scale: 80 %
 
diff --git a/docs/configuration/protocols/pim.md b/docs/configuration/protocols/pim.md
index 1768be72..30f3d49b 100644
--- a/docs/configuration/protocols/pim.md
+++ b/docs/configuration/protocols/pim.md
@@ -257,7 +257,7 @@ source-specific multicast).
 
 In the following example we can see a basic multicast setup:
 
-```{image} /_static/images/multicast-basic.png
+```{image} /_static/images/multicast-basic.webp
 :align: center
 :alt: Network Topology Diagram
 :width: 90%
diff --git a/docs/configuration/service/conntrack-sync.md b/docs/configuration/service/conntrack-sync.md
index d82459df..d35007ff 100644
--- a/docs/configuration/service/conntrack-sync.md
+++ b/docs/configuration/service/conntrack-sync.md
@@ -244,7 +244,7 @@ can be restored before conntrack state is purged.
 
 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.webp
 :alt: Conntrack Sync Example
 :scale: 60 %
 :::
diff --git a/docs/configuration/service/dhcp-relay.md b/docs/configuration/service/dhcp-relay.md
index 4bbee82b..d5f12b5e 100644
--- a/docs/configuration/service/dhcp-relay.md
+++ b/docs/configuration/service/dhcp-relay.md
@@ -100,7 +100,7 @@ uplink to the DHCP server.
 - 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.webp
 :alt: DHCP relay example
 :scale: 80 %
 
@@ -195,7 +195,7 @@ show service dhcp-relay
 - 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.webp
 :alt: DHCPv6 relay example
 :scale: 80 %
 
diff --git a/docs/configuration/service/snmp.md b/docs/configuration/service/snmp.md
index c4976318..e64a6b3b 100644
--- a/docs/configuration/service/snmp.md
+++ b/docs/configuration/service/snmp.md
@@ -53,7 +53,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.webp
 :alt: Principle of SNMP Communication
 :scale: 20 %
 
diff --git a/docs/configuration/vpn/dmvpn.md b/docs/configuration/vpn/dmvpn.md
index 4d1525ad..79a6af7b 100644
--- a/docs/configuration/vpn/dmvpn.md
+++ b/docs/configuration/vpn/dmvpn.md
@@ -27,7 +27,7 @@ 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.webp
 :alt: Baseline DMVPN topology
 :scale: 40 %
 
@@ -186,7 +186,7 @@ This blueprint uses VyOS as the DMVPN Hub and Cisco (7206VXR) and VyOS as
 multiple spoke sites. The lab was built using {abbr}`EVE-NG (Emulated Virtual
 Environment NG)`.
 
-:::{figure} /_static/images/blueprint-dmvpn.png
+:::{figure} /_static/images/blueprint-dmvpn.webp
 :alt: DMVPN network
 
 DMVPN example network
diff --git a/docs/configuration/vpn/ipsec/ipsec_general.md b/docs/configuration/vpn/ipsec/ipsec_general.md
index ff8ac76e..6ff176fc 100644
--- a/docs/configuration/vpn/ipsec/ipsec_general.md
+++ b/docs/configuration/vpn/ipsec/ipsec_general.md
@@ -29,7 +29,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.webp
 :alt: AH and ESP in Transport Mode and Tunnel Mode
 :scale: 80 %
 :::
diff --git a/docs/configuration/vpn/ipsec/site2site_ipsec.md b/docs/configuration/vpn/ipsec/site2site_ipsec.md
index b813380f..153748f1 100644
--- a/docs/configuration/vpn/ipsec/site2site_ipsec.md
+++ b/docs/configuration/vpn/ipsec/site2site_ipsec.md
@@ -178,7 +178,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.webp
 :::
 
 Similar combinations are applicable for the dead-peer-detection.
diff --git a/docs/configuration/vrf/index.md b/docs/configuration/vrf/index.md
index a9100ada..3c5ed2bc 100644
--- a/docs/configuration/vrf/index.md
+++ b/docs/configuration/vrf/index.md
@@ -273,7 +273,7 @@ For VRF maintenance the following operational commands are in place.
 
 The following example topology was built using EVE-NG.
 
-:::{figure} /_static/images/vrf-example-topology-01.png
+:::{figure} /_static/images/vrf-example-topology-01.webp
 :alt: VRF topology example
 
 VRF route leaking