I've had an issue for years with Mitel 5000 series IP phones and the passthrough LAN interface. It's a combined issue with Intel (and other) NICs.
The switchport is configured with a Voice VLAN (single 802.1q tagged VLAN) and the untagged access VLAN. It's a Cisco switch so its a 'pseudo trunk' configured like this:
The IP phones discover the Voice VLAN tag through either CDP or LLDP (both are running on the switch). This works fine - the IP phone uses 802.1q tagged packets on VLAN 20 and the PC uses untagged packets that are handled by VLAN 10 on the switch.
However, the Mitel 5330 passes ALL broadcasts & multicasts from the uplink to the PC downlink from BOTH VLANs. The Intel NIC by default strips the 802.1q tags from the Voice VLAN packets so the attached laptop effectively sees these packets without tags (it's the same if the PC was directly connected to the switchport). We are running 802.1x & MAB authentication on the ports so the VLANs actually get dynamically assigned so we don't actually see this behaviour when a PC is directly connected as the configured access & Voice VLANs are just layer-2 and local to the switch - the authentication mechanism assigns the real VLANs.
This passing through of tagged and untagged packets isn't a problem with IPv4 as the PC only gets a DHCPv4 address from the access VLAN so discards the broadcasts from the Voice VLAN that are synthetically untagged by the NIC driver. With IPv6 and SLAAC though, the PC assigns itself IPv6 addresses on BOTH VLANs as the ICMPv6 messages from the router on BOTH VLANs reach the PC. This leads to IPv6 connectivity issues when the PC sends traffic sourced from an IPv6 address in the Voice VLAN.
With Cisco IP Phones, tagged packets are prevented from passing through to the PC so we don't see the same behaviour. It's a configurable setting on Cisco CallManager: "PC Voice VLAN Access" can be enabled or disabled.
Are there any similar settings on Mitel to block tagged packets from passing through the phone to the PC? It hasn't been as issue until recently when IPv6 is being pushed out.
The switchport is configured with a Voice VLAN (single 802.1q tagged VLAN) and the untagged access VLAN. It's a Cisco switch so its a 'pseudo trunk' configured like this:
Code:
interface GigabitEthernet0/1
switchport mode access
switchport access vlan 10
switchport voice vlan 20
switchport nonegotiateThe IP phones discover the Voice VLAN tag through either CDP or LLDP (both are running on the switch). This works fine - the IP phone uses 802.1q tagged packets on VLAN 20 and the PC uses untagged packets that are handled by VLAN 10 on the switch.
However, the Mitel 5330 passes ALL broadcasts & multicasts from the uplink to the PC downlink from BOTH VLANs. The Intel NIC by default strips the 802.1q tags from the Voice VLAN packets so the attached laptop effectively sees these packets without tags (it's the same if the PC was directly connected to the switchport). We are running 802.1x & MAB authentication on the ports so the VLANs actually get dynamically assigned so we don't actually see this behaviour when a PC is directly connected as the configured access & Voice VLANs are just layer-2 and local to the switch - the authentication mechanism assigns the real VLANs.
This passing through of tagged and untagged packets isn't a problem with IPv4 as the PC only gets a DHCPv4 address from the access VLAN so discards the broadcasts from the Voice VLAN that are synthetically untagged by the NIC driver. With IPv6 and SLAAC though, the PC assigns itself IPv6 addresses on BOTH VLANs as the ICMPv6 messages from the router on BOTH VLANs reach the PC. This leads to IPv6 connectivity issues when the PC sends traffic sourced from an IPv6 address in the Voice VLAN.
With Cisco IP Phones, tagged packets are prevented from passing through to the PC so we don't see the same behaviour. It's a configurable setting on Cisco CallManager: "PC Voice VLAN Access" can be enabled or disabled.
Are there any similar settings on Mitel to block tagged packets from passing through the phone to the PC? It hasn't been as issue until recently when IPv6 is being pushed out.