25 – Why the DC network architecture is evolving to fabric?

The Datacenter network architecture is evolving from the traditional multi-tier layer architecture, where the placement of security and network service is usually at the aggregation layer, into a wider spine and flat network also known as fabric network ( ‘Clos’ type), where the network services are distributed to the border leafs.

This evolution has been conceived at improving the following :

  • Flexibility : allows workload mobility everywhere in the DC
  • Robustness : while dynamic mobility is allowed on any authorised location of the DC, the failure domain is contained to its smallest zone
  • Performance: full cross sectional bandwidth (any-to-any)  – all possible equal paths between two endpoints are active
  • Deterministic Latency : fix and predictable latency between two endpoints with same hop count between any two endpoints, independently of scale.
  • Scalability : add as many spines as needed to increase the number of servers while maintaing the same oversubscription ratio everywhere inside the fabric.

If most of qualifiers above have been already successfully addressed with traditional multi-tier layer architecture, today’s Data centres are experiencing an increase of East-West data traffic that is the result of:

  • Adoption of new software paradigm of highly distributed resources
  • Server virtualization and workload mobility
  • Migration to IP Continue reading

The Power of a Programmable Abstraction Layer

In the previous post, I talked about a common programmable abstraction layer (CPAL).  To better understand the thought process behind having a common PAL, it makes sense to review some of the work Jeremy Schulman has been doing.  Jeremy often refers to the Python interactive shell as the new CLI for networking.  When you watch him give a demo using the Python shell as a CLI, it is second nature and looks exactly like a network CLI.  It makes perfect sense.
It gives real time access to the network devices in a programmatic fashion.  Being programmatic is key here – no screen scraping, etc.  The downside --- you need to know Python.  Well, yes and no.  Of course, you would be using the Python interpreter so you’ll be leveraging programming concepts -- things like variables, functions, classes, etc. 

But, before you think you need to become a professional software developer, the other good news is that Jeremy has created the Junos OS PyEZ library that drastically simplifies the interaction and baseline knowledge to start programming Juniper devices.  Juniper supports native XML APIs, but the PyEZ module abstracts that and eliminates Continue reading

Cisco Nexus 9000 NX-API

A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS. ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well.

Cisco Nexus 9000 NX-API

A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS. ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well.

Show 180 – The Art of Network Architecture: Business-Driven Design

In this show, host Ethan Banks is joined by Russ White & Denise Donohue, co-authors of the soon-to-be-released CiscoPress title, The Art of Network Architecture: Business Driven Design. Orhan Ergun reviewed the book and also shares his perspectives. This isn’t just a book review, though. Really, the show uses the book as a springboard to […]

Author information

Ethan Banks

Co-host at Packet Pushers

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
TwitterGoogle+LinkedIn

The post Show 180 – The Art of Network Architecture: Business-Driven Design appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

Programmatically Configuring Interface Descriptions from Phone Descriptions

I wrote some Python code that allows you to do the following:
  1. Query a Catalyst switch CDP neighbor table from its HTTPS interface,
  2. Extract the device names of the attached IP phones,
  3. Query Communications Manager for the IP phone device description, 
  4. Apply the device description as the switch interface description.
Obviously, this makes it much easier to see whose phone is attached to a switch port.

I hope that this example saves someone the head-banging that I incurred while trying to figure out the AXL XML/SOAP API for Communications Manager.

I haven't tested this extensively; all my testing has been on Catalyst 3560 and 3750 switches and CUCM version 8.6. Using the --auto switch to automatically configure the switch is quite slow; this is a limitation of the HTTPS interface rather than the script code. It may be faster to leave that option off and manually copy/paste the printed configuration if you're in a hurry.

Note that your switch must be configured to allow configuration via the HTTPS interface; you may need to modify your TACACS/etc. configurations accordingly.

All the relevant info is in the Github repo.

Programmatically Configuring Interface Descriptions from Phone Descriptions

I wrote some Python code that allows you to do the following:
  1. Query a Catalyst switch CDP neighbor table from its HTTPS interface,
  2. Extract the device names of the attached IP phones,
  3. Query Communications Manager for the IP phone device description, 
  4. Apply the device description as the switch interface description.
Obviously, this makes it much easier to see whose phone is attached to a switch port.

I hope that this example saves someone the head-banging that I incurred while trying to figure out the AXL XML/SOAP API for Communications Manager.

I haven't tested this extensively; all my testing has been on Catalyst 3560 and 3750 switches and CUCM version 8.6. Using the --auto switch to automatically configure the switch is quite slow; this is a limitation of the HTTPS interface rather than the script code. It may be faster to leave that option off and manually copy/paste the printed configuration if you're in a hurry.

Note that your switch must be configured to allow configuration via the HTTPS interface; you may need to modify your TACACS/etc. configurations accordingly.

