# orderedItems[].object.content
For an upcoming article on #vpp and #eVPN I have a screencast to share.

This 3 minute recording shows the functionality that I intend to ship in v1.0.0 next month. I demonstrate creating a group of VPP routers in an eVPN bridge-domain, including manual failover (2 seconds), and automated failover (8 seconds) between VPP nodes in Zurich and Geneva.

See also https://asciinema.org/a/1222897 for the raw .cast file.

# orderedItems[].object.attachment[].name
A video screencapture of an operator creating a group of routers in an eVPN bridge-domain, including manual failover (2 seconds), and automated failover (8 seconds) between VPP nodes.

# orderedItems[].object.ephemeral.metadata[].twitterTitle
VPP eVPN controlplane with automated failover

# orderedItems[].object.ephemeral.metadata[].ogTitle
VPP eVPN controlplane with automated failover

# orderedItems[].object.content
Guess what I'm building? :)

#vpp

# orderedItems[].object.content
Automation is such a beautiful thing, when done safely.

#vpp #gitea #selfhosting

# orderedItems[].object.content
Yesterday we upgraded the transmission core switches at Qupra DC - while NorthC in Almere was busy burning down.

Yesterday we took MPLS into service, and are delivering our first 20 or so circuits.

Today we will connect Iron Mountain to Qupra using a DWDM connection. EUNetworks will lose network redundancy with only one uplink left. Then, on Sat/Sun we will move from EUNetworks to Iron Mountain, so the window of risk is only two days.

#selfhosting #vpp

# orderedItems[].object.content
Scratched an itch that's been bothering me for a while. I created a vpp-pcap tool to serve network engineers working with #VPP who want something akin to #tcpdump.

root@jt-router:~# vpp-pcap -i any --print
2026-05-05 02:27:16.544645919 lan Inbound 192.168.37.1 → 224.0.0.251  MDNS 212 Standard query response 0x0000 SRV, cache flush 0 0 44677 lgwebostv.local NSEC, cache flush lgwebostv.local NSEC, cache flush LG webOS Projector 3D93._hap._tcp.local AAAA, cache flush 2604:2940:4001:172:32b1:b5ff:feb9:232e A, cache flush 10.11.64.235
2026-05-05 02:27:16.568789127 lan Inbound 2602:f90e:10:0:18ff:7059:2bb8:3aac → 2602:f90e:10:0:ffff:ffff:ffff:fffe ICMPv6 90 Neighbor Solicitation for 2602:f90e:10:0:ffff:ffff:ffff:fffe from 16:59:1d:c2:0d:c7
2026-05-05 02:27:16.568827057 bvi100 Outbound 2602:f90e:10:0:ffff:ffff:ffff:fffe → 2602:f90e:10:0:18ff:7059:2bb8:3aac ICMPv6 86 Neighbor Advertisement 2602:f90e:10:0:ffff:ffff:ffff:fffe (rtr, sol, ovr) is at de:ad:00:00:00:64
2026-05-05 02:27:16.568834557 lan.30 Outbound 2602:f90e:10:0:ffff:ffff:ffff:fffe → 2602:f90e:10:0:18ff:7059:2bb8:3aac ICMPv6 90 Neighbor Advertisement 2602:f90e:10:0:ffff:ffff:ffff:fffe (rtr, sol, ovr) is at de:ad:00:00:00:64
2026-05-05 02:27:16.568929957 lan Inbound 2602:f90e:10:0:18ff:7059:2bb8:3aac → 2602:f90e:10:0:ffff:ffff:ffff:fffe ICMPv6 90 Neighbor Solicitation for 2602:f90e:10:0:ffff:ffff:ffff:fffe from 16:59:1d:c2:0d:c7
2026-05-05 02:27:16.568934037 bvi100 Outbound 2602:f90e:10:0:ffff:ffff:ffff:fffe → 2602:f90e:10:0:18ff:7059:2bb8:3aac ICMPv6 86 Neighbor Advertisement 2602:f90e:10:0:ffff:ffff:ffff:fffe (rtr, sol, ovr) is at de:ad:00:00:00:64
2026-05-05 02:27:16.568935527 lan.30 Outbound 2602:f90e:10:0:ffff:ffff:ffff:fffe → 2602:f90e:10:0:18ff:7059:2bb8:3aac ICMPv6 90 Neighbor Advertisement 2602:f90e:10:0:ffff:ffff:ffff:fffe (rtr, sol, ovr) is at de:ad:00:00:00:64

