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] with the body: unsubscribe enterasys [email protected] --- To unsubscribe from enterasys, send email to [email protected] with the body: unsubscribe enterasys [email protected]
