Solution: Follow this link to download the “Exchange Server 2003 MAPI CDO 1.2.1″. I verified with Blackberry Technical Support that the installation of the MAPI CDO will satisfy the BES requirements.Solution Tested On: Windows Server 2008 R2 (x64)

The past month I have been slowly going through the test material for the CCNA Voice exam (640-460). You can take the CVOICE exam to obtain the CCNA Voice certification, however since I did not have much knowledge of voice topics I stuck with the 640-460 track. The Official Exam Certification Guide was just what I was looking for an even provides a refresher on some CCNA topic in case you’re a bit rusty.

Attached is a PDF document with the notes I took while reading. They are fairly lengthy, but this is an important part of the study process for me particularly when the majority of the topics are brand new (again, for me).

CCNA Voice IIUC 640-460 Notes

Essentially the information that has been floating around the Internet (and covered here) regarding the changes has been spot on. Pre-orders for some of the Cisco Press books have started popping up, with expected delivery dates around the middle of February.

The culprit switch started acting odd after I copied the current software image (which was stable for months) from primary to secondary flash. After doing so, the option to download a new image from TFTP was not available. A reboot left me with a switch that was still moving traffic and showed as “Up” in our NMS, but I was unable to remotely manage the switch via SSH or Telnet.

On my way home, I stopped by the building where the trouble switch was located thinking I could fix the issue quickly. After about 15 minutes of trying various methods of transferring a new image onto the switch (including TFTP and USB), I resulted to using Xmodem.

Xmodem is a last resort method of bringing a switch back from a usually inoperable state. The process below details a few ways to use Xmodem with an HP Procurve 5400zl switch.

The first topic you need to know is baud rate, and what type of impact it has on your transfer speeds when using Xmodem. The console port on most network equipment is set to a baud rate of 9600. This is fine for most normal console management needs. However, if you try to transfer an image using that standard baud rate, you are going to be waiting for a while!

In both scenarios below, I set the baud on the console port of the switch to 115200 (the maximum in this case of the switch I was using). The difference it made was clear by the transfer time estimates. At 9600 baud, it was estimated that the 10MB image would take 3.5 hours to transfer. At 115200 baud the same image only took 40 minutes. 40 minutes is still a long time compared to the transfer times of TFTP or SCP, but it is the lesser of two evils in this case.

Xmodem within Software

Your first option for transferring a software image is to use Xmodem after the switch has fully booted the current software image. The image on my switch was in a broken but semi-functional state, so I was able to attempt this.

First enter configuration mode and set the baud rate on the console port.

configure terminal

console baud-rate 115200

Save the configuration and reboot the switch (This is required for the baud rate change to take effect).

write memory

reload

While the switch begins to reboot, terminate your current console session and start a new one using the new baud rate (115200 in this case). Don’t be alarmed if you do not see the usual information scrolling across the screen as your switch boots. Eventually you will again be presented with your usual login prompt.

Once you have logged into the switch issue the copy command. The command below tells the switch to download the image from Xmodem and write it to the primary flash storage.

copy xmodem flash primary

If this is successful, reboot your switch and ensure it boots the new image properly. To ensure your switch boots from primary flash storage, issue the following command:

boot system flash primary

After you are done, be sure to reset the baud rate on the console to 9600 and then reboot the switch again.

configure terminal

console baud-rate 9600

write memory

reload

Xmodem from RoMon

In my case, I was not able to successfully transfer an image using the previous method because of the broken state of the software image. For this reason, I resorted to using RoMon.

RoMon mode must be selected before your switch begins to boot the software image. In the case of the 5400zl RoMon mode is option “0” on the boot screen.

Once you enter RoMon mode, you will be presented with a prompt. The first thing you want to do is set the baud rate on the console port using the sp command.

sp 115200

After doing this, you will need to restart your console session using the new baud rate.

Now, issue the “do” command to initiate the download utility (you will be prompted to confirm).

do to start download utility

After you confirm, you can initiate the Xmodem transfer using your console program of choice. Since I was using SecureCRT used the “Transfer” menu to select “Send Xmodem”. After doing so, the transfer process will begin. Once the transfer completes, the image will be verified and then saved to the flash location you choose. If everything works, the switch will reboot using the new image.

First up is a piece of equipment that was a major piece of the network infrastructure at our largest building. We started getting complaints of poor network performance in the back 1/4 of the building, I was quickly able to confirm these reports with my own testing. I had only been in my position for a short while, so I wasn’t familiar with all of the nuances of the network. Luckily the building tech was with me and mentioned that there was a “switch” in the ceiling in that part of the building, however none of my network maps or scans showed this device. We go to the spot, I climb into the ceiling and there is a 10 Mb with all of its lights (activity and collision) lit! Apparently this thing had been there for years!

