0

I have some Mitel IP phones that are giving me trouble on a network I recently inherited. I literally came in on for my first day supporting the system on Monday 12/28 to find the fiber connection to the building had been down since the day before Christmas. Thankfully almost everyone is out this entire week. That link is back up now, but the IP phones in the building will not get good IP addresses. I'd really like to have things back to normal by Monday. I came into this knowing very little about the setup, but here's what I've been able to turn up on how things are configured at the moment:

  • The phone system uses a separate vlan from the computers (of course).
  • Each phone shares a wire with the computer at the desk (the computers plug into the back of the phone). That's typical from other environments I've seen.
  • The switch at the building (a 3com superstack 4200) doesn't have any apparent ability to configure vlans per port itself, but is supposedly at least vlan aware and should pass on vlan tags for me.
  • This remote switch talks via a fiber link to a 4900SX fiber switch in the server room across campus that can manage vlans per port; each port can be tagged, untagged, or not a member of a vlan.
  • The 4900 is configured with the normal/default vlan untagged for the remote link, and the phone vlan tagged. This sounds right to me.
  • The phones vlan is on a completely different subnet than the default vlan. I mean, 192.168.xx vs 10.x.x.x, so it's not even close. Addresses for both networks are served from a single Windows Server 2003 dhcp server, with a different zone for each vlan.

The problem is that the phones can't get a valid ip address. Here's how I understand things are supposed to work:

  • A phone starts up with a basic configuration and requests an ip address via dhcp.
  • There are no vlans set on the phone yet, and so it should get a response with an address from the zone on the default/computer network.
  • This zone is configured with a few extra options that the phones recognize.
  • The phone reconfigures itself based on those options, releases the old invalid ip and requests a new ip address, this time tagging it's frames with the correct vlan.
  • The 4900 switch should see the tag, and this time when it forwards the packets to the dhcp server they'll look like they belong in the dhcp zone for the phone vlan.
  • The dhcp server sends back a response for the correct vlan, and the phones are able to connect to the VoIP pbx correctly.

What I watch them boot up is they get the first ip address and reconfigure with the new vlan, but then are either unable to get a new address or continue to get an invalid address and end up stuck in dhcp discovery mode, endlessly retrying the request.

Any ideas about what might be wrong or how best to troubleshoot this are appreciated. Also, it seems to me like a little magic is happening with either how windows decides which dhcp zone to use (at least be default) or how the 4900 switch indicate which network the phones vlan packets belong to, so more information about how that works is appreciated as well.

My gut tells me the problem is in the 4900 switch, since that's where the solution to my first question was and that seems to be where "magic" is (it's supposed to make layer 3 decisions about which network/vlan a frame came from, but I can't see where to configure that).

Update for Dhcp options:

128 Tftp server 192.168.#.#
129 RTC IP Address 192.168.#.#
130 MITEL IP PHONE
132 VLAN ID {phone vlan id}
133 Priority 6

These are set on both zones.

Community
  • 1
Joel Coel
  • 12,932
  • 14
  • 62
  • 100

2 Answers2

2

If it is at all like Cisco does things, the phone is more or less a switch. My Cisco phones here at home (yes, I am a geek) are configured on trunk ports from the switch's point of view, VLAN only, in my case VLAN 13 and VLAN 14. The phones get an address on VLAN 13, and the PC port is VLAN 14.

The Cisco phones sort of do things magically, and CDP is involved.

Now, I suspect many phones act this way, as it sort of makes sense. Is there a configuration file to look into? It's quite possible things are in there to define what VLAN it should use for the PC port.

I would hope the phones don't expect a special DHCP option, but that's possible as well I suppose. Are there any special options defined in your DHCP config? I'm only familiar with ISC's DHCP server but I suspect windows' server can also do special options.

Michael Graff
  • 6,668
  • 1
  • 24
  • 36
  • Yes, the options are there, I'll add them to the question. – Joel Coel Dec 31 '09 at 21:43
  • The first tool I'd use is a tcpdump / wireshark run. Put it on a port that can see all the VLANs in use, and see if the clients are asking for addresses on their proper VLANs. – Michael Graff Dec 31 '09 at 21:51
  • It's sad, but I don't have that ability at the moment. I won't have access to a laptop until later next week. At the moment all I have a borrowed desktop or the server machine itself, and I'd rather not run wireshark on it directly. – Joel Coel Dec 31 '09 at 21:54
  • 1
    Use the borrowed desktop, or just run wireshark on the server. Wireshark is a fairly tame and well used application, it should cause no problems. The desktop will work just as well, but you'll have to run a cable perhaps. Depends on just how hard you want to work to see the traffic. I think that's going to point right at the problem. – Michael Graff Dec 31 '09 at 21:57
0

I feel dumb. I found where to tag the port for the correct vlan on the remote switch.

Joel Coel
  • 12,932
  • 14
  • 62
  • 100