What is the Purpose of Route and Switch in CCDP?

philz1982

If all you do is design, and you have no desire to ever even touch a switch/router, then what is the point of taking the Route/Switch. Now I know they require those for the CCDP. Whether I think that is dumb or not is irrelevant but using the ARCH exam as a stepping stool to the CCDE then what really is the point of the Route and Switch?

Thanks,

darkerz

Call me crazy, but it's a reasonable inference when looking at someone who's aiming for Architecture & Design to have extensive, solid Operations and Implementation experience - and continue to hone that.

philz1982

I guess, I'm an odd duck. I've done a lot of design and only touched a switch/router for the CCNA. I design and I let the VAR's execute. It's more fun that way for me.

joelsfood

Agreed that the requirement makes sense. You can't come up with a proper design without understanding how the components work.

philz1982

I don't necessarily agree with you. I've engineered entire campuses, with multiple technologies. It would be impossible for me to know how to configure a Server, divide a SAN cluster, use the CLI to do configuration, use SQL command line to Setup SQL, ect ect.

I can design b/c I know how these technologies should work. When to use layer 2 vs 3, when to use separate ISP back-links ect. I guess it may be a difference between pre-sales design and operations.

I do appreciate any challenges to this point of view though.

darkerz

philz1982 wrote: »

I don't necessarily agree with you. I've engineered entire campuses, with multiple technologies. It would be impossible for me to know how to configure a Server, divide a SAN cluster, use the CLI to do configuration, use SQL command line to Setup SQL, ect ect.

I can design b/c I know how these technologies should work. When to use layer 2 vs 3, when to use separate ISP back-links ect. I guess it may be a difference between pre-sales design and operations.

I do appreciate any challenges to this point of view though.

Over at Microsoft, what's expected from a lot of Architecture / Design level folks in the revenue critical service organizations is that you run the project from a Pre-Sales to Post-Sales run.

You're there until it's been up for awhile - sometimes onto the next 2-5 year "refresh" cycle. The sense of ownership makes a lot of Architects very, very senior level operations folks too who will address what I'm about to type out-

What happens with SP's or outsourcing groups is they will lay out a high level design with some boots on 'ground considerations, but after go-live or even prior the consultant collects their fee's and is no longer needed. Support is handed off to the local team. The Operations and local staff engineers, in general, will make numerous tweaks, config changes, forwarding efficiency attempts or general protocol behavior changes once legacy or net-new dependencies are introduced into the network. A competent network design professionals goal is to minimize or eliminate all necessary tweaks and changes for at least an 18 month period after their Pre Go-Live or Go-Live phase gate.

You can make this happen with or without boots on ground experience, it's about how deep your protocol to application to human layer understanding is. Sometimes, someone who knows BGPv4 so well from a theory to application perspective, has written parts of the RFC and even acts as a contributor or partner with various vendors won't know a damn thing about how it's configured on specific Cisco or Juniper boxes.

And that's completely OK.

Short answer: "It Depends".

philz1982

I agree in principle with that happening, but that is how a lot of the clients we serve want to buy. You also have to consider I typically deal with new buildings or expansions not tech refresh or retrofit.

darkerz

philz1982 wrote: »

I agree in principle with that happening, but that is how alot of the clients we serve want to buy.

Awesome - as long as the customer is happy, you're boss and comp check is happy

networker050184

I agree you don't need any kind of routing and switch knowledge to do a design that says "this device talks to this device" at a high level. If you are designing a network down to the protocol, technologies, etc. then without the R&S knowledge you aren't going to have a clue.

philz1982

networker050184 wrote: »

I agree you don't need any kind of routing and switch knowledge to do a design that says "this device talks to this device" at a high level. If you are designing a network down to the protocol, technologies, etc. then without the R&S knowledge you aren't going to have a clue.

I do a kind of in the middle approach.

powmia

You design and let the VARs execute? Sounds like you come up with a plan or generate a BOM and let the VARs design. Thinking that taking an opportunity to better understand the functions of what you are "designing" is not worth the effort, because it isn't fun; is rediculous.

shodown

philz1982 wrote: »

I can design b/c I know how these technologies should work. When to use layer 2 vs 3, when to use separate ISP back-links ect.

This is true so to say, and it depends on your job role. If your internal to a company and you have big money to spend you can do this. Now in my role as designer, I have to take in account customer budget, skill of the staff, and supportability.

For example I was recently working with a customer with a multi-cluster call manager system. They wanted to be able to dynamically route numbers across the system, with failover to remote sites. In the cisco design doc this is 100 percent valid design. However when cost came in, configuration, and support, I had to tell the customer his staff was just not ready for this level of implementation and if this was the goal then we have to find a way to get them there. This of course meant the budget went up and eventually they decided to go with another solution.

How this relates to the topic at hand?

I understood how things would work conceptually, but I also understood them at a lower level and could translate that into how the staff would react and overall customer satisfaction which I felt would be sacrificed to complete this project. Our normal Solution architects who dont get much CLI time would have completely missed the boat.

SilverFish

CCDA is literally a 'brief overview' I honestly think CCNA, CCNA DC, CCNA-V, CCNA-S and CCNA-Wireless should all be pre-requisites to sitting CCDA. The route and switch track is in my mind the core.

I wouldn't dare include VOIP on my CV as a skill yet I just passed an exam which may suggest I know how to design VOIP networks - yet ive never even worked with VOIP. I may look at VOIP topologies now and think yeah I remember this... but I couldn't troubleshoot or roll out a VOIP network. In two minds as to whether I should exclude CCDA from my CV.

I think CCDA may come in useful, certainly it would have been useful when I was at uni before I began work, but now having worked at CCNP level I don't think its entirely relevant in my job (VOIP chapter). CCDP will definitely come in useful which is why I stuck at CCDA and am looking forward (genuenly) to studying it.

I really truly believe I was wrong to go sit this exam. The DC stuff is what I am really after and the progression onto the CCDP - but the VOIP chapter may open up a can of worms and cause me no end of problems.

gorebrush

How anyone can expect to become an expert in design without understanding truly how the technologies work at a fundamental level is a bit odd.

The CCDP is Cisco's product, and they clearly expect anyone who wants to call themselves a CCDP be able to fulfil the Route/Switch requirements. Makes perfect sense to me...