03-27-2018 08:03 PM - edited 03-08-2019 02:25 PM
Hi,
We currently have a port configured for dot1x authentication ( dynamic VLAN assignment and multidomain mode )
interface GigabitEthernet2/0/4
switchport access vlan 168
switchport mode access
switchport voice vlan 600
no logging event link-status
srr-queue bandwidth share 1 30 30 30
priority-queue out
authentication host-mode multi-domain
authentication open
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation replace
no snmp trap link-status
dot1x pae authenticator
dot1x timeout tx-period 5
dot1x timeout supp-timeout 5
spanning-tree portfast
end
Our setup is that there are 2 devices connected to the port ( 1 avaya IP phone and a windows laptop ).
This means that both the avaya phone and the windows laptop should authenticate towards using dot1x, but if they fail the authentication the switch will still pass the traffic due to the command "authentication port-control auto".
We are getting reports from the end user that their network connectivity is being intermittent and i would just want to verify whether if if it would be related to our dot1x port configurations. Ive attached a log file on the switch where both clients are connected
24d9.214b.0418 --> AVAYA DEVICE
ecb1.d733.8742 --> LAPTOP DEVICE
Im suspecting that its the avaya device failing to authenticate and removes the MAC address entry for the laptop on the device. Im seeing on the "show dot1x interface GigabitEthernet2/0/4 details", its flaps between AUTHENTICATED (for the laptop)/AUTHENTICATING ( for the avaya) going to no output in the Dot1x Authenticator client list.
Checking the MAC address table on the g2/0/4, im seeing that sometimes the both the STATIC MAC ADDRESS of the laptop ( due to the dynamic VLAN assignment ) and the DYNAMIC MAC of the Avaya is there, but once I get the AUTHMGR-5-SECURITY_VIOLATION and AUTHMGR-5-MACREPLACE, the MAC addresse are removed and re-added making the connection intermittent.
Any inputs regarding this?
regards,
Jon
Solved! Go to Solution.
03-27-2018 09:36 PM
Yes because avaya is doing a request in the data domain.
03-27-2018 09:01 PM
Hi
The command authentication port-control auto isn't for fall authentication bypass. It basically starts authentication when the port guess from down to up.
You have the command authentication event fail actionauthorize vlan xx to assign a vlan if your authentication fails.
Anyway, based on your logs, a mac address is already authenticated and when the second one come, you have a violation because it allows only 1 mac port domain.
To solve this issue, you need to make sure that you're replying with your authorization this device belongs to voice domain. You can also activate lldp and make sure this device authenticates in the voice domain.
Hope this is clear otherwise let me know.
03-27-2018 09:21 PM
"
The command authentication port-control auto isn't for fall authentication bypass. It basically starts authentication when the port guess from down to up.
You have the command authentication event fail actionauthorize vlan xx to assign a vlan if your authentication fails."
Pardon for the error in my query, its the "authentication open" command i was referring to as the fallback.
Is it because the Avaya phone doesnt negotiate the voice vlan that is why its seen as a security violation and is seen as part of the access vlan?
03-27-2018 09:36 PM
Yes because avaya is doing a request in the data domain.
03-27-2018 10:04 PM
Thanks for that info Francesco.
I was just wondering how does 802.1x distinguish whether im making the request in the data domain vs. the voice domain?
regards,
Jon
03-28-2018 06:48 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide