Tellabs 1000 Craft Interface Guide

Getting Into the Craft Terminal on Tellabs 1000 Equipment

The craft interface on Tellabs 1000 is how you actually talk to the system. Serial connection, DCP protocol, and a command set that dates back to the late 90s. I used to pull my hair out trying to remember which command pulled alarm history versus just current alarms. Learned the hard way that they are not the same thing and mixing them up wastes time during an outage. You connect via a standard RS-232 serial cable to the craft port on the shelf. Most people use a USB-to-serial adapter these days since modern laptops don't come with DB9 ports anymore. The catch is that cheap adapters cause issues more often than you'd think. I had a whole provisioning session fail because the FTDI chip in my adapter wasn't enumerating correctly. Swapped it for a StarTech unit and the problem disappeared immediately.

Download the Tellabs 1000 Craft Interface Guide

The official documentation lives on the Nokia support site now since Nokia acquired Alcatel-Lucent who acquired Lucent who originally owned the Tellabs 1000 line. Search for "Tellabs 1000 craft interface guide" on the Nokia Business Support portal and you should find the relevant documents. Sometimes they hide it under the "Alcatel-Lucent" category rather than Tellabs, so if your search returns nothing try that angle. The guide itself is massive. Multiple volumes covering everything from shelf-level maintenance to traffic management commands. Volume 1 is usually the entry point. It walks through login procedures, basic navigation, and the command structure. I keep a PDF copy bookmarked rather than reading it cover to cover because you never need the whole thing at once. One thing the guide doesn't emphasize enough is the timeout behavior. If you leave the craft session idle for about ten minutes, the terminal drops the connection and you have to reauthenticate. This sounds minor until you're in the middle of a multi-step provisioning sequence and suddenly everything is disconnected. I started keeping a terminal session alive by sending a null character every five minutes from a simple script on my laptop.

Basic Connection and Login

Open your terminal emulator and set it to 9600 baud, 8 data bits, no parity, 1 stop bit. That is the standard Tellabs craft port configuration. VT100 emulation works fine though I prefer ANSI mode because the status lines render better. Log in with your craft credentials. Default login is usually craft/craft for new installations but nobody runs with defaults after the first day of deployment. Once you are in, type help and press enter. The command tree branches out in a way that feels arbitrary. There is no real logic to the folder structure and some commands only work at certain privilege levels. You'll figure out the hierarchy through repetition and probably a few failed commands that reset provisioned circuits. Always verify your current privilege level before making any changes. I once ran a clear command thinking I was in display-only mode. It cleared the alarm log. Took me two weeks to reconstruct the alarm history from the NMS backup, and even then it was incomplete. The command to check your level is privilege show. Make it a habit to run it before every session.

Navigating Alarms and Events

The alarm system is where most people spend their time. show alarm current pulls the active alarm list. show alarm history pulls past alarms within a configurable window. The default history window is 24 hours but you can extend it with the alarm history duration command. I set mine to 72 hours because incidents sometimes surface hours after the initial fault. Here is something beginners miss: the alarm display does not show the root cause first. It shows the most recent symptom. If you have a cascading failure starting from a single LOS on line card 3, slot 1, you will see fifteen alarms flashing across multiple shelves before you see the original loss of signal. The workaround is to sort by origin rather than by time. Use show alarm current sorted-by origin and the cascade reverses. Takes some getting used to but it cuts mean-time-to-diagnosis significantly. Another gotcha with alarm clearing. Clearing an alarm on the craft interface does not always mean the fault is resolved. It just clears the display entry. The alarm will reappear if the underlying condition persists. I learned this when I cleared what I thought was a stale alarm and then watched it come back three seconds later while a customer was on the line. Not ideal.

Provisioning Basic Circuits

Circuit provisioning on the Tellabs 1000 follows a specific sequence and skipping steps causes partial failures that are much harder to debug than clean failures. Add the tributary first. Then add the cross-connect. Then verify the path. Then activate. The command structure uses create and configure rather than a single provisioning command. This means you can build the circuit in pieces and verify each segment before committing. It is actually helpful when you are routing across multiple shelves because you can confirm each hop individually. The downside is that it takes longer and there are more places for typos to slip in. I found that keeping a notepad open with the exact command sequence saves time. Something like:

create tributary port type OC3 shelf 1 slot 3 port 1
configure tributary port shelf 1 slot 3 port 1 timing internal
create cross-connect source shelf 1 slot 3 port 1.1 destination shelf 2 slot 1 port 2.1
configure cross-connect shelf 1 slot 3 port 1.1 to shelf 2 slot 1 port 2.1 protection none
activate cross-connect shelf 1 slot 3 port 1.1 to shelf 2 slot 1 port 2.1 Copy-paste that into the terminal and modify the slot and port numbers for your specific setup. Much faster than typing each line and reduces syntax errors. Just be careful about the .1 notation on the tributary port. That is theSTS-1 level inside the OC3. If you omit it the command will reject it but not always with a clear error message.

Common Pitfalls and What They Cost You

One recurring problem is mismatched timing configurations. If two points on the same section are set to different timing sources you will get pointer alignment events and potentially data errors. Check timing on every new circuit you provision. The command timing show gives you a summary of all timing sources currently in use. Run it weekly even if nothing seems wrong. Another issue is firmware version mismatches between shelves. The craft interface lets you manage multiple shelves from a single terminal session but each shelf may be running different software levels. Commands behave slightly differently across versions and some commands simply do not exist on older firmware. Before provisioning anything that touches multiple shelves, check the software version on each one with show software version. If they differ by more than a minor revision level, expect unexpected behavior. There is also the matter of database synchronization. When you make changes through the craft interface, the configuration writes to the active database on the controlling shelf. If you have a redundant control shelf setup, the standby needs to sync. This usually happens automatically within a minute or two but occasionally it stalls. I have seen it take twenty minutes or more depending on how many changes are queued. Do not make additional changes while the sync is pending. It just adds to the queue and prolongs the problem.

When the Craft Interface Is Not the Right Tool

For bulk provisioning or automated workflows, the craft interface is awkward. You can script it to some degree but the lack of a proper API means you are dealing with text output parsing and that breaks whenever firmware updates change the command response format. If you are provisioning more than twenty circuits in a single project, use the network management system instead. It is faster, validates configurations before applying them, and keeps a cleaner audit trail. The craft interface shines for troubleshooting and individual circuit changes. It gives you direct access that the NMS abstracts away. But it is not a replacement for proper documentation practices. Every change you make through craft should be logged somewhere. The system keeps its own logs but they are not designed for human review over long periods. Export them regularly. Bottom line, the Tellabs 1000 craft interface works. It is not elegant and it has quirks that will frustrate you on day one and day one thousand. The documentation helps but the real knowledge comes from doing the same commands enough times that your fingers remember what your brain forgets. Keep a reference sheet nearby, check timing and firmware versions before every session, and never clear an alarm without confirming the fault is actually gone.