The below is my initial take on much of what I learned from and about HP products this week.  Note: it’s not meant to include every announcement they made this week.

They announced their own virtual switch.  They join the likes of Cisco, IBM, VMware, and NEC that all have distributed virtual switches.  Since I didn’t have a deep dive, I’m hesitant to call the HP virtual switch a switch.  Today (or day 1 when it ships), the virtual construct they load in the hypervisor will only run in VEPA/EVB mode communicating to an HP top of rack switch.  To make a comparison to the Cisco world, it is essentially a fabric extender.  Also think VM-FEX.  So in theory, it’s not really a traditional virtual switch.  I would expect all VM to VM traffic local to a single host to actually occur on the HP TOR, but if this is incorrect, definitely let me know.  This means no overlays from hypervisor to hypervisor for HP.  If they target the mid-market, this could work well for simplified management of the physical and virtual environment.  I was also told that eventually it will or could operate as a virtual switch independent of the TOR switch.  Another point that I didn’t get a chance to clarify was how their current model works with VM mobility.

They talked publicly quite a bit about their integration with MSFT Lync and also the Tipping Point IPS to deliver SDN apps to the Campus.  These SDN applications integrate and manipulate flows in real time to enhance QOS for Lync traffic on an HP network and also re-direct DNS queries to be inspected/analyzed to have a fully distributed botnet filter.  In both cases, they are using what I think Ivan (@ioshints) would call “unprotected hybrid port mode.”  The nice thing here is, HP is keeping it simple. They are effectively doing PBR in hardware.  If there isn’t a match against the OpenFlow FIB, the packets are forwarded using their normal pipeline or MAC-table in a L2 switch here.  This means there isn’t any reactive flows or change in how L2/L3 is done today when deploying these applications.  I did clarify during the demo of the Lync solution after “QOS” was mentioned to be modified with OpenFlow that HP specific OpenFlow extensions are being used today and the goal is to get these extensions into the next release OF – maybe 1.4+?

HP is also a member of the newly formed OpenDaylight project.  In numerous discussions with multiple vendors, not just HP, it seems (speculation on my part) the focus is to continue down their own path when it comes to controller development.  Vendors don’t seem to expect soutbound APIs to be the same across their own offerings and OpenDaylight, but however, the majority does want a standard northbound API.  This way, the application works on both controllers and the southbound APIs become an implementation detail (assuming they are open standards based protocols :-)). 

OpenStack contribution – this was news to me, but HP was a TOP 5 contributor for the latest Grizzly release of OpenStack.  I kind of wish they adopted OVS for their virtual switch.

TRILL – HP also announced their next gen DC Core/Agg/TOR platforms.  While they are beasts like most core switches, the point I want to make is they support TRILL today.  Someone from HP told me they are one of two companies now supporting standards based TRILL.  But for me, they are the first company that I’m personally hearing of that supports TRILL.  Not sure of the other.  I wonder what a full stack deployment would like with VEPA/EVB from TOR to hypervisor and TRILL on the same TOR northbound to the spine/Core? 

I hope to share much more about my experience at Interop over the coming days!  If you are curious about anything in particular, feel free to write in ask.  Comment below or contact me privately. 

Thanks,
Jason

Twitter:  @jedelman8



Disclosure: Ivy Worldwide and HP covered my expenses on the trip, but they in no way asked for anything in return.  

Step 1: Download Virtual Box

Step 2: Install Virtual Box!

Step 3: Download a Linux Distribution. 

I am a beginner in Linux so rather than shy away from it, my goal is to simply embrace running into issues and use the interweb to help overcome a problem or perceived problem in Linux.  That’s the best to do to learn this stuff.  I chose Lubuntu mainly because that’s what was used in the Open Networking Summit Engineering Tutorial just a few weeks ago.  Its GUI is Lightweight and less processor/memory intensive, so it’s great for running on a personal machine.

Step 4: Install Lubuntu. 

Your download should have been a disc image file (.iso).  You’ll need to create a new VM in Virtual Box.  Select new, enter a name for your VM, and select Linux as the OS Type and Ubuntu as the Version.  I’d recommend using 2GB RAM.  The rest of the settings can remain as default. Now we must mount the .iso to in order to boot from it.  In Virtual Box, click your newly created VM, go to “Settings,” then “Storage.”  Then click just under the CD icon in the center where it says “Empty.”  You’ll see CD/DVD on the right side.  Browse to your ISO, select it, and start your VM.  Run through the install process accordingly.  Once installed, don’t forget to unmount the ISO.

Step 5: Install “Guest Additions” in the Lubuntu VM. 

This makes it so you can seamlessly copy and paste between your machine and Guest OS (Lubuntu).  It also allows you to re-size the guest OS display window more appropriately to match that of your real machine.  For those who are familiar with vSphere deployments, this is analogous to VMware Tools.  While in the new Linux VM, go to the  Devices drop down, then “Install Guest Additions.”  You may need to force the mount here.  In order to install on the machine, I did the following:

