irule to drop null dns queries
Greetings!!! I was curious if anyone else has had to deal with TONS of null queries to their external dns and if you had any luck dropping those? I am trying to get it to do it via an irule but not having much luck. I have checked out lots of different articles but cant seem to get it quite right. I have tried: when DNS_REQUEST{ if { [DNS::question type] equals "null" } { DNS::drop } } #and this when DNS_REQUEST { if {[DNS::question type] equals "10"} { DNS::drop } } # we also tried using empty rrname when DNS_REQUEST { if { [DNS::rrname] equals "" } { <-- this gave an error DNS::drop } } Any ideas on a way to block these effectively? We are running 14.1, and have a ticket open with support. Will post back if they see where we missed it.
Community: Force Multiplier for Network Programmability
#SDN Programmability on its own is not enough, a strong community is required to drive the future of network capabilities One of the lesser mentioned benefits of an OpenFlow SDN as articulated by ONF is the ability to "customize the network". It promotes rapid service introduction through customization, because network operators can implement the features they want in software they control, rather than having to wait for a vendor to put it in plan in their proprietary products. -- Key Benefits of OpenFlow-Based SDN This ability is not peculiar to SDN or OpenFlow, but rather it's tied to the concept of a programmable, centralized control model architecture. It's an extension of the decoupling of control and data planes as doing so affords an opportunity to insert a programmable layer or framework at a single, strategic point of control in the network. It's ostensibly going to be transparent and non-disruptive to the network because any extension of functionality will be deployed in a single location in the network rather than on every network element in the data center. This is actually a much more powerful benefit than it is often given credit for. The ability to manipulate data in-flight is the foundation for a variety of capabilities – from security to acceleration to load distribution, being able to direct flows in real-time has become for many organizations a critical capability in enabling the dynamism required to implement modern solutions including cloud computing . This is very true at layers 4-7, where ADN provides the extensibility of functionality for application-layer flows, and it will be true at layers 2-3 where SDN will ostensibly provide the same for network-layer flows. One of the keys to success in real-time flow manipulation, a.k.a network programmability, will be a robust community supporting the controller. Community is vital to such efforts because it provides organizations with broader access to experts across various domains as well as of the controller's programmatic environment. Community experts will be vital to assisting in optimization, troubleshooting, and even development of the customized solutions for a given controller. THE PATH to PRODUCTIZATION What ONF does not go on to say about this particular benefit is that eventually customizations end up incorporated into the controller as native functionality. That's important, because no matter how you measure it, software-defined flow manipulation will never achieve the same level of performance as the same manipulations implemented in hardware. And while many organizations can accept a few milliseconds of latency, others cannot or will not. Also true is that some customized functionality eventually becomes so broadly adopted that it requires a more turn-key solution; one that does not require the installation of additional code to enable. This was the case, for example, with session persistence – the capability of an ADC (application delivery controller) to ensure session affinity with a specific server. Such a capability is considered core to load balancing services and is required for a variety of applications, including VDI. Originally, this capability was provided via real-time flow manipulation. It was code that extended the functionality of the ADC that had to be implemented individually by every organization that needed it – which was most of them. The code providing this functionality was shared and refined over and over by the community and eventually became so demanded that it was rolled into the ADC as a native capability. This improved performance, of course, but it also offered a turn-key "checkbox" configuration for something that had previously required code to be downloaded and "installed" on the controller. The same path will need to be available for SDN as has been afforded for ADN, to mitigate complexity of deployment as well as address potential performance implications coming from the implementation of network-functionality in software. That path will be a powerful one, if it is leveraged correctly. While organizations always maintain the ability to extend network services through programmability, if community support exists to assist in refinement and optimization and, ultimately, a path to productization the agility of network services increases ten or hundred fold over the traditional vendor-driven model. There are four requirements to enable such a model to be successful for both customer and vendors alike: Community that encourages sharing and refinement of "applications" Repository of "applications" that is integrated with the controller and enables simple deployment of "applications". Such a repository may require oversight to certify or verify applications as being non-malicious or error-free. A means by which applications can be rated by consumers. This is the feedback mechanism through which the market indicates to vendors which features and functionality are in high-demand and would be valuable implemented as native capabilities. A basic level of configuration management control that enables roll-back of "applications" on the controller. This affords protection against introduction of applications with errors or that interact poorly when deployed in a given environment. The programmability of the network, like programmability of the application delivery network, is a powerful capability for customers and vendors alike. Supporting a robust, active community of administrators and operators who develop, share, and refine "control-plane applications" that manipulate flows in real-time to provide additional value and functionality when it's needed is critical to the success of such a model. Building and supporting such a community should be a top priority, and integrating it into the product development cycle should be right behind it. HTML5 WebSockets Illustrates Need for Programmability in the Network Midokura – The SDN with a Hive Mind Reactive, Proactive, Predictive: SDN Models SDN is Network Control. ADN is Application Control. F5 Friday: Programmability and Infrastructure as Code Integration Topologies and SDNHTML5 WebSockets Illustrates Need for Programmability in the Network
#HTML5 #SDN The increasing use of HTML5 WebSockets illustrates one of the lesser mentioned value propositions of SDN – and ADN: extensibility. It's likely that IT network and security staff would agree that HTML5 WebSockets has the potential for high levels of disruptions (and arguments) across the data center. Developers want to leverage the ability to define their own protocols while reaping the benefits of the HTTP-as-application-transport paradigm. Doing so, however, introduces security risks and network challenges as never-before-seen protocols start streaming through firewalls, load balancers, caches and other network-hosted intermediaries that IT network and security pros are likely to balk at. Usually because they're the last to know, and by the time they do – it's already too late to raise objections. Aside from the obvious "you folks need to talk more" (because that's always been the answer and as of yet has failed to actually occur) there are other answers. Perhaps not turn-key, perhaps not easy, but there are other answers. One of them points to a rarely discussed benefit of SDN that has long been true for ADN but is often overlooked: extensibility through programmability. In addition, leveraging the SDN controller’s centralized intelligence, IT can alter network behavior in real-time and deploy new applications and network services in a matter of hours or days, rather than the weeks or months needed today. By centralizing network state in the control layer, SDN gives network managers the flexibility to configure, manage, secure, and optimize network resources via dynamic, automated SDN programs. Moreover, they can write these programs themselves and not wait for features to be embedded in vendors’ proprietary and closed software environments in the middle of the network. -- ONF, Software-Defined Networking: The New Norm for Networks The ability to alter behavior of any network component in real-time, to make what has been traditionally static dynamic enough to adapt to changing conditions is the goal of many modern technology innovations including SDN (the network) and cloud computing (applications and services). When developers and vendors can create and deploy new protocols and toss them over the wall into a production environment, operations needs the ability to adapt the network and delivery infrastructure to ensure the continued enforcement of security policies as well as provide support to assure availability and performance expectations are met. Doing so requires extensibility in the network. Ultimately that means programmability. EXTENSIBILITY through PROGRAMMABILITY While most of the networking world is focused on OpenFlow and VXLAN and NVGRE and virtual network gateways, the value of the ability to extend SDN through applications seems to be grossly underestimated. The premise of SDN is that the controller's functionality can be extended through specific applications that provide for handling of new protocols, provide new methods of managing flows, and do other nifty things that likely only network geeks would truly appreciate. The ability to extend packet processing and add new functions or support for new protocols rapidly, through software, is a significant part of the value proposition of SDN. Likewise, it illustrates the value of the same capabilities that currently exist in ADN solutions. ADN, too, enables extensibility through programmability. While varying degrees of control and capabilities exist across the ADN spectrum, at least some provide complete programmatic control over traffic management by offering the ability to "plug-in" applications (of a sort) that provide support for application-specific handling or new (and often proprietary) protocols, like those used to exchange data over WebSockets-transported connections. What both afford is the ability to extend the functionality of the network (SDN) or application traffic management (ADN) without requiring upgrades or new products. This has been a significant source of value for organizations with respect to security, who often turn to the ADN solutions topologically positioned in a strategic point of control within the network to address zero-day or emerging exploits for which there are no quick fixes. When it comes to something like dealing with custom (proprietary) application protocols and the use of WebSockets, for which network infrastructure services naturally has no support, the extensibility of SDN and ADN are a boon to network and security staff looking for ways in which to secure and address operational risk associated with new and heretofore unknown protocols. The Need for (HTML5) Speed SPDY versus HTML5 WebSockets Oops! HTML5 Does It Again Reactive, Proactive, Predictive: SDN Models The Next IT Killer Is… Not SDN SDN is Network Control. ADN is Application Control.The Game of Musical (ADC) Chairs
Now things are starting to get interesting… Nearly everyone has played musical chairs – as a child if not as an adult with a child. When that music stops there's a desperate scrambling to pair up with a chair lest you end up sitting on the sidelines watching the game while others continue to play until finally, one stands alone. The ADC market has recently been a lot like a game of musical chairs, with players scrambling every few months for a chair upon which they can plant themselves and stay in the game. While many of the players in adjacent markets –storage, WAN optimization, switching – have been scrambling for chairs for months, it is only today, when the big kids have joined the game, that folks are really starting to pay attention. While a deepening Cisco-Citrix partnership is certainly worthy of such attention, what's likely to be missed in the distraction caused by such an announcement is that the ADC has become such a critical component in data center and cloud architectures that it would leave would-be and has-been players scrambling for an ADC chair so they can stay in the game. ADCs have become critical to architectures because of the strategic position they maintain: they are the point through which all incoming application and service traffic flows. They are the pivotal platform upon which identity and access management, security, and cloud integration heavily rely. And with application and device growth continuing unabated as well as a growing trend toward offering not only applications but APIs, the incoming flows that must be secured, managed, directed, and optimized are only going to increase in the future. F5 has been firmly attached to a chair for the past 16 years, providing market leading application and context-aware infrastructure that improves the delivery and security of applications, services, and APIs, irrespective of location or device. That has made the past three months particularly exciting for us (and that is the corporate "us") as the market has continued to be shaken up by a variety of events. The lawsuit between A10 and Brocade was particularly noteworthy, putting a damper on A10's ability to not only continue its evolution but to compete in the market. Cisco's "we're out, we're not, well, maybe we are" message regarding its ACE product line shook things up again, and was both surprising and yet not surprising. After all, for those of us who've been keeping score, ACE was the third attempt from Cisco at grabbing an ADC chair. Its track record in the ADC game hasn't been all that inspiring. Unlike Brocade and Riverbed, players in peripherally related games who've recognized the critical nature of an ADC and jumped into the market through acquisition (Brocade with Foundry, Riverbed with Zeus), Cisco is now trying a new tactic to stay in a game it recognizes as critical: a deeper more integrated relationship with Citrix. It would be foolish to assume that either party is a big winner in forging such a relationship. Citrix is struggling simply to maintain Netscaler. Revised market share figures for CYQ1 show a player struggling to prop Netscaler up and doing so primarily through VDI and XenApp opportunities, opportunities that are becoming more and more difficult to execute on for Citrix. This is particularly true for customers moving to dual-vendor strategies in their virtualization infrastructure. Strategies that require an ADC capable of providing feature parity across virtual environments in addition to the speeds and feeds required to support a heterogeneous environment. Strategies that include solutions capable of addressing operational complexity; that enable cloud and software defined data centers with a strong, integrated and programmable platform. While Microsoft applications and Apache continue to be the applications BIG-IP is most often tasked with delivering, virtualization is growing rapidly and Citrix XenApp on BIG-IP is no exception. In fact we've seen an almost 200% growth of Citrix XenApp on BIG-IP from Q2 to Q3 (FY12), owing to BIG-IP's strength and experience in not just delivery optimization and the ability to solve core architectural challenges associated with VDI, but also compelling security and performance capabilities coupled with integration with orchestration and automation platforms driving provisioning and management of virtualization across desktop and server infrastructure. Citrix's announcement makes much of a lot of integration that is forthcoming, of ecosystems and ongoing development. Yet Cisco has made such announcements in the past, and it leaves one curious as to why it would put so many resources toward integrating Citrix when it could have done so at any time with its own solution. Integration via partnerships is a much more difficult and lengthy task to undertake than that of integration with one's own products, for which one has complete control over source code and entry points. If you think about it, Cisco is asking the market to believe that it will be successful with a partner where it has been unsuccessful with its own products. What we have is a vendor struggling to sell its ADC solution asking for help from a vendor who is struggling to sell its own ADC solution. It's a great vision, don't get me wrong; one that sounds as magically delicious as AON. But it's a vision that relies on integration and development efforts, which requires resources; resources that if Cisco has them could have been put toward ACE and integration, but either do not exist or do not align with Cisco priorities. It's a vision that puts Citrix's CloudStack at the center of a combined cloud strategy that conflicts with other efforts, such as the recent release of Cisco's own version of OpenStack which, of course, is heavily supported by competing virtualization partner, VMware. In the game of musical ADC chairs, only one player has remained consistently instep with the beat of the market drum: and that player is F5. Cisco ACE Trade-In Program Latest F5 Information F5 News Articles F5 Press Releases F5 Events F5 Web Media F5 Technology Alliance Partners F5 YouTube FeedSDN is Network Control. ADN is Application Control.
#SDN is disruptive but it's not destructive, especially not at layer 4-7 In the wake of VMware's acquisition of SDN notable Nicira there was a whole lot of behind-the-scenes scrambling to understand the impact to the entire networking demesne – especially given speculation that after SDN focuses on L2/3 network virtualization it will move to encompass L4/7 services including ADCs and network security. That sounds more than disruptive, it sounds downright destructive. But the reality is that SDN is not designed for layers 4-7 and its focus on layer 2-3 – and specifically its packet-processing focus – has long been shown to be inadequate for managing application traffic at layer 4 and above. SDN is about moving packets seamlessly and dynamically. It solves issues that have long been problematic for very large networks and service providers but in the wake of virtualization and cloud computing have begun to emerge as a challenge for unlarge networks and, in particular, cloud providers. These challenges revolve around limitations in Ethernet routing and switching standards as well as managing the high volumes of change inherent in cloud computing environments. To resolve this, SDN proposes a centrally controlled, programmable network model that overlays traditional physical networks. This overlay addresses limitations (such as those imposed by the VLAN standard) and the problem of physical wiring required to properly route traffic across networks in the face of failures and route changes. SDN solves this by decoupling the control and data planes, leveraging programmable switching infrastructure and creating an overlay network without the limitations that hold back traditional networks. But at the end of the day, SDN is about routing and switching and forwarding of packets. ADN, on the other hand, is concerned with the routing and switching of applications and the forwarding of sessions. Its model is a mirror of that of SDN, but at the application layers (4-7 of the OSI model). ADN is not – and cannot be – primarily concerned with the forwarding of individual packets, as the application data upon which ADN works is an aggregation of multiple packets, i.e. application data which has been fragmented necessarily over multiple L3 packets by limitations imposed on it by Ethernet standards. Simply establishing a TCP connection, for example, requires the exchange of no less than 3 packets of data: SYN, SYN-ACK, and ACK. An ADC will not even begin to make a routing decision until all three packets have been exchanged and a session is established. This is the mechanism through which application security and routing are achieved – on a per session, per application request basis. ADCs, therefore, are at least half (and the best are full) proxies. Packets are not forwarded until a decision has been made, and thus are required to maintain large stores of session data in their systems. SDN does not provide at this time for such functionality (though it certainly could in the future). Furthermore, SDN would need to solve a significant processing issue around the variability in making decisions at layer 4 and above. Simply load balancing based on source IP or other primitive methods would be possible for SDN and unlikely to overtax the system too much, but such basic functionality is decades old and been proven ineffective for adequately scaling applications while maintaining acceptable performance. Improving beyond such rudimentary capabilities would be difficult for SDN, because it requires processing of each and every request. SDN is able to perform (right now) because only the first time a pattern is seen is the controller required to inform the switching fabric how to route matching packets. Each time thereafter the switching fabric uses its local FIB (Forwarding Information Base) and merrily forwards the packet. When attempting to add security to the mix, each and every request must be evaluated – often at a rate of thousands of requests per second. SDN is simply not designed to handle the application layer processing needs of layer 4-7 and is unlikely able to scale to the levels needed to detect and prevent a large scale application-layer DDoS let alone a massive and sudden rise in layer 7 requests (such as a web application) because the number of DPS (Decisions per Second) that can be made by the controller is limiting in an SDN model. The Intersection of SDN and ADN ADN and SDN are not competing technologies. ADN and SDN are highly complementary and serve to solve to same problems, they each merely do so at different layers of the networking stack. As Mike Fratto recently pointed out, SDN will augment networking, not replace it: In a perfect world--one invented 15 minutes ago--software-defined networking startups could build virtual network products that aren't encumbered by 30 years of tinkering with Ethernet. Ethernet has served us well, but as IT moves toward the software-defined data center , the network "is the barrier to cloud computing," according to Nicira (which was recently acquired by VMware). But, of course, the technology from Nicira will augment, not replace, traditional networking. -- VMware's SDN Strategy Is No Threat to Cisco, Juniper or Anyone Else Mike was focusing on traditional networking (layer 2 and 3) but the reality is that his words apply equally to layer 4-7. VMware's strategy is sound, but it is not a threat to its partners or others in the layer 4-7 space. SDN is disruptive to the space, but it's not destructive. SDN will force change as it is adopted, no doubt there. There will need to be adaption by layer 4-7 ADN vendors to adopt and support SDN programmability in its switching fabrics, as a means to integrate with a broader SDN initiative. ADN and SDN intersect where core layer 2 and 3 routing and switching functionality is required as a means to forward data to the proper systems after the ADC has determined the target. ADN will necessarily need to support SDN in its underlying switch fabrics, most likely by tying into the SDN management plane through API exchange, interpretation, and action, while maintaining its existing capabilities at layer 4-7 as a means to address volatility throughout the upper realms of network stack. As noted in other posts, ADN is architecturally SDN at layer 4-7, decoupling the data and control planes and enabling programmability through open APIs and scripting languages. The ADC provides the basis for expanding functionality of processing through plug-ins, much in the same way the SDN controller is designed to allow "applications" to extend processing functionality on a per-packet basis. This intersection provides a model framework for future network architecture in which SDN is used to manage intra-networks in which a high volume of change or large scale number of nodes is present that requires the flexibility and dynamism inherent in SDN. ADN will still provide the core perimeter application traffic routing it has – including security – but its interface to the applications and systems for which it manages traffic will be an SDN-enabled interface, controlled by a packet delivery controller (or by whatever name the vendor in question decides to give it). Referenced blogs & articles: F5 Friday: Performance, Throughput and DPS VMware's SDN Strategy Is No Threat to Cisco, Juniper or Anyone Else We iz in ur networkz, deep inspecting ur XML packetz. Wait, what? F5 Friday: ADN = SDN at Layer 4-7 Integration Topologies and SDN Applying ‘Centralized Control, Decentralized Execution’ to Network Architecture SDN, OpenFlow, and Infrastructure 2.0 F5 Friday: Programmability and Infrastructure as CodeF5 Friday: Programmability and Infrastructure as Code
#SDN #ADN #cloud #devops What does that mean, anyway? SDN and devops share some common themes. Both focus heavily on the notion of programmability in network devices as a means to achieve specific goals. For SDN it’s flexibility and rapid adaptation to changes in the network. For devops, it’s more a focus on the ability to treat “infrastructure as code” as a way to integrate into automated deployment processes. Each of these notions is just different enough to mean that systems supporting one don’t automatically support the other. An API focused on management or configuration doesn’t necessarily provide the flexibility of execution exhorted by SDN proponents as a significant benefit to organizations. And vice-versa. INFRASTRUCTURE as CODE Devops is a verb, it’s something you do. Optimizing application deployment lifecycle processes is a primary focus, and to do that many would say you must treat “infrastructure as code.” Doing so enables integration and automation of deployment processes (including configuration and integration) that enables operations to scale along with the environment and demand. The result is automated best practices, the codification of policy and process that assures repeatable, consistent and successful application deployments. F5 supports the notion (and has since 2003 or so) of infrastructure as code in two ways: iControl iControl, the open, standards-based API for the entire BIG-IP platform, remains the primary integration point for partners and customers alike. Whether it’s inclusion in Opscode Chef recipes, or pre-packaged solutions with systems from HP, Microsoft, or VMware, iControl offers the ability to manage the control plane of BIG-IP from just about anywhere. iControl is service-enabled and has been accessed and integrated through more programmatic languages than you can shake a stick at. Python, PERL, Java, PHP, C#, PowerShell… if it can access web-based services, it can communicate with BIG-IP via iControl. iApp A latter addition to the BIG-IP platform, iApp is best practice application delivery service deployment codified. iApps are service- and application-oriented, enabling operations and consumers of IT as a Service to more easily deploy requisite application delivery services without requiring intimate knowledge of the hundreds of individual network attributes that must be configured. iApp is also used in conjunction with iControl to better automate and integrate application delivery services into an IT as a Service environment. Using iApp to codify performance and availability policies based on application and business requirements, consumers – through pre-integrated solutions – can simply choose an appropriate application delivery “profile” along with their application to ensure not only deployment but production success. Infrastructure as code is an increasingly important view to take of the provisioning and deployment processes for network and application delivery services as they enable more consistent, accurate policy configuration and deployment. Consider research from Dimension Data that found “total number of configuration violations per device has increased from 29 to 43 year over year -- and that the number of security-related configuration errors (such as AAA Authentication, Route Maps and ACLS, Radius and TACACS+) also increased. AAA Authentication errors in particular jumped from 9.3 per device to 13.6, making it the most frequently occurring policy violation.” The ability to automate a known “good” configuration and policy when deploying application and network services can decrease the risk of these violations and ensure a more consistent, stable (and ultimately secure) network environment. PROGRAMMABILITY Less with “infrastructure as a code” (devops) and more-so with SDN comes the notion of programmability. On the one hand, this notion squares well with the “infrastructure as code” concept, as it requires infrastructure to be enabled in such as a way as to provide the means to modify behavior at run time, most often through support for a common standard (OpenFlow is the darling standard du jour for SDN).For SDN, this tends to focus on the forwarding information base (FIB) but broader applicability has been noted at times, and no doubt will continue to gain traction. The ability to “tinker” with emerging and experimental protocols, for example, is one application of programmability of the network. Rather than wait for vendor support, it is proposed that organizations can deploy and test support for emerging protocols through OpenFlow enabled networks. While this capability is likely not really something large production networks would undertake, still, the notion that emerging protocols could be supported on-demand, rather than on a vendor' driven timeline, is often desirable. Consider support for SIP, before UCS became nearly ubiquitous in enterprise networks. SIP is a message-based protocol, requiring deep content inspection (DCI) capabilities to extract AVP codes as a means to determine routing to specific services. Long before SIP was natively supported by BIG-IP, it was supported via iRules, F5’s event-driven network-side scripting language. iRules enabled customers requiring support for SIP (for load balancing and high-availability architectures) to program the network by intercepting, inspecting, and ultimately routing based on the AVP codes in SIP payloads. Over time, this functionality was productized and became a natively supported protocol on the BIG-IP platform. Similarly, iRules enables a wide variety of dynamism in application routing and control by providing a robust environment in which to programmatically determine which flows should be directed where, and how. Leveraging programmability in conjunction with DCI affords organizations the flexibility to do – or do not – as they so desire, without requiring them to wait for hot fixes, new releases, or new products. SDN and ADN – BIRDS of a FEATHER The very same trends driving SDN at layer 2-3 are the same that have been driving ADN (application delivery networking) for nearly a decade. Five trends in network are driving the transition to software defined networking and programmability. They are: • User, device and application mobility; • Cloud computing and service; • Consumerization of IT; • Changing traffic patterns within data centers; • And agile service delivery. The trends stretch across multiple markets, including enterprise, service provider, cloud provider, massively scalable data centers -- like those found at Google, Facebook, Amazon, etc. -- and academia/research. And they require dynamic network adaptability and flexibility and scale, with reduced cost, complexity and increasing vendor independence, proponents say. -- Five needs driving SDNs Each of these trends applies equally to the higher layers of the networking stack, and are addressed by a fully programmable ADN platform like BIG-IP. Mobile mediation, cloud access brokers, cloud bursting and balancing, context-aware access policies, granular traffic control and steering, and a service-enabled approach to application delivery are all part and parcel of an ADN. From devops to SDN to mobility to cloud, the programmability and service-oriented nature of the BIG-IP platform enables them all. The Half-Proxy Cloud Access Broker Devops is a Verb SDN, OpenFlow, and Infrastructure 2.0 Devops is Not All About Automation Applying ‘Centralized Control, Decentralized Execution’ to Network Architecture Identity Gone Wild! Cloud Edition Mobile versus Mobile: An Identity CrisisF5 Friday: ADN = SDN at Layer 4-7
The benefits of #SDN have long been realized from #ADN architectures There are, according to ONF, three core characteristics of SDN: “In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications. As a result, enterprises and carriers gain unprecedented programmability, automation, and network control, enabling them to build highly scalable, flexible networks that readily adapt to changing business needs.” -- Software-Defined Networking: The New Norm for Networks, ONF Let’s enumerate them so we’re all on the same page: 1. Control and data planes are decoupled 2. Intelligence and state are logically centralized 3. Underlying network infrastructure abstracted from applications Interestingly enough, these characteristics – and benefits - have existed for quite some time at layers 4-7 in something known as an application delivery network. ADN versus SDN First let’s recognize that the separation of the control and data planes is not a new concept. It’s been prevalent in application architecture for decades. It’s a core premise of SOA where implementation and interface are decoupled and abstracted, and it’s even in application delivery networking – has been for nearly a decade now. When F5 redesigned the internal architecture of BIG-IP back in the day, the core premise was separation of the control plane from the data plane as a means to achieve a more programmable, flexible, and extensible solution. The data plane and control plane are completely separate, and it’s part of the reason F5 is able to “plug-in” modules and extend functionality of the core platform. Now, one of the benefits of this architecture is programmability – the ability to redefine how flows, if you will, are handled as they traverse the system. iRules acts in a manner similar to the goals of OpenFlow, in that it allows the implementation of new functionality down to the packet level. You can, if you desire, implement new protocols using iRules. In many cases, this is how F5 engineers develop support for emerging protocols and technologies in between major releases. BIG-IP support for SIP, for example, was initially handled entirely by iRules. Eventually, demand and need resulted in that functionality being moved into the core control plane. Which is part of the value proposition of SDN + OpenFlow – the ability to “tinker” and “test” experimental and new protocols before productizing them. So the separation of control from data is not new, though BIG-IP certainly doesn’t topologically separate the two as is the case in SDN architectures. One could argue physical separation exists internal to the hardware, but that would be splitting hairs. Suffice to say that the separation of the two exists on BIG-IP platforms, but it is not the physical (topological) separation described by SDN descriptions. Intelligence and control is logically centralized in the application delivery (wait for it… wait for it… ) controller. Agility is realized through the ability to dynamically adjust flows and policy on-demand. Adjustments in application routing are made based on policy defined in the control plane, and as an added bonus, context is shared across components focusing on specific application delivery domain policy. Offering “unprecedented programmability, automation, and network control” that enables organizations “to build highly scalable, flexible [application] networks that readily adapt to changing business needs” is exactly what an application delivery network-based architecture does – at least for that sub-section of the network dedicated to delivering applications. WOULD ADN BENEFIT FROM SDN? There is not much SDN can provide to improve ADN. As mentioned before, there may be advantages to implementing SDN topologically downstream from an ADN, to manage the volatility and scale needed in the application infrastructure, and that might require support for protocols like OpenFlow to participate at layer 2-3, but at layer 4-7 there is really no significant play for SDN that has an advantage over existing ADN thus far. SDN focuses on core routing and switching, and while that’s certainly important for an ADN, which has to know where to forward flows to the appropriate resource after application layer routing decisions have been made, it’s not a core application delivery concern. The argument could (and can and probably will) be made that SDN is not designed to perform the real-time updates required to implement layer 4-7 routing capabilities. SDN is designed to address network routing and forwarding, automatically, but such changes in the network topology are (or hopefully are, at least) minimal. Certainly such a change is massive in scale at the time it happens, but it does not happen for every request as is the case at layer 4-7. load balancing necessarily makes routing decisions for every session (flow) and in some cases, every request. That means thousands upon thousands of application routing decisions per second. In SDN terms, this would require similar scale of updating forwarding tables, a capability SDN has been judged unable at this time to accomplish. Making this more difficult, forwarding of application layer requests is accomplished on a per-session basis, not unilaterally across all sessions, whereas forwarding information in switches is generally more widely applicable to the entire network. In order for per-session or per-request routing to be scalable, it must be done dynamically, in real-time. Certainly SDN could manage the underlying network for the ADN, but above layer 3 SDN will not suffice to support the scale and performance required to ensure fast and available applications. When examining the reasons for implementing SDN, it becomes apparent that most of the challenges addressed by the concept have been addressed at layer 4-7 by a combination of ADN and integration with virtualization management platforms. The benefits afforded at layer 2-3 by SDN are duplicated at layer 4-7 with a unified ADN already. In practice, if not definition, ADN is SDN at layer 4-7. OpenFlow/SDN Is Not A Silver Bullet For Network Scalability F5 Friday: Performance, Throughput and DPS Cyclomatic Complexity of OpenFlow-Based SDN May Drive Market Innovation QoS without Context: Good for the Network, Not So Good for the End user The Full-Proxy Data Center Architecture SDN, OpenFlow, and Infrastructure 2.0 Searching for an SDN Definition: What Is Software-Defined Networking? OpenFlow/Software-Defined Networking (SDN) A change is blowing in from the North (-bound API)
Once Again, it Really IS About the Applications.
(Booming voiceover voice); Are you running the same tired old network tools? Does your network staff have to administer security and load balancing for each and every application? Do you find application analysts and owners show a growing frustration with the network team’s response times due to overloading? Well get in there and fix that network! Get the tools that you need to make your network more application friendly, reduce fatigue amongst your network staff, and give application owners more control of their applications! That was, of course, a joke poking fun at both the way we run our networks and the advertisement that tries to sell by listing common problems in a booming voice. But as is almost always the case, there’s a grain of serious in that joke. Many organizations have their infrastructure configured such that the networking staff must intercede with a lot of functionality that is in the application domain. Be it more capacity, granular security, or routing to a new instance of the application, the network staff carries these burdens, while the application staff waits for them to do so and in many cases, the application owner gets frustrated. But the days when ADC functionality – be it security, adding servers, or shipping connections to a remote instance of the application – had to rest completely in the realm of networking staff are behind us. If you still have those problems, you need to look into a state-of-the-art ADC (yes, like F5 sells, but we do have competition if you prefer). Assuming the application people can spin up new instances, they can also get them included in the ADC’s available servers. Since most application folks can spin up a new instance, this extra step means less waiting around for another team. When security issues crop up relative to a particular application, you’ll have the application owner, systems administrators, security… Do you really need to throw the network folks in there too? You used to have to, but technology has relieved that burden. When application owners (or sysadmins) can administer the security policy for a given application, then they just need the advice of the security team (assuming you’re a big enough org to have a security team). This not only makes the organization more nimble, it reduces errors by having those directly responsible for the application implementing policy for the application without a middle-man. Need to do cloud-bursting? The networking team needs to set that all up for you, but once it’s configured and the application can take advantage of it, then when/where/how is up to the application staff, not the networking team. Again, more agile. Just in terms of reducing burden on the networking staff, and thus making them more productive on the other important things they need to do, the move to a newer ADC is worth it. But throw in the concept that the application staff is also empowered to act without waiting to consult with yet another busy team, and the improved IT response time makes the overall organization more adaptable. If you choose an ADC that also resolves other pressing issues your organization has, you can really drive home solutions, while laying the groundwork for future architectural developments. Pick an ADC that enhances VMotion over long distances, for example, and moving apps from DC-to-DC becomes simple and reliable. So if your load balancing solution is just that – load balancing – it is time to look into where the market has gone. If you use a command line for most of your ADC configuration and management, it is again time to check where the market has gone. Enable applications staff to free up time for networking staff. And take advantage of a whole new set of capabilities while you’re at it. Explore what’s out there that might just make your life easier and your company more productive. And if you have an older solution, check out scalability too. Things have come a long way in a few short years, that’s for sure. That’s not to say that you shouldn’t have a command line – F5’s tmsh is a complete command line version of the UI – but not everyone wants to type 50 lines of script when one webpage will do, and to push functionality out beyond the network team, web interfaces are definitely needed, both to increase accessibility and to reduce errors.
