Re: Core technology definition / more switching

Hi Andrew!

My expanded blueprint is based on the original Cisco blueprint. I then
"expand" it. :-) Right now I am busy adding links to all the topics.
After that - I want to bold those that I consider students should know
cold without any reference to the DOC-CD.

As far as whether a topic is core or non-core (effects reachability or
does not), I think you will master that as you practice more with full
labs. When you run into specific questions about that, of course, do
not hesitate to ask.

Warmest Regards,

Anthony J. Sequeira, CCIE #15626
http://www.INE.com

Test your Core Knowledge today!
Q: How many levels of nested policers is supported with MQC?
A: three
More Info: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/hierpol.html

On Oct 21, 2009, at 10:10 PM, ALL From_NJ wrote:

> Hey team,
>
> This is buggin me a little tonight and figured I would 'ask the
> experts' ...
> buggin me especially with the recent emails about the latest v4 lab.
>
> I believe a core technology is defined as one that affects all
> others, or
> one that must be set up first. In other words, this technology must
> be
> working before we can attempt other configs. Example:
>
> Routing and route filtering. Obviously routing is core, and the
> filtering
> might be considered a non-core tech.
>
> Now ... question related to new topic. If all of these are non-
> core, can we
> assume nothing else depends on them? Example might be MPLS and route
> filtering or tagging at remote ends. You cannot tag at remote ends
> if the
> routes were not received.
>
> Team - I want to make sure my time is spent wisely and accordingly
> to the
> core / non-core.
>
> OER / PFR has me worried a little as this can affect routing ... and
> we know
> all the problems that can / will occur when routing changes on us.
> The zone
> based fw thing seems like a non-core tech ... hopefully only worth
> 0.25
> points (wishful thinking).
>
> Anthony, I think you are the one with the expanded blueprint. Is your
> 'expanded blueprint' organized in core / non-core format?
>
> Lastly, with no switches in the tshooting section, can we assume
> there would
> be additional switching stuff in the config section? I know about
> assumptions ... forgive the way I ask this question please.
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed Oct 21 2009 - 22:57:59 ART