Question Mesh Networking Help [long read]

spolo85

Commendable
Oct 7, 2016
10
0
1,520
1
Apologies in advance for the long post, there's a lot of information I need to lay out in order to understand the issue that I'm experiencing. Thank you for those who are willing to read the entirety of this post.

I'm having a problem with my Mesh Network that I've been dealing with for over a year now that I believe I know what the problem is and how to solve it but I wanted to post here to see if others have any other insight from their own perspective.

At a high level, I have a Google Wifi Mesh network among 5 Google Wifi pucks that are all connected through an ethernet backhaul. We have 3 acres of land where I have Nest Cameras set up all throughout the property. In order to support that, I needed to spread my wireless landscape as much as I can and setting up 5 pucks accomplishes this. Below is a link to the diagram of that network

https://drive.google.com/file/d/1Xr-zlM8J7Ngg_en3nMJ9HhkeMHInznum/view

The problem that I'm having is that my Nest cameras are randomly going offline for a short period of time with random WIFI pucks showing offline. It's never the same set of WIFI pucks but it's usually either #3, #4 or #5. Sometimes it's once a month, once a week or a few times a week. I've reset my cameras and my network dozens of times to see if that would clear it up. I've tested the ethernet connections that I've built out myself and they've all tested just fine with no packet losses. Just for some assurance, I've even redone all the end connections on the ethernet and retested with no packet losses. Nothing improved.

I've contacted Google WIFI support twice on this matter over the past year. This is what they responded with...

First Contact:
They ask me why I was using an Ethernet backhaul and I explained to them that I trusted a hard-wired mesh network over a wireless network for performance reasons and that also because #3 was too far from #2 and #4 is too far from #3 for a wireless backhaul to work. They informed me that the issue I was experiencing was due to a bad internet connection to the modem in which the Google WIFI pucks will drop their ethernet backhaul over to a wireless backhaul and because #3 was too far from #2 and #4 is too far from #3, those pucks are going offline as a result. I didn't quite understand why the pucks would do that but whatever, I ended up calling my ISP to fix my internet connection. They informed me that the modem (which is mine) was the issue and that it kept timing out. That on-sight visit was 5 minutes long and cost me $80 but that's another story for another time.... So I ended up buying a high-end Netgear modem for $100 and yet...the problem still persisted

Second Contact:
They're now stating that the "real" issue is that the ethernet connections between #2 and #3 & #3 and #4 are too long and are losing a continuous connection. I informed them that cannot be true because they're less than the rated max distance of 100 meters (328 feet) for ethernet wiring but they said it actually has to be less than 100 feet, not meters. I disagreed with them and just chalked it up to them not reading meters vs feet correctly. However they also informed that when I configure the network (even adding additional pucks later on), I need to do so wirelessly first prior to wiring them up on a switch. For #4 and #5, I had them wired to their switches while I added them to my existing network. So I rebuilt the network and did exactly what they suggested and for nearly 3 months, NO ISSUES!!!!!!

But then recently it has all come back to the same state of weekly dropped pucks/nest camera connections. So I'm now convinced that even though #2 and #3 & #3 and #4 are connected by less than 328 feet of ethernet, that must be the problem and I'm randomly losing packets somehow. So the solution that I'm going to come up with now is using MOCA adapters between those devices, wired with RG6 Coax wiring which has longer distance runs than ethernet. The adapters I plan on using are these

https://www.amazon.com/dp/B078HMDDVS/?coliid=I2N5IAC7H7EO5E&colid=3C7VZVQ2PO7V4&psc=0&ref_=lv_ov_lig_dp_it

Before I go ahead and do that. I'd like to hear from other enthusiast/experts on here to get their thoughts. Mostly because I'm limited to my knowledge with advanced networking but more particularly because I don't trust my ISP or the Google WIFI Support with what they thought were the problems.
 
Take the puck devices and toss them in the trash and use real AP. You likely would have paid much less for the AP to start with. Sound like there is a software issue with these puck devices.

The design you are using with ethernet is the design enterprise customers use in large buildings. 240ft is near the limit so be really sure you are using quality cable and the terminations are well made. The total distance means nothing really. There is some concern that all the traffic from the remote buildings are sharing the same 1gbit bandwidth to the main building. It will have no effect as long as you are not using all the bandwidth.

If you want AP ubiquiti sells quality devices for not a lot of money. They also give away their network management software.

Mesh is pretty much a new marketing name for wifi repeaters. They have some advantages over the older repeaters but they do not compare with ethernet and AP design. If mesh was such a good system large vendors like cisco and avaya would be selling these systems to their enterprise customers who buy thousands of radio units at a time.
 

spolo85

Commendable
Oct 7, 2016
10
0
1,520
1
How do you get power to them?

passive 24V POE only goes around 100ft. POE AF is rated for 100M.