All the relevant info is in the Github repo.

ESXi Server Build

With the release of the IOS XRv router, along with CSR (Cloud Services Router), its time that I go ahead and build myself a virtualization solution.

To that effect, I have just ordered the components for a home build server, which was the cheapest, not to mention most silent option available.

The components are:
Intel Xeon 3.2 Ghz processor (E3-1230).
32 Gig of memory.
Intel Micro ATX server motherboard (S1200V3RPL).
A 120 Gig Kingston SSD.
A supposedly silent PSU.
And to house it all, a Lian-Li Micro-ATX cabinet (PC-V300B).

Hopefully, everything will be here next week. Looking forward to it :)

Kicking tires on Cumulus Linux

So, I ended my last blog post with a wish – “hopefully someday I can get a real switch running Cumulus to play with ;-)”  Well, as it turns out, that post was somewhat popular, and caught the attention of some folks at Cumulus Networks (who kindly RT’d my tweet publicizing the post – thanks!) […]

Author information

Will Dennis

Will Dennis

Will Dennis has been a systems and network administrator since 1989, and is currently the Network Administrator for NEC Laboratories America, located in Princeton NJ. He enjoys the constant learning it takes to keep up with the field of network and systems administration, and is currently pursuing the Cisco CCNP-R/S certification. He can be found on the Twitters as @willarddennis, and on Google Plus.

The post Kicking tires on Cumulus Linux appeared first on Packet Pushers Podcast and was written by Will Dennis.

Show 179 – Avaya Efficient Data Center Design at Fujitsu & the Sochi 2014 Winter Games

In this episode, Avaya comes on board to talk about new and efficient ways to design data centers. They bring a couple of customers along to discuss their implementations: Fujitsu Technology Solutions and the Sochi 2014 Olympic Winter Games. Speaking with host Greg Ferro are Paul Unbehagen, Chief Architect for Avaya Networking; Albert Knoll, Network […]

Author information

Ethan Banks

Co-host at Packet Pushers

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
TwitterGoogle+LinkedIn

The post Show 179 – Avaya Efficient Data Center Design at Fujitsu & the Sochi 2014 Winter Games appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Common Programmable Abstraction Layer

In late January, there were some big names on stage at the latest Open Compute Summit.  I’d like to focus on one keynote panel that was called, “Opening Up Network Hardware.”  The panelists for this session included Martin Casado (VMware), Matthew Liste (Goldman Sachs), Dave Maltz (Microsoft), and JR Rivers (Cumulus) and was led by Najam Ahmad (Facebook).  If you haven’t watched the session already, it’s definitely worth it.  You can check it out here.
It’s always interesting when there are consumers of the technology on stage with those that sell and build their own technology.  Even in a session like this, it’s hard to put Facebook and Microsoft in the consumer/user group because they are increasingly rolling their own.  But Goldman Sachs (GS) on the other hand is unique --- and more relevant to the Enterprise.  They are a user of Enterprise technology, but what makes them unique, in my opinion, is that they seem to be crossing the chasm or straddling Enterprise technology and rolling their own (DIY) with technology from OCP and what they announced at last year’s ONS, which was soon after they joined the ONF.  And there is probably Continue reading

Coffee Break – Show 2

This is “The Coffee Break”. A podcast on state of the networking business where we discuss vendors moves and news, analysis on product and positioning, and look at the business of networking. In the time it takes to have a coffee break.

Coffee Break – Show 2

This is “The Coffee Break”. A podcast on state of the networking business where we discuss vendors moves and news, analysis on product and positioning, and look at the business of networking. In the time it takes to have a coffee break.

Author information

Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus.

TwitterFacebookGoogle+

The post Coffee Break – Show 2 appeared first on Packet Pushers Podcast and was written by Greg Ferro.

One-liner iptables rule to Filter NTP Reflection on Linux Hypervisor

Anybody annoyed enough with massive NTP monlist floods over the weekend? If you did like I did, I believe what immediately came to your mind was, “this shouldn’t have happened if they just had put a ‘default ignore’ line in their ntp.conf file!” But unfortunately there are some people who’re not like you, including casual […]

Author information

Tamihiro Yuzawa

Tamihiro Yuzawa

Tamihiro Yuzawa is a network engineer at Sakura Internet, one of Japan's major data center service providers. Before he joined Sakura in 2007, he spent five years at a busy CRM service provider. Both companies have allowed him to stay mostly within the intersection of these circles, and he is pretty much determined to remain in a serious relationship with both Dev and Ops.

The post One-liner iptables rule to Filter NTP Reflection on Linux Hypervisor appeared first on Packet Pushers Podcast and was written by Tamihiro Yuzawa.

1 … 3,751 3,752 3,753 3,754 3,755 … 3,836