Read, Simon
2013-11-27 09:44:19 UTC
Hi All,
We recently configured the Moveaddtrap command on our S-Series and it's working as design. The Trap window in NetSight is displaying, "A learned address has moved to a new port".
The problem is that's all I'm getting. No MAC address in the Trap to search for. Spanguardlock isn't shutting any ports and there's no suggestion of a loop under, "show neighbors".
Does anybody have any suggestions on how I can troubleshoot further?
We do have a couple of LAG's, but these appear to be operating normally.
Simon Read
Service Engineer
Nashua Communications (Pty) Ltd.
Unit 10 Growthpoint Business Park,
No 2 Tonnetti Street, Midrand, 1685
Cell: +27 (0)84 676 9200
DDI:+27 (0)10 001 3042
Fax: +27 (0)10 001 2500
***@nashua-communications.com<mailto:***@nashua-communications.com>
www.nashua-communications.com<http://www.nashua-communications.com/>
[Nashua Communications EMAIL Logo2.gif]
From: James Andrewartha [mailto:***@ccgs.wa.edu.au]
Sent: 27 November 2013 09:32 AM
To: Enterasys Customer Mailing List
Subject: Re: [enterasys] Wireless 8.31 Bridging at AP unexpectedly
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:***@utica.edu]
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 ***@unc.edu<mailto:***@unc.edu> with the body: unsubscribe enterasys ***@nashua-communications.com<mailto:***@nashua-communications.com>
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, visit http://www.mimecast.co.za/uem.
---
To unsubscribe from enterasys, send email to ***@unc.edu with the body: unsubscribe enterasys gneu-***@gmane.org
We recently configured the Moveaddtrap command on our S-Series and it's working as design. The Trap window in NetSight is displaying, "A learned address has moved to a new port".
The problem is that's all I'm getting. No MAC address in the Trap to search for. Spanguardlock isn't shutting any ports and there's no suggestion of a loop under, "show neighbors".
Does anybody have any suggestions on how I can troubleshoot further?
We do have a couple of LAG's, but these appear to be operating normally.
Simon Read
Service Engineer
Nashua Communications (Pty) Ltd.
Unit 10 Growthpoint Business Park,
No 2 Tonnetti Street, Midrand, 1685
Cell: +27 (0)84 676 9200
DDI:+27 (0)10 001 3042
Fax: +27 (0)10 001 2500
***@nashua-communications.com<mailto:***@nashua-communications.com>
www.nashua-communications.com<http://www.nashua-communications.com/>
[Nashua Communications EMAIL Logo2.gif]
From: James Andrewartha [mailto:***@ccgs.wa.edu.au]
Sent: 27 November 2013 09:32 AM
To: Enterasys Customer Mailing List
Subject: Re: [enterasys] Wireless 8.31 Bridging at AP unexpectedly
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:***@utica.edu]
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 ***@unc.edu<mailto:***@unc.edu> with the body: unsubscribe enterasys ***@nashua-communications.com<mailto:***@nashua-communications.com>
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, visit http://www.mimecast.co.za/uem.
---
To unsubscribe from enterasys, send email to ***@unc.edu with the body: unsubscribe enterasys gneu-***@gmane.org