Next we have a switch that was mounted to the wall in a room. This is pretty common, but what really got me was instead of removing the switch to paint the wall they just painted around it! Even after I removed the screws that held it to the wall, I had to pry it off with a screwdriver since the multiple layers of purple paint where acting as an adhesive.

While you can’t help but laugh at some of this, it really has been a great opportunity as a network administrator. All seven of our buildings had networks in similar states depicted in the pictures above. This has given me numerous opportunities to put my network design skills to good use.

For the whitebox build I purchased a new motherboard, processor, and memory. This was based on the requirements that at the time ESX required a SAS chipset on the whitebox motherboard. Over the past year ESX’s support of SATA chipsets has improved, so you may be able to save some money on the motherboard. Below is a complete list of the hardware used in my build.

• Enclosure: Lian Li PC-V6000B ATX Mid Tower
• Processor: Intel Xenon X3230 Kentsfield (Quad Core)
• Motherboard: Asus P5BV-E/SAS
• Memory: 4 x Wintec AMPX 2GB DDR2-800
• Storage: Western Digital Caviar WD5000AAKS 500GB 7200 RPM 16MB Cache SATA-II
• Hard drive Enclosure: Athena Power BP-SATA3051B 5-bay hot-swap SATA backplane
• Power Supply: Enermax Noisetaker II EG425P-VE 420W
• Enclosure: Lian Li PC-V6000B ATX Mid-Tower

As you can probably tell, this used to be a file server that I built but decommissioned when a motherboard failure also took my data with it. One 500GB hard drive has been sufficient for both the ESXi installation and the storage of the all of the virtual machines (thin provisioning works very well).

Initially I installed Ubuntu 64-bit as the host operating system, with VMware Server running on top of that. Additionally I used GNS3 on the host to connect back to my lab equipment via the second NIC. Since then, VMware has made ESX (ESXi) freely available. I decided to install VMware ESXi 4.0 in place of the host OS, so that ESX can better manage allocation of the physical resources to each VM.

So far everything has been working out well. I have configured another Vswitch which connects to the second physical NIC and will be used to connect the VMs to the lab equipment. In the coming weeks, I will be creating a Linux VM and installing Dynagen to handle virtualization of some Cisco routers.

The advent of the live CD has changed the game of even further. Once upon a time you might need one CD for every task that you might want to complete. Now you are able to cook your own live CD complete with all of the tools you need. Even with this ability, I recognize that there are some great live CDs out there that have a very complete set of network tools out of the box. I will discuss a few tools that make it much easier to take a typical ISO and “burn” it to a bootable USB drive.

Requirements

Before starting, keep in mind that in order for this entire process to work, the computer you intend to use the bootable USB drive with must support booting from such a device. Many older computers do not support this function. In some cases a BIOS upgrade may provide this functionality.

UNetbootin

UNetbootin is a utility for Windows and Linux that can take just about any ISO and write it to a USB drive in a bootable fashion. It has a nice feature where will can even automatically download the ISO for various Linux distributions before writing it to your USB drive.

Most users will use the second option, which will write an existing disk image (ISO or floppy/hard drive format) to the selected USB device.

I have personally used UNetbootin with many different ISOs and I have not run into any problems. This utility comes in handy for OS installs without a CD or otherwise using a live CD.

BootMyISOs

This is a Windows only utility used to make a USB drive bootable. Once BootMyISOs has done its part, all you have to do is copy the ISOs you want to the USB drive. This is great for replacing all of your old CDs with one bootable USB drive.

Make sure you refer to the linked page on Pen Drive Linux, since BootMyISOs only supports certain distributions/ISOs.

Happy booting!

So why was our DHCP server trying to send these update outside of our network? We have two DNS servers locally that should be receiving all of the DNS updates.

My first step was to check out our primary DNS server and double-check the reverse lookup zones. Below is a list of some of the zones I found (IP addresses have been changed to protect the innocent):

10.1.5.x
10.1.8.x
10.1.20.x

Spot the problem? These are very specific reverse lookup zones. Say we have a subnet that has usable addresses spanning from 10.1.5.1 to 10.1.6.254. When the leases from the 10.1.5.1 – 10.1.5.255 range have been handed out and leases from the 10.1.6 group of addresses begin to be served out, the DNS updates for the 10.1.6 addresses have nowhere to go. Essentially we had reverse lookup zones for a very specific set of addresses.

The solution was to create the proper reverse zone that would cover all of the subnets we use. The zone, or zones, that need to be created depend on the address space your organization uses internally. Since we use addresses in the class A 10.0.0.0 range, I needed to create a reverse zone named “10.in-addr.arpa.”. Below is a quick list of the common private address blocks and the reverse lookup zones they require.

