Miscreants in Action
Some short rants that just might help. But probably not.
Monday, February 26, 2024
Where are the rants?
Friday, November 10, 2023
Edge Computing (or something)
A little over a month ago (October 4/5, 2023 if you're reading this in the far future), I was invited to be a delegate at Gestalt IT's second Edge Field Day (#EFD2). I'd participated in a couple of earlier Field Days, so I knew the format: Vendors would present information to a group of technical folks and discussion would ensue.
At the moment, the core of my consulting work lies in helping a WISP with networking issues, and giving technical advice to the State of New Mexico's Office of Broadband Expansion and Access. Also, I run the ABQIX, an Internet Exchange in multiple data centers in Albuquerque, New Mexico.
I don't really design/implement things that I think of as "Edge Computing," so I wasn't really sure what value I would add. But I knew I'd learn a lot, and am old enough that I'm willing to ask questions that others might feel are obvious without getting embarrassed. Also, I figured I'd be able to add comic relief if nothing else to the fray.
On site, we had a roundtable discussion with all of the delegates to talk about Edge Computing. In the end, we talked about a number of issues important to IT workloads, security, and many other points. But I was still fuzzy on Edge Computing.
Next up was a presentation from Solidigm. Their presentation showcased their SSD products. They've got everything: speed, reliability, physical form, rugged packaging, storage density. At the end of their presentation, I was convinced that if I was an OEM, I'd be considering the use of their gear. But I'm not sure I knew a lot more about Edge Computing.
We then heard from StorMagic. They showed us their SvSAN product which was quite cool. Running on top of hypervisors, you can scale the underlying hardware to create the performance level you need. They also have some cool tools for managing these storage devices as you scale -- in fact, they let us see their Edge Control tool before releasing info publically. I was starting to wonder if Edge Computing was really about storage...
Edge Field Day #2 ended with an introduction to NodeWeaver. I know I didn't grok this product, but it spoke to me. A slim hypervisor with a slick install system that lets you build (yet another) hyperconverged platform. A compute and storage swiss-army knife that runs on virtually any x86 hardware, so you can mix/match to meet your performance needs -- just want you need for Edge Computing. Right?
I went home from Edge Field Day with a heavy heart. I seriously wondering if I'd been worth anyone's time. We had good talks on technology with great people, but I still wasn't sure what Edge Computing was.
On October 20, David Linthicum published an article titled "Whatever Happened to Edge Computing?" The title made me wonder if I could stop worrying about Edge Computing because I'd already missed the boat. (Actually my take on David's thoughts indicate that Edge Computing is alive and well -- but the wealth of possible applications make it difficult to define meaningful standards.)
After the last few weeks, I've decided that I'll define Edge Computing for myself until someone can get me a better definition. To wit:
Edge Computing is a optimization strategy that involves distributed computing.
Or something.
At least it isn't the typical consultant weasel words: "It depends."
Postscript:
Thanks go out to Gestalt IT, Solidigm, StorMagic, and NodeWeaver to making things rattle around my head for a couple of weeks. I didn't realize how much this was bothering me until this article started to flow. My conclusion is overly broad -- but so the the term I tried to define.
David Linthicum gets credit for writing an article that helped me gel my thoughts.
Tuesday, January 17, 2023
An Old Sysadmin Tries Out ChatGPT
(Editorial note: Pretend this post is a Star Trek episode with folks spouting techno-babble, use the words as place holders, and feel the flow of the story...)
A while back, I built some anycasting DNS resolvers using bind on a loopback, and FRR talking OSPF to a router. I finally decided I should hammer together a script to turn off FRR if there was something wrong with the bind process so the servers would pull themselves out of service.
Why not try this new ChatGPT thingee?
I won't bore you with the code that was created, but you'll see my thoughts, and the input I gave to ChatGPT as I worked through this problem until... the end?
Wednesday, September 29, 2021
The Ramp Room
Upon opening the door, you'll find that it immediately blocks your way. It feels like you aren't really welcome, but you move forward anyway...
...And end up in a narrow hallway.
In every city, there is a nexus of communication that isn't ensconced in a pristine data center. A place where various players gather. But not because they really want to do so. Rather, their customers demand they work together.
The path of least resistance nets small, out-of-the-way rooms where fiber optics from multiple carriers co-exist. A place that isn't official, but becomes important.
They have, and will persist.
They will become the old guard for a new generation.
Old gear isn't ever removed. It sits and drinks power from the building.
No one owns it, so no one cleans it.
Everyone is afraid to shut anything off. Few know how to tell if something is still in use or not.
Friday, January 22, 2021
ModemCast -- a podcast
I tend to babble a lot. Sometimes I find people that babble about some of the same things. My friend Nick has talked me into helping him babble as well. His take on things is here:
https://forwardingplane.net/2021/01/21/modemcast-podcast/
You might even enjoy some of our mutual babbling:
https://www.modem.show/
If you find it to your liking, do not blame me.
Sunday, May 26, 2019
Joe's Internet -- an IGP adventure
The IGP's job is to advertise what it knows to all of it's neighbors. If there are multiple paths to a destination, it will pick the best of those available, and pick alternates in case of a path failure. The IGP ensures communication resiliency as long as there are redundant paths.
Quick network overview
J-Inet's IGP Map. Click on it for more detail. |
IGP by psuedo-code
- setup loopback interface address
- set global IGP parameters
- get IGP to adopt the loopback
- for each infrastructure link (one or more)
- setup interface address
- get IGP to adopt the interface
Also, we're going to pretend these routers run something that looks a lot like Cisco IOS from a syntax standpoint. Take a look at a config for routers R1 and R2:
! Router R1
!
! global IGP parameters
router ospf 1
router-id 192.168.92.1
! setup loopback, and add to IGP
interface Loopback20
ip address 192.168.92.1 255.255.255.255
ip ospf 1 area 0
! setup infrastructure link, and add to IGP
interface ether 1
description Link to R2
ip address 192.168.92.129 255.255.255.252
ip ospf 1 area 0
! setup infrastructure link, and add to IGP
interface ether 2
description Link to R3
ip address 192.168.92.137 255.255.255.252
ip ospf 1 area 0
! Router R2
!
! global IGP parameters
router ospf 1
router-id 192.168.92.2
! setup loopback, and add to IGP
interface Loopback20
ip address 192.168.92.2 255.255.255.255
ip ospf 1 area 0
! setup infrastructure link, and add to IGP
interface ether 1
description Link to R1
ip address 192.168.92.130 255.255.255.252
ip ospf 1 area 0
! setup infrastructure link, and add to IGP
interface ether 2
description Link to R3
ip address 192.168.92.149 255.255.255.252
ip ospf 1 area 0
! setup infrastructure link, and add to IGP
interface ether 3
description Link to R3
ip address 192.168.92.145 255.255.255.252
ip ospf 1 area 0
- show ip ospf neighbor
- show ip route
- show ip route ospf
Adding Complications to the IGP setup
- password / encryption / message-digest for IGP on links
- link type (point-to-point vs. point-to-multipoint, etc.)
- changing link metrics
router ospf 1
area 0 authentication message-digest
auto-cost reference-bandwidth 10000
!
interface ether-whatever
ip ospf network point-to-point
ip ospf message-digest-key 1 md5 <some key/password>
Conclusion
Our eventual goal is to ensure that the customers share this type of reachability. To do that, we will use BGP to leverage the IGP information for anything else we need to reach on this network. That will be the subject of the next episode of J-Inet...
Sunday, April 14, 2019
Joe's Internet -- Addressing and Interconnection
Before we get too much closer to J-Inet, I want to point out that I'm going to be using a single network model for continuity between posts. I've worked out IP addressing (v4 & v6), consistent routing policies, and a topology that should suffice for many posts. I've got several posts lined up that should help show at least one path to building a scalable network.
The Interconnects
J-Inet has two transit providers (Transit 1 & 2), three customers (Customer A, B, & C), and a single Peer (Peer 1). Customer C is a bit of stretch for this conversation. They aren't an autonomous system, but we'll look at them anyway, as it may lead some readers to revelations they might not have otherwise.The Network, Prefixes, and Policy
The network itself is pretty simple, and looks like this:
Over view J-Inet's network and interconnects. Click on it for more detail |
J-Inet has two blocks of address space it uses internally, that we will advertise to anyone that interconnects. Those prefixes are: 172.16.32.0/21 and 192.168.92.0/22
Customer B uses 10.193.32.0/22, which was allocated to them from their Regional Internet Registry. They advertise this prefix to us, and any other interconnects they have according to their own routing policy. J-Inet will pass advertise all routes to Customer B.
Customer C uses 192.168.93.112/28. They don't have any other interconnects, so they aren't really an autonomous system (AS). They're in this mix as a kind of anti-example -- a customer that really only acts as an extension of J-Inet's network and routing policy. Neither Customer C nor J-Inet will advertise prefixes to one another.
Peer 1 is another ISP that happens to have equipment in the same building that houses POP 1. J-Inet and the Peer 1 decided that they should interconnect directly. They will be announcing 172.16.34.0/24 to J-Inet. J-Inet will pass internal and customer prefixes to Peer 1, but will not send any routes learned from transit providers.