An Established session proves that two BGP speakers can exchange messages. It does not prove that your prefix passed either side's filters, reached other networks, or leads to a working service.
The useful question is: where does the evidence stop? Work through the handoffs in order, keeping the session running while you collect evidence. Restarting BIRD at every step makes it harder to separate a routing change from a temporary recovery.
This guide starts after the BGP session walkthrough. Examples use BIRD 2, documentation prefix 203.0.113.0/24, service address 203.0.113.10, and protocol name upstream_v4. Substitute your own prefix, address, and the protocol name from the portal-generated configuration. The example addresses cannot be routed on the public internet.
Start with the exact failure
Write down a destination address, address family, source network, protocol, port, and UTC time. “IPv4 HTTPS to this address fails from my home connection” is a reproducible test. “BGP is broken” is not.
| Last confirmed observation | Next place to look |
|---|---|
| Session is Established | Is the exact prefix in BIRD? |
| Prefix exists in BIRD | Does it pass the peer's export policy? |
| Local export contains it | Does the upstream accept and propagate it? |
| Remote network sees it | Does traffic reach the VPS? |
| Requests reach the VPS | Can the service answer and route the reply? |
Run IPv4 and IPv6 investigations separately. Success on one does not clear the other.
Check the route before the session
sudo birdc show protocols all upstream_v4
sudo birdc show route 203.0.113.0/24 all
sudo birdc show route 203.0.113.0/24 export upstream_v4
sudo birdc show route 203.0.113.0/24 preexport upstream_v4
The exact-prefix lookup checks the aggregate you intend to announce. A service /32 alone does not create its covering /24. Compare preexport with export: the former skips the export filter; the latter applies it. These are local views, not confirmation from the neighbour. See the BIRD 2 command reference.
If the prefix is absent, inspect the protocol that should originate it. If it exists but is not exported, inspect the selected route, address-family channel, and the generated export filter. Keep the explicit allowlist of your own prefixes; changing to export all is not a diagnostic fix.
A static blackhole route can supply an aggregate for announcement, but it does not deliver traffic to an application. You still need local service addresses or more-specific forwarding routes for the destinations that should work. The anycast guide shows that distinction in a complete deployment.
Check authorisation and upstream acceptance
Verify the exact prefix length and origin ASN against your ROA and IRR objects. A covering ROA with the wrong origin or an insufficient maximum length can make an announcement Invalid. A missing ROA is a different state; it is not evidence of successful authorisation. RIPE explains these states in its origin-validation guide.
Use your real values in the RIPEstat RPKI lookup, then follow the ROA and IRR checklist if they disagree. This lookup checks authorisation, not whether a router received your announcement.
In VPS Control, check the session's configured prefixes and prefix limit. If a limit needs adjusting, use the session's Edit flow. Preserve the portal-generated peer details when changing your local policy.
Next, look for the prefix and origin in an external looking glass or route collector. Check more than one network. A collector sees routes from its peers, so absence from one collector is not proof of global absence. Conversely, one visible route is not proof that every network accepts it.
If local export looks correct but the upstream view does not, collect the exact prefix, session, UTC timestamp, and command output for the network team. That gives them a specific acceptance decision to investigate.
Follow a packet through Linux
From an outside host, make one request while watching the VPS:
ip -br address
ip -4 route show table all
ip -4 rule show
sudo ss -lntup
sudo nft list ruleset
sudo tcpdump -ni any -c 30 'host 203.0.113.10 and tcp port 443'
These are inspection commands. Limit captures to your test traffic and protect captures that contain application data.
If requests never arrive, investigate the upstream path and any filtering before the guest. If they arrive but there is no response, check that the destination is actually assigned, the listener accepts that address, and the firewall permits the request. A service bound only to the VPS's original address will not automatically listen on an address from your announced prefix.
For a local application, a forwarding sysctl is not the missing step. For a VPS routing traffic onwards to another host, check forwarding, the forward chain, and the downstream route as separate requirements.
Prove the return path
Use the address of a remote test host you control. Here 198.51.100.20 is another documentation placeholder:
ip -4 route get 198.51.100.20 from 203.0.113.10
Does the selected interface and next hop match your intended egress? Check policy-routing rules as well as the main table. An outbound test using the VPS's original source address does not prove that replies sourced from your announced prefix work.
If a packet arrives on one interface but its return route uses another, inspect IPv4 reverse-path filtering on all and the receiving interface. Strict mode can reject that asymmetric traffic. Diagnose the routing design before changing the setting; the kernel uses both values when applying the check. See the Linux reverse-path filtering documentation.
For IPv6, repeat the address, route, rule, firewall, and listener checks using IPv6 values. The IPv4 rp_filter setting is not an IPv6 troubleshooting knob.
Close the incident with outside evidence
Retest the original source and at least one independent network. Check the application, not only ping. Record the successful UTC time alongside the changed filter, route, or listener setting.
For wider coverage, use RIPE Atlas measurements. Keep the local export output and remote evidence together: the next time a session is Established but a service is unreachable, you will have a known-good path to compare against.