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

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?

How’s the grounding? Sounds like you’ve probably lost a port somewhere along the way.

You should put all of your STP settings back to where they were, mucking around without understanding the complexities of STP will cause you unbelievable pain. If STP was the issue Meraki would report the switch port status as Blocked, and that would only happen if there was a way for traffic on the far end to work its way back via a separate path.

1 Like

I would also suggest getting the wireless link(s) up between two laptops and work out from there.

Could be something as simple as a misalignment since you’ve described different dB meter readings.

1 Like

Yes try isolating the dishes and testing them to see if they work first. The discarded packets might be due to the dishes not transmitting correctly. You might want to use AirOS or AirView to troubleshoot the dish connections.

1 Like

^^ Definitely what Will has pointed out, when you work with Ubiquiti stuff you want to remove the possibility of it being the radios first. It’s much easier to sort out if you know the radios are communicating properly.

1 Like

Isaac and Will are correct - test your point to point links individually to make sure they are working correctly (e.g. as reliable as a piece of Cat6 ideally). However, being radio you have two other issues to consider:

1/ radio frequency channel settings. Each pair of units should be operating on a different radio frequency. No antenna is perfect and you will get bleed-over at your central radio hub point even if the antennae are point in different directions, unless they are adequately separated by channel frequencies. It does not matter what the modulation method is, the principal applies regardless.

2/ You mention you have a car park of some kind between the buildings. All radio systems have problems with ground reflections where the direct signal suffers interference from an indirect signal reflected off some surface, usually an earth plane (e.g. the ground or across water). If you have vehicles in an intermediate car park you have lots of nice reflective surfaces that keep moving periodically, so your interference pattern at the receivers will change regularly. You therefore should have twin-diversity receivers at both ends of each link.

You also have an issue with trying to run STP, which indicate you are running everything on a flat LAN. DON’T DO IT! Each of your end point buildings should have their own separate IP subnet with your Cisco Meraki MS220 switch running separate VLANs for each one. You should then use a router on the main campus to link them to your main network and external WAN.

Operating as above should mean you can remove any STP settings as you won’t need them. Broadcast packets will remain within each VLAN(subnet) and reduce the radio traffic loading on each radio link. To establish how effective your solution is, use a patch cable to link 2 ports on the same VLAN. You will see broadcast packet traffic build exponentially on that VLAN(subnet), but the other VLAN(subnet)s will not be affected.

1 Like

Thank you all for your replies!

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

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 - God’s timing, maybe?). 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 all of your help, everyone!

** . “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!