Spidey's net project

[spidey07]

Originally posted by: Buddha Bart
Random CCNA question...

Do you guys actually mess with the various timers in OSPF, or its administrative distance? Or is everything generally left at the default?

absolutely. depends on what you want to do. For example if this is a layer3 core you want ultra-fast convergence times (like under 5 seconds) so your hellos will be on the order of 1 second (this is all LAN so we don't care about lots of routing chatter). Lots of summarization as well and shielding the core from other areas, keeping the database clean and allowing the algorithym so run quickly if needed, etc.

hope this helps

 

[Mucman]

I think you guys are just mumbling crap.... all you have to do is plug it in, right?

 

[spidey07]

Originally posted by: Mucman
I think you guys are just mumbling crap.... all you have to do is plug it in, right?

come'r so I can smack you.

 

[cmetz]

Buddha Bart, OSPF is the work of some very clueful people (one very clueful person in particular - John Moy). The defaults and many of the protocol's behaviors are intended to be pretty safe. You CAN tweak a lot of things, but if you have to ask, you probably shouldn't. When tweaking, it is super critically important that you ask yourself "What bad things can happen if I change this?"

That said, folks routinely whine about the link bring-up time and the link down detection time. Tweaking the hellointerval and routerdeadinterval will mostly solve this. Also, some implementations cheat the specs and do the database exchange sooner than they're supposed to. If you have a LAN core with a solidly overengineered backbone, packet delay and loss aren't serious issues, so you can shorten the timers without much trouble.

 

[spidey07]

Originally posted by: cmetz
Buddha Bart, OSPF is the work of some very clueful people (one very clueful person in particular - John Moy). The defaults and many of the protocol's behaviors are intended to be pretty safe. You CAN tweak a lot of things, but if you have to ask, you probably shouldn't. When tweaking, it is super critically important that you ask yourself "What bad things can happen if I change this?"

That said, folks routinely whine about the link bring-up time and the link down detection time. Tweaking the hellointerval and routerdeadinterval will mostly solve this. Also, some implementations cheat the specs and do the database exchange sooner than they're supposed to. If you have a LAN core with a solidly overengineered backbone, packet delay and loss aren't serious issues, so you can shorten the timers without much trouble.

Great insight Cmetz. Follows the "it ain't broke, don't fix it" philosphy.

 

[Buddha Bart]

Ok, more questions not really related to helping you

How do you do all your configs? Does somebody actually console into every router, set 'em all up, and then I guess tftp a backup somewhere? If you use some software (I know Cisco has a product, i've just never seen/used it) what does it do for you?

 

[spidey07]

Originally posted by: Buddha Bart
Ok, more questions not really related to helping you

How do you do all your configs? Does somebody actually console into every router, set 'em all up, and then I guess tftp a backup somewhere? If you use some software (I know Cisco has a product, i've just never seen/used it) what does it do for you?

Lab testing then copy/paste configs onto each router sometimes with some debugging turned on but only after we know what the debugging will do to the router. Its really not that hard once you've played with it in the lab.

-edit- no need to backup the config. Ciscoworks does that for you automagically.

 

[nightowl]

Yeah, CiscoWorks is great for backing up configs. Usually for configs we work off a template for whatever class of Cisco hardware we are installing. From there the config is copied via TFTP to either start or run depending on the situation. If the config is copied and pasted into the console or telnet session certain attributes my remain unchanged if the correct statement is not put in place. For example, on the Cisco APs that have IOS a statement has to be put in place to remove the default SSID or else it will remain in the configuration. If the config is copied to start and then reloaded everything in fine.