matt_skalecki's profile

6 Messages

 • 

120 Points

Mon, Aug 10, 2020 10:30 PM

ICX7150-48zp : LLDP MED Voice policy UNKNOWN for MiVoice Connect phones on 2.5G ports

I have a support ticket open with our vendor, but I'm hoping others have seen and resolved my issue.

I'm deploying Mitel 69XX series phones to several new stacks of icx7150 switches (a mix of 48zp and 48pf).  I'm using LLDP MED network policies to set the voice vlan and qos setting.  This is working as expected on all standard GigabitEthernet ports (ie. all ports on the PF switches and N/1/17 to N/1/48 on the ZP switches).  However, the phones are reporting "Unknown Policy, Untagged" for the Voice application when they are connected to any of the 2.5GigabitEthernet ports (N/1/1 to N/1/16 on the ZP switches).

I'm deploying two LLDP MED policies, both include the 2.5g ports that have phones connected:
lldp transmit-interval 15
lldp tagged-packets process
lldp med fast-start-repeat-count 10
lldp med network-policy application voice tagged vlan 213 priority 5 dscp 46 ports ethe 1/1/16 ethe 1/1/25 to 1/1/48 ethe 2/1/1 to 2/1/48 ethe 3/1/1 to 3/1/48 ethe 4/1/1 to 4/1/48
lldp med network-policy application voice-signaling tagged vlan 213 priority 3 dscp 24 ports ethe 1/1/16 ethe 1/1/25 to 1/1/48 ethe 2/1/1 to 2/1/48 ethe 3/1/1 to 3/1/48 ethe 4/1/1 to 4/1/48

Port ethe 2/1/12, which I'm using for testing, is a 2.5GigabitEthernet port.  Here's its port config:
interface ethernet 2/1/12
spanning-tree 802-1w admin-edge-port
inline power power-by-class 2
trust dscp
!

And here's its LLDP Neighbor details:
Local port: 2/1/12
Neighbor: 0800.0fxx.xxxx, TTL 92 seconds
+ Chassis ID (network address): 172.xxx.xxx.xxx
+ Port ID (MAC address): 0800.0fxx.xxxx
+ Time to live: 120 seconds
+ Port description : "port 0"
+ System name : "Mitel IP Phone"
+ System description : "Mitel IP Phone"
+ System capabilities : bridge, telephone
Enabled capabilities: bridge, telephone
+ Management address (IPv4): 172.xxx.xxx.xxx
+ 802.3 MAC/PHY : auto-negotiation enabled
Advertised capabilities: 10BaseT-HD, 10BaseT-FD, 100BaseTX-HD,
100BaseTX-FD, 1000BaseT-HD, 1000BaseT-FD
Operational MAU type : 1000BaseT-FD
+ 802.3 Power via MDI: PD port + Maximum frame size: 1518 octets
+ MED capabilities: capabilities, networkPolicy, inventory
MED device type : Endpoint Class III
+ MED Network Policy
Application Type : Voice
Policy Flags : Unknown Policy, Untagged
DSCP Value : 0
+ MED Hardware revision : "6920"
+ MED Firmware revision : "5.2.1.1071"
+ MED Software revision : "5.2.1.1071"
+ MED Serial number : "xxx"
+ MED Manufacturer : "Mitel"
+ MED Model name : "6920"
+ MED Asset ID : "xxx"

Meanwhile, here is a working port:
Local port: 2/1/30
Neighbor: 0800.0fxx.xxxx, TTL 108 seconds
+ Chassis ID (network address): 10.xxx.xxx.xxx
+ Port ID (MAC address): 0800.0fxx.xxx
+ Time to live: 120 seconds
+ Port description : "port 0"
+ System name : "Mitel IP Phone"
+ System description : "Mitel IP Phone"
+ System capabilities : bridge, telephone
Enabled capabilities: bridge, telephone
+ Management address (IPv4): 10.xxx.xxx.xxx
+ 802.3 MAC/PHY : auto-negotiation enabled
Advertised capabilities: 10BaseT-HD, 10BaseT-FD, 100BaseTX-HD,
100BaseTX-FD, 1000BaseT-HD, 1000BaseT-FD
Operational MAU type : 1000BaseT-FD
+ 802.3 Power via MDI: PD port + Maximum frame size: 1518 octets
+ MED capabilities: capabilities, networkPolicy, inventory
MED device type : Endpoint Class III
+ MED Network Policy
Application Type : Voice Signaling
Policy Flags : Known Policy, Tagged
VLAN ID : 213
L2 Priority : 3
DSCP Value : 24
+ MED Network Policy
Application Type : Voice
Policy Flags : Known Policy, Tagged
VLAN ID : 213
L2 Priority : 5
DSCP Value : 46
+ MED Hardware revision : "6920"
+ MED Firmware revision : "5.2.1.1071"
+ MED Software revision : "5.2.1.1071"
+ MED Serial number : "xxx"
+ MED Manufacturer : "Mitel"
+ MED Model name : "6920"
+ MED Asset ID : "xxx"

Currently we're working around the issue by moving phones off of these ports, but that's an ugly process in one of the switch closets.

Has anyone else experienced issues with LLDP and or Mitel phones connected to 2.5GigabitEthernet ports on ixc7150-48zp switches?

Employee

 • 

183 Messages

 • 

3.2K Points

1 y ago

I have not personally seen anything like this. Your best bet would likely be to open a support case and have it looked at properly by our support team. Out of curiosity, what code are you running?

2 Messages

 • 

70 Points

3 m ago

Were you able to resolve this issue? I noticed it is doing the same thing for us.

(edited)

6 Messages

 • 

120 Points

3 m ago

We have not resolved this. We were fortunate enough to be able to easily move the phones off the multi-gig ports and onto ports 17-48, so we gave up troubleshooting.

I have periodically tested phones after installing firmware updates, but no luck through 08.0.90k

(edited)

2 Messages

 • 

70 Points

@matt_skalecki 

Thanks. One other question for you.

We are using "lldp med network-policy application voice tagged vlan 213 priority 5 dscp 46" command so the phones will boot up using the tagged vlan.

But what exactly is the other command doing "lldp med network-policy application voice-signaling tagged vlan 213 priority 3 dscp 24"?

Ruckus documentation states "For use in network topologies that require a separate policy for video signaling than for video media"

Also, how are you determining the priority and dscp values for both of these commands? Looking through both Ruckus and Mitel documentation I can't find much. Thanks!

6 Messages

 • 

120 Points

The Mitel documentation mentions using dscp 24 for signaling traffic and dscp 46 for RTP traffic in a few locations. The two I'm seeing now are the "General Network Requirements" section of the "MiVoice Connect Planning and Installation Guide" and page 4-47 of the "Mitel 6800/6900 Series SIP Phone Release 5.0.0 SP2 Administration Guide". I also saw the commands in a forum post somewhere when I was researching exactly how to configure LLDP-MED on the ICX switches specifically (since the Mitel documentation is switch agnostic), but I can't locate that source.

Important Announcement