Open a terminal window.  Browse to the media directory.  It was

 “cd /media/Jason” 

Jason is the user account that I created during the install.  From here you can issue an “ls” command to browse the directory.  You should see the VBOXADDITIONS directory.  Browse to this directory.  You can do:

“cd VBOX” and hit TAB. 

It will auto-complete just like Cisco CLI.  Issue “ls” to see available files.  I ran the Linux additions since after all, I installed Linux.  To run the script, you need to now enter:

“./VBoxLinuxAdditions.run”

and hit enter.  Note that “./” signifies you’ll be executing a script.    Once installed, you can enable Shared Clipboard and Drag ‘n Drop via the drop down “Devices” drop down menu.  Poke around on the drop down menus on top of the VM in the Virtual Box menus.  In the “View” menu, you can also re-size or just double click the Virtual Box bar on top to maximize the full window just like you do any normal windows application.  You may need to reboot Lubuntu in order for the guest additions to fully take effect.

Step 6: Install required components needed to compile and download the OpenDaylight Controller. 

Git, Java JDK/JRE, and Maven need to be installed. “apt-get” is used to install applications in Linux, so it’s a command you’ll see often.  The controller requires maven to be compiled – not sure of the technical details and why, but it seems many of the controllers/APIs/apps coming out require maven to compile and build the application.  Git is used to clone the code and download it from a repository to your local machine.

You can install the required components as shown below, but first let’s update the Linux distro.

“apt-get update”

and then install the components

“apt-get install git”

“apt-get install openjdk-7-jre”

“apt-get install openjdk-7-jdk”

“apt-get install maven” 

I chose to install these individually because it made it easier to debug and troubleshoot.  For me, git and java installed just fine, but maven kept failing.  But you can however, install them all at once like “apt-get install git openjdk-7-jre openjdk-7-jdk maven” if you wish.

I kept getting errors that involved “libwagon” during the maven installation.  After researching this, I found that the following command fixed the problem:

“sudo dpkg -i --force-all /var/cache/apt/archives/libwagon2-java_2.2-3+nmu1_all.deb”

This will force installation of libwagon2.  Following this, you can re-try maven with:

 “apt-get install maven”

By now, you may have realized you need “sudo” in front of commands that require “admin” or “root” privileges!  Maybe I should have stated that earlier :).

Step 7: Download the OpenDaylight controller. 

Using git, enter

 “ http://git.opendaylight.org/gerrit/p/controller.git “

Step 8: Compile and build the controller code using Maven. 

Browse to the following directory

“cd controller/opendaylight/distribution/opendaylight/”

Compile the controller using maven:

 “mvn clean install” 

This was another issue I had.  The install kept failing and it seemed I was low on memory based on the error I was getting.  I also read in other posts to boost the VM memory, so I did.  I went from 1G to 2G to even 4G for my VM.  The install still failed.  After some digging and while still at 4GB RAM, I used this command:

 “export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=128m" 

This was just what was needed.  The install worked perfectly.  I actually finished the complete install process of the controller then reduced the memory back to 2GB and haven’t had issues since.

Step 9: Set the JAVA_HOME variable. 

This is required so that the OpenDaylight controller knows where to find the required JDK needed to run. This is done by entering:

 “export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-i386/”

This only sets it for the active session and we want it to persist during reboots so we also need to enter the same line somewhere else.  In Linux, there are various scripts executed when starting up and as users log in.  The trick is knowing which one to edit.  Since I am the ultimate novice, I tried more than one as you’ll see on simple google searches, but it was “.bashrc” file that worked for me.  This runs every time you login to the OS.  In order to do this, we’ll need to edit a file in Linux.  For anyone that has ever attempted editing a file in Linux, this means using VI, which could be dreadful to use. Of course, this is only my opinion.  After a quick search, I was able to fine “gedit” --- an easy to use application to edit files in Linux.  In order to edit .bashrc, first download “gedit” by entering

“sudo apt-get install gedit”

and following the install, navigate to your user directory.  For me this is /home/Jason.  At the prompt, enter

 “sudo gedit .bashrc” 

If you don’t enter “sudo” here, the file will still open and you can still edit the file, but it won’t save due to permissions, so remember to use sudo.  .bashrc will automatically open --- once it is open, you can easily navigate the file and enter:

“export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-i386/”

 I entered this on the last line of .bashrc.  After a reboot, you can ensure the JAVA_HOME variable is still set by entering

“echo JAVA_HOME”

 --- you should see the location of where the JDK is that you previously defined. 

Step 10: Launch OpenDaylight Controller. 

In order to run the controller, navigate to the directory as such

 “cd /opendaylight/controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-0.1.0-SNAPSHOT-osgipackage/opendaylight”

Once in this opendaylight directory, you can execute the run.sh script by entering

 “./run.sh” 

Remember “./” is required to run scripts.  It’ll take about 30 seconds for the controller to get fully get up and running.

