It’s easy to talk about wireless networking as if it were the end-all for client access. To wireless clients, all many want to know is that they get strong signal, connect to Wi-Fi, and somewhere downstream, they magically pop out on the Internet.
Even for those in the business of Wi-Fi, the bigger network picture can get lost after a while. In this article, we’ll review the important aspects of Ethernet that anyone doing wireless also needs to be aware of.
There’s no wireless Ethernet
Wireless networking is a product of the IEEE 802.11 family of standards, whereas Ethernet is based in 802.3 standards.
Wireless is shared media, which means whatever max capacity a given access point (AP) has to give is divvied up among all connected wireless users and only one client device can transmit at a time.
The more clients that connect to a single AP, the slower things get for everyone. For switched Ethernet connections, if you and I both plug into a gigabit switch on different ports, we both get that dedicated gig throughput and the switch is typically architected with plenty of overhead to keep users from slowing each other down.
Good wireless needs good Ethernet
Given that Wi-Fi is generally a segment on a bigger network, wireless access points (or controllers, if in use) are bridges that convert 802.3 on the uplink to 802.11 on the radio interfaces.
The best access points in the world can’t live up to their potential if the Ethernet network that they’re connected to is shoddy. From the quality of UTP cabling in use, to the right kind of Power over Ethernet, to the quality of the switches in play, the wired network very much matters to the Wi-Fi side of the equation.
This is where looking at counters on Ethernet switches that uplink to wireless access points can tell you a valuable story. If you’re seeing collisions and other errors on a connection that’s supposed to be full-duplex gigabit, you have Layer 1 or 2 issues on the wired side that Wi-Fi can’t make up for.
Every problem that happens to a wireless client feels like sucky Wi-Fi, even if it’s a core service acting up like DNS or DHCP (Dynamic Host Configuration Protocol). Even small environments need end-to-end quality of build to safeguard Wi-Fi’s reputation.
The same device can be good on Ethernet, bad on Wi-Fi
It’s an easy assumption to make, but more often than not an incorrect one: The same laptop that acts wonky on Wi-Fi works great on Ethernet, so the WLAN has to be bad. The same misconception happens regarding devices that have both 4G and Wi-Fi adapters, and one side or the other doesn’t act right.
At the hardware and software levels, we’re talking about different circuitry and drivers on individual device subsystems. If a device performs poorly on Wi-Fi but good on Ethernet, the first question should be whether the rest of the wireless devices in the area are generally OK.
If so, it’s time to look at driver updates and the like for the Wi-Fi problem child. Depending on the specific device (like weird Lenovo laptops I dealt with last year), you may have to update not only the WLAN driver, but also BIOS and the chipset driver.
Solutions enforce policy, whether the network is Wi-Fi or Ethernet
Today’s networks have an incredibly diverse range of clients on them, and many Wi-Fi environments have hundreds or thousands of APs and connected clients. Whether PCI is in play, or IoT devices, or just lots of iPads and laptops, high-function networks don’t just happen. They come from well-planned design, which is based on good policy.
Will access points be managed in private IP space? Is a single SSID required, with some sort of intelligence behind it that sorts out users and devices for placement into different VLANs? Will the WLAN support life-safety devices, and how will they be prioritized and given the best network-enabled chance of doing their jobs in times of crisis?
These questions are simple examples of policy decisions that span both Wi-Fi and Ethernet, with many of the points of control and security mechanisms implemented for Wi-Fi actually happening on the wired side of the network.
When we talk about Wi-Fi generically, we’re usually blowing right past the fact that Ethernet bolts up to it. Whether the paradigm in play is sales, upgrading a dated WLAN environment, or client support, it’s pure folly to not address both sides of the network (even in the smallest of environments). If you develop a holistic awareness and approach, both halves of the network will be that much better off.
