Throughout my life, I have often thought, “Why was I made? Why do I exist?” As I became a believer, these questions evolved. I learned that, at a base level, my purpose is to find God, trust in Him and worship Him. But over time and through spiritual growth, the questions became more specific. What is the Body of Christ? Why does the Body of Christ have a heavenly calling? What is that calling? What does it mean that we are told that we will judge angels? And why did God keep the mystery of the Body of Christ hidden until He revealed it through Paul?

I believe these questions are all connected and are a natural part of the believer’s path.

One of the first things God did according to Genesis was create Heaven. Genesis does not describe the creation of the angels directly, but other Scripture gives us that context. Job 38:4-7 places the sons of God at the laying of the foundations of the Earth, when “all the sons of God shouted for joy.” Colossians 1:16 tells us that Christ created the visible and invisible things in Heaven and Earth, including thrones, dominions, principalities, and powers.

Taken together, Scripture shows that God created Heaven and filled it with angels to form an ordered government. When Satan and a third of the angels rebelled, they corrupted that government and abandoned the positions God had given them. Those angels cannot be redeemed and are awaiting judgment. The mystery revealed through Paul is that God will use the redeemed Body of Christ to restore the heavenly government under Jesus Christ.

The Bible does not state that entire conclusion in a single verse. It gives us the pieces across Scripture and we are tasked with finding, understanding, and connecting them. When those pieces are put together, they show that salvation is just the first step in what God has planned for us. God is preparing us for a purpose in the new heavens.

That future purpose should shape the entire purpose of our lives now. Our works will be evaluated at the judgment seat of Christ, and our reward will determine the place and responsibility we receive in Heaven. Understanding what God is preparing us for changes how we should use the body, time, and opportunities He has given us.

I’ve recently been looking for an easily deployable sFlow collector to receive and index sFlow data from various network hardware. I came across this post on sflow.com and am sharing it here because it was extremely helpful for me. I was able to get an sFlow collector up within 10 minutes using their Git repository and Docker, and once I got my network hardware configured, I was able to see traffic based on source and destination ASN with implied country based traffic as well. This is super powerful software that is all free and open source, I would highly recommend this if you’re just getting into sFlow data ingestion and querying.

https://blog.sflow.com/2023/07/deploy-real-time-network-dashboards.html

Internet archive link in case the previous link becomes unavailable: http://web.archive.org/web/20231004203143/https://blog.sflow.com/2023/07/deploy-real-time-network-dashboards.html

The next speed step in pluggable optics is here and pricing is reaching tolerable levels. While they still use significantly more power than QSFP optics, the actual unit cost of the pluggables is reaching sub $500/pc levels, which makes them viable in many more use cases.

I’ve been researching these in order to get myself more familiar with what is available out there. These are my notes for what I’ve found so far. I’ll probably update these a few times as I learn and try more.

400G FR4

The 400G FR4 is a cost-effective pluggable optic that uses duplex LC SMF connectors and operates at a center wavelength of 1310nm. It has a maximum reach of 2km.

Features:

• Duplex LC SMF connectors
• 1310nm wavelength
• 2km maximum reach
• Cost-effective option - available for around $900 list price

Use Cases:

I recently downloaded and processed some large files on Windows Subsystem for Linux (WSL) on Windows 10. Once I was done with the files, I deleted them from my Ubuntu installation, but the VHD file was still taking up the same amount of space as it was before I deleted the files.

It turns out that Windows and WSL does not automatically shrink the VHD file if you delete files - it just automatically expands it as you use more space in WSL.

How to shrink the VHD file

Locate the VHD file in your user directory of Windows. For me, this was: “C:\Users\Nick Plunkett\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx”

In order to reclaim the disk space that is no longer in use in WSL, open a powershell window and run the following commands:

I was recently chatting with a coworker talking through how we use MPO cables and various optics. It made me realize that I have a lot of “in my head” knowledge about fiber cables and optics from working in the networking space over the past 5 years or so, but I haven’t found a good reference point online to point people to and it would probably be better for that information to live written down somewhere rather than it just being in my head. So here it is - everything that is floating around in my head about MPO cables. I’ve done my best to double check what I’m writing here but it should be mostly accurate.

What is MPO?