Step 11: Connect to the Controller. 

Launch a web browser on the OpenDaylight server and browse to http://127.0.0.1:8080 or using a different machine on the network, browse to the controller using http://x.x.x.x:8080.  You can login to the controller using admin/admin! 

Step 12: Create Directory Alias

If you reboot quite a bit and login daily, it becomes nightmarish navigating to this directory to launch and run.sh.  So, the nice thing is Linux allows you to create an alias for whatever you want.  I simply created an alias to quickly navigate to proper opendaylight directory.  I entered this at the command prompt:

“alias odp=cd opendaylight/controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-0.1.0-SNAPSHOT-osgipackage/opendaylight"

Note: I configured the alias from the /home/Jason directory since that is where I am at time of boot up.

Similarly, we also need the alias to persist  on reboots, so we need to edit .bashrc again.  Open .bashrc using gedit and add the full alias line as above in quotes.  Enter it in the “alias” section.

Step 13: Create shell Alias

Rather than have to enter “./run.sh” each time I want to run the controller, I created another alias.  This is:

“alias startcontroller="./run.sh" 

Don’t forget to add this to bashrc as well!!   Now, non-Linux users can quickly navigate and start the controller.

Step 14: Reboot and try it all!

After restarting your Linux, you can simply start up, launch a terminal window, and enter:

“odp”

and then

“startcontroller”

and you’ll be up and running!

This gets you access to the controller.  There is a different process to hack the code in Eclipse/JAVA that isn’t the focus here.  My goal was to try and break it down for people like me, new to Linux, the world of programming, and even virtualization.  Soon I’ll post more on how to actually do something with the controller like attaching virtual switches.

I couldn’t have done this without the posts from the OpenDaylight Wiki, Brent (@networkstatic), and Jon (@Blinken_Lichten).

Until next time.

Regards,
Jason

Twitter:  @jedelman8

In Vahdat’s answer, you didn’t really hear anything concrete, but the point he did make was vendors need to open up their platforms in order to take full advantage of the ASCIS on board network devices.  I also heard this from someone who works at another web scale giant during a lunch table discussion.  It seems that some chips can do much more than advertised.  For example, some chips can handle MPLS, but the hardware abstraction layer (HAL) or software abstraction layer provided by the vendors does not permit them to take advantage of such functionality.   In the example that I heard, I’m not sure if it was the Broadcom HAL being referred to or if it was another abstraction layer created by another vendor, but the underlying point I was hearing was too many abstraction layers limits things and these guys want DIRECT access.  Each layer of abstraction on a switch limits the amount of hardware programmability they get to take advantage of; could be another reason why Google built their own switch, in addition to the big reason that no vendor at the time offered  256 port 10G switches several years ago when they first built theirs.

Does anyone have concrete examples of this with certain vendors, chipsets, HALs, SALs, etc.?  This is an area that I’m interested in and don’t have much direct experience with.  Any other data that can be shared would be great.  Feel free to leave a comment or write in privately.

On a related note, I know someone *cough* (@networkstatic) *cough* who is dying to get access to the new Unified Access Data Plane (UDAP) ASIC that offers a programmable data plane onboard the new Cisco 3850 Converged Access Layer switches.  Will this be opened up to the public?

Vendors need to unleash the beast  to really show off hardware programmability.



Thanks,
Jason

Twitter: @jedelman8

The OpenDaylight project will offer the ultimate anti vendor lock-in at the controller layer for SDN solutions regardless if it’s Cisco’s or Big Switch’s code underneath.  Aside for getting some good industry gossip, at the end of the day, it really won’t matter who actually produced the code for those that want to use and deploy the technology.  What will matter is to ensure it remains open source and community-driven.  Because there are so many vendors including start ups and incumbents working on ODP, it will be interesting to see the strategy each company takes with regard to their own commercial offerings, either based on OpenDaylight or their own proprietary controller such as Juniper’s Contrail controller, Cisco’s ONE controller, and Big Switch’s Big Network Controller, etc.

What I really look forward to is how the OpenDaylight controller will be deployed, by which customer types, and who will support the controller?  Why is this interesting? 

Because open source is pretty new for the network industry at large.  Open vSwitch (OVS) has been around for a years now and although Cisco does contribute to OVS now, it was initially largely led and created by Nicira.  On the other hand, it is Cisco leading the charge for OpenDaylight.  Because of that, it will get much more attention from the traditional communities of the network industry from users and operators to resellers and solution providers.

The vibe I am getting is that vendors want integrators to step up and support an open source platform like this, but this is not business as usual by any means.  Typically, both customers and integrators rely on that official support/SmartNet SKU to resell just in case there is a problem. 

I recently wrote here about CloudScaling, and they are worth mentioning again.  They are already selling and supporting their own Cloud Platform based on OpenStack.  Projects like OpenDaylight bring more opportunity for companies like them who aren’t necessarily relying on vendor support, but contributing code and offering their own product based on major releases/distributions of open source projects.

