6860 and phone QoS issue

[alcashite]

We have had some Cisco 7841 and 8831 phones set up for a while and have recently moved to 6860 switches at a few sites and are now experiencing issues with the phones dropping IP. We have previously used these phones on 6450 switches without issue. Our other main model of phone in use (Cisco 6941) are not experiencing this issue on the 6860s.

Upon plugging in, the phones will boot up, obtain an IP address through DHCP normally, register then about 5-10 seconds later will drop its IP and unregister and go through same loop again and never retain an IP for more than 10 seconds. A wireshark trace reveals the phone is going through DHCP as normal, then after 5 seconds or so will send a DHCP release. It also seems that the phone will try and hop between two different addresses each time it goes through DHCP, first time it will get one address, then will DHCP release and then will go for the other address next time.

We have managed to get the phones working using fixed IP or by removing config on the switches relating to DSCP/QoS network policy. Upon removing this the phone will obtain an IP, register and work fine but obviously it disables QoS. Our networks guys have been unable to figure out the issue and so far our 3rd party network support and 3rd party phone support have not been able to figure it out either.

The config in question is 'lldp network-policy X application voice vlan X l2-priority 7 dscp 46'. Once this is removed the phone works and as soon as we add this back in the phone will drop and start going through the loop again.

We have tried upgrading phones to latest firmware and also the switch to latest firmware and various other settings on the phone config on CUCM and have not been able to get these phones up and running without either fixing the IP address or removing QoS from our switches.

Any ideas appreciated. Thanks.

[silvio]

Did your phones uses lldp-med? Mostly cisco will uses cdp instead. If possible try to deactivate lldp at the phones.
I didn't think that the qos is the reason. It seams to be the vlan in this policy.
regards
Silvio

[alcashite]

Hi, yes the phones use LLDP MED.

If I set the switch port to just our PC VLAN the phone works fine. If I set it to just the voice VLAN it also works fine so no issue with the VLANs individually. Once I enable the port for PC untagged and voice tagged and also enable our LLDP policies that should drop it in the voice VLAN the phone will either get stuck obtaining then dropping it's IP on the voice or PC VLAN.

Relevant bits of the config from our test switch below:

! VLAN:
vlan 1 admin-state disable
vlan 1021 admin-state enable
vlan 1021 name "STAFF"
vlan 1024 admin-state enable
vlan 1024 name "IPT"
vlan 1021 members port 1/1/1-3 untagged
vlan 1024 members port 1/1/3 tagged

! IP:
ip service telnet admin-state disable
ip interface "vlan-STAFF" address 10.144.178.1 mask 255.255.254.0 vlan 1021 ifindex 1
ip interface "vlan-IPT" address 10.146.217.1 mask 255.255.255.0 vlan 1024 ifindex 5

! NTP:
ntp server 10.80.1.9 prefer
ntp server 10.80.1.14
ntp client admin-state enable

! QOS:
qos log level 8 log console
qos port 1/1/3 trusted
qos apply

! LLDP:
lldp network-policy 1 application voice vlan 1024 l2-priority 5 dscp 46
lldp nearest-bridge chassis notification enable
lldp nearest-bridge chassis tlv management port-description enable system-name enable system-description enable
lldp nearest-bridge chassis tlv management management-address enable
lldp nearest-bridge chassis tlv dot1 vlan-name enable port-vlan enable
lldp nearest-bridge chassis tlv dot3 mac-phy enable
lldp nearest-bridge chassis tlv med capability enable ext-power-via-mdi enable network-policy enable
lldp port 1/1/3 med network-policy 1

ip domain-name XXXXXX
ip name-server 10.80.1.9 10.80.1.14
system timezone BST

! UDP Relay:
ip helper per-vlan-only
ip helper vlan 1021 address 10.80.1.9
ip helper vlan 1021 address 10.80.1.14
ip helper vlan 1024 address 10.80.1.9
ip helper vlan 1024 address 10.80.1.14

! LAN Power:
lanpower slot 1/1 service start

Thanks for your help.

[silvio]

not a good config for your ports. I prefere access guardian ports with mobile-tag enabled instead of static (like at your config for port 1/1/3).


here an unp example for all your ports with template (you can try with one port).

Code: Select all

unp profile STAFF
unp profile STAFF map vlan 1021
unp profile IPT mobile-tag
unp profile IPT map vlan 1024
unp classification vlan-tag 1024 profile1 IPT
unp port-template TEMPLATE1
unp port-template TEMPLATE1 classification 
unp port-template TEMPLATE1 default-profile STAFF
unp port 1/1/1-48 port-type bridge
unp port 1/1/1-48 port-template TEMPLATE1