VPP has some very rich tracing tools, but I find them ergonomically challenging to use. I came up as a network engineer in the late 90s and early 2000s - this feels much more natural to me.

The repository is on GitHub. Both a plugin and a small Rust utility are used to provide live access to data passing through the VPP dataplane. It can also be chained with tcpdump, tshark, or wireshark to use those familiar interfaces. Usage details are in the GitHub README.

License is Apache 2.0, so use it as you'd like.

# orderedItems[].object.content
I might experiment with RFC 8925 tomorrow night to signal to clients on my #IPv6 preferred subnet to disable their IPv4 stacks altogether. That might take another patch to the #VPP router advertisement process.

I can disable IPv4 on my Macs and they engage the CLAT based on the PREF64 and RDNSS flags. But Android seems to be stubborn. It won't stay connected without DHCP (v4) on the network. Maybe RFC 8925 will help.

# orderedItems[].object.source.content
I might experiment with RFC 8925 tomorrow night to signal to clients on my #IPv6 preferred subnet to disable their IPv4 stacks altogether. That might take another patch to the #VPP router advertisement process.

I can disable IPv4 on my Macs and they engage the CLAT based on the `PREF64` and `RDNSS` flags. But Android seems to be stubborn. It won't stay connected without DHCP (v4) on the network. Maybe RFC 8925 will help.

# orderedItems[].object.name
Extending the Vector Packet Processing Engine

# orderedItems[].object.summary
I've been building core networking components to leverage VPP more fully as a branch router. Here is an overview of that work.

# orderedItems[].object.content
Within the last couple of years, I spent some time working with a small regional ISP as CTO. We were focused on building out FTTP for our local community both to rural dwellings and to multi-dwelling units (MDUs).

One of the challenges that we had as a bootstrapped technology company was the cost of enterprise networking equipment. The founder of the company made the strategic decision to focus on delivering active Ethernet to our subscribers (no GPON). This allowed us to stick to the type of networking solutions that might be deployed in an enterprise campus rather than the proprietary solutions that drive more common FTTP deployments.

We also wanted more direct control over our network fabric. That led us to explore open networking solutions like SONiC and #VPP. VPP in particular found a home in our MDU deployments, allowing us to build very capable routing platforms using #OSS and no proprietary ASICs or other traditionally pipelined solutions.

There are some challenges with VPP, however. The system has a number of plugins (e.g., nat44-ed, ct6, nat64, acl-plugin, etc.) that were useful for our deployments. But some plugins interacted poorly with others (e.g., routing through an interface and using NAT together doesn't work well, using NAT64 and anything else doesn't work well, etc.) I came up with some tortured solutions to those problems that involved ACL-based forwarding, memif interfaces, and multiple VPP processes. But they weren't ideal.

Within the last month, I decided to take a stab at solving a problem in my home lab with ct6: ostensibly designed for #IPv6 connection tracking, it really didn't do much of anything. It's mostly a stub for future work that has never been completed. I decided to complete it and submitted a merge request upstream.

But in that process, I realized that I could do a lot more. Rather than just patch ct6, I could build a plugin from whole cloth that handled all of my translation needs from a common state table. And I could perform access control decisions with the state maintained as part of that capability. That became: https://github.com/justindthomas/sfw:

sfw zone internal interface lan
sfw zone external interface wan
sfw policy outbound from-zone internal to-zone external
sfw policy outbound default-action permit-stateful-nat
sfw policy inbound from-zone external to-zone internal
sfw policy inbound default-action deny
sfw nat64 pool add x.x.x.x/32 prefix 64:ff9b::/96

