Spanning Tree (FastStart / PortFast)

You can’t imagine how many times I’ve seen a patch cable patched from one port on a switch in an IDF back into the same switch. It’s usually a case of sloppy cabling, although I’ve met a quite a few users who thought that both ends of the cable needed to be plugged into the wall plate. In order to prevent such scenarios from spoiling your day you should verify that you have Spanning Tree enabled on all edge ports (ports that face the users). And you should also verify that you have FastStart or PortFast enabled to help eliminate the 30 second delay during STP learning (those of us that used to run IPX/SPX networks with Novell NetWare learned this a long time ago).

BPDU Guard (called BPDU Filtering by some vendors)

In addition to Spanning Tree you should also enable BPDU guard on all your edge ports. This will immediately disable the switchport if it receives a BPDU Spanning Tree frame. This can help mitigate topology loops and it can help prevent your users from plugging in their own switches in their offices or cubicles. There are some scenarios where connecting the PC port on the back of an Avaya IP phone could potentially put a loop into the network. BPDU guard (called BPDU filtering by Avaya) will detect the BPDU frame and disable the port, thereby protecting the network.

Rate Limiting (Broadcast / Multicast)

If your in the networking field long enough you’ll eventually see some really odd behavior from one or more devices. I’ve seen my fair share of oddities and eventually you’ll run across a few too. You should prepare for that eventuality today by configuring broadcast and Multicast rate limiting on your edge ports. This helps prevent any single device from flooding too many broadcast or Multicast packets into your network which could impact either other devices connected to the network or the network itself.

You’re already doing each of the previously listed items? Well you could look at the following additional steps. You can find additional detail in a blog post titled, DHCP Snooping ARP Inspection IP Source Guard.

DHCP Snooping

Dynamic Host Configuration Protocol (DHCP) snooping provides security to the network by preventing DHCP spoofing. DHCP spoofing refers to an attacker’s ability to respond to DHCP requests with false IP information. DHCP snooping acts like a firewall between untrusted hosts and the DHCP servers, so that DHCP spoofing cannot occur. There are 2 types of ports in DHCP snooping, trusted and untrusted. The network will only allow DHCP responses from trusted ports – usually uplinks as opposed to allowing DHCP responses from untrusted ports – usually edge switch ports.

DHCP Option 82 – With DHCP Option 82 the switch will append additional information to the DHCP request which can be stored and captured by your DHCP server (or your IP Address Management solution) to help identify the switch and port from which the request was initiated.

ARP Inspection

Dynamic Address Resolution Protocol Inspection (DAI) is a security feature that validates ARP packets in the network.

Without dynamic ARP inspection, a malicious user can attack hosts, switches, and routers connected to the Layer 2 network by poisoning the ARP caches of systems connected to the subnet and by intercepting traffic intended for other hosts on the subnet. Dynamic ARP inspection prevents this type of attack. It intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings.

The address binding table is dynamically built from information gathered in the DHCP request and reply when DHCP snooping is enabled. The MAC address from the DHCP request is paired with the IP address from the DHCP reply to create an entry in the DHCP binding table.

When you enable Dynamic ARP inspection, ARP packets on untrusted ports are filtered based on the source MAC and IP addresses stored in the DHCP snooping table. The switch forwards an ARP packet when the source MAC and IP address matches an entry in the DHCP snooping table. Otherwise, the ARP packet is dropped.

IP Source Guard

IP Source Guard provides security to the network by filtering clients with invalid or spoofed IP addresses. IP Source Guard is a Layer 2 (L2), port-to-port feature that works closely with information in the Dynamic Host Control Protocol (DHCP) snooping binding table. When you enable IP Source Guard on an untrusted port with DHCP snooping enabled, an IP filter entry is created or deleted for that port automatically, based on IP information stored in the corresponding DHCP binding table entry. When a connecting client receives a valid IP address from the DHCP server, a filter is installed on the port to allow traffic only from the assigned IP address. A maximum of 10 IP addresses are allowed on each IP Source Guard-enabled port. When this number is reached, no more filters are set up and traffic is dropped.

While Dynamic ARP Inspection blocks only ARP packets, IP Source Guard blocks all IP packets.

Cheers!
Image Credit: The Lánchid Bridge in Budapest Hungary at nightfall by Abel Leemans

• MotorolaRFS.RFS7000 (RFS7000)
• MotorolaRFS.RFS6000 (RFS6000)
• MotorolaRFS.RFS4000 (RFS4000)
• MotorolaAP.AP7131 (AP7161)
• MotorolaAP.AP7131 (AP7131)
• MotorolaAP.AP650 (AP650)
• MotorolaAP.AP621 (AP621)
• MotorolaAP.AP6521 (AP6521)
• MotorolaAP.AP6532 (AP6532)
• MotorolaAP.AP6511 (AP6511)

The APs will try to associate via a Layer 2 broadcast with a controller, if they fail to adopt via Layer 2 they will issue a a DHCP request with the vendor class IDs listed above.

This is really helpful in your IPAM or DHCP server, you can define specific pools based on the vendor class to return very specific DHCP options. In this case you would probably want to return DHCP option 189 (string) with the IP address of the wireless LAN switch. You can include multiple IPs separated by commas.

Cheers!

I’ve recently started implementing DHCP Snooping, Dynamic ARP Inspection and IP Source Guard in my networks so I thought I’d take the time to strike up a conversation around those features and hear what everyone else is doing.

These features are all intended to provide a more stable network environment and help protect against intentional and unintentional events that can interfere with the proper operation of the network. Before we can implement any of these features we need to understand how they work and what changes (if any) will be needed to support them.

Hopefully most people have Spanning Tree, FastStart, BPDU filtering (guard) and Broadcast/Multicast rate limiting enabled by now but if you don’t you should certainly look at enabling and configuring those features before you start to try any of the ones I’m about to discuss.

The sample configuration code provided below is applicable for Avaya Ethernet Routing Switches.

DHCP Snooping

Dynamic Host Configuration Protocol (DHCP) snooping provides security to the network by preventing DHCP spoofing. DHCP spoofing refers to an attacker’s ability to respond to DHCP requests with false IP information. DHCP snooping acts like a firewall between untrusted hosts and the DHCP servers, so that DHCP spoofing cannot occur. There are 2 types of ports in DHCP snooping, trusted and untrusted. The network will only allow DHCP responses from trusted ports – usually uplinks as opposed to allowing DHCP responses from untrusted ports – usually edge switch ports.

Example, if someone brings a Linksys router into the office and connects the LAN side to your network the Linksys router will start handing out 192.168.1.x IP DHCP addresses which will likely cause some chaos. DHCP Snooping will prevent those DHCP responses from poisoning your network. I’m happy to admit that this is happened to me on more than one occasion, usually at our remote finance office where auditors think their second job could be in Information Technology.

DHCP Option 82 – With DHCP Option 82 the switch will append additional information to the DHCP request which can be stored in your IPAM (IP Address Management) solution to help identify the switch and port from which the request was initiated. This can provide diagnostic and troubleshooting information which can all be stored directly in your IPAM if it supports DHCP Option 82. Infoblox supports DHCP Option 82.

The latest software releases support the ability to copy the DHCP binding table up to a TFTP server. This prevents the switch from throwing away all the previously learned DHCP transactions between reboots or restarts of the switch.

In this example our uplinks are 1/24 and 2/24, all interfaces are untrusted by default.

ip dhcp-snooping vlan 10
ip dhcp-snooping vlan 11
ip dhcp-snooping enable

interface fa 1/24,2/24
 ip dhcp-snooping trusted
exit

If you want to enable DHCP Option 82 support;

ip dhcp-relay option82
interface vlan 10
 ip dhcp-relay option82
interface vlan 11
 ip dhcp-relay option82

You can also edit the text string the switch will append per port with the following;

interface FastEthernet 1
 ip dhcp-relay option82-subscriber-id <string 1..255>

Issues with DHCP Snooping

While you need to properly identify trusted and untrusted ports there are very few draw backs to utilizing DHCP snooping. It only prevents DHCP replies from untrusted ports essentially preventing DHCP spoofing in the network. DHCP Snooping can be enabled in most networks with a few configuration changes and very little danger (impact).

Dynamic ARP Inspection

Dynamic Address Resolution Protocol (Dynamic ARP) inspection is a security feature that validates ARP packets in the network.

Without dynamic ARP inspection, a malicious user can attack hosts, switches, and routers connected to the Layer 2 network by poisoning the ARP caches of systems connected to the subnet and by intercepting traffic intended for other hosts on the subnet. Dynamic ARP inspection prevents this type of attack. It intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings.

