In the first blog in this series, we looked at several issues that still prevail in the enterprise wide-area network (WAN) despite advances in hardware and software technologies and products.
Those issues include branch/remote appliance bloat, complex security and compliance conformance, application performance, WAN configuration management, and operational and management complexities, which raise CapEx and OpEx.
This week we want to take a look at six critical architectural considerations of a software-defined network (SDN)-centric WAN.
Organizations need to understand and evaluate these six architectural considerations to help ensure a successful SDN network design.
- Connectivity: WAN connectivity issues are common, the result of packet loss, high latency, slow or broken Internet connections and other factors, and compounded by data residing in public and private clouds. When considering an SDN-centric WAN for enterprises needing high availability, look at its ability to support direct Internet access for remote/branch sites. This helps to avoid long-haul transit to and from the data center. It should also have the ability to support multiple WAN topologies, such as Multiprotocol Label Switching (MPLS) WAN, and Internet backhaul to data centers.
- Scalability: Forwarding functions in SDN are managed in a software-based, centralized control layer, where automated decision-making results in high scalability. Consider these functions when supporting controller configurations in one or more data centers and deciding how to optimize architecture that accesses internal data centers or public/private clouds. Also explore the capacity of the controller for simultaneous support of physical and virtual/logical devices, and how many sites the controller is capable of supporting before performance and efficiency degrade.
- Efficiency: Making the WAN more “efficient” involves a multitude of parameters. You must know which of your L2/L3 protocols are supported by your controller and Network Functions Virtualization (NFV) solutions. Do any pre-defined or customizable application templates require bandwidth allocation? Also, consider what feature sets are likely to be supported out of the box and then over time to ensure that purpose-built appliances such as firewalls, load balancers and WAN optimizers are capable of being instantiated as virtual functions (VFs). Finally, explore the potential to simplify routing if the current routing between customer edge and provider edge (CE-PE) changes, given the overlay model with centralized control and distributed forwarding intelligence.
- Network economics: When designing your network, it’s important to identify areas where you’ll achieve operational savings on an initial, as well as ongoing basis. Also consider how the organization uses chargebacks: On what basis does your organization currently usethem? Will you use an application-based cost model, a workload and/or consumption-based cost model, or a support and/or maintenance cost model?
- Reliability: To gauge the overall resiliency of a particular WAN architecture, consider how reliability is achieved. For example, is it through dependencies on a remote site device or on a hosted/corporate data center head-end device? Also consider how to leverage the fact that many SDN-WAN deployments are overlay configurations in order to increase service-level agreement (SLA) compliance. Is there a way to use statistics gleaned in this network to measure business-application stats and user-consumption trends?
- Security: In the current data center environment, firewalls have been designed and deployed to look at traffic patterns that run in a traditional north/south pattern instead of the emerging east/west pattern. The traditional firewall architecture focus on perimeter security, instead of internal data center traffic, so they are less effective at discovering and stopping attacks and malware from penetrating the data center and network.
Virtualization makes it even more difficult to provide security using traditional firewalls. Virtual firewalls, which are distributed throughout the data center and network at selected enforcement points, are better at preventing attacks than traditional firewall systems.Before implementing SDN, review the classic security considerations — AAA implementation, multi-tenant environment functionality, encryption options in the control and forwarding planes — and how they work with SDN. Then review where traditional firewall technology can be improved upon in your network.
Consider how your network detects security threats such as spoofing, session hijacking, electronic eavesdropping/packet sniffing and man-in-the-middle attacks. Does your traditional security have detection and mitigation capabilities for DoS/DDoS-type attacks internally and in the cloud? Is it capable of providing secure logical separation for internal corporate, cloud/Internet and business partner traffic? Does it automatically identify application-level capabilities beyond the port/protocol level for policy management and compliance? Does it have a remote enforcement capability that eliminates the need for remote site/branch firewalls?
These points are just some of the architecture considerations to examine when implementing an SDN-centric network.
Next issue, we’ll discuss how the orchestration function works in the SDN architecture, and how you can utilize it as the focal point of changing and activating network services in your infrastructure.
Take the next step toward implementing SDN in your organization. Download our new e-book, Seriously Disruptive Networking: 8 Ways SDN Is Shaking Up The Industry.
