# 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.

# orderedItems[].object.content
This morning, before FOSDEM started, a group of VPP developers and practitioners met at a local bakery for breakfast. Thank you to this wonderful group of people for going the extra mile and meeting!

Picture taken by another FOSDEM participant with Benoit's phone. #fosdem #vpp