Category: Design

Cisco ACI – 1 – High level architecture overview

What is Application Centric Infrastructure (ACI)?
Simplest definition: A data center architecture which abstracts network building blocks (VLAN, VRF, Subnets, etc.) using policies!

In ACI architecture, from the HLD point of view, Nexus 9000 will act as the physical switching fabric, and Application Policy Infrastructure Controller (APIC), in the form of a clustered policy management system, will take care of policies.

As I called the word “fabric”, you can imagine a fabricpath-like topology, but:

  • spines are not connected to each other
  • leaves are not connected to each other
  • leaves are connected to all spines
  • all other connectivities are via the leaf nodes (no thing will be directly attached to spines!)

So, tell me where an APIC should be connected?
Obviously, to a leaf!

It’s all about policies! Policies define all the system configuration/administration. Also, a policy model define how applications and attached systems communicate.

ACI defines some new concepts, such as Service Graphs, Contracts, Filters, Application Profiles, Endpoint groups, etc. Hopefully, I’ll cover them in future posts.

By the concept of Service Graph, ACI is able to be highly integrated with Layer 4 to Layer 7 services devices. A Service Graph could be translated as a description of “where a service, such as a firewall, should be placed in the traffic flow”.

Ok, before diving into anything else, the first step would be provisioning a fabric and let it on. Interested? It will be more interesting in the next post!

By the way, I forgot to mention that, it would be nice to have Cisco ACI Fundamentals open while reading this.

Share this!

IPv6 Subnetting – Overview and Case Study

I’m gonna share an article which I found from Cisco Support Community. Although it’s not that much new, but it’s kinda interesting overview.

The sheer number of bits in an IPv6 address can make IPv6 subnetting intimidating at best. With the addition of a new addressing scheme it’s easy to get lost trying to break up your brand new /48 address across your enterprise.

The New Boss, Same as the Old Boss

Subnetting with IPv6 is not drastically different than subnetting with IPv4, we just need to keep a few things in mind:

1.) Each character in an IPv6 address represents 4 bits (a nibble).
Since 0xF is 1111 in binary, it’s easy to fall back into an IPv4 habit and forget that 0x11 is actually 0001 0001 in binary.

2.) Each IPv6 set represent 16 bits (4 characters at 4 bits each).
Keeping this in mind can make breaking up subnets a bit easier.

3.) Once it’s in binary nothing changes!
It’s easy to get lost in so many binary digits but the math is all the same. Each subnet bit is one fewer host bit and vice versa.

Setting the Ground Rules

The leading practice is to receive at least a /48 prefix from an ISP. This leaves you with 2^80 bits to manipulate (128 bit address – 48 bits that can’t be changed = 80 bits to use). More bits than the entire IPv4 address space! Continue reading “IPv6 Subnetting – Overview and Case Study”

Share this!

Rules of Networking

I have to admit that I’m obsessed with RFC1925 and do my best to apply it to all aspects of my work.

Just as a note to self, I post the Twelve Networking Truths here, and hopefully add more relevant ideas I find in the course of time.

  1. It Has To Work.
  2. No matter how hard you push and no matter what the priority, you can’t increase the speed of light.
    1. (corollary). No matter how hard you try, you can’t make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won’t make it happen any quicker.
  3. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
  4. Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
  5. It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
  6. It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.
    1. (corollary). It is always possible to add another level of indirection.
  7. It is always something
    1. (corollary). Good, Fast, Cheap: Pick any two (you can’t have all three).
  8. It is more complicated than you think.
  9. For all resources, whatever it is, you need more.
    1. (corollary) Every networking problem always takes longer to solve than it seems like it should.
  10. One size never fits all.
  11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
    1. (corollary). See rule 6a.
  12. In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
Share this!

ToR & EoR Data Center Designs

This post is my snippet of Brad Hedlund article about ToR and EoR design which is accessible via the following link:
http://bradhedlund.com/2009/04/05/top-of-rack-vs-end-of-row-data-center-designs/

Top of Rack Design

ToR is sometimes called In-Rack design.

Benefits:
  • All copper cabling for servers stays within the rack as relatively
  • there is no need to for a large copper cabling infrastructure
  • Any network upgrades or issues with the rack switches will generally only affect the servers within that rack
  • any future support of 40 or 100 Gigabit on twisted pair will likely have very short distance limitations (in-rack distances). This too is another key factor why Top of Rack would be selected over End of Row.

Continue reading “ToR & EoR Data Center Designs”

Share this!