We put in two key MiTel servers this week - Mobile Extension and Teleworker.

Mobex lets you twin your internal phone extension to any other phone number (usually a mobile phone but it could be an analog phone) - its like a fancy phone forward. Essentially the Mobex server creates a conference call between the two phones so at any time you can transfer or pickup the call on the other twinned phone. Very useful for travelling staff - it also means you can publish a single number on your business card that will get you where-ever you are.

Teleworker lets you remote boot a VoIP phone from anywhere on the internet - ideal for people working from home or colocated working through a broadband connection. The phone itself does the QoS (your PC connects via the phone) so it will always prioritise the voice traffic over data if you're in a call. Your phone works exactly the same as an internal extension, you can associate it with any PABX controller and you can even get a local analog breakout module to allow local calls.

Interestingly both Mobex and Teleworker are based on CentOS (RedHat derivative) and act as appliances - most configuration is done via a web interface. A bit of a departure from MiTels other add-on application servers which are primarily Windows based.

We're lucky that our Telco provides a unified corporate WAN solution that encompasses everything from plain old POTS to high-speed fibre interconnects. They're also a mobile carrier - when you combine their mobile 3G with their WAN solution and delegated Radius administration it means you can offer your clients seamless LAN access at 3G speeds from their laptops (which they love because they find VPN complicated).

With these two gizmo's setting up ad-hoc offsite LAN's is going to be a whole lot easier (although your wallet may feel the pain depending on your 3G data-plan) -

* LinkSys Wireless 3G Router

* D-Link Wireless 3G Router

More and more people are using Voice Over IP (VoIP) - it seems to work well and removes the hassle involved in leasing a PABX or having contractors come in and make updates to the phone system.

From an admin standpoint it means almost anyone can manage basic PABX admin (eg directory management). You also get the joys of being able to plug 'n play your phone (no more repatching every time someone moves desk) and reset voicemail pins along with a wealth of other functionality previously hidden away in the heads of PABX admins. Most VoIP vendors also have cool stuff in terms of messaging integration (eg with Outlook or Notes) and software phones.

We use a MiTel 3300 which is been ticking along quite happily for a few years now with about 340 users (it'll easily handle twice that) - admin is primarily web based and pretty straightforward although it helps to have some basic PABX familiarity before you go poking around with some of the more esoteric options. As its all software based you can just upgrade your PABX to support new generation phones - stick in the MAC address of the phone and it'll boot up with the appropriate software image.

What you need to utilise all of this VoIP goodness is a solid LAN with Quality of Service (QoS) capable switches and VLAN's to isolate your VoIP traffic. We use Cisco kit and its interesting to note that not all of their gear is created equal - implementing QoS on a Catalyst 3550 is much simpler than the 3500XL (slightly older model).

Another essential to save on cabling is Power over Ethernet (PoE) capability in your switches. Some will transparently power your phones and other devices (the newer 3550's and 3560's) while others will require dongles on your phones (the 3500XL's). For older switches (like the 3500XL's) you can also use a PoE 'booster' like a PowerDSine unit and not have to use a dongle.

In terms of basic troubleshooting be very wary of putting your phones through cheap switches and watch the quality of your patch leads. Most VoIP phones share your PC LAN connection - your patch lead goes from the wall into the phone and then from the phone into your PC. The phone itself acts as a QoS switch controlling what your PC does such that it doesn't adversely affect your voice communications - probably not something you'd notice unless you have some other real-time type apps running on your PC (eg intensive Citrix sessions).

Be careful implementing VoIP across a WAN - it can be done but if you don't have the expertise in-house you *really* need to be able to trust that your comms provider will allocate appropriate bandwidth (we allow about 80kb per call so if you have 10 people in a remote office set aside about 1Mb) for a real-time queue and properly honour the QoS DSCP tagging (44 - 46 seems common in NZ).

If you run into choppy voice calls while copying data across the WAN or when more than one or two people use their phone simultaneously then the circuit/routers haven't been properly provisioned and/or your switches aren't properly handling the QoS tagging (your comms provider will point the finger back at your LAN config so you need to be able to show end to end QoS so you can point the finger right back at them :-)

Still - its all worth the pain - being able to plonk a phone down anywhere and use it as an extension of your primary office is a truly great thing.

Some things to ponder

Security is always a trade off between client side ease of use versus protecting an organisations information assets.

So someone needs to step up and make a call - what happens if security is compromised ? If no one is prepared to take the fall for a breach of security due to ease of use then you need to lock things down and deal with client complaints.

With regards to security there are really only three reasonable options -

• Connect your Wireless system to your internal LAN and use MAC filtering and a WPA2PSK - definitely the path of least resistance. Be sure to change your WPA2PSK regularly and insure theres a safe mechanism to distribute updates. In terms of risk its pretty easy to fake a MAC and difficult to crack the PSK - then again if you update the PSK regularly it is only as secure as the update mechanism. Unfortunately apart from sending and archiving syslog files the auditing and accountability aspect of this option is pretty poor because the authentication is tied to the asset not the person.
• Connect your Wireless system to your internal LAN, use MAC filtering and Radius authentication. A step up in terms of security and it provides for auditing and accountability. The Microsoft Radius solution even allows for a client side certificate for extra security. Again the MAC address can be faked and login/password combinations can be cracked by dictionary attack - possibly less secure than a PSK but using a certificate infrastructure does improve security.
• Connect your Wireless system to your firewall, use MAC filtering, a WPA2PSK and allow access via VPN. Probably the most secure option but it may drive your clients insane unless they're used to using VPN. You get security, auditing and accountability - plus if someone hacks your WLAN they still need to get through the firewall/vpn gateway.

There is probably a fourth option - if you are in an urban area you may be able to use free wireless or an ISP's wireless service in conjunction with VPN. Not a good idea unless you have good laptop firewalls and well educated clients.

In fact if you use Active Directory you may want to restrict which SSID's you want clients to connect to and wether or not they can work in Adhoc mode or not. To be safe you should lock both down.

If you do use VPN be sure to pipe all traffic through it and not just an organisations data.

Ideally you would use a Wireless LAN Controller to coordinate your AP's and do basic IDS. On top of that a dedicated Wireless IDS with sensors is also recommended (some WLAN Controllers have AP's that can access as sensors for third party IDS products - its worth investigating as you can save some money). If possible separate out your wireless traffic via VLAN - it makes tracking, auditing and isolation easier.