The address binding table is dynamically built from information gathered in the DHCP request and reply when DHCP snooping is enabled. The MAC address from the DHCP request is paired with the IP address from the DHCP reply to create an entry in the DHCP binding table.

When you enable Dynamic ARP inspection, ARP packets on untrusted ports are filtered based on the source MAC and IP addresses stored in the DHCP snooping table. The switch forwards an ARP packet when the source MAC and IP address matches an entry in the DHCP snooping table. Otherwise, the ARP packet is dropped.

For dynamic ARP inspection to function, DHCP snooping must be globally enabled. Dynamic ARP inspection is configured on a VLAN to VLAN basis.

Let’s enable Dynamic ARP Inspection on VLANs 10, 11 and set our uplinks as trusted;

ip arp-inspection vlan 10
ip arp-inspection vlan 11
ip arp-inspection enable

interface fa 1/24,2/24
 ip arp-inspection trusted
exit
interface fa 1/1-23,2/1-23
 ip arp-inspection untrusted
exit

Issues with Dynamic ARP Inspection

Dynamic ARP Inspection relies on the information stored in the DHCP binding table (from DHCP Snooping) to validate the ARP packets it receives on untrusted ports. Any device whether it be statically configured or dynamically configured would need to appear in the DHCP binding table.

If you have a statically configured device you’ll need to manually populate the DHCP snooping table. If someone changed out a statically configured device the MAC address would most likely need to be updated in the DHCP binding table. If the DHCP binding table was accidentally cleared the switch would block IP traffic until the DHCP binding table was re-built either manually or from DHCP transactions.

This is another great reason to use manual or reserved DHCP assignments where possible if the device requires a persistent IP address.

This feature will likely create some significant administrative overhead based on the number of devices configured with a static IP address over the number of DHCP configured devices.

IP Source Guard

IP Source Guard provides security to the network by filtering clients with invalid or spoofed IP addresses. IP Source Guard is a Layer 2 (L2), port-to-port feature that works closely with information in the Dynamic Host Control Protocol (DHCP) snooping binding table. When you enable IP Source Guard on an untrusted port with DHCP snooping enabled, an IP filter entry is created or deleted for that port automatically, based on IP information stored in the corresponding DHCP binding table entry. When a connecting client receives a valid IP address from the DHCP server, a filter is installed on the port to allow traffic only from the assigned IP address. A maximum of 10 IP addresses are allowed on each IP Source Guard-enabled port. When this number is reached, no more filters are set up and traffic is dropped.

While Dynamic ARP Inspection blocks only ARP packets, IP Source Guard blocks all IP packets.

interface fa 1/1-23,2/1-23
 ip verify source
exit

Issues with IP Source Guard

IP Source Guard utilizes the information stored in the DHCP binding table (from DHCP Snooping) to validate the IP traffic. Any device whether it be statically configured or dynamically configured would need to appear in the DHCP binding table. Statically configured devices would need to be manually placed in the DHCP binding table. If someone changed out a device the MAC address would most likely need to be updated in the DHCP binding table. If the DHCP binding table was accidentally cleared the switch would block IP traffic until the DHCP binding table was re-built either manually or from DHCP transactions.

This feature will likely create some significant administrative overhead based on the number of devices configured with a static IP address over the number of DHCP configured devices.

My Thoughts

I’m taking a split approach right now, let me explain. I’ll be utilizing DHCP snooping and DHCP Option 82 throughout my network. Unfortunately due to the administrative overhead required to leverage Dynamic ARP Inspection and IP Source Guard I’m only planning on implementing those features at my smaller remote offices – the ones I usually have issues with from a security perspective. Since those remote offices are much smaller and usually don’t make too many changes it offers me the opportunity to evaluate the new features without over taxing my network administrators and engineers.

Cheers!

I do most of my work with CentOS and RedHat Linux because those are the distributions that my organization supports internally (even if I’m one of two people that support Linux across the entire organization). In this case I was working with a CentOS 5.7 server but I was having an issue compiling and installing the Infoblox Perl modules.

LWP::UserAgent version 5.813 required–this is only version 2.033

When I attempted to compile the Infoblox Perl modules I received the following errors;

