Flooding of ip unicast traffic

Hi there,
I capture packets from the network from my workstation during 30 minutes without putting the port of the switch in monitor modus. So my guess was that i would only see broadcast messages and some unicast packets where the mac address is not know to the switch.
But i saw some other packets that i could not explain why i can see them. I saw for example a Syn, Ack package which in my optinion i shouldn't see since the mac address should be known to the switch.
I understand that if i see udp messages that it could be possible that i can monitor the whole traffic if the destination host never sends a packet since than the switch will never know where the machine is located and has to flood all the time. But for tcp? A Syn packet ok no problem but i think that i shouldn't see Ack of Syn, Ack....or everything else.
I hope i was clear describing my problem and to resume i have the impression that sometimes packets are flooded even if the switch knows the destination port.
Is there any way how i can verify this?
Thanks a lot.
regards,
ycae

I have seen a configuration of ISA servers where the server deliberately causes all unicast traffic to the server to be flooded. It does this as part of an elaborate load-balancing technique. The way it tricks the switch into flooding all its unicast traffic is by using its NIC MAC address as the source of its outgoing frames, but giving the client a different MAC address in its ARP response. The client sends its frames to a MAC address that the switch has never seen as source, so it floods them.
There are several other reasons why a switch might flood. Are you sure these are MAC unicasts? The first byte of the destination MAC address ... is it even or odd? If it is odd, then you have a multicast or broadcast destination.
Does that help?
Kevin Dorrell
Luxembourg

