Every wonder how to tell if you put a space at the end of your Cisco password? Well, if you have, or want to see if thats the case during troubleshooting try out this command:
show run | i _$
If you have a user like this in the output:
user cisco password cisco
It most likely means that the password cisco is really "cisco_" where the _ is a blank space! This also applies for items like ospf authentication, etc...
Monday, June 20, 2011
Wednesday, March 23, 2011
RMON - Absolute vs. Delta
I just wanted to put a link here as this is a topic that I never really chose to look that much into but it finally peaked enough interest tonight to do some research on it. Deepak simplified it so greatly in this post I found no real reason to rewrite it:
http://ieoc.com/forums/p/14069/125716.aspx
Here is Mr. Deepak Arora's post:
"Delta : For values that always increase
Absolute : For values that can increase or decrease
CPU utilization can go up or down (0% to 100%) so it would be an absolute value. Packets entering an interface will always accumulate (until the counters are cleared) so this would be a delta value. We’re (more likely to be*) interested in the number of packets during a certain interval (say the last 5 minutes) instead of the total number of packets since the counters were last cleared.
One of the ways that I determine whether to use absolute or delta is whether or not the “falling-threshold” can be attained. If a task has you configure a falling-threshold that cannot be reached (after the rising-threshold has been met) then I choose to use ‘delta’. For instance, if the task is referring to inbound packets (a value that always increases) and has a rising-threshold of 100 and a falling-threshold of 50, you can use ‘absolute’ but once the rising threshold is breached, the falling-threshold cannot be attained (unless the counters are cleared). This is either a poorly written task…or more likely you should use ‘delta’.
*Sure, we could monitor the absolute value of packets and generate an alarm when packets reach certain value (say 1 million) but that’s a pretty strange/ineffective alarm.
HTH...
Deepak Arora"
Well done sir...well done.
http://ieoc.com/forums/p/14069/125716.aspx
Here is Mr. Deepak Arora's post:
"Delta : For values that always increase
Absolute : For values that can increase or decrease
CPU utilization can go up or down (0% to 100%) so it would be an absolute value. Packets entering an interface will always accumulate (until the counters are cleared) so this would be a delta value. We’re (more likely to be*) interested in the number of packets during a certain interval (say the last 5 minutes) instead of the total number of packets since the counters were last cleared.
One of the ways that I determine whether to use absolute or delta is whether or not the “falling-threshold” can be attained. If a task has you configure a falling-threshold that cannot be reached (after the rising-threshold has been met) then I choose to use ‘delta’. For instance, if the task is referring to inbound packets (a value that always increases) and has a rising-threshold of 100 and a falling-threshold of 50, you can use ‘absolute’ but once the rising threshold is breached, the falling-threshold cannot be attained (unless the counters are cleared). This is either a poorly written task…or more likely you should use ‘delta’.
*Sure, we could monitor the absolute value of packets and generate an alarm when packets reach certain value (say 1 million) but that’s a pretty strange/ineffective alarm.
HTH...
Deepak Arora"
Well done sir...well done.
Sunday, March 13, 2011
EIGRP Ratio Calculation
This is a short post to discuss EIGRP ratio calculations. If you are so fortunate to be give a lab task that says.."We want Switch3 to route to 12.0.0.0 via Sw4 and Sw2 in a ratio of 3:1 respectively," this little thread should provide you with enough information to figure this task out on your own. Here goes:
This is our topology, and yes, 12.0.0.0 and the switches in the statement before are actually what we are going to use to do this. Currently all routers are in their the same EIGRP AS, and Sw3's routing and topology table for the route in mention looks like so:
I highlighted some of the pertinent portions of the config snippet. Heres the formula that I learned from Narbik for this type of situation:
3(158720) = 256 ( [10^7/100000] + [5200/10] + x)
Now this deems a bit of explanation...the left side of the equation is the route metric in the examples above, and we are multiplying this by 3 because thats what we want our ratio to be...3:1. So we want to figure out delay on the right (because that is what we want to manipulate here for EIGRP). The other stuff is pretty standard, 10^7/100000 defined by EIGRP for bw calculation, and the 100000 is defined as the minbw in the output above. 5200/10 is the delay in the above output divided by 10 to put it into the "tens of microseconds" category for EIGRP calculations. Finally x is delay, or better yet what we will end up with to add to our delay on the interface. Lets go!
3(158720) = 256 ( [10^7/100000] + [5200/10] + x)
476160 = 256 (100 + 520 + x)
476160 = 256 (620 + x)
1860 = 620 + x //--divided 476160 by 256
1240 = x //--subtracted 620 from 1860
So x = 1240...thats awesome. So do we just plug that in? One would think right, but we actually have one more step. If you were to plug that in, it would get you pretty close, but that needs to be added to what is actually on on our interface already. Lets look:
So our delay on there now is 100 microseconds. lets add that /10, or 10, to our previous x value.
1240 + 10 = 1250
Nice, lets see if that works!
Nope...hmm. Well we know that to do unequal cost load-balancing we need what? Variance of-course!
Now lets take a look..
And as I aptly named the picture...victory! Now I am honestly hoping that I dont get something like this in the real lab as it does take a little time to get it all perfected. Hopefully if I keep replicating the scenario I can get the whole process down to a minute or two. Well I hope this helped someone out there, if it did please leave a comment below! Thanks for the time.
I highlighted some of the pertinent portions of the config snippet. Heres the formula that I learned from Narbik for this type of situation:
3(158720) = 256 ( [10^7/100000] + [5200/10] + x)
Now this deems a bit of explanation...the left side of the equation is the route metric in the examples above, and we are multiplying this by 3 because thats what we want our ratio to be...3:1. So we want to figure out delay on the right (because that is what we want to manipulate here for EIGRP). The other stuff is pretty standard, 10^7/100000 defined by EIGRP for bw calculation, and the 100000 is defined as the minbw in the output above. 5200/10 is the delay in the above output divided by 10 to put it into the "tens of microseconds" category for EIGRP calculations. Finally x is delay, or better yet what we will end up with to add to our delay on the interface. Lets go!
3(158720) = 256 ( [10^7/100000] + [5200/10] + x)
476160 = 256 (100 + 520 + x)
476160 = 256 (620 + x)
1860 = 620 + x //--divided 476160 by 256
1240 = x //--subtracted 620 from 1860
So x = 1240...thats awesome. So do we just plug that in? One would think right, but we actually have one more step. If you were to plug that in, it would get you pretty close, but that needs to be added to what is actually on on our interface already. Lets look:
So our delay on there now is 100 microseconds. lets add that /10, or 10, to our previous x value.
1240 + 10 = 1250
Nice, lets see if that works!
Nope...hmm. Well we know that to do unequal cost load-balancing we need what? Variance of-course!
Now lets take a look..
And as I aptly named the picture...victory! Now I am honestly hoping that I dont get something like this in the real lab as it does take a little time to get it all perfected. Hopefully if I keep replicating the scenario I can get the whole process down to a minute or two. Well I hope this helped someone out there, if it did please leave a comment below! Thanks for the time.
Subscribe to:
Posts (Atom)