After creating the proper zone for our internal IP scheme, the DNS updates for all of the DHCP leases started to appear in DNS. Additionally, the log entries stating that our DHCP server was sending updates to external DNS servers stopped.

A common mistake is to think that you only need the reverse lookup zone for the subnet you are using. For example, if someone is using the 192.168.2.0/24 subnet, they may think they only need the “2.168.192.in-addr.arpa.” reverse lookup zone. In fact they still need to create the “168.192.in-addr.arpa.” zone and let their DNS server handle the rest.

This may seem like a basic rule to most people, but not everyone knows about reverse lookup zones. In my case the current design was inherited. Honestly I may not have noticed the problem with the reverse lookup zones if I wasn’t sifting through logs.

In a mixed vendor network, consisting of both Cisco and HP Procurve switches, it is important to keep traffic to and from multiple VLANs flowing. In any environment trunks, or tagged VLAN links, are an integral part of keeping that traffic moving. This can be a source of confusion since Cisco and HP handle the tagging of VLANs a bit differently. In my opinion Cisco handles 802.1q trunks in an easier to manage way; however the method used by Procurve switches is simple once you are familiar with the process.

The trunk between a Cisco and HP Procurve switch must be of the 802.1q variety. ISL trunks will not work because it is a Cisco proprietary encapsulation. I rarely see ISL in use these days, and I personally consider 802.1q the preferred method of encapsulation if for no other reason than its interoperability.

I will focus on the configuration of the trunks on each switch; if you need a refresher on how to configure VLANs on Cisco or Procurve switches consult the documentation for your switches. Once you have configured all of the needed VLANs it is time to configure the trunk on the Cisco switch using the following commands:

3550-02(config)#interface fa0/48
3550-02(config-if)#switchport mode trunk
3550-02(config-if)#switchport trunk allowed vlan all
3550-02(config-if)#no shutdown
3550-02(config-if)#exit

Here interface number 48 is the trunk port on the Cisco switch. After entering interface sub-configuration mode, the port mode is changed to “trunk” (the default is access). Next, it’s a good idea to set what VLANs you want to allow across the trunk. Here I used the “all” option, but for security reasons you may wish to specifically list the VLANs you use in your environment. Finally, you want to make sure the interface is not in a shutdown state because that would not allow the traffic to flow (ask me how I know)!

Procurve switches, much like their Cisco counterparts, can have a VLAN either tagged or untagged on any particular port. The configuration of this tagging varies a bit as shown in the configuration below.

HP ProCurve Switch 3400cl-24G(config)# vlan 4
HP ProCurve Switch 3400cl-24G(vlan-4)# tagged 24
HP ProCurve Switch 3400cl-24G(vlan-4)# exit

The “vlan 4” command drops you into VLAN sub-configuration mode. Here the “tagged 24” command is used to tell the switch to encapsulate any packets on port 24 that originate from VLAN 4. As may already be obvious, port 24 will be the trunk port on the HP switch. Below is the command that is used to accomplish the same for VLAN 5.

HP ProCurve Switch 3400cl-24G(config)# vlan 5
HP ProCurve Switch 3400cl-24G(vlan-5)# tagged 24
HP ProCurve Switch 3400cl-24G(vlan-5)# exit

The next step is to connect the trunk ports on each switch using the appropriate network cable. Issue the “show interfaces fa0/48 trunk” command on the Cisco switch to verify the trunk has been established. You should see output similar to what is displayed below.

3550-02#show interfaces fa0/48 trunk

Port        Mode             Encapsulation  Status        Native vlan
Fa0/48      on               802.1q                trunking   1

Port            Vlans allowed on trunk
Fa0/48      1-4094

Port            Vlans allowed and active in management domain
Fa0/48      1,4-5

Port            Vlans in spanning tree forwarding state and not pruned
Fa0/48      1,4-5

The key here is that you want the status to read “trunking”. This will indicate that the trunk has been successfully established.

Next test connectivity between two hosts that are in the same VLAN, but on different switches. In this case I assigned IP addresses directly to the VLAN interface on each switch. Here is the IP address layout I used.

Cisco 3550

• VLAN 4: 172.16.1.1/24
• VLAN 5: 172.16.2.1/24

HP 3400

• VLAN 4: 172.16.1.2/24
• VLAN 5: 172.16.2.2/24

Below is ping output from the Cisco switch  after issuing a ping command to both VLAN interfaces on the HP switch:

3550-02#ping 172.16.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

3550-02#ping 172.16.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/202/1000 ms

Now, here is the ping output from the HP switch after issuing a ping command to both of the VLAN interfaces on the Cisco switch.

HP ProCurve Switch 3400cl-24G# ping 172.16.1.1
172.16.1.1 is alive, time = 1 ms

HP ProCurve Switch 3400cl-24G# ping 172.16.2.1
172.16.2.1 is alive, time = 1 ms

