Living in the underlay: CCIE

Showing posts with label CCIE. Show all posts

Wednesday, April 11, 2018

Embrace API not SDK, but don't reinvent the wheel

10:20 AM

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

Being all that said I really think that more needs to be done in order to correct instruct the way that some organizations are taking towards network automation, more over an intent based think is need definitely in order to not fail to repeat the history and do legacy network automation in the new era.

By the way for those who still asks me if I provide some network automation course for DC or generic network programming is Yes and is not based on any SDK, it's not part of the CCIE DC training and is covered in the Network Programmability course (more info ping me directly, linkedin or trough ie-bootcamps :) )

[1] Some vendors, and want to remark that shamely only some of the full network vendors ecosystem, creates their UI or EndUser systems based purely on the consumption of their own boxes REST APIs.

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

Saturday, April 29, 2017

Multicast redundancy: Phantom RP

11:08 AM

Past ~~week~~ two weeks a colleague and also a student asked me about Phantom RP and how it works, all was related with a discussion we have around VXLAN Part 2 post and about supported Multicast configurations for VXLAN in NX-OS.

First of all, and in order to avoid further confusions around it, I would resume current supported methods for VXLAN underlay on Cisco NXOS/ASR devices:

Source: Cisco doc

Being clarified that, we can continue with the original purpose of this post.
So, based in our previous post we have configured our Nexus 5K / 7K underlay to run multicast in to support Flood and Learn configuration, by that time we choose Bidir PIM since is the only supported method in N5K. So let's get some background about bidir and how can we make it redundant (can we?)

BiDir PIM

PIM Bi Directional mode enable multicast group to route traffic over a single shared tree rooted at the RP, instead of using different unidirectional or sources tree. Since RP is the root (his IP address :) ) is good to not to place it on a router but on an unused IP on the network reachable from PIM domain (this will be seen later in PhantomRP configuration).
Explicit join messages are used to establish group membership, Traffic from sources is unconditionally sent up the shared tree toward the RP and passed down the tree toward the receivers on each branch of the tree (note: traffic is not sent unidirectional to RP)