Just as incumbent vendors are figuring out their strategy and startups are emerging with new technologies, the same holds true for services-lead organization like Solution Providers/Integrators, and then product/services companies like CloudScaling.  Incumbents will likely adapt while more companies like CloudScaling emerge. 


As this happens, what does this mean for the vendors and their own software solutions?


Thanks,
Jason

Twitter: @jedelman8

• Goldman mentioned commodity switches twice. 
  

• Within weeks/months, they will be going into production with two (2) SDN deployments.  One of them is the commonly talked about SDN application using commodity hardware as matrix switches with an app on top of a controller to direct flows; the other is to replace bump in the wire firewalls.  There are several spots in the Goldman network that have FWs deployed that are costly to buy and manage.  Schwartz stated that maintaining FW state is not a requirement for these areas of the network for Goldman.  They’ll be using commodity switches as glorified packet filters that will require bi-directional ACLs to be configured from the controller and delivered down to the switches forwarding tables.
  

• It took a junior engineer just a few weeks to develop a lightweight FW application that sits on top of a SDN controller
  

• Floodlight was mentioned by Goldman, but not stated if it was being used for one or both applications mentioned.  No surprise given the investment of GS into Big Switch Networks.
  

This can raise the question for Enterprises – are stateful firewalls *required* for single tenant data centers for intra-DC traffic as bandwidth requirements increase and nothing but multi-10G firewalls are available that cost 100s of thousands of dollars for environments that are already deploying 40G/100G switching infrastructure?  Same actually holds true for virtual security solutions leveraging ACLs like the Cisco Virtual Security Gateway meant for intra-tenant traffic.

Nick Buraglio wrote a few months back in an article: “Think of buying an OpenFlow capable device with 40 and 100G interfaces in it as your firewall….  Port cost is very low.  CAPEX is low.  OPEX is also fairly low since it is just a normal piece of network hardware. “ This is an option for those customers who want big box FWs and do not want to go down the path of scale-out designs with or without Network Functions Virtualization (NFV).

We’ll see if security teams adapt and re-think requirements for statefulness in certain parts of the network and if any companies follow Goldman’s lead on SDN in the Enterprise.

Note: Goldman didn’t state they were using the commodity switches and SDN FW application in the data center.


Thanks,
Jason

Twitter: @jedelman8

For anyone that’s been following the SDN space for a while knows that this falls in line with what Martin Casado, OpenFlow creator and Nicira co-founder, has stressed over the years -- Nicira’s goal is/was to virtualize the network, not evangelize or sell Software Defined Networking (SDN).

Here is the thing.  It is possible to deploy network virtualization without SDN and without a controller.  For example, in the current vCNS VMware networking architecture (pre-Nicira), it is possible to deploy VXLAN along with vShield Edge and App appliances.  You can also deploy Cisco Nexus 1000V with vPath, VXLAN, ASA 1000V, and VSG.  These designs offer properties of the physical network in the virtual network by abstracting the underlying network hardware deployed via overlay protocols (w/ mcast) and NFV (network functions on VMs) with centralized management and integration to Cloud Management Platforms.

With Nicira networking, a controller is used as the control plane in that it manages the proactive setup of certain flows by creating MAC to VTEP entries (using VXLAN as an example; STT could be using different terminology).  The solution also offers gateways to get from the overlay to the traditional/legacy world and then other nodes that are used for controlling BUM traffic.  Does what they are doing make the Nicira solution SDN or simply a control plane for an overlay encapsulation protocol that compliments local MAC learning? 

By the most concrete and succinct definition given at ONS, it may not be SDN.  This definition was that of Nick McKeown, Professor at Stanford, co-founder of Nicira, Board Member at the Open Networking Foundation (ONF), and PhD advisor to Martin Casado.  The definition went something like this:  SDN has two properties (1) physical separation of the control plane and data plane and (2) a single controller (control plane) can control multiple devices.

The control plane Nicira developed adds entries to the already existing MAC table in Open vSwitch.  So, OVS still performs local MAC learning.  It still has a control plane, no?  If this is incorrect, please let me know.  Nicira also handles BUM traffic with their complementary control plane.  The point – there is still a local control plane on each switch – Nicira did not want to re-invent basic functions of switches as can be inferred from reading several articles by Nicira and Casado at Network Heresy.

However, since their controller cluster is integrated to Cloud Platforms such as OpenStack, it could be possible to fully extract each switch’s control plane and manipulate the MAC/flow tables as new VMs are created, moved, etc.  Maybe we’ll see it evolve to this; because of their current architecture, it is already completely possible to accomplish though.  They would only need to write their own control plane to replace local MAC learning.

But, other vendors are leveraging controllers to manage overlays like Nicira and selling it as SDN while Nicira sells the Software Defined Data Center (SDDC).  The way each enables MAC to VTEP manipulation or any type of control plane could be different.  That would be a point to compare between different network virtualization solutions.