Along the way, I realized that I could take things further. I had been using Free Range Router (FRR) to handle things like BGP and OSPF. But it integrates with VPP via a shim called the Linux Control Plane. As the name implies, that only works on Linux, and I want to be flexible enough to support FreeBSD as well.

So I wrote https://github.com/justindthomas/vcl-rs to allow for Rust daemons to bind into VPP directly without going through the host stack. Then I created: ribd, bgpd, ospfd, and dnsd.

These daemons all have common characteristics; they each read a dedicated section from a YAML file (i.e., one file can be used to control all of them), they're designed to reload configuration on a SIGHUP, and they avoid using the host networking stack in favor of either vcl-rs or punt sockets (e.g., for OSPF).

That last daemon (dnsd) has me excited today. I'm very interested in facilitating the transition to IPv6. So things like #464XLAT, #NAT64, and #DNS64 are in my sights. But support for each of those protocols is challenging; VPP does not support router advertisements for #PREF64 (for NAT64) or for #RDNSS (to communicate IPv6 DNS information to clients).

To deal with that, I added in a couple of patches as part of sfw that hook into VPP's existing router advertisement functions. That expands the advertisements to include PREF64 and RDNSS:

00:00:00.000000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 104)
    fe80::dcad:ff:fe00:64 > ff02::1: [icmp6 sum ok] ICMP6, router
    advertisement, length 104
  hop limit 64, Flags [managed], pref medium, router lifetime 600s,
      reachable time 0ms, retrans timer 0ms
    source link-address option (1), length 8 (1): de:ad:00:00:00:64
      0x0000: dead 0000 0064
    mtu option (5), length 8 (1):&nbsp; 1500
      0x0000: 0000 0000 05dc
    prefix info option (3), length 32 (4): xxxx:xxxx:10::/64,
          Flags [onlink, auto], valid time 2584092s, pref. time 596892s
      0x0000: 40c0 0027 6e1c 0009 1b9c 0000 0000 xxxx
      0x0010: xxxx 0010 0000 0000 0000 0000 0000
    unknown option (38), length 16 (2):
      0x0000: 0708 0064 ff9b 0000 0000 0000 0000
    rdnss option (25), length 24 (3):&nbsp; lifetime 90s,
          addr: xxxx:xxxx:10:0:ffff:ffff:ffff:fffe
      0x0000: 0000 0000 005a xxxx xxxx 0010 0000 ffff
      0x0010: ffff ffff fffe

This has enabled me to have a client network that is purely IPv6. My Mac clients see the router advertisements and enable their clat46 functionality:

en0: flags=88e3<UP,BROADCAST,SMART,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
    options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
    ether 16:59:1d:c2:0d:c7
    inet6 fe80::1841:489:85ff:916f%en0 prefixlen 64 secured scopeid 0xb
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf secured
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf temporary
    inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 clat46
    nat64 prefix 64:ff9b:: prefixlen 96
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active

Interactions with IPv4 servers is automatically translated into 64:ff9b::/96 addresses and passed along to the servers over the router's IPv4 stack.

These daemons - even individually - constitute a formidable code base. And obviously I used an LLM to help create the tens of thousands of lines of code in total. The effort has been informed heavily by RFCs, industry-standard conformance testing, and integration testing against other routing platforms. And for some (like dnsd) a lot of iterations just to get performance to a solid level (I think DNS is more complex than we give it credit for - especially when DNSSEC is considered). And the fact that I'm avoiding the host networking stack complicates matters, because I have to handle the translation between Rust code and the C code that exposes the VCL capabilities in VPP.

I'm using the end product daily (pulled together in a larger router framework that I haven't released yet) and tweaking as issues reveal themselves. If you'd like to participate, please feel free to drop me a line.

# orderedItems[].object.source.content
Within the last couple of years, I spent some time working with a small regional ISP as CTO. We were focused on building out FTTP for our local community both to rural dwellings and to multi-dwelling units (MDUs).