Useful references

* SANS Wireless Publications

* AD Wireless Group Policy

* Technet Article on Wireless Security

* Cisco Wireless Security Guide

I can't for the life of me find the reference but (apparently) in terms of the new generation of high speed network interfaces (Gigabit and 10 Gigabit NIC's) - a rule of thumb is that 1Mb of networking speed requires 1MHz of CPU speed to process). For example putting a 100Mb NIC into a 100MHz PC will overwhelm the processor.

So if you're thinking in terms of plonking high-speed NIC's into older hardware be aware of that the CPU is likely to be the bottleneck rather than the NIC.

This is why TOE's are becoming popular. A TOE is a TCP Offload Engine - it handles the network overhead while the CPU can get on with doing whatever it was doing. Its becoming more important as people start to see the potential in iSCSI as a storage transport mechanism.

Some useful tips for novices like me over at JLSNet:

* Beginner Guide to Cisco Router Configuration

* Beginners Guide to Access Control Lists

* Configuring a VLAN

* Load Balancing Across Two T1's

I've been looking at the cool stuff from AirTight.

With all the interest in wireless technologies (it seems only a few years ago that Apple demo'd the AirCard in a clamshell iBook) it seems security has been a bit of an after-thought. Fine for consumers but not quite ready for an organisation to truly trust.

AirTight's SpectraGuard product is pretty much the best-of-breed when it comes to locking down your WLAN. Using a combination of server and sensor arrays you can monitor all WLAN activity within your vacinity - in fact depending on the landscape and structure-density the sensors are so good you will pickup activity 1 to 2km's away. Within minutes of entering the AirTight system we were able to spot 50 Access Points and 600 Wireless PC's.

In terms of the management console you can see the wireless name, mac address, ssid, type of security, channel, protocol, vendor and location (the sensors can triangulate location and superimpose onto a map). For each object you can view extended properties, locate, quarantine, ban, authorise/deauthorise and troubleshoot (which uses ethereal/pcap).

You can also view suspect events (rogue ap's, suspected netstumbler activity, honeypots etc) and generate all sorts of security/audit reports.

From a security perspective you can lock down your own network to participating ssid's, vendors and protocol lists (immediately reducing your profile). You can also block/disrupt/interrupt/degrade wireless connections - only a few channels per sensor; you can't wipeout wireless connectivity blockwide unless you have a lot of sensors (its nice to know that you can actively fight back against war-drivers that park up outside your building and try launching probes/attacks on your WLAN).

The interface is nice, simple and intuitive with a sensible out-of-the-box configuration. Once configured you can quite happily leave it to do its thing (eg its not high-maintenance).

Once these things start to work with Bluetooth, wireless USB and RFID you'd be able to do some pretty interesting things. Its actually pretty amazing to think that these sorts of technologies are even available given the sorts of things I suspect they'll be capable of doing in the very near future.

Time to pull out the tin-foil hat.

I noticed lots of search engine referrals from people looking for Cisco information. Particularly lost passwords and terminal settings. I came across this page of tips. Essentially it contains some pointers to obscure Cisco site documentation - Password Recovery Procedures and Break sequence for various terminal emulators.

Some more info over at Manucomp - Cisco Tips and Tricks.

I've been trying to pick up some Cisco bits and pieces from various sources and came across this useful tidbit from CCNA: Cisco Certified Network Associate Study Guide.

As an aside formatting text is still a PITA on the web - I ended up settling on a combination of PRE and CODE - I'm sure there are fancy CSS ways of dealing with this stuff but I can't be bothered...

Anyways - Cisco stores config information in Hex codes within the routers NVRAM - by tweaking these config registers you can do some pretty low-level things. Its a little like messing with a PC Bios or OpenBoot/SRM console.

In the book Todd Lammle explains one of many handy use for Config Register Codes:

Recovering Passwords

If you're locked out of a router because you forgot the password, you can change the configuration register to help you get back on your feet. As I said earlier, bit 6 in the configuration register is used to tell the router whether to use the contents of NVRAM to load a router configuration.

The default configuration register value is 0x2102, meaning that bit 6 is off. With the default setting, the router will look for and load a router configuration stored in NVRAM (startup-config). To recover a password, you need to turn on bit 6. Doing this will tell the router to ignore the NVRAM contents. The configuration register value to turn on bit 6 is 0x2142.

Here are the main steps to password recovery:

Boot the router and interrupt the boot sequence by performing a break.

Change the configuration register to turn on bit 6 (with the value 0x2142).

Reload the router.

Enter privileged mode.

Copy the startup-config file to running-config.

Change the password.

Reset the configuration register to the default value.

Save the router configuration.

Reload the router.

I'm going to cover these steps in more detail in the following sections, and I'll show you the commands to restore access to 2600 and 2500 series routers.

Interrupting the Router Boot Sequence Your first step is to boot the router and perform a break. This is usually done by pressing the Ctrl+Break key combination when using HyperTerminal and while the router first reboots.

After you've performed a break, you should see something like this:

System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
Copyright (c) 1999 by cisco Systems, Inc.
TAC:Home:SW:IOS:Specials for info
PC = 0xfff0a530, Vector = 0x500, SP = 0x680127b0
C2600 platform with 32768 Kbytes of main memory
PC = 0xfff0a530, Vector = 0x500, SP = 0x80004374
monitor: command "boot" aborted due to user interrupt
rommon 1 >

Notice the line command "boot" aborted due to user interrupt. At this point, you will be at the rommon 1> prompt on some routers.

Changing the Configuration Register As I explained earlier, you can change the configuration register by using the config-register command. To turn on bit 6, use the configuration register value 0x2142.

Note Remember that if you change the configuration register to 0x2142, the startup-config will be bypassed and the router will load into setup mode. Cisco 2600 Series Commands

To change the bit value on a Cisco 2600 series router, you just enter the command at the rommon 1> prompt:

rommon 1 > confreg 0x2142
You must reset or power cycle for new config to take effect

Cisco 2500 Series Commands

To change the configuration register on a 2500 series router, type o after creating a break sequence on the router. This brings up a menu of configuration register option settings. To change the configuration register, enter the command o/r, followed by the new register value. Here's an example of turning on bit 6 on a 2501 router:

System Bootstrap, Version 11.0(10c), SOFTWARE
Copyright (c) 1986-1996 by cisco Systems
2500 processor with 14336 Kbytes of main memory
Abort at 0x1098FEC (PC)
>o
Configuration register = 0x2102 at last boot
Bit#    Configuration register option settings:
15      Diagnostic mode disabled
14      IP broadcasts do not have network numbers
13      Boot default ROM software if network boot fails
12-11   Console speed is 9600 baud
10      IP broadcasts with ones
08      Break disabled
07      OEM disabled
06      Ignore configuration disabled
03-00   Boot file is cisco2-2500 (or 'boot system' command)
>o/r 0x2142

Notice that the last entry in the router output is 03-00. This tells the router what the IOS boot file is. By default, the router will use the first file found in the flash memory, so if you want to boot a different file name, you can either change the configuration register or use the boot system ios_name command.

Note Another way to change the configuration register is to load an IOS image from a TFTP server by using the command boot system tftp ios_name ip_address from global configuration mode. Reloading the Router and Entering Privileged Mode

At this point, you need to reset the router like this:

From the 2600 series router, type reset.

From the 2500 series router, type I (for initialize).

The router will reload and ask if you want to use setup mode (because no startup-config is used). Answer No to entering setup mode, press Enter to go into user mode, and then type enable to go into privileged mode.

Viewing and Changing the Configuration Now you're past the point where you would need to enter the user-mode and privileged-mode passwords in a router. Copy the startup-config file to the running-config file:

copy startup-config running-config

or use the shortcut

copy start run

The configuration is now running in random access memory (RAM), and you're in privileged mode, meaning that you can now view and change the configuration. But you can't view the enable secret setting for the password. To change the password, do this:

config t
enable secret todd

Resetting the Configuration Register and Reloading the Router

After you're finished changing passwords, set the configuration register back to the default value with the config-register command:

config t
config-register 0x2102

Finally, save the new configuration with a copy running-config startup-config and reload the router.

Note If you save your configuration and reload the router and it comes up in setup mode, the configuration register setting is probably incorrect.