Move shared iconography into a shared assets folder

content/articles/2022-12-05-oem-switch-1.md

@@ -578,7 +578,7 @@ the inner payload carries the `vlan 30` tag, neat! The `VNI` there is `0xca986`
 VLAN10 traffic (showing that multiple VLANs can be transported across the same tunnel, distinguished
 by VNI).
 
-{{< image width="90px" float="left" src="/assets/oem-switch/warning.png" alt="Warning" >}}
+{{< image width="90px" float="left" src="/assets/shared/warning.png" alt="Warning" >}}
 
 At this point I make an important observation. VxLAN and GENEVE both have this really cool feature
 that they can hash their _inner_ payload (ie. the IPv4/IPv6 address and ports if available) and use

content/articles/2023-05-28-vpp-mpls-4.md

@@ -187,7 +187,7 @@ MPLS-VRF:0, fib_index:0 locks:[interface:4, CLI:1, lcp-rt:1, ]
         [@1]: mpls via fe80::5054:ff:fe02:1001 GigabitEthernet10/0/0: mtu:9000 next:2 flags:[] 5254000210015254000310008847
 ```
 
-{{< image width="80px" float="left" src="/assets/vpp-mpls/lightbulb.svg" alt="Lightbulb" >}}
+{{< image width="80px" float="left" src="/assets/shared/lightbulb.svg" alt="Lightbulb" >}}
 
 Haha, I love it when the brain-ligutbulb goes to the _on_ position. What's happening is that when we
 turned on the MPLS feature on the VPP `tap` that is connected to `e0`, and VPP saw an MPLS packet,

content/articles/2023-11-11-mellanox-sn2700.md

@@ -543,7 +543,7 @@ Whoa, what just happened here? The switch took the port defined by `pci/0000:03:
 it is _splittable_ and has four lanes, and split it into four NEW ports called `swp1s0`-`swp1s3`,
 and the resulting ports are 25G, 10G or 1G.
 
-{{< image width="100px" float="left" src="/assets/oem-switch/warning.png" alt="Warning" >}}
+{{< image width="100px" float="left" src="/assets/shared/warning.png" alt="Warning" >}}
 
 However, I make an important observation. When splitting `swp1` in 4, the switch also removed port
 `swp2`, and remember at the beginning of this article I mentioned that the MAC addresses seemed to

content/articles/2023-12-17-defra0-debian.md

@@ -243,7 +243,7 @@ any prefixes, for example this session in Düsseldorf:
    };
 ```
 
-{{< image width="80px" float="left" src="/assets/debian-vpp/warning.png" alt="Warning" >}}
+{{< image width="80px" float="left" src="/assets/shared/warning.png" alt="Warning" >}}
 
 This is where it's a good idea to grab some tea. Quite a few internet providers have
 incredibly slow convergence, so just by stopping the announcment of `AS8298:AS-IPNG` prefixes at

content/articles/2024-01-27-vpp-papi.md

@@ -548,7 +548,7 @@ for table in api_reply:
     print(str)
 ```
 
-{{< image width="50px" float="left" src="/assets/vpp-papi/warning.png" alt="Warning" >}}
+{{< image width="50px" float="left" src="/assets/shared/warning.png" alt="Warning" >}}
 
 Funny detail - it took me almost two years to discover `VppEnum`, which contains all of these
 symbols. If you end up reading this after a Bing, Yahoo or DuckDuckGo search, feel free to buy

content/articles/2024-02-10-vpp-freebsd-1.md

@@ -47,7 +47,7 @@ we'll use for performance testing, notably to compare the FreeBSD kernel routing
 like `netmap`, and of course VPP itself. I do intend to do some side-by-side comparisons between
 Debian and FreeBSD when they run VPP.
 
-{{< image width="100px" float="left" src="/assets/freebsd-vpp/brain.png" alt="brain" >}}
+{{< image width="100px" float="left" src="/assets/shared/brain.png" alt="brain" >}}
 
 If you know me a little bit, you'll know that I typically forget how I did a thing, so I'm using
 this article for others as well as myself in case I want to reproduce this whole thing 5 years down

content/articles/2024-02-17-vpp-freebsd-2.md