Bidir-PIM shares mechanisms of PIM-SM like unconditional forwarding of the source traffic toward the RP but without the registering process for sources (https://tools.ietf.org/html/rfc7761#section-4.2). Based on that forwarding can take place based on (*,G) entries, removing the need of any source specific state and, therefore, expanding scaling capabilities. This image extracted from Cisco white paper are good to see the differences in upstream process towards the RP in SM vs BiDir:

Source: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fsbidir.html#wp1023176

"PIM-SM cannot forward traffic in the upstream direction of a tree, because it only accepts traffic from one Reverse Path Forwarding (RPF) interface. This interface (for the shared tree) points toward the RP, therefore allowing only downstream traffic flow. In this case, upstream traffic is first encapsulated into unicast register messages, which are passed from the designated router (DR) of the source toward the RP. In a second step, the RP joins an SPT that is rooted at the source. Therefore, in PIM-SM, traffic from sources traveling toward the RP does not flow upstream in the shared tree, but downstream along the SPT of the source until it reaches the RP. From the RP, traffic flows along the shared tree toward all receivers."

Need of redundancy? Let's do it

We mention that our shared tree is rooted at RP address, so in order to give him redudancy we need a way to duplicate this or use a virtual IP. For bidir pim no traffic is targeted at RP (no control plane functions) so our solution is easier, instead of actually assign same IP in a sort of anycast we can just advertise it thru our IGP, the only issue foreseen is that the actual shared tree should be only one at a given time (we dont want that our RPF interface changes everytime) so in oirder to avoid that we can leverage the path decision to a more specific match in the RIB (by advertising same subnet with largest mask by some of the redundant points).
Well, that was so much talk I think that a code/config snippet worths more than a millon words:

Primary

Secondary (hmm.. if you don't see any difference here is a hint: look at the mask)

Now it's done, you can run your set of favourite verification commands to see if this is working:

Also you can shutdown the active interface (lo1) and see how does this change and our redundancy is working.

For CCIE / CCDE students:
- What is the convergence time of RP in case of a failure on primary?
- Can we give sub-second convergence?
- In flood and learn configuration for VxLAN what would you recommend ASM or bidir PIM?
- In case of choosing ASM how is your redundancy going to be solved?
- Why are we using "ip ospf network point to point" ?

More on Multicast ASM/SSM/Bidir comparisson: http://lostintransit.se/2015/08/09/many-to-many-multicast-pim-bidir/

Friday, March 31, 2017

IE-Bootcamps - Launching a new training experience

5:46 PM

Finally, after a tough work done by me and the CCIE HOME team, we ended creating ie-bootcamps, the first expert level training company based in Latin America that will deliver courses and bootcamps for the most challenging tracks. We plan to cover America completely, and as a start point we introduce the CCIE DC v2 Lab Bootcamp that would be held at Buenos Aires, Argentina in May 22-26th. I will be delivering the course, so you are all invited :)

More info at: http://ie-bootcamps.com/course/ccie-dc-v2-0-lab-bootcamp/
Or reach me directly

-----

Finalmente tras un largo trabajo de parte del equipo de CCIE HOME y mio, hemos dado a luz a la primer empresa encargada de dar capacitaciones de nivel experto en habla hispana: ie-bootcamps.
Como primer medida, hemos arrancado con la coordinacion del bootcamp de CCIE DC v2.0 a darse en Buenos Aires, Argentina el 22 al 26 de Mayo.

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

Tuesday, February 28, 2017

CCDE, be a chameleon

9:33 AM

After passing DE want to take some time and write this words to all futures aspirants and also for those who failed and also pass to see their point of views regarding CCDE. I was thinking about strategy in lab and mind strategy as well and I realize that being a chameleon is one of the important aspects that you will need to address in order to be successful in this path.

Disclaimer: This post is intended to be a wrap up of my experience to succeed in lab, this study methodology and all suggested here is based on my background and available times on week for studying, feel free to use it and adjust it to you own pace.

Being said that...

Get yourself use to read and read

Asumming that you have passed written and you feel like all the theory needed is covered I can assure you, that's not true. Even if you have passed the written you still need to read and re read technology and also be able to understand pros and cons of each design. A general rule that I can say is that to any desig you will need to be able to find the pros and the cons, if you can't you're just being shortsigthed and you're missing to cover all points in a given design. For this aspect is also key to get a group study, so let's talk about this one too.

Be in a group and collaborate as much as you can

Some guys claim that studying alone is the way that best suits them, that can be great if you're a giving a IE level exam or any written, but for DE is completely the opposite. I do really like to do this comparison and say that if you study alone you're just a vlan with a polarized HSRP gateway, despite of the nerd comparison what I do really mean is that you can't argue anyone! and that is not good at all, since I don't expect guys that argue for everything but I do expect people that say their point of view and discuss also why they have thought that caveat or pro in a proposed design. And remember discussions are a good thing, just like other good stuff don't abuse to them and use it carefully.

The methodology that we use in our group was to check one scenario every week, we set up call on weekend and on week we study by ourselves. You can use the scenarios in Orhan and Martin Duggan book, but since we run out of scenarios what we made is split ourselves in group of two and make modifications to create a specific scenario that cover some specific design concern, I do recommend you that in this "split" you choose to create scenarios based on your areas of expertise (in my case it was SP and DC :) )

My study methodology prior to lab was aprox 6hs per day (Monday-Friday), and 4hs sessions on Saturday. This by two months... and assuming that you have cleared written (i cleared mine long ago) and you have good design expertise (if not i will recommend you another 2 months of study), in my case I have near 13 years of expertise working on huge companies (like design scenarios hehe) and last 6 years on a Service Provider (who divest itself into two, nice scenario for CsC we made in real life!)

For lab strategy I can summarize my key points, some of them you will find it along a lot of posts, but this was really useful for me:

