Hi, I was reading the 8.32.02.0006 release notes and noticed the following which sounds like what you were experiencing:
> wns0007074-Info > A partially specified policy is one that has “No change” selected for > filters, default topology or default qos. When a > partially specified policy is assigned to a station the “no change” > settings are replaced by the elements from > another policy applied to the station. When a station successfully > authenticates and is assigned a partially > specified policy, the “No change” elements of the policy are replaced > with the corresponding elements of the > WLAN Service’s default authenticated policy. > > Consider the following example. Suppose a VNS is defined that uses > policy P1 for its default non-authenticated > policy and policy P2 for its default authenticated policy. Policy P1 > assigns the station to topology T1 and policy P2 > assigns the station to topology T2. Suppose there is a policy P3, that > has "no change" set for its topology > A client on the VNS will be assigned to P1 with topology T1 when he > first associates to the VNS. Now suppose > the station is assigned P3 by the RADIUS server when the station > authenticates. > Even though the station is on T1 > and P3 has no change set for the topology, the station will be > assigned to T2. When the client is authenticated, > internally on the controller, the client is first assigned to P2 then > P3 is applied. > A similar scenario > exists when the hybrid mode policy feature is set to use tunnel > - > private > - > group > - > id to assign both > policy and topology but for some reason the VLAN > - > id > - > to > - > Policy mapping table does not contain a mapping for the > returned tunnel private group id. In this case a > station that successfully authenticates would be assigned the > filters and default QoS of the WLAN Service’s default authenticated > policy and the topology with the VLANID > contained in the Tunnel > - > Private > - > Group > - > ID of the ACCESS > - > ACCEPT response. > If this is no > t the desired behavior, then > 1. Avoid using partially specified policies. > 2. When the controller is configured to map the VLAN ID in the Tunnel > - > Private > - > Group > - > ID response to a policy > using the mapping table, ensure that there is a policy mapping for each > VLAN ID that can be returned to the > controller by the RADIUS server. On 14/11/13 05:52, Mark Lamond wrote: > > Hi there, > > > > This is my experience: > > > > I have seen this on C4110’s with 3610 AP’s on various 8.x software > levels. It caused no end of head scratching! > > > > If no default topology is set on your VNS, the default policy (under > “Global”) is applied. As I understand it the default policy can come > into play for a number of reasons – failed Auth etc, and sometimes, > very occasionally for no obvious reason at all when a client connects. > > > > By default the global policy is to bridge at AP untagged and the > associated filter rules allow all traffic. It’s dangerous default > behaviour in my opinion! Deny would be safer because this leakage of > traffic would have gone un-noticed had we not been running DHCP in the > AP VLAN. Be sure to change the HWC and AP filter rules to deny all on > all controllers as a safeguard, if you do not want to use the default > policy. > > > > On a basic VNS, where no dynamic policy is occuring we are always sure > to assign the default topology on the WLAN service to be the same as > that in the associated policy. That way should something odd happen as > the controller processes the client’s request to connect, clients will > always stay in the correct topology. > > > > Also, if you are dynamically changing policy using NAC/RADIUS etc the > problem is more likely to occur. There appears to be a transition > stage in the process where your client has the default policy applied. > > > > With an unrestricted default policy in place if the client happens to > perform a DHCP request during that time it may end up with an address > from the VLAN your AP resides in. > > > > To add more confusion, by the time you look at the reporting screen it > will show the correct policy applied - yet the client has an invalid > IP it has obtained from the AP VLAN! And because the client has what > it thinks is a valid IP, when the policy finally does change the > client does not request another DHCP address and happily sits there, > unable to communicate. > > > > Very confusing – a wireshark capture taken from the AP radio and > Ethernet interfaces (great feature by the way) proved what was going > on. This all happens in a very short time window, but it is enough for > a DHCP server to answer back and reply to the DHCP request. > > > > I’m glad Charles has described exactly the same behaviour and solution. > > > > Mark. > > > > > > > > > > > > ------------------------------------------------------------------------ > > *From:*John Kaftan [mailto:[email protected]] > *Sent:* 12 November 2013 8:35 PM > *To:* Enterasys Customer Mailing List > *Subject:* [enterasys] Wireless 8.31 Bridging at AP unexpectedly > > > > Hello: > > > > We have upgraded to 8.31 and are now managing our policy from PM. We > are having issues with some APs bridging some clients at the AP. I > assume that is what is happening because clients are getting on the > same network that the APs are on. This should not be the case because > all of my VNS topologies are bridging at the controller. It is pretty > darn freaky since that setting is set a the WLAN Service\Role level. > > > > Has anyone else seen this issue? I'm freaking. > > > > This causes big problems as security is bypassed as well as the > wireless clients are eating up all of the IPs on the LAN network and > my wired clients cannot connect. > > > > > > > > > > -- > > John Kaftan > > IT Infrastructure Manager > > Utica College > > > > * --To unsubscribe from enterasys, send email to [email protected] > <mailto:[email protected]> with the body: unsubscribe enterasys > [email protected] > > * --To unsubscribe from enterasys, send email to [email protected] > <mailto:[email protected]> with the body: unsubscribe enterasys > [email protected] > -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 --- To unsubscribe from enterasys, send email to [email protected] with the body: unsubscribe enterasys [email protected]