@@ -163,7 +163,7 @@ interfaces a bit. They need to be:
 075.810547 main [301] Ready to go, ixl0 0x0/4 <-> ixl1 0x0/4.
 ```
 
-{{< image width="80px" float="left" src="/assets/freebsd-vpp/warning.png" alt="Warning" >}}
+{{< image width="80px" float="left" src="/assets/shared/warning.png" alt="Warning" >}}
 
 I start my first loadtest, which pretty immediately fails. It's an interesting behavior pattern which
 I've not seen before. After staring at the problem, and reading the code of `bridge.c`, which is a

content/articles/2024-03-06-vpp-babel-1.md

@@ -63,7 +63,7 @@ Let me discuss these two purposes in more detail:
 
 ### 1. IPv4 ARP, née IPv6 NDP
 
-{{< image width="100px" float="left" src="/assets/vpp-babel/brain.png" alt="Brain" >}}
+{{< image width="100px" float="left" src="/assets/shared/brain.png" alt="Brain" >}}
 
 One really neat trick is simply replacing ARP resolution by something that can resolve the
 link-layer MAC address in a different way. As it turns out, IPv6 has an equivalent that's

content/articles/2024-04-06-vpp-ospf.md

@@ -242,7 +242,7 @@ even if the interface link stays up.  It's described in detail in
 [[RFC5880](https://www.rfc-editor.org/rfc/rfc5880.txt)], and I use it at IPng Networks all over the
 place.
 
-{{< image width="100px" float="left" src="/assets/vpp-babel/brain.png" alt="Brain" >}}
+{{< image width="100px" float="left" src="/assets/shared/brain.png" alt="Brain" >}}
 
 Then I'll configure two OSPF protocols, one for IPv4 called `ospf4` and another for IPv6 called
 `ospf6`. It's easy to overlook, but while usually the IPv4 protocol is OSPFv2 and the IPv6 protocol

content/articles/2024-05-17-smtp.md

@@ -444,7 +444,7 @@ pim@squanchy:~$ sudo cat /etc/mail/secrets
 ipng bastion:<haha-made-you-look>
 ```
 
-{{< image width="120px" float="left" src="/assets/smtp/lightbulb.svg" alt="Lightbulb" >}}
+{{< image width="120px" float="left" src="/assets/shared/lightbulb.svg" alt="Lightbulb" >}}
 
 What happens here is, every time this server `squanchy` wants to send an e-mail, it will use an SMTP
 session with TLS, on port 587, of the machine called `smtp-out.ipng.ch`, and it'll authenticate

content/articles/2024-05-25-nat64-1.md

@@ -305,7 +305,7 @@ switches, I will announce:
     towards DNS64-rewritten destinations, for example 2001:678:d78:564::8c52:7903 as DNS64 representation
     of github.com, which is reachable only at legacy address 140.82.121.3.
 
-{{< image width="100px" float="left" src="/assets/nat64/brain.png" alt="Brain" >}}
+{{< image width="100px" float="left" src="/assets/shared/brain.png" alt="Brain" >}}
 
 I have to be careful with the announcements into OSPF. The cost of E1 routes is the cost of the
 external metric **in addition to** the internal cost within OSPF to reach that network. The cost

content/articles/2024-06-22-vpp-ospf-2.md

@@ -280,7 +280,7 @@ By commenting out the `addresses` field, and replacing it with `unnumbered: loop
 vppcfg to make Te6/0/0, which in Linux is called `xe1-0`, borrow its addresses from the loopback
 interface `loop0`.
 
-{{< image width="100px" float="left" src="/assets/freebsd-vpp/brain.png" alt="brain" >}}
+{{< image width="100px" float="left" src="/assets/shared/brain.png" alt="brain" >}}
 
 Planning and applying this is straight forward, but there's one detail I should
 mention. In my [[previous article]({{< ref "2024-04-06-vpp-ospf" >}})] I asked myself a question:

content/articles/2024-07-05-r86s.md

@@ -292,7 +292,7 @@ transmitting, or performing both receiving *and* transmitting.
 
 ### Intel X520 (10GbE)
 
-{{< image width="100px" float="left" src="/assets/oem-switch/warning.png" alt="Warning" >}}
+{{< image width="100px" float="left" src="/assets/shared/warning.png" alt="Warning" >}}
 
 This network card is based on the classic Intel _Niantic_ chipset, also known as the 82599ES chip,
 first released in 2009. It's super reliable, but there is one downside. It's a PCIe v2.0 device
@@ -462,7 +462,7 @@ ip4-rewrite                      active    14845221    35913927          0   8.9
 unix-epoll-input                 polling      22551           0          0   1.37e3          0.00
 ```
 
