Finally moving back to the VoIP World

I haven't posted in a while but I finished up the TCP/IP Vol 1 book going through the subjects that I feel I needed to review before going back to VoIP. Mainly the interior routing protocols and overview regarding redistribution and basic static routing. This was all for making sure I had foundation for building on my VoIP knowledge to tackle the CCNP: Voice and maybe the CCIE: Voice. How can you sufficiently route voice over IP packets if you don't know how to route IP packets on its own?

I feel comfortable enough with IP routing to start diving deep into the Voice world and I have. It doesn't appear that the new CCNP: Voice reading material is quite done yet so I'm starting with Cisco Solution Reference Network Designs (SRND) material. These are really good free reading material providing best practices and design for all types of network solutions from security, voice, routing/switching, wireless, etc. Also moving to a new place leaves you pretty broke for a while and I know I'm going to have to drop some $$$ for additional lab equipment, books, and the 4 test to become CCNP: Voice certified. So I'm saving up money now while I scavenge the internet for free material!

I started with the Cisco 8.x CUCM SRND last week and I'm already at page 148 (1356 pages total) putting in about an hour of study a day.

Today I started on the security section for both the access layer and phone level. Talks about many basic things such as Man in the Middle Attacks, port security, disabling phone PC ports, etc. Tomorrow I'll read through material regarding Access Lists (ACLs) in a Unifed Communication environment.

End of the EIGRP Chapter (TCP/IP Vol I)

I cruised through the EIGRP chapter which refreshed my memory on a bunch of topics that escaped me. Such as the default metric calculations used when calculating the best routes along with topics such as Feasible Successors, SIA (Stuck-in-Active), and k values. I went through the configuration exercises which were surprisingly not that complex considering the book is supposed to help prepare you for CCIE. All they asked were to configure 5 routers with EIGRP using the process-id 5, create a authentication key between router A and B, and summarize the routes as much as possible.

Tomorrow I'll knock out the troubleshooting section and report back on what that was like time permitting. This has been one of the most helpful chapters so far since we still use EIGRP in our network but not near as much since migrating to a different vendor which uses strictly BGP for connecting WAN's.

RIPv2 and EIGRP

I briefly went through the RIPv2 review questions,configuration labs, and troubleshooting exercises over the last few days in the TCP/IP Vol 1 book. I also went through the basics and beginning of IGRP and how it moved to EIGRP. I will be spending the next week or so going through the this chapter so you may not see a post from me until then when I reach the configuration exercises. In other news I'll be moving soon so you really may not see a post until about 3 weeks or so due to the craziness going on right now!

RIPv1 TCP/IP Vol I Config Exercises

Today's lab involved RIPv1, 6 routers, 2 switches, and 4 configuration tasks. All together the lab was around an hour. The first part was to simply configure the network for RIPv1, simple enough. It's nice not having to mess with static routes all over the place! The next task was make the serial link between RTC and RTD send unicast updates rather than broadcasts. I did this by configuring the serial interfaces as passive along with setting up RTC/RTD with neighbor commands.

Next up was too change how often RTC and RTD sent each other updates, this was done with the timer basic command. I picked some random timers and used the ? command to help me a little. I set this across the board on all 6 routers because from what I understand the timers have to be universal across the network in order to work., someone correct me if I'm wrong though. The last task was to prevent RTA from talking to the 192.168.4.0 network and RTB from talking to the 192.168.5.0 network. I used an access-list and the off-set command. I told both routers that on any incoming RIP update for the particular network listed in their access-list, set the hop count to 16 or invalid. 16 hops is considered an invalid/infinite route with RIP.

RIPv1Characteristics

I went over the beginning pages in the Vol I book regarding the RIP version 1 protocol. There are some interesting things that should be noted about version 1 compared to version 2. I'll list what I remember:

1. Version 1 is a classful protocol rather than a classless protocol.
2. Since it's classful RIPv1 can become problematic when running the protocol over a discontiguous network.
3.RIPv1 pass the entire network class that it knows about when advertising routes rather than the specific subnet unless the subnet is directly connected. Again this points back to numero uno.
4. The only subnets it will list in the routing table are the subnets that's directly connected to the router.
5. RIPv1 assume any subnets that it knows about will be the same subnet size throughout the entire network. Variable subnetted networks could easily cause a lot of problems.

Finishing up TCP/IP Vol I Chapter 4

I went ahead and tackled the rest of chapter 4 regarding dynamic routing protocols. Tomorrow I'll knock out the review questions and then it's time for part II of the book. Which is the meat and potatoes of what the book is about and I should have a lot more lab design, configuration, and troubleshooting which is what I need right now.

