ANYCAST · SELECT · FAIL · CONVERGE
Anycast routing and service health
Observe the route a network sees, not an imaginary nearest-server shortcut.
| Site | Visible | Preference | Path | Cost | RTT | Health |
|---|
Exact routing evidence
Inspect route candidates and request totals
Inspect routes to one shared service
Three ingress networks each choose among advertisements from sites A, B and C for one shared service prefix. Every logical tick from one through sixty sends one request from each ingress. The diagram connects each ingress to its selected site, while the table shows the candidate attributes behind that decision. Selection uses higher local preference, then shorter path length, then lower interior cost, then site identifier as a deterministic tie-break. This is an explicit teaching subset, not the complete BGP decision process. Screen positions and the illustrative RTT column do not drive selection.
Change routing policy and advertisements
Preferred site gives that site preference one hundred fifty instead of one hundred at every ingress in this fixture. No preference leaves them equal. Extra path length for B adds to its advertised path length; it cannot override a higher preference. Advertise A, B and C determine which sites participate from the beginning. Inspect ingress selects the candidate table without changing traffic. Failed site chooses which service becomes unhealthy at tick ten, or no failure. Health detection delay and Base propagation delay determine when a withdrawal reaches ingress zero; ingress one and two add two and four ticks respectively. Withdraw unhealthy route controls whether that removal happens at all.
Reproduce the failed-service window
Keep defaults: A fails at tick ten, detection takes three ticks and base propagation takes two. Ingress zero keeps selecting A through tick fourteen, so five requests fail. At tick fifteen its route disappears and selection moves to B. The final accounting is 175 served, five failed and zero with no route. Choose A as Preferred site so all ingresses initially select it. Their different withdrawal arrival times produce twenty-one failed requests overall. Disable withdrawal and the unhealthy route remains selected: with default preferences, fifty-one requests fail from tick ten through sixty. A health failure and a routing update are not the same event.
Compare recovery and route absence
Recover service at tick forty restores the failed service. When withdrawal is enabled, its route returns after base propagation delay plus each ingress offset; restoring health is not instantly visible in every routing table. With withdrawal disabled, existing routes can use the recovered service immediately, yielding thirty failures at the affected default ingress. Disable all three advertisements: no ingress has a route and all 180 requests are classified as no route, not as failed service requests. Leave only A advertised and fail it: traffic first reaches the unhealthy service, then becomes unroutable as withdrawals arrive.
Inspect selection instead of assuming nearest
At ingress zero the default path to A is shorter than the path to B, although its illustrative RTT is ninety milliseconds compared with twenty for B. The selected route is A. Change preference or path length and inspect why the selected row changes rather than treating anycast as a lowest-latency query service. Play advances sixty ticks over sixty inspection seconds. Pause holds the state; Next tick advances one; Restart rewinds; Speed adjusts viewing pace; Inspect time scrubs; Show final result jumps to the last state. Restore defaults resets all model controls. Parameter edits rebuild and pause the trace.
State the simplifications
The model assumes a single prefix, fixed candidate attributes and deterministic update arrival times. It has no route loops, packet-level forwarding, route reflectors, multipath, session persistence, route dampening, prefix-length competition, MED or origin attributes, RPKI, retransmissions or service-state replication. RTT values are fixed illustrative labels rather than measurements or ranking inputs. Propagation does not model an actual distributed BGP exchange; each ingress receives a scheduled visibility change. The totals classify request opportunities without simulating response duration. Use this lab to separate route policy, convergence and service health, not to predict production failover timing or certify a BGP configuration.
Operational reference: RFC 4786, Operation of Anycast Services.