Michael McNamara

I'll just use this area to cover anything that really doesn't fit nicely into any of the categories to the left. I will probably just end up a dumping ground but we'll see what starts to show up once I start posting some content.

I'll put on my story hat right here and tell you how it all started (your free to stop reading). When I started with my current employer many years ago we had an ATM based LAN. We were using Nortel Centillion 100 ATM Switches. They were very reliable and rock solid switches providing OC-3 uplinks with 100Mbps and 10Mbps Ethernet connectivity. We had a problem at one or our larger locations (~ 40 ATM switches with ~ 100 Ethernet hubs). We had an issue that would disrupt a large portion of the network for ~ 5 minutes at a time. This problem could happen at any time during the day or night. I never seemed to be at my desk at just the right time to observe this problem from start to finish. By the time the Help Desk received a call the problem was already resolving itself and the switch logs were providing very little information. I needed to be online at the exact time the problem started so I could gather some much needed information (FDB tables, ARP tables, tech dumps, etc) while the problem was occurring. I soon came to realize that I wasn't going to be able to physically accomplish this myself. Why? I wasn't always around when the problem occurred and there just wasn't enough time for me to manually login to all the switches and collect all the necessary data. I remembered a friend from college singing the praises of a programming language called Expect. I wrote a Bash shell script that would call fping with a list of switches (FQDNs) and then if fping returned a value other than 0 I would execute an Expect script to telnet into all 6 core ATM switches. After a week I had some data that pointed me further from the core to a few edge switches so I added those to the Expect script and within a week I had identified the two devices that were causing ATM Packet Reflection, essentially there was a device on the network hijacking the MAC address of the default gateway. We put filters into play to drop all ARP packets from those edge ports that had the source MAC address of the default gateway and the problem was resolved.

Expect

Expect is a great tool that is often overlooked by the vast majority. I've used Expect while troubleshooting a number of high profile problems where I needed to collect switch topology information while a problem was detected or trigger reached (often between 1AM and 4AM and only lasting a few minutes).

From the Expect Homepage "Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc. Expect really makes this stuff trivial. Expect is also useful for testing these same applications." If your looking to learn Expect let me recommend the O'Reilly book "Exploring Expect".

Nortel Succession Voice Over IP (VoIP)

The most asked question by almost everyone these days is, "How do I setup this Nortel Internet Telephone?" I've written many a post on my Blog about how to configure the different components but for a newcomer I can definitely understand how it could be very confusing trying to figure out what needs to be done and in what order. I'm hoping to layout a better roadmap with the following post on this website. I'm going to try and break down the process into steps that will be easier to understand;

1. Nortel Succession Call Server Configuration
2. Nortel Ethernet Routing Switch 5520 Configuration
3. Dynamic Host Configuration Protocol (DHCP) Configuration
4. Nortel i2004 Internet Telephone Configuration

Let me start by saying that I'm assuming you already have some Internet Telephones deployed in your environment. That you have a Nortel Succession Call Server (ELAN), at least one Nortel Succession Signaling Server (ELAN + TLAN) and at least one Nortel Succession Voice Gateway Media Card (ELAN + TLAN) all connected to your network and configured for IP Line (providing VoIP to IP phones) services as opposed to IP Trunk (providing VoIP between Call Servers). You'll also need to confirm that you have an adequate number of ISMs (licenses).

Step 1) Nortel Succession Call Server Configuration

I'll skip this part for right now. Unless you perform daily maintenance along with add, moves and changes of your Call Server you should probably look to have a telecom tech help you configure the TN (Terminal Number) and assign the DN (Dialed Number).

Step 2) Nortel Ethernet Routing Switch 5520 Configuration

Instead of covering the material again I'll just point you to entries in my blog, while trying to fill in the blanks.
  Nortel Ethernet Routing Switch 5520 (PwR) Configuration
  Nortel Ethernet Routing Switch 5520 (PwR) Troubleshooting
You should note that this assumes that you have BoSS v5.0.6 or later on the 5520 switch and firmware 0604DAS or later on the Nortel Internet Telephones.

Step 3) Dynamic Host Configuration Protocol (DHCP)

Instead of covering this material again I'll just point you to entries in my blog, while trying to fill in the blanks.
  DHCP Options (Nortel VoIP)
  DHCP Options (Nortel VoIP) Part 2
You can "get by" with just the basic DHCP information (IP address, subnet mask, default gateway, etc) in order to use the phone. Although you'll need to configure the phone manually with the IP address information of the Nortel Succession Signaling Servers. If you don't have a large number of phones you can probably skip this step. In my environment I have over 150+ in just one building so it's easier to rely on DHCP for this information instead of having the techs manually program this information (which would be different for each facility, each Call Server (Signaling Server).

Step 4) Nortel i2004 Internet Telephone Configuration

As with the past steps I'll just link to the relevant posts in my blog.
  Nortel i2002/i2004 Internet Telephone Configuration
Please note the firmware version requirement on the phone itself. If the phone isn't at firmware 0604DAS or later you'll need to statically configure the IP information and Call Server information on the phone in order to upgrade the firmware by connecting to the Succession (Signaling Server) backend. After the phone is upgraded you can re-configure the phone for full DHCP and utilize LLDP if desired.

I'm happy to field questions about the information above or about problems your having in configuring a similar environment.

Last Updated: Wednesday, December 26, 2007 06:50 PM