One of the challenges that we had as a bootstrapped technology company was the cost of enterprise networking equipment. The founder of the company made the strategic decision to focus on delivering active Ethernet to our subscribers (no GPON). This allowed us to stick to the type of networking solutions that might be deployed in an enterprise campus rather than the proprietary solutions that drive more common FTTP deployments.

We also wanted more direct control over our network fabric. That led us to explore open networking solutions like SONiC and #VPP. VPP in particular found a home in our MDU deployments, allowing us to build very capable routing platforms using #OSS and no proprietary ASICs or other traditionally pipelined solutions.

There are some challenges with VPP, however. The system has a number of plugins (e.g., `nat44-ed`, `ct6`, `nat64`, `acl-plugin`, etc.) that were useful for our deployments. But some plugins interacted poorly with others (e.g., routing through an interface and using NAT together doesn't work well, using NAT64 and anything else doesn't work well, etc.) I came up with some tortured solutions to those problems that involved ACL-based forwarding, `memif` interfaces, and multiple VPP processes. But they weren't ideal.

Within the last month, I decided to take a stab at solving a problem in my home lab with `ct6`: ostensibly designed for #IPv6 connection tracking, it really didn't do much of anything. It's mostly a stub for future work that has never been completed. I decided to complete it and submitted a merge request upstream.

