Sep 192013

LLDP-MED for Avaya CS1000 IP PhonesIncreasing boot efficiency is one of those things I’m working on. My personal or work PC, my IP Phone, systems I manage. The less time I have to spend sitting around waiting for something to boot up is more time doing something productive. On the PC, that involves looking at your startup folder, your registry run folders and removing any unnecessary services from automatic startup.

For Avaya CS1000 IP Phones, that involves looking at the config and determining which features can be added or removed to achieve an optimal boot up sequence.

Although my 4st post is not live yet (when it is, it will be here), in it I cover Link Layer Discovery Protocol (LLDP) and how it applies to Avaya CS1000 IP Phone deployment. On of the biggest inefficiencies I’ve found in CS1000 IP Phone deployments is where customers leave LLDP enabled but don’t use it.

ZzzWaiting for LLDP-MED (Link Layer Discovery Protocol, Media Endpoint Discovery) can add as much as 30 seconds delay to the boot process… So disable it if you’re not using it!

With stickiness, you can configure the Phone to not use LLDP on bootup, or you can disable it manually at each phone by turning it off.

On the other hand, if use LLDP you might increase boot efficiency by distributing the configuration of the IP Phones and reducing dependency upon DHCP. If you want to configure the Voice VLAN but don’t use LLDP, your options are to manually configure each IP Phone or use the VLAN-A option to assign a Voice VLAN ID.

Avaya CS1000 IP Phone, DHCP provisioning behaviorIf you use DHCP though, you’re going to be querying the DHCP server (or multiple servers) multiple times.

It’s certainly faster than waiting for LLDP-MED to time out, but using LLDP-MED is faster than multiple DHCP queries (Although talking a fraction of the delay caused by LLDP-MED being enabled and unused.)

It’s also a good idea to reduce the number of retries to allow the IP Phone to failover to an alternate signaling server (i.e. Connect Server) more quickly.

Take away:

  • If you’re not using a feature, disable it. Your phones will boot faster and you’ll recover more quickly from maintenance windows or disaster.
  • Nortel-i2004-B,s1ip=;p1=4100;a1=1;r1=3;s2ip=;p2=4100;a2=1;r2=3;vq=y;st=y;lldp=n;vvsource=a;

Jul 282012

IP Phones LLDP/ADAC Boot Procedure

All Avaya IP Phones, in factory default mode, are configured with ADAC/LLDP enabled. LLDP, or Link Layer Discovery Protocol (802.1ab), and ADAC, or Auto-Detection Auto-Configuration, can operate independently. ADAC provides automatic configuration of the Data Switch port, while LLDP provides a method for the device to communicate it’s nature to the switch it connects to. ADAC can also utilize LLDP to identify the connected device type and configure the Data Switch port. Additionally, LLDP supports LLDP-MED, Link Layer Discovery Protocol Media Endpoint Discovery which permits configuration information to be provided to the Media Endpoint (i.e., IP Phone) automatically from the data switch without the need to communicate with additional components on the network.

LLDP can delay the IP Phone boot process if ADAC/LLDP is not enabled on the network. LLDP is only recommended for those environments where LLDP or ADAC is enabled on the data network.


See the documentation for precedence of configuration methods. Manual configuration always takes precedence over automatic configuration values. If any unexpected behavior is experienced, consider factory defaulting the IP Phone as part of the troubleshooting process.


This LLDP Process diagram does not include LLDP-MED behavior.

Configuration Methods

  • By default, LLDP is enabled on the IP Phone. If LLDP is enabled on the Phone, ADAC can use LLDP to identify the connected device for ADAC configuration.
    If LLDP is disabled on the IP Phone, ADAC can use the MAC Address of the connected device for ADAC configuration.
  • After DHCP Provisioning or “Manual Provisioning” via TFTP, LLDP can be disabled. However, if LLDP is manually disabled on the IP Phone, it cannot be enabled via DHCP or “Manual Provisioning”.
  • LLDP-MED can configure the following settings on the IP Phone:
    • Voice VLAN ID
    • Control pBits (priority bits, Layer 2)
    • Media pBits (priority bits, Layer 2)
    • Data pBits (priority bits, Layer 2)
    • DSCP Override of Voice and Media DSCP (DiffServ Code Point, Layer 3)

