Archive for June 2013
CCIE: R/S Written Passed!
Finally knocked out the CCIE: R/S Written Exam!! The countdown has begun I’ve got 18 months to go pass the lab or I’ll be taking the written again!
If you’ve been following I’ve been studying for the CCIE: R/S for around a year now so the trek continues!
Now back to Cisco Live I go!!
Off to Cisco Live!!!
Looks like it’s time to start my drive to Orlando! I’m all packed and ready to go, got my iPad (with keyboard) so let’s see if I can get some blogging done in the midst of going between sessions and all the new announcements! (CCIE: R/S v5 especially!!)
I’ll probably be doing a fair amount of Twitter so feel free to follow and follow along – @StepehnO86
Why link latency is important for Cisco lightweight access points.
Link latency, it’s a convenient little check box you turn on individually (or globally) on lightweight access points (Operating in FlexConnect/H-REAP or OfficeExtend) to see the latency details to the controller, while this is one of those ‘yea that’s nice to know’ type things it can be a key resource when troubleshooting certain WLAN issues.
First lets start with why knowing the latency is important, well Cisco has published the requirements for CAPWAP latency from the LAP to the controller and that requirement is no more than 300 ms of latency. Now while most enterprise’s do not have to worry about those latency requirements too much (due to a typical MPLS, VPLS, or metro backbones) other types of companies that lets’s say rely on a pretty common DMVPN over the Wild West (the Internet) may have to keep in mind these latency requirements. If you do not meet these latency requirements you might be seeing CAPWAP packets drop in transit or your Flexconnect/H-REAP LAPs flapping between ‘Connected’ mode and ‘Standalone’ mode which depending on your setup can cause a host of issues.
Link latency will monitor the following:
- The round trip time of the CAPWAP heartbeat, it does this by comparing the timestamps of when the request is sent to when the reply is received. Now, by default this CAPWAP heartbeat occurs every 30 seconds and this CAPWAP latency is different from normal network latency, as the CAPWAP heartbeat also has a dependency concerning how quickly the controller can process the request and send the reply back out.
Something to keep in mind about the link latency stats, is the fact they do not reset unless the LAP reboots or they are manually cleared so if you decide to turn on link latency come back 6 months later and review the states you are not going to get any useful information.
Configuring and viewing Link Latency
As you can see from the above screen shot link latency will provide you a quick glance of the current latency, minimum latency, and the maximum latency to the controller. (From when link latency was first enabled or last cleared)
CCIE Challenge 1: Manipulating EIGRP Routing
So last week (Well actually months ago at this point) I was helping out one of buddies who is working on his ROUTE exam and he was working through an EIGRP load sharing lab involving the variance command and interface metrics, after I read through the lab and looked at the requirements I came up with a completely different way to complete lab then what was expected. So I figured I would alter the lab and post it up here:
Objectives:
- You want R1 to load share over links Serial0/0 and Serial0/1 that connect to R2 to reach the 3.3.3.3 /32 prefix on R3.
Rules:
- You cannot make any configuration changes to R1.
- You cannot create any static routes.
- You cannot create any additional interfaces.
- You cannot configure any additional routing protocols. (IE: OSPF, BGP, etc)
- You cannot change any AS types.
- You cannot change which EIGRP ‘k’ values are being used.
- You cannot change any of the metrics on the existing interfaces.
- The solution must involve EIGRP.
You can download the starting configurations here:
There is also a GNS3 .Net file included in there as well.
Have Fun!
CCIE or Null! 