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!