How do I restore my point-to-point connection?

[svbc_david]

Question: "How do I restore my point-to-point connection?"

Problem and Network Description:

I’m having trouble in particular with Wi-Fi connectivity via a point-to-point connection between the church (using enterprise equipment) that I work for and it's residential triplex (church-owned), though I’m not sure of the exact location of the problem. The relevant stretch of connections are as follows:

A --> B --> C --> D --> E --> F --> G --> H --> I --> Rest of Network

A = Wireless client devices (cell phones and laptops).

B = D-Link AC1200 MU-MIMO Wi-Fi Router, wired via Cat6 ethernet cable.

C = Adapter box for 1st dish, wired to router and wall jack.

D = Cat6 keystone wall jack.

E = 1st Ubiquiti Networks NanoBridge M5 wireless dish*, wired via Cat6 ethernet cable to wall jack.

F = 2nd Ubiquiti Networks NanoBridge M5 wireless dish*, wired via Cat6 ethernet cable to adapter box.

G = Adapter box for 2nd dish, wired via Cat6 to dish and patch bay.

H = Patch bay, with Cat6 jumpers to switch.

I = Cisco Meraki MS220 switch.

*.I do not have the exact distance between the two dishes, but the separating parking lot is a fair size with a length of maybe 60-ish parking spaces. That said, given the angle and additional lawn distance, the total should be in the ballpark of 1000ft.

This particular point-to-point connection has worked with few if any issues over the course of the last two and half years (so, not a new installation). Everything on the network-side works fine, including various devices connected via other ports on the same switch.

Potentially Important Note:

Close to the same time as the problem began - yet at a distinctly different time (close to 10-15 minutes’ separation) - two switches were taken offline. To the second deactivated switch was connected a 3rd dish whose partnered 4th dish had been removed and offline for the better part of a week. The positioning of this 3rd dish faces east while the 2nd dish faces south and the 1st dish faces north (3rd and 2nd dishes are on opposite corners of the same side of the building).

Investigation and Troubleshooting:

The indicator lights on both dishes show that both power and network <---> connection are on, the difference between the two being that the 1st dish has a signal strength of nil (zero indicator lights are on (out of four) for signal). The signal indicator lights on the 2nd dish were difficult to see due to the sunlight, but at least two of the indicator lights were alight, possibly all four.

I have run cable tests indicating that the cable status is “OK” and, for all visual indicators, the cables appear both undamaged and properly attached (as opposed to slightly unplugged). These connections include:

1) The patch bay jumper cable connecting the 2nd dish’s cable run to the switch.

2) The cable between the 2nd dish and the patch bay.

3) The cable connecting the adapter to the dish.

4) The cable connecting the adapter to the switch.

One advised possibility from internet research was interference; however, as such has not been an issue before and there has only been the removal of lines with no additions to the affected area, this seems quite unlikely.

I have rebooted the switch and power-cycled the dish’s port, as well as disabling and re-enabling the port, with no luck. As I looked closer at the port in the Meraki Dashboard for only a second an icon appeared over the port, then disappeared. I investigated and determined that the icon reported that “STP [was] discarding packets.” Since the dish-less deactivated switch had been the RSTP root, I set the STP priority to “zero” on our core switch, though this did not resolve the issue.

In the switch configurations for the 2nd dish’s switchport I tweaked as many settings as I could think relevant, observing the lack of change and then returning to former settings to try the next tweak. Among them, I disabled RSTP altogether, then re-enabled it; changed the STP Guard setting to Root Guard, then BPDU Guard, then Loop Guard, then returned it to Disabled (default); changed the port type from Trunk to Access, then back; all without change.

The Event Log reports the STP status as changing frequently between 10fdx and 100fdx.

On the Summary page for the 2nd dish’s port, under the Packets section, time set at “for the last 1 day” (longest possible), it reports 7 “CRC align errors” and 2 fragments, all of which were received and none of which were sent. Broadcast packets sent number close to 100,000 and Multicast packets 220,000, but both report 0 received.

At this point, I don't know what else to do - is there a specific point that I've overlooked that would allow me to restore my point-to-point connection?

[PhilipDAth]

You'll probably need to find a Ubiquity forum for this one.

I would say you would need to look at the Ubiquity web interfaces and see what they report.  I'm going to guess an alignment error (one of the dishes knocked out of alignment) because of the lack of signal reported on one unit.  It could also be that water has gotten into RF cables, or a million other things.  But I would start by collecting data from the various parts.

[svbc_david · Accepted solution]

Thank you for your reply!

A quick first note: All R/STP settings that were tinkered with have been restored to their original state.

Thank you for recommending the Ubiquity forum. I checked it out, but it was not enlightening to my situation. Still, thank you!

After taking down the point-to-point connection, testing on the ground at close range, and still not having any success at either a connection or even accessing the antennas themselves, we replaced the dish antennas with the other pair that we had on site (which conveniently had just been taken down the week before last). The connection worked great! Being in the same locations and positions as the former ones, the root problem remains a mystery to me, but the problem I was actually asked to solve (“fix the Triplex Wi-Fi”) is now technically solved. So, thanks again for your help!

* “We” means me + Mike Poole (our A/V expert) + Mike Adams (our maintenance and all-things-handyman expert). In the event that they ever read this: You guys deserve a huge shout out! Thank you!

** Note: Accepted as solution not because it necessarily found the cause of the initial problem, but because it documents what was done to resolve the problem.

[pstewart]

Not to be "that guy" but you mention Ubiquiti equipment and "enterprise equipment" and their gear is far from what I would consider Enterprise.  I have seen a lot of it deployed and there are lots of folks who like it but it's not the most robust kind of gear.

The first thing that comes to mind is whether or not the M5's are reachable from the Internet on a public IP?  If they are, please firewall them as Ubiquiti have historically had lots of security related issues with getting hacked.  I don't recall if the M5 specifically has had issues like that but there was a "virus" floating around for a while that targeted their gear and would cause all kinds of weird stuff like you described to occur.  A firmware upgrade would remove the "virus" as part of the upgrade.

A bit of a long short but wanted to mention it 

Paul