FortiAP DHCP issues Behind Cisco Catalyst 2960x switches

[thedude78]

Hello,

We are running into an issue deploying our new FAP-U321EV access points. When connected to a Cisco Catalyst 2960x switch they are almost always unable to obtain an IP address.  What we are seeing is that the DHCP Discover packets are not making it past the 2960x.  Other Systems (Windows Machiens, Cisco APs, etc.) all obtain an IP correctly on the same switch port.  DHCP Snooping is currently disabled on the switch and we run into the same issue. Switches have been updated to latest firmware. There are two anomalies that we have noticed which may be nothing.

1. The DHCP discover packets from the AP's are much larger than those of a windows machine. 590 bytes as apposed to 342 bytes.
2. Occasionally (very rarely) the AP will get an IP and when it does it operates fine on the VLAN and connects to the controller without issue (until the lease expires or it is rebooted)

I am hoping that if someone else has run into this, they may be able to share what they have learned.  I have engaged technical support and will update the thread should they provide any answers.

Thanks

[markdr_FTNT]

Hi Dan,

First of all can you confirm that you are using a FortiGate as the Wireless LAN controller with the FAP-U?

As you may be aware, the FAP-U's are Fortinet's 'universal' AP's and can be managed by Forti-WLC or Fortigate (or FortiCloud). TBH - you are probably better off with the normal Fortinet FAP rather than the FAP-U (unless you have a Forti-WLC to manage them) as the FAP-U's do not currently support as many features when managed through a FortiGate (features such as ARRP meaning you will have to channel plan).

Anyway, when the AP's boot up, they will go through a discovery process to try and find a controller. Assuming the CAPWAP ports are open on the Fortigate's interface that the AP's can see, then they will update their UBOOT firmware code from the default (Forti-WLC) firmware to the FortiGate firmware at which point you can authorise them in the Wireless Controller on the FortiGate's Web UI.

In terms of DHCP, ensure that the above is done and that there is a DHCP helper address if the AP's are in a separate subnet to the DHCP server. If the Fortigate is being used as the DHCP server then you should see the address leases in the DHCP monitor. The switch port should be tagged for the user vlans and untagged/native for the management VLAN that the AP's will get their IP address in.

Have you tried plugging a laptop into the same port that the AP's are using to see if it gets an address? This will confirm whether the issue is with the AP's or with the switching infrastructure. Otherwise, connect a console cable to the AP and see what it is doing. 

(Edit - just noticed that you have tried this - please provide the console output from the AP. You may need to manually upgrade the UBOOT firmware)

Let us know how you get on.

Cheers,

Mark

[thedude78]

Hey Mark,

Thanks for the suggestions. We are using a FortiWLC to control the APs.

The issue we are seeing is that the DHCP Discover packet is not being Broadcast beyond the Cisco 2960X switch that the AP is plugged into. Cisco APs and windows machines get an IP fine plugged into the same switchport. 

We see this same behaviour across many APs and Multiple 2960x switches. And can reproduce the behaviour in my lab.

Dan

[markdr_FTNT]

Hi Dan,

Oh so it's with a Forti-WLC.

In that case, assuming the APs are online in the WLC check that the APs are set to L3 connectivity mode and UP set to DHCP. If they're set for L2 discovery then they won't necessarily obtain an IP.

If they are online but disabled they may require their firmware to be updated. It has to be the same as the controller.

Regards

Mark

[markdr_FTNT]

In Reply to Mark Ribbans:

Hi Dan,

Oh so it's with a Forti-WLC.

In that case, assuming the APs are online in the WLC check that the APs are set to L3 connectivity mode and IP set to DHCP. If they're set for L2 discovery then they won't necessarily obtain an IP.

If they are online but disabled they may require their firmware to be updated. It has to be the same as the controller.

Regards

Mark

[jbattam_FTNT]

Hi Dan,

Just to answer your highlighted anomalies; As it looks like Mark has highlighted the issue.

