Aastra 6757i automated deployment

In the interest of making the endpoint deployment easier, we are working toward this model:

  1. Unbox, assemble and install the phone.
  2. Phone’s first boot gets its IP from the data network VLAN, and gets config from TFTP assigning it to the appropriate voice VLAN and rebooting.
  3. Phone now boots into voice VLAN and gets IP and config server from the voice space.  The TFTP config here kicks off the Aastra process that requests the extension and password and configures the phone.
Boom!  Done.  Sounds nice, eh?  Here’s where we’re up a tree.  I have the PBX-In-A-Flash server configured with an IP in both the data and voice VLANs, TFTP responding in both VLAN spaces, and the initial process works as you’d expect: Boot happens, grabs IP, grabs config, reboots, gets voice IP and does a firmware check, sees the new firmware in the voice TFTP space, installs new firmware, reboots, and then…..
Um…  yeah. Then it continually reboots once it gets to the 50% checking for firmware point in the boot process.  So you may see a “passive network tap” writeup from me soon documenting what has already become somewhat of a circus trying to get what seemed like a simple wireshark capture.  <sigh>
[UPDATE] Okay, here’s what I screwed up:  I did not realize that the config COMPLETELY OVERWRITES any previous config.  In other words, on initial boot I was telling the phone to go to the voice VLAN and reboot, and since I was assuming it was already configured for the voice VLAN, I was not adding those lines to the voice VLAN config file.  So it would get the VLAN config from the data side and reboot, get the initial voice VLAN config and reboot…   and find itself back in the data VLAN getting the voice VLAN assignment, etc. etc.  Endless reboot, designed by yours truly.  All I had to do all along was add the voice VLAN config to the final config on the voice side.

Leave a Reply

Your email address will not be published. Required fields are marked *