LWP::UserAgent version 5.813 required--this is only version 2.033 at /usr/lib/perl5/site_perl/5.8.8/Infoblox/Agent.pm line 3.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Infoblox/Agent.pm line 3.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Infoblox/Session.pm line 19.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Infoblox/Session.pm line 19.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Infoblox.pm line 8.
BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.8/Infoblox.pm line 8.
Compilation failed in require at ./ibcli.pl line 78.
BEGIN failed--compilation aborted at ./ibcli.pl line 78.

This was with Perl 5.8.8 on CentOS 5.7 x64, unfortunately it seems this is a known issue with the version of LWP::UserAgent that is currently being distributed via the CentOS repository.

I was able to spin up a new CentOS 6.0 x86 server which was running Perl 5.10.1 and didn’t experience this problem.

The installation was pretty straight forward (except for the issue above) but the API reference manual does a very thorough job of detailing all the possible installation methods on both Windows and Unix/Linux. I just opened a browser to one of the Infoblox appliances and downloaded the Perl modules.

https://10.1.1.1/api/dist/CPAN/authors/id/INFOBLOX/

Just replace the IP address of 10.1.1. with the IP address of your Infoblox appliance. I’m not sure why Infoblox hides their manuals behind their support portal, I just don’t understand why companies do that.  You can find the manual right here, Infoblox_API_Documentation_6.1.0.pdf.

Cheers!

If time allows I hope to post an update in the very near future covering the new Nortel-i2004-B option string. While working with the SIP 4.0 software release in the past few articles I did learn that the Avaya SIP IP phones can utilize a new DHCP vendor class, Nortel-SIP-Phone-A which can allow you a little flexibility when configuring them via DHCP and TFTP.

In the same file below I setup four DHCP scopes; one for 2111/2212/6020/6040 wireless handsets, one for i2002/i2004/1100/1200 series IP phones, one for 1100/1200 series IP phones running SIP and one for all other devices (laptops, desktops, etc). Just a quick note about the example below, you’ll notice that I have no pools in the 192.168.1.0/24 network. All the pools are in the 192.168.25.0/24 network.

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#
# Sample dhcpd.conf file for Avaya (legacy Nortel) IP Phones
#
# Notes: example dhcpd.conf file to illustrate how to configure Avaya
# IP Phones with specific DHCP options for 2000/1100/1200 series IP
# Phones and the 2200/6100 series Wireless IP Phones.
#
# *** WARNING *** WARNING *** WARNING *** WARNING ** WARNING ***
#
# This is just an sample file with specific IP information. You'll
# need to customize this file to your specific IP address scheme
# before you can use it in your environment.
#
# *** WARNING *** WARNING *** WARNING *** WARNING ** WARNING ***
#

ddns-update-style none;
not authoritative;

option nortel-callserver code 128 = string;
option nortel-2245 code 151 = ip-address;
option tftp-server-name "192.168.1.20";

# Vendor Class for i2002/i2004/1120e/1140e/1150e Internet Telephones
class "Nortel-i2004-A" {
  match if substring (option vendor-class-identifier, 0, 14) = "Nortel-i2004-A";
    option nortel-callserver "Nortel-i2004-A,192.168.200.2:4100,1,5;192.168.200.2:4100,1,5.";
    option vendor-class-identifier "Nortel-i2004-A";
}

# Vendor Class for 2210/2211 Wireless Phones
class "Nortel-221x-A" {
  match if substring(option vendor-class-identifier, 0, 13) = "Nortel-221x-A";
    option nortel-callserver "Nortel-i2004-A,192.168.200.2:4100,1,5:192.168.200.2:4100,1,5.";
    option nortel-2245 192.168.99.10;
    option vendor-class-identifier "Nortel-221x-A";
}

# Vendor Class for Avaya 1100/1200 IP SIP Phones (SIP firmware loaded)
class "Nortel-SIP-Phone-A" {
  match if substring(option vendor-class-identifier, 0, 18) = "Nortel-SIP-Phone-A";
    option vendor-class-identifier "Nortel-SIP-Phone-A";
}

# Network Definition
shared-network "mynetwork" {
   subnet 192.168.1.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option routers 192.168.1.1;
   option domain-name "home";
   option domain-name-servers 192.168.0.1;
   next-server 192.168.1.20;
   default-lease-time 28800;
   max-lease-time 86400;
   }
}