TCP/IP Vol I Chapter 4 - Dynamic Routing Protocol Overview

I read through about 20 pages this morning regarding dynamic routing protocols and the basics of why and when they're used. Brushed up a little on my Split-Horizon understanding and how distance vector works. I know I know, it's kindergarten stuff I believe you need to have a thorough understanding of the fundamentals if you want to even think about going after the CCNP certs let alone the big bad CCIE. I plan on knocking 10-20 more pages out tomorrow and to have the chapter finished by next weekend depending on how much time I can spare.

Once I finish the TCP/IP book I'm going to begin drawing out my CCNP:Voice lab requirements and prepare myself to get ready to spend some $$$. I also plan on moving in August and hopefully adding a few simple mods to my car (I drive a Subaru WRX STI) so I probably won't be saving much over the next 3-6 months!

TCP/IP Vol I Troubleshooting Exercises Chapter 3

This evening I briefly ran through some of the static route configuration exercises. I've been swamped at work lately, working 10-12 hour days seems to be the norm lately. I'm not progressing through this book as fast as I like because of being drained by the time I get home. We will be opening a new remote site soon so I'll be even busier, not to mention we're still knocking out the kinks from upgrading our entire Cisco phone system from version 6/7 to 8.5. There's a weird call transfer issue going on when internal users transfers a caller to another user through UCCX.

Basically a caller will call Internal User A, Internal User A will then put the caller on hold, dial a different UCCX CSQ Trigger (CTI Route Point) which then goes through a queue and then to Internal User B via a random CTI Port. Internal User A then attempts to transfer Internal User B but from the reports I receive about 85% of the time Internal User B receives a fast busy when Internal User A hits the transfer button on their phone. Any suggestions lol?

Quick Tip of the day, For those who have the same amount of trouble as me with stack switches booting in the right order. The easiest way is to boot the first switch you want as master completely, then connect the stack cable to the switch(switches) you want to be clients and power them on. Make sure that IOS MATCHES otherwise you'll more than likely run into version mismatch errors like no tomorrow.

TCP/IP Vol I Config Exercises 3-14

I ran through the second configuration exercise in the TCP/IP Vol I book on chapter 3 this evening. For this lab there was a requirement to configure static routes on all routers with redundancy between each routers next-hop router. At first I thought that a floating static route would solve the issue but what I forgot is that none of the other routers would have a clue if a link went down since there wasn't a dynamic routing protocol involved. I simply took the floating static route out along with the AD (Administrative Distance) and added it back in without the AD. Now each router had a redundant route to each far end network and was load balanced using IP CEF. This solved my issue for the most part but I bet there are some ways that the packet can still not route correctly but I haven't dove to deep in all the possibilities.

The above picture shows router RTD with a path to RTB's far end network 172.16.7.0 /24 going through either RTA or RTC. RTA link is down due to a fiber cut so RTD took the route out of it's RIB and forwarded it towards RTC instead.

TCP/IP Vol I Config Exercises 3-13

I spent about 2-3 hours this morning answering review questions for the TCP/IP Vol 1 Chapter 3 section regarding static routes. For now I'm skipping most of the IPv6 stuff, I'll circle around to it a little bit later during my CCNP: Voice studies. I finished off today's studying session by completing the 3-13 Configuration Exercise. This lab involved 6 routers, a bunch of discontiguous networks, and some summarized IP network configuration requirements thrown in for fun. Everything went pretty good, I'm starting to get in the groove again finally of setting up networks in GNS3.

Certification Path and TCP/IP Vol I

I decided not to go and test for the CCNA: Security at this point in time. I believe at this point there's really no need but I did cover all of the material and took what I've learned and applied as much as I could in my current job role. Most likely I'm going to take a hiatus from taking any actual tests and prepare to go straight for the CCNP: Voice in about 9-12 months since that's the field I'm in and I already have a really good start.

That doesn't mean I'm not going to study at all though. On the weekends I spend about 1-3 hours going through the CCIE TCP/IP Vol I book, I need to have IP Fundamentals understood as much as possible. Today I labbed up a simple four router network using nothing but static routes. I've learned that specifying an exit interface (i.e. FastEthernet 0/0) rather than the next-hop router IP address with static routing could generate excessive traffic on a broadcast network. The router uses ARP to query were the packet should be sent rather than just using the next-hop IP address defined in the static route. Below is to example static route configs along with the picture of the lab I worked on:

ip route 10.1.0.0 255.255.0.0 192.168.1.66 (Next-Hop IP Address, preferred method)

