Still here, but tired

I'm still here. I still have the same plan I had when starting this blog.

I'm on the same page of the Cisco CCNP Route book I borrowed.

I'm aware that I need to get going on this certification and I really am excited about it. I'm just so incredibly tired right now with some familial changes that are going on in my home.

I do intend to re-evaluate my plan and my goals this week, though. I'm in need of some motivation and encouragement that this is going to make a difference for me professionally, however.

I'm just tired this summer. I'll be back at it soon, I hope. School is starting and it's time for me to add my own education to the "Important List of Things To Do."

Check back soon for more...

Quick update

It's incredibly difficult for me to focus on geekstuff when the weather finally starts getting nice, and I think we may be in the one week per year of decent weather Minnesotans get. My study routine is faltering and I'm behind schedule terribly.

I'm having trouble waking up early to study, which has historically been my most productive time. My schedule is to wake up at 4:00 AM sot hat I can get an hour of studying in before I get ready and go to work. Maybe I'm getting old, or maybe I'm not as motivated as I once was. I'm just having much more trouble getting out of bed and into the groove and many times I sleep right through the alarm. It's time to change the routine or fail.

When I consider the reasons I'm struggling, I think lack of sleep is a major issue along with distractions in my study area. For instance, all my guitars are sitting here, begging to be played every time I sit down to do some Routing. Here's what I've done and am doing to combat these:

1. Agreed with my wife that this is of utmost importance and I've reinforced our collective decision to move forward with this career path
2. Decided to got to bed earlier - with the time set as 9:30 PM to be in bed. The way things work out now, I get to bed by 10:30 and we sit up and talk or watch TV until 11:00, then by 4:00 AM I'm shot and unable to get up
3. Take down my drumset and put up a "work-workstation" where I won't have anything other than work to distract me. On this "workbench" will be my laptop, some paper and pens, my study materials and various routers and switches. There will be NO GUITAR or MUSIC RELATED ITEMS HERE.

Focus is the key, once again.

Back in the swing

I posted notes from 3 different topics this morning. I've been out of town, traveling for work and my ability to study has been somewhat limited. However, I'm back in it today and catching up on all the things I have been putting off.

It's easy to get discouraged when the plan starts to falter. I know that I typically set lofty goals for study and test-taking, and when things don't go as planned I feel a little pressured to perform. It's important to remember that falling off the plan doesn't produce failure in general, it simply delays it for a short period of time and that the race is won by the persistent.

I'm back in the swing today, and we'll keep pushing forward. Life is going to happen - and as much as I'd like to say that there is nothing so important as obtaining a CCNP certification, I have 5 children that would disagree. Not to mention a beautiful wife who would like to see me once in a while as well...

EIGRP Router ID

EIGRP produces a Router ID, which is a 32-bit number in dotted decimal format. The Router ID (or RID) is used in external EIGRP to prevent routing loops. IN a properly configured network, the highest IP address assigned to a loopback address becomes the RID, and if no loopback interface is configured, the router's highest IP address becomes the RID. For an excellent explanation of the problem and configuration, look here.

Each router determines its RID when the process starts using the same general rules as OSPF:

1. The router will use a configured value (i.e. eigrp router-id a.b.c.d)
2. It will use the highest IPv4 address on an up/up loopback interface
3. It will then use the highest IPv4 address on an up/up non-loopback interface

The EIGRP RID has little value unless you are injecting external routes. That is when you are required to have unique RIDs to avoid confusion.

Show commands seldom list RID values, and are not needed to determine the topology database like OSPF. Duplicate RIDs will not prevent a neighbor relationship from taking place, either.

EIGRP Metric Components: K-Values

Normally, EIGRP metric calculation is done using contraining bandwidth and cumulative delay. Other values can be used and configured to tailor the metric and customize routes to match your environment. The default formula for EIGRP metric calculation is 256*(bw + delay), however, the full formula is:

EIGRP Metric = 256*([K₁*Bw + K₂*Bw/(256-Load) + K₃*Delay]*[K₅/(Reliability + K₄)]).

And the default values are:

K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0

As can be seen from the above formula, K1 and K2 affect bandwidth & load, K3 affects delay, while K4 and 5 affect reliability. If K5 is equal to zero, then the entire section of the formula is ignored, hence we arrive at the default formula. While not recommended by Cisco, K-values can be used to influence route calculation by modifying the weight of each respective metric component. For instance, in a lab situation bandwidth can be disabled to simplify metric calculation and make it easier to learn the concepts of EIGRP.

It is important to note that mismatched K-values can prevent a neighborship from taking place, and IOS will log mismatched K-values when the router receives an EIGRP packet.

To set K-values, you use the following commands:

router eigrp 1
metric weights 1 0 1 0 0

This command would set the values to the default configuration. To verify that K-values are configured properly, we use "show ip protocols" which would list the K-values.

While K-values are rarely modified, it is beneficial to understand exactly how EIGRP comes up with its configuration. Understanding how and why things work is the greatest troubleshooting tool a network engineer can have.

Neighbor Requirements in EIGRP

1. Routers must be able to send IP packets to each other (duh!)
2. Interface primary address must be in the same subnet on neighboring routers
3. Must not be passive on connected interfaces
4. Must use the same Autonomous System Number on the "router" configuration command
5. hello intervals, hello timers and hold timers do not need to match
6. Must pass router authentication
7. IP MTU does not need to match
8. K-values *must* match
9. Router ID does not need to be unique, however - duplicate RIDs may cause problems when configuring external EIGRP
   

Statically Assigning EIGRP Neighbors

To reduce overhead of EIGRP multicast traffic, EIGRP allows neighbors to be specifically, or statically defined. This may be useful in an environment where you have a frame relay circuit with several PVCs, but you only want EIGRP to be configured on a couple routers. In a normal multicast configuration, the frame would be replicated to all PVCs and use precious bandwidth that is unnecessary. By statically configuring the intended neighbors, the EIGRP messages only go to the intended neighbors.

Cool.

Configuration of a static neighbor is pretty straight-forward, but again, as with all IOS configuration, knowing how and why things work makes the design and verification much easier. To configure a static neighbor, you would enter the router sub command context and assign the neighbor as such:

router eigrp 9
neighbor <ip_address_of_intended_neighbor> <outgoing_int_on_router>

Some things to note about the above commands:

• the ip address of the neighbor router must be from the subnet connected to the listed interface
• a "network" command is not required, because EIGRP will still advertise the subnet connected to that interface

To verify a static neighbor, we need to add "detail" to the end of our "show ip eigrp neighbors" command as in:

show ip eigrp neighbors detail

Without the detail command, IOS only shows that a neighbor is valid or not. Other interesting facts about statically assigning neighbors are that IOS disables all EIGRP broadcasts on an interface where a neighbor is statically assigned. There is no need to broadcast out that interface any longer since we're defining specific neighbor partnerships. As a result, any dynamically discovered neighbors will cease to work, and no new neighbors will be dynamically discovered.

Apply with caution, and always know what you're doing before you press "Enter."

EIGRP is fun...