Summary

  • F5 scheduled its Mexico Regional Edge, identified as qro1-mx, for 08:00 UTC on 22 August 2026. At 09:42 UTC on 23 August, its status page still showed Monitoring and contained no update after the original 8 August notice.
  • F5 also told customers to add 159.60.179.0/24 to origin firewall allowlists. A provider edge can therefore become eligible to handle traffic while a customer origin still rejects its source addresses.

A precise launch time is useful only if the operational state can later be closed. F5 gave qro1-mx an exact target — 08:00 UTC on 22 August — but its public status page had not said whether the Mexico Regional Edge was active by the following morning.

The page captured at 09:42 UTC on 23 August was still marked Monitoring, about 25 hours and 42 minutes after the scheduled time. It contained one update, posted on 8 August, with the original schedule and configuration instruction. There was no later Completed, Resolved or equivalent statement.

That absence is not proof of a failed or delayed launch. Statuspage labels can remain open for reasons that are not visible to readers, and F5 may have activated the site without posting a second message. The evidence supports a narrower conclusion: the provider's public record did not yet verify completion.

The configuration instruction makes that ambiguity operationally relevant. F5 told customers to add 159.60.179.0/24 to origin-infrastructure firewall allowlists before the scheduled go-live so the new Regional Edge could connect back to applications. F5 controls the edge and the rules that may select it; each customer controls the firewall or proxy that decides whether its source addresses may reach the origin.

Those states can diverge. The edge might be healthy while a stale customer rule rejects a connection. A customer might successfully accept traffic from the new range while the provider's public page remains Monitoring. Neither observation, alone, proves the whole path.

F5's firewall reference, last modified on 20 August, includes 159.60.179.0/24 in the Americas inventory for Regional Edges. It lists the range for TCP ports 80 and 443 and again for UDP 4500 and 123. F5 says UDP 4500 is optional when SSL provides the tunnel and that UDP 123 supports the edge's NTP service.

That table is a service reference, not a direction to expose every listed port in every deployment. An operator still needs to match the rule to the F5 service in use, the expected direction and the intended destination. The defensible change is narrow, logged, tested and reversible.

F5 also says customers should allow its Distributed Cloud subnets specifically so direct traffic cannot bypass the provider's infrastructure. Adding a provider-owned /24 therefore changes the trusted-source perimeter. It is not evidence of a vulnerability, breach or outage, but it deserves the same change control as any production firewall expansion.

Address records supply context without resolving the status. A RIPE RDAP response for 159.60.179.0 covers the active parent range 159.60.128.0–159.60.191.255 under the name F5-DISTRIBUTED-CLOUD-1. F5's geofeed places only 159.60.179.0/25 in Querétaro. Neither source proves that the full /24 was announced in BGP, that a particular facility was live or that customer traffic used qro1-mx.

F5 says the Mexico site will lower latency, process traffic closer to users and match the capabilities of its other Regional Edges. Its global-network material describes points of presence linked through a private backbone and running routing, SD-WAN termination, load balancing and security functions. These are provider descriptions. The cited public materials provide no before-and-after Mexico latency, route, volume or availability measurements.

The useful news is therefore not a new dot on a network map. It is an observability gap across a shared control boundary. Completion requires separate evidence that the provider activated the edge, the route was reachable, the origin accepted the new source and the application worked.

Sources