Port-Security and Ip Phone : Strange Behavior = BUG ?

Unanswered Question
Dec 14th, 2009

Hi all,

I found a strange behavior between the port-security feature and the voice vlan. I don't know if it is a bug or a protection feature because I didn't find anything about that on this forum (and on the config guide). We encountered a problem during an update of the phones and it comes frome the port-security features (+ the switchport voice vlan ???).

We have an Alcatel-Lucent IP phone infrastructure implemented on a full cisco network infrastructure (Cat6500 + Cat4500 + Cat3750). We configured the interfaces like this :

interface FastEthernet1/0/1
switchport access vlan 20
switchport mode access
switchport nonegotiate
switchport voice vlan 8
switchport port-security maximum 50
switchport port-security
switchport port-security aging time 1
switchport port-security violation restrict
switchport port-security aging type inactivity

spanning-tree portfast
end

When the phone reboots, it follows these nomal steps (ATTENTION : the interface never becomes shutdown --> the mac table isn't cleared) :

1) first boot in the access vlan and DHCPDISCOVER

2) it gets an IP in the access network + the indication to reboot in the voice vlan (the vlan 8)

3) the phone reboots in the voice vlan and gets its voice IP.

4) phone in function.

As I said, the interface on the switch never becomes shutdown because it is a feature of the phone to avoid the lost of connection of the PC connected to the phone. So the mac table and port-security mac table aren't cleared during the reboot process.

The problem occurs because the port-security seems to not allow the phone to go back in the access vlan from its voice vlan as I will explain you here :

1) When the phone is in function we can see its mac address + vlan 8 in the table with the "show mac- int fa 1/0/11".

2) The phone reboot to try an upgrade and it doesn't shut the interface so the link on the switch is always up (phone mac + vlan 8 stays in the table).

3) The phone must restart in the access vlan BUT we never seen the couple "phone mac addr + access vlan" in the "show mac- int fa 1/0/11"

So the interface don't add the "phone mac + access vlan" in the table after the "phone mac + voice vlan" entry. This step is blocked by the port-security and I don't know why but I can assure that if I shutdown the phone by a "shut no shut" then the mac table is cleared and the phone boot in the access vlan, then in the voice and the the upgrade begins.

I also tried thes two next configurations and all was rebooting fine and the upgrade worked too :

interface FastEthernet1/0/1
  switchport access vlan 20
  switchport mode access
  switchport nonegotiate
  switchport voice vlan 8

spanning-tree portfast
end

interface FastEthernet1/0/1
  switchport trunk encapsulation dot1q

switchport mod trunk

switcport trunk native vlan 20

switchport trunk allowed vlan 8,20

switchport nonegotiate
  switchport port-security maximum 50
  switchport port-security
  switchport port-security aging time 1
  switchport port-security violation restrict
  switchport port-security aging type inactivity
end

With these two configurations we encounter the following steps :

1) When the phone is in function we can see its mac address + vlan 8 in the table with the "show mac- int fa 1/0/11".

2) The phone reboot to try an upgrade and it doesn't shut the interface so the link on the switch is always up (phone mac + vlan 8 stays in the table).

3) The phone must restart in the access vlan AND we can see the couple "phone mac addr + access vlan" in the "show mac- int fa 1/0/11" after the "phone mac + vlan 8" entry.

4) The phone reboots in the vlan 8 and upgrade itself fine.

So for, the first config (this without port-security) indicates that the port-security is the cause of the problem but the second configuration indicates that it is also related with the "switchport voice vlan" command.

So my questions are these :

- Is it a bug or a protection feature ? Indeed, it is not a normal behavior of the phone to go back from the voice vlan to the access vlan.

- Is there an incompatibility between the port-security features and the "switchport voice vlan 8" command ?

- Is the "switchport voice vlan 8" command reserved only for Cisco ip phone ?

- What kind of additionnal features can turn on the "switchport voice vlan" command ?

- Why the switch don't support the phone to go voice vlan --> access vlan --> voice vlan ?

