Taking security to a next level with Big Cloud Fabric
As attacks on corporate networks and data breaches have become more common, organizations are forced to rethink their IT security strategies. More than ever, it is understood that it is not if an attack will occur but when. As a result, modern infrastructure must be resilient and able to withstand any external or internal attacks. A secure network freed from the constraints of legacy networking plays a critical role in achieving this goal. Infrastructure meltdowns or data breaches are not always caused by intentional malicious acts but are quite often a result of administrator mistakes. Solutions that are complex and error prone increase the chances of such mistakes and slow down application rollouts. Many IT administrators mistakenly believe that IT agility and security are in opposition and that one must be sacrificed to improve the other. However, Big Cloud Fabric (BCF) is an industry-first data center fabric solution that demonstrates how both can be achieved simultaneously in a cost-effective way for physical and virtual workloads. Big Cloud Fabric brings network agility and other benefits of virtualization to data centers through a controller-based SDN architecture, open networking hardware. Security is paramount in the BCF architecture and in every use case. BCF provides a secure and resilient Software Defined Networking (SDN) solution through innovations in Management, Control Plane and Data Plane. Let’s take a look at how this is done.
There is more than just the table stakes features like authentication based on username and password. Given that REST API is a cornerstone of BCF, we provide one nice addition. DevOps folks are now able to authenticate by simply using a token instead of typing user-password combination or storing it in a file. How is that for simplicity?
- Access Control
No more writing complex ACL entries for each switch to figure out how to prevent specific clients or protocols from accessing your switch. A simple access control infrastructure in BCF allows you to clearly limit allowed methods of access such as GUI or REST API and specific client IPs. Remember that with SDN, you are doing all of this on a controller for the entire fabric, not on every switch. Switches themselves are locked and you cant not change fabric configuration or operational state there, even if you really wanted to.
Role-Based Access Control infrastructure does not just extend to CLI, GUI and REST API access. It applies to orchestrators such as OpenStack as well. Those who are using BCF plug-in for VMware vCenter have additional ways to control access to the fabric. See this blog for more information on BCF solution with VMware.
- Switch Onboarding & Secure Communication
When it comes to SDNs, many administrators have a concern about access to the fabric by rogue switches and communication with controller being compromised. In BCF, if switch is not admitted to the fabric based on its MAC address, it will not communicate with a controller and will not send any data traffic. Communication between switches and controllers happens on a dedicated VLAN and the controller appliance has a dedicated physical interface for this, separate from the one used for management plane. Remember that much like a supervisor in a modular switch, controller does not sit in the data path. These are all great features but they are often not enough. One of the newest additions to BCF, Control Plane Security (CPSec) uses certificates to enable encrypted communication between all fabric components:
- Physical switch running Switch Light OS communication with the BCF controller
- Virtual switch running Switch Light VX communication with the BCF controller
- Communication between active and standby controllers
All of this makes BCF control plane ready for deployment in world's most demanding data centers.
- Rate Limiting
In order to make sure that excess control plane traffic does not overwhelm switch CPU, traditional data center networks require configuring and tuning complex control plane policies on each switch. As you can imagine, this does not scale for data center demands in 2016. Not to mention that with modular switches, we often see protection for supervisor CPU, but not the I/O module CPU. Following our "one big switch" analogy, BCF provides a sophisticated yet simple rate limiting infrastructure that protects not only the switch CPU (I/O module CPU in modular chassis) but also controller CPU (supervisor CPU in modular chassis). No tuning is required as the limits are carefully scoped for each release to support shipping scalability numbers. One may ask though - why does the switch CPU needs to be protected if controller is the brain and is doing all the operations? Sure the controller is the brain, but its wise for us to have controller do more complex tasks like figuring out forwarding path between endpoints and let switches do more trivial tasks like sending LACP or LLDP packets at pre-defined interval. We offload a lot of such operations to switches to achieve higher resiliency and scale. LACP, LLDP, ARP, ICMP and CDP are all offloaded. Scalability and control plane traffic rate limiting without the aggravation.
Big Cloud Fabric allows to segment the network using application-centric constructs such as segments for Layer 2 separation and tenants for Layer 3 separation. No more worrying about what VLAN is trunked where. VLANs are now locally significant to a port and when using a tool such as OpenStack or VMware vCenter to automate the network, they are only provisioned where they are needed. Those of us who are still trunking all 4K VLANs on every single switch port now have a real alternative. To add to that, BCF vPOD technology does not just use above-mentioned constructs to segment workloads but keeps configuration synchronized on a per-orchestrator basis. See this blog for more information about vPODs.
Big Cloud Fabric supports Storm Control. What’s the big deal as this feature has been available for years? That is true, however SDN adds a huge additional value to this. We give ability to configure not just storm control values per interface but to implement a complete storm control profile for different traffic types (broadcast, unknown unicast, known and unknown multicast). This profile can be applied to a particular switch interface or to the entire switch. Most importantly it can be applied to new switch when it is onboarded, therefore keeping the entire fabric resilient. For the first time, a data center admin can rest easy knowing that the fabric is protected from endpoints that decided to have a broadcast blast party one day!
email@example.com for any comments and questions, and join us on this journey as we continue to innovate and disrupt the status quo of networking.
Principal Technical Marketing Engineer, Big Switch Networks
To Learn More: Secure and Resilient SDN with Big Cloud Fabric: Whitepaper