Network Login 802.1x with Mitel phone 6865i and X440 fails because of a link down


Environment : EXOS X440-48P version 15.6.3.1 patch 1-5, X150-24t version 12.6.5.2,
Mitel phones Mitel 6865i version 4.0.0.2031, FreeRADIUS, DHCP server
LLDP is not configured on the switches and the phones VLAN is dynamicaly created on the switches after the phones are authenticated

As you can see below,the proccess is succesfull with X150-24t
08:24:38.44 [i] Network Login 802.1x user AuthUser logged in MAC XX:XX:XX:XX:XX:XX port 15 VLAN(s) "V_VOICE", authentication Radius
08:24:37.83 [i] port 15 link UP at speed 100 Mbps and full-duplex
08:24:36.18 [i] Network Login user AuthUser cleared due to link down event, Mac XX:XX:XX:XX:XX:XX port 15 VLAN(s) "V_VOICE"
08:24:36.18 [i] port 15 link down
08:24:32.55 [i] Network Login 802.1x user AuthUser logged in MAC XX:XX:XX:XX:XX:XX port 15 VLAN(s) "V_VOICE", authentication Radius
08:24:03.64 [i] port 15 link UP at speed 100 Mbps and full-duplex
08:23:25.44 [i] Port 24 link UP at speed 100 Mbps and full-duplex
08:23:08.62 [i] port 15 link down
08:23:08.56 [i] port 15 link UP at speed 100 Mbps and full-duplex


With X440-48P,the proccess failed after the link down


09:15:11.01 [i] port 15 link UP at speed 1 Gbps and full-duplex
09:15:08.18 [i] Network Login user AuthUser cleared due to link down event, Mac XX:XX:XX:XX:XX:XX port 15 VLAN(s) "V_VOICE"
09:15:08.17 [i] port 15 link down
09:15:02.92 [i] Network Login 802.1x user AuthUser logged in MAC XX:XX:XX:XX:XX:XX port 15 VLAN(s) "V_VOICE", authentication Radius
09:14:36.76 [i] port 15 link UP at speed 1 Gbps and full-duplex
09:14:36.45 port 15 is delivering power

Can you help in finding an issue for X440, many thanks.

ColoCopa

20 replies

Userlevel 6
Does the link go down because the phone is rebooting to send tagged traffic in VLAN v-voice?

Also i would check the netlogin detail configuration to make sure they are configured the same. "show conf netlogin detail"
Stephen Williams wrote:

Does the link go down because the phone is rebooting to send tagged traffic in VLAN v-voice?

Also i would check the netlogin detail configuration to make sure they are configured the same. "show conf netlogin detail"

The link goes down but the phone never reboots. After the Network Login user AuthUser cleared due to link down, the phone makes a router solicitation an goes to an endless DHCP discover.

Here are the netlogin details

For X440
NetLogin Authentication Mode : web-based DISABLED; 802.1x ENABLED; mac-based DISABLED
NetLogin VLAN : "auth_dot1x"
NetLogin move-fail-action : Deny

------------------------------------------------
802.1x Mode Global Configuration
------------------------------------------------
Quiet Period : 60
Supplicant Response Timeout : 30
Re-authentication period : 7200
Max Re-authentications : 3
RADIUS server timeout : 30
EAPOL MPDU version to transmit : v1
------------------------------------------------

For X150
NetLogin Authentication Mode : web-based DISABLED; 802.1x ENABLED; mac-based DISABLED
NetLogin VLAN : "auth_dot1x"
NetLogin move-fail-action : Deny

------------------------------------------------
802.1x Mode Global Configuration
------------------------------------------------
Quiet Period : 60
Supplicant Response Timeout : 30
Re-authentication period : 7200
Max Re-authentications : 3
RADIUS server timeout : 30
EAPOL MPDU version to transmit : v1
------------------------------------------------
Stephen Williams wrote:

Does the link go down because the phone is rebooting to send tagged traffic in VLAN v-voice?

Also i would check the netlogin detail configuration to make sure they are configured the same. "show conf netlogin detail"

In addition,the VLAN V_VOICE is configured on the phone in a separate operation. The phone is connected to a switch that doesn't run 802.1X and obtains for the first time its config files from a FTP server after a DHCP proccess.
Userlevel 4
You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

After the link comes up again, the phone never sends an EAPoL start to the switch. He goes to an endless DHCP discover. During the DHCP discover,if we manualy configure the VLAN V_VOICE on the port,the phone reauthenticates.

With a PC connected to the phone PC port, the authentication proccess is total success.
Userlevel 6
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

The phone will need to send a EAPoL start when using 802.1x. MAC authentication does not require a EAPoL
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

