SFP Port LEDs Blinking Yellow
Hi I upgraded the F5 OS to version 1.8 and the tenant software to 17.5.1.3. The upgrade went smoothly and both the Active and Standby devices successfully handled traffic after the upgrade. However I have noticed that the SFP port LEDs on both the Primary and Secondary devices are blinking yellow. Both devices appear to be operating normally but I would like to confirm whether this is expected behavior Could the yellow blinking indicate a speed mismatch or should the LEDs be green under normal conditionsF5 i-series Guests to r-series tenants migration
Hi All, I have two i-series 11900 with 4 guests on each as: 1 LTM, 1 GTM, 1 WAF, and 1 APM. There is HA between the guests. I am working on a migration plan to r-series 10900 and have two options: Option 1: HA method: Here, I will replace the i-series device that has the standby guests with the r-series device. Then will establish the HA between the active i-series and the r-series and sync the configuration. Then will make the r-series active as active. Then will replace the newly bocming standby i-series device with the second r-series and establish the HA with the first r-series. this is a lengthy way but has a positive side of fast rollback in case I faced any issue, and there will be no changes on the management IPs. Option 2: UCS method: in this method I will create a replica of the existing guests on the r-series tenants using the UCS files from the iseries guests. This setup will be isolated from the production network. During the maintenance window, I will disconnect the cables from i-sereis and connect it to the r-series boxes. This way I need to use different management IPs while building the replica setup. and during the migration will change the management IPs and use the onse were on the i-series. Note that, existing devices are connected to cisco ACI. Let me here your thoughts and suggestions.
Building new F5 replica
I have an F5 in the production environment, and now I have to build another F5 for the Disaster Recovery (DR) environment having the exact same configuration (different mgmt IP and default gateway relevant to DR ). The production F5 is running with multiple VIPs and the same needs to be replicated to DR F5, Can anyone guide how to proceed in building the new DR F5, what files need to be copied, and the certificates to be used in the DR environment. Any help would be highly appreciated.F5 CNF/BNK issue with DNS Express tmm scaling and zone notifications
I did see an interesting issue with DNS Express with Next for Kubernetes when playing in a test environment. When you have 2 TMM pods in the same namespace as the DNS zone mirroring is done by zxfrd pod and I you need to create a listener "F5BigDnsApp" as shown in https://clouddocs.f5.com/cnfs/robin/latest/cnf-dnsexpress.html#create-a-dns-zone-to-answer-dns-queries for the optional notify that will feed this to the TMM and then to the zxfrd pod. The issue happens when you have 2 or more TMM as then the "F5BigDnsApp" that is like virtual server/listener as then then on the internal vlans there is arp conflict as the two tmm on two different kubernetes/openshift nodes advertise the same ip address on layer 2. This is seen with "kubectl logs" ("oc logs" for Openshift) on the TMM pods that mention the duplicate arp detected. Interesting that the same does not happen when you do this for the normal listener on the external Vlan (the one that captures and responds to the client DNS queries) as I think by default the ARP is stopped for the external listener that can be on 2 or more TMM as ECMP BGP is used to redistribute the traffic to the TMM by design. I see 4 possible solutions as I see it. One is to be able to control the ARP for the "F5BigDnsApp" CRD for Internal or External Vlans (BGP ECMP to be used also on the server side then) and the second is to be able to select "F5BigDnsApp" to be deployed just one 1 TMM even if there are more. Also if an ip address could be configured for the listener that is not part of the internal ip address range but then as I see with "kubectl logs" on the ingress controller (f5ing-tmm-pod-manager) the config is not pushed to the TMM as also with "configview" from the debug sidecar container on the tmm pods there is no listener at all. The manager logs suggest that because the Listener IP address is not part of the Self-IP IP range under the intnernal Vlan as this maybe system limitation and no one thinking about this use case as in BIG-IP this is is supported to have VIP on non self ip address range that is not advertised with arp because of this. The last solution that can work at the moment is to have many tmm in different namespaces on different kubernetes nodes with affinity rules that can deploy each tmm on different node even if the tmm are on different namespaces by matching a configured label (see the example below) as maybe this is the current working design to have one zxfrd pod with one tmm pod in a namespace but then the auto-scaling may not work as euto scale should create a new tmm pod in the same namespace if needed. Example: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: tmm # Match Pods in any namespaces that have this label namespaceSelector: {} # empty selector = all namespaces topologyKey: "kubernetes.io/hostname" Also it should be considered if the zxfrd pod can push the DNS zone to the RAM of more than one TMM pods as maybe it can't as maybe currently only one to one is supported. Maybe it was never tested what happens when you have Security Context IP address on the Internal Network and multiple TMM pods. Interest stuff that I just wanted to share as this was just testing things out😄Need F5 iRules Consultant - HTTP Header Manipulation Issues
Looking for help with F5 BIG-IP iRules development for custom HTTP header processing. We're trying to modify incoming request headers based on client IP geolocation, but the iRule is causing connection timeouts on certain requests. The logic works for most traffic but specific user agents seem to trigger infinite loops in the header rewrite code. Need someone experienced with iRules scripting and HTTP event handling to debug the conditional logic. Seeking 2-3 hours remote troubleshooting to identify and fix the timeout issues. Must be resolved by Thursday for production deployment.
SSL Orchestrator and Layer 2 Service Integration
Has anyone encountered issues with rSeries Big IP Tenant with the integration of a layer 2 service? In my case, I cannot make the service to come up even though I have the exact VLAN name and tagging set in the OS bare metal, and exactly the same VLAN and tagging configured in the tenant.
4600 rSeries tenant resizing and HA Dependency
Consider there is an HA between 2 tenant. rSeries Chassis 1 - Tenant1 - F5 VM ( Active F5 ) rSeries Chassis 2 -Tenant1 - F5 VM ( Standby F5 ) If Chassis 2 - Tenant 1 is resized for resource perspective ( cpu ) , and put the state into Deployed state , in F5 VM level , will it be automatically be part of HA or both tenant need to have same Hardware resource allocated ?
What is the recommended TCP Profile settings monitor settings for ISO 8583 traffic in F5 Big IP ?
Pls share the recommended TCP Profile settings monitor settings for ISO8583 traffic in F5 Big IP Because we are facing pool members flapping only when load comes through F5, but stable when bypassing it And suggest me is there any configuration tuning on the backend Uniserv servers to stop this flapping Important note is Testers don't find any issues when the load initiated directly to the backend servers bypassing the F5 . Testers facing issues when the load test happening through F5 and we are seeing the backend pool members started flapping. We tried increasing the interval and timeout values but still issues happening after the specified timeout value .Is it advisable to use dedicated health check port, not the same production ISO port ( flapping appears due to aggressive TCP health probes competing with production traffic port ) Any help is really appreciated.
