Need help with Avaya IP phones

[Andrew M Stemen]

The physical interconnect has a lot to do with how your Avaya phones
need to be configured. Do they have their own dedicated switch ports? If
so, what VLAN configuration is assigned to the port? Also, in the config
that you posted, you have option-176 set incorrectly. L2QVLAN should
*always* reflect the voice VLAN ID, not the ID of the VLAN in which it
is currently receiving configuration. In your example, you should always
use L2QVLAN=101.

Below is a revised example of a config currently in production at one of
my sites. The Avaya 96xx phones are connected to Cisco Catalyst
switches, and there is either no or 1 data device plugged into the
switch port on the back of each phone. Be advised that as we use only
96xx phones, we use option-242. If you use older phones (46xx, I
believe), you will need to use option-176. I've read that it will not
cause any conflicts on either 46xx or 96xx phones to receive both
options 176 and 242. Be advised that my experience reflects only 96xx
behavior; not everything is the same with 46xx. For example, 96xx uses
HTTPSRVR, and I believe that 46xx uses TFTPSRVR.

Also, my example below references HTTPSRVR. At
HTTPSRVR/46xxsettings.txt, make sure that there are no options
overriding default VLAN behavior.

Now, regarding phone boot behavior. If the phone has ever successfully
booted on a particular VLAN, it will continue to try booting only on
that VLAN (it will, by default, tag its packets with that VLAN number)
until either the phone's config is cleared or an internal timer expires
(which, I believe, can be configured by 46xxsettings). If the timer
expires, or the phone has never successfully booted using a particular
VLAN, it will request an IP from the DHCP server without tagging packets
-- which, in my case, is the data VLAN. Once it has an IP address on the
data VLAN, it looks for option-242's L2QVLAN parameter. It then releases
the IP address from the data VLAN, begins tagging its packets with the
VLAN ID specified in L2QVLAN, and requests another IP address. After it
has received the option-242 from the voice VLAN, it will begin
configuring itself (downloading firmware and config from HTTPSRVR, and
eventually connecting to MCIPADD). 

Also, it comes to mind that, by default, these phones do not honor lease
expiry in the event that it cannot renew its lease. Check 46xxsettings
for more detail; I've configured my phones to honor expiry.

dhcpd.conf:

authoritative;
server-identifier 10.10.0.5;
ddns-update-style none;
option option-242 code 242 = string;
option time-offset -18000;
option ntp-servers 10.10.0.11;

shared-network crth-data {

        default-lease-time 14400;
        max-lease-time 14400;
        option domain-name-servers 10.10.0.10;
        option domain-name "internalzonename.tld";
        option option-242
        "L2QVLAN=20,MCIPADD=10.20.0.13,10.20.72.13,MCPORT=1719,HTTPSRVR=10.10.0.6";

        subnet 10.10.0.0 netmask 255.255.252.0
        {
                option routers 10.10.0.1;
                option subnet-mask 255.255.252.0;
        }

        pool {
                range 10.10.1.1 10.10.3.239;
        }

}

shared-network crth-voice {

        default-lease-time 86400;
        max-lease-time 172800;
        option domain-name-servers 10.10.0.10;
        option domain-name "internalzonename.tld";
        option option-242
        "L2QVLAN=20,MCIPADD=10.20.0.13,10.20.72.13,MCPORT=1719,HTTPSRVR=10.10.0.6";

        subnet 10.20.0.0 netmask 255.255.252.0
        {
                option routers 10.20.0.1;
                option subnet-mask 255.255.252.0;
        }

        pool {
                range 10.20.1.1 10.20.2.254;
        }

}

Catalyst Config:

vlan 2
 name COURTHOUSE_DATA
vlan 20
 name VOIP

interface FastEthernet5/0/47
 description PORT FOR PHONE AND PC
 switchport access vlan 2
 switchport voice vlan 20
 mls qos trust dscp
 spanning-tree portfast

interface FastEthernet5/0/48
 description DHCP SERVER
 switchport trunk encapsulation dot1q
 switchport mode trunk
 mls qos trust dscp
 spanning-tree portfast

---
Andrew Michael Stemen
andrew at andrewmstemen.net