I understand what you mean but the authentication has been already achieved. It should be a reauthentication proccess, isn'it?.
And how do you explain that the authentication proccess is ok with the X150-24t version 12.6.5.2?

In addition, when the IP phone port speed and duplex are configured manually, not auto, the authentication proccess is also ok.

Here the WireShark capture with X440
No. Time Source Destination Protocol Length Info
1 0.000000000 :: xxxx::xx ICMPv6 90 Multicast Listener Report Message v2

No. Time Source Destination Protocol Length Info
2 0.002075260 ExtremeN_yy:yy:yy Aastra_zz:zz:zz EAP 68 Request, Identity

No. Time Source Destination Protocol Length Info
3 0.950009584 :: ftgjk :❌fgrt:ghj ICMPv6 78 Neighbor Solicitation for tgjk::111:4ghf:fgrt:ghj

No. Time Source Destination Protocol Length Info
4 1.950093743 tgjk::111:4ghf:fgrt:ghj ff02::2 ICMPv6 70 Router Solicitation from 00:08:5d:zz:zz:zz

No. Time Source Destination Protocol Length Info
5 3.789886559 tgjk::111:4ghf:fgrt:ghj xxxx::xx ICMPv6 90 Multicast Listener Report Message v2
No. Time Source Destination Protocol Length Info
6 3.899921795 Aastra_zz:zz:zz Nearest EAPOL 60 Start

No. Time Source Destination Protocol Length Info
7 3.901700309 ExtremeN_yy:yy:yy Aastra_zz:zz:zz EAP 68 Request, Identity

No. Time Source Destination Protocol Length Info
8 3.902416051 Aastra_zz:zz:zz Nearest EAP 60 Response, Identity

No. Time Source Destination Protocol Length Info
9 3.907678245 ExtremeN_yy:yy:yy Aastra_zz:zz:zz EAP 68 Request, MD5-Challenge EAP (EAP-MD5-CHALLENGE)

No. Time Source Destination Protocol Length Info
10 3.908039760 Aastra_zz:zz:zz Nearest EAP 60 Response, MD5-Challenge EAP (EAP-MD5-CHALLENGE)

No. Time Source Destination Protocol Length Info
11 3.941875391 ExtremeN_yy:yy:yy LLDP_Multicast LLDP 149 TTL = 120 System Description = ExtremeXOS (X440-48p) version 15.6.3.1 v1563b1-patch1-5 by release-manager on Sun Aug 16 21:34:14 EDT 2015

No. Time Source Destination Protocol Length Info
12 4.290546788 ab.cde.fg.h 224.0.0.vv VRRP 64 Announcement (v2)

No. Time Source Destination Protocol Length Info
13 4.919453599 ExtremeN_yy:yy:yy Aastra_zz:zz:zz EAP 68 Success

No. Time Source Destination Protocol Length Info
14 5.295021036 ab.cde.fg.h 224.0.0.vv VRRP 64 Announcement (v2)

No. Time Source Destination Protocol Length Info
15 5.681214681 ExtremeN_ss🇸🇸ss Broadcast ARP 64 Who has dd.ddd.dd.dd? Tell bc.ddd.ef.gh

No. Time Source Destination Protocol Length Info
16 5.949882530 tgjk::111:4ghf:fgrt:ghj ff02::2 ICMPv6 70 Router Solicitation from 00:08:5d:zz:zz:zz

No. Time Source Destination Protocol Length Info
17 6.299168015 ab.cde.fg.h 224.0.0.vv VRRP 64 Announcement (v2)

No. Time Source Destination Protocol Length Info
18 7.294583006 ab.cde.fg.h 224.0.0.vv VRRP 64 Announcement (v2)

No. Time Source Destination Protocol Length Info
19 8.296729428 ab.cde.fg.h 224.0.0.vv VRRP 64 Announcement (v2)

No. Time Source Destination Protocol Length Info
20 9.300649111 ab.cde.fg.h 224.0.0.vv VRRP 64 Announcement (v2)

No. Time Source Destination Protocol Length Info
21 15.489773934 0.0.0.0 255.255.255.255 DHCP 594 DHCP Discover - Transaction ID 0x68151121

No. Time Source Destination Protocol Length Info
22 21.549736078 0.0.0.0 255.255.255.255 DHCP 594 DHCP Discover - Transaction ID 0x68151121

No. Time Source Destination Protocol Length Info
23 27.609772208 0.0.0.0 255.255.255.255 DHCP 594 DHCP Discover - Transaction ID 0x68151121

No. Time Source Destination Protocol Length Info
24 33.669728308 0.0.0.0 255.255.255.255 DHCP 594 DHCP Discover - Transaction ID 0x68151121
Userlevel 6
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