ip route 10.1.0.0 255.255.0.0 FastEthernet0/0 (Uses ARP/Broadcast, can be CPU Intensive)

Site-to-Site VPN's

Recently at my company I was put in charge of configuring and deploying Cisco 881 routers and creating a Site-to-Site VPN's back to our ASA at the corporate office. I think this might have something to do with my co-workers knowing that I'm studying my CCNA: Security, oh well I didn't mind at all and kinda volunteered for this project. Well I wanted to learn about Site-to-Site VPN's through my IINS book before I started this project but the deployment happened before I could get to Chapter 4 and I'm really OCD about skipping chapters. In the end it worked out well because I think reading the chapter on Site-to-Site VPN's before ever configuring one beforehand would of just confused me.

I was able to open a TAC case to have an engineer help me get the bare bones configuration up. I then created a template and tweaked it to the point were all you have to do is change the IP's, allow the IP's on the ASA ACL, and create a static route and you were good to go. I was able to configure a group of 5 Cisco 881's in about 2 hours taking about 20 minutes each, the longest time was spent taking the packaging off of the router. The configuration took about 5 minutes.

This weekend I spent some time setting up a site-to-site configuration from scratch. For what ever reason I could never get the tunnel up and I quadruple checked the configuration including starting the lab over from scratch! It wasn't until I found some documentation that I realized why the tunnel never attempted to be created. The tunnel was only created when "interesting' traffic was sent to the other peer that's involved in the VPN process. I did a simple ping from end host to the other and just like magic the tunnels came right up!

A quick show crypto isakmp sa will show you rather your tunnel is up and alive:

Cisco SDM and ACLs

The last week or so I have been reading through chapter 3 in the IINS book which covers access lists (ACLs) using both the CLI (command line interface) and SDM (Security Device Manager). Of course most of the configuration is based off of SDM but most people will use CLI in the real world including my self. I'm near the end of the chapter which digs into Zone-Based Policy Firewall which confuses me still to be honest. I understand the high level view of it which involves around creating zones with multiple interfaces/devices to be inspected with traffic instead of assigning a different ACL per interface which can become complex. I'm sure I'll have this concept nailed down within the next few months.

I'm actually putting some of this security stuff into use already which is nice, I've taken over configuring Cisco 880 routers with VPN connectivity for our home users. Also after our UCS upgrade, I plan on streamlining alot of our IOS configuration and implementing all of our Cisco devices with AAA using the ACS server that we have.

More Cisco SDM Stuff

Well after 3 full days, I was able to get SDM up and working in GNS3. I know I've ran into issues in the pass but I wasn't smart enough to document how I resolved them really. This time I written down the exact configuration I need to have in order for SDM to run properly. You pretty much HAVE to install and use SDM if you plan on studying the CCNA: Security because most of the configuration you're going to do is based off of it. Today I was able to install AAA via SDM and some CLI which went fairly smooth. I had to setup AAA to user the routers AAA local user and password info since I don't have a RADIUS or TACACS server setup. This is good information though because we have a ACS server in our environment that uses AAA but only the older Cisco equipment is setup to use it as neither my colleague or myself are experienced in using it. We plan on beefing up and standardizing our network in the near future but we're just swamped with preparing for some very big network upgrades.

Role-Based CLI Configuration

I spent sometime this morning playing around with different roles you can assign, similar to the privileged levels that you can assign for specific users in the IOS. I created a role called "simple" that only allowed for looking at the running configuration on the router and that's it. the show parser view shows what role/view you're in. The default "root" view is the only view that allows you to create other views...it's like a riddle I know but it makes sense once you play around with it.

I also learned how you can help prevent DoS attacks on the IOS itself. You can limit the amount of times someone can try to access a Cisco device within a certain time period. If someone attempts to login unsuccessfully within a certain amount of time, the IOS can block out any further attempts within a specified time period. As shown in the picture above, this command is called the login block-for and login quiet-mode.

Risk Management

Today I read through more of chapter 1, it's one of the longest chapters I've ever read through in an IT book. I'm on page 91 with at least 10-20 more pages to go. I read up about basic risk management and the ways that you can analysis risk within a business. It's all about weighing the benefits between cost and security along with some guess work about if the risk will ever happen i.e. a tsunami hitting the middle of Missouri. I hope to have the rest of the chapter knocked out by tomorrow or Wednesday.

System Design Life Cycle