Similar Messages

  • Product bug: unknown unicast traffic storms from thunderbolt displays

    Hi All -
    Periodically, a random Thunderbolt display will launch a wire rate unknown unicast traffic storm into our LAN and only stop when unplugged from the network. This typically leads to unicast flooding or at least massive trunk congestion (we now use Cisco's storm-control and block (unknown) unicast).
    In any given event the transmitted frames are all the same and appear to be random data from memory. They make no sense as traffic: they have garbage MAC addresses and hence the "unknown unicast traffic storm".
    We have very roughly 100 and about 1% malfunction this way once a week. We don't think it's the MBP behind the display because we switched to Thunderbolt ethernet adapters (directly on the MPBs) and have not seen an incident for over 7 weeks.
    Here is a LogicMonitor record; the trailing edge of the event was when we unplugged the display.
    Here's what a packet capture looks like from the outage:
    Here is trace data from a different event.
    The destination MAC address is an ASCII string that spells out "vertcp". Although Wireshark identifies the frame type as LLC in the first example, we believe this to be a coincidence; it's a random 436-byte piece of firmware memory. A safe conclusion is that both the LLC tag and the completely invalid ethertype in the first event is just random. Nothing in the captured frames makes sense because they aren't ethernet frames, they are random data passed to the driver due to a bug.
    Thanks
    Branden

    We have experienced the same issue with increasing frequency as more Thunderbolt displays are introduced into our environment in the last year.  On a gigabit port, the display has no problem generating 800mbit/s or more of traffic (~500kpps) - which is then flooded to every port in the same VLAN (~400 user ports in our case).  For 100mbit/s users, this essentially floods them off the network.
    Here is a detail I don't see mentioned above -- this happens even when a laptop/computer is not connected to the display.  The first case we had of this happening was with a display that had no thunderbolt parent device attached.  Shutting down the switchport and no-shutting it (bouncing the link on the display) resolves this until the next time it happens.
    It looks like whatever crap resides in various buffers is used to construct the resulting Ethernet frames.  I did not perform a packet capture this time, but the last time it happened the entire Ethernet header was null bytes with the body being mostly-null but the same random-looking noise in the rest of the frame.  The frame was interpreted by Wireshark and others as a type of Fiber Channel, but I think that was just the default case that matched many of the null characteristics.  The exact same frame was reflected in each packet sent (as opposed to each frame being different/randomized from the predecessor)

  • Picking up unicast traffic from a sniffer, but im on a switched network

    I am seeing(not a lot)a conversation from, a node om my vlan talking to another node on a seperate vlan. We have turned off all possible port mirroring/spanning. It was discovered by our CSO and I was able to verify this by running a sniff on my port and I saw the asme traffic.... anyone have any ideas or suggestions... I looked through the packet in Wireshark and did not see that this was a broadcast; although i do see the standard eigrp, cdp etc......

    Your CSO was looking at packets on the wire? Wow...but I digress;-)
    Like srue said, if a switch receives a frame for which it has no entry in the cam table for, it will send it out on all ports. There are attacks that take advantage of this by flooding the switch with ARP replies with different MAC addresses in an attempt to fill the CAM table. I woudn't bet on that being the case here. Here's a link to get your started on some other possible causes:
    http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d0808.shtml

  • Site Link Flooded By DAG Replication Traffic

    Hi everyone,
    I have a quick question regarding DAG replication. We have a DAG that stretches two sites (one site is the primary site and the other site is strictly DR). The WAN link is 150 Mbps, and we have
    encoutered some issues with the network being over-saturated by bursts from the Exchange servers on the replication networks.
    The manager of the Engineering team informed me of this today. Apparently this has been going on for a while, but they just discovered the cause recently. He asked about policing/rate-limiting
    on traffic destined to the IP at the DR site to 100 Mbps. My understanding is that this would cause packets to drop if they go over 100 Mbps.
    Now, I understand how TCP fundamentally works, and that the DAG utilizes TCP (default port 64327), so I would
    like to think this wouldn't be an issue, but I wanted to open a dialog here anyway to see if anyone else has encountered anything like this, and if so, if problems arose.
    As an aside, I am running Exchange 2010 SP2 (yeah, I know...hopefully going to SP3 next month). There are four total mailbox servers (three at the main site and one at the DR site). And yes,
    I have collapsed my DAG networks (MAPI, Replication, Backup).
    Any insight is welcome.
    Thanks in advance!

    Thank you, Jared and Jim. 
    Yes, I figured that at worst my databases at my DR site may simply fall behind a bit, but I don't think it will be by too much, as it doesn't run that high all the time. 
    The manager of the engineering team is scheduling up a change for Tuesday morning to effectively limit the traffic on Tuesday morning.  I'll monitor it for a few days and let you guys know how it is behaving. 
    Thanks again and have a great weekend!

  • Microsoft TermServer NLB unicast flood problem

    I have three Microsoft Terminal Servers in a Network Load Balanced configuration. It appears that MS does their NLB by playing games with the server's MAC addresses, and this appears to be causing issues on my Cat6k, in that all unicast traffic destined for the TSs are flooded out all ports in that same VLAN. It appears this is due to the fact that the CAM table shows a different MAC than is shown by the arp table, so the switch doesn't know where the servers are at (and thus, floods their traffic out all VLAN ports).
    How can I fix this? I'd rather not every single server get flooded with this traffic (even if the do drop it).
    Note the MAC mis-match (02-*01*-0a-05-3c-76 vs 02*bf*.0a05.3c76)
    Router_6506_>sh ip arp | inc 3c76
    Internet 10.5.60.118 140 02bf.0a05.3c76 ARPA Vlan2
    Internet 10.5.60.81 1 02bf.0a05.3c76 ARPA Vlan2
    Internet 10.5.60.80 1 02bf.0a05.3c76 ARPA Vlan2
    Internet 10.5.60.79 0 02bf.0a05.3c76 ARPA Vlan2
    Commons_6506_1 show cam dynamic 4/4
    VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]
    2 02-01-0a-05-3c-76 4/4 [ALL]
    Total Matching CAM Entries Displayed =1
    Commons_6506_1 show cam dynamic 4/6
    VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]
    2 02-03-0a-05-3c-76 4/6 [ALL]
    Total Matching CAM Entries Displayed =1
    Commons_6506_1 show cam dynamic 4/8
    VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type]
    2 02-02-0a-05-3c-76 4/8 [ALL]
    Total Matching CAM Entries Displayed =1

    The 6500 may not be capable of this but in our case (a 3550) I defined the cluster MAC address as a static entry in the MAC address table for each port that was used by the servers in the cluster.
    Here is what a selection from the table might look like where ports 1 and 2 have the clustered servers:
    switch#sh mac-address-table static
    Mac Address Table
    Vlan Mac Address Type Ports
    1 0002.ba3c.cbd2 STATIC Fa0/1 Fa0/2

  • Layer 2 Bridging - Unknown Unicast - ARP or Flood?

    Hi all,
    I'm trying to understand when a layer-2 bridge (switch) would flood an
    unknown unicast frame. My understanding is that whenever a device
    needs to send a unicast frame, it would use ARP before sending, in
    which case the switch would already have the MAC address of the
    destination due to it's ARP reply. This seems that there would never
    be a scenario where the switch would flood a unicast frame out all
    ports. My book lists this as a valid scenario. Am I missing
    something, or is this only possible in situations where ARP isn't
    used? Thanks.

    Hi,
    as Rick said ARP cache timeout is 4 hours while L2 switch MAC address timeout is only 5 minutes by default.
    So it can happen there is the destination MAC missing in the switch forwarding table.
    See
    http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d0808.shtml
    and
    http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00807347ab.shtml#broadcast
    BR,
    Milan

  • Wireshark capture on access port displays different vlan traffic

    Hi Guys,
    i have a nexus 4001i Blade Center Switch where i have a server connected in mode access to a particular vlan.
    when i use wireshark on this port, i see different traffic conversations of different servers in different vlans which seems strange to me.
    anybody have an idea why a server in mode access with wireshark is able to view different vlan traffic? I also see non multicast and non broadcast converations.
    the port the server is connected to is not a monitor port but only in switch port mode access.
    thanks in advance for you feedback

    Hi,
    So it looks like you're getting unicast traffic flooded to all ports. There are a couple of reasons I've come across that can cause this.
    Asymmetric routing: See Unicast Flooding in Switched Campus Networks and/or Case Study #8: Asymmetric Routing and HSRP (Excessive Flooding of Unicast Traffic in Network with Routers That Run HSRP) for details of why it happens and how to prevent it.
    Microsoft Network Load Balancing. As per the Microsoft Troubleshooting NLB:
    In unicast mode (the default Forefront TMG cluster operation mode) NLB induces switch flooding, by design, relaying packets sent to the VIP addresses to all cluster hosts. Switch flooding is part of the NLB strategy for obtaining the best throughput for any specific load of client requests. However, if the NLB interfaces share the switch with other (non-cluster) computers, switch flooding can add to the other computers' network overhead by including them in the flooding and consequently have a detrimental effect on network and/or server performance.
    Regards

  • ASA Transparent mode multicast traffic in 8.2 and 8.4

    Hi,
    When i configure 8.2 in trasparent mode and deploy the a network that was wrok on EIGRP after that i found the neighborship was stop when i allow the mutlicast address and prtocol on outside interface it was start the working But when i deploy an ASA with 8.4 IOS and then allow the multicast address and protocol both the interface (Inside and outside) after that it was start working.
    So i want to know that what the reasion to allow multicast address and protocol on 8.4 IOS for both interface. I am not able to find any answer for this.

    Hi Mahesh,
    By default ASA in transparent mode do not allow any packets not having a valid EtherType greater than or equal to 0x600. As per my knowledge this concept remain same for all versions of ASA. Most control plane protocols are denied.
    ASA in transparent mode only allows ARP, broadcast traffic, TCP and UDP inspected unicast traffic.
    For EIGRP to work through transparent firewall, we need to open ACLs in both direction for multicast and unicast both type of EIGRP traffic on all versions of ASA Firewall.

  • Unknown network traffic / router traffic monitoring

    So I got a new PC with windows 7 on it, and I installed this gadget that monitors network traffic, and it shows a lot of traffic that my local PC isn't showing, so I am thinking there is something running on the LAN that I can't see. I was looking to find a live, better program to monitor the actiontec router, for traffic. anyone know of anything that can maybe show me who is using all the bandwidth on my network?
    i have found software for Linksys, but nothing for the Actiontec.
    Thanks,
    Quasimodem
    Fios in Florida
    Solved!
    Go to Solution.

    Keep in mind that when looking at Wireshark (sniffer) software there are different types of traffic:
    Unicast
    Broadcast
    Multicast
    Unicast is traffic between two devices.  You will see the traffic between the PC with wireshark and another device on your local network such as a printer, another PC or the Router.  You should not see traffic between another PC and the Internet for example.  Using a phone as an example some calls you and the conversation is between you and the person on the other end of the phone.  This is unicast traffic.  Using defaults of the actiontec, IP address seen will be 192.168.1.1 for the router and 192.168.1.2-99 for devices on your network.  If you have the TV service, 192.168.1.100-1xx is used for the cable boxes.
    Broadcast traffic is traffic sent to all devices.  Its not directed toward a particular PC but rather usually looking for information.  In a sniffer trace you will see broadcast traffic. Going back to the phone example, someone makes an announcement on an overhead intercom system that is broadcast traffic.  Broadcast traffic will be seen as 192.168.255.255
    Multicast traffic is traffic from one device for many devices.  Usually used in video feeds.   Using the phone system as an example someone wishes to tell a group of people something so instead of calling each person up and telling them each person who wants the information joins a conference bridge.  Anyone is allowed to listen but only those that wish to get the information receive it.  Generally how multicast works.  Multicast traffic will be seen as IP address 224.x.x.x or something of the sorts where the address will be 2xx.x.x.x.  
    I hope this makes sense.  Probably more information than you needed but at least it will help you understand what wireshark is telling you.

  • Question about WOL (Wake on LAN) Unicast method

    Hi,  We are trying to get WOL working here on our enterprise network using the Unicast method.  It seems that this method depends on the machine you wish to wake having an entry in the router/switch ARP cache.  The problem is that this cache
    times out rather quickly by default and the suggestion was to increase this timeout setting so the entry stays in the cache longer when the device goes offline.  Our WAN guys are saying that is a bad idea and can cause all kinds of issues if we set this
    to say 12-24 hours.  How is everyone else using Unicast WOL dealing with this issue?

    A few corrections and notes:
    - Yes, unicast WoL traffic requires the system to be in the ARP cache of the final layer-3 device. This has nothing to do with WoL though. This is a requirement for *all* unicast traffic. That's simply how ethernet works.
    - Subnet-directed broadcasts aren't less secure. They can however be exploited enabling certain types of DoS attacks most notably the Smurf attack. This can be easily and reliably mitigated as mentioned though.
    - "Both methods require routers to forward UDP packets from your site server." This is a deceptive statement at best. In Unicast, the traffic is transmitted just like all other traffic on the network and requires nothing special on the network
    side and no configuration of any "forwarding". Only with subnet-directed broadcasts is the network required to "forward" traffic.
    - While a consideration, DHCP is usually not a factor with desktops unless you have a ridiculously short lease time. With laptops, same story unless they actually change subnets but then there's nothing you can really do about that. This is why I recommend
    setting the heartbeat to at least once a day if not more often however.
    Finally, do you know about Peer wakeup in 2012 SP1 and R2? Peer wakeup is much more reliable. You generally use unicast with peer wakeup but it overcomes the ARP cache limit.
    Jason | http://blog.configmgrftw.com | @jasonsandys

  • Network analyzer sees all traffic on the switch

    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:Standaardtabel;
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin:0cm;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;
    mso-bidi-font-family:"Times New Roman";
    mso-bidi-theme-font:minor-bidi;}
    A client of us is having a very strange issue. They see a very load (initially just by watching the LEDs en got a software analyzer run on it. Now a software analyzer on a single port, even in promiscuous mode should only get its local data on a single switch port. The switch should only deliver local data to that port (thats why its switch, not a hub yes?) But to our surprise the analyze sees all the traffic, even the traffic that should get on to that specific switch, let a lone that port on the switch. It looks like everything is working like a big hub.
    Hereunder is a screenshot of the installed network analyser:
    v\:* {behavior:url(#default#VML);}
    o\:* {behavior:url(#default#VML);}
    w\:* {behavior:url(#default#VML);}
    .shape {behavior:url(#default#VML);}
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:Standaardtabel;
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin:0cm;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;
    mso-bidi-font-family:"Times New Roman";
    mso-bidi-theme-font:minor-bidi;}
    Can anyone assist in finding where this is going wrong?
    units in use:
    SGE2000-EU
    SRW224G4-EU
    SRW224G4P-EU
    SRW248G4-EU
    Kind Regards

    Hi RONVER-Systems,
    I cannot see the first image, just doesn't want to come up.  Knowing the behavior of a switch I can imagine "broadcast' traffic being received on each port.
    It would be more relavvnt if you could use wireshark (a freeware 'sniffer' program)  and try the same capture again and post the capture file as a .cap file.
    But you obviously will see broadcast traffic arrive at each switch port. The switches will route at Layer 2 any unicast traffic.  But lets check out the capture file you send in again.
    Sorry for this bother, I just can't see the first image you posted.
    regards Dave

  • Allow client to client traffic

    Hi all,
    I have two clients trying to connect to each other with no success.
    I have a 5760 controller and a pretty plain wlan config...
    The only way the managed to Ping one to another is by activating the command:
     peer-blocking forward-upstream
    But I think this throw the traffic to the uplink switch and lets it deal with it... but that will allow unicast traffic, but nothing else.
    Any idea?
    Naor.

    HI Naor,
    The peer-blocking forward-upstream Causes the packets to be forwarded on the upstream VLAN. The device above the controller decides what action to take regarding the packets.
    Peer-to-peer blocking is applied to individual WLANs, and each client inherits the peer-to-peer blocking
    setting of the WLAN to which it is associated. Peer-to-Peer enables you to have more control over how traffic
    is directed. For example, you can choose to have traffic bridged locally within the controller, dropped by the
    controller, or forwarded to the upstream VLAN.
    NOTE:
    To enable peer-to-peer blocking on a WLAN configured for FlexConnect local switching, select Drop
    From the P2P Blocking drop-down list and select the FlexConnect Local Switching check box.
    Please do go through the link below to understand the Peer to Peer blocking behaviour.
    http://www.cisco.com/c/en/us/td/docs/wireless/controller/7-5/config_guide/b_cg75/b_cg75_chapter_01001011.pdf
    Regards
    Salma

  • Howto block p2p traffic of clients connected to the same ssid on different wlc

    Hi all,
    I use two wlc 4400 (4.2.x version) with a mobility domain and one ssid, both wlc are connected to a cisco l2 switch infrastructure. On the wlc I use the p2p blocking action 'drop' (http://www.cisco.com/en/US/docs/wireless/controller/5.2/configuration/guide/c52wlan.html#wp1209597) to isolate the clients from each other. Does anybody know if only unicast traffic is blocked or also multicast and broadcast traffic like arp requests?
    Concerning blocking p2p traffic of clients connected to the same ssid but different controllers I found the following statement in the LAP FAQs (http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00806a4da3.shtml):
    ===
    Q. In autonomous APs, Public Secure Packet Forwarding (PSPF) is used to avoid client devices associated to this AP from inadvertently sharing files with other client devices on the wireless network. Is there any equivalent feature in Lightweight APs?
    A. The feature or the mode that performs the similar function of PSPF in lightweight architecture is called peer-to-peer blocking mode. Peer-to-peer blocking mode is actually available with the controllers that manage the LAP. If this mode is disabled on the controller (which is the default setting), it allows the wireless clients to communicate with each other through the controller. If the mode is enabled, it blocks the communication between clients through the controller. It only works among the APs that have joined to the same controller. When enabled, this mode does not block wireless clients terminated on one controller from the ability to get to wireless clients terminated on a different controller, even in the same mobility group.
    ===
    Does anybody know what's the best practise to prevent this inter wlc client traffic? I already read about using acls on the wlc dynamic interfaces, or private vlans on the l2 switch vlans where the dynamic interfaces are connected to. Is it allowed to completely isolate the wlc from each other on these dynamic interfaces with acls or private vlans or do the wlc need to see each other on this interfaces (e.g. heart beat)?
    Many thanks in advance,
    Thorsten

    Hi Sasha,Thorsten
    The bug is Junked and I believe which is what you are running into with your tests:
    CSCtr60787    WLC P2P Blocking Set to Forward-UpStream Doesn't Work.
    Bugtoolkit : http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs
    To answer your original query :
    ACL is only solution to block client communication on same ssid between 2 wlcs. 5508 works better with ACLs then 44xx platform.
    ARP requests will be forwarded to upstream router just like any other traffic. WLC won't proxy arp for clients on same vlan.
    Gateway arp's I believe should be handled by WLC . ( Don't quote me on this but I am pretty sure it is ) ..If it was not, then how would client know about gw ?
    Multicast traffic is not applicable for p2p.
    Your ACL can be as simple as this for the scenario :
    WLC 1 - clientvlan = 10
    WLC 2 - clientvlan = 10
    and you want to restrict users from wlc1-wlc1, wlc1-wlc2, wlc2-wlc2 for same vlan10.
    Basically in that case the ACL should look like on both WLCs :
    1. Permit statement to talk to gateway.
    2. Deny to subnet.
    3. Permit all.
    4. If DHCP/DNS other services are on same subnet then you would need to add a permit
    statement before the deny.
    5. Attach the ACL to SSID or dymanic interface.
    Thanks..Salil
    CSCtr60787    WLC P2P Blocking Set to Forward-UpStream Doesn't Work.

  • Arp entries becoming zero

    Hi,
    We have Sun 1280 servers running in our lab. We observe that sometime arp entries for some interfaces become zero suddenly.
    Here is the warning we observe in /var/adm/messages :-
    09:53:50 ca-a ip: [ID 903730 kern.warning] WARNING: IP: Hardware address '00:00:00:00:00:00' trying to be our address 024.094.103.069!
    14:32:17 ca-a ip: [ID 903730 kern.warning] WARNING: IP: Hardware address '08:00:20:ad:37:18' trying to be our address 024.094.103.068!
    Any help ?
    Thanks
    Akhil Jain

    Hello,
    the default ARP timeout on the MSFC is 14400 seconds, or 4 hours. The CAM (MAC address table) default timeout is 300 seconds.
    You actually might want to set the CAM agingtime to 4 hours as well, in order to avoid possible IP unicast traffic flooding...
    HTH,
    GP

  • Aironet 1142 as supplicant to 2960 switch (NEAT/CISP/MAB)

    Hello!
    First, my configuration, (then the problem down below):
    I have an Aironet 1142 with mulitple SSIDs [mapped to VLANs] connected to Gi1/0/2 on a 2960 switch in a user-accessible area.  This switch is uplinked to another 2960 switch in a wiring closet, and the Microsoft NPS server is connected to the wiring closet 2960.
    Aironet -- 2960 [user area] --- 2960 [closet] -- NPS RADIUS
    I have the user-area 2960 configured as an authenticator switch for dot1x, and port Gi1/0/2 is authenticating the Aironet via MAB to RADIUS.  RADIUS is sending VSA device-traffic-class=switch to the 2960.  The closet-2960 has no special 802.1x configuration, nor is it an authenticator swtich; it just has a manually-configured trunk port to the user-area 2960 [for now; i'm trying to take this one step at a time!].
    The user-area 2960 correctly converts port Gi1/0/1 to a trunk port when the Aironet is authenticated [via MAB].  The Aironet boots up, the port is opened, I can ping the Aironet on the native VLAN, and all is well [so it seems].  The Aironet's dot11Radio is configured for two SSIDs and mapped to VLANs, which are being spanned via STP thru the user-area 2960 and the closet-2960.  STP is correct and verified on all switches.
    I have DHCP snooping configured on the user-area 2960 but only for VLAN 1 [but NOT the wireless user VLANs], the trunk port to the closet 2960 is a trusted port.  Hosts on the wired ports on the user-area 2960 are able to get DHCP IPs.  On the Aironet, "show dot11 associations" shows hosts on the SSIDs are getting DHCP addresses.  Again, I am *NOT* running dhcp snooping on wireless SSID VLANs [i read elsewhere that can cause problems as users roam between Aironets].
    I do have CISP configured on the user-area 2960.  I do not have CISP configured on the closet-2960 [best I can tell, that's not required at this stage, but I could be wrong].
    Despite the alleged documentation, I could not get the Aironet to use a dot1x credentials profile to authenticate to NPS/RADIUS as an 802.1x supplicant, which is why I resorted to MAB for this exercise.  The Aironet simply would not run dot1x [best I could tell].  The documentation and configuration didn't seem complex, so I was quite confused.
    I have upgraded the Aironet to the latest 12.4(25d)JA2 software, and the 2960 is at 12.2(55)SE7 [i saw 12.2(58) has some issues, but i'm willing to be persuaded otherwise, based on sound advice].
    Ok, now the problem:  
    Users on the guest wireless SSID (Vlan 20) say they cannot connect.  Yep, classic.  VLAN 20 is trunked and spanned to all the sufficient places.  The Aironet shows users in the associations list for that SSID with IP addresses from the DHCP server!  DHCP snooping is not configured on that VLAN. 
    I read another support forum post saying CISP and MAB could cause problems with "disappearing" ARP entries.  I appear to have that problem.  However, the user on the Staff wireless (VLAN 10) has full access.  Am I running into a problem with "multi-host" authentication config?  Via tcpdump on my firewall, I see nothing but broadcast and multicast traffic coming from a host on VLAN 20.  What puzzles me is how I do see *SOME* traffic from a VLAN 20 host on this SSID, but no unicast traffic! Argh!
    Since you're going to ask, here is my port config for this AP on the 2960 authenticator switch in the user-area, and the AAA config pieces:
    #sh run br | in ip dhcp          
    ip dhcp snooping vlan 1
    no ip dhcp snooping information option
    ip dhcp snooping database flash:dhcp_snoop.txt
    ip dhcp snooping
    #sh ip dhcp snoop
    Switch DHCP snooping is enabled
    DHCP snooping is configured on following VLANs:
    1
    DHCP snooping is operational on following VLANs:
    1
    DHCP snooping is configured on the following L3 Interfaces:
    Insertion of option 82 is disabled
       circuit-id default format: vlan-mod-port
       remote-id: ccd5.3947.7980 (MAC)
    Option 82 on untrusted port is not allowed
    Verification of hwaddr field is enabled
    Verification of giaddr field is enabled
    DHCP snooping trust/rate is configured on the following Interfaces:
    Interface                  Trusted    Allow option    Rate limit (pps)
    GigabitEthernet1/0/46      no         no              15       
      Custom circuit-ids:
    GigabitEthernet1/0/48      yes        yes             unlimited
      Custom circuit-ids:
    GigabitEthernet1/0/52      yes        yes             unlimited
      Custom circuit-ids:
    #sh run br | incl aaa auth
    aaa authentication login default local group rad_eap
    aaa authentication dot1x default group radius
    aaa authorization console
    aaa authorization exec default local group rad_eap
    aaa authorization network default group rad_eap local
    #sh run int gi1/0/2
    interface GigabitEthernet1/0/2
    description Wireless Access Points
    switchport mode trunk
    switchport nonegotiate
    srr-queue bandwidth share 1 30 35 5
    srr-queue bandwidth limit 50
    priority-queue out
    authentication host-mode multi-host
    authentication order mab dot1x
    authentication port-control auto
    authentication violation restrict
    mab
    mls qos trust cos
    macro description CISCO_WIRELESS_AP_EVENT
    auto qos trust
    spanning-tree portfast
    #sh int gi1/0/2 sw
    Name: Gi1/0/2
    Switchport: Enabled
    Administrative Mode: trunk
    Operational Mode: trunk
    Administrative Trunking Encapsulation: dot1q
    Operational Trunking Encapsulation: dot1q
    Negotiation of Trunking: Off
    Access Mode VLAN: 1 (default)
    Trunking Native Mode VLAN: 1 (default)
    Administrative Native VLAN tagging: enabled
    Voice VLAN: none
    Administrative private-vlan host-association: none
    Administrative private-vlan mapping: none
    Administrative private-vlan trunk native VLAN: none
    Administrative private-vlan trunk Native VLAN tagging: enabled
    Administrative private-vlan trunk encapsulation: dot1q
    Administrative private-vlan trunk normal VLANs: none
    Administrative private-vlan trunk associations: none
    Administrative private-vlan trunk mappings: none
    Operational private-vlan: none
    Trunking VLANs Enabled: ALL
    Pruning VLANs Enabled: 2-1001
    Capture Mode Disabled
    Capture VLANs Allowed: ALL
    Protected: false
    Unknown unicast blocked: disabled
    Unknown multicast blocked: disabled
    Appliance trust: none
    #sh auth sess int gi1/0/2
                Interface:  GigabitEthernet1/0/2
              MAC Address:  acf2.c5f2.8e27
               IP Address:  10.100.32.42
                User-Name:  acf2c5f28e27
                   Status:  Authz Success
                   Domain:  DATA
           Oper host mode:  multi-host
         Oper control dir:  both
            Authorized By:  Authentication Server
               Vlan Group:  N/A
          Session timeout:  N/A
             Idle timeout:  N/A
        Common Session ID:  0A64200B00000CDA41AFBEDF
          Acct Session ID:  0x00000D00
                   Handle:  0xDE000CDA
    Runnable methods list:
           Method   State
           mab      Authc Success
           dot1x    Not run
    #sh mab int gi1/0/2
    MAB details for GigabitEthernet1/0/2
    Mac-Auth-Bypass           = Enabled
    #sh int trunk
    Port        Mode             Encapsulation  Status        Native vlan
    Gi1/0/1     on               802.1q         trunking      1
    Gi1/0/2     on               802.1q         trunking      1
    Gi1/0/48    on               802.1q         trunking      1
    Gi1/0/52    on               802.1q         trunking      1
    Port        Vlans allowed on trunk
    Gi1/0/1     1-4094
    Gi1/0/2     1-4094
    Gi1/0/48    1-2,10,20
    Gi1/0/52    1-2,10,20
    Port        Vlans allowed and active in management domain
    Gi1/0/1     1-2,10,20
    Gi1/0/2     1-2,10,20
    Gi1/0/48    1-2,10,20
    Gi1/0/52    1-2,10,20
    Port        Vlans in spanning tree forwarding state and not pruned
    Gi1/0/1     1-2,10,20
    Gi1/0/2     1-2,10,20
    Gi1/0/48    2
    Gi1/0/52    1-2,10,20
    Ok, what am I missing??

    The problem lies in the wired Ethernet port on the Aironet.  I did not submit that configuration because I thought it was simple and unrelated.  Here is what I had:
    interface GigabitEthernet0.20
    encapsulation dot1Q 20
    no ip route-cache
    bridge-group 20
    no bridge-group 20 source-learning
    no bridge-group 20 unicast-flooding
    bridge-group 20 spanning-disabled
    The correct configuration should have been:
    interface GigabitEthernet0.20
    encapsulation dot1Q 20
    no ip route-cache
    bridge-group 20
    no bridge-group 20 source-learning
    bridge-group 20 spanning-disabled
    The line "no bridge-group 20 unicast-flooding" should not be applied to the wired port.  That's stupid.   With that erroneous command, the wired port will forward only broadcast and multicast traffic!  Unicast traffic will be dropped.  Oops.
    However, I do not understand why applying this to the radio interfaces has no effect there.  I have yet to find any conclusive detailed answers, either.  Regardless, my original problem is fixed.

Maybe you are looking for