Personal perspective: While Nicira executives may like to really be specific on Network Virtualization vs. SDN, you know their sales teams are in fact selling SDN solutions today regardless of what is written or said at public conferences.

Based on McKeown ‘s definition, here are two closing questions.  (1) Can a switch that performs MAC learning be called SDN? (2) Can a MAC table exist on a switch and be called SDN?

At the end of the day, what really matters? If network virtualization fixes the problem and it’s not with OpenFlow or SDN, should that matter? 

As usual, if anything is not accurate as stated, please let me know.

Related links:

• An Evolutionary Approach to SDN 
  

• Is OpenFlow/SDN Good at Forwarding?
  

• VXLAN, IP MULTICAST, OPENFLOW AND CONTROL PLANES
  

• Network Virtualization Part 1
  

• Network Virtualization Part 2
  

Thanks,
Jason


Twitter: @jedelman8

Hands-on Labs

The labs were far better and easier to follow than last year.  You can tell a lot of time were put into them.  The labs were based on Beacon --- an open source controller based on Java that seems to have served as the foundation for Floodlight and OpenDaylight.  Those who are frequent readers here know I’ve been spending some time learning Java.  Since I had the source code from Beacon in front of me running in Eclipse today, all I could say is I’m glad that I put the time in prior to today.  In the labs, we deployed Beacon to operate as a hub and then change it to operate as a learning switch.  Although I don’t expect to be building my own controller anytime soon, it was definitely cool to see and manipulate the code in Java.  You never know when you may want to tweak something here and there when you’re in the lab.

The last exercise was with deploying FlowVisor.  I didn't get through this one, so I’ll have to find time sometime soon to check that out.

The Lectures

As I said last year after ONS, I felt it was largely geared towards academics and researchers.  I had a little bit of that same feeling today.  That’s not necessarily good or bad or right or wrong, but as SDN continues to gain momentum, the presenters need to keep the audience in mind which is made up of an increasing number of network engineers.  I heard a hypervisor vendor say recently (not at ONS) “bypass the network team” with network design engineers on the call.  Not what you want to say to network guys.  I heard some similar things today that shouldn't be said to the folks you want to empower to get SDN deployed.  One thing is for sure, the researchers leading this movement do not consider themselves network engineers, and that is perfectly okay.  If they were, we wouldn't have SDN.

Where is the innovation?

SDN applications and use-cases talked about today included network virtualization, network load balancing aka smart routing, wireless bi-casting using wifi and wimax, and how to power down links/switches to reduce power in data centers.  Most of these were talked about last year at ONS in the same tutorial.  I actually wrote then many of these projects and demos have been on Stanford’s website and YouTube since 2010.  Last year Nick McKeown gave a great keynote at ONS, arguably the best session of ONS 2012.  That was also talked about today.  Why more of the same?  It couldn't hurt having some vendors talk about SDN applications in a session like this without doing full blown product pitches.  I think that would work out well.

I want to get jazzed about SDN.  Jayshree kicks the day off tomorrow – I hope she will motivate, inspire, and get the audience going.  


Thanks,
Jason

Twitter: @jedelman8

Now I want to elaborate on my original question:

I mentioned OVS, Quantum, and OpenStack in the original question.  But, it’s really much more than that.  Take a look below at the free and open source technologies widely talked about, but also at other smaller, but impactful trends happening throughout IT.  As you read through, think about how one can directly affect another.

• Cisco Nexus 1000V (1KV) – free Cisco virtual switch

• Cisco Data Center Network Manager (DCNM) –platform to monitor/manage the Nexus 1000V; DCNM is free to fully manage 1KV
• OpenStack – open source cloud management platform
• Quantum – open source network API part of OpenStack
• Open vSwitch  (OVS) – open source virtual switch
• OpenDaylight – open source SDN controller largely led by Cisco 
• Floodlight – open source SDN controller led by Big Switch
• Open source hypervisors
• Network Functions Virtualization (NFV) – running network services on VMs; offers the ability to evaluate almost any network appliance without ever meeting a sales team.  Good or bad?
• Public Cloud – offers a business to get applications up in no time; complete agility; usage based pricing, etc.
• NIC level Firewalls – firewalls that sit in front of each virtual NIC; explicitly stated as precursor to next few bullets
• Bring Your Own Device (BYOD) –Will laptop be next?
• Evolving network provisioning and automation through Arista’s ZTP, Cisco’s POAP, Chef, and Puppet
• Cloud Management for Campus Solutions – think Meraki-like management; bringing up wireless networks has gotten easier over the years.  I’m inclined to say deploying WLAN will continue to get easier.  Add in LAN switches here as well through Meraki-like interfaces or SDN controllers and it changes staging, configuration, and deployment of both WLAN + LAN environments.
  

The next few technologies/trends may be further out, but can have significant impact on the industry.  If the web scale companies are the Enterprise beta users, we should expect to see some adoption of white box/commodity solutions hit the Enterprise within the next 12 months.