This weekend I read through a good portion of Chapter 1 in the Cisco IINS book regarding the System Design Life Cycle (SDLC) and how to create a security policy. I played around with a low-level network scanner tool called Nmap. It's pretty cool, it can scan various things in your network such as UDP/TCP ports and can even graph a simple network topology out of it! I also played around with Cisco's security policy creator template which creates a ready to go security policy with pretty much everything you need. Starting this week I'm going to begin really digging into my studies work and weather permitting. I'm honestly not sure if I'll sit this exam but i do want to up my knowledge on security, even if it's just general knowledge.

Certification Plans

Well I believe I have my plan laid out regarding which certs I'm going to pursue next. I'm hopping right into the CCNA:Security exam now, security is by far my weakest subject. After Security I'm going to most likely restart my CCNP studies again. I believe I would be doing myself a huge disservice if I didn't establish a solid fundamental understanding regarding IP networking and the protocols that's used to transport it. After that I might back track to CCDA or finally begin the new CCNP: Voice cert. I'm starting to realize in my current environment that troubleshooting and configuring networks is only one half of a solution. Properly designing the network to begin with will make or break a network. With an improperly designed network it can be hard to scale or troubleshoot the simplest of tasks.

Officially CCNA: Voice Certified!

Woohoo...I haven't posted in a while but I've been doing some major reviewing along with tearing down and building up my home lab about 5-10 more times over the last 4 weeks. I took my test today and passed with quite a bit or margin compared to my CCNA exam. My worst section was the UC520 platform which I figured, there's just something wrong about trying to learn about information that's nothing more than a sales pitch.

Cisco Network Assistant

Automatic Topology Creation via CDP

So today I've finally played around with Cisco Network Assistant which is essentially the same as the Cisco Configuration Assistant that's used to configure the UC500 device. For all the people studying for the CCNA:Voice, I'm sure you're well aware that Cisco Configuration Assistant is mentioned quite a bit during the UC500 chapter. It was good to get at least somewhat exposed to the software as I didn't want to shell out the money to buy a UC520 just to learn the few basics of configuring it.

Configuring Switch Port Settings through 2D GUI

I went through all the various tabs i could find and I will admit that it's a lot more feature rich than what i expected, especially if you're connecting a a compatible CCA Cisco device to it, such as the UC520. Tomorrow's lab will consist of configuring FXS connectivity using the following lab diagram:

Verifying FXS Connectivity Lab 5-1

I will say that the IP Telephony CME Labs are quite handy as it's teaching me different ways to manipulate the CME features in different environments.

Be careful of the IP Route command on a Switch Pt. II

