Showing results for 
Search instead for 
Did you mean: 

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.


A/V Products Crestron - Biamps with Closed Mode - ISE

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
 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





Octavian Szolga

Hi Rob,


Long story short, it would help to either add authentication control-direction in command at switchport level or remove the authentication timer inactivity 60 command.


This first command will basically tell your switch that any traffic coming from the network to the endpoint is allowed even though the switchport is not authenticated. The ingress switchport traffic (coming from the endpoint) will be dropped if not authenticated.


The behaviour you've noticed is usually found in case of printers. If nobody is printing, the session expires. (if it has a reauthenticate timer) The session would not come up because the printer does not wishes to talk to anybody, so it does not generate any traffic. No traffic = no authentication.


By using this command you guarantee that the endpoint is kept alive by anyone wishing to communicate with it and thus the traffic will keeping the switchport authentication up so to speak ;)


Please test it and let me know if it works.



Thank you Octavian for the suggestion.


I will certainly try this and report back in a week's time.


Thanks again!


Content for Community-Ad