Thanks for the response. I do have Syslog enabled.
We have a single VLAN for our Wireless network and multiple VLAN's for our Data networks that are based on geographical locations.
I am seeing the occasional movement on the Wireless network via Syslog, which I can understand, but the Trap message are coming in at a rate of 6 - 8 a minute.
No high cpu utilisation on any of the switches, but I am seeing Topology changes that I can't account for at the moment.
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 2500simon.read <at> nashua-communications.com www.nashua-communications.com
From: Erik Auerswald [mailto:auerswald <at> fg-networking.de]
Sent: 27 November 2013 12:38 PM
To: Enterasys Customer Mailing List
Subject: Re: [enterasys] - Troubleshooitng the Moveaddtrap command
do you have syslog configured as well? I seem to remember that a syslog message including the MAC address is generated as well.
I used it on N-Series switches quite some time ago. I am quite sure there were two different messages, only one containing the MAC address, but both created by the moveaddrtrap command.
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald <at> fg-networking.de
Gesellschaft für Fundamental Generic Networking mbH
Geschäftsführung: Volker Bauer, Jörg Mayer
Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
On Wed, Nov 27, 2013 at 09:44:19AM +0000, Read, Simon wrote:
> 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
> simon.read <at> nashua-communications.com<mailto:name.surname <at> nashua-commun
> [Nashua Communications EMAIL Logo2.gif]
> From: James Andrewartha [mailto:jandrewartha <at> 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:
> 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.
> From: John Kaftan [mailto:jkaftan <at> utica.edu]
> Sent: 12 November 2013 8:35 PM
> To: Enterasys Customer Mailing List
> Subject: [enterasys] Wireless 8.31 Bridging at AP unexpectedly
> 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 listserv <at> unc.edu<mailto:listserv <at> unc.edu> with the body: unsubscribe enterasys Simon.Read <at> nashua-communications.com<mailto:Simon.Read <at> nashua-communications.com>
> 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 listserv <at> unc.edu
> body: unsubscribe enterasys auerswald <at> fg-networking.de
To unsubscribe from enterasys, send email to listserv <at> unc.edu
with the body: unsubscribe enterasys Simon.Read <at> nashua-communications.com
- --To unsubscribe from enterasys, send email to listserv <at> unc.edu with the body: unsubscribe enterasys gneu-enterasys <at> gmane.org