Adtran Logo

What Is a Network? Adtran Devices, Total Access 904, and the Switches Worth Trusting

If you want one answer before reading the rest: the Adtran Total Access 904 is a reliable carrier-grade NID, and Adtran switches should be selected by model, not by brand trust. I say that as the person who inspects every network access device that goes out of our integration lab—about 200 units a year. Over the last four years, I've rejected more than a few units for small but costly reasons: wrong firmware, mismatched serial labels, configs with stale passwords. Adtran is not the only vendor that has ever been returned, but the 904 is one of the few pieces of hardware I don't worry about before a deployment window.

Now, 'networks' sounds vague. Let's make it concrete.

What is a network, really?

If you searched what is networks, you probably aren't looking for a textbook answer. You're looking for a reason to choose one box over another. So here's the practical version: a network is a group of devices that agree on forwarding rules and trust relationships. That's it. Routers, switches, NIDs, firewalls—each one is a member of that group. The question isn't 'is Adtran good?' It's 'which Adtran device belongs in your group?'

That distinction gets lost when people talk about 'network equipment' as a single thing. A Total Access 904, a NetVanta switch, and a core router are all made by Adtran, but they're not interchangeable. The 904 sits at the edge, between the provider's infrastructure and the customer's network. A switch sits inside the network, moving traffic between the members of the group. If you put an edge NID where a switch should go, you'll get a bad network no matter how good the device is.

So when I evaluate an Adtran device, I don't test it in isolation. I test it as a member of a specific service group. That's the only way 'quality' means anything.

The Adtran Total Access 904: the device I'd defend

Let me be clear about the Total Access 904: it is not a switch, and it is not a router. Adtran's own documentation groups it with Ethernet NIDs, not with LAN switches. It's a four-port GbE network interface device with carrier Ethernet features—802.1ag CFM, Y.1564 service testing, and the usual OAM tools. I'm not going to quote the datasheet line by line, because the datasheet won't tell you how it behaves after the third firmware upgrade.

In our lab, the 904 has been boring in the good way. It passes the service tests, keeps VLAN group tags where they should be, and doesn't flap when an SFP gets reseated. I don't have hard data on industry-wide failure rates, but I can say anecdotally that our return rate for the 904 is under 2% over the last four years. That's better than most edge devices we've handled.

The one weird issue I remember involved a generic SFP. The unit started dropping small packets intermittently. I assumed the Adtran port was marginal. Then I swapped the SFP for an Adtran-compatible optic and the problem vanished. It wasn't the 904. It was the $80 third-party optic that violated the approved list. There's a lesson there: the cheapest line item on the bill of materials is often the part that costs the most time.

I'd also defend the 904 because its configuration grouping makes sense. You define service groups, assign VLANs to those groups, and then apply OAM profiles. Once you understand that model, the rest of the device follows the same pattern. At least, that's been my experience across multiple firmware versions.

Adtran switches: don't buy the logo

Adtran's switches are a different conversation. I've tested enough NetVanta switches to know that some are solid access-layer boxes. I've also seen enough inconsistencies to know that you shouldn't order a hundred units without verifying firmware and VLAN behavior first.

One specific example: we had two switches, same model, same config template, different firmware releases. The VLAN group behavior was different. One unit handled a QinQ tag the way our service design expected; the other one stripped the outer tag even though the CLI showed the same command. The fix was easy—update the firmware—but we found it during a maintenance window, not before. That's not a reason to avoid Adtran. It's a reason to include firmware version in the purchase order and test a representative unit before anything goes to the field.

Had two hours to approve a switch replacement once. Normally I'd run a full port test and verify the config against our baseline. There was no time for that. I checked the config, the power supply, and the port LEDs, and let it go. It worked, but I still don't like that process. Quality acceptance should not be a gut call for critical devices.

If I'm giving you a rule of thumb for Adtran switches, it's this: use them where you need L2 access with manageable power budgets. For high-density cores, deep buffers, or anything that wants to run hundreds of BGP peers, look at different hardware. I'm not saying Adtran has never made a strong core switch; I'm saying I don't have enough evidence to recommend one, and you shouldn't trust a brand demonstration over your own acceptance criteria.

What I check on every Adtran switch before release:

  • Serial number on the box matches the unit and the purchase order.
  • Firmware version is exactly what we approved, not 'newer' or 'the same branch.'
  • Startup config has no default credentials or leftover lab VLANs.
  • All ports in the assigned VLAN group respond to ping and carry the expected tags.

That last one is the one that most often reveals a defect. 'The switch works' is not the same as 'the switch works for our network's group of services.'

Quality perception: the device is the brand

People in procurement talk about quality like it's an abstract score. From where I sit, it's concrete. A customer who sees a mismatched serial label on a box thinks the vendor is lazy. A customer who gets a config with someone else's RBAC settings thinks the vendor is unsafe. A customer who finds the wrong firmware on a switch thinks the vendor is messy. Every one of those perceptions is a brand failure.

In Q1 2024, we rejected a batch of 24 switches because the label on the outside said one firmware group and the actual CLI said another. Normal tolerance for that is zero. The vendor said it was 'within industry standard' because it was only one minor revision. We sent them back. The vendor reflashed all 24 at their cost, and now our contract specifies firmware checkout before shipment. That's the kind of story that doesn't show up in a brochure.

I've never fully understood why some large orders don't force firmware version and serial number verification as contract terms. My best guess is that procurement assumes the factory image is current and consistent, but that assumption has cost us maintenance hours more than once. So now every order I touch includes a line that says 'factory loaded with [approved version], verified before shipment.' It adds a day to the lead time and takes a week of anxiety out of the deployment.

Where I've been wrong and what I'd change

Looking back, I should have asked for a validation unit before we committed to a large TA904 order. At the time, the quote said 'current release,' and I assumed that meant the same release we had in the lab. It didn't. The difference was harmless in the end—an extra CLI option, a changed log format—but it forced our team to redo part of the configuration guide. If I could redo that decision, I'd specify the firmware version on the purchase order and ask for a screen capture of 'show version' before the shipment left the factory. Not because Adtran is dishonest. Because factory quality depends on the person packing the box, and you always need to verify.

I also don't have hard data on how many field failures are caused by configuration drift vs. hardware. What I can tell you is that the most expensive network outages I've reviewed were not caused by a bad switch or NID. They were caused by a config that looked right and wasn't tested against the actual network group. The hardware was fine. The process was the problem.

Boundary conditions: when not to pick Adtran

I'll be honest about the limits of this opinion. I would not pick a Total Access 904 as a data-center switch, because it isn't one. I would not pick an Adtran switch for a high-density 100G backbone unless I saw a validated reference design from the vendor. I would not pick any Adtran device if I didn't have time to verify the actual unit in my own lab first.

That said, the Adtran device I trust most is the 904. It's an edge device that knows its job: connecting a service provider network to a customer's group of switches and routers with clean Ethernet operations. If your problem is at the edge, the 904 is worth testing. If your problem is in the core, keep looking.

And when someone asks what is networks, you can answer with a line I've used more than once: a network is a group of devices under one policy, and a device is only as good as the quality process behind it.

Leave a Reply