As you can see, configuration of 802.1q trunks between Cisco and HP Procurve switches is not overly complicated. The key is to test connectivity to ensure that traffic is flowing as it should. In larger environments it could be a bit cumbersome to manage a large number of tagged VLANs on a Procurve switch. If things are not working, double check your config on both ends. Many times I find that it is easy to forget a tagged command on the HP side of things.

Without getting into too many specifics (since Cisco has not made an official statement regarding the changes) it looks like CCNP 6.0 will bring some major changes. The current information shows that the BCMSN and BCSI exams will be replaced by applicable switching and routing exams. Further information seems to indicate that the ISCW and ONT exams will not be replaced. Finally, it appears that an exam geared towards troubleshooting will be added.

There is much discussion on what these changes will do to the perceived value of the CCNP certification. Others are concerned that they will be stuck with outdated study material if they only begin their studies now. History has shown that there will probably be some sort of phase-in period where both the new and old exam content will be available.

Personally, I have decided to purchase some training material anyway and continue my studies. My decisions were fueled by two major factors. First, the electronic training I purchased came with free updates. As the content of the CCNP exams changes, I will be entitled to free updates to the training material. The most important reason I choose to continue my studies is for personal advancement.

The ultimate goal of my study efforts is to obtain my CCNP certification. However, during this time I also want to build my networking knowledge and skills in order to advance myself both personally and professionally. If I study and learn a topic that is not covered on the new exams, I will still have knowledge of the topic that will no doubt come in handy at some point in my career. In my opinion, this is sometimes lost when studying for any professional certification. Many people find themselves studying just to pass the exam rather then also focusing on their personal advancement.

The steps below assume that you are running Ubuntu Server 8.04.3 LTS i386 with a standard LAMP installation. They may work with other Debian based distributions, but your mileage may vary. For this installation I will be using Rancid version 2.3.2, which is the current stable release at the time that I wrote this article. I encourage you to check the Shrubbery web site and get the latest release that is available. Additionally, this article will go into a bit more detail about using Rancid with various HP Procurve equipment.

It would be a lie to say I figured out all of these steps on my own. Some of it was trial and error, other information I found in various places on the Internet. Tweets from Jeremy over at Evil Routers gave me the needed insight on editing the hrancid file to support some of the newer Procurve equipment.

Rancid Installation

After your base LAMP system is installed, you need to install some packages that are required to install and run rancid. You can combine these commands into one line, but I broke them out into two lines to show that the second line begins the actual Rancid dependencies.

apt-get install gcc make libc6-dev
apt-get install expect cvs

Next, create a user that will run Rancid. This user’s home directory will be used as the install path and CVS repository for Rancid. For simplicity’s sake I have used the user name “rancid”, but you can use anything.

adduser –home /home/rancid rancid

Download the latest rancid source archive using wget.

wget ftp://ftp.shrubbery.net/pub/rancid/rancid-2.3.2.tar.gz

Copy the archive to /usr/src and extract the contents.

cp rancid-2.3.2.tar.gz /usr/src
cd /usr/src
tar xvfz rancid-2.3.2.tar.gz
cd rancid-2.3.2

Configure and install Rancid. Note that we are providing arguments for specific installation directories.

./configure -prefix=/home/rancid -localstatedir=/home/rancid/var/rancid
make install

Since the previous commands were issued by the root user, we need to change ownership of /home/rancid back to the rancid user.

chown -R rancid:rancid /home/rancid

Rancid Configuration

Edit /home/rancid/etc/rancid.conf and look for the following line (which is probably commented out):

LIST_OF_GROUPS=”"

There will probably be text between the quotes which you will delete. The group names you provide will be your CVS groups, and will translate into folders when viewing the repository with CVSweb. In my case I choose to create a group for each building I manage. Once everything is running, each building’s folder will contain the network devices in that building as well as their configuration files. Below is an example of a list of groups. Each group is seperated from the previous group name with a space.

LIST_OF_GROUPS=”Philadelphia Boston Miami Burbank”

Edit the /home/rancid/.cloginrc file. This contains the login information for your switches. If you use AAA/Radius to authenticate users that manager network equipment, your job is easy. All you have to do is provide a username and password for every device like so:

add user * {ranciduser}
add password * {ranciduserpassword}
add autoenable * 1

The first two lines are self-explanatory. The asterisk is a wild card meaning all or every device. The last line tells Rancid that the authentication information provided automatically drops the user into enable mode.

Since the cloginrc file contains passwords, you want to change its permissions to ensure only the rancid user can access this file.

chmod 600 .cloginrc
chown rancid:rancid .cloginrc

Now we run the rancid-cvs command, which will create the CVS groups based on the “LIST_OF_GROUPS” we created earlier. It is important that you run this command as the rancid user.

