I'm trying to figure out exactly what is preventing a quiet device using MAB port-control from seeing either ARPs or flooded unicasts after its authentication goes stale.
The port configuration is as follows:
switchport access vlan XXX
switchport mode access
switchport port-security maximum 16
switchport port-security aging time 240
switchport port-security violation restrict
switchport port-security aging type inactivity
ip arp inspection trust
ip arp inspection limit rate 100
authentication control-direction in
authentication event fail action authorize vlan YYY
authentication event server dead action authorize vlan XXX
authentication event no-response action authorize vlan XXX
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication order mab
authentication priority mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate 600
authentication timer inactivity 600
authentication violation restrict
no lldp transmit
no lldp receive
no cdp enable
spanning-tree portfast
spanning-tree bpduguard enable
ip dhcp snooping limit rate 50
Note that I've turned off port security, and also turned off the block-unicast feature for good measure (which needs to be done anyway with quiet devices). Also note that I already have "authentication control-direction in" applied and I've applied "ip arp inspection trust." Also there's no "ip verify source". That SHOULD eliminate every feature that would prevent unicast flooding or swat down ARPs or whatnot.
VLANs are assigned by the AAA server, and it is up and working, but even so, there's an authorize action in there for all the AAA failure modes IIRC.
Apparently I am missing something, as the device cannot be pinged after the port-access session/inactivity timeouts occur. Dumping on the host, I do not see any of the normal broadcasts, only loop detection packets.
Digging deeper I see this:
# show spanning-tree interface fa0/32
no spanning tree info available for FastEthernet0/32
So my working theory is that since the switch is not nomilnally putting the port into any VLANs until after auth, spanning tree won't flood or broadcast to it. Since the "control-direction in" command is more or less specifically aimed at this situation (WoL or quiet devices) this is a bit surprising, and I'm guessing it's peculiar to the "host-mode multi-auth" which is still a bit dicey. The switch is running 12.2(55)SE1.
Any more educated guesses? Anyone have a fix, other than just turning off MAB for such devices?