your lldp-med config is ok.

Code: Select all

lldp network-policy 1 application voice vlan 1024 l2-priority 5 dscp 46
lldp nearest-bridge chassis tlv med capability enable network-policy enable
lldp port 1/1/3 med network-policy 1

than you can check the state of your clients with "show unp user" and "show vlan members port ..." etc.
There you can check if your phones are tagging correctly.

regards
Silvio

[alcashite]

Hi Silvio,

Thanks for your help.

I have configured as suggested and it appears to work as desired (the phone ends up on our IPT VLAN) but it still experiences the same issue and will obtain an IP address on our voice VLAN then drop it 5-10 seconds later and continue looping like this.

Config on the switch is now:

Code: Select all

! DA-UNP:
unp profile "IPT" mobile-tag
unp profile "STAFF"
unp profile "IPT" map vlan 1024
unp profile "STAFF" map vlan 1021
unp port-template TEMPLATE1 direction both default-profile "STAFF" classification trust-tag admin-state enable
unp port 1/1/12 port-type bridge
unp port 1/1/12 port-template TEMPLATE1
unp classification vlan-tag 1024 profile1 "IPT"

! LLDP:
lldp network-policy 1 application voice vlan 1024 l2-priority 5 dscp 46
lldp nearest-bridge chassis notification enable
lldp nearest-bridge chassis tlv management port-description enable system-name enable system-description enable
lldp nearest-bridge chassis tlv management management-address enable
lldp nearest-bridge chassis tlv dot1 vlan-name enable port-vlan enable
lldp nearest-bridge chassis tlv dot3 mac-phy enable
lldp nearest-bridge chassis tlv med capability enable ext-power-via-mdi enable network-policy enable
lldp chassis med network-policy 1

Not sure if you meant for me to remove some of the LLDP commands to leave only the three you quoted?:

Code: Select all

lldp network-policy 1 application voice vlan 1024 l2-priority 5 dscp 46
lldp nearest-bridge chassis tlv med capability enable network-policy enable
lldp port 1/1/3 med network-policy 1

We have now escalated this directly to Alcatel via our vendor as we have been unable to get these phones working on 6860s.

[alcashite]

For some reason when checking the IP of the phone it appears that it is retaining an IP on our STAFF range somehow:

Code: Select all

Remote LLDP nearest-bridge Agents on Local Port 1/1/12:

    Chassis 0.0.0.0, Port 006CBCA84E20:P1:
      Remote ID                   = 1965,
      Chassis Subtype             = 5 (Network Address),
      Port Subtype                = 7 (Locally assigned),
      Port Description            = SW PORT,
      System Name                 = SEP006CBCA84E20,
      System Description          = Cisco IP Phone 7841, V1, sip78xx.11-7-1-17.loads,
      Capabilities Supported      = Bridge Telephone,
      Capabilities Enabled        = Bridge Telephone,
      MED Device Type             = Endpoint Class III,
      MED Capabilities            = Capabilities | Power via MDI-PD(33),
      MED Extension TLVs Present  = Network Policy| Inventory,
      MED Power Type              = PD Device,
      MED Power Source            = PSE,
      MED Power Priority          = Unknown,
      MED Power Value             = 3.6 W,
      Remote port MAC/PHY AutoNeg = Supported Enabled Capability 0x6c01,
      Mau Type                    = 1000BaseTFD - Four-pair Category 5 UTP full duplex mode


    Chassis 10.144.179.241, Port 006CBCA84E20:P1:
      Remote ID                   = 1966,
      Chassis Subtype             = 5 (Network Address),
      Port Subtype                = 7 (Locally assigned),
      Port Description            = SW PORT,
      System Name                 = SEP006CBCA84E20.kingston.ac.uk,
      System Description          = Cisco IP Phone 7841, V1, sip78xx.11-7-1-17.loads,
      Capabilities Supported      = Bridge Telephone,
      Capabilities Enabled        = Bridge Telephone,
      Management IP Address       = 10.144.179.241,
      MED Device Type             = Endpoint Class III,
      MED Capabilities            = Capabilities | Power via MDI-PD(33),
      MED Extension TLVs Present  = Network Policy| Inventory,
      MED Power Type              = PD Device,
      MED Power Source            = PSE,
      MED Power Priority          = Unknown,
      MED Power Value             = 3.6 W,
      Remote port MAC/PHY AutoNeg = Supported Enabled Capability 0x6c01,
      Mau Type                    = 1000BaseTFD - Four-pair Category 5 UTP full duplex mode


    Chassis 10.146.217.213, Port 006CBCA84E20:P1:
      Remote ID                   = 1967,
      Chassis Subtype             = 5 (Network Address),
      Port Subtype                = 7 (Locally assigned),
      Port Description            = SW PORT,
      System Name                 = SEP006CBCA84E20.kingston.ac.uk,
      System Description          = Cisco IP Phone 7841, V1, sip78xx.11-7-1-17.loads,
      Capabilities Supported      = Bridge Telephone,
      Capabilities Enabled        = Bridge Telephone,
      Management IP Address       = 10.146.217.213,
      MED Device Type             = Endpoint Class III,
      MED Capabilities            = Capabilities | Power via MDI-PD(33),
      MED Extension TLVs Present  = Network Policy| Inventory,
      MED Power Type              = PD Device,
      MED Power Source            = PSE,
      MED Power Priority          = Unknown,
      MED Power Value             = 3.6 W,
      Remote port MAC/PHY AutoNeg = Supported Enabled Capability 0x6c01,
      Mau Type                    = 1000BaseTFD - Four-pair Category 5 UTP full duplex mode

