A personal detailed view of a journey of acquiring IT certifications and career progression.
Monday, June 20, 2011
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.
Sunday, June 19, 2011
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.
Sunday, June 12, 2011
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)
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)
Sunday, April 17, 2011
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:
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:
Sunday, March 20, 2011
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.
Saturday, February 26, 2011
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.
Sunday, February 20, 2011
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.
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.
Subscribe to:
Posts (Atom)