ipng/ipng.ch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Move shared iconography into a shared assets folder

Browse Source
This commit is contained in:
Pim van Pelt
2024-08-05 21:27:08 +02:00
parent 0542c1e2d9
commit 20022b77dd
26 changed files with 21 additions and 120 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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

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

@ -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,

2
content/articles/2023-11-11-mellanox-sn2700.md
View File

@ -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

2
content/articles/2023-12-17-defra0-debian.md
View File

@ -243,7 +243,7 @@ any prefixes, for example this session in D&uuml;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

2
content/articles/2024-01-27-vpp-papi.md
View File

@ -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

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

@ -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

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

@ -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

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

@ -63,7 +63,7 @@ Let me discuss these two purposes in more detail:
### 1. IPv4 ARP, n&eacute;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

2
content/articles/2024-04-06-vpp-ospf.md
View File

@ -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

2
content/articles/2024-05-17-smtp.md
View File

@ -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

2
content/articles/2024-05-25-nat64-1.md
View File

@ -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

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

@ -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:

4
content/articles/2024-07-05-r86s.md
View File

@ -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

2
content/articles/2024-08-03-gowin.md
View File

@ -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