A Quick Update

Reviewing my progress today over the last week of study.

I haven't really been getting to any technical stuff yet, so my posting has been light.  I'm a little bit behind and am planning to schedule some evening work to catch up.  By my progress-o-meter, I should be on page 72 and I'm on page 42 (hmm...I didn't think I had fallen that far off the mark already!).

I'll spare the excuses and come up with a schedule.  A big part of my difficulty is that I need to wake up pretty early to get the full amount of time to study.  I've been kept awake late pretty much every night and the alarm clock isn't getting me motivated to crawl out of bed.  So, issue #1 is that I need more sleep, and this needs to take precedence over everything else.

Issue #2 is that I have a large number of projects that I'm trying to complete, both at home and work.  At home I'm trying to get the house put back together before winter and at work we're busier than ever with fiscal year-end (that magical time of year when sales people realize they may not make quota).

Could use a few more hours in the day, but mostly I need to make this a priority and execute on the plan.

A Slight Change in Program

Due to some recent initiatives at work, I'll be putting the CCNP on hold temporarily while I concentrate on adding the Voice option for my CCNA.  This will be to support several installations of Cisco Voice and add to the team within our Managed IT offering, and it will renew my CCNA as a side benefit.


I am awaiting the Cisco UC500 demo kit to arrive in our St Cloud office so that I can set up some equipment and have a lab to work in.  I haven't seen what's included yet, so I'll update the equipment list once it arrives.   I'm studying out of Cisco Press' Official Certification Guide for exam 640-461 and will likely supplement with real-world support calls from our existing customers.  I also have a pretty deep bull-pen at work with some experienced voice professionals who have been installing and supporting Cisco Voice for some time.  As per usual, I'll post updates about what I'm learning and doing here, mostly as a review for myself - but if someone else can benefit, all the better.


I'm pretty excited to begin.  It's good to have a direction and a plan.  My schedule is:

• Study 5 days/week - 1 hour each day
• Complete the study guide by Nov 11
• Review for a week between 11/13-17.
• Test date will be November 17, 2011.

So let it be written, so let it be done.

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...

EIGRP Authentication

EIGRP allows the use of a pre-shared key (or PSK) to create an MD5 digest for each message sent and received. This prevents denial-of-service attacks by refusing neighbor-ship of unauthorized routers, but does not provide any privacy. Because EIGRP multicasts to 224.0.0.10, any router can joint that multicast group and read the messages but won't be able to establish itself as a neighbor. Essentially, they are allowed to look at the Country Club through the gates but not allowed to golf...

Anyhow...

Configuration contains a few commands requiring special attention to detail. It's important to note that the name of the key-chain and the number of the key-chain *do not* need to match between all neighboring routers. All that is important to match is the key-string used to hash the PSK.

To configure:

key chain <name_of_keychain>
key <#>
key-string <string_used_for_PSK>
!Optional - set lifetime
accept-lifetime <start_date> <end_date>
send-lifetime <start_date> <end_date>

After configuring the key chain and PSKs, we enter interface configuration mode and execute the following sub-commands:

ip authentication mode eigrp <asn> md5
ip key-chain eigrp <asn> <name_of_chain>

Time-based logic for EIGRP authentication allows some rotation of keys and provides a higher level of security. The basic rules are:

• EIGRP will send messages using the lowest-numbered valid key
• EIGRP will receive messages using any valid key

So, if there are 4 keys in a router's key chain, and the 1st key has expired while the 4th has not yet reached its valid date, the router will *always* send using the 2nd key, but will accept messages using keys 2 or 3.

To verify that EIGRP authentication is working properly, three commands are used:

show ip eigrp neighbors

This will show that neighboring routers are still up and that everything is working correctly. However, for the rare instance when that doesn't "just work" it's best to use:

show key chain

This command lists the valid keychain configuration and valid keys. If your keys aren't valid between all routers, it's not going to send or receive, and if your keys are valid, use:

debug eigrp packet

This command will list messages about why the intended neighbor routers did not authenticate. Typically, you will see messages that state "authentication mismatch" and then one of two reasons, either "invalid authentication" or "missing authentication". Both are relatively self-explanatory, don't you think?

Notes for troubleshooting EIGRP Authentication:

• make sure your time is accurate and matched using "show clock" and use NTP to sync time on all routers
• Key chain name and number do not need to match on all routers, *only the PSK (or key-string) needs to match*
• use show key chain to list which keys are valid
• Each interface must have EIGRP authentication configured on it (ip authentication mode eigrp md5) and the key chain assigned to it (ip authentication key-chain eigrp ) or authentication will fail with an invalid or missing authentication message in the EIGRP debug
  

EIGRP Passive Interfaces

In some cases, there will be a need to *not* send EIGRP information out a particular interface. To minimize network bandwidth consumption and congestion, it is possible to restrict hello packets to the 224.0.0.10 multicast address. We would do this by either configuring the interface as passive or by not enabling the EIGRP on that interface and using the "redistribute connected" command to send routing information about desired networks.

This scenario would be used when you have 3 offices connected by routers, perhaps using T1's. A T1 connects each router to every other router via serial port, and each router has 2 fast ethernet interfaces connected to different subnets in each office. When the "network" command is executed for each fast ethernet subnet, EIGRP will be enabled on those interfaces even though there is no legitimate EIGRP neighbor on those interfaces and EIGRP messages will go out those interfaces even though there is no need nor any desire for that traffic.

To limit this traffic, the preferred method is to set the fast ethernet interfaces to passive mode by executing the commands:

router eigrp 1
passive-interface fastethernet0/0
passive-interface fastethernet0/1
network
network