Code: Select all

Total 3 arp entries
 Flags (P=Proxy, A=Authentication, V=VRRP, B=BFD, H=HAVLAN, I=INTF)

 IP Addr           Hardware Addr       Type       Flags   Port              Interface   Name
-----------------+-------------------+----------+-------+-----------------+-----------+---------------------------------
 10.144.179.241    00:6c:bc:a8:4e:20   DYNAMIC                      1/1/12  vlan-STAFF
 10.146.217.213    00:6c:bc:a8:4e:20   DYNAMIC                      1/1/12  vlan-IPT

This seems odd as the phone is not daisy chained to another device currently.

[silvio]

Hi,
what is the output of
> show unp user
Are all the users in the correct unp associated?

[alcashite]

Show unp users comes back with:

Code: Select all

Port    Username             Mac address       IP              Vlan Profile                          Type         Status
-------+--------------------+-----------------+---------------+----+--------------------------------+------------+-----------
1/1/12  00:6c:bc:a8:4e:20    00:6c:bc:a8:4e:20 10.146.217.213  1024 IPT                              Bridge       Active
1/1/12  00:6c:bc:a8:4e:20    00:6c:bc:a8:4e:20 10.144.179.216  1021 STAFF                            Bridge       Active

Total users : 2

Not sure if this is correct?

Thanks.

[silvio]

same mac in both unp (profiles). And so in both vlan. Seams to be not correct.
But the reason for it will be, that we have classified the traffic with the vlan tag. That means that only tagged traffic goes to profile IPT. Untagged traffic from your phone (f.e. 802.1x-auth packets) will be associated to default profile STAFF. So in my opinion all is correct.
But I am wondering about the different IP addresses. I have used a lot of different ip-phones. But never seen this behavior.
So it will be the best, that you use extra to the vlan tag also the vendor-oui (mac 00:6c:bc) as classification to profile IPT.

unp classification mac-oui xxx profile1 "IPT"

regards
Silvio

[alcashite]

Hi, yes I did find that odd that it retained an IP for the STAFF VLAN as the phone had no PC plugged in to it so shouldn't be showing an IP there.

Have added the mac classification and now get:

Code: Select all

Port    Username             Mac address       IP              Vlan Profile                          Type         Status
-------+--------------------+-----------------+---------------+----+--------------------------------+------------+-----------
1/1/12  00:6c:bc:a8:4e:20    00:6c:bc:a8:4e:20 10.146.217.213  1024 IPT                              Bridge       Active

Total users : 1

Total 2 arp entries
 Flags (P=Proxy, A=Authentication, V=VRRP, B=BFD, H=HAVLAN, I=INTF)

 IP Addr           Hardware Addr       Type       Flags   Port              Interface   Name
-----------------+-------------------+----------+-------+-----------------+-----------+---------------------------------
 10.146.217.213    00:6c:bc:a8:4e:20   DYNAMIC                      1/1/12  vlan-IPT
 10.254.0.60       e8:e7:32:81:35:ba   DYNAMIC    B                 1/1/49  vlan-927

