SSL Orchestrator and SWG combined
Hi, I wonder if it is at all possible to setup both SWG and SSL Orchestrator as combined solution using one BIG-IP (or two BIG-IP) setup? Idea is to be able to use SWG features for user authentication, URL filtering etc. and SSL Orchestrator for Service chaining to provide added security for users accessing Internet. From what I tested deploying SSL Orchestrator (module on BIG-IP VE, not Herculon appliance) in Explicit proxy SSL Orchestrator is deployed as kind of iApp (but not visible via iApps -> Application Service) with Strict Updates enabled - so no way to modify VS created by wizard. Additionally it seems that there is no way to disable Strict Updates for SSL Orchestrator so impossible to add APM policies to VS set as Explicit proxy. So not possible to combine those functionalities? Or maybe kind of proxy chaining from SWG Explicit proxy to SSL Orchestrator Explicit proxy VS? Or iRule on SWG Explicit Proxy VS with VIP targeting VIP? I am curious (if combining is possible) what are real life best practices and experiences how this setup works. Piotr
SSL Orchestrator and SWG combined
Hi, I wonder if it is at all possible to setup both SWG and SSL Orchestrator as combined solution using one BIG-IP (or two BIG-IP) setup? Idea is to be able to use SWG features for user authentication, URL filtering etc. and SSL Orchestrator for Service chaining to provide added security for users accessing Internet. From what I tested deploying SSL Orchestrator (module on BIG-IP VE, not Herculon appliance) in Explicit proxy SSL Orchestrator is deployed as kind of iApp (but not visible via iApps -> Application Service) with Strict Updates enabled - so no way to modify VS created by wizard. Additionally it seems that there is no way to disable Strict Updates for SSL Orchestrator so impossible to add APM policies to VS set as Explicit proxy. So not possible to combine those functionalities? Or maybe kind of proxy chaining from SWG Explicit proxy to SSL Orchestrator Explicit proxy VS? Or iRule on SWG Explicit Proxy VS with VIP targeting VIP? I am curious (if combining is possible) what are real life best practices and experiences how this setup works. Piotr
F5 Synthesis for Service Providers: Scaling in Three Dimensions
#MWC14 #SDAS #NFV #SDN It's not just about changing the economy of service scale, it's about operations, too. Estimates based on reports from Google put the number of daily activations of new Android phones at 1.3 Million. Based on reported data from Apple, there are 641 new applications per day added to the App Store. According to Cisco's Visual Networking Index, mobile video now accounts for more than 50% of mobile data traffic. Put them all together and consider the impact on the data, application and control planes of a network. Of a mobile network. Now consider how a service provider might scale to meet the demands imposed on their networks by continued growth, but make sure to factor in the need to maintain a low cost per subscriber and the ability to create new revenue streams through service creation. Scaling service provider networks in all three dimensions is no trivial effort, but adding on the requirement to maintain or lower the cost-per-subscriber and enable new service creation? Sounds impossible - but it's not. That's exactly what F5 Synthesis for Service Providers is designed to do: enable mobile network operators to optimize, secure and monetize their networks. F5 Synthesis for Service Providers F5 Synthesis for Service Providers is an architectural framework enabling mobile network operators to optimize, secure and monetize their networks. F5 Synthesis achieves this by changing the service economy of scale by taking advantage of a common, shared platform to reduce operational overhead and improve service provisioning velocity while addressing key security concerns across the network. F5 Synthesis for Service Providers enables mobile network operators to scale in three dimensions: control, data and application planes. Control Plane The control plane is the heart of a service provider network. Tasked with the responsibility for managing subscriber use and ensuring the appropriate services are applied to traffic, it can easily become overwhelmed by signaling storms that occur due to spikes in activations or an Internet-wide gaming addiction that causes millions of concurrent players to join in. The control plane is driven by Diameter, and F5 Synthesis for Service Providers includes F5's Traffix Signaling Delivery Controller, nominated this year for Best Mobile Infrastructure at Mobile World Congress. With unparalleled performance, flexibility and programmability, F5 Traffix SDC helps mobile network operators scale the control plane while enabling the creation of new control plane services. Less often considered but no less important in the control plane are DNS services. A scalable, highly resilient and secure DNS service is critical to both the performance and security of service provider networks. F5 Synthesis for Service Providers includes DNS services. F5 Synthesis is capable of scaling to 418 million response queries per second (RQPS) and includes comprehensive protection against DNS-targeting DDoS attacks. Data Plane The service provider data plane serves as the backbone between the mobile network and the Internet, and must be able to support millions of consumer requests for applications. Banking, browsing, shopping, watching video and sharing via social media are among the most popular activities, many of which are nearly continuous for some subscribers. Bandwidth hungry applications like video can become problematic for the data plane and cause degradations in performance that hamper the subscriber experience and send them off looking for a new provider. To combat performance, security and reliability challenges, service providers have invested in a variety of targeted solutions that has led to a complex, hyper-heterogeneous infrastructure comprising the Gi network. This complexity increases the cost per subscriber by introducing operational overhead and can degrade performance by adding latency due to the number of disparate devices through which data must traverse. F5 Synthesis for Service Providers includes a high-performance service fabric comprised of any combination of hardware or virtual appliances capable of supporting over 20 Tbps. Hardware and appliances from F5 are enabled with its unique vCMP technology, which allows the creation of right-sized service instances that can be scaled up and down dynamically and ultimately reduce the cost per subscriber of the services delivered. The F5 Synthesis High Performance Service Fabric is built on a common, shared and highly optimized platform on which key service provider functions can be consolidated. By consolidating services in the Gi network on a single, unified platform like F5 Synthesis service fabric, providers can eliminate the operational overhead incurred by the need to manage multiple point products, each with its own unique management paradigm. Consolidation also means services deployed on F5 Synthesis High Performance Service Fabric gain the performance and scale advantages of a network stack highly optimized for mobile networking. Application Plane Value added services are a key differentiator and key revenue opportunity for service providers, but can also be the source of poor performance due to the requirement to route all data traffic through all services, regardless of their applicability. Sending text through a video optimization service, or video through an ad insertion service does not add value, but it does consume resources and time that impact the overall subscriber experience. F5 Synthesis services include policy enforcement management capable of selectively routing data through only the value added services that make sense for a given subscriber and application combination. Using Dynamic Service Chaining, F5 Synthesis optimizes service chains to ensure more efficient resource utilization and improved performance for subscribers. This in turn allows service providers to selectively scale highly utilized value added services that saves time and money and reduces costs to deliver. F5 Synthesis for Service Providers works in concert with virtual machine provisioning systems to enable service providers to move toward NFV-based architectures. Intelligent monitoring of value added services combined with awareness of load and demand enables F5 Synthesis for Service Providers to ensure VAS can be scaled up and down individually, resulting in significant cost savings across the VAS infrastructure. by eliminating VAS silos and the need to scale the entire VAS infrastructure at the same time. F5 Synthesis for Service Providers also offers the most flexible set of programmability features in the industry. Control plane, data plane, management plane. APIs for integration, scripting languages for service creation, iApps and a cloud-ready, multi-tenant services fabric that can be combined with a self-servicing service management platform (BIG-IQ). This level of programmability changes the operational economy of scale through automation and orchestration opportunities. With F5 Synthesis for Service Providers, mobile network operators can simplify their Gi Network while laying the foundation for rapid service creation and deployment on a highly flexible, manageable virtualized service fabric that helps providers execute on NFV initiatives.Roaming around at Mobile World Congress
#MWC14 #F5 #mobile #sdas Consumers, like fate, are the fickle mistresses of the service provider world. When the multitude of applications they increasingly use on their mobile devices perform poorly, they often blame the network provider irrespective of the real cause. Mobile network operators are stuck between a rock (the consumer) and a hard place (the application provider) trying to satisfy both. F5 recognizes how difficult it can be to not just identify the source of poorly performing applications, but do something about it while simultaneously securing and making reliable those same applications and the networks over which they are delivered. F5 Synthesis addresses core challenges with mobile application delivery with an architectural framework designed to enable mobile network operators to rapidly provision and manage the services they need to optimize, secure and monetize their networks. Our newly announced F5 Synthesis 1.5 includes a number of mobile-focused capabilities and enhancements including new mobile TCP optimizations, support for MPTCP, response steering and Dynamic Service Chaining. Additionally, we announced a modern version of our control plane API - iControl REST - that simplifies integration with cloud management platforms and orchestration systems. Whether enabling a transitory approach to deploying NFV-enabled networks or simply taking advantage of programmability in the data, control and management planes to create new and differentiated services, F5 Synthesis offers mobile network operators a modern, high performance and manageable solution for satisfying consumer's insatiable demand for fast applications while ensuring the security of their networks. If you're roaming around at Mobile World Congress, you'll want to visit F5 at Booth 5G11 (Hall 5) and learn how to capitalize on the changing mobile landscape, transition to an application-driven service delivery model, or learn more about F5 Traffix SDC, nominated this year for Best Mobile Infrastructure at the show. We'll also have a variety of essential demos at the booth you won't want to miss: Essential Demo: Video optimization on @Skyfire platform at F5's booth 5G11 (Hall 5) Essential Demo: BIG-IP PEM virtual orchestration at F5's booth 5G11 (Hall 5) Essential Demo: Global Mobile Best Mobile Infrastructure Nominee F5 Traffix SDC at booth 5G11 (Hall 5) Essential Demo: TCP Optimization at F5's booth 5G11 (Hall 5) If you're not attending the show, you can follow the activities and observations on Twitter #MWC14 or follow along with F5.Why SDN (or something like it) was Inevitable: Service Velocity
#Agile #Devops #SDN All three core IT groups must align with similar approaches to succeed - and we aren't done yet. Once upon a time, there was a movement in IT called "agile". Developers adopted it in response to complaints from the business that they needed applications, that applications were everything, that without new applications the business would surely dry up. Dev then began tossing code over the wall faster and more frequently. At some point, the operations folks responsible for herding these applications and application updates through the road to production decided that if they were going to keep up with development, they needed a new approach. Enter devops. Operations version of agile as applied to deployment processes. Where app dev focuses on continuous development, operations tries to match their velocity with continuous deployment. You can see where this is going, right? Exactly. The next (hopefully last but perhaps only penultimate) obstacle is the network. It is not yet agile, nor has it fully embraced the notion it needs to be. But it does, because network service velocity is currently a growing issue for organizations, because it is vastly slower than app dev and operations rate of execution. Thus, SDN (or something like it) was inevitable. Interestingly enough, InformationWeek's most recent SDN survey showed overwhelmingly that improving service velocity - "a more efficient and flexible network that speeds service delivery" - is used to justify investments in SDN by 76% of respondents. That may because app dev and devops are already running at full tilt but the network? Not so much. Something had to change, and given that service velocity is significantly impeded today by the network, it just makes sense that it was going to have to change to accommodate the rest of the IT organization. How SDN Addresses Service Velocity. Or Doesn't As the Case May Be. If you consider the five key characteristics defined by the ONF as being core to SDN you'll find that all of them directly or indirectly (by enabling other technologies) address this need for service velocity. ONF Characteristic Address Need for Service Velocity by Directly programmable Enabling automation Agile Improving responsiveness of netops Centrally managed Reduces complexity of the network, which can impede provisioning of services Open standards-based and vendor-neutral Can reduce complexity by ensuring consistency of interfaces used for automation and provisioning Programmatically configured Assists in automation SOURCE: Open Networking Foundation Unfortunately, the classical SDN architecture as defined by ONF (and used by most people as the common definition) is very focused on service velocity of layer 2-3 forwarding functions and some layer 4 services, but not very good at improving service velocity rates for higher order services. Service Chaining on the Horizon The reality that SDN's network focus (L2-3) does not adequately address the challenges posed by application layer services (L7) meant some other approach was necessary to complete the full "network" implied by the "N" in SDN. That some other approach appears to be service chaining. Use Case Purpose Benefit Service Insertion (or Service Chaining) To create dynamic chains of L4-7 services on a per tenant basis to accommodate self-service L4-7 service selection or policy-based L4-7 (e.g. turning on DDoS protection in response to attacks, self-service firewall, IPS services in hosting environments, DPI in mobile WAN environments) Provisioning times reduced from weeks to minutes, improved agility and self-service allows for new revenue and service opportunities with substantially lower costs to service From SDNCentral "SDN Use Cases" There are already a variety of approaches bubbling to the surface with respect to how best to implement service chaining in conjunction with (and sometimes separately from) SDN architectures. In general, however, the concept is fairly simple. Applications have a need for application services that operate at L4-7. A reactive SDN architecture is not well-suited to dealing with the requirements to operate said services. Service chaining assumes that all L2-3 traffic routing and switching is managed by the SDN controller, and when an application has need of these services, the SDN controller will ensure that traffic is forwarded to the appropriate service(s), chaining them (in a manner similar to orchestration) if there are more than one that need to be invoked. Some proposals suggest using a new protocol that "tags" (yes, much like VXLAN and NVGRE tag packets for routing purposes) packets and flows in order to enforce execution order, others suggest using policy, others still simply hard coding the order of invocation. Regardless of the implementation details, the concept of service chaining remains fairly close no matter who is proposing the solution. Rather than coding the "next hop" in each application service, it's software defined so that it can be programmatically and dynamically, if necessary, modified to fit the application. The good news is that Service Chaining in theory appears to address service velocity needs for application services. Which means in conjunction with an SDN implementation, service chaining provides a full network stack that is software-defined and improves service velocity to match that of the network group's app dev and devops counterparts. Which is what we need to happen to prevent dev and ops from viewing the provisioning of application services in the network in the same light as booking a cruise with Odysseus. .