i second unifi. just one place for all config.
I'm assuming you mean between the switches? They're not POE switches, just standard unmanaged switches. Am I reading the max cat5/6 run (not POE) wrong? Every source that I've googled is stating 100 meters, not 100 feet. What I'm getting wrong here?

Even Wiki is stating 100 meters....

https://en.wikipedia.org/wiki/Category_6_cable#Maximum_length
 
Your are correct it is 100 meters. That is also the limit for 802.3AF the "standard" form of PoE. What makes stuff confusing is all the non standard PoE that is running at lower voltages. Part of the reason 802.3af runs at 48volts is to get the distance The huge problem with 48volts is it can damage equipment much more easily so it is a active protocol that only delivers power when requested. Other vendors use other voltages to cut the costs but it also limits the distance. The gets complex and is related to the wire size and how many amps it can pass.

Many times AP are powered over ethernet but I think in your case you have power in each of the remote buildings so it does not matter.

This is partially why you see different numbers for distance. For simplicity as a new user I would just use the 100 meter number and pretend things like PoE do not exist until you need them.

I have not used those silly mesh devices but you would think they have the ability to disable all the extra features and run them as stupid AP. Pretty much a media converter that converts wifi to ethernet.
 
Like Bill, I assume the PoE discussion is a red herring. You have power at the cabana and shed and your devices plug into the wall.

It's hard to believe there is an issue with the wiring ... I would guess the issue is with the devices themselves.

All devices like this run on software and there is always the potential for such software to glitch (section of code that is misread or a variable set to an unsupported value or something). This is why the first recommendation is restart the device and 90% of the time it resolves the problem. But then after some time the problem will crop up again and you have to restart again. In a great world (the one pretty close to perfect, but a bit more realist) these glitches will occur years apart. With lots of "residential" hardware it's usually more like a couple months. In my home, I combat this by having the my APs (I have 2) restart every Sunday at 4am. It's overkill, but I started this 3 years ago and since then my teenagers have not once complained about not being able to connect. I did some quick reading about the google mesh and they don't seem to support an autorestart, so I would recommend a once a week (once a month if you can get away with it) restart of each device. A pain for sure, but I know the google systems are not cheap and would like to see your system working with what you have.
 

spolo85

Commendable
Oct 7, 2016
10
0
1,520
1
It's hard to believe there is an issue with the wiring ... I would guess the issue is with the devices themselves.
I've always assumed the same as well. It has to be the pucks themselves, either a hardware issue or software issue. It's just upsetting that Google was unable to assist me with this and kept putting the blame on something else. I actually do like these products though, specifically the remote access they give you to manage the network via an iOS app. It really helps when I'm away and I need to adjust any settings. I have these setup in 3 other locations as well, 2 businesses and another home and it's great to be able to manage them remotely especially when I need to open any ports.

Also I agree, if they came with a scheduled restarting feature, I would have set that up from the beginning. With those two other businesses that we own, I have all the POS systems restart overnight and it has solved all the problems we were experiencing beforehand. Specifically with the printing.

What are your thoughts of the MOCA adapters? You think its a waste of time or do you think it is possible that these pucks can't handle an ethernet backhaul more than 100 feet and this solve that?
 
Moca should appear to device as ethenet so I can't see how it is better. If you were going to run anything I would run fiber but that also appears as ethernet after it is converted so you can connect your equipment.

It can't be a distance issue. It has to be something stupid like the devices detect each other wifi or some other software problem. The signal in ethernet is actually completely regenerated at each switch. The data is very technically a copy of the data that was received it does not just amplify the signal or something. There likely is some limit but we have run ethernet over 500 meters with switches in between when we did not have the fiber we needed in a building.

There are very tiny delays caused by switches. like .0012ms for a maximum length packet. There are also delays based on the time it takes the signal to travel over the cable but this is about 2/3 the speed of light so again some very tiny fraction of 1ms. If equipment is affected by delays that tiny they need to be in the trash can.

I would not remotely manage equipment like that unless you use VPN to get to the site. Devices like this are the ones that are being targeted by hackers. They do not run any form of firewall or virus software and they are seldom patched by ether the providers or the end users. You do not want these exposed directly on the internet.

The ubiuqiti device can also be remotely managed. This brand is extremely popular for people that do not have the money to buy the fancy enterprise systems. They are not as good but cost a fraction of the systems from say cisco.
 
Reactions: anotherdrew
You can test your longest ethernet run with iperf3. it's not the same as a real ethernet line test but you can check your throughput.
if you're not getting around 900Mbs then the long run might have issues.

I think moca will be a complete waste since you have ethernet. moca is a last resort item for people who have cable ran through their house, but not ethernet. it's a better option than wireless repeaters or powerline.
 
Reactions: anotherdrew

ASK THE COMMUNITY

TRENDING THREADS