This post is related to my new initiative called Design Expert Weekend.
The pilot workshop for DEW: IPv4/IPv6 Routing Design, will be held in Olaya, Riyadh, on Friday-Saturday 3-4 January 2014.
What:
Design Expert Weekend in Riyadh on 3-4 January will focus on IPv4/IPv6 Routing Design. Agenda will cover:
- IGP IPv4 and IPv6 Design (OSPF, ISIS, EIGRP)
- BGP Design
- Routing scalability and Inter-AS
- Traffic Engineering
- Routing Fast Convergence and High Availability
- Multicast Routing Design
- CCDE exam tips and tricks
- CCDE sample questions and scenario to practice ability to analyze design requirements, develop network designs, implement network design, validate and optimize network design
The other two DEW will be held in separate session:
DEW:Tunneling Design (MPLS-based L3VPN/L2VPN, tunnel protection/MPLS TE, other tunnelling include IPv6 transition)
DEW:SP Design (Physical, L2, IGP/BGP/MPLS/PIM as transport, MPLS-based services, Internet, IPTV, HA, QoS, security, management)
Why:
To help network engineers to gain real design skills. DEW can help with CCDE exam preparation, and beyond.
Our main goal is not to make you certified. But to give the real knowledge. The real skills. Then to be certified or not it's your decision not ours.
Who:
Any network engineers/architects who want to learn design skills can join the workshop, even we prefer you to have several years of experience working with network devices.
Himawan Nugroho will be the mentor for this DEW. He holds three CCIE#8171 in R&S, Security, SP track and CCDE#20130018. Himawan has total 14 years experience in network design, with the last 7 years working for Cisco Advanced Services as Solutions Architect. He has worked in many design projects for Cisco important customers in Asia, Europe, Middle East and Africa.
Where:
Holel meeting room in Olaya, Riyadh, KSA.
When:
Friday-Saturday, 3-4 January 2014 from 8 am to 5 pm.
How:
2-day workshop to discuss design aspect of IPv4/IPv6 routing in detail. The class will be small (4-6 max) to ensure lots of interaction. Expect to see heavy discussion on design options for each technology covered. There will be discussion of CCDE exam tips and tricks, sample questions and scenario. Materials used for this workshop will be public material (non-NDA). Anyone who joins the workshop will be part of DEW community that will be formed as follow up after the workshop.
There is fee to attend each DEW that will be used to cover the expenses such as renting the meeting room for 2-day workshop, wireless Internet, lunch, coffee break, my accommodation, effort to build workshop material and so on. And after all the expenses, the remaining will be used to fund my organization back home.
The reservation is first come, first serve.
And your seat will be guaranteed only after you have completed the payment.
Please send email to info@jawdat.com to get more detail information.
Sunday, December 22, 2013
Tuesday, December 17, 2013
Project DEW
I don't want to claim myself as Global Consultant anymore. It seems like many people have problem with that. Some called me showing off, some said I'm too proud with that title. Others even said I spent so much time marketing myself. Blah blah. Ok, ok, I get it.
But here is the fact: since I joined Cisco in 2006 I've traveled to many countries to do consulting projects. Below you can see some Cisco customers in Asia, Europe, Middle East and Africa that I worked with in the past. And most of the time my role in the project is to lead the design work: to capture customer requirements and provide technical solution to address them. In many projects I also lead the implementation and migration. For some projects I'm responsible to lead the whole engagement from project scheduling, managing resources as well as quality assurance for deliverables. So call me anything you want, even Janitor, but it seems like I have some experiences working on design consultancy project, globally.
And actually before I joined Cisco I had already done many design project as well with many customers. I invented my own methodology and workflow for design work. I call the methodology as - I bet you are going to like the name - CISCO way. Yes, I'm not joking. You heard it here first. And I'm sharing it here now.
My CISCO way is actually an abbreviation of the following:
C - Capture customer requirements, current network design, today's challenges and future requirements
I - Identify what customer wants vs. what customer needs, identify the root cause of today's challenges
S - Solve today's challenges, address current and future requirements with the proposed solution design
C - Communicate the proposed design to customer to get feedback and discuss more design options
O - Optimize the design to achieve the best solution for the customer
I have been involved in many design workshop with customers. I have spent countless hours discussing design options for different technologies and customer industries, and writing both high level and low level design documents. I won't call myself as a Design Expert even with total 14 years experience in the field as network consultant and solutions architect. I also happen to have CCDE certification. And from my observation, as well from many emails I received, I understand there is a need for many network engineers to get design skill and get certified in CCDE if possible.
So today I want to launch my personal initiative to the world that I call Project DEW.
DEW stands for Design Expert Weekend.
It's a 2-day onsite workshop during the weekend to discuss various design technologies just as what CCDE covers. There will be discussion about multiple design options. There will be discussion about tips and tricks and my personal experience taking the exam several times (without violating the NDA). There will be discussion about CCDE-like scenarios. The workshop will be inline with skills expected from a CCDE: ability to analyze design requirements, develop network designs, implement network design, validate and optimize network design. The workshop can help you to pass CCDE. And even beyond.
In my previous post, I mentioned you need the following to pass CCDE practical exam:
1. Technical Skills, in L2 Control plane, L3 Control plane, Tunneling/Virtualization, QoS, Network Management and Security
2. Design Experiences, in multiple technologies as well as from vertical and different industries like SP, Enterprise, Financial, Retail and so on
3. Customer skills, such as ability to capture and analyze requirement, to propose design, to explain and justify the design, and to plan for implementation
DEW will try to cover all three points above as much as possible. Obviously nothing can replace the real design experience with the real customers, to achieve point 2 and 3. But the workshop will cover the technical skills in depth from the design perspective. DEW will not only explain What the technology is, but also Why it is required, How it works, Where to implement the technology, and When to use the technology compare to the alternatives. I will also share my view when looking at technology based on my design experience. And there will be discussion using CCDE-like design scenarios, so hopefully it can provide some level of experience in designing as well as some exercise to analyze requirement until proposing design to answer the requirements.
There are different types of DEW and each takes 2-day during the weekend:
DEW:Routing Design (IGP IPv4/IPv6, BGP, scaling, inter-AS, HA, and include PIM, ASM, SSM Multicast)
DEW:Tunneling Design (MPLS-based L3VPN/L2VPN, tunnel protection/MPLS TE, other tunnelling include IPv6 transition)
DEW:SP Design (Physical, L2, IGP/BGP/MPLS/PIM as transport, MPLS-based services, Internet, IPTV, HA, QoS, security, management)
The pilot for DEW:Routing will be held in Riyadh in two weeks. The class size will be small and limited to ensure lots of interaction. There is fee to attend that will be used to cover the expenses to conduct the workshop such as renting the meeting room, projector, accommodation and so on. And after all the expenses, the remaining will be used to fund my organization back home.
My main goal is not to make you certified. But to give the real knowledge. The real skills. Then to be certified or not it's your decision not mine.
If you are interested to join the first DEW:Routing in Riyadh, KSA, on 3-4 January 2014, please send email to info@jawdat.com to get more detail information.
See you at the first DEW!
But here is the fact: since I joined Cisco in 2006 I've traveled to many countries to do consulting projects. Below you can see some Cisco customers in Asia, Europe, Middle East and Africa that I worked with in the past. And most of the time my role in the project is to lead the design work: to capture customer requirements and provide technical solution to address them. In many projects I also lead the implementation and migration. For some projects I'm responsible to lead the whole engagement from project scheduling, managing resources as well as quality assurance for deliverables. So call me anything you want, even Janitor, but it seems like I have some experiences working on design consultancy project, globally.
And actually before I joined Cisco I had already done many design project as well with many customers. I invented my own methodology and workflow for design work. I call the methodology as - I bet you are going to like the name - CISCO way. Yes, I'm not joking. You heard it here first. And I'm sharing it here now.
My CISCO way is actually an abbreviation of the following:
C - Capture customer requirements, current network design, today's challenges and future requirements
I - Identify what customer wants vs. what customer needs, identify the root cause of today's challenges
S - Solve today's challenges, address current and future requirements with the proposed solution design
C - Communicate the proposed design to customer to get feedback and discuss more design options
O - Optimize the design to achieve the best solution for the customer
I have been involved in many design workshop with customers. I have spent countless hours discussing design options for different technologies and customer industries, and writing both high level and low level design documents. I won't call myself as a Design Expert even with total 14 years experience in the field as network consultant and solutions architect. I also happen to have CCDE certification. And from my observation, as well from many emails I received, I understand there is a need for many network engineers to get design skill and get certified in CCDE if possible.
So today I want to launch my personal initiative to the world that I call Project DEW.
DEW stands for Design Expert Weekend.
It's a 2-day onsite workshop during the weekend to discuss various design technologies just as what CCDE covers. There will be discussion about multiple design options. There will be discussion about tips and tricks and my personal experience taking the exam several times (without violating the NDA). There will be discussion about CCDE-like scenarios. The workshop will be inline with skills expected from a CCDE: ability to analyze design requirements, develop network designs, implement network design, validate and optimize network design. The workshop can help you to pass CCDE. And even beyond.
In my previous post, I mentioned you need the following to pass CCDE practical exam:
1. Technical Skills, in L2 Control plane, L3 Control plane, Tunneling/Virtualization, QoS, Network Management and Security
2. Design Experiences, in multiple technologies as well as from vertical and different industries like SP, Enterprise, Financial, Retail and so on
3. Customer skills, such as ability to capture and analyze requirement, to propose design, to explain and justify the design, and to plan for implementation
DEW will try to cover all three points above as much as possible. Obviously nothing can replace the real design experience with the real customers, to achieve point 2 and 3. But the workshop will cover the technical skills in depth from the design perspective. DEW will not only explain What the technology is, but also Why it is required, How it works, Where to implement the technology, and When to use the technology compare to the alternatives. I will also share my view when looking at technology based on my design experience. And there will be discussion using CCDE-like design scenarios, so hopefully it can provide some level of experience in designing as well as some exercise to analyze requirement until proposing design to answer the requirements.
There are different types of DEW and each takes 2-day during the weekend:
DEW:Routing Design (IGP IPv4/IPv6, BGP, scaling, inter-AS, HA, and include PIM, ASM, SSM Multicast)
DEW:Tunneling Design (MPLS-based L3VPN/L2VPN, tunnel protection/MPLS TE, other tunnelling include IPv6 transition)
DEW:SP Design (Physical, L2, IGP/BGP/MPLS/PIM as transport, MPLS-based services, Internet, IPTV, HA, QoS, security, management)
The pilot for DEW:Routing will be held in Riyadh in two weeks. The class size will be small and limited to ensure lots of interaction. There is fee to attend that will be used to cover the expenses to conduct the workshop such as renting the meeting room, projector, accommodation and so on. And after all the expenses, the remaining will be used to fund my organization back home.
My main goal is not to make you certified. But to give the real knowledge. The real skills. Then to be certified or not it's your decision not mine.
If you are interested to join the first DEW:Routing in Riyadh, KSA, on 3-4 January 2014, please send email to info@jawdat.com to get more detail information.
See you at the first DEW!
Sunday, December 15, 2013
Superman, Immortal, Janitor
"What's the difference between Solutions Architect and Technical Leader?"
Someone asked me that question last week. We all know the answer: none. It's just a damn title. Title doesn't matter. It never does. Batman once said: it's not who you are underneath, it's what you do that defines you.
In my current organization, that focuses on consulting services, there is a distinction between Solutions Architect and Technical Leader role in career path for technical person. (Himawan, but you said there is no such thing as career path? Well, let's save the debate for some other time).
As seen in below figure, Network Consulting Engineers (NCE) make progress from level I to level IV, and this is the point where he/she can make decision: either to stick as NCE then becomes Technical Leader someday, or to move to become Solutions Architect. He/she can actually move to any other position across the organization like pre-sales consultant or project manager or business development manager or even accountant! But let's keep the discussion between the path of Technical Leader and Solutions Architect.
So what's the difference between the two then?
Both must have excellent soft skills: communicate effectively, above average presentation skills, team player and so on. Both must have superb technical skills. Both must face customer in various projects from time to time so it is expected to have customer oriented mindset.
Perhaps the difference is in the focus: a Technical Leader should be a Subject Matter Expert in one or more technologies. A Solutions Architect, as the name implies, should be focusing on end-to-end solutions architecture. Technical Leader should put more focus on deep down technical stuff, while Solutions Architect even must still required to be a techie but the focus is on providing the complete solutions. Technical Leader produces white paper. Solutions Architect considers business architecture.
In reality it's really hard to find the distinction when both roles are in the field. I have worked with so many Technical Leaders and Solutions Architects and even Network Consulting Engineers, and they all pretty much do similar things. They all have the soft skills, technical skills, and customer oriented mindset. Throw away more responsibilities to these individuals: lead the project execution, manage team resources, build project schedule. Ask the individual to perform pre-sales: define the scope of work and calculate mandays. Let him or her integrate the whole solutions with another vendor. And the result is the Superman in networking.
But even Superman gets weak by kryptonite. Or fall to his colleague reporter. Is there anyone stronger that Superman?
Meet the Distinguished Engineers. They are way above both. They are the gatekeeper of computer networking industry. They work in leading edge technology from time to time. They are usually part of the expert community who write Internet standard. They were the first in my organization who talked about IPv6 or SDN. They involve first-hand then spread the knowledge to others. When people start talking about it they have already moved on to the next topic like Internet of Everything. They shape the future of the technology. They are the kungfu masters. They are the Immortals.
How about myself? Even my official title is Solutions Architect, I usually do all what I explained above: lead project, provide technical solution and design, talk business, do pre-sales, manage resource and so on. But I'm not the Superman. Most of the time somebody make a mess and I get called to clean it up. I won't discuss it in more detail here but let's just say I'm needed the most where it's required to connect the broken pieces. To wipe the floor. So I prefer to call myself the Janitor.
Superman, Immortal, Janitor. Which one do you want to be?
Someone asked me that question last week. We all know the answer: none. It's just a damn title. Title doesn't matter. It never does. Batman once said: it's not who you are underneath, it's what you do that defines you.
In my current organization, that focuses on consulting services, there is a distinction between Solutions Architect and Technical Leader role in career path for technical person. (Himawan, but you said there is no such thing as career path? Well, let's save the debate for some other time).
As seen in below figure, Network Consulting Engineers (NCE) make progress from level I to level IV, and this is the point where he/she can make decision: either to stick as NCE then becomes Technical Leader someday, or to move to become Solutions Architect. He/she can actually move to any other position across the organization like pre-sales consultant or project manager or business development manager or even accountant! But let's keep the discussion between the path of Technical Leader and Solutions Architect.
So what's the difference between the two then?
Both must have excellent soft skills: communicate effectively, above average presentation skills, team player and so on. Both must have superb technical skills. Both must face customer in various projects from time to time so it is expected to have customer oriented mindset.
Perhaps the difference is in the focus: a Technical Leader should be a Subject Matter Expert in one or more technologies. A Solutions Architect, as the name implies, should be focusing on end-to-end solutions architecture. Technical Leader should put more focus on deep down technical stuff, while Solutions Architect even must still required to be a techie but the focus is on providing the complete solutions. Technical Leader produces white paper. Solutions Architect considers business architecture.
In reality it's really hard to find the distinction when both roles are in the field. I have worked with so many Technical Leaders and Solutions Architects and even Network Consulting Engineers, and they all pretty much do similar things. They all have the soft skills, technical skills, and customer oriented mindset. Throw away more responsibilities to these individuals: lead the project execution, manage team resources, build project schedule. Ask the individual to perform pre-sales: define the scope of work and calculate mandays. Let him or her integrate the whole solutions with another vendor. And the result is the Superman in networking.
But even Superman gets weak by kryptonite. Or fall to his colleague reporter. Is there anyone stronger that Superman?
Meet the Distinguished Engineers. They are way above both. They are the gatekeeper of computer networking industry. They work in leading edge technology from time to time. They are usually part of the expert community who write Internet standard. They were the first in my organization who talked about IPv6 or SDN. They involve first-hand then spread the knowledge to others. When people start talking about it they have already moved on to the next topic like Internet of Everything. They shape the future of the technology. They are the kungfu masters. They are the Immortals.
How about myself? Even my official title is Solutions Architect, I usually do all what I explained above: lead project, provide technical solution and design, talk business, do pre-sales, manage resource and so on. But I'm not the Superman. Most of the time somebody make a mess and I get called to clean it up. I won't discuss it in more detail here but let's just say I'm needed the most where it's required to connect the broken pieces. To wipe the floor. So I prefer to call myself the Janitor.
Superman, Immortal, Janitor. Which one do you want to be?
Wednesday, December 04, 2013
About Promotion
There is no such thing as career path.
I wrote this several years ago. And I believe it's still true. For those who don't understand why I wrote such thing, please spend few minutes to read that blog post before leaving nasty comment. (This means: you still can leave nasty comment after reading that post :))
Allow me to share my secret: patience is not my virtue.
Every time I want to change to new position, or to new job title, I move to new company. Some of my previous employers offered me promotion the moment I gave them my resignation letter. Some of them simply didn't care and just let me go. For those who offered me promotion, I never accepted the offer. I thought they should have offered that while I was still with them, not at my last moment in the company when I usually had decided to leave.
There was a time I even worked as independent contractor. Had to deal with the customer directly, defined the scope by myself, set the performance index, and delivered end-to-end solution to customer. No job title. No career. Hmm, good old days. Even it was only for several months before I got back into corporate job.
Eventually I managed to get promotion in one company. And the truth is, when I was given the new job title I didn't feel like it was a promotion. Because I've been doing the scope of work and assuming the responsibility of that new title for years, long before the company really made it happen.
So here is the complete statement: there is no such thing as career path for technical people, who still believe the only way to go up is by working hard in their current position. Most techies believe if they work hard and be good on what they do, somebody will eventually notice and give the reward.
I don't believe such thing exists anymore.
You may disagree as the experience is different for each individual. But based on my own experience, I can suggest you the following to get the promotion or target position you always dream of:
1. Define the target position you want to be
2. Assume responsibility and work with the scope of that target position, regardless of your current position or job title
3. Get the right attention from the right people
What is my next target position, you may ask?
I want to be able to put the title in my business card just as Mark's.
How about you?
I wrote this several years ago. And I believe it's still true. For those who don't understand why I wrote such thing, please spend few minutes to read that blog post before leaving nasty comment. (This means: you still can leave nasty comment after reading that post :))
Allow me to share my secret: patience is not my virtue.
Every time I want to change to new position, or to new job title, I move to new company. Some of my previous employers offered me promotion the moment I gave them my resignation letter. Some of them simply didn't care and just let me go. For those who offered me promotion, I never accepted the offer. I thought they should have offered that while I was still with them, not at my last moment in the company when I usually had decided to leave.
There was a time I even worked as independent contractor. Had to deal with the customer directly, defined the scope by myself, set the performance index, and delivered end-to-end solution to customer. No job title. No career. Hmm, good old days. Even it was only for several months before I got back into corporate job.
Eventually I managed to get promotion in one company. And the truth is, when I was given the new job title I didn't feel like it was a promotion. Because I've been doing the scope of work and assuming the responsibility of that new title for years, long before the company really made it happen.
So here is the complete statement: there is no such thing as career path for technical people, who still believe the only way to go up is by working hard in their current position. Most techies believe if they work hard and be good on what they do, somebody will eventually notice and give the reward.
I don't believe such thing exists anymore.
You may disagree as the experience is different for each individual. But based on my own experience, I can suggest you the following to get the promotion or target position you always dream of:
1. Define the target position you want to be
2. Assume responsibility and work with the scope of that target position, regardless of your current position or job title
3. Get the right attention from the right people
What is my next target position, you may ask?
I want to be able to put the title in my business card just as Mark's.
How about you?
Thursday, October 24, 2013
With SDN, Do We Still Need CCIEs?
"With SDN, we don't need CCIEs anymore. Anyone can run the network with a simple click-and-drag GUI." Really.
"SDN makes the knowledge of traditional networking is not relevant anymore. We need more people who can write code instead." Wow.
"SDN with Openflow removes all the current routing protocols. So why wasting your time to study CCIE?" Speechless.
Let's start with definition.
According to Wikipedia, SDN is "...an approach to building computer networks that separates and abstracts elements of these systems..." There are two important keywords there: separate, and abstraction. Separate means decouple Control Plane and Data/Forwarding Plane function. If in 'traditional networking' both Contol and Data functions are contained within a single device, SDN makes the separation so the Control plane can be moved to a device or system that is located at the central of the network. More intelligent control function that can see the whole network end-to-end.
And the Control plane can be customized, manipulated, re-programmed and so on, regardless the state of the Data plane. This is the first level of the abstraction.
Why is abstraction important? Because we want to separate the complexity. Think about building multiple layers that separate the function of whole networking components from Data Plane, Control Plane, and even beyond. Imagine if user only needs to deal with a GUI-based tool to manage and operate the network. He doesn't need to know about the complexity of how the GUI-based tool interprets his request and push it to the layer below. Imagine if programmer can build this network management tool without any need of knowledge how her code can connect to the network device to push the instruction. Imagine if researcher can develop new control function and create new rule what to do with the packet at Control Plane, without having to worry about how the device really forwards the packet at Data Plane. You get the idea.
And is Openflow really the Holy Grail for SDN?
Using the same Wikipedia, OpenFlow is "...a communications protocol that gives access to the forwarding plane of a network switch or router over the network..." So it's just the communication protocol between one system, that most likely has the control plane function, with a switch or router over the network.
Hey, I thought we were talking about abstraction, how user can deal with only one layer, programmer deals with another layer, other programer deals with another layer, researcher deals with another layer, and so on. How OpenFlow can help with that?
Exactly.
Because OpenFlow is only one piece of the puzzle.
The above figure shows the big picture of something that we call Full Network Programmability. Beyond SDN. And definitely beyond OpenFlow, since OpenFlow is only one part that connect us to the network devices that do the actual forwarding of the packet. And OpenFlow is not the only protocol to do that.
And is that true we will completely remove the intelligence part from network device? Is that true we can use central Control function to manage those cheap dumb switches that only do the forwarding?
If you believe this separation of Control Plane and Data Plane is the only way. Some of us believe we still need to leave some control plane function in the device, even we have already had more intelligent control function at the central location of the network. A model we call 'Hybrid' SDN.
Why? So this 'distributed' control plane in network device can run basic function that doesn't require consultation to the central control plane. Because today's distributed control plane in network device has reached the stage of "self healing". It means if there is any failure with the link or neighbor device, it can find alternative way automatically. And these days it can find that alternative way in even much faster (Fast Convergence). Or it can pre-compute the alternative way and prepare the forwarding plane before the failure happens (Fast Re-route). Today's network with distributed control plane has become so resilient, closing the milisecond time gap between the start of the failure until the traffic forwarding is normal again.
The distributed control plane model has also reached a very high performance in a very high scale. It has intelligent security function and other features. In fact, it has a very rich feature-set. Those are the results of more than 25 years research by networking industry. And I personally won't believe all will be thrown away overnight.
So preserve what's working, and program the network when required.
That's what some people, including myself, believe.
This means we still need the CCIEs then.
Because they understand how traditional networking technologies work in detail.
But CCIE can't write code! And we need programmers to run the new network!
We need programmer to build network application indeed. But we need CCIEs to handle the complexity in lower layer. To handle how the application can interact with the network devices. To tell the programmer how they can leverage the current networking protocols to achieve the objective.
And what is the objective, by the way?
To solve customer's business problem.
What's the point to have a very sophisticated network infrastructure, with either traditional networking technologies or the new emerging SDN, if it doesn't help the customers with their business?
It's all about solving customer's business problem.
Always has, always will.
The problem can be: how to simplify the operation? That's why we develop tools for orchestration, to manage and monitor the whole systems. The problem can be: how to be more agile, much faster in deploying services? That's why we integrate tools in many layers so user can have a very simple and easy tool to use in upper layer, programmer build the system in another layer, and another programmer use the communication protocol to push the instruction to the devices. The problem can be: how to use the SDN to open up new business opportunities? That's why we look at virtualization to partition the network, so we can offer new business model to customer, and so on.
So someone, with extensive networking knowledge, still needs to talk to customer to understand the problem and figure out the way to solve it. And that has to happen prior to writing the code. So we still need CCIEs to capture customer requirements. We still need CCIEs to tell the customer that the traditional networking technology won't be able to meet the requirements. We still need CCIEs to tell programmer what to build in the first place.
Cisco Learning Network has defined the "workforce of the future" with job roles evolution and certifications, to prepare the engineers who currently work in networking industry to adapt to this new paradigm in networking.
Network Programmability Engineer: The network programmability engineer will be responsible for deploying the network applications into the programmable environment and making them operational. The engineer will receive the network application and the infrastructure design from the network programmability designer to deploy, install, and troubleshoot.
Network Programmability Designer: In an architect role, this individual will collect the customer requirements, be knowledgeable about the applications that leverage the infrastructure, and translate the customer requirements into a recommended open infrastructure. This individual will provide the functional specifications of the network applications to the network programmability developer.
Network Programmability Developer: The network programmability developer will be responsible for developing network applications in the programmable environment such as Cisco Open Network Environment (ONE). This is a new role focused on the development of the network applications layer, which can live in any of the Cisco provided programmable components, and will enable service provider, campus, and data center use cases. This individual is a software programmer able to program in Python, C, or other languages in an open networking environment.
Business Application Developer: This individual develops business applications such as for SAP and Oracle, leveraging the programmability capability of the new open network environment. This individual will also leverage API capabilities in order to collect information from the network.
Prerequisite for Supporting Cisco Network Programmability course (for Engineer)?
CCNP. With hands on Operating System experience, understanding of debug and troubleshooting tools specific to a virtualized, software and programmable environment.
Prerequisite for Developing Cisco Network Programmability course (for Developer)?
CCNA. Obviously with knowledge of Java, Python, C programming language and good understanding of virtualized environment.
Prerequisite for Designing Cisco Network Programmability course (for Designer)?
CCIE, with knowledge of programming environment, and Operating systems.
So CLN say we need CCIEs to become Network Programmability Designer.
And I personally believe the knowledge learned from CCIE/CCDE is crucial to support SDN, especially to become the architect who can translate customer requirements into functional specifications of the network applications to the developer:
CCIE Routing & Switching is the fundamental knowledge.
CCIE Service Provider teaches how to build "self healing" network.
CCIE Data Center becomes more interesting since many SDN use cases are currently focusing on Data Center, especially the Massively Scaled ones.
And CCDE put all the pieces together, making sure we know the reason behind when and why to use the technology. Go beyond the configuration level.
To summarize, we still need CCIE.
But those who have the quality as above.
And the most important: we need CCIEs who can adapt.
So to all CCIEs out there: prepare yourself.
Use Protect, Grow and Transform strategy to develop your skillset.
Protect, by making sure you understand the traditional networking technology in detail. Beyond CLI.
Grow, by learning the end to end solution. To understand the big picture of networking.
Transform, by understanding the application layer. To learn how to write code.
It's almost 4 am here in Dubai. Time to go back to my Python course.
"SDN makes the knowledge of traditional networking is not relevant anymore. We need more people who can write code instead." Wow.
"SDN with Openflow removes all the current routing protocols. So why wasting your time to study CCIE?" Speechless.
Let's start with definition.
According to Wikipedia, SDN is "...an approach to building computer networks that separates and abstracts elements of these systems..." There are two important keywords there: separate, and abstraction. Separate means decouple Control Plane and Data/Forwarding Plane function. If in 'traditional networking' both Contol and Data functions are contained within a single device, SDN makes the separation so the Control plane can be moved to a device or system that is located at the central of the network. More intelligent control function that can see the whole network end-to-end.
And the Control plane can be customized, manipulated, re-programmed and so on, regardless the state of the Data plane. This is the first level of the abstraction.
Why is abstraction important? Because we want to separate the complexity. Think about building multiple layers that separate the function of whole networking components from Data Plane, Control Plane, and even beyond. Imagine if user only needs to deal with a GUI-based tool to manage and operate the network. He doesn't need to know about the complexity of how the GUI-based tool interprets his request and push it to the layer below. Imagine if programmer can build this network management tool without any need of knowledge how her code can connect to the network device to push the instruction. Imagine if researcher can develop new control function and create new rule what to do with the packet at Control Plane, without having to worry about how the device really forwards the packet at Data Plane. You get the idea.
And is Openflow really the Holy Grail for SDN?
Using the same Wikipedia, OpenFlow is "...a communications protocol that gives access to the forwarding plane of a network switch or router over the network..." So it's just the communication protocol between one system, that most likely has the control plane function, with a switch or router over the network.
Hey, I thought we were talking about abstraction, how user can deal with only one layer, programmer deals with another layer, other programer deals with another layer, researcher deals with another layer, and so on. How OpenFlow can help with that?
Exactly.
Because OpenFlow is only one piece of the puzzle.
The above figure shows the big picture of something that we call Full Network Programmability. Beyond SDN. And definitely beyond OpenFlow, since OpenFlow is only one part that connect us to the network devices that do the actual forwarding of the packet. And OpenFlow is not the only protocol to do that.
And is that true we will completely remove the intelligence part from network device? Is that true we can use central Control function to manage those cheap dumb switches that only do the forwarding?
If you believe this separation of Control Plane and Data Plane is the only way. Some of us believe we still need to leave some control plane function in the device, even we have already had more intelligent control function at the central location of the network. A model we call 'Hybrid' SDN.
Why? So this 'distributed' control plane in network device can run basic function that doesn't require consultation to the central control plane. Because today's distributed control plane in network device has reached the stage of "self healing". It means if there is any failure with the link or neighbor device, it can find alternative way automatically. And these days it can find that alternative way in even much faster (Fast Convergence). Or it can pre-compute the alternative way and prepare the forwarding plane before the failure happens (Fast Re-route). Today's network with distributed control plane has become so resilient, closing the milisecond time gap between the start of the failure until the traffic forwarding is normal again.
The distributed control plane model has also reached a very high performance in a very high scale. It has intelligent security function and other features. In fact, it has a very rich feature-set. Those are the results of more than 25 years research by networking industry. And I personally won't believe all will be thrown away overnight.
So preserve what's working, and program the network when required.
That's what some people, including myself, believe.
This means we still need the CCIEs then.
Because they understand how traditional networking technologies work in detail.
But CCIE can't write code! And we need programmers to run the new network!
We need programmer to build network application indeed. But we need CCIEs to handle the complexity in lower layer. To handle how the application can interact with the network devices. To tell the programmer how they can leverage the current networking protocols to achieve the objective.
And what is the objective, by the way?
To solve customer's business problem.
What's the point to have a very sophisticated network infrastructure, with either traditional networking technologies or the new emerging SDN, if it doesn't help the customers with their business?
It's all about solving customer's business problem.
Always has, always will.
The problem can be: how to simplify the operation? That's why we develop tools for orchestration, to manage and monitor the whole systems. The problem can be: how to be more agile, much faster in deploying services? That's why we integrate tools in many layers so user can have a very simple and easy tool to use in upper layer, programmer build the system in another layer, and another programmer use the communication protocol to push the instruction to the devices. The problem can be: how to use the SDN to open up new business opportunities? That's why we look at virtualization to partition the network, so we can offer new business model to customer, and so on.
So someone, with extensive networking knowledge, still needs to talk to customer to understand the problem and figure out the way to solve it. And that has to happen prior to writing the code. So we still need CCIEs to capture customer requirements. We still need CCIEs to tell the customer that the traditional networking technology won't be able to meet the requirements. We still need CCIEs to tell programmer what to build in the first place.
Cisco Learning Network has defined the "workforce of the future" with job roles evolution and certifications, to prepare the engineers who currently work in networking industry to adapt to this new paradigm in networking.
Network Programmability Engineer: The network programmability engineer will be responsible for deploying the network applications into the programmable environment and making them operational. The engineer will receive the network application and the infrastructure design from the network programmability designer to deploy, install, and troubleshoot.
Network Programmability Designer: In an architect role, this individual will collect the customer requirements, be knowledgeable about the applications that leverage the infrastructure, and translate the customer requirements into a recommended open infrastructure. This individual will provide the functional specifications of the network applications to the network programmability developer.
Network Programmability Developer: The network programmability developer will be responsible for developing network applications in the programmable environment such as Cisco Open Network Environment (ONE). This is a new role focused on the development of the network applications layer, which can live in any of the Cisco provided programmable components, and will enable service provider, campus, and data center use cases. This individual is a software programmer able to program in Python, C, or other languages in an open networking environment.
Business Application Developer: This individual develops business applications such as for SAP and Oracle, leveraging the programmability capability of the new open network environment. This individual will also leverage API capabilities in order to collect information from the network.
Prerequisite for Supporting Cisco Network Programmability course (for Engineer)?
CCNP. With hands on Operating System experience, understanding of debug and troubleshooting tools specific to a virtualized, software and programmable environment.
Prerequisite for Developing Cisco Network Programmability course (for Developer)?
CCNA. Obviously with knowledge of Java, Python, C programming language and good understanding of virtualized environment.
Prerequisite for Designing Cisco Network Programmability course (for Designer)?
CCIE, with knowledge of programming environment, and Operating systems.
So CLN say we need CCIEs to become Network Programmability Designer.
And I personally believe the knowledge learned from CCIE/CCDE is crucial to support SDN, especially to become the architect who can translate customer requirements into functional specifications of the network applications to the developer:
CCIE Routing & Switching is the fundamental knowledge.
CCIE Service Provider teaches how to build "self healing" network.
CCIE Data Center becomes more interesting since many SDN use cases are currently focusing on Data Center, especially the Massively Scaled ones.
And CCDE put all the pieces together, making sure we know the reason behind when and why to use the technology. Go beyond the configuration level.
To summarize, we still need CCIE.
But those who have the quality as above.
And the most important: we need CCIEs who can adapt.
So to all CCIEs out there: prepare yourself.
Use Protect, Grow and Transform strategy to develop your skillset.
Protect, by making sure you understand the traditional networking technology in detail. Beyond CLI.
Grow, by learning the end to end solution. To understand the big picture of networking.
Transform, by understanding the application layer. To learn how to write code.
It's almost 4 am here in Dubai. Time to go back to my Python course.
Sunday, October 13, 2013
Protect, Grow, Transform
It's been a while since I wrote something in this blog. Long holiday season, moving house, multiple projects in neighbor country, were really occupying my time the past several months.
Yesterday I flew 16 hours from Dubai to San Francisco, had to queue 2 hours, and drove about 1 hour to San Jose for some company meeting in Cisco Head Quarter office. Now it's early morning here and I can't really sleep due to 11 hours time zone difference with Dubai, so I guess it's the right time to post new blog.
Last month I was moved to Architecture group for the new Intelligent Infrastructure Center of Excellence team for EMEAR region, focusing on IP NGN and Network Programmability. My current role as Solution Architect is not only to lead complex NGN projects, something that I've been doing for many years, but as well as to grow Cisco Advanced Services business in those focused technologies within the region.
One strategy that we just came up recently is to define the objectives of this new team. We classify the objectives using Protect, Grow, Transform terminology. For example, Protect by focusing on renewal business and ensuring the quality of project delivery, Grow by moving into architecture based solution and enabling field engineers for any new technology, Transform by opening new business opportunity with Software Defined Network and Internet of Everything.
From technical perspective, Protect means to ensure our NGN design skills and extensive experiences with current platform such as Cisco CRS, ASR9K etc are maintained and well documented hence can be re-used by field engineers to optimize the project delivery, Grow means to go to Cross Architecture collaboration and solution like FMC, unified access, IPv6, IP Optical, and new platform such as NCS family, and Transform means to enable ourselves with the comprehensive Cisco ONE solution.
While creating this strategy, I could see the same Protect, Grow, Transform can be applied for technical skill development plan for individuals. For example, for someone who works in Service Provider market he can "Protect" his relevancy with the market by keep improving his technical skills. If we relate this with Cisco certification it's almost mandatory for this individual to take CCIE SP and perhaps CCDE. He can "Grow" skills in Data Center to expand his horizon and to have end-to-end solution based knowledge, and he may even take CCIE DC certification. And to "Transform" himself for the upcoming Network Programmability, he should start getting adequate programming skills with Python or Java, and start looking at leading edge SDN solution such as Cisco OnePK and XNC.
Just like any organization, the only way to be successful as individual in this industry is by having a clear strategy to continuously developing the skill, by executing the strategy, and by preparing for any upcoming changes in the industry.
How about you? What will be your Protect, Grow, Transform?
Yesterday I flew 16 hours from Dubai to San Francisco, had to queue 2 hours, and drove about 1 hour to San Jose for some company meeting in Cisco Head Quarter office. Now it's early morning here and I can't really sleep due to 11 hours time zone difference with Dubai, so I guess it's the right time to post new blog.
Last month I was moved to Architecture group for the new Intelligent Infrastructure Center of Excellence team for EMEAR region, focusing on IP NGN and Network Programmability. My current role as Solution Architect is not only to lead complex NGN projects, something that I've been doing for many years, but as well as to grow Cisco Advanced Services business in those focused technologies within the region.
One strategy that we just came up recently is to define the objectives of this new team. We classify the objectives using Protect, Grow, Transform terminology. For example, Protect by focusing on renewal business and ensuring the quality of project delivery, Grow by moving into architecture based solution and enabling field engineers for any new technology, Transform by opening new business opportunity with Software Defined Network and Internet of Everything.
From technical perspective, Protect means to ensure our NGN design skills and extensive experiences with current platform such as Cisco CRS, ASR9K etc are maintained and well documented hence can be re-used by field engineers to optimize the project delivery, Grow means to go to Cross Architecture collaboration and solution like FMC, unified access, IPv6, IP Optical, and new platform such as NCS family, and Transform means to enable ourselves with the comprehensive Cisco ONE solution.
While creating this strategy, I could see the same Protect, Grow, Transform can be applied for technical skill development plan for individuals. For example, for someone who works in Service Provider market he can "Protect" his relevancy with the market by keep improving his technical skills. If we relate this with Cisco certification it's almost mandatory for this individual to take CCIE SP and perhaps CCDE. He can "Grow" skills in Data Center to expand his horizon and to have end-to-end solution based knowledge, and he may even take CCIE DC certification. And to "Transform" himself for the upcoming Network Programmability, he should start getting adequate programming skills with Python or Java, and start looking at leading edge SDN solution such as Cisco OnePK and XNC.
Just like any organization, the only way to be successful as individual in this industry is by having a clear strategy to continuously developing the skill, by executing the strategy, and by preparing for any upcoming changes in the industry.
How about you? What will be your Protect, Grow, Transform?
Monday, July 08, 2013
How to Prepare for CCDE Practical Exam
I was a bit harsh when I wrote: you have to be CCIE to pass CCDE. Couple of friends of mine, who are not CCIEs, came to me after reading that post and said I had demolished their hope to pass the exam.
I won't lie. It's easier to become CCDE if you have already had a CCIE. But fear not, there is still chance for non-CCIE to pass CCDE exam as well. And several guys who are not CCIE but able to put their name in this Hall of Fame is the proof.
The next CCDE practical exam date is on August 27. So there is still time for both groups of CCIE and non-CCIE to pass it, and here is another version of "how to prepare for CCDE exam" that may help to do so:
1. You still need a good reason to do it
You need a good reason as your main motivation to keep continue pursuing this certification, after you fail the exam. Or after you fail the exam several times.
So find your reason.
2. You still need the experience
You can't skip experience. I'm not kidding.
From CCDE Techtorial it says "CCDE Practical is multidimensional, each question or problem must map to all three blueprints"
And the three blueprints are:
- Task Domain
- Job Tasks
- Technology
Scope of Job Tasks:
- Analyze design requirements
- Develop network designs
- Implement network design
- Validate and optimize network design
You can try to learn those from case study, you can try to practice using sample scenarios from books or from training material, but the best resource to learn the above is always the experience.
It's recommended to have 7+ years related experience, as shown in table from Cisco Learning below, with multiple technologies covering from Routing and switching, Security to Data Center.
It's easier to get opportunity to work with the design of those various technologies if you are a CCIE. Ok, nevermind, I will stop pushing it.
3. Learn the technology
First, you have to do "self assessment" by checking your current knowledge against the technologies listed in CCDE Written blueprint. From CCDE Techtorial, the technologies include but not limited to:
- Layer 2 control plane (STP, Fabric, Down detection, Failure domain, multicast, FHRP etc)
- Layer 3 control plane (OSPF, ISIS, EIGRP, BGP, PIM, Modularity, Hierarchy, FC/Resiliency, Core topology etc)
- Network virtualization (802.1q, MPLS L3VPN, L2VPN, L2TPv3, IPsec, GRE, routing, scaling, inter-AS, traffic engineering etc)
- Quality of Services (classification, CBWFQ, WRED, shaping, policing, QoS model, hierarchy, QoS inside tunnel etc)
- Network Management (FCAPS, SNMP, Syslog, Netflow, RMON, In band, OOB, baseline etc)
- Security (DDoS, GTSM, RPF, IPsec, Infrastructure security, QoS as security tool, RTBH etc)
Assess yourself to identify the technology that you are already familiar with, the one that you heard about it before but need more time to study, and the technology that is completely alien to you.
Once you have the result you will know where you should put your focus on.
4. Read or watch
Well, August 27 is near so I guess there is no time to read all the books in CCDE Practical Reading Booklist. But at least you should read Russ White's CCDE Quick Reference, for written exam, and Optimal Routing Design book. And you can skim the scenarios in Definitive MPLS Network Design book. Those three books are the only ones I read during my study.
And nowadays if I want to learn something new, or to re-fresh my mind, I prefer to watch Cisco Live 365 recorded session instead of reading books. I actually watched more than 40 videos during my preparation, and some of them are not relevant to CCDE exam.
So even if you have to watch 40+ Cisco Live sessions like me, you still have more than 40 days to do that until the next exam date.
Watch one video per day, at least.
And focus on why and when to use the technology.
If you have spare time, spend at least another hour per day to read CVDs/Design Zone.
Remember, stay away from CLI but you still need to understand on which device to enable the features.
I use iPhone as my daily phone, but to watch Cisco Live sessions I use HTC One black edition. No, you don't have to buy one to become CCDE. And I have no affiliation with HTC. I'm just happy to use it to watch any videos while on the move.
5. Remember Task Domain during your study
The third blueprint is Task Domain blueprint:
- Merge/Divest
- Add Technology
- Replace Technology
- Scaling
Try to consider the third blueprint when learning about the technologies, for example:
- Merge/Divest
How to merge two L3 control plane? What is the implication? What are the steps required to implement?
- Add Technology
What will be impact to QoS if customer adds new technology like Telepresence? Any security concern when adding new services?
- Replace Technology
What is the best network virtualization technology to replace the current physical technology e.g. TDM? Which one is better to the other, on which type of scenario?
- Scaling
How to scale each IGP? How to scale virtualization technology like GRE or L2VPN?
6. Master the skill of skimming
Make sure you are used to read many information within short time, skimming rather than reading completely, and find the information that's important.
I think that's all.
And below are some of Cisco Live sessions that I watched during my study:
To refresh the IGP, Tunneling, and WAN Concept design:
- BRKRST-2310 Deploying OSPF in a Large Scale Network
- BRKIPM-3010 Which Routing Protocol? IPv4 and IPv6
- BRKIPM-2444 EIGRP – An in depth look at the Protocol
- BRKMPL-2101 Deploying L2 Based MPLS VPN
- BRKCCIE-3345 CCIE Candidate Introduction to MPLS L3VPN
- BRKCRS-2041 Enterprise WAN Architectures and Design Principles
- BRKMPL-2109 MPLS Solutions for Cloud Networking
- BRKRST-2042 Highly Available Wide Area Network Design
To refresh Campus design and QoS:
- BRKCRS-2661 Designing Layer 2 Networks - Avoiding Loops, Drops, Flooding
- BRKCRS-2031 Multilayer Campus Architectures and Design Principles
- BRKRST-2501 Enterprise QoS or BRKCRS-2500 Campus QoS
I did "speed watching" the following:
- BRKSEC-4054 DMVPN Deployment Model
- BRKRST-2301 Enterprise IPv6 Deployment
- BRKSEC-2000 Secure Enterprise Design
- BRKMPL-1261 IP Multicast Concept Design and Troubleshooting
Some Cisco Live sessions that were not recorded, but I went through the slides:
- BRKRST-2335 IS-IS Network Design and Deployment -
- BRKIPM-2261 Deploying IP Multicast
- BRKMPL-2105 Inter-AS MPLS Solutions
- TECSEC-2011 IPSec and SSL VPNs
Good luck and let me know when you get your number!
I won't lie. It's easier to become CCDE if you have already had a CCIE. But fear not, there is still chance for non-CCIE to pass CCDE exam as well. And several guys who are not CCIE but able to put their name in this Hall of Fame is the proof.
The next CCDE practical exam date is on August 27. So there is still time for both groups of CCIE and non-CCIE to pass it, and here is another version of "how to prepare for CCDE exam" that may help to do so:
1. You still need a good reason to do it
You need a good reason as your main motivation to keep continue pursuing this certification, after you fail the exam. Or after you fail the exam several times.
So find your reason.
2. You still need the experience
You can't skip experience. I'm not kidding.
From CCDE Techtorial it says "CCDE Practical is multidimensional, each question or problem must map to all three blueprints"
And the three blueprints are:
- Task Domain
- Job Tasks
- Technology
Scope of Job Tasks:
- Analyze design requirements
- Develop network designs
- Implement network design
- Validate and optimize network design
You can try to learn those from case study, you can try to practice using sample scenarios from books or from training material, but the best resource to learn the above is always the experience.
It's recommended to have 7+ years related experience, as shown in table from Cisco Learning below, with multiple technologies covering from Routing and switching, Security to Data Center.
It's easier to get opportunity to work with the design of those various technologies if you are a CCIE. Ok, nevermind, I will stop pushing it.
3. Learn the technology
First, you have to do "self assessment" by checking your current knowledge against the technologies listed in CCDE Written blueprint. From CCDE Techtorial, the technologies include but not limited to:
- Layer 2 control plane (STP, Fabric, Down detection, Failure domain, multicast, FHRP etc)
- Layer 3 control plane (OSPF, ISIS, EIGRP, BGP, PIM, Modularity, Hierarchy, FC/Resiliency, Core topology etc)
- Network virtualization (802.1q, MPLS L3VPN, L2VPN, L2TPv3, IPsec, GRE, routing, scaling, inter-AS, traffic engineering etc)
- Quality of Services (classification, CBWFQ, WRED, shaping, policing, QoS model, hierarchy, QoS inside tunnel etc)
- Network Management (FCAPS, SNMP, Syslog, Netflow, RMON, In band, OOB, baseline etc)
- Security (DDoS, GTSM, RPF, IPsec, Infrastructure security, QoS as security tool, RTBH etc)
Assess yourself to identify the technology that you are already familiar with, the one that you heard about it before but need more time to study, and the technology that is completely alien to you.
Once you have the result you will know where you should put your focus on.
4. Read or watch
Well, August 27 is near so I guess there is no time to read all the books in CCDE Practical Reading Booklist. But at least you should read Russ White's CCDE Quick Reference, for written exam, and Optimal Routing Design book. And you can skim the scenarios in Definitive MPLS Network Design book. Those three books are the only ones I read during my study.
And nowadays if I want to learn something new, or to re-fresh my mind, I prefer to watch Cisco Live 365 recorded session instead of reading books. I actually watched more than 40 videos during my preparation, and some of them are not relevant to CCDE exam.
So even if you have to watch 40+ Cisco Live sessions like me, you still have more than 40 days to do that until the next exam date.
Watch one video per day, at least.
And focus on why and when to use the technology.
If you have spare time, spend at least another hour per day to read CVDs/Design Zone.
Remember, stay away from CLI but you still need to understand on which device to enable the features.
I use iPhone as my daily phone, but to watch Cisco Live sessions I use HTC One black edition. No, you don't have to buy one to become CCDE. And I have no affiliation with HTC. I'm just happy to use it to watch any videos while on the move.
5. Remember Task Domain during your study
The third blueprint is Task Domain blueprint:
- Merge/Divest
- Add Technology
- Replace Technology
- Scaling
Try to consider the third blueprint when learning about the technologies, for example:
- Merge/Divest
How to merge two L3 control plane? What is the implication? What are the steps required to implement?
- Add Technology
What will be impact to QoS if customer adds new technology like Telepresence? Any security concern when adding new services?
- Replace Technology
What is the best network virtualization technology to replace the current physical technology e.g. TDM? Which one is better to the other, on which type of scenario?
- Scaling
How to scale each IGP? How to scale virtualization technology like GRE or L2VPN?
6. Master the skill of skimming
Make sure you are used to read many information within short time, skimming rather than reading completely, and find the information that's important.
I think that's all.
And below are some of Cisco Live sessions that I watched during my study:
To refresh the IGP, Tunneling, and WAN Concept design:
- BRKRST-2310 Deploying OSPF in a Large Scale Network
- BRKIPM-3010 Which Routing Protocol? IPv4 and IPv6
- BRKIPM-2444 EIGRP – An in depth look at the Protocol
- BRKMPL-2101 Deploying L2 Based MPLS VPN
- BRKCCIE-3345 CCIE Candidate Introduction to MPLS L3VPN
- BRKCRS-2041 Enterprise WAN Architectures and Design Principles
- BRKMPL-2109 MPLS Solutions for Cloud Networking
- BRKRST-2042 Highly Available Wide Area Network Design
To refresh Campus design and QoS:
- BRKCRS-2661 Designing Layer 2 Networks - Avoiding Loops, Drops, Flooding
- BRKCRS-2031 Multilayer Campus Architectures and Design Principles
- BRKRST-2501 Enterprise QoS or BRKCRS-2500 Campus QoS
I did "speed watching" the following:
- BRKSEC-4054 DMVPN Deployment Model
- BRKRST-2301 Enterprise IPv6 Deployment
- BRKSEC-2000 Secure Enterprise Design
- BRKMPL-1261 IP Multicast Concept Design and Troubleshooting
Some Cisco Live sessions that were not recorded, but I went through the slides:
- BRKRST-2335 IS-IS Network Design and Deployment -
- BRKIPM-2261 Deploying IP Multicast
- BRKMPL-2105 Inter-AS MPLS Solutions
- TECSEC-2011 IPSec and SSL VPNs
Good luck and let me know when you get your number!
Subscribe to:
Comments (Atom)