Recommended Scenarios

  • LLDP on the IP Phone is recommended where the data network is using LLDP or ADAC. If LLDP or ADAC are not enabled on the data network, then LLDP should be disabled on the phone to speed the IP Phone boot process.
  • ADAC is recommended on data networks where security is critical, or where the size of the voice network creates a requirement to distribute the boot-provisioning-registration load.
  • LLDP-MED on the data network is recommended to speed the boot procedure where Voice VLAN, pBits and DSCP values are currently configured via DHCP or TFTP (i.e., “Manual Provisioning”) and/or where security is critical.

For environments where Auto-VLAN ID is enabled, the IP Phone must request DHCP (acquiring an IP address and the Auto-VLAN ID from the DHCP server), then release the DHCP IP address and perform DHCPDISCOVERy a second time to obtain the DHCP Provisioning information. By configuring the Voice VLAN ID via LLDP/ADAC or LLDP-MED, you can eliminate the second DHCP request (reducing load on the DHCP server.)

Additionally, ADAC/LLDP and LLDP-MED increase network security by configuring the network port to the Voice VLAN instead of trusting the 801.1q VLAN ID supplied by the connected device. (A standard converged scenario is to configure the data port to trust the VLAN ID tag provided by the attached device, but this does introduce the potential for security issues and is not recommended for a secure environment.)


Auto-Detection, Auto-Configuration (ADAC) provides an automatic configuration method for Avaya (formerly-Nortel) IP Phones.

ADAC Modes configured on the Ethernet Routing Switch (ERS):

  • Untagged-Frames-Basic – Used when the IP phones are sending untagged traffic.
  • Untagged-Frames-Advanced – Used when the IP Phones are sending untagged traffic.
  • Tagged Frames – Used when the IP Phones are sending tagged traffic.

Detection Modes configured on each port (one or both must be assigned to each port to enable ADAC for that port):

  • MAC address
  • Link Layer Discovery Protocol, or LLDP (IEEE 802.1ab)

MAC address detection supports up to 32 devices per port. LLDP detection supports up to 16 devices per port. A standard scenario is one IP Phone and one PC on each port.

Ports are polled every two (2) seconds for their auto-configuration state. ADAC will be applied against a port when one of the following two conditions are true:

  • op-mode untagged-frames-basic or op-mode untagged-frames-advanced, at least one IP phone is detected on the port and no non-IP phones are detected on the port.
  • op-mode tagged frames, and at least one IP phone is detected on the port.

ADAC is removed if any of these conditions become true:

  • Auto-detect becomes disabled on the port.
  • The ports operational state becomes disabled.
  • op-mode untagged-frames-basic or op-mode untagged-frames-advanced, and at least one non-IP phone device is detected on the port.
  • There are no IP Phones detected on the port and the link is down.
  • If the link is still up but there are no IP phones on the port, auto-configuration is disabled after an aging period of about 90 seconds.
  • If all MAC addresses belonging to Nortel IP Phones on a port age out, the auto-configuration settings are removed from the port.
ADAC will automatically update VLAN ID and PVID settings under the above specified conditions. This will cause manual settings to be over-written and is design intent. Michael McNamaranoted in 2008 that an earlier release of the ERS software will maintain the VLAN ID and PVID as the port is configured when ADAC is enabled. For example, if you configure the default VLAN ID and PVID as 10 and the ADAC Voice VLAN and PVID as 20, then change the VLAN ID and PVID to 30, when ADAC resets the port configuration (either enabling ADAC or disabling ADAC), the configuration will go back to what it was configured at the time ADAC was enabled. (VLAN/PVID 10 if ADAC is disabling, VLAN/PVID 20 if ADAC is enabling.)I do not have a lab ERS to play with this configuration at this time, so I’ll just make a note that it’s something to watch for.