su – rancid
/home/rancid/bin/rancid-cvs

Next, edit the router.db files for each group. There is a seperate router.db file for each group. The groups are located in the /home/rancid/var/rancid directory (each group has its own folder). The router.db files tell rancid the IP address or hostname of the device, the device manufacturer, and the status of the device. For example

192.168.1.2:hp:up

If you use a hostname instead of an IP address, be sure the server running Rancid is able to resolve the hostnames. For newer HP Procurve devices, you will set the manufacturer to “hp”. This works for 5400zl and 8200zl models as well as older model stackables (3400, 2524, etc). If you have a switch that was manufactured by Foundry, such as the Procurve 9308, set the manufacturer to “foundry”. Rancid will only process the device if the status is set to “up”. Any other status will cause the device to be skipped.

Edit hrancid File

The newer Procurve models no longer support the “show system-information” command, instead this command has been changed to “show system”. Luckily this command is specific enough that when it is issued on older switches that still use “show system-information”, it translates properly. In order to support the newer switches, we need to edit the “hrancid” file located in /home/rancid/bin. Once you have the file open, look for the following block of code:

@commandtable = (
{’show version’                 => ‘ShowVersion’},
{’show flash’                   => ‘ShowFlash’},
{’show system-information’      => ‘ShowSystem’},
{’show system information’      => ‘ShowSystem’},
{’show module’                  => ‘ShowModule’},
{’show stack’                   => ‘ShowStack’},
{‘write term’                   => ‘WriteTerm’}
);

You need to change “show system-information” to “show system”. The “show system information” line does not need to be modified.

Run Rancid

Now we will run Rancid for the first time. Again, we are going to need to do this as the rancid user. Be patient, as this command can take some time to complete if you have a large number of devices.

su – rancid
/home/rancid/bin/rancid-run

Install & Configure CVSweb

CVSweb will provide a web interface where you can view the configuration files for your network devices in addition to performing diffs on the files to see what has changed. Installing CVSweb is simple.

apt-get install cvsweb

After the installation is complete, edit the /etc/cvsweb/cvsweb.conf file to point CVSweb to your Rancid CVS repository.

@CVSrepositories = (
#’local’ => ['Local Repository', '/var/lib/cvs'],
‘MNSD’ => ['MNSD Devices', '/home/rancid/var/rancid/CVS'],
);