But in that process, I realized that I could do a lot more. Rather than just patch `ct6`, I could build a plugin from whole cloth that handled all of my translation needs from a common state table. And I could perform access control decisions with the state maintained as part of that capability. That became: [https://github.com/justindthomas/sfw](https://github.com/justindthomas/sfw):

```
sfw zone internal interface lan
sfw zone external interface wan
sfw policy outbound from-zone internal to-zone external
sfw policy outbound default-action permit-stateful-nat
sfw policy inbound from-zone external to-zone internal
sfw policy inbound default-action deny
sfw nat64 pool add x.x.x.x/32 prefix 64:ff9b::/96
```

Along the way, I realized that I could take things further. I had been using Free Range Router (FRR) to handle things like BGP and OSPF. But it integrates with VPP via a shim called the Linux Control Plane. As the name implies, that only works on Linux, and I want to be flexible enough to support FreeBSD as well.

So I wrote [https://github.com/justindthomas/vcl-rs](https://github.com/justindthomas/vcl-rs) to allow for Rust daemons to bind into VPP directly without going through the host stack. Then I created: [ribd](https://github.com/justindthomas/ribd), [bgpd](https://github.com/justindthomas/bgpd), [ospfd](https://github.com/justindthomas/ospfd), and [dnsd](https://github.com/justindthomas/dnsd).

These daemons all have common characteristics; they each read a dedicated section from a `YAML` file (i.e., one file can be used to control all of them), they're designed to reload configuration on a `SIGHUP`, and they avoid using the host networking stack in favor of either `vcl-rs` or `punt` sockets (e.g., for OSPF).

That last daemon (dnsd) has me excited today. I'm very interested in facilitating the transition to IPv6. So things like #464XLAT, #NAT64, and #DNS64 are in my sights. But support for each of those protocols is challenging; VPP does not support router advertisements for #PREF64 (for NAT64) or for #RDNSS (to communicate IPv6 DNS information to clients).

To deal with that, I added in a couple of patches as part of `sfw` that hook into VPP's existing router advertisement functions. That expands the advertisements to include `PREF64` and `RDNSS`:

```
00:00:00.000000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 104) 
    fe80::dcad:ff:fe00:64 > ff02::1: [icmp6 sum ok] ICMP6, router 
    advertisement, length 104 
  hop limit 64, Flags [managed], pref medium, router lifetime 600s, 
      reachable time 0ms, retrans timer 0ms
    source link-address option (1), length 8 (1): de:ad:00:00:00:64
      0x0000: dead 0000 0064
    mtu option (5), length 8 (1):  1500
      0x0000: 0000 0000 05dc
    prefix info option (3), length 32 (4): xxxx:xxxx:10::/64, 
          Flags [onlink, auto], valid time 2584092s, pref. time 596892s
      0x0000: 40c0 0027 6e1c 0009 1b9c 0000 0000 xxxx
      0x0010: xxxx 0010 0000 0000 0000 0000 0000
    unknown option (38), length 16 (2):
      0x0000: 0708 0064 ff9b 0000 0000 0000 0000
    rdnss option (25), length 24 (3):  lifetime 90s,
          addr: xxxx:xxxx:10:0:ffff:ffff:ffff:fffe
      0x0000: 0000 0000 005a xxxx xxxx 0010 0000 ffff
      0x0010: ffff ffff fffe
```
This has enabled me to have a client network that is purely IPv6. My Mac clients see the router advertisements and enable their `clat46` functionality:

```
en0: flags=88e3<UP,BROADCAST,SMART,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
    options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
    ether 16:59:1d:c2:0d:c7
    inet6 fe80::1841:489:85ff:916f%en0 prefixlen 64 secured scopeid 0xb
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf secured
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf temporary
    inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2
    inet6 xxxx:xxxx:10:0:xxxx:xxxx:xxxx:xxxx prefixlen 64 clat46
    nat64 prefix 64:ff9b:: prefixlen 96
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active
```
Interactions with IPv4 servers is automatically translated into `64:ff9b::/96` addresses and passed along to the servers over the router's IPv4 stack.

These daemons - even individually - constitute a formidable code base. And obviously I used an LLM to help create the tens of thousands of lines of code in total. The effort has been informed heavily by RFCs, industry-standard conformance testing, and integration testing against other routing platforms. And for some (like `dnsd`) a lot of iterations just to get performance to a solid level (I think DNS is more complex than we give it credit for - especially when DNSSEC is considered). And the fact that I'm avoiding the host networking stack complicates matters, because I have to handle the translation between Rust code and the C code that exposes the VCL capabilities in VPP.

I'm using the end product daily (pulled together in a larger router framework that I haven't released yet) and tweaking as issues reveal themselves. If you'd like to participate, please feel free to drop me a line.

# orderedItems[].object.content
Running a Static CT log is fun!
IPng's logs are being used in production by most public CAs, and are being monitored by most public log verification and monitoring companies.

This little web cluster does 140M/day (1600/s), and scrapers / dos attacks are becoming a thing!

#ctlog #vpp #selfhosting

# orderedItems[].object.content
https://github.com/srl-labs/containerl ab/pull/3152

Let's goooo! #vpp #containerlab prepping for ZANOG training session

# orderedItems[].object.ephemeral.metadata[].twitterTitle
fdio_vpp: Update to image which has all configs in /config by pimvanpelt · Pull Request #3152 · srl-labs/containerlab

# orderedItems[].object.ephemeral.metadata[].description
container-based networking labs. Contribute to srl-labs/containerlab development by creating an account on GitHub.

# orderedItems[].object.ephemeral.metadata[].ogDescription
Upstream image :stable moves VPP, Bird2 and FRR configs to /config It allows bind-mount into /config/ and will copy any other file from the image into /config, then symlinking /etc/{vpp,bird,frr}/ ...

# orderedItems[].object.ephemeral.metadata[].ogTitle
fdio_vpp: Update to image which has all configs in /config by pimvanpelt · Pull Request #3152 · srl-labs/containerlab

# orderedItems[].object.ephemeral.metadata[].twitterDescription
Upstream image :stable moves VPP, Bird2 and FRR configs to /config It allows bind-mount into /config/ and will copy any other file from the image into /config, then symlinking /etc/{vpp,bird,frr}/ ...

# orderedItems[].object.content
eVPN/VxLAN interop between VPP, Nokia and Arista is a fact!
#vpp #bird

# orderedItems[].object.content
I guess I have VXLAN point-multipoint tunnels working in VPP. The cool thing is, I am at 39000ft over the Atlantic right now.

eVPN/VxLAN gets closer every day! Take a look at https://gerrit.fd.io/r/c/vpp/+/45221 to see what I got so far #vpp

# orderedItems[].object.content
Note the subinterface :)

