R700 APs (previously connected) on remote subnet disconnected from ZD

  • 1
  • Question
  • Updated 3 years ago
R700 APs on remote subnets show disconnected, although they are pingable by the ZD, have the correct ZD address (discovered by DNS name), and can ping and traceroute the ZD by both IP and DNS name.

I don't really understand why they are not connecting when all connectivity and address settings seem to be fine. In this particular instance with have 3 APs on a remote subnet and two of them show disconnected while one of them still remained connected. All have the exact same settings and are part of the same AP group.
Photo of B4BTech

B4BTech

  • 7 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Monnat Systems

Monnat Systems, AlphaDog

  • 714 Posts
  • 151 Reply Likes
Hello B4BTech,

quick questions:

How Remote and disconnect AP's are reaching ZD? MPLS? VPN? Public internet?
what is LED status on AP for DIR LED?
Have they ever worked?
how Remote connected AP is different from disconnected remote AP? I mean is it at a different physical remote location? or network route?
on the remote AP side, is router or firewall router configured to allow LWAPP traffic?
Latency of the link between ZD & disconnected remote AP's?
Did you try rebooting the remote AP to see what happens? do they connect ok?

answers to above will help in guiding you further.
Photo of B4BTech

B4BTech

  • 7 Posts
  • 0 Reply Likes
All three of the remote APs I'm referring to go through a site-to-site VPN set up between two Fortigates and are in the same physical location, connected to the same switch. All three of them worked great for a couple of weeks and two of them disconnected inexplicably one weekday morning. There were no network changes made. Latency is a fairly steady 50ms from AP to ZD, and of all the test pings I have run I haven't seen any dropped packets. The APs are mounted very high in a ceiling so I can't see the lights. I have tried rebooting them with no improvement. There really is nothing different between the three APs, they were all configured identically and have the same firmware. MTU size is 1024.
Photo of B4BTech

B4BTech

  • 7 Posts
  • 0 Reply Likes
Forgot to add, all traffic is allowed over this site-to-site VPN tunnel and SSHing into the problem IPs they report their status as "sulking." However, doing a show director returns the correct IP address and pinging the ZD address and DNS name is successful from the problem AP.
Photo of Monnat Systems

Monnat Systems, AlphaDog

  • 714 Posts
  • 151 Reply Likes
Hello,

Status as "sulking." means that they are not able to reach ZD for some reason. If these 2 disconnected AP's are connected, configured, installed in same way as other remote connected AP then try few things:

Remove/delete these 2 two AP's from ZD. Ensure that you have connectivity to these AP's even after you have removed them. SSH into both the disconnect remote AP's and set the ZD IP address manually by running the following command

set director ip (x.x.x.x)

where x.x.x.x is the Ip address of the Zone Director and then reboot

Post above steps, keep an eye on the ZD to see if these two come up or not and logs. if it works good and if not then do the following:

Swap the ETH cable going into working AP to not working one just to see if that makes any difference.
Check for cabling issues on disconnected AP's
Check for switch port configuration between working port and not working port
Please check in fortinet for any errors or logs for these two AP.

if all of the above fails then try uploading the support file for those 2 AP's would help in finding clues.

Hope this helps.

PS: read this - https://support.ruckuswireless.com/an...
Photo of Justin Cottrell

Justin Cottrell

  • 1 Post
  • 0 Reply Likes
Photo of Monnat Systems

Monnat Systems, AlphaDog

  • 714 Posts
  • 151 Reply Likes
Justin,

well if it is MTU related then as you mentioned that other single AP which is working ok should also NOT connect which is on the same physical site as other disconnected AP's and use the same route and firewall.

Symptom for MTU related issue is that AP will connect and will get disconnected right after provisioning, Same cycle will repeat. I assume that in your case AP's are just disconnected. Is this is what is happening in your case?
Photo of Michael Brado

Michael Brado, Official Rep

  • 1968 Posts
  • 275 Reply Likes
I'm a TSE and got a similar ticket which we got to the bottom of. Version 9.8.0.0.373
firmware has a DNS recursion bit bug (ER-1672), that may prevent new APs from
discovering the Zonedirector solely by DNS. The bug fix will be incorporated as
soon as possible.

The workaround in the meantime, is to employ DHCP option 43 with your ZD's IP
address translated by a tool like this link:

http://shimi.net/services/opt43/

Otherwise, you should also be able to SSH into the remote APs and issue the
'set director ip a.b.c.d' command with your ZD's IP address, then 'reboot' and
the APs should find their way to your ZoneDirector.

If DNS only discovery isn't the problem, then back to the VPN/MTU ideas.
Photo of Keith Gipe

Keith Gipe

  • 6 Posts
  • 3 Reply Likes
I know what the problem most likely is as we have experienced this exact issue multiple times. When your site-to-site tunnel blips because of a connection issue, the traffic from the AP to the ZoneDirector then automatically tries to route out your WAN connection instead of going across the tunnel connection. Once that session is active, even after the tunnel comes back up it will continue to try to send that traffic out the WAN interface instead of pushing it back through the tunnel. If you do a diag sys session clear on your Fortigate, it will clear that session and it will send it back out the active tunnel.
Photo of B4BTech

B4BTech

  • 7 Posts
  • 0 Reply Likes
Keith, that was our problem, thanks for your post!