BGP routes, tunnel probes, and application checks

Three green lights answer three different questions

A branch application times out. The operator sees an established BGP session and assumes the network is healthy. Another operator sees successful tunnel probes and assumes the application is healthy. Both observations leave gaps.

Treat the diagnosis as three separate claims: a route was advertised and selected; the intended tunnel carried a probe; the intended application completed a request. A route can point toward the correct subnet while a firewall rejects the service port. A probe can reach the border router while the backend is unavailable. These are original diagnostic examples, not incidents measured on Cloudflare.

The October 5 GA announcement changes availability: IPsec/GRE BGP is generally available for Cloudflare WAN and Magic Transit accounts using Unified Routing, without a separate enablement step. CNI BGP remains closed beta. GA does not prove that a particular customer's forwarding path works.

The route has a control path and a data path

RFC 4271, published in January 2006, defines BGP as exchange of destination reachability and path attributes. Its routing information bases distinguish received, selected, and advertised routes. This is the protocol foundation; later RFCs update it.

1. 1CPE export policy
2. 2BGP advertisement
3. 3Cloudflare route selection
4. 4Forwarding table

1. 1Application packet
2. 2Selected destination route
3. 3Tunnel
4. 4Application response

1. 1Tunnel probe
2. 2Probe target response
3. 3Tunnel health observation

This original schematic separates the information used to make forwarding decisions from packets sent afterward. It is not a packet capture or a complete Cloudflare topology.

Cloudflare's traffic-steering reference places this peering inside a customer's virtual network, separately from Internet peering with ASN 13335. Its architecture propagates learned routes into distributed forwarding tables. BGP does not replace tunnel health checks. During the documented Edge Resiliency Mode, forwarding can retain the last valid table while new control updates cannot propagate normally.

The operational implication is narrower than “BGP down means traffic stopped.” Capture route age, the selected next hop, tunnel evidence, and the actual request result. A stale route may still forward; an established session may still advertise an unsuitable prefix. Those are hypotheses to test, not observations from this run.

What changed after the 2024 on-ramp discussion

The February 7, 2024 SASE announcement discussed connecting users and sites through different on-ramps. It supplies architecture history, not a BGP availability date. January 30, 2026 introduced BGP over IPsec/GRE in beta; October 5 changed that feature to GA for Unified Routing accounts.

Our research window is September 6, 2026 at 17:16:05 through October 6 at 17:16:05, Asia/Tokyo. Only the October GA announcement is a dated primary update within that window for this chapter. Current configuration pages were checked October 6; their access date is not a release date.

Settings that determine the experiment

The configuration reference states that the CPE initiates the session toward the tunnel's Cloudflare-side IPv4 interface address. External BGP uses different ASNs. Cloudflare's advertised Hold Time is 240 seconds; the negotiated value is the smaller peer value. The minimum supported value is 30 seconds; at least 90 is recommended. The optional MD5 key is explicitly not a security mechanism; its documented purpose is avoiding misconfiguration.

Keep the distinction between a lower bound and a recommendation. A timer experiment needs the configured peer values and observed session events. Neither a chosen timer nor a healthy session measures application availability.

The health-check reference describes encapsulated ICMP probes and distinguishes tunnel checks that inform steering from endpoint checks that do not. A probe's target and direction determine what its success demonstrates. Do not rename an ICMP response “application health.”

Evidence to collect	Question it can answer	Question still open
Session state and received prefix	Did this peer exchange this route?	Was this route selected and propagated?
Selected route and next hop	Which path should this destination use?	Can this packet traverse it now?
Probe target, direction, result	Did that specific probe return?	Did the authenticated application request succeed?
Application status, response, timestamp	Did this request satisfy its acceptance check?	Does another site or failure condition behave the same?

The table is an original investigation plan. It does not assert that every field is available in every dashboard or device. Choose current supported inspection tools for the actual environment and preserve their timestamps.

A strict export-policy check on synthetic input

Before changing a router, write down exactly which destinations the branch owns. Here the invented approved set contains one prefix, 10.42.8.0/24. A more specific child may still route traffic, but it was not approved in this exercise. A default route would broaden the export far beyond the intended application network.

The following unexecuted offline Python exercise parses input strictly and compares exact sets. It performs no network request and configures no router. It is a policy fixture, not a BGP emulator or a Cloudflare configuration validator.

from ipaddress import ip_network

allowed = {ip_network("10.42.8.0/24")}
cases = {
    "approved": ["10.42.8.0/24"],
    "unapproved-child": ["10.42.8.0/25"],
    "default-route": ["0.0.0.0/0"],
    "host-bits": ["10.42.8.7/24"],
}

for label, values in cases.items():
    try:
        advertised = {ip_network(value, strict=True) for value in values}
        if advertised != allowed:
            raise ValueError("advertisements differ from the approved set")
        print(label, "PASS")
    except ValueError as error:
        print(label, "FAIL", str(error))

Expected by inspection: only approved passes. The child prefix and default route fail the exact-set check. The host-address form fails strict network parsing. Failure is visible; the exercise never silently widens the allowed set or replaces bad input.

This intentionally small check omits AS paths, next-hop reachability, withdrawals, duplicates, IPv6, and device syntax. An approved export policy is necessary for this exercise's scope, but does not establish any of those properties. Keep actual account addresses and credentials out of a public worksheet.

Plan the network observation before making a change

In a separately authorized test network, first record the account's Unified Routing status, tunnel type, both ASNs, peer addresses, approved prefixes, and current route evidence. Use an owner-approved identity with the minimum configuration permissions; this article supplies no access expansion or token.

Next, observe one intended destination through the four layers in the table. Match the route and probe to the same tunnel and site. Then perform a controlled route withdrawal or service failure only in that test environment. Record which observation changed first, which remained green, and when the application succeeded again. A service failure is especially useful for showing why BGP can remain established during an application outage.

This network exercise has not been run. No convergence, loss, throughput, or recovery time is reported. A hypothetical estimate can sum observation intervals, but must not be labelled a measured outage or SLA.

If the session never establishes, inspect initiation direction, peer addressing, ASN agreement, and device logs. If it establishes without the intended prefix, inspect export policy and received-route evidence. If the route is present but the request fails, inspect the selected path, probe scope, firewall, service listener, and response. Preserve a failed result instead of switching to another path and calling the first test successful.

BGP is useful when site reachability changes often enough that hand-maintained prefixes become a concrete operational problem. A small fixed lab can retain an explicit static routing design without introducing a routing protocol merely because GA exists. Dynamic routing adds session state and route policy to diagnose. Product access and connectivity costs depend on the customer's agreement; this chapter has verified no price or bill. The offline fixture needs no paid service.