is it possible to use regex within switch block?
Hello! Is it possible to use regular expressions within switch block? My scenario: a.domain.com a.domain.net So different TLDs. Now I want to write iRule that will handle both 'com' and 'net', but I can't figure this out and instead I have to use following syntax: when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { "a.domain.com" { pool some_pool_a } "a.domain.net" { pool some_pool_a } "b.domain.com" { pool some_pool_b } "b.domain.net" { pool some_pool_b } } } I would like to rewrite this iRule to something like this: when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { "a.domain.[com|net]" { pool some_pool_a } "b.domain.[com|net]" { pool some_pool_b } } } but it seems to be not working. Do you guys have any good idea how to fix it? BTW - I'm using v11.6 of BIG IP software.
ADFS 3.0 monitor for ADFS Proxy servers on LTM 11.6 HF3
We are load balancing ADFS 3.0 Proxy servers, but cannot get the monitor to work. The external script provided by F5 is as follows: !/bin/sh These arguments supplied automatically for all external monitors: $1 = IP (nnn.nnn.nnn.nnn notation) $2 = port (decimal, host byte order) This script expects the following Name/Value pairs: HOST = the host name of the SNI-enabled site URI = the URI to request RECV = the expected response Remove IPv6/IPv4 compatibility prefix (LTM passes addresses in IPv6 format) NODE=`echo ${1} | sed 's/::ffff://'` if [[ $NODE =~ ^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$ ]]; then NODE=${NODE} else NODE=[${NODE}] fi PORT=${2} PIDFILE="/var/run/`basename ${0}`.sni_monitor_${HOST}_${PORT}_${NODE}_sni.pid" if [ -f $PIDFILE ] then echo "EAV exceeded runtime needed to kill ${HOST}:${PORT}:${NODE}" | logger -p local0.error kill -9 `cat $PIDFILE` > /dev/null 2>&1 fi curl-apd -k -v --resolve $HOST:$PORT:$NODE https://$HOST$URI 2>&1 > /dev/null | grep -i "${RECV}" STATUS=$? rm -f $PIDFILE if [ $STATUS -eq 0 ] then echo "UP" fi exit I can ssh into the F5 and get a good response when I hard-code the values: config curl-apd -k -v --resolve adfs.abc.edu:443:10.255.200.201 https://adfs.abc.edu/FederationMetadata/2007-06/FederationMetadata.xml 2>&1 > /dev/null | grep -i "HTTP/1.1 200 OK" < HTTP/1.1 200 OK Is there a way on the command line to see what variables are actually being used or maybe a way to log their values? I wonder if it is not correctly pulling the $NODE or $PORT values. As an experiment I also changed [ $STATUS -eq 0 ] to [ $STATUS eq 0 ] just to see if the monitor would come up and that did not help either. Thanks, Rob
Help! ACS, v11.6, variable substitution for multiple user roles in multiple partitions?
v11.6 allows multiple roles per account as long as they are assigned to different partitions. What is the recommended configuration for LTM v11.6 and ACS 5.2 to support variable substitution for complex RBAC assignments? For instance, UserA in AD who is a member of AD groups 'F5 Operator' and 'F5 Certs' can login and have manager access to PartitionA and Certificate Manager access to Common.snmp values changed in 11.6?
i just upgraded some ltms from 11.4 to 11.6 and noticed my snmp throughput numbers are considerably different, i'm wondering what changed? is there a different mib that i should be querying? i double-checked all switch ports and the traffic remains consistent there however the f5s think otherwise. i'm using sysStatClientBytesIn and sysStatClientBytesOut
F5 Synthesis: Hybrid SSL Offload
#SSL #webperf #infosec Now your services can take advantage of hardware acceleration even when they're deployed on virtual machines Way back in the day, when SSL offloading was young and relatively new, there were a variety of hardware, software and even architecture that arose to defeat the security penalty imposed by the requisite cryptographic functionality. Most commonly, we'd slap a PCI-card into a server, muck with the web server configuration (to load some shared objects) and voila! Instant performance boost via hardware acceleration. Later, an architectural approach that leveraged a network-based offload capability was introduced. This meant configuring an SSL offload appliance in a side (or one) arm configuration (common for caches and even load balancers back then) in which SSL traffic was routed to the offload appliance and decrypted before being sent on to the web or app server. You added some latency in the hairpin (or trombone, if you prefer) but that was always more than offset by the improvement of not letting the web server try to decrypt that data in the first place. We've come a long way since then and most often these days you'll find an application delivery controller (ADC) or an app proxy serving duty as cryptographic master of the application. Most ADCs are still far more efficient at handling SSL/TLS traffic because they've benefitted from Moore's Law in two places: the core system and the SSL acceleration hardware (which takes advantage of CPUs, too, in addition to custom hardware). Now comes the advent of the next generation of application delivery architectures which, necessarily, rely on a fabric-based approach and incorporate virtual appliances as well as traditional hardware. Services deployed on the hardware of course benefit from the availability of specialized SSL acceleration but the virtual appliances? Not so much. We (as in the corporate We) didn't like that much at all, especially given trends toward greater key lengths and the forthcoming HTTP 2.0 specification which, yes, requires SSL/TLS. That means a lot more apps are going to need SSL - but they aren't going to want the associated performance penalty that comes with it running on software. They may not be as important, but they aren't expendable. That's true whether the web server natively handles SSL or you move it off to a virtual ADC within the services fabric. All apps are important, of course, but we know that some are more important than others and thus are afforded the benefits of services deployed on faster performing hardware while others are relegated to virtual machines. We take our commitment with Synthesis to leave no application behind seriously and thus have introduced the industry's first hybrid SSL offload capability. Hybrid SSL Offload Hybrid SSL Offload was made available with the release of BIG-IP 11.6 and enables virtual editions of BIG-IP as well as less capable and legacy BIG-IP appliances and devices to harness the power of hardware to improve app performance through cryptographic acceleration. This has the added benefit of freeing up resources on virtual appliances to improve the overall performance and capacity of app services deployed on that virtual edition. In a nutshell, user requests are sent to the appropriate virtual ADC instance, which hosts all app services for an app except SSL. SSL is offloaded to a designated service running on a hardware platform that can take advantage of its targeted hardware acceleration. Using hybrid SSL offload within the Synthesis service fabric allows organizations to: •Achieve the maximum SSL performance of a virtual license •Free up Virtual Edition CPU utilization for other application services All together this means better app performance and capacity for services deployed on virtual editions. All applications need services and deserve optimal performance, even those that might otherwise by designated as "red shirt" apps by IT. F5 Synthesis continues to leave no application behind by ensuring every application has access to the services it needs, even when it means collaborating across device types.F5 Synthesis: Your gateway to the future (of HTTP)
#SDAS #HTTP #webperf #SSL De facto standards can be as difficult to transition off of as official ones If you haven't heard about HTTP 2.0 it's time to start paying attention. It is anticipated that in November the latest version of the specification will become "the standard" for applications. It includes enhancements designed to improve the security and performance of web applications, which have become critical strategic components to just about every organization on the planet. Go ahead, name an organization that doesn't rely on at least one web-based application to conduct business today. Exactly. Performance and security being imperatives along with the presence of applications means that HTTP 2.0 should be a welcome addition to the family of Internet protocols. But it will likely be met with some amount of trepidation by those tasked with supporting it on the data center side of applications because one of the downsides of updating standard protocols after so many years (HTTP 1.1 was ratified in RFC 2616 in 1999) is that they're rarely compatible. That's because in technology years, that 15 years is more like 75 years. Consider for a moment IPv6, which was officially standardized way back in 1995 (RFC1883). Yes, I said 1995. Before the great dot bomb. Before Web 2.0. Before mobile apps. And how's that been going for us? Well, as of May 2014 more than 96% of all Internet traffic was still carried via IPv4. Go ahead, read that again because you're right - a 4% adoption rate over nearly 20 years is somewhat hard to swallow, isn't it? But, you might think, IP affects everything. We're only talking about apps, here. And web apps, at that. Well, let's consider that for a moment. According to our data, 65% of all apps are delivered via HTTP right now. in other words, HTTP is pretty darned important to app delivery and it'd be pretty hard to convince someone to upgrade all the things that need upgrading in order to support HTTP 2.0 (particularly with its requirement for encryption via SSL or TLS). And yet major browsers (and consumer demand for speed, more speed and even MOAR SPEED) are already pushing adoption by broadly supporting SPDY (the protocol upon which HTTP 2.0 is based and which is the primary cause behind compatibility headaches). According to this site, which tracks SPDY adoption across browsers, all major browsers already have at least partial (if not full) support for SPDY. They're ready to go. The app side? Not so much. That's where an app gateway comes into play. App Gateway: Bridging the Old and the New Like IPv6, the answer to the conundrum of transitioning from one protocol to another is a gateway. In the case of HTTP, it's an app gateway because HTTP is an app layer protocol. In the latest release of the ADC platform on which F5 Synthesis High Performance Services Fabric is built we've included both SPDY 1.3 and HTTP 2.0 support, enabling a gateway architectural approach to supporting the latest (soon to be) standard and the existing, more prominent one. This architectural feat is accomplished by way of BIG-IP's full proxy architecture, which lets our ADC speak one version a protocol on the outside (the client) and another on the inside (to the app). But what about all that security stuff you might ask. The requirement for SSL and TLS is as disruptive as the changes to the core protocol, after all. You're right, it is, but again - the nature of being a full proxy means we can support SSL or TSL on the outside and plain old HTTP on the inside, sans encryption. While some organizations require end-to-end encryption of all traffic, those that don't will benefit from the ability to leverage client-side (outside) encryption without doing so on the inside (server-side) where lots of Layer 4-7 services may need visibility into traffic to do their respective jobs. Using a gateway approach also enables a mix of HTTP 2.0 and HTTP 1.x on the inside (server side). That means organizations can take a transitory approach to adoption of the latest app protocol, moving if and when it seems most prudent based on upgrade and refresh cycles, not standards body meeting schedules. The performance and security (and let's not forget business) benefits to moving to HTTP 2.0 with its SSL/TLS requirements and improvements in core transport of data between client and server are worth exploring. But it's understandable that a protocol so entrenched like HTTP 1.x is not easily ripped out and replaced with something new. Taking a gateway approach to adoption enables organizations to support the old while exploring the new and making sure that consumers and employees using the latest and greatest browsers will be able to enjoy improved performance and productivity. Additional Resources: F5 Synthesis Demo of F5 HTTP 2.0 Gateway with Sr. Product Manager Dawn Parzych @ Velocity 2014F5 Synthesis: Hybrid to the Core
#SDAS #SDN #Cloud #SSL #HTTP2.0 F5 continues to pave the way for business to adopt disruptive technologies without, well, as much disruption. The term hybrid is somewhat misleading. In the original sense of the word, it means to bring together two disparate "things" that result in some single new "thing". But technology has adapted the meaning of the word to really mean the bridging of two different technological models. For example, a hybrid cloud isn't really smashing up two cloud environments to form a single, new cloud, rather it's bridging the two technologies in a seamless way so as to make them interoperate and cooperate as if they were a single, unified cloud. This concept is necessary because the way in which data center and computing models evolve. We don't ditch the last generation when the next generation comes along. Rather we graft the new onto the old or combine them in ways that enable the use of both - albeit often times separately. IPv4 and IPv6, for example, pose significant challenges due to incompatibilities. The reliance on the former and the need for the latter drive us to adopt technology such as gateways and brokers to enable a smooth(er) transition from the old to the new. Hybrid is a way to keep organizations moving forward, without sacrificing support for where we are right now. As organizations are challenged to adopt the latest applications and technology based on cutting-edge protocols to improve performance and gain advantages through efficiency, they are simultaneously challenged to scale network infrastructure to handle more traffic, more applications and more "things" connecting to their networks. Cloud offers a path forward, but introduces challenges, too, in managing access, performance, security and scale across an increasingly distributed set of domains. Organizations need hybrid answers to hybrid challenges that threaten the reliability and security of their applications. F5: Hybrid to the Core F5 is no strange to providing hybrid answers to hybrid challenges. F5 Synthesis Software Defined Application Services (SDAS) provide a robust set of services spanning protocol and application layer gateway capabilities that mean you can support a hybrid cloud as easily as a hybrid network that incorporates SDN or emerging protocols like HTTP 2.0. With the release of BIG-IP 11.6 - the platform from which F5 Synthesis High Performance Services Fabric is composed - organizations will be even better positioned to take advantage of new and existing technologies simultaneously while meeting hyperscale challenges arising from even more devices and more applications in need of services. F5 is the first and only vendor to support HTTP 2.0 with BIG-IP 11.6. Like IPv6, HTTP 2.0 is incompatible with the existing de facto standard version (1.1), making it difficult for organizations to move forward and enjoy the proffered benefits of HTTP 2.0 in faster, simpler and more secure applications. F5's approach is hybrid: why be constrained to just one version when you can support both? Too, why must you choose between the performance benefits of hardware-accelerated SSL or the flexibility of a virtual ADC on off-the-shelf hardware? F5 believes you shouldn't have to, and offers another first in the industry - a hybrid SSL offload approach. Organizations can enable 8 times the SSL capacity by taking advantage of the hybrid nature of the F5 High Performance Service Fabric enabled through its unique ScaleN technology. And then, of course, there's cloud and the Internet of Things (or BYOD if you're still focusing just on devices) driving the need for a different kind of access control strategy; a hybrid one. Whether it's things or people, traditional access control techniques that rely on IP address and can't effectively manage both cloud and data center deployed applications isn't going to cut it. Add in the need to hyperscale to meet demand and you need a more hybrid-friendly approach. BIG-IP 11.6 puts the focus on identity-based firewalling into our application delivery firewall services. Combined with existing cloud-identity federation capabilities based on broad SAML support, a seamless hybrid cloud experience for SSO and access is well within reach. As F5 continues to expand and extend the capabilities of its Software-Defined Application Services (SDAS), the notion of "hybrid" architectures, technologies and networks will remain core to its capabilities to ensure organizations can continue to deploy and deliver applications without constraints.