# Network Definition 192.168.25.0/24
shared-network "192-168-25-0" {
   subnet 192.168.25.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option routers 192.168.25.1;
   option domain-name "home";
   option domain-name-servers 192.168.1.1;
   next-server 192.168.1.20;
   default-lease-time 28800;
   max-lease-time 86400;

   # IP Address Pool for generic devices
   pool {
      range 192.168.25.50 192.168.25.100;
      deny members of "Nortel-i2004-A";
      deny members of "Nortel-221x-A";
      deny members of "Nortel-SIP-Phone-A";
   }

   # IP Address Pool for i2002/i2004/1120e/1140e/1150e
   pool {
      range 192.168.25.150 192.168.25.175;
      allow members of "Nortel-i2004-A";
      deny members of "Nortel-221x-A";
      deny members of "Nortel-SIP-Phone-A";
   }

   # IP Address Pool for 2210/2211
   pool {
      range 192.168.25.176 192.168.25.199;
      allow members of "Nortel-221x-A";
      deny members of "Nortel-i2004-A";
      deny members of "Nortel-SIP-Phone-A";
      }

   # IP Address Pool for Avaya 1100/1200 IP SIP Phones
   pool {
      range 192.168.25.200 192.168.25.224;
      allow members of "Nortel-SIP-Phone-A";
      deny members of "Nortel-i2004-A";
      deny members of "Nortel-221x-A";
      }

 }
}

Cheers!

I had to spend more than a few minutes trying to get the DHCP relay working on the SRX 210. The configuration was pretty straight forward, the trick in the end was the “vpn” statement (see below) that allows the DHCP/BOOTP packets to be relayed across a VPN tunnel. Please note that the DHCP server at 10.1.1.1 is accessible via the VPN tunnel.

forwarding-options {
 helpers {
  bootp {
   relay-agent-option;
   description "Branch DHCP Relay";
   server 10.1.1.1;
   maximum-hop-count 10;
   minimum-wait-time 1;
   vpn;
   interface {
    vlan.0;
   }
  }
 }
}

The next big step will be deploying OSPF between all the SRX gateways.

Cheers!

In one of my first blog posts entitled “DHCP Options (VoIP)” I outlined the DHCP options and the format that the phone expected. Kenneth quickly pointed out that I had fat-fingered the example DHCP string omitting the semicolon between the values for the primary Call Server (S1) and the secondary Call Server (S2). (I’ve since fixed the original post)

Here’s the format the DHCP option code 128 which the IP phones expects to be returned from the DHCP server when the IP phone is configured for “Full DHCP”;

Nortel-i2004-A,iii.iii.iii.iii:ppppp,aaa,rrr;iii.iii.iii.iii:ppppp,aaa,rrr.

Where the following values are;

• “Nortel-i2004-A” = Option #128 begins with this string for all Nortel IP phones
• “iii.iii.iii.iii” = the IP Address of the Call Server (S1 or S2)
• “ppppp” = port number for the Call Server
• “aaa” = the Action for the Server
• “rrr” = the Retry Count for the Server

The IP Address must be separated from the port number by a colon (:). The parameters for the Primary (S1) and the Secondary (S2) Call Servers are separated by a semicolon (;). The string must end a period (.).

If you are using an ISC DHCP server (this is generally included with any of the Linux distributions) you can refer to my article entitled “ISC DHCP Server (Nortel VoIP)” for information on how to setup and configure the ISC DHCP server to work with Nortel IP Telephony.

Cheers!

Update: Wednesday January 28, 2009

I just came across a “DHCP Parse Error” that actually had nothing to-do with the DHCP string. We had a phone that was using the same DHCP template as 9 other i2002 phones but it was displaying “DHCP Parse Error” when it booted up (this only surfaced after we upgraded to 0604DCG). The phone was actually configured incorrectly. It was suppose to be configured for a Voice VLAN and configured to get the Voice VLAN via LLDP-MED. The LLDP-MED option had been left set at “0” (disabled) so the phone was trying to make a DHCP request looking for Option 191 while the DHCP server was only configured to return Option 128 as detailed above. It only took a few minutes to fix but I can see how someone could spend hours stuck on this.

Cheers!

I will admit that I really don’t use the ISC DHCP server these days. We’ve been using Lucent’s VitalQIP IP Management software to manage our internal BOOTP/DHCP/DNS/DDNS needs for the past 10 years.

However, since there was so much interest I decided to setup a lab (at home) with a i2002 phone and a server running CentOS v5.0. I installed dhcp-3.0.5-7.el5 via YUM and came up with a sample dhcpd.conf file that anyone should be able to modify to meet their specific needs.

