There are many conversations to be had about network virtualization in general, and SDN in particular. One conversation we don’t always hear about is the human factor – which is to say resistance from telecoms department heads who see SDN as a challenge to their livelihoods, either through consolidating networking departments or automating resources to the point of making employees redundant.
Data center networking continues to evolve, with increasing choices for open and disaggregated network solutions, while other vendors aim for more closed, proprietary systems. Enterprises should evaluate different vendor approaches and architectures, with a particular focus on software capabilities.
The landscape of the modern data center is rapidly evolving. The migration from physical to virtualized workloads, move towards software-defined data centers, advent of a multi-cloud landscape, proliferation of mobile devices accessing the corporate data center, and adoption of new architectural and deployment models such as microservices and containers has assured the only constant in modern data center evolution is the quest for higher levels of agility and service efficiency.
Last week we attended the Check Point CPX2016 conference in Chicago. We talked to a lot of interesting people including network administrators, security team members & CISOs, each one with his or her own story and pain points. We’ve had fascinating conversations, about floating data centers, securing law firm applications and the usual woes of developers on security teams (and the other way around).
One of the typical questions when considering NSX deployments is who should be the administrator? However this is typically a two horse race, between Network and Virtualization Systems Administrators. Although NSX is SDN (software defined networking) the driver behind much of what it does is due security requirements, using vlans to segregate layer two networks, firewalls and vpns are examples of security driven network features.
Comments by Cisco CEO Chuck Robbins last week that the networking giant is open to collaborations with VMware in virtual networking raise the question: Just how would Cisco’s ACI and VMware’s NSX platforms could work together?
Last week I posted a tweet saying “Friends don’t let friends delete the NSX-v VTEP PortGroup” and as most of us do in our industry we learn by doing and I found out the hard way that you shouldn’t mess with the PortGroup created during the Host Preparation of the NSX setup and configuration stage. This PortGroup is used by the Hosts in an NSX Enabled Cluster for the VMKernel Interfaces that are the VTEPs or VXLAN Tunnel End Points.
As one of the network and security leads for the VMware TAM program in North America, I was contacted by a colleague whose customer wanted to discuss NSX permissions and rights in detail. The questions from this customer inspired this post.
As part of study for VCIX-NV I’ve given myself task of exploring in my new home lab all parts of NSX which I don’t use at work. One of these things is NSX Activity Monitoring, to investigate this I came up with a test scenario and then worked through the steps to achieve a solution to meet the scenario design.