cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Automate All the Things!

Level 10

automate.png

Eric Wright (Discoprosse) talk on this topic from a server/orchestrations side in his February post Server Build Processes, Monitoring, Orchestration and Server Lifecycle Management  but I wanted to circle back around and add networking into the mix.

There is a ton of information and views on the topic of network automation and in order to keep this post short and open Im only going to graze the surface of these topics. Also Im going to speak mostly for the Data Center space but this topic could also pertain to the enterprise network as well.

Centralized Controllers and Network Automation

The big challenge with modern data centers is how to manage and deploy these massive infrastructures and their growing complexity. Imagine managing hundreds of switches, thousands of VLANS, possibly spanning multiple data centers, servicing hundreds of customers. Each customer needs their own space and must be isolated from everyone else. These customers also expect turn-up as fast as possible.

Network vendors have addressed these challenges and design shifts in multiple ways. Both Cisco and Juniper have deployed a controller based solution where access and top of rack (ToR) switches are controlled and managed by a central controller or master switch. This design reduces the number of devices administrators need to manage and also simplifies deployment of changes or add/removes. Multiple vendors are also opening up there switches allowing 3rd party software or controllers to manage their switches.

Controllers to me are the network industry dipping our toes in the orchestration/automation realm. As I'm sure most of you know there is a lot of activity right now in the network automation realm.  

Several open source projects are out leading the charge on network automation such as OpenStack, Open Daylight and I'm sure there are others. Vendors are also making a move in this realm such as Cisco's ACI. You are also starting to see new companies pop up with some really cool products such as tail-f.

Everyone sees this topic differently so I want to hear what you think. To me automation will remove the redundant manual configuration of network equipment and speed up and simplify network deployments even further. It will also give us better control and allow us to quickly adapt and alter networks with changing traffic patterns.

Anyone here been playing with these tools?

How do you see SDN and Network automation changing our day-to-day roles?

18 Comments
MVP
MVP

I have not worked with those products specifically.  In a past lifetime I provided similar tools to provide mass updates via perl to vpn appliances and switches at 5000+ stores.

The network team would provide me with the "approved" commands and I'd write a perl script to update all the devices beginning with the lab stores to validate.

Level 10

I've only used tools such as SolarWinds NCM and ManageEngine DeviceEngine.  If these count.  I don't think they do.  Based on the hyperlinks to the open source stuff.  Maybe they do.  Not sure.

Level 10

Yeah I think these types of tools are the grandfather of this stuff. Up until now everyone who needs to manage a large number of devices must develop or deploy some sort of script or tool to automate changes. Usually it involves hooking in via SNMP or SSH/Telnet logging in and making the changes.

Companies now are opening up their devices via API to allow direct control and management. This gives you full control and viability of any given device and will also give you a very good holistic view of large infrastructures.

To me the two areas of networking that hint on what is going on is controller based wifi and NAC (shudder). Wifi everyone is familar with. You deploy an AP with little to no configuration and it auto-magically assimilates into the borg. NAC on the other hand controls remote access into a network and dynamically defines VLAN, ACLs and access based on specific criteria on the remote user and hardware.

These are all different types of network automation.

Level 13

My current employer is migrating to Cisco Nexus switches as our core and distribution in our facilities.  As described by that1guy15 our data centers use Nexus 2K's as the top-of-rack switch, controlled by a Nexus 5K.  We also have a number of VMware/ESX/UCS clusters.

However we're not realy looking at any SDN as I would picture it.  It can be said that there is some SDN going on in the VM clusters regarding which VMs connect to which VLANs but that is the extent of it.  Our data centers are relatively static and we like to keep them that way.

SDN is a cool idea and I can see some application in hosting environments, but how many other environments are dynamic enough to really get any use out of it?

Level 12

How do you see SDN and Network automation changing our day-to-day roles?

Unless software developers start behaving themselves, SDN terrorizes me. Network Automation needs extremely good planning to work correctly (I mean, not create more problems) and we all know that planning is always done correctly in every shop... Mass deployment of changes in network gear and single point of administration, I'm all in... but automatic configuration changes based on network load or software demand... not so much.

I see a nice new wave of exploits coming up in the next few years...

Level 10

"SDN is a cool idea and I can see some application in hosting environments, but how many other environments are dynamic enough to really get any use out of it?"

This is a big talking point to a lot of people which circles back to my main theme. What level of complexity does each DC really need. Keep in mind also, DC is a very lose term thrown around for anything from a basic one rack server rooms or all the way to Google's DCs and everything in between.

Does each and every datacenter need a full Cisco UCS chassis environment for virtualization or would dedicated hardware per ESX box be enough?