But still having the same issue. Phone will get that IP address but drop and come back up.

Code: Select all

PING 10.146.217.213 (10.146.217.213): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
64 bytes from 10.146.217.213: icmp_seq=6 ttl=57 time=1.738 ms
64 bytes from 10.146.217.213: icmp_seq=7 ttl=57 time=0.901 ms
64 bytes from 10.146.217.213: icmp_seq=8 ttl=57 time=0.952 ms
64 bytes from 10.146.217.213: icmp_seq=9 ttl=57 time=0.830 ms
64 bytes from 10.146.217.213: icmp_seq=10 ttl=57 time=0.891 ms
64 bytes from 10.146.217.213: icmp_seq=11 ttl=57 time=0.914 ms
64 bytes from 10.146.217.213: icmp_seq=12 ttl=57 time=0.834 ms
64 bytes from 10.146.217.213: icmp_seq=13 ttl=57 time=0.900 ms
64 bytes from 10.146.217.213: icmp_seq=14 ttl=57 time=0.829 ms
64 bytes from 10.146.217.213: icmp_seq=15 ttl=57 time=0.862 ms
64 bytes from 10.146.217.213: icmp_seq=16 ttl=57 time=0.846 ms
64 bytes from 10.146.217.213: icmp_seq=17 ttl=57 time=0.804 ms
64 bytes from 10.146.217.213: icmp_seq=18 ttl=57 time=0.930 ms
64 bytes from 10.146.217.213: icmp_seq=19 ttl=57 time=0.915 ms
64 bytes from 10.146.217.213: icmp_seq=20 ttl=57 time=0.828 ms
64 bytes from 10.146.217.213: icmp_seq=21 ttl=57 time=0.984 ms
64 bytes from 10.146.217.213: icmp_seq=22 ttl=57 time=0.920 ms
64 bytes from 10.146.217.213: icmp_seq=23 ttl=57 time=1.023 ms
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
Request timeout for icmp_seq 28
Request timeout for icmp_seq 29
Request timeout for icmp_seq 30
Request timeout for icmp_seq 31
Request timeout for icmp_seq 32
Request timeout for icmp_seq 33
Request timeout for icmp_seq 34
Request timeout for icmp_seq 35
64 bytes from 10.146.217.213: icmp_seq=36 ttl=57 time=0.845 ms
64 bytes from 10.146.217.213: icmp_seq=37 ttl=57 time=0.882 ms
64 bytes from 10.146.217.213: icmp_seq=38 ttl=57 time=0.919 ms
64 bytes from 10.146.217.213: icmp_seq=39 ttl=57 time=0.928 ms
64 bytes from 10.146.217.213: icmp_seq=40 ttl=57 time=0.944 ms
64 bytes from 10.146.217.213: icmp_seq=41 ttl=57 time=0.974 ms
64 bytes from 10.146.217.213: icmp_seq=42 ttl=57 time=0.845 ms
64 bytes from 10.146.217.213: icmp_seq=43 ttl=57 time=0.852 ms
64 bytes from 10.146.217.213: icmp_seq=44 ttl=57 time=0.798 ms
64 bytes from 10.146.217.213: icmp_seq=45 ttl=57 time=0.826 ms
64 bytes from 10.146.217.213: icmp_seq=46 ttl=57 time=0.842 ms
64 bytes from 10.146.217.213: icmp_seq=47 ttl=57 time=0.855 ms
64 bytes from 10.146.217.213: icmp_seq=48 ttl=57 time=1.262 ms
64 bytes from 10.146.217.213: icmp_seq=49 ttl=57 time=0.980 ms
64 bytes from 10.146.217.213: icmp_seq=50 ttl=57 time=0.991 ms
64 bytes from 10.146.217.213: icmp_seq=51 ttl=57 time=0.887 ms
64 bytes from 10.146.217.213: icmp_seq=52 ttl=57 time=0.936 ms
64 bytes from 10.146.217.213: icmp_seq=53 ttl=57 time=0.806 ms

This config seems to successfully get the phone on the right IP subnet without issue which wasn't the case before (sometimes it would get IP only on STAFF and then drop and loop) but we still having the IP address drop. Wireshark trace I did before showed the phone was sending a DHCP release packet for some reason and I guess is still happening now. Perhaps the issue is with our DHCP server? It is odd that it only affects this model of phone only on OS6860 and not when connected to other switches so must be something specific about the two together.

Thanks for all your help Silvio.