#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#
# Sample dhcpd.conf file for Nortel Internet Telephony
#
# Notes: example dhcpd.conf file to illustrate how to configure Nortel
# Internet Telephone specific DHCP options for i2002/i2004 Internet
# Telephones and 2210/2211 Wireless Phones.
#
# *** WARNING *** WARNING *** WARNING *** WARNING ** WARNING ***
#
# This is just an sample file with specific IP information. You'll
# need to customize this file to your specific IP address scheme
# before you can use it in your environment.
#
# *** WARNING *** WARNING *** WARNING *** WARNING ** WARNING ***
#

ddns-update-style none;
not authoritative;

option nortel-callserver code 128 = string;
option nortel-2245 code 151 = ip-address;

# Vendor Class for i2002/i2004/1120e/1140e/1150e Internet Telephones
class "Nortel-i2004-A" {
match if substring (option vendor-class-identifier, 0, 14) = "Nortel-i2004-A";
option nortel-callserver "Nortel-i2004-A,192.168.200.2:4100,1,5;192.168.200.2:4100,1,5.";
option vendor-class-identifier "Nortel-i2004-A";
next-server 192.168.0.10;
}

# Vendor Class for 2210/2211 Wireless Phones
class "Nortel-221x-A" {
match if substring(option vendor-class-identifier, 0, 13) = "Nortel-221x-A";
option nortel-callserver "Nortel-i2004-A,192.168.200.2:4100,1,5:192.168.200.2:4100,1,5.";
option nortel-2245 192.168.200.25;
option vendor-class-identifier "Nortel-221x-A";
next-server 192.168.0.10;
}

# Network Definition
shared-network "mynetwork" {
 subnet 192.168.0.0 netmask 255.255.255.0 {
 option subnet-mask 255.255.255.0;
 option routers 192.168.0.1;
 option domain-name "acme.org";
 option domain-name-servers 192.168.0.1;
 default-lease-time 28800;
 max-lease-time 86400;

   # IP Address Pool for generic devices
   pool {
      range 192.168.0.50 192.168.0.100;
      deny members of "Nortel-i2004-A";
      deny members of "Nortel-221x-A";
   }

   # IP Address Pool for i2002/i2004/1120e/1140e/1150e
   pool {
      range 192.168.0.150 192.168.0.175;
      allow members of "Nortel-i2004-A";
      deny members of "Nortel-221x-A";
   }

   # IP Address Pool for 2210/2211
   pool {
      range 192.168.0.176 192.168.0.199;
      deny members of "Nortel-i2004-A";
      allow members of "Nortel-221x-A";
      }
 }
}

In the example above I setup two DHCP scopes; one for the standard hardwired Nortel Internet Telephones (Nortel-i2004-A) and another for the Nortel Wireless Phones (Nortel-221x-A). Hopefully this example should be fairly easy to follow just remember to edit all the site specific IP information.

Cheers!

The latest release of firmware for the AP300 will first attempt to locate a wireless switch for adoption via a Layer 2 broadcast request. If it’s unable to locate a wireless switch it will make a DHCP request for an IP address. If the DHCP response does not include option 189 (string) it will make a DNS request to try and locate the wireless switch.

There are two ways the Access Port can locate the Wireless LAN Switch (WS5100/RFS7000) in Layer 3 mode;

• DHCP Option
• DNS Query

You can use DHCP and configure option 189 (string) with the IP address of the Motorola Wireless LAN Switch. You should note that you may need to enclose the string in quotation marks depending on your DHCP server software.

You can also create a DNS alias which the AP can use to locate the switch through a DNS query. The default DNS name requested by an AP300 is “Symbol-CAPWAP-Address”.

You might also notice that the AP300 will also support LLDP (802.1ab) if your Ethernet switch supports it.

Cheers!

Update: August 27, 2008
I should point out that you may need to “prime” the AP300 with the latest firmware by connecting it to a WS5100/RFS7000 over a Layer 2 network. If the AP300 has an older firmware it won’t be able to connect up over a Layer 3 network so you may need to connect it over a Layer 2 network first to allow the AP300 to upgrade after which you’ll be able to connect it over a Layer 2/3 network. The AP300 will automatically upgrade once it connects to the WS5100/RFS7000, there’s nothing that needs to be done by the user or administrator. The WS5100/RFS7000 will need to be running v3.x or v1.x respectively.

