When I was a young lad learning networking (informallly in the late '80s and early '90s, and formally in the mid '90s), your could start from scratch and get a somewhat whole picture in a 12 week 2x90min sessions per week term.

Nowadays, It takes 2~3 14 week terms to work through the full stack. And, to top it off, many lazy professors (the older the more common this behaviour, perhaps us a burden to make new powerpoints) dedicate ample swathes of time to dead-wood topics (like 10base2 Eth and the intricacies of the crossover cable), and little to no time to modern topics (like 2.5Gbps and up Eth and the intriciacies of the 64b-66b cookbook of some 10Gbps (and up) Eth). I saw (and heard) this with my own eyes (and ears) when I was teaching networks at undergrad level between 2009~2016.

I've always advocated for a scheme in which you dedicate the first part of the first term by runnig up the stack fast by analyzing only a few SIMPLE components in each layer (say, 802.11b + IPv4 + RIPv2 + UDP + Some apps that use UDP), so that the students get a picture of a whole stack as fast as possible, and the reminder of the 2 + Chage terms to go through the model layer by layer (application to phy like cisco or phy to application like classic, does not matter)...

And to drop all the dead wood.

This gave me my opening to elaborate on my belief that teaching mental models is central to what we as educators need to do. I managed to quote Rodney Brooks one more time on the symbol-grounding problem. He makes the point that robots can’t use transformer-like LLMs to reliably perform tasks, because LLMs don’t have grounding in the real world of physical objects in which robots operate. They manage symbols (words) but can’t connect those words to real objects.

I believe this is equally true when the objects in question are networks. A real understanding of, say, transport protocols and their relationship to end-to-end security is not the same as how the words written about transport protocols normally show up in a document. Certainly this matches my experience from asking an LLM about QUIC and the Internet hourglass for a previous discussion about LLMs in networking education.

I was challenged on the question of how one builds a mental model of networking, and my initial answer – that it is built up over years of experience – was rightly challenged by Jim as well. What can we teach in a one semester course if that’s the expectation? To take an example of a famously complex protocol, I think it’s fair to expect that a student can learn the broad design challenges that are tackled by a protocol like BGP, while we would not expect them to be able to configure BGP policies for an ISP at the end of one semester. //

We need to teach about how abstracting away the details can lead to later problems, of which the initial design of HTTP over TCP is a famous example. //

we did seem to have something like a consensus around a few ideas: teaching principles and the design process more than artifacts; helping students build a solid mental model of networking; and using a problem/solution approach rather than just teaching the current set of protocols.

In the early 1990s, internetworking wonks realized the world was not many years away from running out of Internet Protocol version 4 (IPv4) addresses, the numbers needed to identify any device connected to the public internet. Noting booming interest in the internet, the internet community went looking for ways to avoid an IP address shortage that many feared would harm technology adoption and therefore the global economy.

A possible fix arrived in December 1995 in the form of RFC 1883, the first definition of IPv6, the planned successor to IPv4.

The most important change from IPv4 to IPv6 was moving from 32-bit to 128-bit addresses, a decision that increased the available pool of IP addresses from around 4.3 billion to over 340 undecillion – a 39-digit number. IPv6 was therefore thought to have future-proofed the internet, because nobody could imagine humanity would ever need more than a handful of undecillion IP addresses, never mind the entire range available under IPv6. //

"IPv6 was an extremely conservative protocol that changed as little as possible," APNIC chief scientist Geoff Huston told The Register. "It was a classic case of mis-design by committee."

And that notional committee made one more critical choice: IPv6 was not backward-compatible with IPv4, meaning users had to choose one or the other – or decide to run both in parallel.

For many, the decision of which protocol to use was easy because IPv6 didn't add features that represented major improvements. //

While IPv6 didn't take off as expected, it's not fair to say it failed.

"IPv6 wasn't about turning IPv4 off, but about ensuring the internet could continue to grow without breaking," said John Curran, president and CEO of the American Registry for Internet Numbers (ARIN).

"In fact, IPv4's continued viability is largely because IPv6 absorbed that growth pressure elsewhere – particularly in mobile, broadband, and cloud environments," he added. "In that sense, IPv6 succeeded where it was needed most, and must be regarded as a success." //

But there are plenty of organizations that still see a need for IPv6. Huawei sought 2.56 decillion IPv6 addresses and Starlink appears to have acquired 150 sextillion, which is helping to push more countries past 50 percent IPv6 adoption.

If you have Cisco 9300 model Ethernet switches and haven’t checked their OS versions lately, you should probably do that. Early releases of Cisco’s IOS version 17.x have an issue with flooding ports when a topology change is detected.

Topology changes like bringing a port up or down could cause flooding. When a port being used for WheatNet IP is flooded, the device connected to that port will most likely miss one or more network packets (potentially hundreds), resulting in loss of control signals and/or audio issues (including but not limited to distortion or dropouts).

Every port in your system should have the no ip igmp snooping tcn flood command applied. But even if this command shows up in your switch configuration, it is ignored in some versions of the Cisco operating system.

Deciphering the third transport protocol's four RFCs is a task to rival the proverbial blind man trying to understand an elephant. //

Streams are the primary mechanism making QUIC a better fit for request/response operations. When HTTP runs over TCP, the only way to allow one request to proceed independently of another is to open multiple parallel TCP connections.

With each connection running its own congestion control loop, the experience of congestion on one connection is not apparent to the other connections; each connection tries to figure out the appropriate amount of bandwidth to consume on its own, while competing with the others. And if HTTP runs over a single TCP connection, a single dropped packet blocks the entire progress of any requests in flight until that lost packet is retransmitted.

So QUIC allows for many streams within a single connection, and each stream can make progress independently from the others. A single packet loss only impacts the stream (or streams) whose data was in that packet. At the same time, QUIC can use that one packet loss to respond appropriately to congestion. //

Larry Peterson and Bruce Davie are the authors behind Computer Networks: A Systems Approach and the related Systems Approach series of books. All their content is open source and available for free on GitHub. https://github.com/SystemsApproach

The Federal Communications Commission yesterday announced it will no longer approve consumer-grade routers made outside of the US, citing a President Trump directive on reducing the use of foreign technology for national security reasons. The action will prevent foreign-made routers from being imported into or sold in the US.

Routers already approved for sale in the US can continue to be sold, and consumers can keep using any router they’ve previously obtained, the FCC said. But the FCC will not approve new device models made at least partly outside the US unless the Department of Defense or Department of Homeland Security determines that the router does not pose national security risks.

The prohibition applies to both US and foreign companies that produce routers outside the US. Foreign production includes “any major stage of the process through which the device is made, including manufacturing, assembly, design, and development.”

“This action means that new models of foreign-produced routers will no longer be eligible for marketing or sale in the US,” FCC Chairman Brendan Carr wrote on X.

Ethernet switches aren’t exactly made for audio. And yet, they are the backbone of the IP audio networked facility. They have the power to make or break, literally, your broadcast operation. Here are a few things we’ve learned over the years in working with switches.

IP audio networks for broadcast are built on multicast, WheatNet IP audio included. Ethernet switches do not natively manage multicast traffic. They send multicast packets to every port on the switch, whether the devices connected to those ports requested streams or not. When more traffic arrives at the port than the device can handle, flooding occurs and that results in audio dropouts or complete loss of audio.

For this and other reasons, managed switches are best for broadcast. These Ethernet switches have control, security, and monitoring features that unmanaged switches lack. Among the most important are two key IGMP (Internet Group Management Protocol) features for managing audio packets: IGMP Snooping and an IGMP Querier.

Careless big-time users are treating FOSS repos like content delivery networks //

its repository site is at risk of being overwhelmed by constant Git pulls. The team has dug into this and found that 82 percent of the demand comes from less than 1 percent of IPs. Digging deeper, they discovered that many companies are using open source repositories as if they were content delivery networks (CDNs). So, for example, a single company might download the same code hundreds of thousands of times in a day, and the next day, and the next. This is unsustainable. //

Fox revealed that last year, major repositories handled 10 trillion downloads. That's double Google's annual search queries if you're counting from home and they're doing it on a shoestring. Fox described this as a "tragedy of the commons," where the assumption of "free and infinite" resources leads to structural waste amplified by CI/CD pipelines, security scanners, and AI-driven code generation.

With the ability to intercept all link-layer traffic (that is, the traffic as it passes between Layers 1 and 2), an attacker can perform other attacks on higher layers. The most dire consequence occurs when an Internet connection isn’t encrypted—something that Google recently estimated occurred when as much as 6 percent and 20 percent of pages loaded on Windows and Linux, respectively. In these cases, the attacker can view and modify all traffic in the clear and steal authentication cookies, passwords, payment card details, and any other sensitive data. Since many company intranets are sent in plaintext, traffic from them can also be intercepted. //

“Even when the guest SSID has a different name and password, it may still share parts of the same internal network infrastructure as your main Wi-Fi,” the researcher explained. “In some setups, that shared infrastructure can allow unexpected connectivity between guest devices and trusted devices.” //

The MitM targets Layers 1 and 2 and the interaction between them. It starts with port stealing, one of the earliest attack classes of Ethernet that’s adapted to work against Wi-Fi. An attacker carries it out by modifying the Layer-1 mapping that associates a network port with a victim’s MAC—a unique address that identifies each connected device. By connecting to the BSSID that bridges the AP to a radio frequency the target isn’t using (usually a 2.4GHz or 5GHz) and completing a Wi-Fi four-way handshake, the attacker replaces the target’s MAC with one of their own. //

For now, client isolation is similarly defeated—almost completely and overnight—with no immediate remedy available.

At the same time, the bar for waging WEP attacks was significantly lower, since it was available to anyone within range of an AP. AirSnitch, by contrast, requires that the attacker already have some sort of access to the Wi-Fi network. For many people, that may mean steering clear of public Wi-Fi networks altogether.

If the network is properly secured—meaning it’s protected by a strong password that’s known only to authorized users—AirSnitch may not be of much value to an attacker. The nuance here is that even if an attacker doesn’t have access to a specific SSID, they may still use AirSnitch if they have access to other SSIDs or BSSIDs that use the same AP or other connecting infrastructure. //

Probably the most reasonable response is to exercise measured caution for all Wi-Fi networks managed by people you don’t know. When feasible, use a trustworthy VPN on public APs or, better yet, tether a connection from a cell phone.

for /l %i in (1,1,254) do @ping 192.168.1.%i -w 10 -n 1 | find "Reply"

This will ping all addresses from 192.168.1.1 to 192.168.1.254 one time each, wait 10ms for a reply (more than enough time on a local network) and show only the addresses that replied.

PsychoArs Ars Scholae Palatinae
20y
768
Subscriptor

jhodge said:
If your management network is accessible from the Internet, you're doing it wrong.

It needs to be fixed, but this shouldn't be a full-on freakout for most shops.

Yes and no.

If your management network is accessible from your workload network, you're doing it wrong. All it takes is a compromised laptop/desktop/IoT device that's reaching out and lets a bad actor control it. Defense in depth. //

fuzzyfuzzyfungus Ars Legatus Legionis
12y
10,234

PsychoArs said:
Yes and no.

If your management network is accessible from your workload network, you're doing it wrong. All it takes is a compromised laptop/desktop/IoT device that's reaching out and lets a bad actor control it. Defense in depth.

You also probably want 'your management network' to be internally divided to the degree possible. Ideally you'd like all your BMCs to work for you; but if one of them turns out not to you can't necessarily trust the remainder to protect themselves(and for newly added devices that aren't supposed to require hands-on provisioning more or less blind trust in the first thing that talks to you is a feature; so you really, really, want that to be you).

Not every wire can be cut, or you might as well just get an empty shed for much, much, less money; but there is often not much call for any two random devices on the management network to talk to one another, rather than a relative handful of monitoring and provisioning systems talking to otherwise solitary BMCs who have no excuse for knowing about one another. //

Little-Zen Ars Praefectus
24y
3,201
Subscriptor

Deny_Deflect_Disavow said:
“The vulnerability, carrying a severity rating of 10 out of a possible 10, resides in the AMI MegaRAC, a widely used firmware package that allows large fleets of servers to be remotely accessed and managed even when power is unavailable or the operating system isn't functioning.”

I‘m not sure I understand how firmware can be manipulated if electricity is not available or the OS is not functioning. Secondly, these hosts may be physically wired to any network, yet how can a remote execution or procedure call be issued to the server if powered down?

If there's literally no power, like at all, then they aren't accessible, yes. But that's "no power" as in "the whole building's power is out."

If, however, it's just that the server has been powered off but is still plugged in, and the BMC is connected to a network, you can reach it. These are things like Dell iDRAC, HP iLO, Lenovo IMM, etc. They're designed to be always on, and they provide a way to access the server as though you were physically there, including a virtual console that acts like a connected monitor and keyboard, so you can even remotely power on/off a server if necessary. It doesn't use the installed host operating system - thing of it like a remotely accessible BIOS with a ton of other functionality that also lets you see what's happening on the system in real time. You can even virtually mount ISOs to remotely install an operating system.

It is extremely convenient and I'm sure anyone here who has worked in IT has stories about how iDRAC saved their life at one point or another. I certainly have a few.

However, I can also say - when I was managing servers, all my BMCs were connected to an isolated VLAN, in-building only accessible from another isolated VLAN and to only a very specific set of users with separate logins used solely for interacting with devices on the management network, and remotely over a VPN that only allowed that very specific set of users to access a jump box, which itself was accessible only with the separate management network logins.

You absolutely want to isolate and protect these interfaces specifically because of vulnerabilities like this one.

Enter File size, Transfer Rate, select units, and then click Calculate.

Hi All,
I want to set up WireGuard VPN for remote work with 2 MikroTik routers: “home router” and “travel router”. Could you review my hardware and and config?

Requirements:

• “Home router” is connected to the internet in my home
• “Travel router” will be traveling with me.
• It should be possible to connect a “travel router” to any available internet - phone tethering (most often), another router, WIFI
• Traffic from any devices connected to the "travel router" should be visible as traffic from my “home router”.
• “Home router” will be connected to the router with dynamic public IP

There is no such thing as traceroute.

I used to deliver network training at work. It was freeform, I was given wide latitude to design it as I saw fit, so I focused on things that I had seen people struggling with - clearly explaining VLANs in a less abstract manner than most literature, for instance, as well as actually explaining how QoS queuing works, which very few people understand properly.

One of the "chapters" in my presentation was about traceroute, and it more or less said "Don't use it, because you don't know how, and almost nobody you'll talk to does either, so try your best to ignore them." This is not just my opinion, it's backed up by people much more experienced than me. For a good summary I highly recommend this presentation.

But as good as that deck is, I always felt it left out a crucial piece of information: Traceroute, as far as the industry is concerned, does not exist.

Look it up. There is no RFC. There are no ports for traceroute, no rules in firewalls to accommodate it, no best practices for network operators. Why is that?

Traceroute has no history
First off: Yes, there is a traceroute RFC. It's RFC1393, it's 31 years old, and to my knowledge nothing supports it. The RFCs are jam-packed with brilliant ideas nobody implemented. This is one of them. The traceroute we have is completely unrelated to this.

Unsurprisingly however, it's a good description of how a traceroute protocol should work. //

As the linked presentation explains, traceroute simply no longer works in the modern world, at least not "as designed" - and it no longer can work that way, for several reasons not the least that networks have been abstracted in ways it did not anticipate.

There are now things like MPLS, which operate by encapsulating IP - in other words, putting a bag over a packets head, throwing it in the back of a van, driving it across town and letting it loose so it has no idea how far it's traveled. Without getting much further into how that works: It is completely impossible for it to satisfy the expectations of traceroute.

This "tool" works purely at layer 3, so it's impossible for it to adapt to the sort of "layer 12-dimensional-chess" type shenanigan that MPLS does - and there are other problems, but they're all getting ahead of reality, since traceroute never even worked correctly as intended, and there's no reason it would.

Traceroute, you see, is "clever," which is an engineering term that means "fragile." When programmers discover something "clever," any ability they may have had to assess its sustainability or purpose-fit often goes out the window, because it's far more important to embrace the "cleverness" than to solve a problem reliably. //

I can't count how many times this happened, but I do remember after about four years of doing this, I had come up with a method for getting more accurate latency stats: just ping -i .1. Absolutely hammer the thing with pings while you have the customer test their usual business processes, and it'll be easier to see latency spikes if something is eating up too much bandwidth.

What I discovered is that running two of these in parallel would produce exactly 50% packet loss, with total reliability. I then tested and found that if I just fired up three or four normal pings, at the default interval, it would do the same thing. 30% or 40% packet loss.

There is no telling how many issues we prolonged because everyone was running their own pings simultaneously and the kernel was getting overloaded and throwing some of them out. This is a snapshot of every network support center, everywhere. It is a bad scene.

yuliyp 40 days ago | next [–]

I think the "The Worst Diagnostics In The World" section is a bit simplistic about what traceroute does tell you. It can tell you lots of thing beyond "you can reach all the way". Specifically, it can tell you at least some of the networks and locations your packet went through and it can tell you how far it definitely got. These are extremely powerful tools as they rule out lots of problems. It's useful to be able to hand an ISP a "look, I can reach X location in your network and then the traceroute died" and they can't wonder "are you sure your firewall isn't blocking it?"
It's still a super-common tool for communicating issues between networking teams at various ASes. That the author's ISP thought they were too small to provide reasonable support to is not a strike against traceroute. Rather, it's a strike against that ISP.

Gather around the fire for another retelling of computer networking history. //

Systems Approach A few weeks ago I stumbled onto an article titled "Traceroute isn’t real," which was reasonably entertaining while also not quite right in places.

I assume the title is an allusion to birds aren’t real, a well-known satirical conspiracy theory, so perhaps the article should also be read as satire. You don’t need me to critique the piece because that task has been taken on by the tireless contributors of Hacker News, who have, on this occasion, done a pretty good job of criticism.

One line that jumped out at me in the traceroute essay was the claim "it is completely impossible for [MPLS] to satisfy the expectations of traceroute." //

Many of them hated ATM with a passion – this was the height of the nethead vs bellhead wars – and one reason for that was the “cell tax.” ATM imposed a constant overhead (tax) of five header bytes for every 48 bytes of payload (over 10 percent), and this was the best case. A 20-byte IP header, by contrast, could be amortized over 1500-byte or longer packets (less than 2 percent).

Even with average packet sizes around 300 bytes (as they were at that time) IP came out a fair bit more efficient. And the ATM cell tax was in addition to the IP header overhead. ISPs paid a lot for their high-speed links and most were keen to use them efficiently. //

The other field that we quickly decided was essential for the tag header was time-to-live (TTL). It is the nature of distributed routing algorithms that transient loops can happen, and packets stuck in loops consume forwarding resources – potentially even interfering with the updates that will resolve the loop. Since labelled packets (usually) follow the path established by IP routing, a TTL was non-negotiable. I think we might have briefly considered something less than eight bits for TTL – who really needs to count up to 255 hops? – but that idea was discarded.

Route account
Which brings us to traceroute. Unlike the presumed reader of “Traceroute isn’t real,” we knew how traceroute worked, and we considered it an important tool for debugging. There is a very easy way to make traceroute operate over any sort of tunnel, since traceroute depends on packets with short TTLs getting dropped due to TTL expiry. //

ISPs didn’t love the fact that random end users can get a picture of their internal topology by running traceroute. And MPLS (or other tunnelling technologies) gave them a perfect tool for obscuring the topology.

First of all you can make sure that interior routers don’t send ICMP time exceeded messages. But you can also fudge the TTL when a packet exits a tunnel. Rather than copying the outer (MPLS) TTL to the inner (IP) TTL on egress, you can just decrement the IP TTL by one. Hey presto, your tunnel looks (to traceroute) like a single hop, since the IP TTL only decrements by one as packets traverse the tunnel, no matter how many router hops actually exist along the tunnel path. We made this a configurable option in our implementation and allowed for it in RFC 3032. //

John Smith 19Gold badge
Coat
Interesting stuff
Sorry but yes I do find this sort of stuff interesting.

Without an understanding of how we got here, how will we know where to go next?

Just a thought. //

doublelayerSilver badge
Responding to headlines never helps
This article's author goes to great lengths to argue against another post based on that post's admittedly bad headline. The reason for that is simple: the author has seen the "isn't real" bit of the headline and jumped to bad conclusions. It's not literal, but it's also not satire a la "birds aren't real". The article itself explains what they mean with the frequent claims that traceroute "doesn't exist":

From a network perspective, traceroute does not exist. It's simply an exploit, a trick someone discovered, so it's to be expected that it has no defined qualities. It's just random junk being thrown at a host, hoping that everything along the paths responds in a way that they are explicitly not required to. Is it any surprise that the resulting signal to noise ratio is awful?

I would have phrased this differently, without the hyperbole, because that clearly causes problems. This response makes no point relevant to the network administration consequences of a traceroute command that is pretty much only usable by people with a lot of knowledge about the topology of any networks they're tracing through and plenty more about what that command is actually doing. Where it does respond, specifically the viability of traceroute in MPLS, it simplifies the problem by pointing out that you can, if you desire, manually implement the TTL field, then goes on to describe the many different ways you can choose not to, ways that everyone chose to use. It is fair to say the author of the anti-traceroute article got it wrong when they claimed that MPLS couldn't support it, but in practice, "couldn't support" looks very similar to "doesn't because they deliberately chose not to". It is similar enough that it doesn't invalidate the author's main point, that traceroute is a command that is dangerous in the hands of people who aren't good at understanding why it doesn't give them as much information as they think it does. //

ColinPaSilver badge

It's the old problem
You get the first version out there, and see how popular it is. If it is popular you can add more widgets to it.

If you spend time up front doing all things, that with hindsight, you should have done, you would never ship it. Another problem is you can also add all the features you think might be used, in the original version, and then find they are not used, or have been superseded.

I was told, get something out there, for people to try. When people come hammering on your door, add the things that multiple people want.

20 hrs
the spectacularly refined chapSilver badge

Re: It's the old problem
Cf the OSI network stack, which took so long to standardise that widespread adoption of IP had already filled the void it was intended to.

In some ways that is not ideal, 30+ years on there is still no standard job submission protocol for IP, OSI had it from the start.

Industrial networking is vital to today’s manufacturing landscape. From different types of networks to key components and best practices, this guide will help you navigate the intricacies of industrial Ethernet networking. See video.

As shown in the below picture, the CAN bus level typically ranges (Common-Mode-Voltage = 0V) between 1.5 (CAN_L during dominant bit) and 3.5 Volts (CAN_H during dominant bit). However, the actual signal status, recessive or dominant, is based on the differential voltage Vdiff between CAN_H and CAN_L.

SAE J1939 Quick Reference

• Higher-Layer Protocol using CAN as the physical layer
• Shielded twisted pair wire
• Max. network length of 40 meters (~120 ft.)
• Standard baud rate of 250 kBit/sec
• Max. 30 nodes (ECUs) in a network
• Max. 253 controller applications (CA) where one ECU can manage several CAs
• Peer-to-peer and broadcast communication
• Support for message length up to 1785 bytes
• Definition of Parameter Groups (Predefined vehicle parameters)
• Network Management[1] (includes address claiming procedure.

It must be emphasized that the maximum network length of 40 m (roughly 120 ft.), the baud rate of 250 kBit/sec and the maximum number of nodes (30) are self-inflicted restrictions by the SAE, most probably with the intention to keep everything on the extreme safe side and thus trying to prevent potential runtime problems.

In all consequence, the network length at 250 kBit/sec, according to ISO 11898, is 250 m (roughly 750 ft).

In this guide we introduce the J1939 protocol basics incl. PGNs and SPNs.

Note: This is a practical intro so you will also learn how to decode J1939 data via DBC files, how J1939 logging works, key use cases and practical tips.

Learn below why this has become the #1 introduction to J1939.

You can also watch our J1939 intro above - or get the PDF