Once again it always comes back to "it depends"

Level 10

Food for thought.

Will developers jump the divide, learn networking and do network automation or will network admins learn programing and do it?

Im with you 100%. I fear a Dev team taking over network operations and deploying automation without really having a handle on networking beyond what they learned in their CIA classes in college. But on the flip side I dont trust my self one bit to develop/test a production-grade application. Heck im lucky if I can peace together a batch script at the moment.

Level 14

So, here's additional "food for thought." I've had a little exposure to SDN/ACI/automatic networking recently. Here's what I took away from the experience:

  1. It took 15 CCIEs to build the environment, and requires 3 CCIEs to maintain it on a daily basis. All that, just so 1 App Developer can point and click to build a server for their new app. All that just so some App Developer with no infrastructure background can build a server that doesn't meet their needs can tear it down and try 3 - 4 more times until they get it right.
  2. Who out there uses ASDM (ASA admin console)? For those that do, have you seen the ASA config after you apply your change? The nightmare configuration it creates. Well, same thing here. The tools apply the same mess to your clean config.

As stated above, I see many exploits in our new future due to messy configs and lack of experience to properly clean them up.

I'm no longer terrorized...I started building a dooms day bunker!

D

Level 21

We are a service provider and the idea of automation on large scales is incredibly exciting.... and incredibly scary.  My largest concern is that all software has bugs.  The more widespread and the more control an application has the larger the risk a potential software bug has on your environment.  Imagine the possibility of one bug or failed deployment destroying your entire environment.  I know that may sound a bit paranoid but the software bugs I have to deal with now on "stable" releases is already more than I like to manage.  Then again, only having a few commands to issue to deploy all the bits necessary to turn up a new customer is certainly a nice concept!

Level 10

This is where I can see it taking on a market such as service providers.

My pie in the sky view of how SDN/Network automation could be: customer A calls SP XYZ (or does it online through a web tool) and purchases cloud services for an entire infrastructure. Purchase is executed then the client is spun up with a few clicks of the mouse and selecting a tick box for the services they want. Within hours customer A has full access to their new private infrastructure.

I know, I know there is a lot of holes in this one and a TON of concerns but this is just how I imagine automation transforming what we do.

This will also give me more time on the back end to watch cat videos on youtube all week!

Level 17

Just what you check, it shouldn't change the way you think.

With automation there is also more of a need for programming knowledge, the ability to script and decrypt someone's bad script will be needed. That along with the basic knowledge of whatever you are scripting for just paves the way to the IT Pro.

MVP
MVP

proper comments/documentation in the scripts are super important....otherwise they are not 3 AM friendly.

Level 17

only insomniacs are 3 AM Friendly.... but still most are not very friendly at 3 AM.

Level 12

I usually don't sleep a lot... but I can tell you, at 3 AM I am far from friendly in any circumstance.

Level 10

your second point is something I had not yet thought of...if all these config updates are automatically getting pushed, it could cause chaos trying to find and troubleshoot a single element in a config file and makes it look horrible although I guess to the same point using SDN engineers shouldnt have to look at configs

Level 10

Great write up! I'm working to try to get as much in vCenter Orchestrator as possible, but I've done Puppet also which is great for cross-platform and cross-silo (network, server, desktop) so I think it has good chances to take a strong hold out in the wild.

The trick for many is to pick up languages. I'd say that Python is the top given it's wide use in many projects.

Level 15

Good discussion.  I found it educational and informative.

I like the tone of the responses:  have a great reason for making major changes--something better than just having an Application person be able to run a GUI instead of relying on a Network Analyst to run a script.

Don't get me wrong, I appreciate a great GUI that's fast and reliable and intuitive.  In my dreams I wish Cisco'd never gone down the Network Assistant path, and had instead bought out Nortel and deployed their Device Manager and ESM technologies across all IOS.  That would've been sweet to use.  Fully intuitive and fast GUI's, while keeping the full CLI scripting path option available for massive and fast changes.

My organization went with Nexus six years ago when we replaced our Nortel data center infrastructure, and outside of getting some faulty chips from Asian manufacturers, it's been reliable.  Complex, challenging to manage on occasion (can you say "OTV"?  I knew you could.), but much more reliable than Nortel hardware and code.

Now we're planning to migrate to ACI, and I'll confess to being a bit intimidated.  I've not gone done the scripting path required for ACI management, so I've got some learning to do.  But the overall benefit to all IT departments should result in faster and easier and more intuitive changes, that provide improved visibility between UCS and Nexus/ACI solutions.

I'm cautiously optimistic, for a new solution that might be fraught with Murphy's laws.