SYSTEM Cited by 1 source
V.tal GlobeNet (AS52320)¶
V.tal GlobeNet is a Colombian network service provider, operating AS AS52320.
Role in the 2026-01-02 BGP anomaly¶
V.tal GlobeNet was the recipient of the leaked routes in
the AS8048 hairpin leak: its customer AS8048
(CANTV) advertised to it prefixes
originated by AS21980 but learned indirectly via AS8048's
other upstream AS6762
(Sparkle) — producing paths like
52320, 8048 (x9), 23520, 1299, 269832, 21980.
From V.tal GlobeNet's perspective, this was a valid BGP update from its customer. Under present-day protocols, there's no cryptographic signal that would have let AS52320's routers reject the update: AS21980 is a legitimate origin, the prefix list matched AS8048's customer cone, and the path loop prevention check passed.
What would have let AS52320 reject¶
- ASPA — if Sparkle (AS6762) had
published an ASPA object with the
AS0upstream declaration, AS52320 would see AS6762 downstream-of-AS8048 on the leaked paths and recognise this as contradicting Sparkle's ASPA → reject. - RFC 9234 OTC — if AS8048's session with AS52320 negotiated a Customer→Provider role (AS8048 = Customer) and the OTC attribute was set on the leaked routes (because they were received from AS6762, a non-customer), AS52320 would reject the received route as OTC-set-from-a-customer.
- Peerlock (operator-side) — a rule "reject customer-learned routes containing AS6762 in the path" would catch it.
Seen in¶
- sources/2026-01-08-cloudflare-a-closer-look-at-a-bgp-anomaly-in-venezuela — named recipient AS for the leaked routes; the ASPA worked example has AS52320 as the verifier rejecting Sparkle's indirect appearance.