Cisco Blogs


Cisco Blog > Perspectives

Summary – Network Design for Automation

There has been a lot of recent online discussion about automation of the datacenter network, how we all may (or may not) need to learn programming, the value of a CCIE, and similar topics. This blog tries to look beyond all that. Assume network configuration has been automated. How does that affect network design?

Read my full article to find out more..

Tags: , , , , , , , , ,

Network Design for Automation

20140519-CISCO-spine-and-leafThere has been a lot of recent online discussion about automation of the datacenter network, how we all may (or may not) need to learn programming, the value of a CCIE, and similar topics. This blog tries to look beyond all that. Assume network configuration has been automated. How does that affect network design?

Automation can greatly change the network landscape, or it may change little. It depends on what you’re presently doing for design. Why? The reason is that the programmers probably assumed you’ve built your network in a certain way. As an example, Cisco DFA (Dynamic Fabric Automation) and ACI (Application Centric Infrastructure) are based on a Spine-Leaf CLOS tree topology.

Yes, some OpenFlow vendors have claimed to support arbitrary topologies. Arbitrary topologies are just not a great idea. Supporting them makes the programmers work harder to anticipate all the arbitrary things you might do. I want the programmers to focus on key functionality. Building the network in a well-defined way is a price I’m quite willing to pay. Yes, some backwards or migration compatibility is also desirable.

The programmers probably assumed you bought the right equipment and put it together in some rational way. The automated tool will have to tell you how to cable it up, or it  might check your compliance with the recommended design. Plan on this when you look to automation for sites, a datacenter, or a WAN network.

The good news here is the the Cisco automated tools are likely to align with Cisco Validated Designs. The CVD’s provide a great starting point for any network design, and they have recently been displaying some great graphics. They’re a useful resource if you don’t want to re-invent the wheel — especially a square wheel. While I disagree with a few aspects of some of them, over the years most of them have been great guidelines.

The more problematic part of this is that right now, many of us are (still!) operating in the era of hand-crafted networks. What does the machine era and the assembly line bring with it? We will have to give up one-off designs and some degree of customization. The focus will shift to repeated design elements and components. Namely, the type of design the automated tool can work with.

Some network designers are already operating in such a fashion. Their networks may not be automated, but they follow repeatable standards. Like an early factory working with inter-changeable parts. Such sites have likely created a small number of design templates and then used them repeatedly. Examples: “small remote office”, “medium remote office”, “MPLS-only office”, or “MPLS with DMVPN backup office”.

However you carve things up, there should only be a few standard models, including “datacenter” and perhaps “HQ” or “campus”. If you know the number of users (or size range) in each such site, you can then pre-size WAN links, approximate number of APs, licenses, whatever. You can also pre-plan your addressing, with, say, a large block of  /25′s for very small offices, /23′s for medium, etc.

On the equipment side, a small office might have one router with both MPLS and DMVPN links, one core switch, and some small number of access switches. A larger office might have one router each for MPLS and one for DMPVN, two core switches, and more access switches. Add APs, WAAS, and other finishing touches as appropriate. Degree of criticality is another dimension you can add to the mix: critical sites would have more redundancy, or be more self-contained. Whatever you do, standardize the equipment models as much as possible, updating every year or two (to keep the spares inventory simple).

It takes some time to think through and document such internal standards. But probably not as much as you think! And then you win when you go to deploy, because everything becomes repeatable.

Read More »

Tags: , , , , , , , , ,

#EngineersUnplugged S4|Ep12: DevTest on UCS Blades, Home Lab How-To

February 5, 2014 at 10:32 am PST

Welcome to the Season 4 Finale! Instead of a cliffhanger, Randy Keener (@vmrandy) and Trevor Roberts (@vmtrooper) bring you practical how-tos for your dev/test or home lab environment. If you have wanted to try your hand at code but didn’t know how to start, or if you want step-by-step on devtest on UCS Blades, this is the episode for you.

Read More »

Tags: , , , , ,

#EngineersUnplugged S4|Ep11: Level Up Your Skills, Next Gen IT

January 22, 2014 at 3:28 pm PST

In this week’s episode of Engineers Unplugged, Scott Hanson (@CiscoServerGeek) and Conrad Ramos (@vNoob) discuss the IT jobs of the future, what the next gen needs to learn, and how to level up your skills. It’s a can’t miss watch for anyone interested in the trends of the industry. Also, how can your efforts benefit the community? Watch and see:

Unicorns at work: Scott Hanson and Conrad Ramos talk next-gen IT skills.

Unicorns at work: Scott Hanson and Conrad Ramos talk next-gen IT skills.

**The next shoot is last week of January at Cisco Live in Milan! Stop by the Social Media Hub to say hello.**

This is Engineers Unplugged, where technologists talk to each other the way they know best, with a whiteboard. The rules are simple:

  1. Episodes will publish weekly (or as close to it as we can manage)
  2. Subscribe to the podcast here: engineersunplugged.com
  3. Follow the #engineersunplugged conversation on Twitter
  4. Submit ideas for episodes or volunteer to appear by Tweeting to @CommsNinja
  5. Practice drawing unicorns

Join the behind the scenes by liking Engineers Unplugged on Facebook.

Tags: , , , , , ,

MPI Programming Mistakes

February 25, 2011 at 7:30 am PST

Mistakes

I’ve seen many users make lots of different kinds of MPI programming mistakes.

Some are common, newbie types of mistakes.  Others are common intermediate-level mistakes.  Others are incredibly subtle programming mistakes in deep logic that took sophisticated debugging tools to figure out (race conditions, memory overflowing, etc.).

In 2007, I wrote a pair of magazine columns listing 10 common MPI programming mistakes (see this PDF for part 1 and this PDF for part 2).  Indeed, we still see users asking about some of these mistakes on the Open MPI user’s mailing list.

What mistakes do you see your users making with MPI?  How can we — the MPI community — better educate users to avoid these kinds of common mistakes?  Post your thoughts in the comments.

Read More »

Tags: , ,