Good morning experts,
It has reached the point where I have to vent my frustration on the support forums :)
Alright, to make a long story short we have recently deployed a closed mode policy throughout our enterprise. We have a lot of A/V products such as Crestron Scheduling Panels, and Biamps touch panel devices. After moving towards a closed mode environment a handful of these devices either loose their layer 2 address or IP address.
So for example when I try to find authentication sessions within the switch I come up empty handed:
Switch1#sho auth sess int gi7/40
No sessions match supplied criteria.
Runnable methods list:
Handle Priority Name
17 5 dot1x
18 10 mab
21 15 webauth
When I look at the interface status we can clearly see the device is connected:
Switch1#sho int gi7/40
GigabitEthernet7/40 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet Port, address is 54a2.7479.76ef (bia 54a2.7479.76ef)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, link type is auto, media type is 10/100/1000-TX
input flow-control is off, output flow-control is off
Auto-MDIX on (operational: on)
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output never, output hang never
Last clearing of "show interface" counters 4d17h
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
21229 packets output, 9578713 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
At this point I have to bounce the interface in order for the authentication to re-initialize at which I'm able to see a authentication session.
So my question is why do we have to bounce the port to initialize an authentication session? This is starting to become problematic as we have to bounce the ports to get these devices back online. Do we know why this is an issue? This was never an issue when our environment was within a low impact/monitor mode environment. This only started to rear it head when we moved our NADs into a closed mode policy.
I will provide our port config for further analysis.
Switch1#sho run int gi7/40
Building configuration...
Current configuration : 874 bytes
!
interface GigabitEthernet7/43
switchport access vlan 144
switchport mode access
switchport voice vlan 143
ip access-group ACL-ALLOW in
no logging event link-status
authentication event fail action next-method
authentication event server dead action authorize vlan 43
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication order mab dot1x
authentication priority dot1x mab webauth
authentication port-control auto
authentication timer inactivity 60
authentication violation restrict
mab
snmp trap mac-notification change added
no snmp trap link-status
auto qos trust
dot1x pae authenticator
service-policy input AutoQos-4.0-Input-Policy
service-policy output AutoQos-4.0-Output-Policy
ip dhcp snooping information option allow-untrusted
end
Thanks,
-Robert