• Open Compute Project (OCP)
  
• Commodity/White box (ODM) servers
  
• Commodity/White box (ODM) network switches
  
• Cumulus –network operating system built for white box  (ODM) switches 
  
• SwitchLight – open source virtual switch; can run as a vswitch or control stack on physical switches similar to OVS; led by BigSwitch
  
• Optical in the data center – from combining electrical/optical on the same platform to leveraging optical circuit switches.  Take a look here (pdf) to read more about it.
  
• Intel Reference Design for SDN switches
  
• Intel Software Stack for Switches – via Wind River acquisition
  
• Good read: Open Compute Project’s impact on networking

 

What’s my take?

• IT is in the process of changing – it’s not coming in 3-5 years; it’s here now, but the changes are so gradual, sometimes subtle, and in select vertical markets, it’s not visible to the whole world.  Remember, this is my opinion.
  

• How often do we see vendors or analysts talk about how these trends together will affect IT, the network, and the data center?  Think Cloud + BYOD.  My thoughts on this next.
  

• All Enterprises, small and large, will become Service Providers – we only talk about the data center now, but the Campus is already “under construction” with BYOD.  Maybe we’ll see user based overlays in the Campus, maybe we won’t.  I wrote about this here.  Check it out if you haven’t already.  
  

• Once BYOD is the norm, the way we design networks will change.  Think about that.  See previous and next statements.
  

• The Enterprise data center will become one big DMZ for what remains on prem and doesn't go to the public cloud via IAAS, PAAS, or SAAS.  Over the years, I've heard the biggest risk is being attacked form within; maybe a rogue employee, but more practical, maybe a virus, Trojan, or malware of some sort.  Still, 80% of network security I see is on the Internet Edge.  Does that make sense?  Secure each and every server as if it was on the Internet – this becomes easier with new forms of security solutions like NIC level FWs, and of course with application level security. 
  

• Once Cloud Management (M&O: vCD, OpenStack, CIAC, etc.) becomes easy to deploy off the shelf, this will have a huge impact in the Enterprise.  I recently heard someone talk about selling the value of a particular server in a cloud in a box offering, but is that type of offering really about the server, converged infrastructure, or about the agility gained for the business?  If M&O does its job, things will change.
  

• Scale out architectures – it’ll be okay of a device fails and the business will not even know; the IT staff will quietly swap it out for a new one.  This should be true for network, network services, compute, and storage.
  

• Network services will run on x86 compute and will scale on demand
  

• Can you imagine scaling a control plane of a Core chassis based switch by using VMs?  Hardly, but why not? There is only so much CPU, disk, and memory on a Supervisor engine – could it be possible to off load certain tasks or functions to VMs to prolong the life of a Sup or introduce new features?   Interesting.
  

• I recently had a conversation with a white box vendor.  Pricing aside, they can provide a full IP stack with OpenFlow support on the hardware.  You can also deploy another vendor’s software stack.  They don’t care.  They even specifically mentioned BigSwitch’s SwitchLight as being available to load up on their switches.  They went on to tell me customers in my area, large F100, are already talking to them and buying their kit.  That definitely caught me off guard.  They don’t have a channel today and it didn't seem like they have short-term plans to develop one, but if they did…
  

• Major name brand players (maybe not current incumbents, but they will be name brand) will have reference architectures for combining hardware + software for network deployments even without SDN (no openflow) meaning hardware from Vendor A and software/OS Vendor B.  Vendor A, B, or C can provide the controller should an SDN deployment be desired.
  

• Customers have access to a lot of cheap, free, and open source technology.  Will the new and younger generation feel empowered to DIY, test, and play? If so, usability and manageability will be more important than ever going forward.
  

• For those who don’t DIY, offering complete solutions will still remain valuable.  As I've said before, we should expect to see new and emerging companies productize solutions that combine, as an example, their own fork of OVS, OpenStack, and OpenDaylight.  
  

• I've reviewed a lot here, but now go back to Brian’s questions and see if you think you may be answering them differently in the future, both short term and long term.  Can the future value chain help you or hurt you?
  

Am I living in a different world?  I hope so. 

 
Side bar…

Note: About 6-7 years ago, a customer of mine who had worked at the same company for over 20 years who was always striving to make a company-wide impact, not just IT, said to me if you are not trying to make that big of an impact, what’s the point?  That may not have been it verbatim, but I walked away from that thinking big and looking out for the greater good for my team, organization, and company.  I had always been a person to hope and dream, but being a young and naive SE, it was refreshing to hear that from someone who had been around for quite some time.  I try and remain young and naive, but now with more knowledge of what’s real and how others think.

 
What trends are you seeing?  Please let me know.  I need more to think about.


Thanks,
Jason


Twitter: @jedelman8