I hope you can explain me more in details what happens with my initial configuration and why the couple "port-security + voice vlan" doesen't work well

Thank you in advance.

Bye.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Mon, 12/14/2009 - 12:21

Hello Nicolas,

first of all my compliments for your very clear post.

I think that you have already found the root cause of the problem: the fact that the Alcatel-lucent phones are able to keep live the port while rebooting is a difference with what a Cisco IP phone does.

The switchport voice vlan command actually instructs the port to act as a mini-trunk with only two vlans allowed: the native data vlan = access vlan and the voice vlan. This allows for 802.1Q tagged VoIP frames that is very handy for implementing QoS up to the user.

The switchport port-security commands instructs the port to enable all the port security framework on the port.

The difference with the third configuration is the switchport mode trunk command that probably looses some controls because the port becomes a full featured 802.1Q trunk where it is allowed to see the same MAC address in different vlans (think of SVIs MAC addresses, router vlan subinterfaces and may be some server os environments).

To demonstrate this in the third configuration I would add the switchport voice vlan 8 command and you should see the same behaviour.

This should show that the three commands switchport port security, switchport mode trunk, switchport voice vlan can work together.

The adding of switchport mode trunk and of the list of permitted vlans can be seen as a workaround.

see

https://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/port_sec.html#wp1138948

for comparison documentation of 7940 with SIP protocol

https://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7960g_7940g/sip/4_4/english/administration/guide/sipovr44.html#wp1026596

Hope to help

Giuseppe

NicolasDemonty Tue, 12/15/2009 - 07:06

Hi Giuseppe,

thank you for your answer. I'm afraid but I can't solve this problem. I still have questions about it and the behavior of the port-security.

Indeed, I did another tests to try to understand what happens.

1) After reading the two links you provided me, I tried this configuration and launched the upgrade :

interface FastEthernet1/0/25
switchport access vlan 20
switchport mode access
switchport nonegotiate
switchport voice vlan 8
switchport port-security maximum 15
switchport port-security maximum 10 vlan access
switchport port-security maximum 5 vlan voice
switchport port-security
switchport port-security aging time 1
switchport port-security violation restrict
switchport port-security aging type inactivity
spanning-tree portfast
end

RESULT : no upgrade because the switch interface blocks the phone frames in the access vlan 20 (when it starts the first time).

2) I forced the phone to boot only and directly in the voice vlan 8 :

In this case, the phone can upgrade itself. It is normal because the interface switch seen only the mac phone in the vlan 8 without going in the access vlan before !

With your two links, I understood that in trunk mode, the same MAC can appear in two different vlans on the switch interface in the same time. I find that logical because the neighbor switch interface appears in all the trunk vlans. Thus, I find this behavior normal. I agree your explaination about the characteristics of the access + voice vlan (mini trunk with less functionalities that the full trunk) but if I compare the full trunk with the "voice vlan" interface, there is a major difference : the access + voice interface don't accept the same MAC address in two differents vlans in the same time. Isn't it ? (but the full trunk accepts it without problem).

I have two different cases :

