Our CCIE Data Center version 2.0 Rack Rental system is now in beta testing phase. Click here to submit a request for beta access and I will contact you directly with more details on timing and availability.
Our CCIE DCv2 Rack Rentals consist of the following:
- Nexus 9300 ACI Spines
- Nexus 9300 ACI Leafs
- Application Policy Infrastructure Controller (APIC)
- Nexus 7000s with F3 line cards
- Nexus 5600s
- Nexus 2300 & 2200 10GigE Fabric Extenders
- UCS C series rack servers
- UCS B series blade servers
- UCS 6248 Fabric Interconnects
- Nexus 1000v virtual switch
- Dual 10GigE attached hosts for application testing
- Fibre Channel SAN
- iSCSI SAN
The visual topology topology diagrams are as follows:
Now that Cisco Live US 2016 is winding down, we’re going full steam ahead with our CCIE Data Center version 2.0 Blueprint updates. For those of you that haven’t seen it, my live blog of the CCIE DCv2 Techtorial @ Cisco Live US 2016 can help to answer some additional questions about the exam content and format changes.
Some important upcoming dates in the short term are:
- July 18th – 24th – DCv2 Bootcamp in Washington DC
- July 25th – CCIE DCv2 Written & Lab Exams Go Live
- August 1st – 5th – Online DCv2 Transition Technologies
- August 8th – 14th – DCv2 Bootcamp in Chicago
- August 15th – 21st – DCv2 Bootcamp in RTP
For those of you that have already spent time working on the DCv1 blueprint and are transitioning to DCv2, I would highly recommend to check out the online class the week of August 1st. I’ll mainly be focusing on the technologies that changed in the blueprint, such as Nexus 9k, ACI, BGP EVPN signaled VxLAN, etc.
Additionally, our new class and rack rental topology has been finalized. Some of the key topology changes are as follows:
- Nexus 9K 9336PQ ACI Spines
- Nexus 9K 9372PX-E ACI Leafs
- APIC-M2 ACI Controllers
- Nexus 7K supervisors ugraded to SUP 2E’s
- Nexus 7K linecards upgraded to F348XP-25′s
- Nexus 5K’s upgraded to 5672UP’s
- Nexus 2K’s upgraded to 2348UPQ’s
Visual topology diagrams for these changes can be seen below. Click the images for high-res versions.
Rack rentals are currently in beta until further notice. The scheduler shows all sessions booked, but I am taking beta testing requests directly if you email me at firstname.lastname@example.org
This morning I’m in Las Vegas for Cisco Live 2016, and am attending TECCCIE-3644 – CCIE DC Techtorial which focuses on the new CCIE Data Center v2 updates.
I’m live blogging the session so please feel free to submit your questions for the CCIE team as a comment here and I’ll try to get an answer for you.
Final Update - UCS M4308 is no longer part of the topology (device is End of Sale). The official blueprint has been updated to include the following software packages and versions:
- UCS Software Release 3.x Fabric Interconnect
- Cisco Data Center Manager Software v7.x
- Application Policy Infrastructure Controller 1.x
- UCS Central 1.x
- Cisco Integrated Management Controller 2.x
- UCS Director 5.x
- ASAv 9.x
Update 8 – 14:08PDT - Access to ESXi, VCenter, and CIMC will be allowed in v2 lab exam for troubleshooting tasks such as Nexus 1000v.
Update 7 – 14:03PDT - UCS Central will be tested on in the lab.
Update 6 – 13:55PDT - UCS will be running 3.x, not 2.x as currently listed on the blueprint.
Update 5 – 11:30PDT - Starting Storage Networking now. Interested to see what the scope is going to be now with the MDSes removed and the N9K’s added.
Update 4 – 09:15PDT - One major format change for the CCIE DCv2 Lab Exam is the introduction of the Diagnostics section, similar to other tracks such as RSv5. Here are some highlights and demo questions illustrating the format of the Diag section.
- Diag section consists of one or more independent Tasks.
- Each Task can have one or more Questions.
- Questions are typically 1 point apiece, but could be 2 or 3 points.
- Each Question within a task is graded individually. It is possible to get Task 1 Question 1 wrong but still get Task 1 Question 2 correct.
- The goal is to reach the minimum cut score, but the cut score is not published and changes between specific exam deliveries.
- Questions have deterministic answers. There is typically only one correct answer, but it’s possible that two answers are correct (e.g. multiple choice multiple answer). You must sort through all the information and find what is relevant and what is irrelevant.
- You CAN go back and forth between tasks and questions in diagnostics section, and you CAN change your answers.
- All information is needed is provided at once for each task. This is not the same as the CCDE engine where you get additional information as you go on
Update 3 – 08:57PDT - Timing of the Diagnostics and Configuration/Troubleshooting section are different from the R&S exam. Diagnostics is fixed at 60 minutes, and Config/TS is fixed at 7 hours. If you finish Diag early, you cannot add this additional time to Config/TS.
Update 2 – 08:30PDT - Grading is done manually by the proctors. Automated tools are used to gather information, but ultimately the pass/fail decision is up to the proctor. Tasks can have multiple solutions, and grading does check for this. Just because your solution works doesn’t mean it’s right. You have to meet the requirements of the question!
Update 1 – 08:29PDT - Don’t change the device passwords otherwise they can’t grade the exam. Hopefully this is self explanatory
Finally, Cisco has made the official announcement on the upcoming changes for CCIE Security Version 5. Both the written exam and the lab exam will be changes go live starting 31st of January 2017, which gives you the usual 6 months window to pass the Version 4 exam, before the change to Version 5 occurs. As opposed to the old blueprint, there are major changes in both the technical content and exam delivery format.
As expected, the new exam topics are inline with Cisco’s current Security product line with pretty much nothing missing. Yes, you got that right! Also, as expected, Cisco is trying to push the same exam delivery model for all CCIE tracks.
Blueprint Technical Topic Changes
We now have a Unified Exam Blueprint, covering topics for both the written and lab exam, similar to the change that was introduced with CCIE Data Center Version 2. The Blueprint for Version 5 is divided into 6 sections, with the last one being relevant only for the written exam:
- Perimeter Security and Intrusion Prevention
- Advanced Threat Protection and Content Security
- Secure Connectivity and Segmentation
- Identity Management, Information Exchange and Access Control
- Infrastructure Security, Virtualization and Automation
- Evolving Technologies*
*Written exam only
Topics removed from both written and lab exams:
- EzVPN is out now, as expected, Cisco is moving forward to its AnyConnect (IPsec and SSL) Remote Access VPN Client
- Legacy IPS, or Cisco’s old IPS technology, is out now as well
There are many topics added to the current blueprint. As we no longer have different blueprints for the written and the lab exams, it means that what’s in the blueprint can show up in both exams. Although based on the lab exam equipment changes, some technologies cannot be configured in the lab exam, you might still get questions about these technologies in the new Diagnostic section of the lab exam. This means that you should be prepared for the technologies as per the blueprint, for both exams.
New Version 5 Topics:
- ASA Clustering
- NAT for IPv6
- Cloud Web Security (CWS)
- Email Security Appliance (ESA)
- Content Security Management Appliance (SMA)
- Advanced Malware Protection (AMP)
- Virtual Security Gateway
- TrustSEC with SGT and SXP
- ACI, EVPN, VXLAN and NVGRE
- ISE Personas with multimode deployment
- MDM Integration with ISE
- Wireless concepts such as FlexCONNECT and ANCHOR
- NetFLOW/IPFIX and eStreamer
- APIC-EM Controller
- RESTful API in scripting languages such as Python
- Evolving Technologies (Cloud, SDN and IoT) being only in the written exam
Lab Exam Equipment Changes
As previously rumored, in Version 5 we have more equipment going virtual:
- FirePOWER Management Center version 6.0.1 and/or 6.1
- FirePOWER NGIPSv version 6.0.1
- Cisco FirePOWER Threat Defense version 6.0.1
- FireAMP Private Cloud
- Cisco ASAv version 9.1
- Cisco Application Policy Infrastructure Controller Enterprise Module version 1.2
- Email Security Appliance (ESA) version 9.7.1
- IOSv L2 version 15.2 (which is virtual IOS for layer 2)
- IOSv L3 version 15.5(2)T (which is virtual IOS for layer 3)
- Cisco CSR 1000v version 3.16.02S
- Cisco Unified Communications Manager version 8.6(1)
Other virtual devices have been kept from previous blueprint, with a version change:
- Cisco Identity Services Engine (ISE) version 2.1.0
- Cisco Secure Access Control System (ACS) version 220.127.116.11
- Cisco Web Security Appliance (WSA) version 9.2.0
- Cisco Wireless Controller (WLC) version 8.0.133
- Test PC is Microsoft Windows 7
- Active Directory is running on Microsoft Windows Server 2008
- AnyConnect version 4.2
As for physical devices we have the following devices in Version 5:
- Cisco Catalyst Switch C3850-12S 16.2.1 version 16.2.1
- Cisco Adaptive Security Appliance: 5512-X version 9.6.1
- Cisco 2504 Wireless Controller: 2504 version 18.104.22.168
- Cisco Aironet1602E version 15.3.3-JC
- Cisco Unified IP Phone 7965 version 9.2(3)
FirePOWER is the major new addition, where we have both the FirePOWER NGIPS and the FirePOWER Threat Defense (unified code for ASA and FirePOWER Services) being added, alongside with FirePOWER Management Center as the management platform. FireAMP will also be present through the private cloud appliance, used for advanced malware protection through big data analytics, policies, detections, and protections stored locally on premises.
ASA Firewall is now present through the physical model of ASA 5512-X, and the virtual model of ASAv. Addition of APIC-EM, which supports both the physical and virtual ASA models, is clearly interesting, being a strong proof about Cisco’s vision moving forward, which is clearly the adoption of SDN technologies in the Enterprise market.
As expected, ESA has been finally added to the game, as even in version 4 it was supposed to be in the lab exam, but Cisco decided in the end to skip it.
Routers and switches are now virtualized through IOSv for Layer 2/Layer 3 and CSR 1000v, exception being the 3850 switch model which most probably is there for some TrustSEC features not supported by virtualization (MACsec, SGT, SXP).
Finally, I would assume that the only scope for the Cisco Unified Communications Manage being in a Security CCIE lab, is for the IP Phone to register, which means you need zero knowledge about this technology.
Lab Exam Format Changes
The new lab exam format follows up with Cisco’s current vision of exam delivery, aimed to properly test you on different set of skills. The format is the same that was introduced with CCIE R&S Version 5, but of course with the Security technical topics instead of R&S ones.
The eight-hour lab format is now divided into three modules with order of the modules being fixed as follows:
- Troubleshooting module
- Diagnostic module
- Configuration module
- It’s 2 hours in length, you can optionally borrow 30 minutes from the configuration module.
- By the name, it’s a troubleshooting section, where you’ll be given a certain number of tickets/incidents that you need to fix. There is no inter-dependency between tickets and you can fix tickets in whatever order you want. You have access to devices consoles in order to reconfigure the network and fix the problems.
- This module is aimed to test your troubleshooting technical and methodology skills, and the ability to fix a problem from an unknown network topology within fixed allocated time.
- It’s 1 hour in length, and you cannot extend it
- By the name, diagnostic, it’s still a troubleshooting section, but in a different format; you’ll be given a certain number of tickets/incidents that you need to fix, there is no inter-dependency between tickets and you can fix tickets in whatever order you want; challenge is that you have NO access to devices console, instead, for each ticket, you’re being given many inputs (e-mail threads, diagrams, logs, traffic captures), out of which you have to diagnose the problem and select the correct answer(s)
- This module is aimed to test your ability to analyze and correlate multiple inputs related to a network problem within fixed allocated time, and without being given access to the devices you need to identity the root cause
- It’s 5 hours in length, but it can be 4.5 hours if you extended the troubleshooting module
- By the name, it’s a configuration section, where you’ll be given a certain number of configuration tasks, with access to devices console to implement the given requirements; this is nothing else but what was in version 4 the actual exam itself, as it had only one module; there will be dependencies between tasks, some of them will be explicitly stated, some of them you’ll have to figure it, are implicit
- This module is aimed to test your understanding of a solution design and architecture, of the traffic flows and dependencies within a network when multiple technologies are combined, ability to understand network requirements and translate it into working configuration within fixed allocated time
Passing the Lab Exam
In order to pass the lab exam, two conditions need to be satisfied:
- Pass each module, score enough points in each module to meet the minimum cut score for the module
- Total number of gained points must equal the minimum overall cut-score criteria
As each individual module tests you on different set of skills, though for the same technologies, the first criteria make sense, having to pass each module. This is to ensure that you have proved being an expert not only from the technology point of view, but also through the fact that you can make use that knowledge to fix various types of problems, being challenged in different ways. The minimum cut-score for each module is unknown, most probably because it could vary between different lab exam versions; for example you might get a more complex Diagnostic section with a lower minimum cut-score, or a less complex Diagnostic section with a higher minimum cut-score.
The second criteria also make sense, the minimum overall cut-score. This is probably to ensure that you don’t pass the exam if you passed each individual module with close to exactly the minimum module cut-score. Basically you can have a PASS for each module, but a FAIL for the exam. What this means, is that in order to have a PASS for the exam, you need to score more than the minimum cut-score for all modules, or only for some modules.
Although it might seem that you’re walking in blind, you go to the lab exam without knowing how many points are required to pass and in which of the three modules, this new lab exam format also has some benefits:
- It gives flexibility, as you can score less points in one module because of being less prepared or less knowledgeable, and more points in other modules
- It gives you a better focus, as you’re no longer chasing points in the exam, you’re now chasing to do your best in each module and prove your skills; this also implies a strategy change for the lab approach
- By passing the current lab exam format, you’ve become an expert in the field, with certified skills required to implement Cisco’s technologies into today’s and tomorrow’s networks
In conclusion, it’s now clear that if you want to become CCIE Security Version 5 certified, you will need more FirePOWER.
Congratulations to Neil Moore on passing the CCDE Practical Exam this week, and becoming a NONTUPLE (9x) CCIE & CCDE!
Neil was a student in both my CCIE Data Center Bootcamp and CCDE Bootcamp within the past few years, and is truly an inspiration to us all. Neil’s brother Kelly is also a CCIE in Data Center. Neil likes to introduce himself and his brother to people at Cisco Live that they have 9 CCIEs between the two of them! This year Neil gets to bump that up to 10 CCIEs and CCDE between the two of them!
Neil for sure will win the longest badge this year at Cisco Live 2016 Las Vegas!
Neil currently works for VMWare as an NSX Systems Engineer, is a VMware Certified Implementation Expert — Network Virtualization (VCIX-NV), and has plans to pursue the VMware Certified Design Expert (VCDX).
I recently received an email from a learner who is studying for his CCNA Routing-and-Switching Certification and he had a few excellent questions about the OSI model and how, exactly data moves from one-layer to the next. I figured my response might prove valuable to others studying for their CCNA so…here it is!
- Learner-Question: In video of the osi model, you said that the session layer should provide the source and destination port number but the fields of those ports are at the transport header- my question is how does the session layer put this number on field which does not exist in that time (when i send the date the encapsulation process goes down from the app layer)?
In order to thoroughly answer all of your questions below, one really needs to know about computer programming, APIs, etc…which frankly, I know very little about. But what I do know, I’ll try to explain. From my understanding, there are some kind of software “links” or “hooks” which are used to allow a program at one layer of the OSI model to communicate with a program at another layer. Many applications have software built-in that provide multi-layer functionality. For example, imagine that you open some kind of Terminal Client (like Hyperterminal, SecureCRT, PuTTY, etc). That software you’ve opened technically does not reside at ANY of the OSI layers. That software just provides the graphical display such as the buttons you can press, the pulldown menus available, etc. Now imagine that within PuTTY or Hyperterminal you press a button to initiate a Telnet connection. At that moment, the PuTTY software informs your CPU that the CPU must start the Telnet program. PuTTY provides the interface so you can see…and control…what is going on, but PuTTY itself is NOT Telnet. It’s simply the user-interface so you can control Telnet.
The functionality of Telnet actually is actually composed of an Application-Layer process as well as a Session layer process, all rolled into one. At the Application layer, the Telnet protocol answers such questions as, “what is a “username” and what is a “password” and is that required? Shall it send data downstream to lower-levels of the OSI model one-bit-at-a-time or several bytes-at-a-time? How is the user supposed to know when Telnet is waiting for input, versus currently transmitting output?” etc etc. The Session-Layer component of Telnet knows that it should be “listening” for incoming sessions on port-23. And when initiating outgoing sessions, it should use a destination port-23. At some point, the Telnet protocol creates a hook (I think these are called APIs) that allows it to invoke the Transmission Control Protocol (TCP). TCP knows that as part of the datastructure it creates, it must reserve 2-bytes for a “destination port-number” field and another 2-bytes for a “source port-number field” but what TCP DOESN’T know is what numbers to place in those fields. So this API (or whatever it is) allows the Session-Layer component of Telnet to convey to TCP that it place the value of “23” in either the Source or Destination Port Number field (depending on who is initiating the Telnet session).
You may now be thinking, “but what about the Presentation Layer? You didn’t include that in the Telnet process?”. I believe that once SecureCRT (or PuTTY or Hyperterminal) invoke your Application-Layer protocol (such as Telnet or SSH) that SecureCRT/Hyperterminal will provide the Presentation Layer-component. SecureCRT knows if, when you press a keystroke on your keyboard, that key should be represented by ASCII or EBCDIC, SecureCRT/Hyperterminal also knows if you pressed the button indicating that encryption should be used. So it kind of “merges” or “blends” all of that information into Telnet thus providing the Presentation-Layer components. I’m not sure HOW it does this…but it does.
- This question is about the type code field which lays at the llc sublayer, I understood that it purpose is to provide the upper layers what protocol is “talking”‘, how does it happens if the nic strips off the frame header in the decapsulation process?
Basically what I wrote above happens in reverse here. There is some kind of internal software “hook” (probably another API) that allows your Layer-2 protocol (Ethernet) to communicate the value in the EtherType field to the CPU. In this way the CPU knows if it needs to invoke a Layer-3 procoess (like IP) or…if that process is already running…to take the Data from the Telnet frame and forward it to the correct layer-3 process. So IP itself does NOT see that Ethernet frame or any of the fields within it. But that “hook” (API???) provides the interface so that Ethernet data can be transferred upstream to the IPv4 process. At this point, my knowledge of the specific details of how this works ends.
- If the type code provides the protocol(and its version), why does the IP header has “vers” field?
Once again, to answer this question I believe it’s all about the APIs that allow protocols at different layers to talk to each other. Moving downstream (from Layer-3 to Layer-2) when IPv4 (as an example) has created a full IP Packet, it will “call” the API that allows it to hook into the Layer-2 protocol. IP doesn’t even CARE what that Layer-2 protocol is. It probably does something like, “Hey Layer-2 hooking API!! I’ve got some data here. Please pass it on to whatever protocol is operating at the Datalink Layer for me!!” The API, because it is talking to IPv4 will then invoke whatever layer-2 protocol is running (Ethernet, HDLC, Frame-Relay, etc) and say, “I’ve got some Layer-3 data for you!!”. At that point, the Layer-2 protocol (Ethernet in this case) will say, “Great! Can you give me some number that I can shove into my Ethertype field that indicates WHICH Layer-3 protocol created the data?? I don’t really care personally…but the device at the other end of the link receiving this data will need to know!”. So the API (that was originally called by the IPv4 process and was DESIGNED to be an interpreter between IPv4 and Ethernet) will say, “sure…the number you need is 0×800!” and thus…Ethernet places that value into the Ethertype field. Receiving an Ethernet frame would work the same way but in reverse. This time the Layer-2 protocol would “call” that L2-to-L3 API and provide the data, ALONG WITH the value of the Ethertype field to that API. In turn, the API would then know it needs to call-out to IPv4 and transfer the data upstream.
This coming Tuesday, April 19th 2016, at 09:00 PDT (17:00 UTC) I will be joining the VIRL team for a discussion and demo of using cloud hosted servers, VIRL, and INE material for CCIE preparation, with a focus on large topologies (30+ devices). The Webex signup link is here. The session will also be simulcast on live.ine.com.
Specifically in this session I will be covering:
- How to deploy VIRL on cloud servers
- Loading INE topology files into the VIRL cloud instance through GIT
- Launching and managing multiple large topologies
Attendees will also have an opportunity to submit questions to me as well as the VIRL team.
Hope to see you there!
Rack Rentals for INE’s CCIE Service Provider v4 topology are now available at rentals.ine.com.
Both CCIE RSv5 Full Scale Labs and CCIE SPv4 now share the same topology in the scheduler, which consists of the following devices:
- 20 x IOS XE virtual machine instances (R1 – R20)
- 4 x IOS XRv virtual machine instances (R21 – R24)
- 4 x Catalyst 3560 physical switches (SW1 – SW4)
IOS XRv instances can be managed through the control panel similar to other devices in the topology, as seen below:
Cisco has just announced CCIE Data Center Written and Lab Exam Content Updates.Important dates for the changes are:
- Last day to test for the v1.0 written – July 22, 2016
- First day to test for the v2.0 written – July 25, 2016
- Last day to test for the v1.0 lab – July 22, 2016
- First day to test for the v2.0 lab – July 25, 2016
Key hardware changes in the v2.0 blueprint are:
- APIC Cluster
- Nexus 9300
- Nexus 7000 w/ F3 Module
- Nexus 5600
- Nexus 2300 Fabric Extender
- UCS 4300 M-Series Servers
Key technical topic changes in the v2.0 blueprint are:
- Policy Driven Fabric (ACI)
More details to come!
As we reported last April, Cisco changed the CCIE Lab Exam retake policy to an exponential backoff, meaning that the more attempts you took at the lab the more time you had to wait between attempts.
In a sudden change of heart, today Cisco announced that they are reversing their policy change until at least December 31st 2015. Per Cisco:
“For a limited time, we will waive the current lab retake policy so that all lab candidates will be able to retest for their lab exam with only a 30-day wait period.” “If you register for any CCIE lab exam between now and December 31, 2015, you will have the option of retaking the exam with only a 30-day wait regardless of the number of attempts you may have already made.”
Frequently Asked Questions about the policy changes:
Q: Does this mean that between now and December 31, I can take the lab every 30 days?
Q: Is the original policy back in place after December 31?
A: What happens after December 31 is dependent on the results of our research from now until that date.
Q: What does this mean if my current wait period is 90 days and I’m in the middle of the waiting period? Can I sign up now or do I have to continue to wait?
A: Yes, you can sign up now. You do not have to wait. The policy that is active at the time you schedule your lab will determine the time you have to wait. If you are beyond the 30-day wait period, you can book the earliest available seat you find.
Q: What if I’m already scheduled for a lab that I had to schedule out 90 days because of the original policy?
A: You will have the option to reschedule your lab attempt to an earlier date through the system.