About AS393941
AS393941 is a cybersecurity and infrastructure consultancy operating a multi-datacenter network with presence in:
- Seattle, WA (primary)
- Kalamazoo, MI
- Denver, CO
- Vancouver, BC (VANIX)
We operate a dual-stack (IPv4/IPv6) network and are committed to a healthy, well-maintained routing ecosystem.
Technical Requirements
To establish and maintain a peering session with AS393941, peers must meet the following requirements:
BGP & Routing
- Maintain a publicly routable ASN registered with an RIR (ARIN, RIPE, APNIC, etc.)
- Have a current and accurate entry in PeeringDB
- Maintain up-to-date route objects in a public IRR database (e.g., ARIN, RADB, RIPE)
- Support and enforce RPKI Route Origin Validation (ROV) — we filter RPKI-invalid prefixes and expect peers to do the same
- Only advertise prefixes that your network legitimately originates or has been authorized to announce
Prefix Limits
- Agree to a reasonable maximum-prefix limit appropriate to your announced address space
- Sessions will be suspended if prefix limits are exceeded without prior notice
Connectivity
- Private peering sessions are preferred where we share a common facility or IX presence
- Route server peering is accepted at exchanges where AS393941 is present
- Sessions must remain stable; peers with persistent flapping sessions may be suspended
Communities
- Peers should honor standard BGP well-known communities
- AS393941-specific BGP communities are documented separately upon request
What We Announce
- All prefixes originated by AS393941
- No transit routes — we do not provide transit via peering sessions
- Full list of prefixes available via our IRR records and RPKI ROAs
What We Expect Peers to Announce
- Only prefixes legitimately originated by or authorized to the peer's ASN
- No default route
- No more-specific prefixes than those registered in IRR / covered by RPKI ROAs
Filtering
AS393941 applies the following inbound filters on all peering sessions:
- RPKI Invalid prefixes are rejected
- Prefixes not found in the peer's IRR records are rejected
- Bogon prefixes and reserved address space are rejected (per IANA/RFC guidelines)
- Prefixes longer than /24 (IPv4) or /48 (IPv6) are rejected
We strongly encourage all peers to implement equivalent filters outbound.
Maintenance & Operations
- We will provide advance notice of planned maintenance where possible via the NOC contact
- Emergency maintenance may occur without prior notice; we aim to notify peers promptly
- AS393941 participates in the global NOC community and responds to abuse/operational issues within 24 hours
How to Request Peering
- Ensure your network has an accurate PeeringDB entry
- Email anthony@as393941.com with:
- Your ASN
- Desired peering location(s)
- IPv4 and/or IPv6 peering addresses
- Your NOC contact
We aim to respond within 2-3 business days to emails and tickets.
If your request is an emergency, please contact our on-call engineer.
Disputes & Policy Changes
AS393941 reserves the right to modify this peering policy at any time. Changes will be reflected on this page and in PeeringDB. Existing peers will be notified of material changes. We reserve the right to de-peer any network that violates these guidelines, engages in route leaks, or poses operational risk to our network or customers.