I usually comment out the “local” line with a pound, just to make navigation a bit easier (since in my case the local repository is not used.

Create a link to in the www directory that points to the location of the CVSweb icons.

ln -s /usr/share/cvsweb /var/www/cvsweb

You can now access your repository using the following URL: http://YOUR_SERVER/cgi-bin/cvsweb

Rancid Automation

Now that everything is working properly, we want to make sure Rancid runs automatically every so often. We will do this by editing the /etc/crontab file and adding the following lines.

1 12,23 * * *    rancid    /home/rancid/bin/rancid-run
50 23 * * *    rancid    /usr/bin/find /home/rancid/var/rancid/logs -type f -mtime +2 -exec rm {} \;

The first line runs Rancid at 12:00 PM and 12:00 AM. Carefully choose your intervals, because the number of devices you are running Rancid against and the size of the config on each device will increase the run time. The second line periodically clears the configuration differ log files.

There you have it! You should now have a working version of Rancid!

Orion allows you to create and add custom links to your menu bars, but adding a typical link is a bit “clunky” since the link either takes the user away from the Orion page or opens in a new window. The steps below describe how to create a custom link that will retain the Orion header and menu barat the top of the page. This has made navigating between the two much easier and has eliminated the need for me to have both Orion and Rancid open in separate browser tabs.

Creating a Custom Link

First, make sure you log into Orion with credentials that have administrator access. After you do that, click the “Admin” link that appears in the Orion menu bar.

On the admin page, click the “Customize Menu Bars” link under the Customize section.

On the “Customize Menu Bars” page, I choose to edit the admin menu bar by clicking the “Edit” button under the menu bar. If you want different groups of users to see this link, you may have to edit different or multiple menu bars.

On the edit menu bar page, click the “Add” button that appears towards the bottom of the page.

This will open the dialog box shown below.

Fill in the name and description fields as you see fit. Next, uncheck the “Open in a New Window” option box. In the URL field type the following:

http://YOUR_SERVER/Orion/External.aspx?Title=Rancid&URL=

After the “URL=” argument, type the URL of the web page you wish the link to display. When you are finished, click the “OK” button.

Back on the edit menu bar page, you will notice your new link in the “Available Items” list. Click and drag the link from this list to the “Selected Items” list.

When finished, click the “Submit” button and enjoy the fruits of your 30 seconds of labor!

This is a very simple process, but it came in handy for me and makes day to day management a bit easier.

A few of these tools I use mainly for organization, as I am anal retentive about being organized and making commonly used information easily accessible. You may find some of these tools more or less useful depending on your habits.

KeePass – This a great tool to organize and securely store password information. It has multiple methods of authentication, including password and key based. KeePass allows you to create groups as well as nested groups to easily organize information. The entire database is also searchable to further make accessing information easier. The included password generator can help you come up with passwords other than the usual P@$$word!

Wireshark  - Wireshark is a popular traffic capture program. A traffic capture program comes in handy when issues arise and you need to see communication information between hosts. It has helped my countless times when troubleshooting port authentication issues. Wireshark has a plethora of other features that can aide in finding the cause of any issues.

Tftpd32 - You’re going to need a TFTP server as some point in your career. It may be to upload a new software image, backup a config, or some other reason. Tftpd32 takes your run of the mill TFTP server and adds a few more features including: Tftp Client, DHCP server, and Syslog server. Even with these features, the program remains light and quick.

Network Stumbler - If you’re using the bars displayed in the Windows wireless connection manager to determine wireless signal strength, you’re not getting an accurate picture. Net Sumbler will give you a real-time graph of the signal to noise ratio. It will also provide various other pieces of information about the wireless networks it discovers.

PuTTY Connection Manager - PuTTY has been my personal choice for managing network devices from the terminal (Console, Telnet, etc). PuTTY CM is a separate piece of software that uses PuTTY for connections to devices. The biggest advantage of PuTTY CM, for me, is the ability to build a database of Telnet/SSH configurations to network devices. This allows me to quickly connect to a device and automate various tasks at login.

About one year ago the organization I work for went through a complete network infrastructure upgrade in one of our buildings. Since space was limited and building renovations were not in the scope of the project, we ended up using locking 45U server cabinets to house the switching equipment as well as patch panels. Most of these cabinets were put in shared storage rooms, and only one was placed in a room the received steady traffic.
With the renovation of another one of our buildings this year, we had to make a decision on if we wanted to use locking cabinets or dedicate closets specifically for networking. My past experience and current opportunity allowed me to reflect one the pros and cons of both. Here is a quick breakdown that I came up with:

Network Cabinets:

• Allows flexible placement of distribution frames to maintain cabling standards
• Provides relative security when placed in trafficked areas

Network Closets:

• Security by obscurity
• Generally allows more flexibility for cable routing
• Easy access without interrupting others

These lists could be much longer and could contain many more technical arguments. In this case, I choose to look at the less technical reasons for choosing one over the other.

In my case, I believe that a dedicated network closet is superior to a locking cabinet in a public area. Placing anything in the public eye will by nature draw more attention to that object. Add some whirly fans along with blinking lights and even a grown adult will be drawn to a network cabinet. This attention may come with some unwanted consequences such as vandalism or even accidental damage. I strongly believe in security by obscurity. What’s out of sight is out of mind, and therefore people are less likely to tamper with the equipment.

Network closets are only superior if they are dedicated and secure. Closets that are shared will quickly become a place for others to store their junk. This increases the risk that someone might cause an outage or otherwise damage equipment. I often see custodians move their cleaning carts into these spaces, bringing with them all sorts of liquids and chemicals you don’t want on your equipment!

As with any project take your requirements into close consideration. Also ensure that you plan for the future and not just present needs. A properly designed network closet can easily scale to future needs, whereas with a cabinet you are more or less stuck between the posts.

The first is Campus Network Design Fundamentals, a Cisco Press book. My hope is that this book will help me strengthen my network design skills as well as provide a good starting point for integrating VOIP into a network.

The second book is Network Warrior. This book intreagued me because of that statement on the cover that said: “Everything you need to know that wasn’t on the CCNA exam”. This should be interesting!

Be sure to check out my Bookshelf for a full list of network related books that you may enjoy.

Static NAT is used to map one IP address to another. This is typically used to perform translations from public address space to private address space. Many organizations do not put servers directly on the internet. Instead the servers may sit on a private LAN, or even in a DMZ. Static NAT mappings are used in these cases to allow servers that are sitting behind a firewall to extend services to the Internet.

Static NAT Configuration

Fortigate firewalls call the static NAT function “Virtual IP Mapping”. These virtual IP mappings can be used for static or dynamic NAT; however I will only be covering static NAT with a one to one mapping relationship.
A new virtual IP mapping is created on the “Virtual IP” tab under Firewall -> Virtual IP. On the “Virtual IP” tab, click on the “Create New” button. This will bring you to the “Add New Virtual IP Mapping” page as shown below:

Fill in the following information:

• Name – This is a name that will uniquely identify this mapping. It may be easy to use the name of the server that mapping is for just to keep things simple.
• External Interface – This will almost always be set to “external” unless you have a different configuration.
• External IP Address/Range – Here you can enter either the first and last IP addresses in a range, or just a single IP address (Leaving the second text box empty). Remember to use the public IP address here.
• Internal IP Address/Range – Same as the external IP, except this time you will use the private IP address of the server.
• Port Forwarding – Only use this if people will be sending requests from the outside on one port, while your server will be listening on another. For example if people will be requesting web pages on port 80, but your server’s web server runs on port 8080.

Once you have configured the virtual IP mapping it is time to create the corresponding policy. This will be done by going to Firewall -> Policy and then the “Policy” tab. Click on the “Create New” button to create a new policy.

This time we are going to create a policy for traffic entering our network, so the source interface will be “external” and the destination interface will be “internal” (or DMZ depending on your configuration).

The next crucial step is to set the “Destination Address. If you expand the drop down menu, you will see a section titled “Virtual IP”, under which you should see the name of the “Virtual IP Mapping” that was just created. It’s also good practice to only accept traffic for the services that the server will be running. There is no use in accepting incoming HTTP for a server that only runs SMTP services, plus it’s a good security practice.

Finally, in this case you do not need to select “NAT”. The virtual IP mapping will take care of all of the NAT work.

Now you should be armed to configure all of the basic NAT services on a Fortigate.

I will be using the Fortigate web interface for all configuration steps. The unit I am using is a Fortigate 800 running software 4.0.2,build0099. Other versions or Fortigate models may use a different process to configure NAT.

Before starting, ensure that your Fortigate is in NAT mode. This can be accomplished by going to the “Operation” tab under System -> Config. Keep in mind that you will lose many, if not all, of your policies and settings by making this change. Be sure to backup your configuration file first so you have something to fall back on if things go south.

NAT Overload/PAT Configuration

NAT overload, also called Port Address Translation (PAT), is a process used to allow many computers to access the Internet using one or more IP addresses. This is used when you have a large number of computers on your LAN, but your public IP address space does not allow for a one to one mapping of public IP addresses for each computer. Without going into detail, PAT uses one public IP address with a TCP port number appended to the IP address. The port number is what is used to identify which session maps to which computer.

First a public IP address must be assigned to the external interface on your firewall. This can be accomplished by going to System -> Network -> Interface tab. On the Interface tab, click the edit icon for the external interface. You will see the screen below:

Under “Addressing mode”, click “Manual” and enter the IP address and subnet mask. The IP address and subnet mask should be separated by a forward slash like this: “176.16.1.2/255.255.255.0”. Click “Ok” to save your changes.

Next, we need to make sure the firewall knows how to get where it needs to go. This is done through routes under the Router -> Static -> Static Routes tab. Here, you’re probably going to need at least two routes. The first route you will need is a default route, which is represented using “0.0.0.0/0.0.0.0”. Here the gateway address should be set to the next hop of your Internet bound routing equipment.
Now your firewall needs to know how to get back to your LAN subnets. It’s up to you how you configure this, but for simplicity sake we will use a blanket route. Say all of the IP addresses on your LAN subnets start with “10.70.xxx.xxx”, you can simply create a route for all of the subnets that start with “10.70” using the following IP address and subnet mask combination: “10.70.0.0/255.255.0.0”. You may choose to be more specific with your routes.

Below is an example route configuration. This is used on a production Fortigate, so I have blocked out some information to protect the innocent.

Now that the routing has been setup we can create a policy to allow outbound traffic and enable NAT. This is accomplished by going to the “Policy” tab under Firewall -> Policy. Once there, click the “Create New” tab. Here you will be presented with a list of options, but we will focus on a select few.

The “Source Interface” and “Destination Interface” options are self explanatory. We are going to set the source to “Internal” and the destination to “External” since we want to configure internal to external translation (the translation table will automatically handle the reverse mapping). The next crucial step is to ensure that the “NAT” checkbox is selected to enable NAT for this policy. You can create an “allow all” policy for now just to test if NAT is working. Various “what’s my IP” web sites should be able to confirm that the public IP address of the external interface on the firewall is being used for NAT.

One note about the NAT checkbox; it needs to be checked for any internal to external policy that you wish to allow traffic. At work I have a policy that blocks outbound RDP access; however there is one vendor’s server to which we need to permit outbound RDP access. If you create the outbound policy and place it in the appropriate spot on the policy list, but forget to check the NAT option the policy will not work. If things don’t seem to be working as they should, or is seems that the policy is being ignored, always check the Nat checkbox!

That covers NAT overload/PAT configuration on the Fortigate 800. In a follow-up article I will cover static NAT configuration, which is a less involved process.

If your company has a network with all Cisco devices and a Cisco IP telephony system has been chosen, everything seems straightforward. Cisco is going to make sure their products work well together; otherwise they’re going to have a tough time marketing their telephony system to current Cisco customers. Concerns arise when you have a mixed vendor environment. Will it work? How do the switches need to be configured?

If you have an HP Procurve based network, Procurve has you covered with their interoperability guides. These guides detail how to get phones from various vendors to work with Procurve networking equipment. The guides are very detailed covering configuration of the phones, the switching equipment, and even Call Manager (In the case of Cisco). Each section of the guide includes screen shots of any web interfaces as well as command prompt output you may encounter along the way.

If you are planning to run an IP telephony system on top of HP Procurve gear, these guides will be your source of knowledge more than a few times!

Thanks to “procurvehelp” on Twitter for posting a link to these documents!

Where would this be useful? At work I use this to secure ports in our computer labs. In the labs the desktops stay in one place. In this situation, seeing multiple MAC addresses through any port (except for the uplink port) would indicate that either someone setup a rouge switch/hub or a game of musical computers is being played. This particular command allows me to set the maximum amount of MAC addresses allowed though a port to one.

The command that makes all of this happen is ‘port-security’. Here is an example of a command that I use in our computer labs at work:

port-security 1-20 address-limit 1 learn-mode static action send-disable

Breaking the command down into sections makes it easier to understand:

‘port-security 1-20’ – Apply the command and all of the following options to ports 1 thru 20. A single port or group of ports can be specified in addition to a range.

‘address-limit 1’ – Set the amount of MAC addresses that can gain access through the switch port(s). Most HP switches support an address limit of up to about 38.

‘learn-mode static’ – This configures how the switch will learn or know the MAC addresses that are allowed to gain access through the port(s).

‘action send-disable’ – This sets the action to be taken once the threshold defined by ‘address-limit’ is crossed. ‘send-disable’ sends an error message and disables the port.

My preferred option for ‘learn-mode’ is static. In this case I do not predefine any MAC addresses, which leaves many people wondering how the switch knows which MAC addresses to allow though which ports. When the above command is first issued, the switch doesn’t know that information. With the ‘learn-mode static’ option the switch will take the first source MAC address is sees on a port and assign that MAC address as an authorized MAC address for that particular port. This process is repeated for each port in this case. The picture below illustrates this process so that it is easier to understand.

Our basic training has told us that when you first take a switch out of the box it is a blank slate. For the sake of explanation we are going to assume this for our scenario. We are also going to assume that the previously discussed ‘port-security’ command has been applied to interfaces one thru twenty. You connect Computer A to interface one of the switch. Soon after that Computer A sends a packet which enters the switch through interface one. The switch reviews the packet and one of the steps it takes is to add the source MAC address (AAAAAA-AAAAAA) to its MAC address table. This accomplishes multiple things at once. First it now tells the switch which interface Computer A is attached to, which allows more efficient forwarding of packets destined for Computer A. This MAC address table is also used by the ‘port-security’ command to determine if another computer should be allowed to gain access to the network through that port.

If some black hat comes by and connects their laptop to interface one, the switch will now see a new source MAC address attached to the packets. In this case the ‘address-limit’ was set to one, and the switch already has one MAC address associated with port one in its MAC address table. This means that the switch will take the ‘send-disable’ action, disabling the interface.

There you have it! This is a quick and easy way to add another layer of security to your network! I caution to use this command wisely as using it in the wrong situation could make you one unpopular network administrator!

As always consult the manual for your HP Procurve switch for the exact command syntax.

When making changes to any network it is often important to test all services from inside and outside the network. With tightening budgets, you can consider yourself lucky if your employer springs for an Internet connection strictly for testing. That’s ok, since you can use that fancy phone that’s attached to your hip for testing.

At work we recently changed Internet service providers. Along with this change came changes to our address space, DNS zones, firewall policies and more. It was important for me to test connectivity to our external facing services after the migration, particularly since I was taking this opportunity to apply hardened policies to our firewall. Once the migration was complete, I was able to use my cell phone to see check the status of our DNS zone propagation as well as to test how well my firewall policies were working (sometimes they work too well).

Tethering your cell phone to your computer can be a tricky subject. Many carriers charge an extra monthly fee for tethering for one reason or another. There are ways to tether your cell phone to your computer without the need for an additional tethering plan. I caution you in following any of these processes. There is the likelihood that if you abuse the “free” tethering your cell phone provider can find out and you may be stuck with a fat bill.

Moderation is the key here. In my opinion you should only use the free tethering process minimally, such a when you need to do testing. These processes should not be used if you plan to tether regularly, or use your phone as you would a data card.

Below are some links to tutorials on how to setup various cell phones for tethering. Remember; use them wisely and at your own risk.

• Using a Blackberry as a modem
• Windows Mobile phone as a modem
• Tetherbot (Proxy) for Android Phones
• Palm Pre Bluetooth Tethering