sf 300-48P disconnect issue

[spensleyj]

We have a SF 300-48P setup in layer 2 mode with 2 static vlans; vlan 1 (data) and vlan 2 (voice) support Mitel IP phones.  The unit has given us 3 months of trouble free service, recently however devices on vlan2 have been randomly disconnecting.  The discconects are reported to happen to 1-3 random phones per day...sometimes in the middle of a call.  The phones don't lose power, they behave as if they have lost connectivity to the phone system...but the computers connected to the phones through the built-in switches never lose connectivity - so it appears that the issue is only occurring on vlan 2.  A reboot restores the phone to service.  I've looked through what logs there are on the switch and nothing looks out of the ordinary nor are there any RMON interface errors.

The switch is running the latest firmware.  I do have copies of the config and the RAM log file if needed.

Does anyone have an idea about why this could be happenning?  I'm somewhat stymied so any advice would be appreciated.

Note:  I have seen this issue before with the older generation SRW248G4P where the native vlan works fine but other vlans intermittently stop forwarding traffic after about 8-12 months in service.  A reboot temporarily makes the switch operable again.  The only long-term resolution to that problem is to replace the switch.

startup config attached

[David Hornstein]

Hi John,

Firstly good choice to use the 300 series for VOIP applications, nice switch.

Interesting choice of configurations modes and setting, almost a bit confusing, but i guess you know the setup better than me.

A network diagram would be very useful..

I see that you set switch ports e(1-48),g(2,4) to  general mode.  This allows for multiple tagged and also untagged vlans to reside on the same switch port.

Why not just use tagged VLANs for VOICE and untag the data vlan for PC or APPLE connectivity..

Further on in the script,  you then set switch port 1 and 3  from general to access mode (only a untagged vlan can reside on these switchports in access mode ).

Your also telling the switch to trust layer 2 Class of service (COS), so i assume that all MTEL phones are tagged in VLAN2  and are sending out a COS priority in the priority bits in the VLAN Tag

Mitel seems to  supports LLDP-MED. (802.1AB).  why not experiment with the following  attached configuration.

when you have about half an hour to play with, and all users off the switch,  try the following; (keep a console cable handy)

step 1.  save your startup or running configuration to your PC desktop.

step 2.  unzip and copy the attached configuration to the startup-config of the switch and reboot the switch.

( it enables  link-layer discovery protocol  (LLPD-MED) to define the voice vlan as vlan 2.)

step 3.  via the console cable add your management ip address and gateway back into the SF300-48P.

step 4.  Ok if you must, do as you did before, and alter the basic QOS parameters of the switch to  trust COS if the Mitel phones  do not send out DSCP at Layer 3.)

step 5,  Save the  attached configuration to the startup and see if the phone system behaves itself.

I am assuming , since you trusted COS in your old configuration, that your Mitel  phones are taggable for VLAN2.

If this configuration  does not work, you can always back out,  restore factory defaults and reload the previously saved configuration that was saved to your desktop..

The contents of the attached configuration file is basically;

vlan database

vlan 2

exit

lldp med network-policy 1 voice vlan 2 vlan-type tagged

interface range ethernet all

switchport trunk allowed vlan add 2

lldp med enable network-policy

lldp med network-policy add 1

exit

I can see from your config that vlan2 is untagged on uplink ports, can't figure out wh?.

interface range ethernet e48,g(2,4)

switchport general allowed vlan add 2 untagged

General mode allows for multiple untagged and tagged vlans on a port.  I can't figure why VLAN2 is untagged on potential uplink ports as it would mingle with data vlan packets.  How would the Mitel know the difference between voice and data packets when untagged packets traverse through the same uplink.  .

To me your configuration seems  a little confusing.

Prefer almost to see the VLAN screen captures  from the GUI.

The problem really may be,  that since the phones do not loose Ethernet  connectivity, it may just be the phones loosing registration, which may be indicative of untagging uplink ports maybe to the Mitel call control unit or lack of QOS or prioritization of voice packets.. 

Do the mitel phones have a different IP network compared to the PC network ?  Maybe you can check on some of the pones that are rebooting?

But It way be interesting to enable LLDP-MED on the Mitel    so that the phones can discover that they are connected on tagged VLAN 2.

Thank you for your business,

regards Dave

[spensleyj]

Thanks for your response Dave.  The following narrative and diagram might help clarify why the switch is configured in the way it is..

Generally, I configure switches close to the following:

When implementing a system that uses VLANs, the voice and data VLANs are always assigned differenct IP subnets.

Equipment that is dedicated to the voice VLAN will be uplinked to ports untagged in voice, excluded from data and PVID set to the voice VLAN.  Because the Mitel provides DHCP to phones, excluding the data VLAN from those ports prevents the Mitel from responding to DHCP broadcasts on any VLAN other than the voice VLAN.

The data VLAN DHCP server is always uplinked to a port that is untagged in the data VLAN, excluded from the voice VLAN and PVID set to the data VLAN.  Again, this prevents the data VLAN DHCP server from responding to DHCP broadcast traffic on the voice VLAN.

All other ports are set as General, untagged in the data VLAN, tagged in the voice VLAN with PVID that corresponds to the data VLAN.

The Mitel phone bootup process is as follows:
1.  power up and broadcast for DHCP on the native vlan
2.  receive an address and multiple options from teh DHCP server that define the voice vlan, L2 priority, etc
3.  Release data VLAN Ip
4.  Join the proper VLAN then rebroadcast DHCP request
5.  Receive the voice VLAN IP from the phone system and begin downloading firmware.
note:  I don't know why the broadcasts 'hop' VLANS or if there is a way to prevent that...this is just the way I have always done it, though not necessarily the 'best' way.

I haven't messed with LLDP-MED on this series of switches yet (though have set it up on Procurves) though I plan to give it a go in the near future since it will allow steps 1-3 to be skipped.   Some of the featureset on the SF300 is new compared to the SRW series, so I haven't used them yet ... you know the saying about draining swamps and alligators? 

[David Hornstein]

Hi Jon,

You said "Because the Mitel provides DHCP to phones, excluding the data VLAN from those ports prevents the Mitel from responding to DHCP broadcasts on any VLAN other than the voice VLAN."

If the Mitel call control unit that also acts as a DHCP server is attached to a untagged port in VLAN 2 then a PC in VLAN1 will not broadcast any DHCP request into VLAN2, even if the 300 series switch is in Layer 3 mode.  If it does there is a problem with the switch.  A VLAN is a broadcast domain and broadcasts such as DHCP should not "spil over" or leak  into other VLANs.

Don't understand what you mean by "note:  I don't know why the broadcasts 'hop' VLANS or if there is a way to prevent that...this is just the way I have always done it, though not necessarily the 'best' way."  You are going to make me simulate your configuration, because what you have said should never happen.

So if ports 3-46 are set aside for Mitel phones, why not just leave the switch port mode in the default, which is  trunk mode.

Just add VLAN 2  to each switch port 3-46  as tagged members of each switch port. 

OK,  since the unmanaged switches are for PC's only,  then don't add VLAN 2 as a tagged member of these  uplink ports that lead to the unmanaged switches. simplicity.

Why not utilize the Voice VLAN functionality within the switch, see if it makes QOS for the Voice easier

regards Dave

.