Copilot Not Autopilot

I’ve noticed a trend recently with a lot of AI-related features being added to software. They’re being branded as “copilot” solutions. Yes, Microsoft Copilot was the first to use the name and the rest are just trying to jump in on the brand recognition, much like using “GPT” last year. The word “copilot” is so generic that it’s unlikely to be to be trademarked without adding more, like the company name or some other unique term. That made me wonder if the goal of using that term was simply to cash in on brand recognition or if there was more to it.

No Hands

Did you know that an airplane can land entirely unassisted? It’s true. It’s a feature commonly called Auto Land and it does exactly what it says. It uses the airports Instrument Landing System (ILS) to land automatically. Pilots rarely use it because of a variety of factors, including the need for minute last-minute adjustments during a very stressful part of the flight as well as the equipment requirements, such as a fairly modern ILS system. That doesn’t even mention that use of Auto Land snarls airport traffic because of the need to hold other planes outside Continue reading

Use AGW for packet radio applications

When creating packet radio applications, there are several options on how to get the packets “out there”, and get them back. That is, how to interface with the modem.

Sure, you can write your own modem, and have the interface to the outside world be plain audio and PTT (push to talk, i.e. trigger transmit). But now you’re writing a modem, not an application. You should probably split the two, and have an interface between them.

KISS

You can use KISS, but it’s very limited. You can only send individual packets, so it’s only really good for sending unconnected (think UDP) packets like APRS. It’s not good for querying metadata, such as port information and outstanding transmit queue.

Think of KISS like a lower layer that applications shouldn’t think about. Like ethernet. Sure, as a good engineer you should know about KISS, but it’s not what your application should be interfacing with.

Linux kernel implementation

On Linux you can use AF_AX25 sockets, and program exactly like you do for regular internet/IP programs. SOCK_DGRAM for UI frames (UDP-like), and SOCK_STREAM for connected mode (TCP-like).

But the Linux kernel implementation is way too buggy. SOCK_STREAM works kinda OK, but does Continue reading

1000BASE-T Part 1 – Introduction

How does Ethernet detect that a link goes down? This, what I thought was a simple question, I asked myself a couple of weeks ago. I realized I didn’t have a very good answer. I realized I had more to learn about Ethernet and the physical layer and so does pretty much the entire networking industry. Through the graceful help of Peter Jones at Cisco, I got in touch with George Zimmerman, an independent professional with a PhD in electrical engineering, a history of teaching at Caltech, and that works within the IEEE on different standards. To answer my initial question, we first need to understand more about Ethernet, and especially the physical layer. As every version of Ethernet has slightly different PHY, I will be covering 1000BASE-T. This will be covered in a series of posts, this being the first.

Going back to the OSI model, most roles in networking puts the focus on layers two to four:

This is natural as most of our work relates to these layers.

When we think of two hosts communicating, we imagine that the transceivers connect to each other and that there are ones and zeroes traveling across the cable:

Continue reading

On the ‘net: Networking Models

I’m writing a series on network models over at Packet Pushers; links to the first three are below.

Looking back at my career in network engineering, beyond some basic concepts and naming conventions, I cannot remember using the OSI model once. I have used the concept of layering, but never the OSI model specifically.

First, models are not sacrosanct. A model is just a tool. If the model you are using is not working for you, feel free to modify it. I find simpler yet extensible models far more effective than complex models for channeling my thoughts. In the past I have tried building huge models that “put everything in one place,” but they do not work for me.

How does a host differ from a middlebox? Hosts are designed to run applications that create and consume packets rather than quickly forwarding traffic through the network. The primary difference is that the source and destination are not two different ports on the same device but rather a virtual interface representing an application and a physical interface.

FRRouting Claims IBGP Loopbacks Are Inaccessible

Last week, I explained the differences between FRRouting and more traditional networking operating systems in scenarios where OSPF and IBGP advertise the same prefix:

  • Traditional networking operating systems enter only the OSPF route into the IP routing table.
  • FRRouting enters OSPF and IBGP routes into the IP routing table.
  • On all platforms I’ve tested, only the OSPF route gets into the forwarding table1.

One could conclude that it’s perfectly safe to advertise the same prefixes in OSPF and IBGP. The OSPF routes will be used within the autonomous system, and the IBGP routes will be propagated over EBGP to adjacent networks. Well, one would be surprised 🤦‍♂️

Read more …

FRRouting Claims IBGP Loopbacks Are Inaccessible

Last week, I explained the differences between FRRouting and more traditional networking operating systems in scenarios where OSPF and IBGP advertise the same prefix:

  • Traditional networking operating systems enter only the OSPF route into the IP routing table.
  • FRRouting enters OSPF and IBGP routes into the IP routing table.
  • On all platforms I’ve tested, only the OSPF route gets into the forwarding table1.

One could conclude that it’s perfectly safe to advertise the same prefixes in OSPF and IBGP. The OSPF routes will be used within the autonomous system, and the IBGP routes will be propagated over EBGP to adjacent networks. Well, one would be surprised 🤦‍♂️

Read more …

Getting Started With Juniper PyEZ Library

Getting Started With Juniper PyEZ Library

In this blog post, we're diving into how to use the PyEZ Python library to interact with Juniper devices. I'll be working with a Juniper vMX device as our example, but PyEZ can work with any other Junos-based device. So, whether you have a vMX, an SRX, or any other Junos device, you'll find this guide helpful.

What we will cover?

  • What is Juniper PyEZ?
  • Why do we need PyEZ?
  • Prerequisites
  • Getting facts from Juniper vMX
  • Getting Interface Stats and Errors
  • A few things to note
  • Closing thoughts

What is Juniper PyEZ?

Junos PyEZ is a microframework for Python that enables you to manage and automate Junos devices. Junos PyEZ is designed to provide the capabilities that we would typically get from the CLI.

You can use Junos PyEZ to retrieve facts or operational information from a device, execute remote procedure calls (RPC) available through the Junos XML API and even install or upgrade the Junos software. But for the sake of this example, we will retrieve the facts from the vMX and then retrieve some interface statistics.

But, Why Do I need PyEZ?

If you're wondering why we need PyEZ, here's a straightforward reason from my experience. I often Continue reading

Recap: KubeCon + CloudNativeCon EU + CalicoCon 2024

Last week we had the pleasure of attending KubeCon + CloudNativeCon EU in Paris, France. It was a fantastic event where we once again had the opportunity to engage in meaningful conversations about Kubernetes, container security, and the latest developments in the open source ecosystem. We also hosted CalicoCon 2024, a co-located event, to talk about our favorite subject: Calico! Let’s take a look at some of the highlights from the conference.

CalicoCon 2024

A large group of KubeCon attendees joined us on March 19th for a full-day event to explore the trends, strategies, and technologies making waves in the Kubernetes networking, security, and observability world. The day included a keynote on Project Calico’s past, present, and future, plus multiple presentations and workshops delivered by Calico engineers that provided a deep dive into topics such as eBPF, Windows HNS, multi-cluster mesh, best practices for network policies, scale, performance, encryption, and compliance.

A good time was had by all in attendance, and two lucky winners of our raffles each took home a pair of AirPods! The day ended with happy hour and networking, where attendees had a chance to meet other Calico users as well as the engineers and leadership Continue reading

1 … 167 168 169 170 171 … 3,855