Traceroute is one of those tools that network admins reach for instinctively, but most use only a fraction of its potential. This episode strips the command down to its packet-level mechanics—starting with the TTL mechanism that makes it work. Each router along a path decrements the Time to Live field by one; when it hits zero, the router sends back an ICMP Time Exceeded message. Traceroute exploits this by sending probes with incrementing TTL values, revealing each hop in sequence. But the probe type matters enormously. Linux defaults to UDP on high ports, Windows uses ICMP Echo, and TCP SYN probes behave like normal web traffic. A firewall that silently drops UDP probes will produce asterisks even when the path is perfectly functional for real application traffic—a common source of misdiagnosis. The episode also addresses a frequent misconception: traceroute operates purely at Layer 3 and has no visibility into Layer 2 neighbors, ARP tables, or switch fabrics. What looks like a neighbor relationship in the output is often an MPLS label-switched path where the provider has configured "no mpls ip propagate-ttl," hiding internal routers from view. That single hop spanning half a continent with disproportionate latency is a clue, not a bug. For multi-WAN failover verification, traceroute becomes a one-command diagnostic. The first hop reveals which local gateway you hit; the second hop shows which ISP's backbone you're on. Scripting this with ASN checks turns a potential thirty-minute outage into a thirty-second confirmation. Asymmetric routing—where forward and return paths differ—causes subtle issues like stateful firewall drops and unpredictable TCP behavior, and running traceroute from both ends is the definitive way to catch it. The episode closes with practical advice: when troubleshooting and seeing asterisks, switch probe types before concluding the path is broken. MTR combines traceroute with continuous pings for real-time path analysis, and understanding TTL mechanics unlocks the ability to interpret latency patterns, jitter, and hidden infrastructure. Traceroute isn't a legacy tool—it's more relevant than ever in complex SD-WAN and cloud routing environments.
#3901: Traceroute Beyond the Basics: Path Diagnostics
Discover what traceroute actually reveals about network paths, firewalls, and multi-WAN failover.
Episode Details
- Episode ID
- MWP-4080
- Published
- Duration
- 31:08
- Audio
- Direct link
- Pipeline
- V5
- TTS Engine
-
chatterbox-regular - Script Writing Agent
- deepseek-v4-pro
AI-Generated Content: This podcast is created using AI personas. Please verify any important information independently.
Downloads
Transcript (TXT)
Plain text transcript file
Transcript (PDF)
Formatted PDF with styling
You Might Also Like
Never miss an episode
New episodes drop daily — subscribe on your favorite platform
New to the show? Start here#3901: Traceroute Beyond the Basics: Path Diagnostics
Daniel sent us this one — he's been thinking about traceroute, that old standby you reach for when a headless Linux box loses connectivity and ping works to the gateway but not to eight eight eight eight. But he's noticed it does a lot more than just show the path. Multi-WAN verification, failover detection, seeing how traffic actually exits a network — he's spotted some of the deeper use cases and wants to know what else is under the hood. Also admitted he doesn't fully understand the IP address neighbor concept it supposedly exposes.
Which is a great instinct, because that neighbor thing — we should unpack that. It's probably a conflation with ARP tables or routing protocol adjacencies, not something traceroute itself reveals. But the fact that he's asking means he's poking at the edges of what the tool can do, and that's exactly where the interesting stuff lives.
Most admins, let's be honest, use maybe ten percent of what traceroute can actually tell them. They run it, see some hops, maybe some asterisks, shrug, and move on. The output is richer than people think — if you know how to read it.
The timing of this question is good too. Multi-WAN failover setups are everywhere now. SD-WAN has made routing topologies more complex, not less. Cloud egress paths can be completely opaque until you probe them. Traceroute's ability to reveal path asymmetry and routing policy violations — this is not a legacy tool gathering dust. It's a diagnostic scalpel that's more relevant than it's ever been.
A scalpel that a lot of people are holding by the wrong end.
Let's strip this down to the packet level and understand what traceroute is actually doing, because once you get the mechanics, all the diagnostic use cases Daniel's hinting at start to make sense.
We should probably address his neighbor question early, before it sits there nagging. Traceroute operates purely at Layer 3 — it has no visibility into Layer 2 neighbors, ARP tables, switch fabrics, none of that. If you see what looks like neighbor relationships in traceroute output, like multiple consecutive hops in the same slash twenty-four subnet, what you're actually seeing is either a switched infrastructure where intermediate devices aren't decrementing TTL, or an MPLS label-switched path where the provider has configured no mpls ip propagate-ttl. The routers are there — they're just invisible to traceroute.
That Cisco knob — no mpls ip propagate-ttl — that's a common culprit. Service providers use it specifically to hide their internal MPLS topology from customer traceroutes. So you'll see what looks like a single hop spanning half a continent, when in reality you've crossed six or seven label-switched routers inside the provider cloud. The TTL wasn't decremented inside the LSP, so traceroute never saw them.
Which is itself a useful diagnostic clue. If you see a hop with wildly disproportionate latency compared to the ones around it, and the IPs on either side belong to the same provider, you're probably looking at a hidden MPLS core. Not a problem — just architecture.
That's the neighbor misconception cleared up. Now the real question Daniel's asking is: what can this tool actually do when you know how to drive it? And the answer starts with understanding what's happening at the packet level, because the three different probe types — UDP, ICMP, TCP — they each trigger completely different behavior from intermediate routers and firewalls. If you don't know which one you're using and why, you're going to misread the output constantly.
That's the thing. Most people run traceroute, see asterisks starting at hop four, and conclude the destination is unreachable. When in reality, hop four is just a firewall that drops UDP probes on high ports but would happily forward a TCP SYN packet to port four forty-three. Same path, same destination, completely different result depending on which probe type you send.
That's not a bug — it's the tool doing exactly what you told it to do, and you just didn't realize what you told it. The default behavior varies by operating system, which makes this even more of a trap. On Linux, traceroute sends UDP datagrams to high-numbered ports — starting at thirty-three thousand four hundred thirty-four and incrementing. On Windows, tracert uses ICMP Echo Request packets. On macOS, it's UDP by default but with different behavior than Linux.
If you're SSH'd into a Linux box troubleshooting connectivity, and you run traceroute without flags, you're sending UDP probes. If the path includes a firewall that blocks UDP on those port ranges — which a lot of enterprise firewalls do by default — you'll get asterisks even though the path is perfectly functional for actual application traffic.
This is where Daniel's use case about verifying which WAN link is active gets interesting. In a dual-WAN setup, your first hop is going to be different depending on which link is currently carrying traffic. If your primary ISP gateway is ten dot zero dot zero dot one and your secondary is ten dot zero dot one dot one, running traceroute to one dot one dot one dot one immediately tells you which path you're on. But you have to know what you're looking at — the first hop alone might not be enough, because both gateways could be on the same local subnet. What you really want to check is the second hop, which will belong to the upstream provider's network.
Hop one tells you which local gateway you hit. Hop two tells you which ISP's backbone you're on. If you see a Cogent IP at hop two, you know you're on the primary. If you see a Level 3 IP, you're on the secondary. That's a one-command failover verification that doesn't require logging into the router.
You can script that. If you're monitoring whether failover actually worked after a primary circuit drops, you don't need to wait for alerts — you can run a traceroute, grep for the expected second-hop ASN, and know within seconds whether traffic is flowing the way you expect. That's the kind of thing that turns a thirty-minute outage into a thirty-second confirmation.
Which brings us back to the fundamentals. Let's talk about what traceroute is actually doing at the packet level, because once you understand the TTL mechanics and the three probe types, all of these diagnostic scenarios become obvious rather than mysterious.
Here's the core mechanism. Every IP packet has a TTL field — Time to Live. Despite the name, it's not actually measuring time. It's a hop count. Each router that forwards the packet decrements the TTL by exactly one. When the TTL reaches zero, the router drops the packet and sends an ICMP Time Exceeded message back to the source — that's ICMP Type eleven, Code zero.
Traceroute exploits this deliberately. It sends a series of probes — typically three per TTL value — starting with a TTL of one. The first router receives the packet, decrements TTL to zero, drops it, and sends back the Time Exceeded message. Traceroute records that router's IP address and the round-trip time. Then it sends probes with TTL two, which get through the first router but expire at the second. And so on, incrementing until either the destination responds or you hit the maximum hop count, usually thirty by default.
The destination responds differently depending on the probe type. With UDP probes, when the packet finally reaches the destination, the port number is deliberately set to something unlikely to be in use — that high range starting at thirty-three thousand four hundred thirty-four. The destination host receives a UDP datagram on a closed port and responds with an ICMP Port Unreachable message — Type three, Code three. That's how traceroute knows it's reached the end. With ICMP Echo probes on Windows, the destination simply sends back an ICMP Echo Reply, same as ping. With TCP probes, the destination responds with either a SYN-ACK if the port is open or an RST if it's closed — either way, traceroute knows it's arrived.
This is where the firewall implications get interesting. A lot of network administrators don't realize that the three probe types have completely different relationships with firewalls and rate limiters along the path. UDP probes on high ports are the most likely to be silently dropped — many firewalls see them as suspicious or simply don't have rules to handle them. ICMP Echo probes are often rate-limited by routers that prioritize forwarding actual traffic over generating ICMP responses. TCP SYN probes to port eighty or four forty-three, on the other hand, look exactly like legitimate web traffic. They sail through most firewalls that would block the other two.
There's a classic case study here that I've seen play out in real troubleshooting sessions. A sysadmin runs traceroute to a remote server, sees the path stop at hop three with nothing but asterisks beyond, and concludes the destination is unreachable. They spend an hour checking routing tables, firewall rules, BGP announcements — everything looks fine. Then someone suggests trying traceroute with the dash T flag to use TCP SYN probes to port four forty-three. Suddenly the full path appears, twelve hops, perfectly normal latency. The problem wasn't connectivity — it was probe selection.
The intermediate router at hop three was dropping UDP probes but happily forwarding TCP SYN packets. And this is incredibly common. I'd say if you're troubleshooting and you see asterisks starting at a specific hop and continuing to the end, the first thing you should do is switch probe types before you conclude anything about the path being broken.
The other thing to understand about those three probes per TTL is that they're not just redundancy. The three round-trip times tell you something about consistency. If you see times like fifteen milliseconds, sixteen milliseconds, fourteen milliseconds, that's a stable path. If you see fifteen milliseconds, two hundred milliseconds, sixteen milliseconds, something is introducing jitter at that hop — could be congestion, could be a router that's busy with its control plane, could be a load-balanced path where one link is saturated.
That's where we start getting into the limitations of classic traceroute, which is why tools like MTR exist. But before we go there, there's one more fundamental thing about the TTL mechanics that trips people up. Traceroute only shows you the forward path — the route from source to destination. It tells you nothing about the return path. And on the internet, those two paths are frequently different.
This is one of the most powerful diagnostic uses of traceroute that Daniel was hinting at, even if he didn't use that exact term. If you run traceroute from your server to a remote host, and then run traceroute from that remote host back to your server, you can compare the two paths. When they differ significantly — different intermediate ISPs, different geographic routes, different numbers of hops — you have asymmetric routing.
Asymmetric routing isn't necessarily a problem. The internet was designed to handle it. But it can cause maddeningly subtle issues. Stateful firewalls that see only one direction of a TCP flow will drop packets. TCP window scaling can behave unpredictably when the forward and return paths have different bandwidth-delay products. And you get those troubleshooting tickets that make no sense — "I can SSH to the server, but as soon as I try to transfer a file, the connection hangs." Asymmetric routing is often the culprit, and traceroute from both ends is how you catch it.
There's another scenario Daniel mentioned that's worth pulling apart — verifying that a specific WAN link is active in a multi-WAN setup. This goes beyond just checking the first hop. In a properly configured dual-WAN deployment with policy-based routing, different types of traffic might take different WAN links. You might have VoIP going out the low-latency fiber link while bulk file transfers go out the cheaper cable connection. Running traceroute with different source addresses or different probe types can reveal whether your routing policies are actually being enforced the way you think they are.
This is where traceroute becomes a policy verification tool, not just a connectivity diagnostic. You think you've configured your SD-WAN appliance to send all port fifty-three DNS traffic out the primary link? Run a TCP traceroute to port fifty-three from your internal host and see which second-hop ASN shows up. If it's the secondary ISP, your policy isn't working. That's a one-command audit that would otherwise require logging into the SD-WAN controller and parsing flow tables.
Let me give you a concrete case study for this. I worked with a company that had a primary fiber circuit and a backup LTE connection for failover. They had automatic failover configured — if the primary circuit's BGP session dropped, traffic would shift to the LTE link within about thirty seconds. They tested this once when it was set up and then forgot about it. Six months later, the primary circuit actually failed. They got alerts, they checked their monitoring dashboards, everything said failover had worked. But users were still reporting outages for certain applications.
Let me guess — the failover worked for some traffic but not all of it.
They ran traceroute from an affected user's machine to eight eight eight eight and saw the first hop was indeed the LTE gateway — so failover had triggered. But the second hop was still their primary ISP's upstream router. The LTE modem was tunneling traffic back through a VPN to the primary ISP's edge, which was also down. So the path looked like it had failed over, but at Layer 3 it was still dependent on the primary circuit. Traceroute revealed this in thirty seconds. Without it, they would have been chasing phantom configuration issues for hours.
The lesson there is that hop one tells you which local gateway you're using, but you need to look at the full path to understand whether you're actually egressing through the network you think you are. The IP addresses at hops two, three, and four tell the real story.
You can use whois or BGP looking-glass servers to map those intermediate IPs to specific autonomous systems and ISPs. If you're expecting to be on Cogent and hop three belongs to NTT, something is wrong — either your routing policy is misconfigured or your upstream provider is peering in a way you didn't anticipate.
This is all before we even get to the advanced stuff — MTU discovery, MTR, Paris-traceroute. The basic traceroute that ships with every Linux distribution already does all of this, and most people use it like it's just a fancy ping.
Which is why I love that Daniel sent this prompt. He's spotted that there's more to the tool than path discovery, and he's right — there's a whole diagnostic framework hiding in plain sight. The next step is understanding where classic traceroute's blind spots are, and how tools like MTR and Paris-traceroute address them.
Those mechanics are powerful, but they have real blind spots. The first one that tends to bite people is MTU. Path MTU discovery is one of the most underused features of traceroute, and it solves a class of problems that are otherwise maddeningly hard to diagnose.
The scenario is always the same. SSH works fine, small HTTP requests work fine, but the moment you try to push a large file or establish a VPN tunnel, the connection hangs or fragments in weird ways. Everyone blames the application. It's almost never the application.
It's the MTU. Some hop along the path has a smaller maximum transmission unit than the endpoints expect, and the packets are either being fragmented in ways that break things or dropped outright because the don't-fragment bit is set. Traceroute can pinpoint exactly which hop is the bottleneck. You set the DF bit on your probes and start varying the packet size. When a router needs to fragment a packet with DF set, it doesn't just drop it silently — it sends back an ICMP Fragmentation Needed message, Type three Code four. Traceroute captures that and shows you which hop sent it.
You start with a small probe size, maybe fourteen hundred bytes, and work your way up. When you hit the size that triggers the ICMP Fragmentation Needed response, you know two things: the exact MTU limit and exactly which router imposed it. That's gold for VPN tunnel optimization, because you can set your tunnel interface MTU to match the bottleneck instead of guessing and hoping.
This is one of those things where the error message is genuinely helpful if you know how to read it. The ICMP Type three Code four packet actually includes the MTU of the next hop in its payload. So the router isn't just saying "can't fragment" — it's telling you what size will work. Traceroute displays this if you're paying attention to the output.
Which brings us to MTR, because classic traceroute's one-shot approach has a fundamental limitation: it gives you a single snapshot of the path at one moment in time. Network conditions change second to second. A hop that looks clean in one traceroute run might show thirty percent loss thirty seconds later. MTR — My TraceRoute — solves this by combining traceroute's path discovery with continuous statistics collection.
MTR is essentially traceroute and ping having a very productive marriage. It sends probes continuously and updates per-hop statistics in real time — loss percentage, average latency, best and worst case, standard deviation of jitter. You get a living picture of the path rather than a single photograph. And this matters enormously for a misinterpretation that I have seen waste more troubleshooting hours than any other network diagnostic error.
The classic MTR misinterpretation. Hop four shows fifty percent loss. Hop five shows zero percent loss. The admin sees that and immediately concludes hop four is failing.
They're wrong almost every time. If hop four were actually dropping data packets, hop five would also show at least fifty percent loss, because those packets have to go through hop four to reach hop five. The fact that hop five shows zero loss means the packets are getting through hop four just fine — what's being lost are the ICMP Time Exceeded responses that hop four generates. The router is rate-limiting its ICMP replies because its job is to forward packets, not to answer traceroute queries.
This is the most important interpretation rule in network diagnostics and almost nobody knows it. Loss at a hop is only real if all subsequent hops show equal or greater loss. If a later hop shows less loss, the earlier hop is rate-limiting ICMP, not dropping your data. You'd be amazed how many router replacements have been triggered by someone misreading MTR output.
I've seen a production router get yanked out of a rack because of this. The replacement showed exactly the same "problem" because it was never a hardware failure — it was the router doing exactly what it was configured to do, which is prioritize forwarding over diagnostics.
MTR gives you the time dimension that classic traceroute lacks, but it inherits the same probe-type vulnerabilities. Which is where Paris-traceroute enters the picture, and this one solves a completely different problem — load-balanced paths that create optical illusions in your output.
This is one of my favorite pieces of network engineering history. Standard traceroute can produce what looks like a routing loop or a completely nonsensical path when the network is using ECMP — Equal-Cost Multi-Path routing. Different probes with the same TTL value can get hashed to different physical links and take completely different paths through the network. So at TTL four, your first probe might hit a router in Chicago and your second probe might hit a router in Dallas. The output looks like chaos.
The specific scenario that trips people up: you see two IP addresses alternating at the same hop number, and you think there's a routing loop flapping between two devices. There isn't. It's just two parallel links, both perfectly functional, and your probes are being load-balanced across them.
Paris-traceroute fixes this with a remarkably elegant hack. It keeps the IP header checksum and the flow label constant across all probes for a given TTL. Since ECMP hash algorithms use those fields to decide which path a packet takes, keeping them constant ensures all your probes follow the same physical path. You get a clean, linear trace through the network instead of a fan-out that looks like a malfunction.
The name comes from the research group that developed it — a team in Paris studying load-balanced path measurement. And it's one of those tools that you don't need until you desperately need it. If you're troubleshooting a network you know uses ECMP — which is most modern data center fabrics and a lot of ISP backbones — and your traceroute output looks like it was generated by a random number generator, Paris-traceroute is the answer.
There's another environment where traceroute behavior surprises people, and that's containers. If you run traceroute from inside a Docker container or a Kubernetes pod, you'll often see a suspiciously short path — maybe two hops to a destination that should take ten. People assume something is broken. It's usually not.
The container's network namespace only sees its own virtual Ethernet interface and the bridge or overlay network gateway. The host's kernel is forwarding the packets, but the intermediate virtual switching layers — the Docker bridge, any CNI plugin interfaces, the overlay network's encapsulation — those don't decrement TTL. They're Layer 2 constructs from the packet's perspective. So traceroute sees the container's gateway, then the host's external gateway, and then the rest of the internet. Everything in between is invisible.
This matters when you're diagnosing connectivity issues in Kubernetes. If a pod can't reach an external service, you run traceroute from inside the pod and see only two hops before asterisks. The temptation is to conclude the problem is at the node level. But you're missing all the CNI policy enforcement points, the network policies, the service mesh sidecars — none of which show up in traceroute because they operate at layers that don't touch TTL.
Which brings us to the security dimension, and this one cuts both ways. Traceroute is a reconnaissance tool. If an attacker compromises a host inside your network, one of the first things they'll run is traceroute to map your internal topology — they want to know what subnets exist, where the firewalls are, what the egress paths look like. A lot of security teams respond by blocking outbound ICMP Time Exceeded messages at the perimeter. It obscures the internal topology from external probes, but it also makes legitimate troubleshooting harder.
There's a subtler security use case on the defensive side. If you run regular traceroute baselines of your internal network and you suddenly see a new hop appear — a router IP you don't recognize responding to probes — that's either a misconfigured device someone spun up without telling you, or it's something worse. Unexpected traceroute responses from internal IPs are a surprisingly effective intrusion detection signal that most monitoring systems completely ignore.
It's the quiet diagnostic that tells you something changed before any alert fires. And that's really the thread running through all of this — traceroute and its descendants are tools that reward the curious. Daniel's instinct was right. There's a lot more here than path discovery.
Where does this leave the working admin who's three hours into an outage and just needs to know what's actually broken? I think there's a practical workflow here that cuts through the noise.
Start with MTR, not classic traceroute. You get the path and the loss statistics in one pass, and you get them over time instead of a single snapshot. MTR dash dash report with a count of fifty or a hundred cycles gives you enough data to distinguish transient blips from real problems. If the loss looks clean end-to-end, you're probably not dealing with a routing issue at all — move on to application-layer or DNS.
If MTR does show loss, apply the interpretation rule before you do anything else. Loss at a hop is only meaningful if every subsequent hop shows equal or greater loss. If hop four says thirty percent and hop five says zero, hop four is rate-limiting ICMP. It is not dropping your packets. Do not file a ticket about hop four.
I have watched senior engineers get this wrong in the middle of an incident call. The pressure makes you want to act on the first number you see. But the math doesn't lie — packets that get dropped at hop four cannot magically reappear at hop five. If hop five is clean, hop four is clean too. The loss is an ICMP accounting artifact.
Second interpretation rule, and this one applies whether you're using MTR or classic traceroute. Asterisks do not mean the destination is unreachable. They mean your probe type got dropped or ignored. Before you conclude the path is broken, switch probe types. If you're on Linux and getting asterisks with the default UDP probes, try dash T dash p four forty-three for TCP to HTTPS. If that also fails, try dash I for ICMP. One of them will almost always get through unless the destination is offline.
That's the cheatsheet worth memorizing. Traceroute dash T dash p four forty-three target for TCP to port four forty-three — this is your firewall-bypass option, the one that looks like legitimate web traffic. Traceroute dash M udp target if you need to force UDP explicitly. MTR dash dash report target for a single-shot statistical report. And if you see path fan-out that looks like a routing loop, reach for Paris-traceroute — it's in most package managers and it will resolve ECMP artifacts instantly.
The order of operations matters. MTR first for the statistical baseline. If MTR reveals ambiguous loss, TCP traceroute to bypass ICMP rate-limiting. If the path looks chaotic with multiple IPs at the same hop, Paris-traceroute to linearize it. That three-step escalation covers probably ninety percent of the routing diagnostics you'll ever need to do.
The beauty of it is that none of this requires specialized hardware or vendor-specific tooling. It's all in the standard repositories. You can be SSH'd into a barebones Debian box at two in the morning and have the full diagnostic toolkit available in the time it takes to run apt install.
Which is exactly the scenario Daniel was probably imagining when he sent this in. Headless Linux box, no GUI, nothing but a terminal and a problem. These tools were built for that moment.
The Linux Foundation blog post from a couple years back put it well — they called traceroute one of the "classic sysadmin tools," and the reason it's endured is that it operates at a layer encryption doesn't obscure. QUIC can hide your HTTP headers, DNS-over-HTTPS can bury your queries, WireGuard can encapsulate everything inside UDP — but the IP layer is still the IP layer. Routers still decrement TTL. ICMP Time Exceeded still comes back. As long as there are IP routers making forwarding decisions, traceroute or something like it has a job to do.
Which is a comforting thought, but I do wonder about the edge cases. If everything between the endpoints is an encrypted tunnel — WireGuard from the container to the cloud, QUIC from the client to the CDN — traceroute can still see the hops, but it can't tell you what's happening inside the tunnel. The path is visible, but the application-layer topology isn't. That's a blind spot that's only going to grow.
The counterpoint is that tunneled traffic still has to egress somewhere. The tunnel endpoints themselves are addressable and traceable. You might not see what's inside, but you can verify that the tunnel is taking the path you expect — which WAN link, which upstream provider, which geographic route. That's still valuable, even if the inner topology is opaque.
The tool evolves, but the need doesn't go away. Path verification is fundamental. The question is whether we'll need new probe types that can pierce encrypted tunnels, or whether we'll just accept that traceroute sees the outer envelope and we use other tools for what's inside.
I suspect the answer is both, and I suspect someone's already working on it. In the meantime, if this episode gave you a few new tricks for your next two A.troubleshooting session, we've done our job. The full command cheatsheet and links to the MTR and Paris-traceroute docs are in the show notes at my weird prompts dot com.
Now: Hilbert's daily fun fact.
Hilbert: The Seychelles islands, despite being uninhabited until roughly the seventh century, nearly became home to a variant of the Roman hand abacus — a shipment of bronze counting boards was lost at sea en route to a Red Sea trading post around three hundred CE, and ocean current models suggest the wreck drifted within fifty miles of the Seychelles before sinking.
Hilbert: The Seychelles islands, despite being uninhabited until roughly the seventh century, nearly became home to a variant of the Roman hand abacus — a shipment of bronze counting boards was lost at sea en route to a Red Sea trading post around three hundred CE, and ocean current models suggest the wreck drifted within fifty miles of the Seychelles before sinking.
A near-miss for abacus history in the Indian Ocean. All right then.
Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts. If you found this useful, send us your own diagnostic war stories — show at my weird prompts dot com.
We'll be back next week. Until then, check your second hop.
This episode was generated with AI assistance. Hosts Herman and Corn are AI personalities.