Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Archive] [WLC/WLA] APs sharing IP space with local-switching-web-portal clients may have trouble booting up

0

0

Article ID: KB29607 KB Last Updated: 10 Oct 2020Version: 2.0
Summary:

New Access Points (APs) may have trouble booting up when an existing client on another AP in the same VLAN is in web-portal state. The solution is to leave the APs on a separate tagged/untagged VLAN at the uplink switch and create a new VLAN specifically for clients on the uplink switches.

Symptoms:

New APs may have trouble booting up when an existing client on another AP in the same VLAN is in web-portal state (requesting login page from WLC).

 The problem is experienced when the following elements come together

  1. Client and AP share same VLAN (and IP subnet space)
  2. Client relies on web-portal authentication method in this locally switched VLAN
Cause:

1. As the client's VLAN is locally switched, this VLAN does not exist on the controller. It only exists at the AP's uplink switch.
2. The controller needs an IP interface locally in the client IP space to serve the login web-page (this is by design).
3. The controller achieves this by obtaining a local (DHCP) IP address ( in client's VLAN) by tunneling to wireless client's AP or any other AP in the same VLAN/IP subnet space.
4. The WLC serves the web-page to the client through this interface. Authentication moves forward till the client is fully authenticated. Eventually this tunnel from WLC to the AP is torn down.

If at stage 3 above another AP attempts to boot in the same IP space, the WLC will respond to it with its DHCP-derived IP since the controller's IP stack suggests that it is the best route to talk to an AP in that IP space. However, the controller does not let the new AP boot from within an existing tunnel to the client's AP.

At this point, the new/rebooted APs are not able to boot.

Solution:

This behavior is as per design. The underlying assumption is that APs and clients will be isolated on different VLANs as a security measure.

The best course of action is to leave the APs on a separate tagged/untagged VLAN at the uplink switch and create a new  VLAN specifically for clients on the uplink switches.

The vlan-profile for the APs can be updated with this new vlan record with its tag (if needed). As long as separate VLANs exist for clients and APs at the uplink port, this symptom can be avoided. It does not matter which VLAN is tagged or untagged.

Modification History:
2020-10-10: Archived article.
 
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search