Policy Agile Solutions Provider operates under ASN 328748 and maintains a selective peering policy. We reserve the right to refuse, or to terminate, peering with any party at our discretion. Except where a session presents an operational or security risk, we will give existing peers 30 days' notice via their registered peering contact before terminating a session. This policy applies equally to IPv4 and IPv6 peering. Last updated: August 2026.
What Agile Solutions Provider Will Do 1. Announce only prefixes legitimately assigned to Agile Solutions Provider or received from our customers. 2. Maintain up-to-date route objects in a route registry for all announced prefixes. 3. Maintain valid RPKI ROAs for all prefixes originated by AS328748. 4. Maintain an up-to-date PeeringDB entry for AS328748. 5. Provide peers with a monitored, reachable email address for peering-related issues. 6. Support both public and private peering arrangements. 7. Encourage peering at multiple mutual locations, though this is not mandatory. 8. Ensure peering links remain uncongested and upgrade congested links promptly. 9. Apply anti-spoofing ingress filtering per BCP38 on customer-facing edges. 10. Adhere to MANRS principles. 11. Promptly address any routing mistakes or prefix leaks. 12. Honor MEDs received from peers. 13. Avoid unnecessary de-aggregation of prefixes. 14. Announce routes consistently across all peering sessions, except where required for customer-specific traffic engineering.
What We Expect From Our Peers 1. Announce only prefixes legitimately assigned to them or to their customers. 2. Avoid excessive AS_PATH prepending and unnecessary de-aggregation. 3. Apply BCP38 anti-spoofing filtering and adhere to MANRS principles where feasible. 4. Provide monitored contact details for peering-related issues, and respond to reports of routing incidents promptly. 5. Maintain up-to-date route objects in a route registry. 6. Maintain valid RPKI ROAs for originated prefixes, or be willing to implement RPKI signing on request. 7. Ensure sufficient capacity on peering links to avoid congestion. 8. Maintain an up-to-date PeeringDB entry.
Peering Requirements - We do not require minimum traffic volumes, traffic ratios, or contracts for public peering. - We may consider contracts for private peering if requested. - We generally do not peer with route servers; we prefer direct bilateral sessions.
Peering Restrictions - We do not peer with our own customers. - We may decline peering with networks that are customers of our customers. - A peering session with AS328748 provides reachability only to prefixes originated by Agile Solutions Provider and our customers. Peering is not an IP Transit or Internet Access service, and does not include access to on-net CDN or caching infrastructure. For transit or connectivity services, please contact sales.
Route Filtering Policy We do not build per-peer IRR-based prefix filters on peering sessions. We do, however, apply the following sanity filters to all peering sessions. We will not accept: - IPv4 prefixes longer than /24, or IPv6 prefixes longer than /48; - Private, reserved, or otherwise unallocated (bogon) address space; - Default routes (0.0.0.0/0 or ::/0); - Prefixes originated by AS328748 or assigned to our customers; - Routes with private ASNs anywhere in the AS_PATH; - Routes whose AS_PATH contains major international transit networks, as protection against route leaks. In addition: - Max-prefix limits are configured on all peering sessions. If a session exceeds its limit it is shut down, and the peering contact on record may be notified before the session is restored. - We intend to drop RPKI-invalid announcements on peering sessions as this capability is rolled out across our edge. - We perform strict prefix, AS_PATH, and max-prefix filtering on all customer BGP sessions. - We do not implement uRPF on peering routers.
Technical Requirements - Peering sessions must be direct eBGP (no multi-hop), using public ASNs and public address space only. Sessions across an exchange fabric must use the addresses assigned by the IXP. - We exchange both IPv4 and IPv6 routes, natively over the respective address family. - Peers must not point default routes toward Agile Solutions Provider, use static routes to send us traffic for destinations we have not announced, or offer our next-hop to third parties. - MD5 authentication on BGP sessions is supported on request.
Peering Contact Information For peering inquiries: [email protected] Peering locations: for a list of exchange points and data centre facilities where you can peer with Agile Solutions Provider, please see our PeeringDB record.