Let's try that with rest of the formatting fixed: On 27/11/13 15:26, James Andrewartha wrote: > 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 not 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. >> >> >> >>
-- 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]