Jan 232012

This article provides an overview of the Avaya IP Phone registration procedure (for UNIStim IP Phones)

When the phone is powered up, the following happens:

  1. NVRAM (non-volatile RA) is loaded, including the local configuration information. Any configuration options set to manual on the phone will overwrite automatic configuration information received.
    If you experience any problems with any part of the process, use the IP Phone Factory Default reset procedure to clear all local configuration settings.


  2. Phone then boots and determines if data switch provides LLDP or ADAC. This setting can be disabled manually, via DHCP or via manual provisioning. Unless this is disabled manually, the phone will always check LLDP/ADAC when it first boots.
    Leaving LLDP/ADAC enabled when it is not supported by the Layer 2 switching equipment installed at the site can extend boot times for IP Phone devices. While LLDP/ADAC is enabled in a factory default configuration, it is recommended that this be disabled unless it is specifically supported by the networking environment.


  3. The phone then requests DHCP. If DHCP is available it processes the DHCP information.
  4. If a provisioning server is provided via DHCP Option 66, DHCP or manually configured on the IP Phone, then the the IP Phone requests the system.prv and <TYPE>.cfg from the HTTP or TFTP servers. While there is a lot more available under manual provisioning than just firmware upgrades (and while I will be writing an article to cover those topics later), I have only written the manual firmware upgrade article.
  5. Then the phone attempts to contact the S1 and S2 (primary signaling server and failover signaling server). If the phone cannot make a connection to the signaling server (or that information isn’t provided via any of the configuration methods available: manual, DHCP or provisioning server) then the Phone reboots and tries again.
  6. If a connection is made to either the primary or failover signaling server, then the phone will register and proceed with attempting to connect to External Application Servers (XAS) such as the Application Server 1000. A lot of the functionality that was originally relegated to an External Server (screen savers, backgrounds, some directory functions) have been incorporated in to the base firmware/functionality of the IP Phones. Others still require an XAS. For more information on this, contact an authorized Avaya distributor.

The only information that is critical to an IP phone for the boot process is:

  1. Set IP address, subnet mask and gateway
  2. Primary signaling server (S1) IP address, Port, Action and Retry values
  3. Node and TN

When troubleshooting, eliminate variables by resetting the unit back to factory default and then configure only the minimum number of settings needed to establish connectivity (start with manually configuring the phone, then migrate components of the configuration back to auto to determine where the process fails.)

Jan 202012

There are several reasons why you might want to enable manual provisioning of your Avaya IP Phones:

  1. Branch office scenarios, where you want to reduce bandwidth requirements for provisioning or firmware distribution.
  2. Large site scenarios, where you want to offload provisioning from the DHCP server or offload firmware distribution from the signaling server.
  3. Secure environment scenarios, where phone security is paramount and phones should not allow themselves to be reconfigured.
  4. Any scenario where a signaling server is not available, such as a home office scenario or staging warehouse scenario. This includes scenarios where you want to load VPN client licensing on to the IP phone to allow it to be deployed remotely (e.g., a home office.)

The provisioning phase of the boot process can use DHCP or HTTP. To use HTTP, you must configure DHCP Option 66 in the IP Phone VLAN to point to the HTTP server name and prefix the server name with “http://”. For example DHCP Option 66 “http://httpserver/”. Whether you select TFTP or HTTP, the provisioning phase process checks the system.prv file and if it exists, may load one of the other provisioning files. If multiple provisioning files are loaded, the configuration parameters take effect in the following priority:

  1. DEVICE (e.g., <MAC>.prv, or, 001365FEF4D4.prv)
  2. TYPE (e.g., <TYPE>.prv, or, 1140E.prv)
  3. ZONE (e.g., headqrtr.prv)
  4. SYSTEM (e.g., system.prv)