As I was making a frozen pizza (don't laugh!) it hit me that I believe the reason I couldn't ping any of the other VLAN's was because the ip route command turned my switch into a L3 capable device. I didn't tell my switch how to get to the other subnets via a static route/dynamic route since it was now basically a router as well. It could reach the router still because it was on the same subnet 10.1.0.0 /24.

I didn't have time to test this theory but I'm 90% positive this was the issue!

Be careful of the IP Route command on a Switch

Well I decided to tear down my current voice lab and rebuild it as i work my way through the "IP Telephony Using CallManager Express Lab Portfolio" workbook. One of the labs I was working on required me to create RoAS (Router on A Stick) and I had everything configured and for some strange reason I couldn't ping between the other VLAN'S. This was due to having the ip route command configure by accident on my switch. I'll be honest and admit that I'm not quite sure how this effects routing quite yet, if you know feel free to leave a comment.

A colleague at my current job ran into the exact issue as he was making some IP address range changes on one of our remote sites. He was lucky and was able to have someone on site connect a console cable for him to connect back to the switch to remove the command. While all the devices stayed up he lost connectivity to the switch completely.

In other news I FINALLY scheduled my CCNA:Voice test for January 4th! I really need to pass on the first go round as the cut off date for IIUC is Febuary 28th and then it switches to the ICOMM series.

Creating Voip Dial Peers

Well I figured I would make use of the extra T1 ports that I had on both my 1760 routers and create some voip dial-peers since I had the dial-peer pots working really well. While I have one T1 broken out as a simple CAS connection for making a PSTN type connection. I created the other one as a data T1 with IP addresses on each end to simulate a WAN network. Here's a small snippet of my 1760 that's acting as a remote router's running config:

This is configured to be a simple CAS T1
controller T1 0/0
 framing esf
 linecode b8zs
 ds0-group 1 timeslots 24 type e&m-wink-start


This is configured to be a WAN T1 connection
controller T1 0/1
 framing esf
 linecode b8zs
 channel-group 0 timeslots 1-24

This dial-peer is configured to send calls out of the CAS T1
dial-peer voice 1001 pots
 description outbound calls to x1001
 destination-pattern 915551001
 port 0/0:1
 forward-digits 4

This dial-peer is configured to send calls out of the WAN T1
dial-peer voice 8008 voip
 description outbound calls to x1001 using IP
 destination-pattern 915551001
 translate-outgoing called 1
 session target ipv4:69.1.1.1

Obviously I don't have both T1's up at the same time, I did this however to experiment with the different things that will happen depending on how the call is sent out of the gateway. This type of configuration will be useful for the CCNP:Voice I bet, I can have certain calls forward out through the WAN and others out of the PSTN. Or I can create some type of configuration in CUCM that'll allow for calls to be forwarded out of the PSTN if the WAN connection fails!

UCCX Holiday Scripting....Doh!

My current employer is a medium sized call center with IPCC Express used for their contact center solution currently. I'm still learning my way around UCCX but I'm getting there, I can program basic scripts and troubleshoot basic issues. We use over 40 different queue scripts that all calls out to the same default holiday script. This script then points to a very simple XML file that lists calender dates that is edited with notepad. If the holiday condition is met, the original script then inputs the variable set (usually set to change to the "closed" setting).

There was one queue that was supposed to be open today (oops) so I had to create a duplicate script called "holiday_Alternate" that called out to a similar XML file except it didn't have today's date (11/26/2010) listed therefore the original queue script was set to open instead of closed.

Configured My First ASA this Week

I configured my first ASA this week and what a mess it was! Oh well it was a good intro to getting hands on with some of the security side of things. When one of our remote sites was initially built, there wasn't any internet availability in the area due to it being in a more rural location. To remedy this, all internet traffic was delivered over our MPLS and then out of our corporate site to access any external website. Recently the area finally offered simple business DSL connectivity (that was more than enough for this location) and we asked for this service pretty quickly.

Well of course we didn't want to just connect a non-secure DSL connection to our network so we needed a simple firewall aka ASA 5505 to provide a buffer between our remote sites network and the outside world. Once all was said and done/configured it was actually pretty simple but I ran into many bumps along the way. The first thing was that the new ASA had NO configuration whatsoever on the device, not even the factory-default settings. The device was asking for a username and password which wasn't configured so after about 3 hours of mucking around I ended up finally getting in by using the ROMMON mode and changing the configuration register to 0x41. This tells the ASA to ignore the saved start-up configuration, from there I entered the command configure factory-default which put the right factory default settings on the device it should of had to begin with.

The only thing I could think of is that maybe they forgot to throw this command on the device before shipping it out lol. After that fiasco now I had to figure out to configure it finally! It wasn't to bad but I ran into some weird things mainly due to the silly DSL modem itself. The DSL provider configured the modem to work in "pass through" mode so it didn't do anything besides provide a bridge between the ISP and the ASA, it took me a while to realize that. So I had to battle NAT configuration, IP Addresses, and ASA port configuration.

What confused me the most was how I had to tell the ASA what it should and shouldn't know. The ASA had no problems reaching the internet or the internal network. However internal devices could only reach the ASA and not the external world, not even the ASA's outside interface. At first I thought this was due to access-lists I had configured. Turns out it was because NATing wasn't configured all the way and I hadn't specified the internal network IP range the ASA should know about.

I used ASDM and even a little CLI to finally get the thing working. Commands I'll never forget is the route inside and route outside which is similar to the ip route command used on routers and L3 switches.

CME Music On Hold

Ever since I've read past the CCNA:Voice section regarding Music on Hold (MOH) I've been trying to get it working ever since. The problem I ran into is that I couldn't get MOH to work when I placed a call from one IP Phone to another in my internal network, just dead silence. After some research, apparently this a known issue depending on how you configure MOH. In order for this to work between IP Phones in your internal network, you're supposed to use multicast rather than the default method. Even with multicast configured and every option I could think of, I still couldn't get this working.

Well after completely forgetting about MOH and eventually setting up my remote network weeks later, I was reviewing a few CBT's when it hit me that MOH should work when putting external callers on hold. I placed a call to the analog phone on the remote network and then put them on hold, sure enough it worked! I will admit though that the quality wasn't great because I was using the G.729 codec across my WAN and I'm betting that this analog phone is at least 15 years old!

The Smart Business Communications System

I finally knocked out the book for the CCNA:Voice this evening, the last two chapters were based on the Smart Business Communications System (SBCS). To be honest both chapters felt like one huge sales pitch but there was some useful information that I'm sure will be on the exam. As far as I understand, the SBCS suite is based around the Cisco UC500 product family and how they interconnect between each other.

The main player within the SBCS is the UC520 ISR which is pretty slick within itself, especially if you're a non-Cisco person. It enables you to have a router, firewall, POE switch, PBX, Wireless, and many other features within one small device. The UC520 itself seems fairly straightforward, especially with the web based GUI tool called Cisco Configuration Assistant (CCA). Now that I finish these last few chapters it's time to review over the next few weeks and then exam time!

Cisco Unity Express Hardware Limits

It's important to know that you're limited with voice mail size limits based on the Cisco Unity Express hardware itself. Below I have listed the four different hardware size's and their limitations that I'm assuming will be on the exam:

• Cisco Unity Express Advanced Integration Module (AIM-CUE)

50 mailboxes
14 hours of storage
4-6 ports for voice sessions depending on the router model

• Cisco Unity Express Network Module (NM-CUE)

100 mailboxes
100 hours of storage
8 ports for voice sessions

• Cisco Unity Express Network Module with Enhanced Capability (NM-CUE-EC)

250 mailboxes
300 hours of storage
16 ports for voice sessions

• Cisco Unity Express Enhanced Network Module (NME-CUE)

250 mailboxes
300 hours of storage
24 ports for voice sessions

Complete Voice Network

Today I wrapped up the last bit of configuration I needed to do to complete my CCNA:Voice lab setup (besides Unity Express). I am now able to place calls not only internally but also to my remote site via a PSTN connection. I have four more chapters to go and then it's time to review and prepare for the test. I want to take and pass the exam sooner than later because the certification is being completely revamped and I only have until February 28th to take to current version. I already feel pretty confident, especially after I was able to finally dig into dial-peers and the many ways you can manipulate them.

VoIP Trunking Protocols

With most business that integrate VoIP into their network, they not use VoIP technology within their own LAN but also across WAN's to remote sites, other businesses, ISP's, etc. There are a few popular voice trunking protocols to pick from and I'm starting to learn the history and details behind each. There are four voice gateway protocols that I hear and see configured quite a bit in the voice networks I've seen so far.

1. H.323: This is a pretty mature and older voice protocol that was created primarily for connecting to other networks using the ISDN connection. This doesn't surprise me as I see this used mainly on PSTN connections to ISP's. While the protocol is pretty stable, there are a lot of features newer protocols handle better along with being easier to manage. When I run the debug command debug isdn q931 on a gateway, the information is usually pretty cryptic and hard to undertstand.

2. MGCP: I see this protocol used all the time in the Cisco VoIP networks, apparently Cisco is really the only vendor that uses this protocol even though it's an open standard. MGCP is a centralized based configuration.

3. SCCP: Again this is only on Cisco VoIP networks because this is Cisco's proprietary protocol. This protocol is used specifically for communication with Cisco IP Phones and other Cisco endpoints such as ATA's.

4. SIP: This is the new kid on the block and it's still being developed constantly. SIP is basically a lighter and more feature rich version of H.323. Except that it is based on VoIP instead of ISDN, it uses a lot of the same standards that HTTP uses which makes it a lot simpler to develop. I haven't touched SIP yet but I've heard a LOT about it. There's actually a forum that is very involved with this new protocol, check it out at www.sipforum.org

First Hands on With QoS

As I dive deeper into the VoIP world, I'm starting to learn just how important QoS (Quality of Service) is in a network. QoS is a complicated topic and for good reason, not only because the configuration can be quite involved, but also their can be a lot of corporate politics involved. QoS comes into play when a network is congested, instead of having a router just drop random packets that it can't route you can prioritize which specific packets should be sent from most important to least important. With the least important being sent to the "bit bucket (gone forever)" most likely. With this said RTP voice traffic is very time sensitive, when there is latency it upsets the way it is sent to the receiving end and in turn usually upsets the end user as it can cause echoing, dropped calls, and a plethora of other issues.

You should prioritize voice and video traffic before other traffic in most environments...well unless the CEO steps in and demands that his e-mail and internet traffic is more important than any other traffic! There are essentially 3 steps to configuring QoS:

1. Identify and match packets with the class-map command
2. Prioritize traffic with the policy-map command
3. Assign the QoS policy to the impacted interface with the service-policy command

You can see a sample configuration in the picture above that I was messing around with in GNS3.

The Many CME Phone Features

Over the last few weeks I've been reading and toying with the many different phone feature settings that you can configure through CME. While there are still many options I haven't covered quite yet such as Intercom, Music On Hold, and Paging, I've learned a lot about what you can do using the ephone commands on the CME gateway. By far the most confusing part for me has been the configuration of hunt groups and how to route and stop the calls within hunt groups and to other hunt groups. It's a lot easier to understand when you're looking at a full Call Manager GUI rather than from ephone-dn commands!

DHCP IP Exclusion Command

As I was reading one of the CCNA:Voice chapters I noticed that my phones were picking up the wrong VLAN IP addresses. I spent hours and hours today working the issue until I realized what it was. My DHCP router has two dhcp pools to pick from when handing out IP address, one named VOICE for my IP phones (172.16.1.0 /24) and one named DATA (172.16.2.0 /24) for PC's and everything else simply enough. I like to exclude a small range of IP's from being handing out becuase you'll see this in most real world environments. So I excluded 10 IP's on both dhcp pools, 172.16.x.1 - 10 which allows me 20 IP addresses for servers, future routers, etc. Well what I didn't pay attention too was that I accidentally excluded the range 172.16.1.1 to 172.16.2.10 instead of this:

172.16.1.1 to 172.16.1.10 (10 spare IP's on the VOICE VLAN)
172.16.2.1 to 172.16.2.10 (10 spare IP's on the DATA VLAN)

I didn't notice that this was causing the issues because it was still handing out IP's but only from 172.16.2.11 on up obviously. Once I caught the error and typed this command:

ip dhcp excluded-address 172.16.2.1 172.16.2.10
ip dhcp excluded-address 172.16.1.1 172.16.1.10

Sure enough both phones picked up the right IP addresses, well after I restarted the phones from the voice router that is.

Internal VoIP Network

I'm finally back from traveling and had some downtime to begin studying once again. I was able to finish setting up my internal VoIP network and I can place calls between both phones now. The configurations for the phone settings is done through the router CME using ephone commands. I assigned one phone extension 1001 and the other 2002. Once I get a little further in my studying I'm going to configure the T1 connections between my two 1760's to simulate placing calls to a remote site over a WAN link. I'm planning on taking the CCNA:Voice test before the end of the year so I can begin ramping up for the CCVP a little after April once I'm in my new place.

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.

Preventing Redistributed Routing Loops

Today I ran over a quick lab of something you may experience in the real world, routing loops due to redistribution. As shown in the picture above, both the routers R1 and R2 are redistributing the same networks both ways. Because of Administrative Distance, each router would think the best route to EIGRP were through each others OSPF interfaces and vice versa which would cause a routing loop.

To circumvent this, I have created a route-map and assigned tags to both routing networks to prevent redistributed routes to be learned in both directions:

(Running Configurations on Both R1 and R2)
router eigrp 1
redistribute ospf 1 route-map OSPF-to-EIGRP
network 20.0.0.0
default-metric 100000 100 255 1 1500
no auto-summary
!
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets route-map EIGRP-to-OSPF
network 10.0.0.0 0.255.255.255 area 0
default-metric 100
!
route-map EIGRP-to-OSPF deny 10
match tag 90
!
route-map EIGRP-to-OSPF permit 20
set tag 110
!
route-map OSPF-to-EIGRP deny 10
match tag 110
!
route-map OSPF-to-EIGRP permit 20
set tag 90

I'm going to be learning about GRE tunnels shortly as well, hopefully it isn't to complicated to grasp, VPN's and tunneling always confused me because I have a habit of over complicating things!

Lab Portfolio Case Study 1

It took a while but I was able to finally finish the first case study presented in the CCNP Lab Portfolio book. I was rusty on a few topics but I was able to complete the following:

1. Enable EIGRP 1
2. Summarize the 5 loop back address on R2 (not presented in above image)
3. Inject a default route into the EIGRP network pointing towards R3
4. Configure OSPF between R3 and R4
5. Redistribute OSPF into the EIGRP network
6. Inject a default route into the OSPF network pointing towards R3
7. Configure DHCP on the R2 router in order for R3 to gain an IP address on its LAN (Fast Ethernet) interface.

All in all not to bad and it allowed me to brush up on the topics that I always forget! I'm digging pretty deep into my voice studies already. This morning I read through a lengthy overview on the history of Call Manager and VoIP in general. I'll probably finish that up by going through some white papers on IPCC along with the network warrior book.

IPv6 Challenge Lab

I finished today's lab which was a challenge lab, which basically makes you configure the network without any instructions besides IP configuration information. I was able to complete all required tasks successfully which included:

1.Enabling IPv6 EUI-64 between the R3 and R4 routers 2.Enabling EIGRP without auto summarization 3.Creating a manual IPv6 tunnel between the R1 and R3 router 4. Enabling OSPFv3 on all routers using IPv6 (R1,R3,R4)

While I'm about finished with the portfolio book, I'm about to dig even deeper into voice shortly, especially IPCC for my new job. I also picked up the network warrior book and reallly wished I would of had this a year ago, it gives some very good information how a live network operates and what happens in the real world instead of just topics you see on the CCNA.

IPv6 6to4 Tunnels

Today I configured another type of IPv6 tunnels used to alleviate the headaches of switching to an entirely different IP format in a network! It's called a 6to4 tunnel and it does exactly what the name says. It encapsulates a Ipv6 address within a IPv4 packet so that it can use the IPv6 address locally and still travel across a IPv4 network. Do to the nature of this type of tunnel, it doesn't need to be configured on both ends of the tunnel since it's not considered a point-to-point link. To configure a 6to4 tunnel I used this simple command:

First I configured the logical tunnel:

R1 (config)# interface tunnel 0
R1 (config-if)# tunnel mode ipv6ip 6to4
R1 (config-if)# ipv6 address ipv6 address
R1 (config-if)# tunnel source interface
R1 (config-if)# exit

Second I configured a static route to point towards my tunnel:

R1 (config)# ipv6 route ipv6 address tunnel 0

This tells the router to send this particular IPv6 address out tunnel 0 and tunnel 0 routes this interface out of the source interface.

Using IPv6 Tunnels

Today's study session consisted of creating a Ipv6 Tunnel connection between two routers. OSPF IPv6 was also configured for the loopback interfaces on routers R1 and R3 to talk to each other. This lab was fairly straightforeward and allowed for me to play around with tunnel interfaces a little bit. I come across tunnel interfaces quite a bit in my current job role so it was good getting some practice in with configuring them even if they were IPv6 tunnels which aren't to common yet in most networks! My next IPv6 lab will be on configuring 6 to 4 tunnels which is a tunnel that allows you to encapsulate IPv6 address into a IPv4 packet to traverse over a network. This is particularly useful in networks that haven't migrated to IPv6 completely yet (which is most networks).

Configuring OSPF for IPv6

I'm finally on the last chapter in the CCNP Portfolio book which covers IPv6 topics. Today's lab was dealt with configuring the many types of IPv6 address (link-local, EUI-64, etc). The lab ended with configuring OSPF over IPv6 along with a challenge lab. The challenge lab consisted of summarizing two IPv6 addresses over OSPF. All in all it was very straight foreword, when it comes to configuring IPv6 I noticed that it's very similar to it's older brother IPv4 except the order you place commands and the way you implement them on your router device. I was very surprised honestly that it worked over the switch as well, I figured the GNS3 switch wouldn't understand how to interpret the IPv6 address in its MAC table but I was wrong thankfully.

Multilinks Revisted

So I wasn't able to work through one of my CCNP Portfolio labs this morning so I subsituted with something I deal with commonly..multilinks. I've posted on this topic before and it's really straight forward to configure. Basically your load-balancing data across all of your T1 links in a simple but effective manner. You do this through the use of the PPP protocol and a logical interface called a Multilink (go figure). Say you have a business that wants to use 3 Mb of data rather than the standard 1.5 Mb, you can take their 2 serial interfaces and bundle them into one with two simple commands:

ppp multilink
ppp multilink group

You also have to create the multilink interface and assign the multilink the designate IP address as shown above. Thanks to GNS3-labs and Evil Routers for today's lab.

Multicasting Dense Mode

I spent a good part of my morning working my way through the second multicast lab in the CCNP portfolio book the best I could. Since I didn't have a real switch that could emulate SVI (I don't think) I had to use GNS3 the best I could for the IGMP snooping. Multicast is by far the hardest topic for me so far and I still don't understand it honestly. I know enough to get by but it's still very confusing and works differently then any of the routing protocols. I did understand a little more about how the multicast tree is built however using other routing protocols are RPF (reverse-path forwarding). this will for sure be a topic I'll have to spend extra time on understanding, tomorrow is another multicast lab using PIM sparse mode instead of dense mode.

BGP Policy Based Routing

I had a lot of trouble with this lab and was very confused and overwhelmed quickly trying to get the BGP routes to traverse correctly through the main SanJose router. The SaneJose2 router was supposed to be the back T1 and all traffic coming in and out should only flow through the main SanJose router. While I was able to get mostly everything working, I had problems getting the local preference settings to work right and I had RIB failures on top of that in my routes which is never a good thing lol. I'll have to come back to this lab or work through some other BGP labs to figure out what I was missing or doing wrong.