The configuration looks the same from what you sent me but the default configuration not shown in this output could be different. Check both switches "show config netlogin detail" and let me know what's different.

Does the link still go down after the first authentication when the phones port speed are configured manually?

I would like to see what the x150 capture looks like.
Userlevel 4
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

No. Time Source Destination Protocol Length Info
13 4.919453599 ExtremeN_yy:yy:yy Aastra_zz:zz:zz EAP 68 Success

In the above packet trace, X440 sent the EAP authentication success packet to the phone. Is this captured when you see a problem?
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

Yes, after the success the link down comes, the switch clears the netlogin user, the phone goes to a DHCP discover, the link becomes up.
Userlevel 4
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

If the EAP success packet is part of authentication process before the link goes down, it appears that an EAPoL start packet was not received on the switch after the link bounced. I don't know what would make a difference between two switches but the switch should receive an EAPoL start packet to initiate the authentication process. You may need to check if the phone sends an EAPoL start after the link bounces. Since you don't see the same problem with manual link setting, it could be related to auto negotiation. But, no known issue that I know of.
Userlevel 6
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

If EXOS 12.6.5.2 authenticates without a EAPoL start then 12.6.5.2 would not be working per RFC.
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

Each time and whatever the case, the IP phone sends an EAPOL start but once and at the begining (time 5 for 6865i and time 3 fore 6753i) as you can see in the captures bellow.
In case of success, the phone sends a DHCP request and starts to download its configuration files.
But with automatic link setting, the IP phone 6865i can't join the DHCP server because of the network ogin user AuthUser cleared due to link down event.
On the other hand, the link never goes down with manual link setting.

Here the "show config netlogin detail" for both switches
Userlevel 4
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

I hope I understand the problem correctly. When a link bounces, it's the expected behavior that a switch clears the existing authentication state and waits for a new EAPoL start packet to reauthenticate from a supplicant. If you see an unexpected link bounce occur on an auto-nogotiated port and somehow the ip phone not send EAPoL start packets to the switch at this point, I would turn off auto-negotiation on a port to prevent an unexpected link bounce. Or, I would fix the port speed to a desired one along with auto-negotiation.

# configure ports 5 auto on speed 1000 duplex full
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

Yes you understand the problem correctly.
However, with auto-negotiation turn off or the port speed fixed, a link bounce occures and the switch clears the existing authentication state.

The link never bounces when both swicth port and phone port are manually set or only the phone port is manually set.
Userlevel 4
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

It sounds to me like the phone itself bounces the link since the problem appears to happen even when the auto-negotiation is off only in the switch side.
Userlevel 6
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

Kevin, I agree. I think the EXOS 12.6 behavior is wrong but it prevented you from seeing this issue.
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

We finaly discover the main problem of this :

We have netlogin 802.1x and dynamic vlan assignment.
We assigned tagged vlan with the FreeRadius dictionnary Extreme-Netlogin-Extended-Vlan = Tvoicevlan.

When a packet with tagged 802.1q arrived on a port without the same 802.1q tagged open on the port, is dropped directly without sending the packet to the 802.1x process (which normaly open this tagged port).
If the switch port is open with the tagged vlan (conf vlan voicevlan add port tagged), when a packet arrived on port, the 802.1q process validate the packet and pass to the second process 802.1x which send a EAP Request Identity.

To resume, the 802.1q validation process is before the 802.1x validation process.
If the 802.1x validation process is before 802.1q validation process, we will not have any issue, because the 802.1x process will open the good 802.1q tagged port...

This can be simulate with two Extreme Network switch. One trying to "speak" with tagged packet on a port of the second switch, without the tag on the port. Never the second switch will send the EAP request identity.
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

I agree. But this is the result when the switch port bounces. The question is, why the switch port bounces when the IP phone port is set to auto-negociation.
Is it because in auto-negociation mode, the maximum speed is 100 Mbps for the switch port 10/100/1000 Mbps ? Is it because of the IP phone ?
Userlevel 4
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

It appears that the IP phone somehow drops the link on a tri-speed auto-nego port based on the fact that a link bounce occurs as long as the iphone port has auto-nego turned on. (while a switch port has auto-nego off.)
Userlevel 4
Kevin Kim wrote:

You could also verify if the IP phone sends an EAPoL start to the switch after the link comes up again by checking the log counter, configuring additional log event, or mirrorring EAPOL packets on the port to the IP phone.

show log counters "nl.dot1x.eapolPktRcvd"

enable log debug-mode
configure log filter "DefaultFilter" add events "nl.dot1x.eapolPktRcvd"

It appears that the IP phone somehow drops the link on a tri-speed auto-nego port based on the fact that a link bounce occurs as long as the iphone port has auto-nego turned on. (while a switch port has auto-nego off.)

Reply