This will allow all WAN routers to be aware of routes to all LAN interfaces, but will not send any multicast or unicast messages out the fast ethernet interfaces. This will limit network utilization, as well as add to security by not broadcasting route information out interfaces that have no legitimate neighbors by design.

It is also possible to change the default behavior of EIGRP per ASN by using:

router eigrp 1
passive-interface default
no passive-interface serial0/0/0
no passive-interface serial0/0/1
network

This essentially changes the default so that all interfaces are configured as passive, and to allow EIGRP to broadcast out an interface, you have to disable the passivity.

To verify the configuration, we use "show ip eigrp interfaces" to see which are enabled. While this shows which interfaces EIGRP is enabled on, it does not show any passive interfaces. By using a "show ip protocols" command, we will see which networks are being routed using EIGRP as well as a specific list of passive interfaces.

Controlling route distribution using EIGRP is somewhat straight-forward in this respect. using passive-interfaces allows us to enable and restrict who sees what, allowing the fine-tuning and securing of networks.

EIGRP Review

The morning started with a review of EIGRP. I haven't considered EIGRP for quite some time and don't work with it daily, so a review is good.

EIGRP is a relatively simple protocol to configure from a basic level. With a few simple commands, it can be enabled on a router and will likely run without issue. All it takes is a "router eigrp" with an autonomous system number and a network command and away it goes.

router eigrp 1

network 10.0.0.0

Normally we'd want to add a wild card mask to the network statement, but when a statement like the above is entered, it will enable EIGRP on all interfaces that match the classful IP address in the network statement. If the wild card mask is added, it will apply ACL properties to apply EIGRP only on the interfaces which match the mask.

Commands for verifying the functionality of EIGRP would then be:

show ip interfaces This command shows which interfaces EIGRP is enabled on and routing, omits passive interfaces

show ip protocols Shows which protocols are in effect and which networks are being advertised, or rather the contents of the 'network' commands as well as a list of neighbor IPs

show ip eigrp neighbors Lists the routers who have established relationships with the router on which one is currently working, and does not list neighbors for which a mismatched parameter prevents a valid EIGRP neighbor relationship

show ip eigrp topology shows the topology table, including the successor, feasible successor route, but does not list all known topology details

show ip route Lists all the networks for which this router is aware, including details of how the route was learned (by which protocol, connected, etc) and the administrative distances. All EIGRP-learned routes are labelled with a 'D'

I spent some time reacquainting myself with these commands last night, and was glad to see that with a little effort, I'm able to hone in on the information needed to troubleshoot and resolve any issues. I was also glad to make a mistake in my EIGRP test lab, where I misconfigured an interface. When I added the network to my EIGRP ASN, the route did not propagate. It ended up that the network I added didn't contain the IP address of the interface, and therefore EIGRP knew that there was no information to send to its neighbors. Using 'show ip eigrp int' I was able to see that it was not enabled on all the interfaces for the router. I was then able to troubleshoot backward and see where my mistake had been made.

A good review for the night. I'll continue reviewing tomorrow.

CCNP Day 1

As I begin tonight on my completion of the CCNP certification, I read the intro chapter #1 of Cisco Press' CCNP Route 642-902 by Wendell Odom. My goal is to finish this certification in 7 weeks from today, or rather to test on June 17.

Breaking that down, it's about 100 pages each day to study. I'm planning to work through about 20 each day.

One thing that I wish I had paid closer attention to over the past couple years was my original intent to maintain my CCNA skills. When I achieved that certification in 2009, I intended to continually work through labs where I don't have much exposure at work. This was intended to keep me sharp and ready for recertification or upgrading to the CCNP. Well, today when I took the first "Do I know this" quiz, I realized that I haven't been designing or supporting any EIGRP over the last couple years and I have a bit of catching up to do. I work more with firewalls and switches in my daily job, and do very little (if any) routing. So....now I have some catching up to do.

But I am pretty pumped to get going. I was surprised to read that Cisco has removed QoS from the CCNP requirements. I was hoping to delve into that a bit in the near future to enable me to more efficiently support Cisco's Voice offering which my company recently began selling like crazy.

So today I read about the exam topics and some thoughts about how to prepare for them. There is a large design and documentation component to the CCNP, which include determining resources required, creating an implementation plan and creating a verification plan all before configuring and verifying the solution. After these, results are documented.

While there is no single planning style recommended by Cisco, their PPDIOO model seems most natural to my style. The steps involved here are:

1. Prepare
2. Plan
3. Design
4. Implement
5. Operate
6. Optimize

These are the steps of the Cisco Lifestyle Services, and it seems to me to make the most sense - that or I work in a Cisco shop and that's all I know. Either way, it will get the job done. I also am glad to see the focus on planning and documentation in the CCNP objectives. Working in a support role where I inherit various networks from all kinds of different vendors, I'm always amazed at how little anyone plans or documents when they build a network. More commonly, people throw components together without any thought or consideration for support, and when I finally get the call it's usually pretty ugly. Great for my troubleshooting skills, not great for a customer who relies on their network to get their job done.

So, here we go. For the next week I'll be working on EIGRP neighbors, topology, routes and convergence. It was incredibly valuable to me when studying for the CCNA to summarize my nightly work in a blog, so I'll be doing that here instead of on my personal blog to keep the geek stuff apart from the stuff regular people might be interested in. Feel free to comment, let me know what you think or if you have any words of wisdom for my study. Especially comment if I make a mistake or don't explain something well enough - I want this to be a quick reference for my review as well and can't afford to have mistakes in the info.

OK, then. CCNP Route exam in 7 weeks. Away we go...

Hello world!

Seems that is how these always have to start.

I've got some Cisco certifications to earn and a new endeavor into Cisco Voice. Stay tuned for more...