0

Goal: Provide fault tolerance for LAN clients so access to a service with a service-level agreement (SLA) is not interrupted in the event of an incident with a physical switch.

Question: Is there a configuration which would provide fault tolerance for LAN clients over Ethernet via a single wall port per client?

Stop reading here if the answer to my first question is yes.

--

With Ethernet, In the following topology if the switch stops working the client no longer has access to services provided over the LAN.

client<--> wall port <--> patch panel <--> switch

With Wi-Fi, In the following topology if a single switch stops working the client continues to have access to services provided over the LAN, if the client is in range of both access points (AP) 01 and 02.

                        Wi-Fi client
                       /            \
  Cluster A Wi-Fi AP 01              Cluster A Wi-Fi AP 02
             ||                                 ||
          ethernet                           ethernet
         /                                           \
 switch A                                             switch B    

I'm unaware if there is a standard for Wi-Fi clustering. The type I am referring to is present in Linksys LAPAC line of Wi-Fi access points.

While two NICs and two wall ports for each client would overcome this limitation, it is unrealistic in a usual office environment.

In this scenario would it be preferential to use Wi-Fi with clustering? If so, am I correct in assuming that it would it imply that Wi-Fi with clustering delivers better uptime (especially with mobile devices)?

From a best practices perspective how would this configuration be considered?

Thank you for your answers and input.

Jack.L
  • 18
  • 4

1 Answers1

1

Is there a configuration which would provide fault tolerance for LAN clients

Yes, There is Fault Tolerant Ethernet (FTE). Properiatary (and expensive), but works well.

over Ethernet via a single wall port per client?

Not over a single port, as the copper itself isn't fault tolerant if there isn't anything to fail over to.

With Wi-Fi, In the following topology if a single switch stops working the client continues to have access to services provided over the LAN, if the client is in range of both access points (AP) 01 and 02.

That's not the case by default. WiFi AP roaming is based the wireless signal, not the connection beyond. A WiFi client will happily roam to an AP if the signal is stronger, even if it does not have the same network connectivity. This "failover" (aka choosing another SSID) has to b done manually or the lost AP has to disable its radio under certain circumstaces.

In this scenario would it be preferential to use Wi-Fi

Not really; because WiFi is easily disturbed by a lot of things, does not scale and is a lot less reliable - compared with copper.

with clustering?

Maybe, but i'd settle with roaming. Clustering is usually (Motorola/Cisco/HPE) a not-so-smart "config aware duplicate" mode. In most cases it is a lot more efficient to get more and better coverage by just using slightly overlapping ranges from APs and some smart (active) radio control.

But this wouldn't be my choice, because you'd intruduce an additional point of failure in your architecture, not less. Your APs will need switches, too.

Client > Switch is okay (2-Stage), but Client > AP > Switch (3-Stage) adds another layer of risk.

If so, am I correct in assuming that it would it imply that Wi-Fi with clustering delivers better uptime (especially with mobile devices)?

Not from my personal experiance. A dedicated copper cable with a dedicated switch is usually way more reliable than a shared medium like the air. Especially with configurations like this, using a lot af small cells. And its a lot faster, though.

Have you thougt about using copper and switches, but failing over your clients to WiFi if this fails? Given that the WiFi infrastructure is swiched independently from you clients, this would be a real failover, even including the medium.

bjoster
  • 4,805
  • 5
  • 25
  • 33
  • 1
    `Not from my personal experiance.` Could one say that, compared to copper, in theory, clustering could deliver better uptime but in practice it does not as the technology is not as reliable? – Jack.L Mar 25 '19 at 00:42
  • Yes, thats exactly what I was trying to say. – bjoster Mar 25 '19 at 10:28
  • `Client > AP > Switch (3-Stage) adds another layer of risk.` Could one argue that, if the reliability, or lack thereof, of APs is not taken into consideration then 'Client A > AP01 > Switch01 / Client A > AP02 > Switch02' also adds a layer of redundancy, negating the added risk of an extra layer? – Jack.L Mar 25 '19 at 18:54
  • Last follow-up question: `Have you thougt about using copper and switches, but failing over your clients to WiFi if this fails?` No I hadn't, interesting idea. Is this a common practice? – Jack.L Mar 27 '19 at 19:32
  • Usually we do this the other way (WiFi failing over to copper), but yes, in BYOD envirenments this is pretty common. – bjoster Apr 01 '19 at 08:48
  • I'm surprised that your service order puts Wi-Fi over Ethernet, especially given your comments concerning the difference in reliability. What is the rationale behind this choice? – Jack.L Apr 05 '19 at 08:43
  • This depends on the environment, there is no 100% answer for every case. Which is why I said "in *BYOD* setups", where WiFi>copper is really common. In BYOD environments, 90% of the users are on mobile anyway - in classic office setups it's the other way round. In both cases cable <-> copper failover is the way to go. – bjoster Apr 08 '19 at 14:13
  • 1
    Of course, makes sense. I did think that it was about use case, but didn't want to presume. Just making sure! _(Thank so much, all very informative. I avoided saying thank you until now because I misread and thought it was forbidden on StackExchange! As someone British it was very conflicting to not be overly polite!)_ The answer may be obvious but just to wrap things up, do you have an answer for my 2nd comment (3rd comment down)? – Jack.L Apr 09 '19 at 15:30