[j-nsp] AP oddness

[Jonathan Call]

- Have you double checked that the APs are configured with an identical set 
of profiles on all radios?

- Are you terminating end user traffic at the AP via a local switching 
profile, or tunelling everything back to the controller (the default)? If the 
latter, the only thing that the EX4200 port configuration is relevant to is 
the AP getting back to the controller.

And here is where trusting/using the web interface bit me. The affected (and new) APs were missing the correct traffic termination since we put the authenticated users into their respective VLANs directly from the APs:

set ap XX local-switching mode enable vlan-profile company-operations

As far as I can tell this mode can only be configured via the CLI.

- Have you verified that the users are actually ending up on the right VLAN 
via "show sessions network"?

Yep. All of this was working smoothly.

- What code rev are you on? I had quite a few problems during the brief 
time I ran 9.1, so I'd recommend the latest 9.0 release (MR4, I believe).

We're on 8.0.4.3.0, does 9.0 perform better? The both the GUI and SSH connections are incredible unstable on our WLC.

Thank you,

Jonathan



----------------------------------------
> Date: Mon, 1 Jun 2015 22:29:12 -0400
> From: fs at WPI.EDU
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] AP oddness
>
>
> A few basic questions:
>
> - Have you double checked that the APs are configured with an identical set
> of profiles on all radios?
>
> - Are you terminating end user traffic at the AP via a local switching
> profile, or tunelling everything back to the controller (the default)? If the
> latter, the only thing that the EX4200 port configuration is relevant to is
> the AP getting back to the controller.
>
> - Have you verified that the users are actually ending up on the right VLAN
> via "show sessions network"?
>
> - What code rev are you on? I had quite a few problems during the brief
> time I ran 9.1, so I'd recommend the latest 9.0 release (MR4, I believe).
>
> If nothing obvious jumps out, you may also have luck enabling trace debugging
> for the afflicted client:
>
> set trace dot1x level 10 mac <mac-addr>
> set trace sm level 10 mac <mac-addr>
> set trace radius level 10 mac <mac-addr>
>
> You can then use "show log trace" to view the buffer, and "clear trace all" to
> disable the debugging when you're done.
>
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB20351
>
> Frank Sweetser fs at wpi.edu | For every problem, there is a solution that
> Manager of Network Operations | is simple, elegant, and wrong.
> Worcester Polytechnic Institute | - HL Mencken
>
> On 6/1/2015 4:47 PM, Jonathan Call wrote:
>>
>> I have two APs connected to the same EX4200. Both are controlled by the same (and only) WLC. When a client enables WIFI near the first AP that person is able to access the Internet. When the same client enables WIFI under the second AP they cannot connect to the Internet. The port configuration for each AP is identical.
>>
>> The WLC is configured to authenticate clients via Steel Belted Radius (PEAP/802.1X) and put the clients into different VLANs based on their SBR profile. In the case of the first AP the logs show the client IP changing from 0.0.0.0 to the correct IP for their VLAN. In the latter, the client IP is observed changing from 0.0.0.0 to 169.254.x.x as if DHCP (or VLAN assignment) failed.
>>
>> Both ports have the same configuration and any new APs added to the WLC have the same problem.
>>
>> Jonathan
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp