Living in the underlay: DCv2

Showing posts with label DCv2. Show all posts

Thursday, July 6, 2017

Juniper DC Reading list

11:41 AM

One of my colleagues just asked me about the recommended reading list for the Juniper DC track (in particular what I've used to clear JNCIP-DC few weeks ago), here is a complete list of free resources that you can access to prepare yourself for the exam, I will also recommend (if you don't have any real/lab experience with QFX/EX for vxlan setup and mostly with VCF) to do some labs with vQFX (you can try out EVE-NG, which is *highly recommended*)

Here it is:

Juniper Networks EVPN Implementation for Next-Generation Data Center Architectures - https://www.juniper.net/assets/us/en/local/pdf/whitepapers/2000606-en.pdf

Virtual Chassis Fabric Feature Guide - http://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/qfx-series/virtual-chassis-fabric.pdf

Comparing Layer 3 Gateway & Virtual Machine Traffic Optimization (VMTO) For EVPN/VXLAN And EVPN/MPLS - https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/solutions/l3gw-vmto-evpn-vxlan-mpls.pdf

Clos IP Fabrics with QFX5100 Switches - https://www.juniper.net/assets/cn/zh/local/pdf/whitepapers/2000565-en.pdf

Virtual Chassis Fabric Best Practices Guide - http://www.juniper.net/documentation/en_US/release-independent/vcf/information-products/pathway-pages/vcf-best-practices-guide.pdf

EVPN Control Plane and VXLAN Data Plane Feature Guide for QFX Series Switches - https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-sdn/evpn-vxlan.pdf

Understanding Zero Touch Provisioning - https://www.juniper.net/documentation/en_US/junos/topics/concept/software-image-and-configuration-automatic-provisioning-understanding.html

Configuring Zero Touch Provisioning - https://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/software-image-and-configuration-automatic-provisioning-confguring.html

Configuring Zero Touch Provisioning in Branch Networks - https://www.juniper.net/documentation/en_US/release-independent/nce/information-products/pathway-pages/nce/nce-151-zero-touch-provisioning.pdf

Also another great book which I just end reading is "Building Data Centers with VXLAN BGP EVPN", this book is Cisco NXOS oriented but provides an amazing background on how VXLAN BGP EVPN Fabrics works.

HTH,

Sunday, May 14, 2017

CCIE DC v2 - bootcamp - outline

12:45 PM

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

Thursday, March 9, 2017

VxLAN Deep Dive Part III: Flood and Learn

10:19 AM

Rainy day ideal for continuing with the series of VxLAN :)

Part 1: Let's overlay -- Basic info about VXLAN, addressing and headers.
Part 2: It's all about knowledge -- Packet forwarding overview, VTEP control plane learning options
Part 3: Hands On #1 -- Configuration on Cisco Nexus Devices, Flood and Learn.
Part 4: Hands On #2 -- Configuration on Cisco Nexus Devices, EVPN.

Today we will focus on config, the funniest part of any IE track. In part 1 & 2 we cover fundamentals, now we understand how VxLAN works, how many addresses can we get and the different options of advertising MAC/IP information to peers. In this case we will start with Flood & Learn, I choose this one not only for being the first adopted but also to be the *poorly* documented on the web.

Note: If you want to find any VxLAN config info in NXOS I encourage you too look under N9K, since latest release of 7K will do the same and under 7K you will not find anything :)

Recommended reading: I've also mentioned this in the prep for DC IE track, but if you don't have the chance I really recommend Cisco Live Presentations, in this case BRKDCT-2404: VxLAN Deployment Models

Let's use this topology:

First we will define each component in the network:

H1 / H2 would be hosts in different VLAN, for this example VLAN 101 and 102.

L1 - L4 would be Nexus 5K running as VXLAN L2 GW.
L5 - L6 would be Nexus 7K running as VXLAN L3 GW

S1 / S2 will be the underlay L3 core between all the nodes, the L3 cloud also supporting multicast.

IGP + Multicast cloud

First things first, we need basic IGP reachability between our nodes plus multicast reachability. For multicast we are going to use static mapping for the RP and, in order to bring redundancy, we will deploy PhantomRP, of course you can use any other way that you want but, for the purpose of the example, static mapping is the simplest option. Here is the snippet of config in each device

L1 - L6

S1 / S2

Also the config for IGP is omitted here, since you can run whatever you want (also static routing right? yes! but lot of work), in our case we simply setup OSPF in area 0 and point to point interfaces in each link, the only consideration was the MTU, as you may recall from previous post of this series you will need to tune up MTU to be able to send a VXLAN packet inside, you can do the math by yourself (remember VXLAN adds an additional 8 byte field...) but lets assuming that anything beyond ~~1554~~ 1600 would be ok.

Just a minor note on Naming conventions

Before taking any other step further we will need to clarify some naming conventions that cisco has impossed to us :)

If you recall correctly each host in the VXLAN network has a VTEP which establish the tunnel and is , in the end, the responsible of taking in/out encapsulated packet to our vxlan network... Well for Cisco is quite different, since they don't have any host here messing around with VXLAN for them VTEP is the device responsible for the encap/decap process, but if VTEP is the device how do I configure the interface on that device in which this magic occurs? and here we come with NVE (Network Virtual Interface) which is the logical interface where the previous mentioned magic of encap/decap actually takes place.

VXLAN L2 Gateway

Well here the fun begins, at L2 of course. I've stated the concept of VXLAN L2 GW and thats because it is so important to understand how it works and what it does, the L2 keyword is key to understand this.
Let's asume you are running a legacy network, with VLANs in place and you want to integrate to a new design with VXLAN. Of course that you want not just to allow inter-routing between them but also allow to place some hosts in your new network in the same segment as the legacy one. Nice scenario... but how we can accomplish this?

Essentially what we need is a device capable of taking L2 frames, let's say tagged since I state that we've VLANs in place, and put them in the same bridge domain with the VXLAN traffic. Using different words to say the same what we want to accomplish is to put VLAN traffic into the VXLAN VNI associated to that traffic and be able to ~~flood~~ interact between them.

Here I will post two suggested options for config, one at the interface level (i.e. config direct on interface that get the tagged frames) and one at the switch level (what will use in our 5K), Cisco refer to this config as VSI (VN-Segment service instance) and VLAN modes.

VSI CLI Mode (L1/L2)

For this config let's assume that L1/L2 leafs gets the frames on H1/H2 ports on a trunk interface and what we want to accomplish is the vlan-to-vni mapping.

VLAN CLI Mode

This mode is much more easier, and that is because what we do is just an association between a vlan and a vn-segment.

VXLAN L3 Gateway

So basically we cover full L2 reachability between VXLAN under same bridge domain, but what about inter VXLAN routing? Seems pretty obvious that we will need to add a gateway with interfaces in the interesting VXLAN segment to route among them and also like SVI we do have a BDI (Bridge Domain Interfaces). We will associate that BDI with our VNI and assign addressing to it in order to be the VXLAN gateway for that segment and also be able to route outside (also to other VXLAN segment if we have)

So if we dig into config we can see is pretty straight forward since the magic already happened, what that means is that we do the hardest part that is the association between BD-VNI or VLAN-VNI, so only thing left id to create the associated interface (SVI in VLAN mode or BDI in VSI mode) with the addressing and thats all:

Note #1: See, only "new" stuff here is that we need to run PIM sparse mode, can you guess why? ping me!
Note #2: Yes, I'm using a VRF since it's also best practice to run tenant traffic into a separate vrf, this is pretty common in real life deployments (not flood and learn, VRF isolation i mean :) )

Now lets consider some design caveats and the first thing in mind for everyone here is HA so...

Redundancy? VXLAN L3 GW + HSRP? What about VPC ?

Yes, Yes and also Yes. Of course you can run HSRP on top of BDI/SVI but the not so easy part here is VPC. As you know VPC provides MAC state sync between peering devices and if you've opted to HSRP redundant VTEPs share anycast VTEP IP address (underlay). This way VPC provides L2 + L3 redundancy in HW, to be able to do this some changes needed to be done to loopack interface used for VTEP sourcing and to VPC Domain config, as a starter point first thing to recall is that a secondary ip address should be shared between VPC peers in order to forward VXLAN packets that can be handled for any of the peering devices, does that remember you something?... Yes, we also need peer-gateway under VPC Domain. Based on what we just describe peer-gateway is mandatory and also requires a SVI configured with PIM across peer link, a list of requirements can be found here:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/vxlan/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_VXLAN_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_VXLAN_Configuration_Guide_chapter_010.html#concept_C769B7878CE2458E98657905843DEEFA

But what you can never forget is:

Unique primary IP for underlay loopback
Same secondary
PIM
Consistent VNI to multicast group mapping
peer-gateway and a "special SVI" (PIM enabled) // This is needed in case your leaf lost connectvity to Spines and needs to forward packet to peering device.

Those are key for me but in the doc you will find a lot of more information, also something to mention is that on Nexus 5K VXLAN VPC configuration requires the use of that special SVI for VXLAN traffic by issuing a special command:

Distributed Gateway

Well, this is a huge post... we will talk about distributed GW, anycast and that stuff in another one since if not this will take me a lifetime and I do want to explain it in detail :)

Stay in touch :)

Friday, January 27, 2017

VXLAN Deep Dive Part II: It's all about knowledge

3:37 PM

Before starting with second part of this post and in order to calm down anxiety will briefly describe what this series is going to cover:

Part 1: Let's overlay -- Basic info about VXLAN, addressing and headers.
Part 2: It's all about knowledge -- Packet forwarding overview, VTEP control plane learning options
Part 3: Hands On #1 -- Configuration on Cisco Nexus Devices, Flood and Learn.
Part 4: Hands On #2 -- Configuration on Cisco Nexus Devices, EVPN.
Part 5: NSX Overview

So if you're interested in any other topic that you think is not going to be covered kindly ping me and will add.

After all that prelude I think we can start. As we see in Part I, we cover the header added into the original frame in order to be forwarded into an L3 network and also we end the post by giving an overview of packet forwarding. In order to reference later here is a pic of a VXLAN packet:

Figure 1: VXLAN Packet header

In later post we just reach a point in where host (hypervisor or device with VTEP, I will use any of these indistinctly) get a packet (VXLAN) which is not local and need to be delivered. Let's think like any L2 forwarding plane, we need to know where to route/send out this packet, this process is made by a lookup made by the host based on DST MAC Address of Original L2 frame (see picture above) and based on that we should get a ~~destination port~~ (hehe no L2 switching ) destination VTEP Address. This post would cover different methods of learning and populating this internal table, and as usual for forwarding it's all about knowledge.

VxLAN Flood and Learn

This scenario was the first introduced, it relies in head end replication, meaning that end host in case of not having any entry for the destination MAC address will send out an ARP to other devices / VTEPs in the VXLAN network. This is done by sending the request to the VXLAN multicast group for this Bridge domain, remote VTEPs will get the packet and answer accordingly direct to the originating VTEP (Here we can be aware of two requirements for running this: multicast core, IGP or unicast reachability between VTEP Addresses)

Figure 2: VXLAN Peer Discoveries and Tenant Address Learning

I will base the explanation using this amazing pic that I just stole from cisco web page :)

End System A (ES-A) sends out an ARP request for IP-B on its Layer 2 VXLAN network (note the Dst MAC Address).
VTEP-1 receives the ARP request. Since he doesn't have a mapping for IP-B yet, it encapsulates the ARP request in an IP multicast packet and forwards it to the VXLAN multicast group for that specific segment (VNI). The encapsulated multicast packet has the IP address of VTEP-1 as the source IP address and the VXLAN multicast group address as the destination IP address.
The IP multicast packet is distributed to all members in the tree, VTEP-2 and VTEP-3 receive the encapsulated multicast packet because they’ve joined that specific VXLAN multicast group, after that they decapsulate the packet and forward it locally to the local VXLAN network. In this process, if no prior communication was made between VTEP-1 to them, they insert into his local tablet the mapping between Mac Address of ES-A with IP of VTEP-1.
After the local transport of ARP, End System B (ES-B) gets the request forwarded by VTEP-2 and responds with its own MAC address (MAC‑B), and learns the IP-A-to-MAC-A mapping.
VTEP-2 receives the ARP reply of ES-B that has MAC-A as the destination MAC address, as per step 3 he knows about MAC-A-to- VTEP-1 mapping and therefore it can use the unicast tunnel to forward the ARP reply back to VTEP-1. The ARP reply is encapsulated in the UDP payload of a packet sourced from VTEP-2 and destined to VTEP-1.
VTEP-1 receives the encapsulated ARP reply from VTEP-2. It decapsulates and forwards the ARP reply back to ES-A, also it learns the IP address of VTEP-2 from the outer IP address header and inspects the original packet to learn MAC-B-to-VTEP-2 IP mapping.
Subsequent IP packets between ES-A and B are unicast forwarded, based on the mapping information on VTEP-1 and VTEP-2, using the VXLAN tunnel between them.
VTEP-1 can optionally perform proxy ARPs for subsequent ARP requests for IP-B to reduce the flooding over the transport network.

Head-end Replication

When you are working with VXLAN and reading literature also is common to hear or read the concept of head-end replication, what this essentially means is that the local VTEP has the overhead of replicate the broadcast traffic out to the other VTEPs, in the original release of VXLAN which uses multicast as underlying layer to reach VTEPs this only means encapsulate packet and sent out to multicast group, but also there is the possibility of have unicast peering (full-mesh) with all the VTEPs and in this scenario the head-end replication has a notorious impact.

Figure 3: Head-end replication example in unicast VTEP reachability

VxLAN MAC Distribution

Another well know method is VXLAN MAC Distribution, head-end replication is still used to deliver broadcast and multicast frames to remote VTEPs, but.. what about unknown unicast? You shouldn't have any (wish, read further). In this scenario MAC learning is not based on data plane activity and instead of that we have a central control unity (Nexus 1000V VSM, NSX controller, etc) which is used to keep track of all MAC addresses in the domain and send this information to the VTEPs on the system. Why do I say that this is a wish? Basically things are there to be broken, just like anY mapping table (CAM i.e.) entries have an aging associated to it, so if in first scenario VTEP-2 announces MAC-B entry through it and VTEP-1 gets populated with that all traffic will flow accordingly and VTEP-1, if doesn't have an entry for MAC-B, will query controller to get this info. Here two branches appears, a) controller has an entry and reply back to VTEP-1, entry gets installed and unicast traffic flow; b) controller doesn't have an entry for MAC-B and reply with an invalid entry so VTEP-1 must use head-end replication to reach learn where to send his packet (*this may vary depending on VTEPs OS/SW implementation).

Also there is another case in which VTEP-1 has a valid entry but it lost connectivity to controller and that entry gets old (and removed from table), in this case controller can't be queried and head-end replication will be used again.

VxLAN BGP EVPN Control plane

Quick disclaimer: Before starting with this I will say that you will find a lot of literature for this approach, also a lot of information regarding configuration to make this possible. This is the desired scenario for any real / production environment, Flood and Learn was showed just to understand what we got in the beginning and how we came up with a real control plane solution (and in a standard fashion way!).

EVPN overlay specifies adaptations to the BGP MPLS-based EVPN solution to enable it to be applied as a network virtualization overlay with VXLAN encapsulation, essentially this bring us great benefits (I will add more later):

Standardized solution: BGP plus VxLAN
Real Control Plane learning

For this approach what we made is (for MPLS EVPN knowers):

VTEP/network virtualization edge (NVE) is the equivalent to PE node
VTEPs use control plane learning/distribution via BGP for remote MAC addresses instead of data plane learning.
Broadcast, unknown unicast and multicast (BUM) data traffic is sent using a shared multicast tree.
In order to reduce the need of full mesh between VTEPs we can rely on BGP route reflector (RR)
Enhanced security by using well known Route filtering and constrained route distribution (control plane traffic for a given overlay is only distributed to the VTEPs that are in that overlay instance).
Host (MAC) mobility mechanism to ensure that all the VTEPs in the overlay instance know the specific VTEP associated with the MAC

MP BGP could be used for L2 VXLAN and also for L3 VXLAN (instead of Mac addresses learning think of IP association to VTEPs, do you remember LISP?). It's not my goal to enumerate all the benefits of running BGP EVPN control plane for VXLAN, apart of greater scalability, well known and proven protocols, etc. instead of that I will focus in the life of a packet in this new scenario and hopefully in next post we can cover all the variations for this (anycast GW, asymmetric. symmetric IRB, etc)

Packet forwarding in L2 VxLAN Segment

In this scenario we are covering L2 VxLAN communication, Host-A and Host-B belong to same VNI: 30000.

Host-A sends traffic to his local VTEP V1 (post ARP resolution), DST MAC B.
V1 will lookup in his table for an entry for MAC B.
V1 has an entry for MAC B thru VTEP V2, it encapsulate the packets and unicast send to V2.
V2 gets the packet, decapsulate and locally deliver to Host-B

