Ethernet Switching
Highlighted
Ethernet Switching

EX4200 and Mitel phone, strange behavior, need some help

[ Edited ]
‎05-29-2019 12:52 PM

We have a stack with one EX4500 and two EX4200-48PX switches running Junos 15.1R7.9. LLDP and LLDP-MED enabled on all ports via this code

protocols {
   igmp-snooping {
      vlan all;
   }
   rstp;
   lldp {
      interface all {
         power-negotiation {
            disable;
         }
      }
   }
   lldp-med {
      interface all;
   }
}

 

I plug a Mitel phone into port ge-2/0/7 and it works perfect. LLDP/LLDP-MED negotiation allows the switch to place the phone in the voice vlan. Here is the relevant code. The port itself has the data vlan specified with the voip information shown as well

ge-2/0/7 {
   unit 0 {
      family ethernet-switching {
         port-mode access;
         vlan {
            members DO_ECS;
         }
      }
   }

 

ethernet-switching-options {
   voip {
      interface ge-2/0/7.0 {
         vlan PhonesDO_ECS;
         forwarding-class assured-forwarding;
      }
   }
}

Here is the crazy part, I plug the same phone into port ge-2/0/28 and it gets put into the data vlan! Here is the config for port ge-2/0/28 and it is identical to ge-2/0/7

ge-2/0/28 {
   unit 0 {
      family ethernet-switching {
         port-mode access;
         vlan {
            members DO_ECS;
         }
      }
   }

 

ethernet-switching-options {
   voip {
      interface ge-2/0/28.0 {
         vlan PhonesDO_ECS;
         forwarding-class assured-forwarding;
      }
   }
}

 

Any idea on what is causing this? I am not sure even how to troubleshoot this other than two wireshark captures, one from each port as the phone is booting up. I tried this on two phones and both exhibited this behavior.

3 REPLIES 3
Ethernet Switching
Solution
Accepted by topic author HendersonD
‎05-30-2019 06:21 PM

Re: EX4200 and Mitel phone, strange behavior, need some help

‎05-29-2019 08:15 PM

Hi Henderson,

 

Please check if there's any unsupported config like "switch-options" configured on the switch.   And validate if the power negotiated (especially class) is identical using "show poe interface <>" before and after moving phone between ports.  Ensure it's sending the class each time, think that's needed if you have the power-negotiation disabled.  ow poe interface <>). 

 

Try to clear the MAC address learnt on the initial port and/or bounce the ports to see if that corrects the situation.

 

In either case, ethernet-switching and lldp traceoptions might help clarify what's going on and TAC case may be the way to go:

set ethernet-switching-options traceoptions flag all

set ethernet-switching-options traceoptions file voip_trace1 files 5 size 10m

 

set protocols lldp traceoptions flag all

set protocols lldp traceoptions file lldp_trace files 5 size 10m

 

Hope this helps.

 

Regards,
-r.

--------------------------------------------------

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated Smiley Happy.

Ethernet Switching

Re: EX4200 and Mitel phone, strange behavior, need some help

‎05-30-2019 04:50 AM

I issued this command on the switch stack then rebooted the phone and it now works!

clear ethernet-switching table

 

Any idea why just clearing out the MAC addresses would solve this?

Thanks for the help on this, I was stumped

 

Ethernet Switching

Re: EX4200 and Mitel phone, strange behavior, need some help

‎05-30-2019 06:24 PM

Hi Henderson

 

Not sure if this is what you were seeing but If we receive any untagged frame on a port the mac gets learned for the data vlan part.
Normally when we do not have return attribute, the mac gets learned in the data vlan, by default and after the lldp-med capabilities are shared the mac gets learned in the voip vlan.

 

Eventually, the mac entry from the data vlan would get timed out and the mac would only show up in the voip vlan. But again if we received untagged lldp packet on the switch on the port, again the mac learning would happen for the data vlan too.


This is the expected behavior.

 

 

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are really appreciated as well.