The provisioning files provide the Info Block, which contains all the information you might normally stick in DHCP (or manually configure on the phone if  you’re especially sadistic towards your telecom analysts). The Info Block can also contain information that is not normally provided in the DHCP string (e.g., Node and TN.) After the provisioning block is loaded, the IP phone will load the configuration file to determine how it should obtain firmware and font file updates. At some future point, I might come back and write another article to cover provisioning via HTTP or TFTP, but for now, we’re going to focus on the configuration file and manually upgrading the firmware on an IP phone.

  1. TYPE (e.g., <TYPE>.cfg, or, 1140E.cfg)

The Configuration file can contain a lot of information:

  1. [FW] Set Firmware
  2. [GEM FW] Expansion Module Firmware
  3. [USER_KEYS] User keys
  4. [DEVICE_CONFIG] Device configuration
  5. [IMAGES] Backgrounds and screensavers
  6. [FONTxx] Custom fonts
  7. [LANGUAGE] Language (associated with customized fonts)
  8. [LICENSING] Feature licensing
  9. [DIALING_PLAN] Dialing plan (SIP only?)

We’re going to focus only on the [FW] values in this article.

[FW] Section header for SET FIRMWARE download information.
DOWNLOAD_MODE AUTO Recommended value. Download firmware only if the VERSION on the provisioning server is newer than the version on the phone.
FORCED VERSION of the phone is ingored. Firmware is always downloaded.
VERSION e.g., 0625C8J The VERSION string is compared to what is on the phone. VERSION should match the firmware FILENAME exactly.
FILENAME e.g., 0625C8J.bin Image filename. Must match the filename of the actual IP phone FW file to be downloaded
PROTOCOL TFTP Download protocol. Must be TFTP Documentation for CS1000 7.5 says that this must be TFTP, but the sample CFG files available from AVAYA show that HTTP is supported. Further testing is recommended.
SERVER_IP x.x.x.x IP address of the TFTP server in decimal notation.
SERVER_PORT 0 to 65535 The port used by the TFTP server at SERVER_IP. Optional
SECURITY_MODE 0 For future use

Example 1140E.cfg file:

FILENAME 0625C8J.bin

After placing both the configuration file (e.g., 1140E) and the FILENAME (firmware image) in the root of the TFTP server at SERVER_IP, the next step is to choose the method of configuring the IP Phone to know about the external provisioning server (if you haven’t already done this). The options available are:

While it is possible to configure the DHCP Option 66 to point to an HTTP server (to retrieve the *.prv or *.cfg files), other files must be available via the protocol specified within the *.cfg file. For the purposes of this article, that means a TFTP server is required whether you provide the <TYPE>.cfg via HTTP or TFTP.
  1. DHCP Option 66 – TFTP/HTTP Server Name
  2. DHCP Option Nortel-i2004-B specification
  3. Manually configuring the Provisioning Server on the IP phone.

Select a method and implement it. To keep this article short and focused, we’re going to assume you know how to do this.

Plug in your phone and power it up. Assuming that (your DHCP configuration or manually configured provisioning server is correct and) it is able to reach the provisioning server, it will download the <TYPE>.cfg file from the TFTP/HTTP server, then using the instructions contained within, determine if a firmware download is required and perform that download if necessary.

If you use DOWNLOAD_MODE FORCED, the IP phone will force a download of the firmware each time the phone boots. This will increase the boot time for all IP phones configured to use that <TYPE>.cfg file.

I hope you found this article helpful. If you did, please share it.


Note regarding i2007.cfg file

Early versions of the IP Phone 2007 FW will fail to download newer versions of FW if the [FW] line is present before the FW download information in the .cfg file.

If the FW version currently on the IP Phone 2007 is prior to any version of 0621C4x, then delete the [FW] line. Once the phone has FW version 0621C4x or greater, the [FW] line must be present. Example: Phone has 0621C3A – comment out or delete the [FW] line in the i2007.cfg file Phone has 0621C4J – keep the [FW] line in the i2007.cfg file