End of happy tale, right? What about L3 traffic between VxLAN (see that we didn't cover this in flood and learn, since in that approach traffic should reach a device with the two VxLAN segments involved and logically route)

Packet forwarding between different L2 VxLAN VNI

In this scenario Host-A (VNI 30000) sends packet to Host-F (VNI 30001), core network is using VNI 50000, based on that the process is similar to:

Host-A sends traffic to DG (post ARP) which is configured on the locally attached VTEP V1.
V1 make a FIB lookup based on DST IP
V1 routes the packet to VTEP V2, but VXLAN packet is using core VNI 50000.
V2 gets the packet, it decapsulates, made a FIB lookup determining that DST VNI is 30001, rewrites the packet and deliver locally.

Ok, so now what about the ugly tale? As you can see I made two examples saying "this happens post ARP resolution", but how do we process ARP?

There is an ARP suppression mechanism, essentially, the IP-MACs learnt locally via ARP as well as those learnt over BGP-EVPN are stored in a local ARP suppression cache. ARP request sent from the end host is trapped at the source ToR and a lookup is performed in the ARP suppression cache with the destination IP as the key. If there is a HIT, then the ToR proxies on behalf of the destination with the destination MAC.

In case the lookup results in a MISS, when the destination is unknown or a silent end host, the ToR re-injects the ARP request received from the requesting end host and broadcasts it within the layer-2 VNI. This entails sending the ARP request out locally over the server facing ports as well as sending a VXLAN encapsulated packet with the layer-2 VNI over the IP core. This follows same process that we saw but only difference is that at reply the ToR will store the MAC binding in his ARP supression cache for further usage

Tuesday, January 17, 2017

Let's Overlay: VXLAN Deep Dive - Part I

9:37 AM

I was getting a lot of technical questions regarding VXLAN and overlays, how did they work, how you can configure them, etc. So I always think that is better if we can share all of that to all of you instead of reply each of you separately.

Let's start with a quick definition on overlays. Overlays, as the name mentions, allow us to reach different points in network without the need of caring about the under layer, you can say "OK, so it's all about tunnels", well I will not lie to you, there is a lot more behind that (address replication, control plane, ARP resolution, etc) but you can start with that vague idea (in coming posts I promise that you will get a better picture of it).

Being said that, one of the most used overlay technologies used and spreaded is VXLAN, which is designed to provide the same Layer 2 network services as VLAN does, but with greater extensibility and flexibility. How do we achieve this? Key aspects to understand are:

VXLAN uses a 24-bit segment ID known as the VXLAN network identifier (VNID), which enables up to 16 million VXLAN segments, this allow us for higher scalability and multi-tenancy
VLAN based designs uses STP in the back to choose best path, VXLAN uses MAC-in-UDP encap and in consecuence he can take advantage of the underlying network (Layer 3) and can take complete advantage of Layer 3 routing, equal-cost multipath (ECMP) routing, and link aggregation protocols to use all available paths, this provides us better use of resources.

VXLAN Packet format

As we mention, it uses MAC-in-UDP encapsulation to provide a means to extend Layer 2 segments across the data center network. The encapsulation scheme used places the original Layer 2 frame with a VXLAN header and then placed in a UDP-IP packet. With this MAC-in-UDP encapsulation is easy to think in tunneling VXLAN across L3 networks, a great and easy way to see this is in the following packet format:

As seeing in the picture, VXLAN introduces an 8-byte VXLAN header that consists of a 24-bit VNID and a few reserved bits. The VXLAN header together with the original Ethernet frame goes in the UDP payload. The 24-bit VNID is used to identify L2 segments and to maintain L2 isolation between the segments.

Also by seeing picture is now easier to get the idea on how tunneling can work with this frame, tunnels are formed between devices which want to exchange VXLAN data and for that only thing needed is destination IP (in Outer IP Header) also once reached we have to do the hard work that every tunnel does encap/decap, and for that we have to introduce other player that is the VTEP or VXLAN Tunnel Endpoint.

VXLAN Tunnel Endpoint

VTEPs are essential players in VXLAN work, as we mentioned earlier their role is similar to any tunnel endpoint (encap/decap) but we will explain in detail how this occur. I would use this simple scenario to do some explanations:

VTEP has presence in a Local LAN segment and has a defined mapping from that segment to a VNID. The encapsulation process consist on taking the L2 Frame sended by any of the End Systems on the local segment, add the VXLAN header with the corresponding VNID, add UDP header, and add Outer IP header (with destination IP for the remote VTEP where we want to send out our packet, if you are now thinking how this entries get populated and how arp is handled you have to wait for Part 2 :) ). Once packet arrives remote VTEP, decap process start by stripping off VXLAN Header and identifying, based on VNID, the local segment in which we have to deliver out our packet.

Being said this the following is pretty self-explanatory (if you follow me, if not here you have a nice picture):

In this figure, Host A is sending out a packet to host B, his associated VTEP, VTEP-1, has an entry for Destination MAC-B in his table and his referring to IP of remote VTEP VTEP-2, he also has the info of the VNID assignment for Host-A, VNID 10. Based on that VTEP-1 has all the info that he needs to encap the packet and deliver it out to VTEP-2. Once packet reach VTEP-2, gets decapsulated, based on VNID is associated to LAN segment where Host-B lives and packet is sent out to the destination (also on VTEP-B and switches if any there know how to reach MAC-B :) )

I think we are good for today, next post in this series will cover how BUM traffic is processed, control plane options and config scenarios. If you want to see any in particular, just let me know.

Friday, January 13, 2017

About Writtens and CCIE DC written prep

10:05 AM

I'm constantly been asked of several things about certs, and particularly about written exams. In this post I will try to summarize two things, one is my personal belief and the second one is the study method / reading list that I followed up.