The DHCP discover packets sent from the AP are meant to be much larger than a client device because they contain a lot more information in the request. i.e. many DHCP options for controller discovery. Just as they would be larger from a Cisco AP compare to a client device.

Your FortiAP-U is connecting fine in Layer 2 mode (discovered via MAC broadcast) which is the default option. The AP's follow a specific controller discovery boot cycle; L2 mode (MAC broadcast) is first by default, then L3 mode (IP), then DHCP Options, then DNS discovery and lastly MESH. See attached FAP-U Boot Sequence.jpg

You can modify this default discovery method on your WLC by going to Configuration > Devices > AP > AP# > Connectivity. See AP-Discovery.jpg attached.

If you want your AP's to connect to the controller via IP (layer 3 mode) make sure you specify either the controller IP address or the DNS host name of the WLC, the default is wlan-controller. You would need to add an (A) host record to your DNS server to use wlan-controller.

Alternatively you can also use DHCP options for controller discovery such as Option 138 (CAPWAP controller address).

As your WLC and AP’s are on the same subnet, if you want them to always connect via IP (L3 mode) please make sure you set the discovery method to L3 only. Otherwise for example if you were to restart the WLC the AP may reconnect in L2 mode, depending on where the AP was in the controller discovery cycle and the WLC becoming available again.

#JB_WiFi

[thedude78]

Thanks John,  But I think some details in my original post are being overlooked.  The issues I am seeing is specifically that once the DHCP discover packets are sent from the AP they are dropped on the switch prior to being broadcast. This is not a connectivity issue with the WLC. Other devices connect to the same switch port and their DHCP discover packets are broadcast just fine, the process continues and they happily receive an IP address. So it is not an issue with the DHCP server either. I am simply trying to determine why this is happening, because we don't want to replace every POE switch we have because these AP's are doing something "different".  I was hoping someone else may be running Fortinet universal APs on a Cisco 2960x switch and might be able to share their experiences.

Thanks,

Dan

[thedude78]

Ok, I was able to get to the bottom of my issue.  It seems that "spanning-tree portfast" needs to be enabled on the switchports where the FAP-U321EV AP's are connected or they might not get an IP.  We found this more the case after the AP upgraded from the factory image to 8.4 which we are running on our WLC's.  A fairly simple workaround, although frustrating that we overlooked it for two days.  I guess Cisco must account for this in the boot process of their AP's and Windows systems would just retry after a short time and obtain their IP.

I hope this is helpful for someone else who runs into similar issues.

-Dan

[jbattam_FTNT]

Thanks for the update Dan,

PortFast also known by other switch vendors is the edge port mode for spanning-tree. Meaning the port will go into a forwarding state significantly faster, so this makes sense. Cisco recommend this be enabled for any port where DHCP is being used.

As a best practise all edge ports should be set to port-fast mode otherwise you can experience the same issues with other devices. However I typically disable STP on an AP port as you don't need BPDU being forwarded by your AP's and lot of people have issue with Cisco AP's where STP port fast and BPDU guard are enabled, the recommendation is to not have these standards enabled on switchports where AP's are connected.

Example;https://supportforums.cisco.com/t5/getting-started-with-wireless/cisco-ap-sending-bpdu/m-p/1957089

#JB

[NIKHRAJ]

Hi Dan,

is your issues solved.

I am experiencing a similar issue.
AP is configured to broadcast multiple SSID's
each SSID in seperate vlan and connected to cisco switch in trunk port

interface GigabitEthernet1/0/21
description ** AP U323EV***
switchport trunk native vlan 125
switchport mode trunk
spanning-tree portfast trunk


when windows client machines connect to any one of the SSID it connects
but
1. the client machine does not get DHCP IP address 
2. some times eve if the client machine gets IP address the SSID shows connected but without internet and this time ping to 8.8.8.8 do not happen.

Any solutions?