Living in the underlay

I'm having lot of discussion with my students and colleagues regarding this topic and want to start by clarifying this question that someone made few time ago:

"Why do you teach Cobra SDK for CCIE DC curricula instead of pure raw REST API?"

The answer was quite simple "Is in the official curricula/blueprint and you need to master it"  but it has some drawbacks and I feel that some other things needs to be considered here:

• Embrace API: The freely way to operate is to use pure REST API and automate as you wish the service (at the end we want to cover some use case that serves some purpose and that can be considered a service for an specific end user - engineer, customer, etc- ). If you understand and comprehends how the API is structured and works it would be quite easy to automate that specific gear moreover you can even start thinking like that box/system ;) [1]

• SDK is a huge toolbox, use it wisely: The SDK just provides you a toolbox to quickly start coding without messing around with a **huge** API set, but even if it seems the easy way there are some caveats to consider: The SDK packages common operations into functional boxes (methods) for you to consume, however that doesn't mean that all your pretty weird use cases will be covered/reflected into the SDK [Even if they say that the SDK reflects the API, I've not met a single SDK from a network vendor that covers their full set of API operations into the SDK and lets not even start talking about documentation..].

• Don't reinvent the wheel: If you're planning to move towards a pure REST API model i'm happy for you (really, not sarcastic) but consider: are you going to encapsulate the specific device on your specific package/model? If the answer is yes for each specific device my first response would be "why not to use the SDK on the first time?" since you are deploying the same thing with a less code power than the vendor. if the answer is yes but not to a specific device but to a specific role in network we are start talking about good design choices ;) don't tie your code to a specific gear, make it independent and more on this...

• Don't repeat the past: If you're planning to use pure REST API to talk to a network device and you're thinking the legacy way you will end up in multiple API calls (being multiple equals to the lines of CLI commands that you need to enter in the device configuring by hand). So basically you will be doing old school network in a fancy way, why not starting asking devices about a desired state? (intent)

• Code a service not a function: Creating a [script/program/api] to do a specific task such as create vlan, trunk it, enable a protocol or even to do a correlate serie of tasks is not the same than creating a service, the aim of your code should be the service automation since network automation is well covered by many sources but service automation is specific to your business/use case (please have in mind that even if there are a lot of powerpoint $#$%$# around the probability that your use case is not a standard covered one is near to 99.99999%)

I was using this quite lot past weeks and think that is a good resource to share to everyone playing around with Cisco ACI. When it comes to tshoot and to understand packet flow inside the Fabric ELAM is a great tool.

So, what it is?

ELAM stands for Embedded Logic Analyzer Module, It is a logic that is present in the ASICs that allows us to capture and view one or more packets, that match a defined rule, from all the packets that are traversing the ASIC. ELAM is not new at all, some of you can remember this from CAT6500, and thats ok, same logic also same from N7K (for the youngest?).

and... whats new?

Essentialy the concept is still the same, an we just need to focus on understand how is the architecture inside the ASICs on Leafs and Spines to fully apply this concept.

Cisco ASIC data path is divided into ingress and egress pipelines where two ELAMs are present (see figure) at the beginning of the lookup block.

ELAM Example

For those attending to my CCIE DC v2 bootcamp next week, here is the updated outline, I will be posting updated diagram in few (remember this course is not based in any rack rental so interface numbering is up to that :) )

Introduction

Exam Considerations / Oveview / Strategy


Section 1 – Cisco Data Center Layer 2/Layer 3 Technologies

1.1 – Configure VDC Resources
1.2 – Configure NXOS multicast
1.3- Understanding VxLAN
1.4 – Configure vPC & Deployment options
1.5 – Configure FEX & Deployment options
1.6- Configure VxLAN L2/L3 GW (EVPN | F&L)
1.7 – Configure NXOS Security
1.8 – Configure& Troubleshoot Spanning Tree Protocol
1.9 – Configure & Troubleshoot OTV


Section 2 – Cisco Data Center Network Services

2.1- ACI Service Graph
2.2 – RISE
2.3 – Unmanaged devices in ACI
2.4 –Configure Shared L3 Services


Section 3 – Data Center Storage Networking and Compute

3.1 – Configure FCoE
3.2 – Cisco UCS Connectivity
3.3 – UCS QoS
3.4 – Service Profiles
3.5 – Configure advanced policies
3.6 – Configure Cisco UCS Authentication
3.7 – Configure Call Home Monitoring
3.8 – Troubleshoot SAN Boot
3.9 – UCS Central Basics
3.10 – UCS Central Advanced configuration & tshoot


Section 4 – Data Center Automation and Orchestration

4.1 – Introduction to scripting in Python / cobra SDK
4.2 – Python Programming with ACI Advanced
4.3 – UCS Director Basics
4.4 – UCSD Advanced Workflows Design


Section 5 – ACI

5.1 – Understanding ACI Fabric Policies
5.2 –Understanding ACI Access policies
5.3 – ACI external L3 connectivity in shared resources
5.4 – ACI L2 bridge / L2out
5.5 – ACI VMM integration

Well, I think that if you are in an IE track you probably read a lot about this day and prep prior to it. I will not bore you with all the same stuff and I will only summarize few steps that I took.

• Lab Day

All that you have read still applies, be familiar with lab location, have a good meal and arrive early, I will add also "be confident" probably you where working on this track for a the past months so this day you will transfer all that knowledge that you gather into the lab

• Lab Experience

For v2 there are some changes, first of all is the introduction of a DIAG section. DIAG is composed of a series of scenarios in which you got some input from client and need to diagnose the issue. It's really no complex at all, if you have some prior experience in show commands you should not face any issue. Also is good to know that *based on all the output provided* only one question is correct. You're granted of one hour to end DIAG, notice that if you end early you will not have access to the lab, after one hour the lab would be started for you and you will get access to devices and questions.

In lab there's not much to say, use your own strategy, read carefully (I really encourage you to read all the questions first, at least once) and do only what is asked. Lab is hard, I will not lie to you, but if you train well and have practice you will find it possible :), remember be confident, avoid getting stuck with a question if you feel that something is taking you so much time just make a note and go ahead. Other really useful recommendation, and related to ACI, is to take snapshots, I found it very useful when I was making changes in ACI to have some snaps to quickly come back after modifying stuff that hurt my tenants :)

After the exam, relax, watch Vikings and release anger/stress/anxiety or whatever you feel, news will come (in my case it took up like almost 48hs....)

Well I think that here things get more exciting, lets talk about preparation that I face for CCIE DC, v1 and also v2.

As you may notice I've failed v1, it was in April of this year, and fail by so little (literally, doing maths it was about 2 points..,), for that (v1) my prep was based on:

• INE CCIE v1 bootcamp (Nexus Switching)
• Lot of knowledge of Nexus / UCS
• Minimal rack lab practice...

As you may notice, being confident could be one of your biggest enemy, so instead of thinking that you may know something is better if you can practice (a lot) to get faster and confident for real lab.

So lets forget v1 and start talking of v2, lot of new stuff: UCS Central, UCS Director, VXLAN, Cisco AVS and, as you may know, ACI.

Lets summarize:

• UCS Central / UCS Director

For this Cisco community and particularly DevNet workflows was the best, also I practice a lot basic tasks like creating pools, tshooting pool asignments (from UCS C) and from Director side I created basic workflows like configure vlans, service profiles and some ACI workflows.

• VXLAN

Also to tackle VXLAN I followed this:

- Understand control plane options: Flood and Learn & BGP EVPN

- Understand how to configure in the different nexus families: Nexus 5K & Nexus 7K, Cisco documentation is good for N5K but not so good for 7K, let say that scenarios presented are not complete at all and are so different from a real case, I made a review of those documents but didn't get a reply from cisco yet. A workaround that I've found for such poor doc at 7K was using 9K documentation in NX-OS mode, configuration is pretty much the same :)
Those are the docs I've used:

VXLAN @7K: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/vxlan/configuration/guide/b_NX-OS_VXLAN_Configuration_Guide/overview.html

VXLAN @5K: http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/layer2/7x/b_5600_Layer2_Config_7x/b_5600_Layer2_Config_7x_chapter_010010.html

VXLAN @9K: http://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/118978-config-vxlan-00.html

• Programmability

One of the interesting topics was about programmability in ACI, I really love Python and this point wasn't a headache to me,  if it is to you you will be able to find great tutorials on the web (I will also write down some in a few days), if you have some knowledge and you are familiar with data model of ACI and terminology you can go directly to Cisco Developers page, amazing doc there: https://developer.cisco.com/media/apicDcPythonAPI_v0.1/install.html

• ACI

In all of this process I've spend like three months, practicing every day with CCIE HOME guys and mock lab scenarios, I can tell for sure that I've tested much more that what I've found on real lab so when I saw real scenario I didn't feel scared (well just a little). In next posts I will write down about overall lab experience and recommendations, hope this would be helpful for all aspirants for this AMAZING TRACK.