Sunday, December 12, 2010

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.

Tuesday, December 7, 2010

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.

Saturday, November 27, 2010

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!

Friday, November 26, 2010

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.

Thursday, November 25, 2010

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.

Sunday, November 21, 2010

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!