As I said in before, I think it’ll come down to the type of customer and what they require.  For a large scale muti-tenant public cloud, they will likely view the network as an IP fabric.  For Enterprise, I could see them wanting to maintain end to end visibility because that is what they know and for the fear of not being able to troubleshoot in the case of a problem.  But in the long run, that could likely change.  Time will tell.

While I usually agree with much of what Martin says, I’m not sure I like comparing voice to network virtualization.   The part that I don’t agree with would be for the Enterprise customer.  As he has stated with advanced codecs, abundant bandwidth, and some QOS, voice on an IP network has come a long way with no longer discussing RSVP when it comes to IP Voice.  Phone calls are peer to peer, with call setup being done by a call controller just like a tunnel setup in network virtualization.   One could draw even further similarities with call conferencing that require multicast to join multiple parties to what the current control plane, or lack thereof, looks like in some forms of network virtualization. 

With all of that said, while voice and video traffic are kept local to an Enterprise, network operators have full visibility to this traffic on a hop by hop basis.  This comes in handy for those trying to troubleshoot why their CXO just had a call dropped for the third time in two hours. In current forms of network virtualization where an overlay is created between hypervisor switches, this wouldn’t be possible.  Rather the network operator would likely troubleshoot a tunnel.  Tunnel is up, network is up.  Can it be that simple? The big question is, how many and which type of organizations will deploy network virtualization without regard of being able to troubleshoot individual flows in the physical network?

That doesn’t paint the best picture because some visibility can still be maintained within network virtualization, but it must be done local on the vswitch.  For example, NetFlow data can still be pulled from the virtual switch.  In addition APM/NPM tools such as Riverbed Cascade (as an example) can be deployed on each physical host to correlate data entering the tunnel (pre-encapsulation)  and exiting the tunnel (post- decapsulation) correlating a single flow within a particular tenant.  This would allow a network operator to see end to end latency, packet loss, along with full traffic analysis/statistics.  If SLAs were being offered, it would still be simple to prove they are being adhered to or broken.  This type of network visibility could be offered under or over the cloud.  If the physical network had different paths in their IP Core, they could then *possibly* shift where that traffic appropriately based on traditional routing metrics.

Random : In general APM/NPM are often deployed in a passive manner (via SPAN/tap) using something like RVBD Cascade mentioned above, but for those who have access to the actual servers to load agents on, Boundary has a slick solution that is able to gather flow level data from every server and correlate it together.  This makes Boundary a great solution if servers are deployed in multiple data centers and in the public cloud.  How did Boundary get that domain name is what I want to know? :)

In a recent post, I talked about Network vMotion and Network Driven DRS.  I still believe there could be benefit integrating the virtual network and physical network.  In this model, there would be intelligence exchanged between the network virtualization manager (NVP, etc.) and physical top of rack switches, not the full network including Core/Distribution.  Just the virtual edge and physical edge. 

Resource pools are created within vSphere today and a virtual server admin would not add a new VM to a resource pool that is already at 98%.  Why would we allow a VM, or group of VMSs, to be added to physical hosts that connect to a Top of Rack (TOR) switch that already has its uplinks at 98% utilization.  Simple answer.  We can’t prevent it today because there is no communication between the physical and virtual networks to know this utilization or dynamically react to it, hence Network Driven DRS.  Rather than being driven by the network, network I/O should be an attribute the hypervisor uses to calculate proper VM placement. 

How do we mitigate this?  Can we deploy something like Call Admission Control (CAC) for network virtualization?

1. Ensure there is no oversubscription and unlimited bandwidth in the data center using a non-blocking fabric; this may be the recommendation from vendors who sell only network virtualization 
2. Use optical in the data center to bring bandwidth where it’s needed – a moving partial mesh; this would be the recommendation for those who sell physical networks with optical integration that tie back into the hypervisor
3. Load a hypervisor (VMware, etc.) agent on each physical TOR switch (VMware tools-ish) so total bandwidth capacity and utilization was known and bandwidth could be a factor in VM placement; while this sounds interesting, I’m not sure incumbent network vendors would entertain this.  Possibly on open platforms or whitebox solutions.
4. Because what I described is applicable to network virtualization using VXLAN or VLANs, there could be parallel communication between the hypervisor manager (vCenter) and a focal point of physical network control.  Hmmm --- we don’t have controllers in the physical network, yet.  This could be an ideal solution once there is a controller in the data center communicating/controlling TOR physical switches.  This solution would differentiate a particular vendor’s hardware solution.
5. Develop rack awareness for physical hosts and monitor total network bandwidth utilization for all VMs in a given rack.  This could be something a server virtualization vendor can accomplish fairly simple with CDP/LLDP and bandwidth tracking.
   

What do you think?  I’d love to hear your thoughts.

Thanks,
Jason

Twitter: @jedelman8

