Link Controller - bigip_link from big3d time out
I'm with this problem can someone help me? "May 9 11:41:03 f5 alert gtmd [6921]: 011a2003: 1: SNMP_TRAP: Link / Common / embratel (ip = 201.73.190.81) state change blue -> red (Monitor / Common / bigip_link from : no reply from big3d: timed out) " All my self-ip station as "non-float" and "Default port lockdown" And why can not monitor the links for Controller Link
Local Traffic Adaptive Monitoring
Hi All, Anyone ever try to used adaptive monitoring on F5? As mention on LTM monitor reference document: "A monitor with adaptive response time enabled marks a service as up or down based on the deviation of latency of the monitor probe from the mean latency of a monitor probe for that service. In typical cases, if the monitor detects three consecutive probes that miss the latency value you set, the system marks the pool member or node as down." In my case, I'm going to use this adaptive monitor for monitoring ISP link on F5 Link Controller, run using BIGIP OS 13.1.0.2. I make a monitor object like this: Type: gateway_icmp Interval time: 5 sec Timeout time: 16 sec Transparent: Yes Alias address: 8.8.8.8 Alias port: all ports Adaptive: Enabled Allowed Divergence: Absolute, 5 msec Adaptive Limit: 5 msec Sampling timespan: 60 sec If I do ping test from CLI to 8.8.8.8, then I get the average latency time is 13 msec: [root@CDT:Active:Standalone] config ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=13.2 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=13.0 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=61 time=13.4 ms I was intentionally set the allowed divergence and time limit to a low number, which is 5 msec, to see how this monitor will marked down the pool member, which in this case is an ISP link. But I never get this pool member to be marked down by this monitor object. Anything wrong on my configuration? Do I need additional configuration to make it work? Thanks anyway..Persisting SNAT Addresses in Link Controller Deployments
My friend Bruce Hampton recently reached out with a problem he was facing with a BIG-IP Link Controller (LC) deployment. We had a nice exchange of ideas for several days before he carried this over the finish line with a working solution for his environment. The problem? How do you persist the client address AND the snat address?Source persistence is an easy profile add-on. But the snat address? Not so simple. Consider the scenario as shown in the drawing. This represents Anywhere University, with tens of thousands of students, thousands of faculty and staff, and more university compute and bring your own device(s) than is practical to count. Because of the high client load flowing through the LC, snat automap is not an option due to the high risk of port exhaustion. A snat pool works well here, and snatpools are smart enough to assign an address from the correct subnet even when addresses from multiple subnets are lumped together in a single snatpool, as is the case here. The tricky part for this solution is persisting the snat address for the client source address that is persisted. The order of operation is thus: Check for persistence ( source IP persistence is set) If there is no persistence record, make a load balancing decision Once the next hop is determined (i.e. the ISP gateway has been selected,) select a snat address appropriate for that ISP Bind the client persistence to the snat persistence So what’s to be done about this? It’s time for an iRule of course! Checking persistence isn’t challenging, nor is setting it up. But in the case of establishing a snat and persisting it, the next hop has to be established. So the critical events to make this work are CLIENT_ACCEPTED and LB_SELECTED. Remember this is an LC deployment, so we’re really not interested in the traffic at all, just how to direct it. So we really only care about addressing. A single snatpool is used (and although you could possibly make this work without a snatpool at all, it’s nice to let BIG-IP manage all the arp and traffic group stuff for you and just use the minimal logic in the iRule) with three addresses from each ISP subnet to allow for the ports necessary to avoid port exhaustion. Source persistence is enabled. ## RemoteAdmin Inc v 1.0 4/21/17 ## This irule sets up 2 static arrays for load balancing SNAT pools ## and will persist the client to the correct SNAT address, eliminating ## the bouncing around on the SNAT address ## The logging statements are for troubleshooting purposes only. ## To add additional SNAT addresses, simply add them to the arrays below when CLIENT_ACCEPTED { # set up 2 arrays, one for each ISP's addresses set snat_isp1(0) 172.16.1.1 set snat_isp1(1) 172.16.1.2 set snat_isp1(2) 172.16.1.3 set snat_isp2(0) 192.168.1.1 set snat_isp2(1) 192.168.1.2 set snat_isp2(2) 192.168.1.3 ##RA##set client_remote "[IP::client_addr]:[TCP::client_port]" # calculate which snat to use; will need to add a snat_(n) if expanding snatpool # check first octet # First let's see if there is already a persistence record in place # Uncomment the below line to see what ##RA##log local0. "First octect is [getfield [ persist lookup source_addr [IP::client_addr] node] "." 1]" if {[getfield [ persist lookup source_addr [IP::client_addr] node] "." 1] eq "172" }{ snat $snat_isp1([expr {[crc32 [IP::client_addr]] % [array size snat_isp1]}]) } elseif {[getfield [ persist lookup source_addr [IP::client_addr] node] "." 1] eq "192" }{ snat $snat_isp2([expr {[crc32 [IP::client_addr]] % [array size snat_isp2]}]) } } # LB_SELECTED only fires if there is no persistence record when LB_SELECTED { # check first octet if { [getfield [LB::server addr] "." 1] eq "172" } { ##RA##log local0. [getfield [LB::server addr] "." 1] snat $snat_isp1([expr {[crc32 [IP::client_addr]] % [array size snat_isp1]}]) } elseif { [getfield [LB::server addr] "." 1] eq "192" } { ##RA##log local0. [getfield [LB::server addr] "." 1] snat $snat_isp2([expr {[crc32 [IP::client_addr]] % [array size snat_isp2]}]) } } It might look a little overwhelming, but it’s really not that complicated. In CLIENT_ACCEPTED, the arrays are established for the snat addresses (this part could be moved to RULE_INIT, but when expanding/contracting you might experience some oddness during failovers.) The real magic is in setting the snat addresses themselves. In CLIENT_ACCEPTED and in LB_SELECTED, either via a persist lookup or LB::server lookup, the snat is assigned based on a calculation of the client IP address, which will always be the same result. So…magic! Client IP address bound to the snat address! You could optimize performance by manually keeping track of the array size to eliminate those operations, but the tradeoff is management. There is a version of this same approach for snat persistence in the codeshare you can look at as well. Before I conclude, I wanted to mention that there is a non-iRule solution to this problem: BIG-IP Carrier-Grade NAT. CGNAT offers Large-Scale NAT (LSN) pool persistence that makes this a simple checkbox, and is way more performant than the iRule could ever be. So if you are in a pinch with what you have, iRules again to the rescue! But if you are starting fresh with new designs, CGNAT is the way to go.
Link Controller sync issues
Hi Folks. We tried to configure LC from standalone to HA (Active-Standby). When we run gtm_add the objects of LC was synced. After, when we try to sync from Device Management only LTM objects are synced. Other issue is that the monitors mark down (Links and wideips) on Standby Unit. We followed the next steps ( https://support.f5.com/kb/en-us/products/lc_9_x/manuals/product/lc-implementations-11-6-0/4.html😞 -Build cluster with HA vlan and failover connection. -Sync using HA VLAN. Secondary using MGM. -Network failover using HA VLAN. -Create Sync failover group. -Configure NTP. -Add the floating IPs and Sync. -Configure Port-lockdown allow default. -Enable Golbal traffic Sync. -Run gtm_add tool. -Test to add LC object and is not synced. Only works when run again gtm_add tool Note: For one ISP we have one public IP available (used only for outbound traffic). The self-IP is configured on Active Unit. F5 active ISP 1 .- Self IP and floating IP (Vlan 2) ISP 2.- Self IP and floating IP (Vlan 3) ISP 3.- Self IP and floating IP (Vlan 4) ISP 4.- Self IP ( Vlan 5) (We have 1 public IP) F5 standby ISP 1.- Self IP and floating IP (Vlan 2) ISP 2.- Self IP and floating IP (vlan 3) ISP 3.- Self IP and floating IP (Vlan 4) ISP 4.- No self IPLink Controller, dual-homing with two ISP and own ASN and IP blocks
Hello, I've been reading and searching around to find an answer to my question but there is one part that is not clear. We have a data center with our own /21 IP block and ASN. Currently we are connected through an ISP and have a pair of BIG-IP Link controllers in HA connected to a pair of Cisco routers which are then connected to the service provider. Inbound traffic goes through a Firewall before entering the network. It is not possible to provide IP-transit, so BGP is out of the question. We want to have a second ISP as backup link so we can have failover in case the main link goes down. Everything I read around the Internet speak about how to configure the links and how the device manages links and can load balance. I understand the scenarios where we should have two separate VLANs for connections to ISPs, and virtual servers and pools. But the question is, knowing that we have our IP block that should be advertised by the ISP for global routing, how is that managed in case a second ISP enters the game, since they should both advertise the routes towards the data center, what happens if one link goes down? Does this setup require the ISPs to cooperate with us and perhaps stop advertising if one link goes down, thus the setup is no longer transparent to the ISPs? Also, when having both links up and running, with both ISPs advertising, does this mean response packets can come back through the other link? and does the BIG-IP handle that? Or it is not possible to have the entire range advertised by both and we should be splitting the range and have each service presented with two virtual servers, one for each link? I'm confused.
GTM Sync or Device Management Sync?
I have an old pair of devices on HA in version 11.6.4, they don't have GTM module, but Link Controller instead. There's an issue that sometimes, suddenly, Wide IPs configuration is changed without any human intervention, and I think that is probably due that I have Device Management Sync in Manual, and also I have Link Controller Configuration Synchronization activated. So, my theory is that maybe I only need to have Device Management Sync configured, and Link Controller Configuration Synchronization needs to be disabled in order to prevent issues with automatic GTM (Link Controller) sync. I'm not sure if Device Management Sync syncronize the bigip_gtm.conf file or this only happens with GTM (Link Controller) sync...
F5 Link controller ISP migration considerations
Is there any known template or best practices to migrate ISP at LC? Currently customer have 2 ISP, they would like to swap one of the ISP link to another provider Any recommendation to manipulate the settings so that it can be done per phase (less distruption) instead of all-in? They have quite a number of web app hosted (Inbound request)