#vpp

# orderedItems[].object.content
I've been working on building a #VPP-based router for the last year to support a small ISP I've been partnering with. I recently began polishing it (e.g., building an image that can be installable from USB, etc.) and adding a unified configuration CLI that abstracts away the details of managing multiple VPP processes, FRR, ZFS snapshots, (eventually) immutable system, etc.

This weekend I began experimenting with adding local #LLM capabilities (using #Ollama with gpt-oss:120b running on an AMD AI MAX 395+ system with 128GB of unified RAM) and I'm really excited by the possibilities.

imp> agent

[+] Connected to Ollama (gpt-oss:120b)
Type your request, or 'exit' to return

agent> Let's add a new loopback interface with IPv4 10.5.5.1/32 and IPv6 fc00::5:5:1/128. It can be called "service".
Thinking...
[Tool: add_loopback]
  create_lcp: True
  ipv4_cidr: 10.5.5.1/32
  ipv6_cidr: fc00::5:5:1/128
  name: service
  → Added loop0 (service) with 10.5.5.1/32, fc00::5:5:1/128
Thinking...

The loopback interface loop0 (named “service”) has been created with:

 • IPv4 10.5.5.1/32
 • IPv6 fc00::5:5:1/128

Let me know if you’d like any further changes!

agent> exit
Returning to IMP REPL...
imp*> apply
[+] Configuration saved to /persistent/config/router.json
[+] Configuration files generated in /tmp/imp-generated-config

Changes detected:
  Detected 1 configuration change(s):
    - ADD loopback loop0

  [DRY-RUN] VPP Core changes (5 commands):
    create loopback interface instance 0
    set interface state loop0 up
    lcp create loop0 host-if lo0
    set interface ip address loop0 10.5.5.1/32
    set interface ip address loop0 fc00::5:5:1/128


Apply changes live? [Y/n]: y
[+] Applying changes live...
  Detected 1 configuration change(s):
    - ADD loopback loop0

  Applying VPP Core changes...
[+] OK (5 commands)
[+] Live changes applied successfully
imp>

