|
I would agree with the others here that in the real world, one would never do this and as ChuckMountain suggests one would be explaining to client why this approach is very bad idea and not taking the job.
Just to pick up a couple of other thoughts:
Be sure to understand that in enterprise data networking terms a "router" is to hell and back different from the SOHO "get-you-on-the-Internet" omni-box lay people often call a "router."
"Proper" routers are not "Wi-Fi" providers - don't fall into the trap of assuming that because something is called a "router" that it "does Wi-Fi." In an enterprise system, the routing devices that we have at the "edge" and/or availing inter-subnet connectivity rarely offer Wi-Fi.
Yes, a SOHO get-you-on-the-Internet omni-box does "route" and contains a routing engine (as does every other device that uses IP,) but it's pretty basic and such boxes also do a lot of "other" things - ethernet switch, modem, NAT, firewall, DHCP Server, DNS Proxy, yada, yada, and yes there's a Wi-Fi AP built in too. However, enterprise scale system buiders would not be using such omni-box devices. Attached to the "Using Two Routers Together" FAQ pinned in this forum is a block diagram showing many of the functions of a SOHO get-you-on-the-Internet omni-box: In an enterprise system many, if not all, of those functions would be implemented in separate boxes.
It is one of the ironies of deploying large scale Wi-Fi infrastructure that one usually ends up putting more cabled infrastructure in rather than taking it out: Wi-Fi AP's nearly always need to be deployed in places where there is not any data or power available, so we need to run in new cables to the AP locales. Then those cables need to plug into something "the other end" so we need to check there's sufficient ethenet switch ports available and possibly buy more ethernet switches and/or replace them with Power Over Ethernet (POE) capable devices (POE is the most convenient way to get electrical power to Wi-Fi AP's - even then one has to plan carefully the number of AP's deployed versus the POE available on each switch.) After that there's some planning to do to engineer the bandwith (speed) required between the backhaul infrastructure components which might mean 10Gig links and/or link aggregation is required.
Next there's the very much mis-understood concept of "Wi-Fi signal." There is no such thing as "Wi-Fi Signal." Most people think that Wi-Fi is availed by some ethereal energy field called "Wi-Fi Signal" with permeates the ether like The Force. But it isn't like that at all. Wi-Fi links are a two-way conversation between communicating peers like walkie-talkies not a one way broadcast like television. Think of it in audio terms: Wi-Fi is you and a few mates chatting in the pub. It's not a one way "lecture" with everyone in a room passively listening in rapt adoration to the speaker. Just like the pub conversation, for it to proceed usefully, "only one person at a time can speak," - same for Wi-Fi.
So when planning Wi-Fi infrastructure, one starts by assessing the number of clients in each cell, their throughput requirements (speed) then figuring our how many AP's to deploy and where to deploy them rather than using an (overly) simplistic idea of simply painting an area with (fictitious) "Wi-Fi Signal."
To cite example from my own experience, I've availed Wi-Fi in refectories, assembly halls, conference centers, etc. In such rooms a single AP would easily provide the geographical coverage required. But with (say) 100 delegates present, (bear in mind the "only one thing can transmit paradigm,) you've got a 101 to 1 "air time" contention ratio. The throughput would be dreadful, if it even worked at all. Instead, one would deploy multiple AP's - I'd want at least 4 for that number of clients, which drops you down to contention ratios of the order of 26 to 1 in each cell.
The very best way to improve the Wi-Fi contention ratios is to remove as much as possible from Wi-Fi leaving more "air time" available for the remaining Wi-Fi devices. So far from turning all our servers, fixed (non moving) computer, printers, scanners, copiers, etc into Wi-Fi devices, we leave as many of them as possible wired.
In summation, this is way more complicated that just looking at some kit and saying "what shall we replace this box with so we can throw the incumbent away and do it all with Wi-Fi." Things like this need to be (and in the real world are) planned holistically starting with the user requirements then taking a view on how to achieve it, rather than starting with the "kit" and looking for a problem for it to solve.
I am sure we can collectively pursue this further as an academic exercise and tease out the minutia of various aspects, but in the real world, we simply wouldn't do it the way it's been posited. |
|