So, lets start by saying a bad word... dumps. Lot (and i mean a LOT) of people asks me "which dumps have you used to clear XYZ?", "I'm waiting till dumps get more accurate" and so on... My answer is always the same: "you can do whatever you want, but think if time spent by reading questions worth it", how much time do you spend by reading a series of 2^20 Qs? And by memorizing them? And it gets better, do you enjoy that process? If you do, just skip this post since you're not going to need the book list and start thinking if you can memorize cards in a casino, maybe you get a bigger reward ;) if you don't... don't feel silly, we are at least two guys (And believe me I know a lot of people who enjoy the process of reading books instead of memorizing Qs)
Also, another thing that i really want to point out about this is that I know that Cisco is working really hard to overcome dumpers by releasing new Qs everyday (maybe that is too much, but they are working on it, believe me)

Well, after all the introduction setted up (feel free to comment if you agree or not), I will post my study methodology for writtens and my book list for DC (v1, sorry guys.. I will post the books readed for v2 but for written i took v1 in beggining of 2016).

Study methodology

Read the blueprint at cisco cert page and topics included in written (https://learningnetwork.cisco.com/community/certifications/ccie_data_center/written_exam/exam-topics)
Start by identifying the topics that you (think) master and those you definitely don't.
Mix reading of topics you don't know anything of with those that you do, this is key to avoid being overwhelmed by new stuff (your brain will thank you)
Always take notes! For CCIE written exams and similar certs you have to note down those concepts and configuration maximums/limits that you will never remember in real life!
To use as a guide, be sure that you have a section on your notes for each protocol that is in the blueprint, i.e. for FabricPath you should have at least this info:

"Running per Supervisor Engine, on a per-VDC basis:●   FabricPath IS-IS - SPF routing protocol process that forms the core of the FabricPath control plane
●   DRAP - Dynamic Resource Allocation Protocol, an extension to FabricPath IS-IS that ensures network‑wide unique and consistent Switch IDs and FTAG values
●   IGMP - Provides IGMP snooping support on FabricPath edge switches for building multicast forwarding database
●   U2RIB - Unicast Layer 2 RIB, containing the “best” unicast Layer 2 routing information
●   M2RIB - Multicast Layer 2 RIB, containing the “best” multicast Layer 2 routing information
●   L2FM - Layer 2 forwarding manager, managing the MAC address table
●   MFDM - Multicast forwarding distribution manager, providing shim between platform-independent control-plane processes and platform-specific processes on I/O modules

Global components that run on each of the I/O modules, processing forwarding information from each VDC and programming it into the I/O module hardware:
●   U2FIB - Unicast Layer 2 FIB, managing the hardware version of the unicast Layer 2 RIB
●   M2FIB - Multicast Layer 2 FIB, managing the hardware version of the multicast Layer 2 RIB
●   MTM - MAC table manager, managing the hardware version of the MAC address table"

Well I think that finally a book list is expected:

NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures, 2nd Edition
I/O Consolidation in the Data Center
Storage Networking Fundamentals: An Introduction to Storage Devices, Subsystems, Applications, Management, and File Systems
Cisco Unified Computing System (UCS) (Data Center): A Complete Reference Guide to the Cisco Data Center Virtualization Server Architecture
Policy Driven Data Center with ACI, The: Architecture, Concepts, and Methodology
Cisco Live docs, don't you use that? You're missing a GREAT resource

BRKDCT-2404 VXLAN Deployment Models - A Practical Perspective
BRKDCT-2370 - Intermediate - End-to-End Application-Centric Infrastructure Automation with UCS Director
BRKDCT-2049 - Overlay Transport Virtualization
BRKDCT-3237 - Advanced - Versatile architecture using Nexus 7000 with a mix of F and M modules to deliver FEX, FabricPath, Multihop FCoE, MPLS and LISP all at the same time
BRKDCT-3145 - Advanced - Troubleshooting Cisco Nexus 5000 / 2000 Series Switches
BRKDCT-3378 - Advanced - Building simplified, automated and scalable DataCenter network with Overlays (VXLAN/FabricPath)

Also lot of blogs... I will write down my RSS feeds soon :) there is really smart people near us :)

