From fdb77838b8b04c9de622fad01d2fec97e091c1b6 Mon Sep 17 00:00:00 2001 From: Pim van Pelt Date: Sun, 4 May 2025 21:54:16 +0200 Subject: [PATCH] Rewrite github.com to git.ipng.ch for popular repos --- content/articles/2021-08-13-vpp-2.md | 12 ++++++------ content/articles/2021-08-15-vpp-3.md | 8 ++++---- content/articles/2021-08-25-vpp-4.md | 14 +++++++------- content/articles/2021-09-02-vpp-5.md | 4 ++-- content/articles/2021-09-10-vpp-6.md | 8 ++++---- content/articles/2021-09-21-vpp-7.md | 2 +- content/articles/2021-12-23-vpp-playground.md | 4 ++-- content/articles/2022-03-27-vppcfg-1.md | 4 ++-- content/articles/2022-04-02-vppcfg-2.md | 2 +- content/articles/2023-02-12-fitlet2.md | 4 ++-- content/articles/2023-02-24-coloclue-vpp-2.md | 6 +++--- content/articles/2023-04-09-vpp-stats.md | 6 +++--- content/articles/2023-05-07-vpp-mpls-1.md | 2 +- content/articles/2023-05-21-vpp-mpls-3.md | 2 +- content/articles/2023-05-28-vpp-mpls-4.md | 2 +- content/articles/2023-10-21-vpp-ixp-gateway-1.md | 2 +- content/articles/2024-03-06-vpp-babel-1.md | 4 ++-- content/articles/2024-04-06-vpp-ospf.md | 2 +- content/articles/2024-06-22-vpp-ospf-2.md | 6 +++--- content/articles/2025-02-08-sflow-3.md | 2 +- content/articles/2025-05-04-containerlab-2.md | 2 +- 21 files changed, 49 insertions(+), 49 deletions(-) diff --git a/content/articles/2021-08-13-vpp-2.md b/content/articles/2021-08-13-vpp-2.md index 22b2be6..814bc36 100644 --- a/content/articles/2021-08-13-vpp-2.md +++ b/content/articles/2021-08-13-vpp-2.md @@ -89,7 +89,7 @@ lcp lcp-sync off ``` The prep work for the rest of the interface syncer starts with this -[[commit](https://github.com/pimvanpelt/lcpng/commit/2d00de080bd26d80ce69441b1043de37e0326e0a)], and +[[commit](https://git.ipng.ch/ipng/lcpng/commit/2d00de080bd26d80ce69441b1043de37e0326e0a)], and for the rest of this blog post, the behavior will be in the 'on' position. ### Change interface: state @@ -120,7 +120,7 @@ the state it was. I did notice that you can't bring up a sub-interface if its pa is down, which I found counterintuitive, but that's neither here nor there. All of this is to say that we have to be careful when copying state forward, because as -this [[commit](https://github.com/pimvanpelt/lcpng/commit/7c15c84f6c4739860a85c599779c199cb9efef03)] +this [[commit](https://git.ipng.ch/ipng/lcpng/commit/7c15c84f6c4739860a85c599779c199cb9efef03)] shows, issuing `set int state ... up` on an interface, won't touch its sub-interfaces in VPP, but the subsequent netlink message to bring the _LIP_ for that interface up, **will** update the children, thus desynchronising Linux and VPP: Linux will have interface **and all its @@ -128,7 +128,7 @@ sub-interfaces** up unconditionally; VPP will have the interface up and its sub- whatever state they were before. To address this, a second -[[commit](https://github.com/pimvanpelt/lcpng/commit/a3dc56c01461bdffcac8193ead654ae79225220f)] was +[[commit](https://git.ipng.ch/ipng/lcpng/commit/a3dc56c01461bdffcac8193ead654ae79225220f)] was needed. I'm not too sure I want to keep this behavior, but for now, it results in an intuitive end-state, which is that all interfaces states are exactly the same between Linux and VPP. @@ -157,7 +157,7 @@ DBGvpp# set int state TenGigabitEthernet3/0/0 up ### Change interface: MTU Finally, a straight forward -[[commit](https://github.com/pimvanpelt/lcpng/commit/39bfa1615fd1cafe5df6d8fc9d34528e8d3906e2)], or +[[commit](https://git.ipng.ch/ipng/lcpng/commit/39bfa1615fd1cafe5df6d8fc9d34528e8d3906e2)], or so I thought. When the MTU changes in VPP (with `set interface mtu packet N `), there is callback that can be registered which copies this into the _LIP_. I did notice a specific corner case: In VPP, a sub-interface can have a larger MTU than its parent. In Linux, this cannot happen, @@ -179,7 +179,7 @@ higher than that, perhaps logging an error explaining why. This means two things 1. Any change in VPP of a parent MTU should ensure all children are clamped to at most that. I addressed the issue in this -[[commit](https://github.com/pimvanpelt/lcpng/commit/79a395b3c9f0dae9a23e6fbf10c5f284b1facb85)]. +[[commit](https://git.ipng.ch/ipng/lcpng/commit/79a395b3c9f0dae9a23e6fbf10c5f284b1facb85)]. ### Change interface: IP Addresses @@ -199,7 +199,7 @@ VPP into the companion Linux devices: _LIP_ with `lcp_itf_set_interface_addr()`. This means with this -[[commit](https://github.com/pimvanpelt/lcpng/commit/f7e1bb951d648a63dfa27d04ded0b6261b9e39fe)], at +[[commit](https://git.ipng.ch/ipng/lcpng/commit/f7e1bb951d648a63dfa27d04ded0b6261b9e39fe)], at any time a new _LIP_ is created, the IPv4 and IPv6 address on the VPP interface are fully copied over by the third change, while at runtime, new addresses can be set/removed as well by the first and second change. diff --git a/content/articles/2021-08-15-vpp-3.md b/content/articles/2021-08-15-vpp-3.md index 4abf31a..67a6acf 100644 --- a/content/articles/2021-08-15-vpp-3.md +++ b/content/articles/2021-08-15-vpp-3.md @@ -100,7 +100,7 @@ linux-cp { Based on this config, I set the startup default in `lcp_set_lcp_auto_subint()`, but I realize that an administrator may want to turn it on/off at runtime, too, so I add a CLI getter/setter that -interacts with the flag in this [[commit](https://github.com/pimvanpelt/lcpng/commit/d23aab2d95aabcf24efb9f7aecaf15b513633ab7)]: +interacts with the flag in this [[commit](https://git.ipng.ch/ipng/lcpng/commit/d23aab2d95aabcf24efb9f7aecaf15b513633ab7)]: ``` DBGvpp# show lcp @@ -116,11 +116,11 @@ lcp lcp-sync off ``` The prep work for the rest of the interface syncer starts with this -[[commit](https://github.com/pimvanpelt/lcpng/commit/2d00de080bd26d80ce69441b1043de37e0326e0a)], and +[[commit](https://git.ipng.ch/ipng/lcpng/commit/2d00de080bd26d80ce69441b1043de37e0326e0a)], and for the rest of this blog post, the behavior will be in the 'on' position. The code for the configuration toggle is in this -[[commit](https://github.com/pimvanpelt/lcpng/commit/934446dcd97f51c82ddf133ad45b61b3aae14b2d)]. +[[commit](https://git.ipng.ch/ipng/lcpng/commit/934446dcd97f51c82ddf133ad45b61b3aae14b2d)]. ### Auto create/delete sub-interfaces @@ -145,7 +145,7 @@ I noticed that interface deletion had a bug (one that I fell victim to as well: remove the netlink device in the correct network namespace), which I fixed. The code for the auto create/delete and the bugfix is in this -[[commit](https://github.com/pimvanpelt/lcpng/commit/934446dcd97f51c82ddf133ad45b61b3aae14b2d)]. +[[commit](https://git.ipng.ch/ipng/lcpng/commit/934446dcd97f51c82ddf133ad45b61b3aae14b2d)]. ### Further Work diff --git a/content/articles/2021-08-25-vpp-4.md b/content/articles/2021-08-25-vpp-4.md index ac9310f..67d748a 100644 --- a/content/articles/2021-08-25-vpp-4.md +++ b/content/articles/2021-08-25-vpp-4.md @@ -154,7 +154,7 @@ For now, `lcp_nl_dispatch()` just throws the message away after logging it with a function that will come in very useful as I start to explore all the different Netlink message types. The code that forms the basis of our Netlink Listener lives in [[this -commit](https://github.com/pimvanpelt/lcpng/commit/c4e3043ea143d703915239b2390c55f7b6a9b0b1)] and +commit](https://git.ipng.ch/ipng/lcpng/commit/c4e3043ea143d703915239b2390c55f7b6a9b0b1)] and specifically, here I want to call out I was not the primary author, I worked off of Matt and Neale's awesome work in this pending [Gerrit](https://gerrit.fd.io/r/c/vpp/+/31122). @@ -182,7 +182,7 @@ Linux interface VPP is not aware of. But, if I can find the _LIP_, I can convert add or remove the ip4/ip6 neighbor adjacency. The code for this first Netlink message handler lives in this -[[commit](https://github.com/pimvanpelt/lcpng/commit/30bab1d3f9ab06670fbef2c7c6a658e7b77f7738)]. An +[[commit](https://git.ipng.ch/ipng/lcpng/commit/30bab1d3f9ab06670fbef2c7c6a658e7b77f7738)]. An ironic insight is that after writing the code, I don't think any of it will be necessary, because the interface plugin will already copy ARP and IPv6 ND packets back and forth and itself update its neighbor adjacency tables; but I'm leaving the code in for now. @@ -197,7 +197,7 @@ it or remove it, and if there are no link-local addresses left, disable IPv6 on There's also a few multicast routes to add (notably 224.0.0.0/24 and ff00::/8, all-local-subnet). The code for IP address handling is in this -[[commit]](https://github.com/pimvanpelt/lcpng/commit/87742b4f541d389e745f0297d134e34f17b5b485), but +[[commit]](https://git.ipng.ch/ipng/lcpng/commit/87742b4f541d389e745f0297d134e34f17b5b485), but when I took it out for a spin, I noticed something curious, looking at the log lines that are generated for the following sequence: @@ -236,7 +236,7 @@ interface and directly connected route addition/deletion is slightly different i So, I decide to take a little shortcut -- if an addition returns "already there", or a deletion returns "no such entry", I'll just consider it a successful addition and deletion respectively, saving my eyes from being screamed at by this red error message. I changed that in this -[[commit](https://github.com/pimvanpelt/lcpng/commit/d63fbd8a9a612d038aa385e79a57198785d409ca)], +[[commit](https://git.ipng.ch/ipng/lcpng/commit/d63fbd8a9a612d038aa385e79a57198785d409ca)], turning this situation in a friendly green notice instead. ### Netlink: Link (existing) @@ -267,7 +267,7 @@ To avoid this loop, I temporarily turn off `lcp-sync` just before handling a bat turn it back to its original state when I'm done with that. The code for all/del of existing links is in this -[[commit](https://github.com/pimvanpelt/lcpng/commit/e604dd34784e029b41a47baa3179296d15b0632e)]. +[[commit](https://git.ipng.ch/ipng/lcpng/commit/e604dd34784e029b41a47baa3179296d15b0632e)]. ### Netlink: Link (new) @@ -276,7 +276,7 @@ doesn't have a _LIP_ for, but specifically describes a VLAN interface? Well, th is trying to create a new sub-interface. And supporting that operation would be super cool, so let's go! Using the earlier placeholder hint in `lcp_nl_link_add()` (see the previous -[[commit](https://github.com/pimvanpelt/lcpng/commit/e604dd34784e029b41a47baa3179296d15b0632e)]), +[[commit](https://git.ipng.ch/ipng/lcpng/commit/e604dd34784e029b41a47baa3179296d15b0632e)]), I know that I've gotten a NEWLINK request but the Linux ifindex doesn't have a _LIP_. This could be because the interface is entirely foreign to VPP, for example somebody created a dummy interface or a VLAN sub-interface on one: @@ -331,7 +331,7 @@ a boring `.` name. Alright, without further ado, the code for the main innovation here, the implementation of `lcp_nl_link_add_vlan()`, is in this -[[commit](https://github.com/pimvanpelt/lcpng/commit/45f408865688eb7ea0cdbf23aa6f8a973be49d1a)]. +[[commit](https://git.ipng.ch/ipng/lcpng/commit/45f408865688eb7ea0cdbf23aa6f8a973be49d1a)]. ## Results diff --git a/content/articles/2021-09-02-vpp-5.md b/content/articles/2021-09-02-vpp-5.md index 5538d68..ddcbb16 100644 --- a/content/articles/2021-09-02-vpp-5.md +++ b/content/articles/2021-09-02-vpp-5.md @@ -118,7 +118,7 @@ or Virtual Routing/Forwarding domains). So first, I need to add these: All of this code was heavily inspired by the pending [[Gerrit](https://gerrit.fd.io/r/c/vpp/+/31122)] but a few finishing touches were added, and wrapped up in this -[[commit](https://github.com/pimvanpelt/lcpng/commit/7a76498277edc43beaa680e91e3a0c1787319106)]. +[[commit](https://git.ipng.ch/ipng/lcpng/commit/7a76498277edc43beaa680e91e3a0c1787319106)]. ### Deletion @@ -459,7 +459,7 @@ it as 'unreachable' rather than deleting it. These are *additions* which have a but with an interface index of 1 (which, in Netlink, is 'lo'). This makes VPP intermittently crash, so I currently commented this out, while I gain better understanding. Result: blackhole/unreachable/prohibit specials can not be set using the plugin. Beware! -(disabled in this [[commit](https://github.com/pimvanpelt/lcpng/commit/7c864ed099821f62c5be8cbe9ed3f4dd34000a42)]). +(disabled in this [[commit](https://git.ipng.ch/ipng/lcpng/commit/7c864ed099821f62c5be8cbe9ed3f4dd34000a42)]). ## Credits diff --git a/content/articles/2021-09-10-vpp-6.md b/content/articles/2021-09-10-vpp-6.md index a704b92..8ba0da1 100644 --- a/content/articles/2021-09-10-vpp-6.md +++ b/content/articles/2021-09-10-vpp-6.md @@ -88,7 +88,7 @@ stat['/if/rx-miss'][:, 1].sum() - returns the sum of packet counters for ``` Alright, so let's grab that file and refactor it into a small library for me to use, I do -this in [[this commit](https://github.com/pimvanpelt/vpp-snmp-agent/commit/51eee915bf0f6267911da596b41a4475feaf212e)]. +this in [[this commit](https://git.ipng.ch/ipng/vpp-snmp-agent/commit/51eee915bf0f6267911da596b41a4475feaf212e)]. ### VPP's API @@ -159,7 +159,7 @@ idx=19 name=tap4 mac=02:fe:17:06:fc:af mtu=9000 flags=3 So I added a little abstration with some error handling and one main function to return interfaces as a Python dictionary of those `sw_interface_details` -tuples in [[this commit](https://github.com/pimvanpelt/vpp-snmp-agent/commit/51eee915bf0f6267911da596b41a4475feaf212e)]. +tuples in [[this commit](https://git.ipng.ch/ipng/vpp-snmp-agent/commit/51eee915bf0f6267911da596b41a4475feaf212e)]. ### AgentX @@ -207,9 +207,9 @@ once asked with `GetPDU` or `GetNextPDU` requests, by issuing a corresponding `R to the SNMP server -- it takes care of all the rest! The resulting code is in [[this -commit](https://github.com/pimvanpelt/vpp-snmp-agent/commit/8c9c1e2b4aa1d40a981f17581f92bba133dd2c29)] +commit](https://git.ipng.ch/ipng/vpp-snmp-agent/commit/8c9c1e2b4aa1d40a981f17581f92bba133dd2c29)] but you can also check out the whole thing on -[[Github](https://github.com/pimvanpelt/vpp-snmp-agent)]. +[[Github](https://git.ipng.ch/ipng/vpp-snmp-agent)]. ### Building diff --git a/content/articles/2021-09-21-vpp-7.md b/content/articles/2021-09-21-vpp-7.md index c99350b..f226706 100644 --- a/content/articles/2021-09-21-vpp-7.md +++ b/content/articles/2021-09-21-vpp-7.md @@ -480,7 +480,7 @@ is to say, those packets which were destined to any IP address configured on the plane. Any traffic going _through_ VPP will never be seen by Linux! So, I'll have to be clever and count this traffic by polling VPP instead. This was the topic of my previous [VPP Part 6]({{< ref "2021-09-10-vpp-6" >}}) about the SNMP Agent. All of that code -was released to [Github](https://github.com/pimvanpelt/vpp-snmp-agent), notably there's +was released to [Github](https://git.ipng.ch/ipng/vpp-snmp-agent), notably there's a hint there for an `snmpd-dataplane.service` and a `vpp-snmp-agent.service`, including the compiled binary that reads from VPP and feeds this to SNMP. diff --git a/content/articles/2021-12-23-vpp-playground.md b/content/articles/2021-12-23-vpp-playground.md index e412b1e..2e91d8b 100644 --- a/content/articles/2021-12-23-vpp-playground.md +++ b/content/articles/2021-12-23-vpp-playground.md @@ -62,7 +62,7 @@ plugins: or route, or the system receiving ARP or IPv6 neighbor request/reply from neighbors), and applying these events to the VPP dataplane. -I've published the code on [Github](https://github.com/pimvanpelt/lcpng/) and I am targeting a release +I've published the code on [Github](https://git.ipng.ch/ipng/lcpng/) and I am targeting a release in upstream VPP, hoping to make the upcoming 22.02 release in February 2022. I have a lot of ground to cover, but I will note that the plugin has been running in production in [AS8298]({{< ref "2021-02-27-network" >}}) since Sep'21 and no crashes related to LinuxCP have been observed. @@ -195,7 +195,7 @@ So grab a cup of tea, while we let Rhino stretch its legs, ehh, CPUs ... pim@rhino:~$ mkdir -p ~/src pim@rhino:~$ cd ~/src pim@rhino:~/src$ sudo apt install libmnl-dev -pim@rhino:~/src$ git clone https://github.com/pimvanpelt/lcpng.git +pim@rhino:~/src$ git clone https://git.ipng.ch/ipng/lcpng.git pim@rhino:~/src$ git clone https://gerrit.fd.io/r/vpp pim@rhino:~/src$ ln -s ~/src/lcpng ~/src/vpp/src/plugins/lcpng pim@rhino:~/src$ cd ~/src/vpp diff --git a/content/articles/2022-03-27-vppcfg-1.md b/content/articles/2022-03-27-vppcfg-1.md index f5eea55..0d796b1 100644 --- a/content/articles/2022-03-27-vppcfg-1.md +++ b/content/articles/2022-03-27-vppcfg-1.md @@ -33,7 +33,7 @@ In this first post, let's take a look at tablestakes: writing a YAML specificati configuration elements of VPP, and then ensures that the YAML file is both syntactically as well as semantically correct. -**Note**: Code is on [my Github](https://github.com/pimvanpelt/vppcfg), but it's not quite ready for +**Note**: Code is on [my Github](https://git.ipng.ch/ipng/vppcfg), but it's not quite ready for prime-time yet. Take a look, and engage with us on GitHub (pull requests preferred over issues themselves) or reach out by [contacting us](/s/contact/). @@ -348,7 +348,7 @@ to mess up my (or your!) VPP router by feeding it garbage, so the lions' share o has been to assert the YAML file is both syntactically and semantically valid. -In the mean time, you can take a look at my code on [GitHub](https://github.com/pimvanpelt/vppcfg), but to +In the mean time, you can take a look at my code on [GitHub](https://git.ipng.ch/ipng/vppcfg), but to whet your appetite, here's a hefty configuration that demonstrates all implemented types: ``` diff --git a/content/articles/2022-04-02-vppcfg-2.md b/content/articles/2022-04-02-vppcfg-2.md index 7e4e2fd..20fa893 100644 --- a/content/articles/2022-04-02-vppcfg-2.md +++ b/content/articles/2022-04-02-vppcfg-2.md @@ -32,7 +32,7 @@ the configuration to the dataplane. Welcome to `vppcfg`! In this second post of the series, I want to talk a little bit about how planning a path from a running configuration to a desired new configuration might look like. -**Note**: Code is on [my Github](https://github.com/pimvanpelt/vppcfg), but it's not quite ready for +**Note**: Code is on [my Github](https://git.ipng.ch/ipng/vppcfg), but it's not quite ready for prime-time yet. Take a look, and engage with us on GitHub (pull requests preferred over issues themselves) or reach out by [contacting us](/s/contact/). diff --git a/content/articles/2023-02-12-fitlet2.md b/content/articles/2023-02-12-fitlet2.md index 390fcfd..621ce32 100644 --- a/content/articles/2023-02-12-fitlet2.md +++ b/content/articles/2023-02-12-fitlet2.md @@ -171,12 +171,12 @@ GigabitEthernet1/0/0 1 up GigabitEthernet1/0/0 After this exploratory exercise, I have learned enough about the hardware to be able to take the Fitlet2 out for a spin. To configure the VPP instance, I turn to -[[vppcfg](https://github.com/pimvanpelt/vppcfg)], which can take a YAML configuration file +[[vppcfg](https://git.ipng.ch/ipng/vppcfg)], which can take a YAML configuration file describing the desired VPP configuration, and apply it safely to the running dataplane using the VPP API. I've written a few more posts on how it does that, notably on its [[syntax]({{< ref "2022-03-27-vppcfg-1" >}})] and its [[planner]({{< ref "2022-04-02-vppcfg-2" >}})]. A complete configuration guide on vppcfg can be found -[[here](https://github.com/pimvanpelt/vppcfg/blob/main/docs/config-guide.md)]. +[[here](https://git.ipng.ch/ipng/vppcfg/blob/main/docs/config-guide.md)]. ``` pim@fitlet:~$ sudo dpkg -i {lib,}vpp*23.06*deb diff --git a/content/articles/2023-02-24-coloclue-vpp-2.md b/content/articles/2023-02-24-coloclue-vpp-2.md index be8c4bd..3cc6cdc 100644 --- a/content/articles/2023-02-24-coloclue-vpp-2.md +++ b/content/articles/2023-02-24-coloclue-vpp-2.md @@ -185,7 +185,7 @@ forgetful chipmunk-sized brain!), so here, I'll only recap what's already writte **1. BUILD:** For the first step, the build is straight forward, and yields a VPP instance based on `vpp-ext-deps_23.06-1` at version `23.06-rc0~71-g182d2b466`, which contains my -[[LCPng](https://github.com/pimvanpelt/lcpng.git)] plugin. I then copy the packages to the router. +[[LCPng](https://git.ipng.ch/ipng/lcpng.git)] plugin. I then copy the packages to the router. The router has an E-2286G CPU @ 4.00GHz with 6 cores and 6 hyperthreads. There's a really handy tool called `likwid-topology` that can show how the L1, L2 and L3 cache lines up with respect to CPU cores. Here I learn that CPU (0+6) and (1+7) share L1 and L2 cache -- so I can conclude that 0-5 are @@ -351,7 +351,7 @@ in `vppcfg`: * When I create the initial `--novpp` config, there's a bug in `vppcfg` where I incorrectly reference a dataplane object which I haven't initialized (because with `--novpp` the tool will not contact the dataplane at all. That one was easy to fix, which I did in [[this - commit](https://github.com/pimvanpelt/vppcfg/commit/0a0413927a0be6ed3a292a8c336deab8b86f5eee)]). + commit](https://git.ipng.ch/ipng/vppcfg/commit/0a0413927a0be6ed3a292a8c336deab8b86f5eee)]). After that small detour, I can now proceed to configure the dataplane by offering the resulting VPP commands, like so: @@ -573,7 +573,7 @@ see is that which is destined to the controlplane (eg, to one of the IPv4 or IPv multicast/broadcast groups that they are participating in), so things like tcpdump or SNMP won't really work. -However, due to my [[vpp-snmp-agent](https://github.com/pimvanpelt/vpp-snmp-agent.git)], which is +However, due to my [[vpp-snmp-agent](https://git.ipng.ch/ipng/vpp-snmp-agent.git)], which is feeding as an AgentX behind an snmpd that in turn is running in the `dataplane` namespace, SNMP scrapes work as they did before, albeit with a few different interface names. diff --git a/content/articles/2023-04-09-vpp-stats.md b/content/articles/2023-04-09-vpp-stats.md index 09d2f55..d900dc1 100644 --- a/content/articles/2023-04-09-vpp-stats.md +++ b/content/articles/2023-04-09-vpp-stats.md @@ -14,7 +14,7 @@ performance and versatility. For those of us who have used Cisco IOS/XR devices, _ASR_ (aggregation service router), VPP will look and feel quite familiar as many of the approaches are shared between the two. -I've been working on the Linux Control Plane [[ref](https://github.com/pimvanpelt/lcpng)], which you +I've been working on the Linux Control Plane [[ref](https://git.ipng.ch/ipng/lcpng)], which you can read all about in my series on VPP back in 2021: [![DENOG14](/assets/vpp-stats/denog14-thumbnail.png){: style="width:300px; float: right; margin-left: 1em;"}](https://video.ipng.ch/w/erc9sAofrSZ22qjPwmv6H4) @@ -70,7 +70,7 @@ answered by a Response PDU. Using parts of a Python Agentx library written by GitHub user hosthvo [[ref](https://github.com/hosthvo/pyagentx)], I tried my hands at writing one of these AgentX's. -The resulting source code is on [[GitHub](https://github.com/pimvanpelt/vpp-snmp-agent)]. That's the +The resulting source code is on [[GitHub](https://git.ipng.ch/ipng/vpp-snmp-agent)]. That's the one that's running in production ever since I started running VPP routers at IPng Networks AS8298. After the _AgentX_ exposes the dataplane interfaces and their statistics into _SNMP_, an open source monitoring tool such as LibreNMS [[ref](https://librenms.org/)] can discover the routers and draw @@ -126,7 +126,7 @@ for any interface created in the dataplane. I wish I were good at Go, but I never really took to the language. I'm pretty good at Python, but sorting through the stats segment isn't super quick as I've already noticed in the Python3 based -[[VPP SNMP Agent](https://github.com/pimvanpelt/vpp-snmp-agent)]. I'm probably the world's least +[[VPP SNMP Agent](https://git.ipng.ch/ipng/vpp-snmp-agent)]. I'm probably the world's least terrible C programmer, so maybe I can take a look at the VPP Stats Client and make sense of it. Luckily, there's an example already in `src/vpp/app/vpp_get_stats.c` and it reveals the following pattern: diff --git a/content/articles/2023-05-07-vpp-mpls-1.md b/content/articles/2023-05-07-vpp-mpls-1.md index b99c403..289341c 100644 --- a/content/articles/2023-05-07-vpp-mpls-1.md +++ b/content/articles/2023-05-07-vpp-mpls-1.md @@ -19,7 +19,7 @@ same time keep an IPng Site Local network with IPv4 and IPv6 that is separate fr based on hardware/silicon based forwarding at line rate and high availability. You can read all about my Centec MPLS shenanigans in [[this article]({{< ref "2023-03-11-mpls-core" >}})]. -Ever since the release of the Linux Control Plane [[ref](https://github.com/pimvanpelt/lcpng)] +Ever since the release of the Linux Control Plane [[ref](https://git.ipng.ch/ipng/lcpng)] plugin in VPP, folks have asked "What about MPLS?" -- I have never really felt the need to go this rabbit hole, because I figured that in this day and age, higher level IP protocols that do tunneling are just as performant, and a little bit less of an 'art' to get right. For example, the Centec diff --git a/content/articles/2023-05-21-vpp-mpls-3.md b/content/articles/2023-05-21-vpp-mpls-3.md index 1607e17..be64d45 100644 --- a/content/articles/2023-05-21-vpp-mpls-3.md +++ b/content/articles/2023-05-21-vpp-mpls-3.md @@ -459,6 +459,6 @@ and VPP, and the overall implementation before attempting to use in production. we got at least some of this right, but testing and runtime experience will tell. I will be silently porting the change into my own copy of the Linux Controlplane called lcpng on -[[GitHub](https://github.com/pimvanpelt/lcpng.git)]. If you'd like to test this - reach out to the VPP +[[GitHub](https://git.ipng.ch/ipng/lcpng.git)]. If you'd like to test this - reach out to the VPP Developer [[mailinglist](mailto:vpp-dev@lists.fd.io)] any time! diff --git a/content/articles/2023-05-28-vpp-mpls-4.md b/content/articles/2023-05-28-vpp-mpls-4.md index 1c213d9..6838cc2 100644 --- a/content/articles/2023-05-28-vpp-mpls-4.md +++ b/content/articles/2023-05-28-vpp-mpls-4.md @@ -385,5 +385,5 @@ and VPP, and the overall implementation before attempting to use in production. we got at least some of this right, but testing and runtime experience will tell. I will be silently porting the change into my own copy of the Linux Controlplane called lcpng on -[[GitHub](https://github.com/pimvanpelt/lcpng.git)]. If you'd like to test this - reach out to the VPP +[[GitHub](https://git.ipng.ch/ipng/lcpng.git)]. If you'd like to test this - reach out to the VPP Developer [[mailinglist](mailto:vpp-dev@lists.fd.io)] any time! diff --git a/content/articles/2023-10-21-vpp-ixp-gateway-1.md b/content/articles/2023-10-21-vpp-ixp-gateway-1.md index 376ffc7..b91d141 100644 --- a/content/articles/2023-10-21-vpp-ixp-gateway-1.md +++ b/content/articles/2023-10-21-vpp-ixp-gateway-1.md @@ -304,7 +304,7 @@ Gateway, just to show a few of the more advanced features of VPP. For me, this t line of thinking: classifiers. This extract/match/act pattern can be used in policers, ACLs and arbitrary traffic redirection through VPP's directed graph (eg. selecting a next node for processing). I'm going to deep-dive into this classifier behavior in an upcoming article, and see -how I might add this to [[vppcfg](https://github.com/pimvanpelt/vppcfg.git)], because I think it +how I might add this to [[vppcfg](https://git.ipng.ch/ipng/vppcfg.git)], because I think it would be super powerful to abstract away the rather complex underlying API into something a little bit more ... user friendly. Stay tuned! :) diff --git a/content/articles/2024-03-06-vpp-babel-1.md b/content/articles/2024-03-06-vpp-babel-1.md index 26d394f..90931b5 100644 --- a/content/articles/2024-03-06-vpp-babel-1.md +++ b/content/articles/2024-03-06-vpp-babel-1.md @@ -359,7 +359,7 @@ does not have an IPv4 address. Except -- I'm bending the rules a little bit by d There's an internal function `ip4_sw_interface_enable_disable()` which is called to enable IPv4 processing on an interface once the first IPv4 address is added. So my first fix is to force this to be enabled for any interface that is exposed via Linux Control Plane, notably in `lcp_itf_pair_create()` -[[here](https://github.com/pimvanpelt/lcpng/blob/main/lcpng_interface.c#L777)]. +[[here](https://git.ipng.ch/ipng/lcpng/blob/main/lcpng_interface.c#L777)]. This approach is partially effective: @@ -500,7 +500,7 @@ which is unnumbered. Because I don't know for sure if everybody would find this I make sure to guard the behavior behind a backwards compatible configuration option. If you're curious, please take a look at the change in my [[GitHub -repo](https://github.com/pimvanpelt/lcpng/commit/a960d64a87849d312b32d9432ffb722672c14878)], in +repo](https://git.ipng.ch/ipng/lcpng/commit/a960d64a87849d312b32d9432ffb722672c14878)], in which I: 1. add a new configuration option, `lcp-sync-unnumbered`, which defaults to `on`. That would be what the plugin would do in the normal case: copy forward these borrowed IP addresses to Linux. diff --git a/content/articles/2024-04-06-vpp-ospf.md b/content/articles/2024-04-06-vpp-ospf.md index e945a29..bd5ade2 100644 --- a/content/articles/2024-04-06-vpp-ospf.md +++ b/content/articles/2024-04-06-vpp-ospf.md @@ -147,7 +147,7 @@ With all of that, I am ready to demonstrate two working solutions now. I first c Ondrej's [[commit](https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8)]. Then, I compile VPP with my pending [[gerrit](https://gerrit.fd.io/r/c/vpp/+/40482)]. Finally, to demonstrate how `update_loopback_addr()` might work, I compile `lcpng` with my previous -[[commit](https://github.com/pimvanpelt/lcpng/commit/a960d64a87849d312b32d9432ffb722672c14878)], +[[commit](https://git.ipng.ch/ipng/lcpng/commit/a960d64a87849d312b32d9432ffb722672c14878)], which allows me to inhibit copying forward addresses from VPP to Linux, when using _unnumbered_ interfaces. diff --git a/content/articles/2024-06-22-vpp-ospf-2.md b/content/articles/2024-06-22-vpp-ospf-2.md index 48184b1..5f1f380 100644 --- a/content/articles/2024-06-22-vpp-ospf-2.md +++ b/content/articles/2024-06-22-vpp-ospf-2.md @@ -250,10 +250,10 @@ remove the IPv4 and IPv6 addresses from the }})] and its [[operations]({{< ref 2022-04-02-vppcfg-2 >}})] so I won't repeat that here. Instead, I will just show the configuration: diff --git a/content/articles/2025-05-04-containerlab-2.md b/content/articles/2025-05-04-containerlab-2.md index 3b8eff2..ee9deff 100644 --- a/content/articles/2025-05-04-containerlab-2.md +++ b/content/articles/2025-05-04-containerlab-2.md @@ -49,7 +49,7 @@ RUN apt-get update && apt-get -y install vpp vpp-plugin-core && apt-get clean # Build vppcfg RUN pip install --break-system-packages build netaddr yamale argparse pyyaml ipaddress -RUN git clone https://github.com/pimvanpelt/vppcfg.git && cd vppcfg && python3 -m build && \ +RUN git clone https://git.ipng.ch/ipng/vppcfg.git && cd vppcfg && python3 -m build && \ pip install --break-system-packages dist/vppcfg-*-py3-none-any.whl # Config files