From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Tue Feb 04 2003 - 14:37:41 GMT-3
At 11:30 AM -0400 2/4/03, Joe Chang wrote:
>For my own lab attempts I didn't follow such an approach. In programming,
>over-designing something can lead to unforseen side-effects. I think this
>applies to configuring routers as well.
There's over-designing, but there's also designing for avoiding
errors and enhancing troubleshooting and maintainability. In
programming, the key concept of "information hiding" came from DL
Parnas in 1968. The idea is to hide as much information from lower
levels as possible -- less to get them confused and less overhead.
Most good routing architects practice significant information hiding,
although this doesn't always seem to be the CCIE Way, which freely
admits it doesn't reflect best current practices. In the real world,
stubbiness, defaults, aggregation, etc., all make things more
scalable and reliable.
It might be an interesting thing to put to the proctor -- "since
there is no requirement for externals or virtual links in this area,
is it acceptable for me to make it stubby to simplify its databases
and make troubleshooting easier?"
"Since this area either has only one ABR, or if there are no
requirements to do end-to-end route optimization (i.e., closest exit
is adequate), is it acceptable for me to make the area totally
stubby?"
>
>----- Original Message -----
>From: "Matthew Poole" <matthew.poole@blueyonder.co.uk>
>To: <ccielab@groupstudy.com>
>Sent: Tuesday, February 04, 2003 10:27 AM
>Subject: OSPF stub areas
>
>
>> More assumptions!
>>
>> Should I assume that OSPF areas should be configured as stubs if eligible
>to
>> be so, although the lab doesn't specifically request it?
>>
>> I've just completed a lab and in the solution they did this - why not take
>it
> > one step further and make it totally stubby?
.
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:07 GMT-3