XROUTE · PT DEWATA TELEMATIKA
Routing Policy — AS58401
Version 1.1 · Effective 1 September 2026 · Last updated 27 August 2026
READ THIS FIRST
XROUTE is not an IXP, and it is not a transit provider. We do not sell a full BGP table.
We sell capacity to specific destination networks. You choose which ASN you want to reach, from which exchange, and at what capacity. You receive the prefixes of that destination — nothing more. Each subscription is a route, identified by a Circuit ID.
This model is additive. XROUTE runs alongside your existing transit and peering, not instead of it. If you are looking for default route or a full table, we are not the right provider.
NETWORK AT A GLANCE
1. What You Receive
When you order a route, we announce to you the prefixes originated by the destination ASN you selected. You do not receive the rest of the XROUTE table, and you do not receive a default route.
- One BGP session can carry multiple routes. Each route is billed and tracked separately by its Circuit ID.
- Capacity is ordered in multiples of 100 Mbps, with 100 Mbps as the minimum.
- Routes are tagged with communities identifying the source PoP, so you can apply your own traffic-engineering policy.
- Adding, changing, or removing a route is done from the Member Portal. No NOC ticket required.
Circuit ID format: XROUTE-{CITY}-AS58401-AS{YOUR-ASN}-{SEQ}
2. Path Preference
Routes learned through XROUTE are announced with local-preference 1500 by default. Whether that path wins over your existing transit or peering is entirely your decision — apply your own local-pref, AS-path prepending, or community-based policy on your side.
We do not require exclusivity. Keeping a second path to the same destination through another provider is expected and encouraged; redundancy is your business, not ours to restrict.
3. Capacity and Rate Limiting
Each route is rate-limited to the capacity you ordered. Two details matter in practice:
The 10% allowance covers packet header overhead. Without it you would receive less usable throughput than you paid for. The rate limit applies to the route as a whole, not to each prefix individually.
The 2× oversubscription ratio applies to our transport capacity between PoPs and is standard industry practice. It is accounted for in our pricing and monitored per route.
4. Peering Policy
AS58401 operates a selective policy. BGP sessions are established with subscribing customers, and at internet exchanges where XROUTE maintains a presence.
Requirements for a customer session:
- A registered ASN with an up-to-date PeeringDB record.
- Route objects in a recognised IRR, or a valid RPKI ROA, for every prefix you announce to us.
- A NOC contact reachable 24 hours a day.
- An active subscription with sufficient prepaid balance.
There is no minimum traffic volume and no separate peering fee — capacity is billed through the subscription.
5. Prefix Filtering
Prefixes are controlled on a per-session basis before entering the XROUTE table. We describe below what is active today and what is still being built, rather than describing a target state as if it were already in place.
Active now:
- Explicit route distribution. Each BGP session carries its own filter chain. Only prefixes matching the policy defined for that session are accepted or announced; everything else is rejected by a closing rule. Routes are not passed between sessions by default.
- Maximum prefix limits per session, as listed below.
- Manual review at onboarding. Announcements are checked against IRR route objects and PeeringDB records when a session is established, and when a customer changes what they announce.
Being deployed:
- Automated bogon filtering — private, reserved, documentation, and unallocated space, plus private ASNs in the AS path.
- Prefix length enforcement — IPv4 /8 to /24, IPv6 /19 to /48.
- AS path validation — first-AS matching, with the exceptions required for route server sessions.
- RPKI Route Origin Validation — see section 6.
These four are being rolled out PoP by PoP through scheduled maintenance windows. This page is updated as each one becomes active. We would rather publish a shorter list that is accurate than a longer one that is not.
MAXIMUM PREFIX LIMITS
Higher limits are available on request. Contact peering@xroute.id before you approach the limit — an unexpected session shutdown helps nobody.
6. RPKI Route Origin Validation
RPKI Route Origin Validation is currently being deployed across the XROUTE edge. Until it is active on a given router, origin validation relies on IRR and PeeringDB data as described above.
Publish ROAs for your prefixes regardless of our deployment status — a valid ROA protects your network across the entire internet, not only within XROUTE. This page will be updated when validation becomes active, including the policy applied to invalid announcements.
7. Source Address Validation
XROUTE applies source address validation in line with BCP 38 to prevent traffic with forged source addresses from leaving our network.
- Egress filtering is active on XROUTE infrastructure servers.
- Edge router uRPF deployment is in progress, scheduled through maintenance windows.
- Customers are expected to apply anti-spoofing on their own networks. Sending spoofed traffic through XROUTE is prohibited and may result in immediate suspension.
8. BGP Communities
Minimum /24 for IPv4 and /48 for IPv6, and only for prefixes you are already authorised to announce. Traffic to the tagged prefix is dropped at the network edge within seconds. PoP-identifying and traffic-engineering communities are documented in the Member Portal.
9. What We Announce
XROUTE announces only prefixes it is authorised to originate, together with customer prefixes where the customer has authorised us. We do not announce prefixes learned from one peer to another peer unless a transit arrangement exists.
10. Maintenance and Incidents
Scheduled maintenance is announced at least 5 business days in advance by email, carried out between 00:00 and 06:00 WIB where possible. Emergency maintenance may occur at any time when required to protect network security or integrity, with notification as soon as practicable.
Critical incidents are responded to within 1 hour, 24 hours a day. Availability is guaranteed at 99.5% per calendar month — see our Terms of Service for the full SLA and service credits.
11. Routing Security Commitment
XROUTE is committed to the routing security practices promoted by MANRS: preventing propagation of incorrect routing information, preventing traffic with spoofed source addresses, facilitating global operational communication, and publishing our routing policy — this page.
We state our position plainly. Filtering, coordination, and policy publication are in place. RPKI validation and edge uRPF are still being deployed. We will update this page as each item is completed rather than claim more than we currently do.
Contact
- Peering requests: peering@xroute.id
- Network operations, 24/7: noc@xroute.id
- Abuse reports: noc@xroute.id
- WhatsApp: +62 815 511 3333
- PeeringDB: peeringdb.com/net/21946
PT Dewata Telematika · Jalan Teuku Umar Barat No. 170A, Denpasar Barat, Bali 80114 · +62 361 3012345
© 2026 XROUTE · AS58401 · Routing Policy v1.1