1) I do a shutdown then a no shutdown of my interface and then the phone can boot and upgrade itself correctly. So, with the shutdown command, I cleared the mac and port-security entries. The sequence is the following :

    • the phone boots in the access vlan --> an entry "phone mac + access vlan" is created.
        • after the reception of its first config (in access vlan), the phone boots in the voice vlan (without shutting its interface) and an "phone mac + voice vlan" entry is created BUT the previous entry is STILL in the table. The interface stored the phone mac in the access and voice vlan in the same time !

        ---> So, why is it permitted by the port-security ?

        2) I don't shutdown the interface and I launch the upgrade request. So the interface don't reset the entries and it contains the "phone mac + vlan 8" entry before during the first reboot. In this case, when the phone tries to boot in the access vlan the "phone mac + access vlan" is never created. The question is WHY

        ---> Why is the entry never created (and thus the traffic is blocked) ?

        In the first case we seen that the phone mac appeared in the access vlan then in the voice one without any problem (the two entries exists in the same time because of the aging time). BUT in the second case, the phone is in the voice vlan and tried to boot in the access one and the phone mac in the access vlan is blocked.

        ---> Why ? The only difference is the order of the entries in the mac table : "access --> voice" against "voice --> access".

        Thus my biggest question is : why this transition is blocked ? Is it a feature of the combination "port-security + switchport voice vlan" that block automaticaly the unwanted transition "voice --> acccess" ?

        As you can see it is a real problem for us because we have more thant 3200 Alcatel IP phones in service and we want to upgrade them but without a "shut no shut" procedure ;-).

        Thank for your information

        Nicolas

        Giuseppe Larosa Wed, 12/16/2009 - 00:12

        Hello Nicholas,

        if this option

        I forced the phone to boot only and directly in the voice vlan 8 :

        it is not easy to deploy on all phones, I would consider to open a service request with cisco TAC to ge ufficial advice.

        if you know which phone connects on each port, the shut /no shut procedure can be automated with scripts. Using for example TCL/TK with expect.

        As I wrote in my first post I think you have performed a good in depth analysis and that configuration is correct.

        So it is high time to open a service request. Hopefully they may have already helped other customers with similar issues.

        Hope to help

        Giuseppe

        NicolasDemonty Wed, 12/16/2009 - 01:24

        Hi Giuseppe,

        thank you for your help. I'll follow your advice and I'll open a case.

        I'll post the solution (if there is one) for all as soon as I can.

        Bye

        Nicolas

        Pieter Geens Wed, 01/06/2010 - 07:17

        Hi Nicolas

        I´m experiencing the same issue. Switches are cat 3560POE and voip phones Alcatel ip touch. In stead of port security for the voice vlan i now use a vacl which only allows the Alcatal mac oid to communicate, until the issue is resolved.

        I reported this in october to cisco TAC, but did not get an answer yet, will update this post when cisco responds.

        1. telephone is booting for the first time
        2. telephone receives correct voice vlan via dhcp info in the access vlan 20 (only vlan it knows)


           sh port-security int fa 0/2 address
                     Secure Mac Address Table
           ------------------------------------------------------------------------
           Vlan    Mac Address       Type                     Ports   Remaining Age
                                                                         (mins)
           ----    -----------       ----                     -----   -------------
             20    0080.9f69.eb3e    SecureSticky             Fa0/2        -
           ------------------------------------------------------------------------
           Total Addresses: 1

        3. telephone receives vlan 41 and changes from vlan20 to voice vlan41

           sh port-security int fa 0/2 address
                     Secure Mac Address Table
           ------------------------------------------------------------------------
           Vlan    Mac Address       Type                     Ports   Remaining Age
                                                                         (mins)
           ----    -----------       ----                     -----   -------------
             41    0080.9f69.eb3e    SecureSticky             Fa0/2        -
           ------------------------------------------------------------------------
           Total Addresses: 1

        4. telephone works perfectly
        5. telephone cable is unplugged and plugged back in (POE) and reboots

           sh port-security int fa 0/2 address
                     Secure Mac Address Table
           ------------------------------------------------------------------------
           Vlan    Mac Address       Type                     Ports   Remaining Age
                                                                         (mins)
           ----    -----------       ----                     -----   -------------
             41    0080.9f69.eb3e    SecureSticky             Fa0/2        -
           ------------------------------------------------------------------------
           Total Addresses: 1

        6. telephone does not boot, it does not have access to access vlan 20 anymore and does not receive the correct voice vlan via dhcp.

           Removing the above Securesticky learned mac address, and the telephone boots again successfully
           I looks like port security only allows the change from access to voice and not from voice to access
           Also the SecurityViolation count does not increase, so why does the switch block this traffic?

        regards

        Pieter Geens

        NicolasDemonty Thu, 01/07/2010 - 00:55

        Hi,

        I reported the problem to IBM and I'm waiting for the solution.

        I'll update the post as soon I receive an answer.

        Bye

        Actions

        This Discussion