HiddenOne

Problem: You are trying to build a new Blackberry Enterprise Server on top of Windows Server 2008 and your mail server is running Exchange 2003. The BES prerequisites state that you need to install the Exchange 2003 management tools on the BES, but they will not install on Windows Server 2008

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)

Systems

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

CCNA Voice

After much anticipation, the changes to the CCNP certification track have been officially announced. You can view the official certification options on Cisco’s website.

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.

CCNP Study

Over the long weekend, I caught up on some much needed network maintenance at several of our buildings. I was able to upgrade most of the switch software without any trouble, but there is only that one bad apple!

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.

HP Procurve

I finally got around to uploading some of the pictures I took at my current place of employment. They are not great quality, since I took them with my Blackberry. Below are a few of my favorites and the stories behind them. You can view the rest of the pictures here.

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.

General

A while back I talked about building a VMware whitebox to run VMware ESX on inexpensive equipment. That was over a year ago and a few things have changed, so I figured an update was in order.

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.

Virtualization

I hate to break the news to those of you with spindles filled with hundreds of blanks CD’s, but optical disc is dead! While this statement may be a bit dramatic, it holds true for me. Sure discs are still a means of cheap retail content delivery (Software, movies, etc), but for a network administrator even rewritable discs are a hassle.

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!

Network Tools

Recently while sifting through some logs at work, I discovered some odd traffic coming from our DHCP server. The server appeared to be sending DNS updates to external DNS servers. This traffic never made it out of our network since our egress policy was not expecting to see DNS traffic from the DHCP server, so the packets were dropped.

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.

Design, General

The first thing I would like to do is clarify that this article discusses how to configure an 802.1q VLAN trunk between a Cisco switch and an HP Procurve switch. From here on out any references to trunking refer to an 802.1q tagged VLAN trunk. I am making that distinction now because in the Procurve world trunking refers to a feature similar to Cisco’s Etherchannel.

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.

HP Procurve

It seems that those of us studying for our CCNP certification have some decisions to make. For some time rumors have been floating around about an update to the CCNP exam (currently version 5.0). About one week ago, information that looked to be targeted to Cisco Network Academy partners was leaked. This information seems to substantiate the rumors that have been floating around.

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.

CCNP Study