Uploading CME Files

I spent most of this evening trying to upload the full featured Call Manager Express (CME) tar files to my Voice router. I was doing very well until I realized that I didn't have enough Flash memory to support the full version! Thankfully I was able to find the basic version which should be enough to get me through the studying and the test.

It was very time consuming deleting all the old files but I did learn a new command which I've never heard of, it's called the squeeze command. It's for sure one the weirdest command names in the Cisco IOS. Here's how it works, by default when you delete a file from flash, it really doesn't delete it rather it marks it as deleted so you're not gaining your flash memory space back by just typing the delete flash: command. The squeeze command however goes through the entire flash directory and removes any files marked as deleted, it works fairly well but is time consuming also.

Beginning The Setup of My Voice Network

I've been really busy over the last few months with this one being the busiest with me working 16-22 hour days. This is due in part of me installing and bringing up new networks for a few of our remote sites that's growing in size. I'll be in St. Paul MN this Wednesday and won't be back until Tuesday of next week if all goes well. I finally had a little downtime to get some studying in. After about 1 month of researching and about $700 later I had purchased everything I needed for my CCNA: Voice lab.



After I plugged everything in I did some of the initial configuration based on the CBTNuggets CCNA: Voice videos. I ran into an issue that stumped me for a long time however which was due to none of my phones or PC was receiving an IP address from the DHCP server I configured on my 2620 router. It turns out that my 7960 and 7940 didn't like the simplified vlan configurations much on my switch.

I had the following configured at first:

switchport mode access
switchport access vlan 50
switchport access voice vlan 10

I had to change the configuration to the old way:

switchport trunk encap dot1q
switchport mode trunk
switchport trunk allowed vlan 10,50
switchport access vlan 50

Once I added this all my devices starting picking up IP addresses. The only thing I can think of at this point is that maybe the older IP Phones don't accept the new way of switch vlan configuration but I'm sure I'm wrong and may be missing something.

Learning The Analog World

Before I begin digging deep into the VoIP part of my studies I spent the last 3-4 weeks studying more about the PSTN world. Mainly how analog voice signals is converted into electric and eventually binary signals. This process is called Pulse Amplitude Modulation (PAM) if your converting analog to electrical values and Pulse Code Modulation (PCM) when you're converting the PAM values to binary.

An engineer named Dr. Harry Nyquist noticed that human voice only uses between 20-9000 Hz. He figured out if you take samples of the voice signals at twice it's frequency rate, you can accurately send the signal over a medium and play it back without any noticeable sound distortion.

The problem with that if you sampled the highest frequency range that a human can reach (18,000 digital samples per second), it would require a lot of bandwidth for each voice call. To remedy this he lowered the frequency range to 4000 Hz (8,000 samples per second) since rarely do humans ever speak above this range and if they did it would probably be pretty annoying.

With that said, the 8000 sample rate per second plays nicely with the digital world. The rule states that each sample is 8 bits (1 Byte).

Therefore 8000 samples * 8 bits = 64,000 bps (64 kbps)

Does 64 kbps sound like a familar term you hear? It should as 64 kbps equals the same size as one ds0 channel in a T1. Remember a T1 has twenty four 64 kbps ds0 channels that makes up the entire T1 speed of 1.536 Mbps (24 * 64,000 bps = 1,536,000 bps) with T1 framing signaling the T1 size is actually 1.544 Mbps.

CCNA: Voice

So I'm finally preparing for the voice certifications, I've been reading a lot of material over the last few months but I'm officially getting into study mode again. I started going through the CCNA Voice CBTNugget videos and taking notes along with ordering the CCNA:Voice study guide. I'm still finishing up pricing out my lab but I'm hoping to spend less than $800 total on it. I have phones I can use at work along with some other hardware probably so that should help. I'm going to use one of the lab guides from techexams.net to help determine what I do and don't need. I plan on going after the CCVP straight after that and then who knows maybe CCIE Voice!

I have to travel quite a bit for work over the next month so I probably won't really dig into my studies until the end of September hopefully.

Internal Router Switching

Something that's over looked during CCNA/CCNP studies is the actual switching that's done on the router. Of course the switching a router does and the switching done on an actual switch is completely different. When speaking of switching on a router it deals with the process of forwarding a packet from one interface on the router to another interface on the same router. This process can be extremely CPU intensive for the router to do. However with the use of certain router switching tecnologies such as "Fast Switching" and Cisco Express Forwarding (CEF) you can significanlty decrease the amount of work the router's CPU has to do.

In the lab I created, I told the internal router to ping the "website" router with 1000000 packets (to simulate traffic). While doing this I disabled CEF and Fast Switching note what happened below:


Note that each exclamation point means that the packet was successfully forwarded and that each period means that the packet was dropped. Looking near the end of the picture you can see when I disabled CEF and the packets were too processor intensive for the router to handle and queue so it started dropping packets to keep up with demand. For testing purposes I increased the packet size to help bog down the router so that you can see the example shown.

Configuring HSRP Protocol

I spent a little time this morning learning about the HSRP (Hot Standby Router Protocol) and how to configure it in a real world environment. This is something that I might think about implementing in our networking system actually. It works by creating redundancy between two routers in case one router loses internet connectivity, the other router can take over. The configuration was rather simple and easy to understand. You're basically creating a virtual IP (VIP) that your internal network will use rather than the routers actual Ethernet IP address. I have including a sample configuration below:

Router_A#sh run int fa0/0
Building configuration...

Current configuration : 166 bytes
!
interface FastEthernet0/0
ip address 192.168.100.2 255.255.255.0 (actual IP address)
duplex auto
speed auto
standby ip 192.168.100.1 (VIP address configured on Router B as well)

standby preempt (Tells the router to try and become primary when circuit is back up)

standby track Serial0/0 10 (decrements HSRP priority, router with highest is primary router)

end

Creating GRE Tunnels

Today was a pretty simple lab, I went through the configuration of GRE Tunnels between two different remote locations. GRE configuration is very simple and consists of the following commands on both device:

1. Create the logical tunnel interface on both remote devices:

interface tunnel X

2. Assign an IP address to the tunnel interface:
ip address X.X.X.X subnet mask

3. Point the tunnel towards the source interface:

tunnel source interface

4. Point the tunnel towards the destination interface:
tunnel destination X.X.X.X (remote device ip)

One thing to note when creating tunnels is that the remote destination must be in the routers ip table. That's about it though, you should see your tunnels come right up once everything is configured on both ends. Remember that GRE tunnels are unencrypted so it's best to route the tunnels through some type of security device such as an ASA or even a dedicated VPN concentrator.