Hi Simon, 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. HTH, Erik -- Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ [email protected] T:+49-631-4149988-0 M:+49-176-64228513 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 > [email protected]<mailto:[email protected]> > www.nashua-communications.com<http://www.nashua-communications.com/> > > [Nashua Communications EMAIL Logo2.gif] > > From: James Andrewartha [mailto:[email protected]] > 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:[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]<mailto:[email protected]> with the body: unsubscribe > enterasys > [email protected]<mailto:[email protected]> > > > 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 [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]
