Monday, June 20, 2011

Handy Command ...

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

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.

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.

Thursday, February 3, 2011

BGP Conditional Default Route

Pretty much everyone knows that you can inject a default route to a neighbor in BGP by using a command like so:
router bgp 300
neighbor 164.18.46.8 default-originate

This will unconditionally inject a default route to that neighbor.  Note: They will still get all the other BGP routes as the router originating this command will not suppress the other routes just b/c it is injecting a default to them.  To conditionally set a default route you can use the route-map option at the end of this neighbor command.  See below:
router bgp 300
neighbor 164.18.48.8 default-originate route-map SW2-DEFAULT
neighbor 164.19.26.6 default-originate route-map R6-DEFAULT

ip access-list standard BGP-SW2
permit 192.168.2.0

ip access-list extended BGP-R6
permit ip host 192.168.2.0 host 255.255.255.0

route-map SW2-DEFAULT permit 10
match ip address name BGP-SW2

route-map R6-DEFAULT permit 10
match ip address name BGP-R6

So as you can see here the big difference is the access-lists right?  One is a standard ACL, the other is an extended ACL.  So whats the difference?  Well the first one will allow the default to originate if there in an entry in the routing table that will match that route, no matter the mask (192/8 , 192.168/16, 192.168.2/24) ...all would work.  The extended acl actually defines a mask, a /24 to be picky in this case. 

This is just something I ran into and found interesting when I was trying to filter using that route-map option originally.  I looked it up, and found it here BGP REFERENCE ...strange that I never used this enough to remember it in my CCIP studies!

Sunday, January 30, 2011

Just a note for later....

Forward metric....in regards to OSPF External Type 2 routes

Got hit with this in a lab scenario today...honestly didnt even know it existed until I did a show ip route on a specific entry.  I will do a lab this week with a bit more information, but it is definitely interesting.

Still labbing everyday for those listening in.  4-6 hrs per day/7days a week.  Still feel weak in some areas, and looking forward to Narbik in 2 weeks!

Saturday, January 22, 2011

Selective Packet Discard

Well I can officially add this hidden ios feature to my "bag of things I will probably not ever use in real life" tricks.  It actually serves a cool function to prioritize the "important" router traffic within the input queues on an interface.  Control plane traffic such as IP prec 6, IGP traffic, etc...can be placed in additional priority headrooms that will be serviced first over the regular input queue during times of congestion.  Here are some Cisco links on it:

Doc 1
Doc 2

Friday, January 14, 2011

INE

Well as I have mentioned before I purchased Internetwork Experts CCIE v4 self-study package....damn.  This is the most challenged...and humbled that I have been since beginning my Cisco certification/career journey several years ago.  I originally hit the labs pretty fast and furious, and have in the last week really talked myself into slowing down...and going via best practice of reading the lab...drawing the diagrams, and trying to really understand whats going on in the network that I am working on.  Sometimes this is a bit harder than it sounds, especially when you hit a level 9/10 lab, with multiple points of mutual redistribution, ipv6, multicast, rip, ospf, bgp, ospfv3, security, management, and qos....gets rough.  But tonight I have had some epiphanies..slowing down and nailing task after task.  I should keep it like this for a while...when the foundation is in tact I will work on speed. 

Thursday, January 6, 2011

Catalyst QoS

Well I am still here....chugging away with 30+ hours a week or so towards CCIE lab preparation. It IS hard work....I spent the last week going through the two preparatory Lab Books for Narbik's class that I am taking from micronicstraining.com in February. I am really looking forward to this! Since finishing those up though, I am back going through some INE Volume II labs. Did one on Tuesday...got killed with some Catalyst QoS stuff that I had never seen before, and some IP services items that I had just forgotten. I am going back through Vol I today on the portions where I was lacking. I was going to do a brief thing here on Cat QoS, but I found a blog article from the guys at INE that say it better than I ever could.

http://blog.ine.com/tag/per-vlan/