Cheers!

If you don’t have a switch that supports ADAC/LLDP you can still utilize automatic VLAN assignment using DHCP. I’ve actually used this method (before Nortel supported LLDP) and it works well but can sometimes be difficult to troubleshoot.

You’ll need to configure DHCP option 191 (string) with the following syntax;

VLAN-A:vvvv.

Where: “VLAN-A” Option 191 begins with this string for all Nortel IP phones.
“vvvv” The VLAN ID for the voice VLAN in decimal
Here’s an example if I were trying to assign the phones with a voice VLAN of 31;

VLAN-A:31.

There must be a colon (:) seperating the VLAN-A from the VLAN ID. The string must also end in a period. It may be necessary, depending on your DHCP server, to enclose the enter string in quotation marks.

How does it actually work?
With the phone and DHCP server configured properly here’s how it will work.

1. The phone will boot up and make a DHCP request for option 191 in the Default VLAN of the port connecting the phone.
2. If the phone receives a response to it’s request it will issue a DHCP Release of the address it received in Step 1.
3. The phone will make a second DHCP request in the VLAN that was returned in option 191. The phone will be requesting DHCP option 128 from the DHCP server, this will include the Call Server information. (Note: if you use a sniffer you will see that the DHCP packets will have an 802.1q header with the appropriate VLAN ID)
4. The phone will connect to the Call Server specified in DHCP option 128 and will prompt the user for the Node ID and TN information.

With all that said we did leave out one very important piece of the pie… the network switch configuration. You’ll need to configure the VLAN and QoS settings manually depending on the switch vendor.

Cheers!

You’ll need to add a custom vendor DHCP option with a code of “128” as a string value. You should name this DHCP option as “Call Server Information”. The value of this DHCP option will use the following format;

Nortel-i2004-A,iii.iii.iii.iii:ppppp,aaa,rrr;iii.iii.iii.iii:ppppp,aaa,rrr.

Where the following values are;

• “Nortel-i2004-A” = Option #128 begins with this string for all Nortel IP phone sets
• “iii.iii.iii.iii” = the IP Address of the Call Server (S1 or S2)
• “ppppp” = port number for the Call Server
• “aaa” = the Action for the Server
• “rrr” = the Retry Count for the Server

The IP Address must be separated from the port number by a colon (:). The parameters for the Primary (S1) and the Secondary (S2) Call Servers are separated by a semicolon (;). The string must end a period (.).

For this example, enter the following:

Nortel-i2004-A,10.1.1.10:4100,1,5;10.1.1.20:4100,1,5.

This would equate with the following values;

• Call Server S1 = 10.1.1.10
• Port S1= 4100
• Action S1= 1
• Retry S1= 5
• Call Server S2 = 10.1.1.20
• Port S2 = 4100
• Action S2 = 1
• Retry S2 = 5

You can use the vendor class of “Nortel-i2004-A” if you’d like to build different scopes within your DHCP server. A default scope for all general devices and then a specific scope for any device that requests the vendor class of “Nortel-i2004-A”.

Let me make this comment… if your DHCP server mistakenly returns a DHCP response that does NOT include DHCP Option 128 the IP phone will just sit at the “Starting DHCP…” prompt. You need to make sure that you return DHCP Option 128 in the DHCP response to the phone.

This all assumes that you’ve setup a DHCP relay on the Voice VLAN on the core ERS 8600 switch or whichever switch you might be using as the router for that VLAN.

I’ll review the basic configuration of the ERS 8600 (core) in a subsequent post as it applies to the example configuration I’ve laid out in the past few posts.

Please feel free to drop a line if you have questions.

Cheers!

Here’s a picture of the Nortel i2002 Internet Telephone.

• 4×24 Character LCD
• Headset Jack
• Handsfree speaker phone
• 802.3af PoE (Class 2)
• Internal Switch (10/100Mbps)
• XAS (Application Gateway) support

Here’s a picture of the Nortel i2004 Internet Telephone.

• 8×24 Character LCD
• Headset Jack
• Handsfree speaker phone
• 802.3af PoE (Class 2)
• Internal Switch (10/100Mbps)
• XAS (Application Gateway) support

You can see that both phones are fairly similar and they run the same software/firmware. We use a single CAT5e/CAT6 cable drop to connect the phone and then connect the end-user’s desktop/laptop to the PC port on the phone. We employ QoS to guarantee that the voice VLAN gets the appropriate priority and queuing over the data VLAN.