vPath is a strategic Cisco technology used in Cisco virtual switch deployments; it is a semi *closed* or proprietary technology that offers a way to redirect or steer traffic flows in Nexus 1000V environments.  It is not directly doing this communicating to the forwarding table, but rather using a service policy.  Similar result, but done different when compared to OpenFlow environments.  While it is a Cisco technology, Cisco is allowing 3rd parties to integrate virtual services with vPath.  Two of these include Citrix and Imperva.  You will start to see vPath is Cisco’s way to enable policy based traffic steering in virtual environments.   However, it isn’t used to broadly enable traffic steering or take over full control plane functionality – rather, it is used to steer traffic to and between virtual service nodes (VSN) such as the Cisco Virtual Security Gateway (VSG).

This means vPath makes it possible for the 1000V to get traffic that matches a certain policy (IP SRC / DEST) to then perform an action to forward that traffic to a virtual services node (VSN).  Doesn’t this sound familiar?  OpenFlow uses a MATCH/ACTION methodology.  An OF action could be to forward out to a certain port or out a certain overlay.

Getting a big deeper…

vPath intercepts traffic coming from a VM, examines the associated service policy mapped to a VM port profile, and makes a decision.  The traffic will be forwarded according to the MAC table or be re-directed by vPath.  Using VSG as an example and assuming the traffic matches the policy defined, a single packet is re-directed to the VSG for inspection.  Based on the policy rules defined on the VSG, an ACL is downloaded from the VSG to the 1000V Virtual Ethernet Module (VEM).  This means that the first packet is in the “slow path” and all subsequent packets are in the “fast path.”  Doesn’t this sound like an OpenFlow/SDN environment again?

vPath uses an overlay tunnel to transport traffic from each VEM (1000V linecard) to and between virtual service nodes (VSN).  This enables the VSN to be Layer 3 adjacent to the virtual switch.  Using an overlay approach also allows service-chaining of various virtual services.  Using vPath defined policies, traffic is steered in the direction that is required to offer a particular service or chain of services.  Since overlays are used as part of vPath, the physical network requires only L3 forwarding between virtual services.  vPath overlays inter-connect software virtual switches to software virtual service network appliances.  Interesting and cool use of overlays, right?  This can come in handy for dynamic service insertion.

For a company like Cisco who probably wants to continue to sell large amounts of hardware, wouldn’t it make sense to offer vPath on physical Nexus switches (2K/5K/6K/7K) and physical network services (ASA, 3rd party LB)? 

OpenFlow and vPath Recap

OpenFlow is a protocol that is used between a controller and switch to remotely program a forwarding table.  Applications are written on top of a controller using Northbound APIs.  One such application could be a packet filtering application or a light-weight firewall like VSG.  In this model, another interface to the network device is still needed to configure the device, i.e. ovsdb, SNMP, CLI.

vPath is a technology that is used between Nexus virtual switches and virtual services nodes.  Only a single packet (just like OF reactive flow policy) is sent to a VSN making it analogous to a OF/SDN controller.  Slow path/Fast path exist in this model just like with SDN controller deployments.  The Virtual Supervisor Module (VSM) for the 1000V is the means to configure the virtual switch just like CLI, of-config, ovsdb is required to still configure switches in the standard SDN model.

My Take

Cisco has developed what they should be calling SDN technology. I don’t think it would be SDN washing.  Competitors would clearly use it as FUD though because it is Cisco proprietary, but there is nothing wrong with that.  It could always end up as a standard if it catches on.  The same goes for the Cisco Virtual Supervisor module (VSM) in the 1000V solution; while not being called a controller, it will be the device managing VXLAN overlays very soon (common role of a SDN controller).    vPath and VSM are two cases where a vendor needs to re-market or re-brand because unfortunately perception is reality.  Cisco isn’t shipping any data center SDN products today.  BTW, VMware’s equivalent products are definitely part of the Software Defined Data Center.

While my point was to draw some analogies between OpenFlow SDN and Cisco vPath environments, you can see the architectures are different.  In the “open SDN” world, 3rd parties integrate network services on top of an OpenFlow controller.  In the Cisco world, 3rd parties integrate talking directly to virtual switches using vPath overlays. 

Closing Random Thoughts

Which is more scalable and allows for faster integration of 3rd party services/applications?  Both seem to accomplish dynamic service insertion, but could vPath be opened up to do more than just steer traffic to virtual services nodes and take on more control plane functions?  I wonder if another model is to leverage vPath between VEM and VSM and build services/applications on top of the VSM.  Or, yet another option could be to put a virtual appliance onto VXLAN segments (dot1q for VXLAN?? or multiple vnics) and build service-chains by dynamically manipulating VXLAN overlays to get to a particular service.  This could make it possible to use off the shelf virtual appliances without requiring weeks/months of development with 3rd party vendors rather to focus on building standard overlays as needed (as we can tell vPath is already doing this; it’s just changing the slow path by dynamically changing overlay associations to vswitch ports).

And how will Cisco’s ONE controller fit into all of this in the data center?  That’s even a bigger question.  Keep it simple: DC controller is VSM and Campus controller is ONE.