Dashboard and logs show different bandwidth utilization?
I can't figure this one out, so I figure I'd ask the experts! I've found multiple times that the performance view or the dashboard on the F5 don't correlate to local traffic logs about bandwidth. I've seen this multiple times, but here is an example from yesterday with my 200Mbps LTM. The dashboard showed this (grabbed historic from performance statistics). At the same time, I was getting flooded with messages like this from my system local traffic log. Tue Jun 27 08:05:06 PDT 2017 notice PERF-F5 tmm[11064] 01010045 Bandwidth utilization is 244 Mbps, exceeded 75% of Licensed 200 Mbps I've looked at it multiple times and it just doesn't add up. I've had this issue in multiple environments. Can someone explain to me where I can actually see the bandwidth I'm using if it's not being represented in the dashboard? Thanks!AAM Dynamic Policy Updates And Removal of SPDY in BIG-IP v13
February 22nd marked the downloadable release of F5 BIG-IP v13. With any major release, our user community wants to know what changes and features will present themselves post upgrade. For BIG-IP Application Acceleration Manager (AAM) users, there are two changes users can expect. Under-the-hood, users will enjoy improved performance in Bandwidth Controller updates for Dynamic Policies. For those who deployed SPDY services, keep reading. Dynamic Policy Updates Maybe you implemented dynamic bandwidth policies and maaaayyybeeee you saw policies not always metering "fairly" causing throttling prior to peak utilization. We saw it too. The algorithms behind the fairness policies within Bandwidth Controller and their surrounding policy management are updated to properly maximize your available bandwidth. BIG-IP v13 modifies existing static and common token bucket algorithms. For you this means: Better tracking of slow flows Better utilize assigned max rates in all conditions Better control of max rate and token distributions across TMM instances and blades These updates require no user intervention to implement. If you have existing policies already in use, you should see performance improvements immediately. There are two mechanisms for assigning policy-based flow rates in AAM, Policy Enforcement Manager and Access Policy Manager (and iRules if you're splitting hairs) but actual changes for these improvements reside within Bandwidth Controller. Say Goodby to SPDY Google announced removal of SPDY support in favor of HTTP/2 Februrary 2015. SPDY (and NPN) support were removed from Chrome in February 2016. All other major browsers followed suit or are planning to drop support shortly. F5 introduced HTTP/2 support in 11.6 and with version 13 we complete SPDY's removal as a functioning service. SPDY service profiles in v12 SPDY profiles create is removed in v13 SPDY profiles create is removed in v13 If for some reason you had a SPDY-only virtual server/application, kudo's for being that one person and let's start making plans to migrate your SPDY gateway/services to HTTP/2 before your upgrade. SPDY functionality exists in LTM and AAM and GUI removal applies to both. We don't want you to be surprised. SPDY removal and Bandwidth Controller fairness algorithm updates are the two changes you'll see affect AAM (and other modules) in BIG-IP v13. One requires no intervention and will provide performance increases, the other is a deprecated web standard who should already have both feet out your infrastructure door. Let us know your experiences with BIG-IP v13 keep on IT'ing
Self Ip's displaying in AV 1x1 call when callee ip address is expected.
Using Big IP to load balance IBM Sametime works well except when I plug in Bandwidth Manager into the AV solution. Using self ips as part of our F5 solution means that to route a call I need to add the self ip addresses into my Bandwidth configuration so the calls will route. With this config in place when trying a 1X1 call, the call policy from one ip to another isn't being applied.The callee's ip address being displayed is always the F5's self ip address. How can I get the actual ip address of the callee to display correctly?Only one active ctg on an instance allowed
I'm trying to set a DSCP value for an HTTP response based on the MIME type returned from the application services. Things are being tag correctly, but occasionally, I get the following message in the LTM log. Does anyone know how to decipher this to tell me the underlying issue? What is a "ctg"? Category? and what is the "instance" referring to? TCL error: /Common/SND-BWC-Rule - Only one active ctg on an instance allowed.: unable to set bwc app policy 'Media-Category' (line 1) invoked from within "BWC::color set AODefault-BWC Media-Category" iRule when CLIENT_ACCEPTED { log local0. "attached Media-BWC [IP::remote_addr]:[TCP::remote_port]" BWC::policy attach AODefault-BWC [IP::remote_addr]:[TCP::remote_port] } when HTTP_RESPONSE_RELEASE { if { [HTTP::header Content-Type] equals "image/jpeg" } { log local0. "colored Media-BWC Media-Category" BWC::color set AODefault-BWC Media-Category } } Should I just wrap the BWC::color in a TCL exception check to log and ignore this error? Is there a better way to handle or check if a category has already been assigned?