How do you get started?

I will outline how we configure the i2002/i2004 phones for LLDP (Link Layer Discovery Protocol / 802.1ab) and LLDP-MED for the voice VLAN assignment. We configure every phone with the same configuration throughout the enterprise. We rely on LLDP and DHCP to provision the phones with site specific information such as voice VLAN, IP address, Succession Call Server, etc.
You can of course statically configure all that information into the phone manually but then you’d need to visit the phone anytime you needed to make a change and if you had to replace a phone you’d need to re-program it to match the original settings (assuming you had them documented somewhere).

As of August 3, 2007 the phones are shipping with firmware 0604D31. This firmware does NOT support LLDP and will not have an option to enable LLDP. In order to properly deploy LLDP on the Nortel i2002/i2004 Internet telephones you’ll need to be running firmware 0604DBG or later. In order to upgrade the phone you’ll need to get it to connect to the Call Server (that means you’ll probably need to static the configuration through the phone). Once the phone connects to the Call Server it will automatically pull down the latest firmware that has been installed on the Call Server.

If you don’t have a PoE (Power over Ethernet) switch you’ll need to use a power supply to power the phone. As the phone is booting you’ll need to strike the four soft buttons at the bottom of the display window while the text “Nortel Networks” is being displayed. This will allow you to confirm that the phone is configured properly from the factory.

You should configure the i2002/i2004 IP phone as follows; (depending on what version of firmware is installed on the phone you might not see all the options below)

• EAP Enable? [1=Y, 0=N]: 0 (Default – no EAP authentication)
• LLDP Enable? [1=Y, 0=N]: 1 (we are going to need LLDP)
• DHCP? [0-No, 1-Yes]: 1 (we are going to need DHCP)
• DHCP: 0-Full, 1-Partial: 0 (we want to get a full DHCP response)
• Speed[0-A,1-10,2-100]: 0 (Auto negotiation)
• Cfg XAS? [0-No, 1-Yes]: 0 (Default – we don’t use XAS)
• Voice 802.1Q[0-N,1-Y]: 1 (Default – mark voice VLAN pakcets with 802.1Q tags)
• Voice VLAN? [0-N, 1-Y]: 1 (we want a Voice VLAN since we’ll be attaching a PC to the PC port)
• VLAN Cfg? 0- Auto, 1-Man: 0 (Automatically configure the Voice VLAN)
• LLCP MED? 0-No, 1-Yes: 1 (Voice VLAN will be configured using LLDP-MED)
• LANFILTER? [0-No, 1-Yes]: 1 (filter Voice VLAN packets from the PC port)
• Ctrl pBits[0-7,8-Au]: 8
• Media pBits[0-7,8-Au]: 8
• PC Port? [0-OFF, 1-ON]: 1 (Default – leave PC port enabled)
• Speed[0-A,1-10,2-100]: 0 (Default – leave Autonegotiation enabled on PC port)
• Data 802.1Q[0-N,1-Y]:1 (Default – mark data VLAN packets with 802.1Q tags)
• DATA VLAN? [0-N, 1-Y]: 0 (Default – we’re going to use the PVID on the switch port)
• Data pBits[0-7,8-Au]:8
• PCUntagAll? 0-No, 1-Yes: 0
• DUPLEX [0-AUTO, 1-FULL]: 0
• GARP Ignore? [0-No, 1-Yes]: 0
• PSK SRTP? [0-No, 1-Yes]: 0 (Default – you can encrypt the RTP stream if necessary)

If everything has been setup and configured properly (including the Call Server, network switch, DHCP server, etc) the phone will boot and will prompt you for a “Node Number” and “TN”.

I’ve jumped the gun by telling you how to configure the phone before configuring all the back-end equipment, including the Nortel Ethernet Routing Switch 5520 PwR and the DHCP server. In my next installment I’ll cover how to configure the Nortel Ethernet Routing Switch 5520 PwR and what you’ll need to configure in your DHCP server.

Troubleshooting

If the phone hangs with “Starting DHCP…” on the display for more than 60 seconds you’ll need to start troubleshooting. You’ll need to confirm that the phone is configured properly and you’ll need to confirm that it’s grabbing the proper IP address from the DHCP server. Just remember that the MAC address can be found on the back of the phone.

Cheers!