Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to figure out why at our company the 3com 3101 or 3102 phones we use, when NEW out of box will not jump on the network and update, unless they are at a specific physical location.

For example, if I take a brand new phone, plug it in at Building "A", which happens to be physically where the main 3com VCX unit is also located, it will not program or get a DHCP. This building is also where all the servers and the main network stack of core switches is located (including the dhcp windows server).

If I bring the phone next door, to building "B", which has no servers, no dhcp server, etc. It jumps on fine. It has a network stack of it's own and has it's own ip subnet, but it all ties back to the main building "A".

So it really makes no sense - I would think if it had an issue, it would be the opposite, that it should not work on building B.

I know there are mac address entries in the configuration of the 3com super stack, one looks like a 3com entry, so not sure if that's part of it.

Any thoughts as to why a 3com voip phone would be able to get dhcp at the secondary location, but not at the main location, but then once it does and gets it's updates, etc. from the vcx, it's FINE, now you can bring it anywhere in the company and it will jump on fine?

share|improve this question

I'm assuming the port VLAN memberships (and other configuration attributes) are the same in both buildings, then? I've never worked with 3Com phones, but your "building A" experience sounds like what I might see plugging a phone into a port that doesn't have a "voice VLAN" specified.

The fact that it works after receiving its "updates" may indicate that the new firmware adds LLDP support (or some such) that causes the ports in "building A" to become "acceptable" to the phone, or the phone may just commit the VLAN configuration to NVRAM (thanks @Robin Gill for jogging my memory about how phones do this).

I'd start trying to identify the configuration differences between the buildings. You might also consider sniffing the traffic from a problematic phone when attached to the "building A" network. There's no substitute for seeing the packets on the wire.

share|improve this answer
Just to add, I'm guessing once the phones have been to building B, they get configured with the correct VLAN details so then use the correct VLAN back at building 1. Sorry I'm also not familiar with 3com phones, but I'm thinking along the lines that it may actually be getting DHCP, but from your normal LAN rather than VOIP VLAN. Could be helpful to plug a managed switch in the middle and mirror the phone port to see precisely what is happening. – Robin Gill Feb 21 '12 at 18:21
The VLAN concept makes sense - that possibly the stack in the other building is tagging the packets and allowing it to get DHCP, the the firmware updates are adding the VLAN in to the phone -- assuming it has that capability -- how can I check in the phone if it has a VLAN setting/what it is? – Scott Szretter Feb 23 '12 at 14:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.