…and watching it come up (and be automatically handled by #iBGP since I'm pinging from a host that's not directly connected).

> ping 10.5.5.1
PING 10.5.5.1 (10.5.5.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
64 bytes from 10.5.5.1: icmp_seq=10 ttl=63 time=3.067 ms
64 bytes from 10.5.5.1: icmp_seq=11 ttl=63 time=3.132 ms
64 bytes from 10.5.5.1: icmp_seq=12 ttl=63 time=3.128 ms
64 bytes from 10.5.5.1: icmp_seq=13 ttl=63 time=4.260 ms
64 bytes from 10.5.5.1: icmp_seq=14 ttl=63 time=3.189 ms
64 bytes from 10.5.5.1: icmp_seq=15 ttl=63 time=3.992 ms

# orderedItems[].object.source.content
I've been working on building a #VPP-based router for the last year to support a small ISP I've been partnering with. I recently began polishing it (e.g., building an image that can be installable from USB, etc.) and adding a unified configuration CLI that abstracts away the details of managing multiple VPP processes, FRR, ZFS snapshots, (eventually) immutable system, etc.

This weekend I began experimenting with adding local #LLM capabilities (using #Ollama with `gpt-oss:120b` running on an AMD AI MAX 395+ system with 128GB of unified RAM) and I'm really excited by the possibilities.

```
imp> agent

[+] Connected to Ollama (gpt-oss:120b)
Type your request, or 'exit' to return

agent> Let's add a new loopback interface with IPv4 10.5.5.1/32 and IPv6 fc00::5:5:1/128. It can be called "service".
Thinking...
[Tool: add_loopback]
  create_lcp: True
  ipv4_cidr: 10.5.5.1/32
  ipv6_cidr: fc00::5:5:1/128
  name: service
  → Added loop0 (service) with 10.5.5.1/32, fc00::5:5:1/128
Thinking...

The loopback interface loop0 (named “service”) has been created with:

 • IPv4 10.5.5.1/32
 • IPv6 fc00::5:5:1/128

Let me know if you’d like any further changes!

agent> exit
Returning to IMP REPL...
imp*> apply
[+] Configuration saved to /persistent/config/router.json
[+] Configuration files generated in /tmp/imp-generated-config

Changes detected:
  Detected 1 configuration change(s):
    - ADD loopback loop0

  [DRY-RUN] VPP Core changes (5 commands):
    create loopback interface instance 0
    set interface state loop0 up
    lcp create loop0 host-if lo0
    set interface ip address loop0 10.5.5.1/32
    set interface ip address loop0 fc00::5:5:1/128

Apply changes live? [Y/n]: y
[+] Applying changes live...
  Detected 1 configuration change(s):
    - ADD loopback loop0

  Applying VPP Core changes...
[+] OK (5 commands)
[+] Live changes applied successfully
imp>
```
...and watching it come up (and be automatically handled by #iBGP since I'm pinging from a host that's not directly connected).

```
> ping 10.5.5.1
PING 10.5.5.1 (10.5.5.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
64 bytes from 10.5.5.1: icmp_seq=10 ttl=63 time=3.067 ms
64 bytes from 10.5.5.1: icmp_seq=11 ttl=63 time=3.132 ms
64 bytes from 10.5.5.1: icmp_seq=12 ttl=63 time=3.128 ms
64 bytes from 10.5.5.1: icmp_seq=13 ttl=63 time=4.260 ms
64 bytes from 10.5.5.1: icmp_seq=14 ttl=63 time=3.189 ms
64 bytes from 10.5.5.1: icmp_seq=15 ttl=63 time=3.992 ms
```

# orderedItems[].object.content
In case you missed it - @civiloid presented the >1Gpps and >1Tbps testing gear will fully open source #vpp and #trex at DENOG'17.

His presentation: https://youtu.be/3zFiCRMh70E?si=Rr-wF0 dK_uY_BTF5

Phenomenal.

# orderedItems[].object.ephemeral.metadata[].twitterTitle
DENOG17 - "What can possibly go wrong?" Stories of peculiarities of modern server hardware

# orderedItems[].object.ephemeral.metadata[].ogTitle
DENOG17 - "What can possibly go wrong?" Stories of peculiarities of modern server hardware

# orderedItems[].object.content
VPP 25.10 was released a few days ago - I've created a Containerlab image for amd64 and arm64 for it.

See instructions on: https://git.ipng.ch/ipng/vpp-container lab

Have fun building wicked topologies!!

#containerlab #vpp

# orderedItems[].object.ephemeral.metadata[].description
vpp-containerlab - VPP Containerlab Docker image

# orderedItems[].object.content
Hmmm, maybe a 'show interface transceiver', for at least DPDK interfaces anyway, is in our future.

#vpp

# orderedItems[].object.content
Aaaaand there's VPP Containerlab support with FRRouting! #vpp

See https://git.ipng.ch/ipng/vpp-container lab

# orderedItems[].object.content
I was also allowed to bring a small contribution to the FOSDEM network devroom this year - about the recently committed sFlow plugin in VPP.

I shared Neil and my work in talk 3 of 4 on the top ic of #vpp at #fosdem in Brussels, Belgium.

# orderedItems[].object.content
Next up at FOSDEM in the Network Devroo is Nathan Skrzypczak of Cisco, showing the super cool loadbalancing plugin in a talk entitled 'Levitation made handy: roll your own Maglev LB with VPP!'.

This is #vpp talk 2/4 today in the #fosdem conference in Brussels, Belgium.

# orderedItems[].object.content
This next one is very close to home for me - Federico Iezzi of Google and Mohammed Hawari of Cisco, co-present the underlying details of Unleashing 100 Mpps with FD.io VPP on GCP.

Marrying DPDK and VPP with Google's Andromeda network stack and its Titanium (aka E2000) network cards: magic.

This is #vpp talk 1 of 4 at #fosdem in Brussels, Belgium.