-{{< image width="100px" float="left" src="/assets/vpp-babel/brain.png" alt="Brain" >}}
+{{< image width="100px" float="left" src="/assets/shared/brain.png" alt="Brain" >}}
 
 I kind of wonder why that is. Is the Mellanox Connect-X3 such a poor performer? Or does it not like
 small packets? I've read online that Mellanox cards do some form of message compression on the PCI

content/articles/2024-08-03-gowin.md

@@ -407,7 +407,7 @@ loadtest:
 
 {{< image src="/assets/gowin-n305/cx5-cpu-rdma1q.png" alt="Cx5 CPU with 1Q" >}}
 
-{{< image width="100px" float="left" src="/assets/vpp-babel/brain.png" alt="Brain" >}}
+{{< image width="100px" float="left" src="/assets/shared/brain.png" alt="Brain" >}}
 
 Here I can clearly see that the one CPU thread (in yellow for unidirectional) and the two CPU
 therads (one for each of the bidirectional flows) jump up to 100% and stay there. This means that

static/assets/vpp-mpls/lightbulb.svg

@@ -1,81 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg
-   xmlns:dc="http://purl.org/dc/elements/1.1/"
-   xmlns:cc="http://creativecommons.org/ns#"
-   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
-   xmlns:svg="http://www.w3.org/2000/svg"
-   xmlns="http://www.w3.org/2000/svg"
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   version="1.1"
-   x="0px"
-   y="0px"
-   viewBox="0 0 93.533997 110"
-   xml:space="preserve"
-   id="svg30"
-   sodipodi:docname="noun_1263005_cc.svg"
-   width="93.533997"
-   height="110"
-   inkscape:version="0.92.2 5c3e80d, 2017-08-06"><metadata
-     id="metadata36"><rdf:RDF><cc:Work
-         rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
-           rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></metadata><defs
-     id="defs34" /><sodipodi:namedview
-     pagecolor="#ffffff"
-     bordercolor="#666666"
-     borderopacity="1"
-     objecttolerance="10"
-     gridtolerance="10"
-     guidetolerance="10"
-     inkscape:pageopacity="0"
-     inkscape:pageshadow="2"
-     inkscape:window-width="640"
-     inkscape:window-height="480"
-     id="namedview32"
-     showgrid="false"
-     fit-margin-top="10"
-     fit-margin-right="10"
-     fit-margin-bottom="10"
-     fit-margin-left="10"
-     inkscape:zoom="1.888"
-     inkscape:cx="46.767"
-     inkscape:cy="42.5"
-     inkscape:window-x="0"
-     inkscape:window-y="0"
-     inkscape:window-maximized="0"
-     inkscape:current-layer="svg30" /><g
-     id="g24"
-     transform="translate(-3.233,5)"><path
-       d="m 59.632,75.107 v -2.822 c 0,-4.96 2.015,-9.725 5.529,-13.073 4.396,-4.189 6.817,-9.839 6.817,-15.909 0,-12.119 -9.859,-21.978 -21.978,-21.978 -0.827,0 -1.667,0.046 -2.496,0.138 -10.5,1.161 -18.86,10.013 -19.447,20.591 -0.354,6.379 2.066,12.583 6.64,17.02 3.604,3.496 5.671,8.31 5.671,13.208 v 2.824 c 0,2.999 2.439,5.438 5.438,5.438 h 8.387 c 2.999,0.002 5.439,-2.438 5.439,-5.437 z m -4,0 c 0,0.793 -0.646,1.438 -1.438,1.438 h -8.387 c -0.793,0 -1.438,-0.646 -1.438,-1.438 v -2.824 c 0,-5.973 -2.51,-11.833 -6.886,-16.079 -3.741,-3.629 -5.721,-8.706 -5.431,-13.927 0.48,-8.65 7.312,-15.888 15.893,-16.837 0.684,-0.076 1.376,-0.114 2.057,-0.114 9.913,0 17.978,8.064 17.978,17.978 0,4.965 -1.98,9.586 -5.576,13.013 -4.302,4.099 -6.77,9.919 -6.77,15.969 v 2.821 z"
-       id="path2"
-       inkscape:connector-curvature="0" /><path
-       d="M 56.509,82.521 H 43.491 c -0.829,0 -1.5,0.671 -1.5,1.5 0,0.829 0.671,1.5 1.5,1.5 H 56.51 c 0.829,0 1.5,-0.671 1.5,-1.5 0,-0.829 -0.672,-1.5 -1.501,-1.5 z"
-       id="path4"
-       inkscape:connector-curvature="0" /><path
-       d="m 58.009,88.761 c 0,-0.829 -0.671,-1.5 -1.5,-1.5 H 43.491 c -0.829,0 -1.5,0.671 -1.5,1.5 0,0.829 0.671,1.5 1.5,1.5 H 56.51 c 0.828,0 1.499,-0.672 1.499,-1.5 z"
-       id="path6"
-       inkscape:connector-curvature="0" /><path
-       d="m 14.733,43.267 h 8.643 c 0.829,0 1.5,-0.671 1.5,-1.5 0,-0.829 -0.671,-1.5 -1.5,-1.5 h -8.643 c -0.829,0 -1.5,0.671 -1.5,1.5 0,0.829 0.671,1.5 1.5,1.5 z"
-       id="path8"
-       inkscape:connector-curvature="0" /><path
-       d="m 86.767,41.767 c 0,-0.829 -0.671,-1.5 -1.5,-1.5 h -8.643 c -0.829,0 -1.5,0.671 -1.5,1.5 0,0.829 0.671,1.5 1.5,1.5 h 8.643 c 0.829,0 1.5,-0.671 1.5,-1.5 z"
-       id="path10"
-       inkscape:connector-curvature="0" /><path
-       d="m 48.5,6.5 v 8.643 c 0,0.829 0.671,1.5 1.5,1.5 0.829,0 1.5,-0.671 1.5,-1.5 V 6.5 C 51.5,5.671 50.829,5 50,5 49.171,5 48.5,5.671 48.5,6.5 Z"
-       id="path12"
-       inkscape:connector-curvature="0" /><path
-       d="m 73.877,15.769 -6.111,6.111 c -0.586,0.585 -0.586,1.536 0,2.121 0.293,0.293 0.677,0.439 1.061,0.439 0.384,0 0.768,-0.146 1.061,-0.439 l 6.111,-6.111 c 0.586,-0.585 0.586,-1.536 0,-2.121 -0.587,-0.586 -1.536,-0.586 -2.122,0 z"
-       id="path14"
-       inkscape:connector-curvature="0" /><path
-       d="m 32.234,59.533 c -0.586,-0.586 -1.535,-0.586 -2.121,0 l -6.111,6.111 c -0.586,0.585 -0.586,1.535 0,2.121 0.293,0.293 0.677,0.439 1.061,0.439 0.384,0 0.768,-0.146 1.061,-0.439 l 6.111,-6.111 c 0.585,-0.585 0.585,-1.535 -10e-4,-2.121 z"
-       id="path16"
-       inkscape:connector-curvature="0" /><path
-       d="m 30.113,24.001 c 0.293,0.293 0.677,0.439 1.061,0.439 0.384,0 0.768,-0.146 1.061,-0.439 0.586,-0.585 0.586,-1.536 0,-2.121 l -6.111,-6.111 c -0.586,-0.586 -1.535,-0.586 -2.121,0 -0.586,0.585 -0.586,1.536 0,2.121 z"
-       id="path18"
-       inkscape:connector-curvature="0" /><path
-       d="m 73.877,67.765 c 0.293,0.293 0.677,0.439 1.061,0.439 0.384,0 0.768,-0.146 1.061,-0.439 0.586,-0.586 0.586,-1.536 0,-2.121 l -6.111,-6.111 c -0.586,-0.586 -1.535,-0.586 -2.121,0 -0.586,0.586 -0.586,1.536 0,2.121 z"
-       id="path20"
-       inkscape:connector-curvature="0" /><path
-       d="m 54.754,93.5 c 0,-0.829 -0.671,-1.5 -1.5,-1.5 h -6.509 c -0.829,0 -1.5,0.671 -1.5,1.5 0,0.829 0.671,1.5 1.5,1.5 h 6.509 c 0.829,0 1.5,-0.671 1.5,-1.5 z"
-       id="path22"
-       inkscape:connector-curvature="0" /></g></svg>