MPO (Multi-Fiber Push On) in common terms refers to both the connector and the cable itself. It is a cable that contains (currently, 2023) either 8, 12, or 24 fibers terminated onto a single connector, male or female, on both sides of the cable. The cables are available in Single Mode (OS3) and Multimode (OM3, OM4, OM5) formats.

Where is MPO used?

For typical use cases, MPO cables are used in the following applications:

I have recently been integrating Peering Manager into my network deployment at my day job in order to help automate our BGP configuration & management. We run Arista switches running as routers across our entire footprint.

Peering Manager has NAPALM integration built into it, both for managing and deploying configuration as well as polling device status. However, for Arista devices, this requires the Arista eAPI to be enabled on the router, and it must be running in HTTPS mode. That means you need some sort of security certificate installed.

I hadn’t dealt with this before and this wasn’t straightforward. I wasn’t able to find great documentation online for how to do this. Below is my process for generating a self signed key, then using that key to generate a self-signed certificate, then using that certificate to allow HTTPS connections to the router over the management interface for eAPI command and control.

1. Generate a self signed key:

router# security pki key generate rsa 2048 self-signed.key

2. Generate a self signed certificate using that self signed key:

Recently, as a part of network automation at $dayjob, I have been provisioning Salt across our network footprint. One particular problem I’ve run into is that we use a dedicated management VRF on all of our devices.

This was an issue because by default, commands ran on bash on the Arista software run in the default VRF, and in that state we can’t communicate with our management IP networks. There just isn’t a route to the management networks on the default routing table.

Our Salt server only has a Management VRF IP address, and we did not want to configure a proxy to make the Salt master reachable outside the Management VRF.

I had previously had no experience with management VRFs on Linux, and there were no articles that were particularly helpful in helping me to run commands specifically in the management VRF of an Arista switch, within the context of the Bash/Linux shell.

If you find yourself in this same situation, you’ll want to do the following, assuming you were able to get Salt Minion installed on the switch already.

I recently have been working on a home network buildout in my new home. One of the features I was excited to implement was PoE - power over ethernet. My main use case for PoE in my home network was going to be to power small desktop switches and routers near the wall mounted ethernet ports, in order to eliminate unnecessary wall wart style AC to DC power adapters.

I purchased a NETGEAR 16-Port Gigabit Ethernet Unmanaged PoE Switch (GS116PP), one of the highest power budget consumer level fanless switches I was able to find on the current market. It has 16 1Gb ports with a total PoE budget of 183W - more than enough for my needs for now and into the future when it will eventually need to be replaced with a 2.5Gb version. It also supports up to PoE+ and can supply up to 30 watts of power on each PoE port - perfect for my intended use case.

I had gotten a little ahead of myself though, because the only gear I have to power on the other end of the PoE connection is a Mikrotik HeX router. One of the key features of this router is that it can be powered entirely by PoE on the first port - no wall adapter required.

One thing that the documentation of the HeX router leaves vague is that it requires passive PoE - the device itself is not capable of negotiating PoE with any other device. However, the Netgear switch doesn’t supply passive PoE - an old and outdated standard at this point.

The HeX router requires adaptation to passive PoE, which only took a cheap $30 adapter from Ubiquiti - once that was in place, the device was able to sense the passive power and came online and I could ditch the wall wart!

I’ve always loved using my Mac for network engineering tasks - because it has a UNIX-like base it was kind of built from the ground up in a way that is suited to the task. I’ve recently tried to use a Windows laptop for network engineering work to not pigeon-hole myself to one specific platform. One of the seemingly small but high friction activities on Windows through the terminal by default is that when you double click an IPv4 address it only highlights the first octet. This seemingly small annoyance builds up over time when working with tons of IPs and usually causes me to shift back to macOS.

However, I recently learned about delimiters within the various OSes. From what I understand, macOS handles highlighting/double clicking on a system-wide level, while Windows allows each application to handle highlighting/double clicking independently.

In the Windows terminal settings, you can manually set your delimiters - this is where the magic happens.

In October of 2018, I gave a brief Lightning Talk presentation at NANOG 74. It covered how I and my colleagues at CENIC identified and deployed a crafty low cost metro DWDM solution across CENIC’s network backbone. The video recording of this talk is available in the Youtube URL above.