Color scheme for highlighting

I do really quick reading and that has a caveat, you can omit stuff, so be sure that you read all of the sentences and also take a color scheme to highlight information. I choose a real simple one: Green is good design option taken, Red is bad design or caveat on design, Yellow is constraint or requirement. I want to use pink for IGP info but i realize that info is so mixed that in second scenario I back to the roots and only use those three.

Be a chameleon

This is the mind status that you have to reach in the exam, you will have to be a chameleon to read all requirements and constraints and be ready to transform yourself in the designer of ABC Company to take the best choice, But inmmediately , in next scenario you will transform yourself into a Service provider architect being part of team who is evaluating X or Y technology. All this happens really fast and you have plenty of info around you to support you in this transformation, what you need is the ability to quickly focus in the job role that they have assigned to you, gather the info and take the best shot.

Suboptimal routing still works right?

I do really love to do comparisons of real life and technology and in this case I can think in suboptimal routing as a wrong (or not so good) branch in exam. If you have readed all Cisco Live material of DE you may be aware that in scenarios there is always several branches based on your selections, so even if you're not in the best branch you can get points (STOP! if you're not reading Cisco Live info for DE take a moment to review that, is key to understand exam flow). So in the time frame of an scenario the branch will become your life, so being able to manage bad decissions is important, because you will realize that you don't choose the best path (trust me, it happens) but they will provide you options to understand why you make that choice and you will have to choose the not so good and not so bad option to be able to continue, so don't get worried suboptimal routing still works :) and we know next time you will not face same mistake :)

Hope this help all the next aspirants, those new and those not so new. Also for those which have passed lab, congrats! and inputs are always welcome.

Friday, February 24, 2017

CCDE... happy ending

10:25 AM

Well guys, you may note that I was out of blogging for a while, and there was a reason behind that... CCDE was so time consuming, I spend at least 4 to 6 hours last two months with a my awesome study group debating scenarios, design choices and pros/cons of each of them... it was real hard, it requires ****a lot**** of reading but definitely worth it!! Past Feb 22nd I pass the lab, it was at my first attempt and I feel very lucky about that but it was really about training, reading, understanding and debate with my colleagues what make me succeed, I will write down a post with strategy and training used as well, but at this moment just want to take me some time to write down this line and congratulate all my friends and colleagues who have taken the CCDE lab, passed or not, was a real good experience and an amazing learning!

Keep you updated guys :)
CCDE 2017::27

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

Wednesday, January 11, 2017

IE expert level certification training

12:07 PM

As you may also know, I've recently passed my CCIE DC v2 and i really want to thanks again CCIE-HOME team. If you have read my first post about this track, i do not work for any of them, so comments are on my own.

Being said that I want to start a discussion, and I'm open to comments, about level of bootcamps / training provided for this tracks. Specifically for DC when I start my journey to v2 I feel "alone". No info for any training partners, no bootcamps offering, no twitter posts of people passing...

Also and added to that, I'm based on Argentina, here and I will not miss if I say in whole Latin America, the level of training is so poor... we're used to reach INE or other companies outside of our region to get trained. Based on that I was able to reach CCIE HOME and saw that they we're starting this track and need people interested in join and test the level of their new bootcamp.

After that, and now being passed this track and being also certified as VCIX-NV, JNCIP-ENT and several other certs I've started the path to build my own training company, based only on IE level for all the major vendors (Cisco, Juniper, VMware), being in technology for so many years made me reach a real network of expert professionals in different subjects. Im also instructor for majority of this tracks and being able to know a lot of people trained and capable of deliver a real IE level training, so I've decided to start with a new offering for bootcamps, based in Latin America and for Latin America mostly (I really want to give a Spanish based offering, I know that we need English to learn this track that's for sure but for training we have very well trained people that can deliver the training in our native tongue :) ). I will keep you posted about this, I'm actually training a few guys in VMware and Cisco DC track, after that I will focus 100% on this and hope you joined me :)

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.