Thursday, August 25, 2011

Beyond CLI

So you passed CCIE yesterday. Congratulations.

Now what?

Don't stop learning. The lab exam forces you to know lots of concepts in IP network, to implement them by putting the configuration in the network devices using CLI*, to run all the protocols and features in a complex scenario, to debug and troubleshoot the problems. Not to forget all the non-technical aspect such as to work under the pressure and very tight timeline, to make lots of quick decisions, to learn how to find the information and to ask the right question.

But that's all.

With all my respect to CCIE program, there are lots more you need to learn when it comes to the real production network. There are lot of things you need to understand outside the topics asked in the lab exam.

There is a difference between running a feature, and running a feature with scalability, for example. Configuring BGP with route-reflector and lots of route policy, with multiple address-family and community set, seems like a piece of art. But will the same setup work when there are hundred of thousands IP prefixes? When thousands of prefixes are using /32 and /31? When the route-policy needs to balance the utilization between links to multiple upstream providers?

Multicast means a network device needs to do the replication from one incoming packet to multiple packets and send them each to interested outgoing interfaces. Who is doing the replication inside the device? Incoming or ingress side, or outgoing aka egress? Why does it matter? If the device is doing replication on ingress side it may congest the backplane or switch fabric in between the incoming and outgoing interface. If the replication is done on egress side, who should do the lookup to see which interfaces are interested? And how?

High availability, beyond the OSPF fast convergence configuration that you can copy paste from the documentation to the device console. Will you rely on IGP FC or would like to use MPLS TE? When the link fails, how to detect and inform the upper layer protocol? Will BGP flush the whole table immediately when the next hop is not reachable?

Talking about passing layer 2 over pseudowire, do the devices need to learn about the Mac address? If yes, how many number of Mac address maximum it can handle? How to carry the customer dot1q tag transparently? Can you bridge and route at the same time? How about the layer 2 mechanism to break the loop, how to integrate it with the pseudo wire network?

Which traffic needs to be protected when there is congestion? How if you have business customers and residential coming from the same physical interfaces? Will you use sub-interface to identify them or just match based on VLAN? Do you shape the residential or let them take the whole bandwidth when the business is not using it? How about protecting the voice traffic inside one type of customer? How many layers of QoS mechanism can you go?

What will happen if one of the Route Processor fails? What will happen if there is line card inserted when the device is online? What will happen if one switch fabric fails when the traffic is passing through?

What is In Service Software Upgrade? Can it really happen?

How about stress test? How to ensure the CPU can handle and process the request when it receives hundreds of thousands routes at the same time? What if the neighbor flaps during the process? Will you even consider to implement dampening?

How to protect the CPU when there is flooding in the control plane? And the most important, how to ensure the forwarding packet is not disrupted even when the CPU stays 100%?

And don't forget about interoperability. Interoperability of products from two different vendors, some bits may need to be changed even when you try to have a simple physical connection between two different vendors using Sonet. Interoperability of products from the same vendor but using different software. Interoperability between network devices and any other components in the network like load balancer, security devices, caching and clustered servers?

Typing fast in the console is not the most important anymore.
There are lots more beyond CLI.

And we are just talking about a small portion of the technical aspect here.

CCIE really is just a beginning.

*A command-line interface (CLI) is a mechanism for interacting with a network device operating system or software by typing commands to perform specific tasks.


inSecure said...

Really nice post.
I am working towards my CCIE also.

Maybe you can provide us with the answers to the questions ?:)


inSecure said...

Btw, you never said in your posts(i read all your posts btw) when did you find the time to learn for the 1st CCIE and 2nd.

I mean you learned after work, during work or you where not working at all ?

Himawan Nugroho said...

inSecure, you just need to go through the archives to find how I passed my 1st and 2nd CCIE

inSecure said...

Himawan Nugroho,

I read last week your whole blog. It was the 1st time i found it.

I really liked your ideas and the way you shared it(not technical related).

Your a guy that i admire, you followed your dream and reached it. You're inspiring.

I looked through your archive, but you never said when you find the time to learn.

If you learned after work/at work etc.

Anyway, maybe you can summarize it in a few phrases.

inSecure said...


I have found it:
06:30 Wake up, read some news on the Internet
07:00 Take my daughter to school
07:30 Sit and have discussion with my wife
08:00 Go to office
13:00 Lunch break, go home
13:30 Short nap
14:00 Back to office
17:00 Go home, family time
(if my family still take nap, I take my 2nd nap with them)
21:30 Wait until everybody's sleeping
22:00 Start my lab
03:00 (sometime more) Stop geeking out, go to bed
06:30 Wake up, back to the schedule for next day

EarlJ said...

Very good real-world questions! This is a sign of an experienced engineer.

Anonymous said...

that's too much on list to worry about........ these issues should be taken down while planning and designing sessions.....configs come later.....

step by step will solve this long list.

i like to keep things simple...