Thursday, January 12, 2017

Next Goals 2017

11:00 AM

As many of you already know me I'm not a man who can be relaxed after reaching a goal, I really enjoy chasing new stuff and for this year I 've set up several goals:

CCDE (Passed my written past year, going for lab soon...)
CCIE RnS or SP, I have a story behind this, early last year I've started my RnS trip but people of my team telled me that I've to chase DC and they convinced me, after achieving that goal now is time to back to basics SP and RnS can do that for me.
VCDX-NV, working actively to get it, lot of time consuming but really like it, hope to find time to end with this
VCIX-DCV
JNCIE, I owe juniper the chance to delight me with a lab and hopefully i can find a timeslot at the end of this year to go out for lab (I'm already a JNCIP-ENT just have to take the courage and set up a lab for hands on practice)

As always, this is my wishlist for this 2017, lets see at the end of this year how much do I achieve (if any, hope at least one :) ), in the meanwhile I will keep posting about DC since as you may figured it out I love that track, and also about tech and the preparation for all of this goals, hope you join me in this trip :)

Tuesday, January 10, 2017

CCIE DCv2: Lab experience & general recommendations

2:44 PM

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....)

Monday, January 9, 2017

CCIE DCv2: Part I - Preparation

5:46 PM

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

This is the real hard topic to cover, not in theory or technology but really in config section. For this I really tried to use Cisco Documentation but wasn't enough, so further reading follow me to this GREAT presentation: BRKDCT-2404 VXLAN Deployment Models - A Practical Perspective

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

Last but definitely not least is ACI, as you can imagine (I figured it out at least), Cisco will push you to use this new tech that they acquire a few years ago. Actually there is no good content related ACI from any partner or learning vendor, I took a quick look at Jason Lunde and other videos, but they where so so introductory that you really need further info. In my case I achieve that by setting up a POD several times and facing all kind of errors, I focused on what I though that it was the key objectives of having ACI deployed, and for me that was:

- Setting up VMM integration

- Deploying Contracts between EPG and Tenants

- Customizing several Fabric configurations (It's well known that in a CCIE Exam they can ask you to change whenever option is available at the interface, so be prepared)

- Deploy a L2 Out connection

- Deploy an L3 Out connection

- Share L3/L2 between tenants

For all this I really recommend to use and see Cisco Community, that was really helpful, Tomas De Leon (a TAC guy who wrote there) uploads very useful documents about how to configure APIC. And again, get a lot of hands on experience in this topic, ACI have a lot of errors and you have to get familiar with them, if you have no previous experience start with a video series to get familiar with concepts and after that book your labs, get an image or us dCloud but be sure to get hands on :)

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.

CCIE DC v2: Posts & Thanks

12:28 PM

As i mentioned before I will start a series of post regarding my prep to achieve CCIE DCv2, but before that I want to leave some things clears:

I will not post any info regarding lab that violates NDA, so please don't insist

I don't work for any vendor, training school, etc, so posts are on my own ;)

Being said that I want to start by thanking to all who really help me pass:

My wife, for supporting me at every moment

CCIE-HOME team, and particularly Arshad Dhunna & Joaquim Fernandes, those guys are beasts (I mean literally, having 7xCCIE, VCIX, CCDE... come on!!), they gave me rack access and helped me since three months to achieve this goal

Last but not least, our skype group colleagues, we discuss pretty much every section of the blueprint and different variations or approaches to scenarios.

Saturday, January 7, 2017

First post... more coming

10:17 AM

Just wanted to ping here quickly, to let everyone knows that I will update this soon and post my whole CCIE DC v2 experience and preparation, it would take me some time but I expect to end by this week. Also wanted to thank everyone who encourage me to make this and who kindly congratulate me about the achievement! Keep you updated in very few.