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.